A transit chatbot should explain delays using Knowledge Base facts and escalate low-confidence drafts for human review. Which safety pattern implements that behavior?
Select an answer to reveal the explanation.
Short Explanation
Riders deserve delay facts from the ops playbook, not creative writing. Ground answers in the Knowledge Base and send shaky drafts to a human—like a dispatcher double-checking the board before the announcement.
Full Explanation
A transit chatbot should explain delays using Knowledge Base facts and escalate low-confidence drafts for human review. The safety pattern is retrieval grounding plus confidence-based human routing: delay explanations must come from approved ops knowledge, and uncertain generations must not auto-publish. That combination protects riders from improvised status messages while keeping GenAI useful for routine, well-supported answers.
Answering every delay question from general web chatter with no Knowledge Base and no confidence checks fails by concept: untrusted web text is not the transit authority’s operational truth. Suppressing all factual sources so the model improvises rider messages for speed fails accuracy and safety. Auto-publishing every low-confidence completion directly to station loudspeakers fails because uncertain drafts can spread incorrect disruption information at scale.
Exam caveat: “low confidence” must be defined operationally (retrieval score thresholds, model confidence proxies, or policy heuristics) and tuned to avoid both alert fatigue and under-escalation. Grounding in a Knowledge Base requires fresh ops content; stale indexes produce confidently wrong answers that still look “grounded.” Human review queues need SLAs during incidents.
Operational check: query a delay scenario with strong KB hits and confirm an auto-ready grounded answer; query an ambiguous scenario that yields weak retrieval scores and confirm routing to human review; verify loudspeaker/public channels cannot be fed low-confidence drafts without approval.