RAG Assistant With Weak Retrieval and Unsupported Citations

Retrieval is the first bottleneck. Recall@5 of 0.62 means the correct passage is missing from the context in nearly four of ten queries; the generator cannot reliably answer or cite what it never receives. Fix retrieval before tuning generation:

1. Change chunking to heading-aware or semantic chunks of roughly 200-350 tokens with overlap, increase the candidate pool to 20-50, and add a reranker that passes the best 4-5 passages. This directly targets the recall ceiling.
2. Add grounded-answer enforcement: require each factual claim to map to a cited span; if no supporting span exists, abstain or escalate. This addresses the 9% unsupported citations and reduces confident wrong answers.
3. Fix freshness with event-driven reindexing or daily refresh, because 18% of articles changed in a quarter while the index updates weekly. Stale retrieval produces plausible but outdated answers.
4. Address latency after quality: stream tokens, cache frequent retrievals, parallelize retrieval and reranking, and consider a smaller or quantized generator. A 9.2-second median against a 4-second SLA is a product failure, but optimizing latency first would make an already inaccurate assistant faster.

Billing actions should wait. They require authorization, transactional correctness, and auditability that this system has not demonstrated.

Use a frozen, stratified evaluation set of at least 300 real queries, labeled independently by two support experts with adjudication. Include multi-hop questions, questions whose answers changed in the last quarter, out-of-scope requests, and adversarial prompts. Track:

• Retrieval: recall@k, MRR, and whether the gold passage is present at the rank passed to the model.
• Generation: fully/partially/incorrect correctness, faithfulness (every claim supported by a cited span), citation precision, abstention rate, and unsafe or unauthorized action rate.
• Operations: p50 and p95 latency, cost per conversation, escalation rate, and cache hit rate.

With 71% correctness on 200 samples, the 95% confidence interval is roughly plus or minus 6 percentage points. Gate on the lower confidence bound, not the point estimate. Suggested release gates: no more than a 2-point drop in faithfulness, no more than a 5-point drop in recall@5, p95 latency under 4 seconds, and zero unauthorized billing actions. Run a 5% canary against human-handled traffic and compare escalation and resolution rates before full rollout.

It is not ready. The current system has a 15% incorrect-answer rate, unsupported citations, stale retrieval, and no evidence of authorization or transactional testing. Billing actions change state and create financial and legal exposure, so the failure mode is not a bad answer but an unauthorized refund, plan change, or data disclosure.

Mandatory guardrails: separate read-only answering from action-taking; require authenticated user identity and scope-limited tool permissions; require explicit user confirmation before any state change; use deterministic business rules and idempotency keys for billing operations; log every tool call, parameter, and result; and route low-confidence or high-value actions to a human. Build a sandbox with synthetic accounts and test negative cases such as another customer's account ID, expired subscriptions, and partial failures.

Only after retrieval and faithfulness gates pass should a limited pilot be considered, for example read-only balance lookup before any write action. The product timeline should be reset around those gates.