A county must generate embeddings for a large ordinance corpus ahead of RAG go-live. Which processing pattern is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
Don’t calculate every ordinance embedding while a resident is waiting on chat. Batch the heavy lifting with Lambda-style jobs so the vectors are ready before go-live, like prepping labels before opening day.
Full Explanation
Generating embeddings for a large county ordinance corpus before RAG go-live is a batch compute problem. Batch embedding generation with scalable compute such as AWS Lambda (or equivalent job infrastructure) over the corpus prepares vectors ahead of traffic, controls cost through parallelism and retries, and avoids putting heavy embedding work on the resident chat path. Precomputation is the appropriate processing pattern for go-live readiness.
Generating embeddings synchronously inside each resident chat for every ordinance page fails latency, cost, and reliability under load. Asking staff to manually type embedding vectors into a spreadsheet fails scale and correctness. Skipping embeddings and retrieving only by unsorted S3 object keys fails semantic retrieval—the core of RAG over ordinances.
Exam caveat: Offline/batch embedding for large corpora is standard; online per-request embedding of the whole corpus is an anti-pattern.
Operational check: run idempotent batch jobs with progress checkpoints, validate embedding counts match chunk counts, load vectors into the store before cutover, smoke-test ordinance queries, and keep a re-batch path for amendments without synchronous chat embedding.