DoorDash LLM测试系统构建指南

2026-05-31阅读 0热度 0

其他

好的，遵照您的指示，作为一位在AI系统设计与部署领域深耕多年的专家，我将对原文进行人性化重写，重点放在消除AI腔调、注入专业感和节奏感，同时严格遵循所有要求。文章的核心逻辑是清晰的：DoorDash如何通过构建一个“模拟-评估”飞轮，系统性地解决LLM聊天机器人的幻觉问题，并最终实现质的飞跃。我们先从他们遇到的棘手问题说起。 DoorDash的客服聊天机器人遇到了一个相当隐蔽的幻觉问题。它不是那种天马行空的胡编乱造，而是更像一个“过度自信的误读”——比如，看了一眼用户的订单历史，把某个字段的状态弄错了，然后底气十足地建议一个根本不存在的退款政策。问题在于，原始数据就在那里，就在LLM的“上下文窗口”里，但信息过载反而把事情搞砸了。作为美国最大的本地服务平台之一，DoorDash每天要处理数十万次来自顾客、商家和配送员的咨询。在这个量级下，自动化客服已经不是锦上添花，而是业务刚需。团队很清楚问题出在哪，但修复起来却像走钢丝：针对一个场景修好了幻觉，可能在另一个场景又造出新问题。他们当时面临着两个选择：要么直接部署到生产环境“赌一把”，这风险太大；要么花几周时间手动测试几十种对话场景，还未必能覆盖全。这个困境并非DoorDash独有，它是所有人从传统确定性软件转向LLM系统时必须面对的挑战。过去，基于决策树的客服系统，每一次改动的影响都是可预测、可追溯的。而LLM带来了灵活和自然对话，也带来了“非确定性”——同一个输入，可能每次输出都不一样。 DoorDash的解题思路，不是去打造一个“更好的聊天机器人”，而是构建一个让聊天机器人能“变得更好”的系统。他们称之为“模拟与评估飞轮”。

这个飞轮到底怎么转？

这个飞轮由两个相互咬合的部分构成： * 第一部分：离线模拟器。它能够生成逼真的多轮对话，而不需要任何真实用户参与。 * 第二部分：评估框架。它能够自动为聊天机器人在这些模拟对话中的表现打分。两者结合，就形成了一个高效的迭代闭环。

Source: DoorDash Engineering Blog

当团队发现问题时，他们首先会编写一个专门的“评估项”来捕捉这个特定的失败模式。然后，只需一个作业触发器，就能编排整个流水线：从历史对话记录中自动生成测试场景，让模拟器和聊天机器人进行多轮对话，最后自动评估结果。

Source: DoorDash Engineering Blog

接下来，他们修改提示词或系统架构，再次运行模拟器，看看“通过率”有没有上升。通过了，就继续优化；没通过，就换个思路。如此循环，直到通过率达到预设的退出标准，他们才有信心将改动部署上线。下面的图表展示了“无幻觉评估”的通过率随时间的变化：

Source: DoorDash Engineering Blog

这个闭环的速度是它的核心优势。DoorDash能在5分钟内模拟超过200次对话，并立即得到自动化的评估结果。过去需要几天的手动测试和评审，现在几小时就能搞定。而且，所有过程都是离线的，完全不影响真实用户体验。目前，他们的评估套件已经发展到涵盖超过50个评估项，包括幻觉检测、语气评估、问题分类等质量维度。任何改动在上线前，都必须通过这一整套评估，它既是质量把关，也是回归测试。听起来很简单？但无论是模拟器还是评估器，都需要解决真正棘手的问题。

模拟会“推搡”的顾客

一个静态的测试用例只能检查聊天机器人对单条消息的回应是否合理，但它无法捕捉到真实场景中的复杂性：一位沮丧的顾客连番追问三次，在对话中途提供了新的信息，或者威胁要升级投诉。 DoorDash的模拟器完全摒弃了脚本化消息。它本身就是一个LLM，扮演顾客角色，根据详细的测试场景动态生成回应。在每一轮对话中，模拟器会进行结构化分析，自问几个关键问题：问题解决了吗？对话有进展吗？顾客是否需要提供更多信息？是不是在兜圈子？基于这些分析，它来决定一个真实顾客下一步会说什么。这些测试场景也并非凭空想象，而是来自真实的历史客服记录。LLMs会分析过去的对话，从中提取结构化的行为画像，包括客户的个性特征（是愤怒苛刻，还是困惑耐心）、具体的场景描述，以及客户期望达成的目标。这让模拟器根植于真实的客户行为，而非理想化的测试案例。

Source: DoorDash Engineering Blog

这个模拟器还会表现出真实的“升级”模式。它不会一上来就要求找经理，而是会给聊天机器人多次机会来解决问题；只有在遭遇连续的无效应答或陷入死循环后，才会考虑升级；当对话重新出现转机时，它又会再次介入。这完全模拟了真实顾客的行为逻辑。为了让模拟对话有意义，聊天机器人还需要访问逼真的后端数据，比如查配送状态、退款资格、订单详情等。DoorDash通过一种混合模拟数据的方式来实现：将真实的线上数据与特定场景的测试数据结合，保留时间戳和关联性，让交互尽可能地真实可信。这使得他们能够测试过去无法处理的复杂边界情况，包括欺诈场景和高额退款请求。

让一个LLM来评判另一个LLM

生成了数百段逼真的对话，如果不能判断聊天机器人是否处理得当，那就毫无意义。但人工阅读每段对话，又违背了自动化的初衷。所以，DoorDash选择用另一个LLM来自动评估聊天机器人的表现。每个评估项都被设计成一个函数。它接收完整的对话记录，包括工具调用和后端响应，以及相关的公司政策，然后应用一个提示词，询问聊天机器人是否正确地遵循了该政策，最终返回一个“通过/失败”的二元结果，并附上推理过程。这里有一个很自然的疑问：如果LLM本身导致了幻觉问题，为什么还要相信另一个LLM来发现它？ DoorDash为此引入了一个核心概念——“生成器-验证器差距”。扮演一个完整的客服袋里，涉及到跨越海量场景的复杂多步决策，这非常困难。但验证一个单一的、明确定义的行为，则是一个简单得多的任务。比如，“聊天机器人是否声称顾客符合退款条件，而政策规定并非如此？”这是一个直截了当的二元问题。评估员不是在试图成为更好的客服，它只是一次只检查一件事。而LLMs在接受这种聚焦的、二元的判断任务时，远比进行开放式生成要可靠得多。当然，DoorDash不会盲目信任LLM裁判。他们通过一个结构化的流程来校准它：收集对话样本，让人类专家标出“通过/失败”；在同一批样本上运行LLM裁判；测量其与人类判断的一致性，分析分歧背后的原因；然后修改评估提示词来修正系统性错误。通过反复迭代，直到LLM裁判的结论稳定地与人类专家判断相符。这一步校准，是建立信任的关键。值得注意的是，评估项的二元性质非常关键。DoorDash不是让LLM在1到10分的尺度上对聊天机器人的表现进行主观评分，而是问它“聊天机器人是否遵循了某个特定政策”。这加快了校准速度，让分歧更容易诊断，也产生了更可靠的判断。

“喂”给聊天机器人更少的信息来修复幻觉

有了模拟器和评估器，DoorDash的飞轮开始运转。在早期的上线过程中，人工评审发现，聊天机器人被塞入上下文窗口的海量数据搞得不知所措。订单历史、配送状态、退款决定、工具调用结果，所有这些原始事件日志一股脑地喂给了模型。聊天机器人因此误判字段或建议不存在的政策——问题不在于信息错误，而在于信息太多。这与“给模型更多信息就应该得到更好结果”的直觉完全相反。 DoorDash的假设是：那些对推理至关重要的数据，在生成最终回复时却变成了噪声。他们的解决方案是一个名为“案例状态”的架构层。它不是把所有原始历史塞进上下文，而是将相关的工具调用历史提炼成一个结构化的、中间层的表示，整理成聊天机器人能真正理解的干净格式。这个“案例状态”的成型过程，恰恰体现了飞轮的价值。最初几次提取逻辑的效果并不理想，有的版本遗漏了关键信息，导致聊天机器人错过解决问题的核心细节；另一些版本则依然嘈杂、结构混乱，以不同的方式误导了模型。但由于模拟器能在几分钟内生成大量逼真的对话，团队能够在快速的反馈循环中尝试几十种不同的上下文结构和提示策略。每一次迭代只需几小时，而过去通过手动测试则需要数周。经过11次迭代，“无幻觉评估”的通过率稳步攀升。值得注意的是，第三次迭代出现了一次明显下滑，说明改进并非线性进行，有时候甚至会暂时变得更糟。这也恰恰是飞轮的另一个价值：在改动影响到真实用户之前，就能捕获到这种回退。最终，模拟环境中的幻觉减少了90%，并且这一改进成功迁移到了生产环境。离线指标与线上表现之间的强相关性，让团队确信这个飞轮是可靠的发展工具，而非一个与现实脱节的内部沙盒。

总结

DoorDash的“模拟与评估飞轮”从根本上改变了他们开发和部署聊天机器人改进的方式，将迭代周期从数天压缩到数小时，并让他们能够在影响任何真实用户之前，在数百个场景中验证改动。当然，这个方法也有其固有的局限性。最核心的限制是：飞轮只能捕捉到你已经编写了评估项的问题。如果一个失败模式没有被评估项覆盖，飞轮对它就是“视而不见”的。DoorDash通过在上线前运行完整的评估套件来缓解这个问题，但新的失败模式总会不断涌现。这也是为什么无论自动化程度有多高，人工审查依然是每一个改进周期的起点。模拟的逼真度是另一个固有局限。即使场景来自历史记录，并使用了混合模拟数据，合成对话终究是对真实用户行为的近似模拟。DoorDash报告了其离线指标与线上结果之间的强相关性，这验证了方法的有效性，但这种相关性并不能保证在所有场景或所有类型的系统变更中都成立。此外，成本也是一个不容忽视的问题。每个测试周期都要运行数百次LLM对LLM的对话，再加上每一次对话的LLM裁判评估，所需算力相当可观。对于较小的团队或非关键应用，一个更轻量级的版本——比如减少模拟场景、使用更聚焦的评估项——可能是更务实的起点。跳出这个案例本身，更广泛的启示在于：LLM系统需要一套与传统软件完全不同的测试范式。既然我们无法再像追踪分支逻辑那样追踪它的决策路径，就需要一个强大的反馈闭环，让我们能够在发布前通过足够快速的模拟、评估和迭代，来建立部署的信心。 **参考文献:** * A Simulation and Evaluation Flywheel to build LLM Chatbots at Scale * LLM as a Judge Pattern

DoorDash LLM测试系统构建指南

这个飞轮到底怎么转？

模拟会“推搡”的顾客

让一个LLM来评判另一个LLM

“喂”给聊天机器人更少的信息来修复幻觉

总结

相关阅读

最新教程

最新资讯