Long RAG enrichment jobs exceed default Consumption timeouts for the city’s Function app. What hosting decision fits?
Select an answer to reveal the explanation.
Short Explanation
Think of the hosting plan as the shift length at your enrichment desk: Consumption’s default timeout may end before a large RAG job is done. A Premium or similarly extended Functions plan, with adequate timeout settings, gives the job enough time to finish reliably.
Full Explanation
Long RAG enrichment jobs that exceed default Consumption timeouts need a hosting decision that permits longer executions. Moving the work to a Premium (or similarly extended) Functions plan and configuring an adequate timeout fits the requirement: it gives large municipal documents time to finish processing. Keeping Consumption defaults and canceling enrichment halfway through every large document fails the completeness requirement, because partial embeddings can reduce RAG quality. Disabling Functions entirely and pasting enrichment prompts into a desktop chat window abandons automation, auditability, and scale. Lowering timeouts further without changing the plan only makes failures happen sooner; it does not allow enrichment to complete. Exam caveat: even Premium has limits, and very long jobs may require chunked progress or Durable Functions orchestration. Also, the plan alone may not be enough if the app retains a short configured timeout, so configure that setting explicitly where the platform allows. Practical check: measure enrichment duration on representative large documents, set the plan and timeout above the 95th-percentile duration with a margin, and alert on cancellations or host shutdowns during processing.