LLM-Based Dasher Support Automation with RAG and Quality Controls

doordash · E-commerce · 2024 · source Agentic: no · promotional bias: low · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Dasher support automation

DoorDash needed an LLM-based Dasher support system that could answer routine delivery-support issues from KB articles while controlling hallucinations, compliance risk, language limitations, and monitoring gaps.

Constraints:

• Pre-built flow resolutions handled only a small subset of support issues.
• KB articles were difficult to discover, slow to mine for useful details, and English-only.
• RAG outputs could sound natural while being ungrounded or irrelevant.
• Online guardrails had to avoid excessive latency and token usage.
• Quality monitoring had to produce actionable feedback, not just aggregate support metrics.

Architecture

DoorDash replaced pure flow-based automation with a RAG chatbot managed by LLM Guardrail and LLM Judge. The system summarizes multi-turn Dasher conversations, retrieves similar historical cases and their KB articles, inserts relevant article content into prompt templates, and generates a contextual support answer. A first guardrail tier compares response text to KB segments; failures go to an LLM evaluator for groundedness, coherence, and compliance. LLM Judge and human transcript review turn recurring issues into prompts, rules, and monitoring checks.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  dasher-conversation[Dasher conversation] --> conversation-summarizer[Conversation summarizer]
  conversation-summarizer --> historical-case-retrieval[Historical case retrieval]
  historical-case-retrieval --> kb-article-prompt[KB article prompt]
  kb-article-prompt --> support-llm[Support LLM]
  support-llm --> llm-guardrail[LLM Guardrail]
  llm-guardrail --> human-support-fallback[Human support fallback]
  llm-guardrail --> llm-judge-quality-monitor[LLM Judge quality monitor]
  llm-judge-quality-monitor --> human-calibration-review[Human calibration review]

Components

Data flow

A Dasher conversation is condensed into a core issue, matched against historical cases, and linked to relevant KB articles. The prompt template uses the conversation context, issue summary, and retrieved KB content to generate a response. The response then passes a two-layer guardrail; quality monitors and human review feed recurring issues back into prompts and rules.

Why this architecture

The architecture keeps the answer grounded in DoorDash KB articles while adding layered controls for the known RAG failure modes. A shallow semantic check limits guardrail cost and latency, and a higher-cost LLM evaluator handles cases where the shallow check is not enough. Offline LLM Judge monitoring exists because operational metrics alone did not explain how to improve the bot.

Models used: GPT-4 · Claude-3 · LLM Guardrail · LLM Judge · RAG chatbot

Scale

• The system assists thousands of Dashers every day.
  “Each day, this system autonomously assists thousands of Dashers, streamlining basic support requests while maximizing the value of human contributions.”article, stated
• The LLM Guardrail reduced hallucinations by 90%.
  “This guardrail system has successfully reduced overall hallucinations by 90% and cut down potentially severe compliance issues by 99%.”article, stated
• The LLM Guardrail reduced severe compliance issues by 99%.
  “reduced overall hallucinations by 90% and cut down potentially severe compliance issues by 99%.”article, stated
• The monitoring pipeline was based on thousands of reviewed transcripts.
  “So we manually reviewed thousands of chat transcripts between the LLM and Dashers to develop an iteration pipeline for monitoring LLM quality.”article, stated

Alternatives considered (roads not taken)

Keep the old flow-based automated support system.

Rejected because: Flow-based resolutions depended on pre-built paths and resolved only a small subset of issues quickly.

Show RAG answers without online verification.

Rejected because: Ungrounded or irrelevant responses can sound legitimate and mislead users.

Use only high-level metrics such as Dasher feedback, engagement, and speed.

Rejected because: Those perspectives did not provide actionable feedback for improving the chatbot.

Patterns

rag-retrieval (retrieval)

The bot retrieves historical cases and KB articles from a distilled conversation issue before generating the response.

guardrails-io-filtering (governance)

A two-layer guardrail checks response/article semantic similarity first and escalates failed cases to an LLM evaluator.

llm-as-judge (evaluation)

DoorDash uses LLM Judge to ask open-ended quality questions, summarize issues, and create monitoring prompts or rules.

human-in-the-loop-gate (governance)

Human agents remain the fallback for complex support, and a dedicated human review team samples transcripts for calibration.

Tradeoffs

Guardrail routing

Chose Cheap semantic similarity first, backup LLM evaluator second. over LLM-based deep evaluation for every response..

Rationale: The shallow check reduces hallucination risk cheaply while limiting expensive LLM evaluation to flagged responses.

Fallback path

Chose Default some problematic cases to human agents. over Keeping every case fully automated..

Rationale: The problematic-response volume was small enough that human fallback preserved quality while keeping high automation.

Quality improvement workflow

Chose Manual transcript review plus LLM Judge categories. over Relying only on Dasher feedback, engagement, and delivery speed..

Rationale: Manual review exposed actionable quality categories that could become prompts, monitors, or rules.

Gotchas (what bit them)

Knowledge-base content was present but hard to use directly.

Root cause: Dashers and systems had to find the right article, locate useful details, and overcome English-only articles.

Resolution: DoorDash used RAG to retrieve KB content and generate an issue-specific response.

LLM responses could propagate outdated or incorrect public information.

Root cause: Foundation models draw from public text such as Quora, Reddit, and Twitter.

Resolution: The RAG system grounds responses in KB articles and applies guardrails before delivery.

Quality monitoring needed human calibration.

Root cause: Automated monitors alone may not ensure coverage of real support-quality failure modes.

Resolution: A dedicated human team reviews random transcript samples and calibrates with automated monitoring.

Evaluation

DoorDash combines guardrail pass/fail decisions, LLM Judge categories, human transcript sampling, and outcome metrics such as hallucination and compliance reductions.

Metrics: 90% reduction in hallucinations · 99% reduction in severe compliance issues · Thousands of reviewed chat transcripts · Thousands of Dashers assisted per day · Five quality areas monitored

Outcomes

• RAG support automation reduced hallucination and compliance risk.
• The system autonomously assists thousands of Dashers each day.
• Human representatives can focus on more complex problems.
• The quality pipeline turned an initial prototype into a robust chatbot solution.

The article reports thousands of daily Dasher assists, thousands of reviewed transcripts, 90% hallucination reduction, and 99% reduction in severe compliance issues.