DiDi 联络中心 QA 以 Amazon Bedrock 取代黑箱

DiDi 在其意图检查准确率仅达到 38% 后，替换了一款不透明的质量保证工具。据称，新的 DiDi 联络中心 QA 系统将这一数字提升至 86%。

该公司与 AWS 为其国际业务集团构建了替代方案。该系统处理网约车、外卖和金融服务领域的西班牙语及葡萄牙语客服对话，同时评估合规性并发现新出现的客户投诉。

这不只是又一家企业为客户支持加入大语言模型。DiDi 将一项关键的内部控制能力从外部供应商转入了自家团队能够检查和修改的架构。因此，核心较量在于不透明的外包自动化与透明、自主掌控的 AI 之间。

AWS 和 DiDi 于 2026 年 9 月 8 日在一项 contact center QA 案例研究中披露了该系统。大多数性能数据来自 DiDi 的生产验证，尚未经过独立审计。

这些结果仍值得关注。它们表明，精准限定的上下文、确定性检查和结构化输出，可能比反复改写提示词更重要。

DiDi 联络中心 QA 内部发生了什么变化

DiDi 并非只是用一个模型替换另一个模型，而是将质量保证拆分为三条受控管道，每条管道承担不同职责，并具有不同的证据要求。

第一条管道用于验证意图。客服代表会为每段对话分配一个联系原因，从而将案例置于 DiDi 的分层分类树中。系统检查该分配的原因是否与客户实际讨论的内容相符。

如果标签看起来有误，管道会推荐替代选项。它还会检查被标记为“Other”的对话，即现有类别似乎均不适用的情况。这类案例可能暴露分类体系本身的缺口。

第二条管道评估合规性。它在从同一段对话中提取运营洞察的同时，对多项质量标准进行评分。DiDi 表示，在生产验证期间，其平均合规评分准确率超过 90%。

第三条管道分析客户之声数据。客户之声，或 VOC，指有关客户问题、情绪、结果和重复出现原因的汇总证据。当运营团队需要了解某种正在形成的模式时，DiDi 会按需使用这条管道。

在线聊天记录和电话转录文本首先进入预处理层。通话的语音转文字结果会被规范化为与聊天相同的对话格式。随后，生成的记录会进入相应的 QA 管道。

这一通用模式至关重要。语音与聊天之间的差异不应迫使每个下游分析组件各自实现接入逻辑。该系统将渠道处理与后续推理任务分离开来。

两家公司表示，DiDi 的国际业务覆盖 14 个国家和地区。其支持组织面向三条业务线的数千万用户，处理西班牙语和葡萄牙语对话。

在这一规模下，人工审核只能检查有限比例的互动。然而，外包方案也存在自身问题。DiDi 表示，其此前的系统没有提供足够的推理可见性，无法解释历史判断，也无法支持快速变更。

一次失败的合规评分可能影响辅导、审计和运营优先级。错误的意图标签可能扭曲有关客户为何寻求帮助的报告。因此，无法解释的判断对开发人员而言不只是麻烦。

替代系统会为每项模型判断附加一条推理链。审核人员可以查看评分的既定依据，检查原始对话，并将决策与适用规则进行比较。

这种可追溯性构成了文章的核心张力。将系统纳入 DiDi 内部提高了可见性和控制力，但也让 DiDi 必须负责验证、安全、配置和持续准确性。

DiDi 现在拥有塑造结果的定义权。当这些定义不完整或有误时，它也要承担相应后果。

为什么隔离上下文胜过更多提示词调优

据称，最大的准确率提升来自在恰当时刻向模型展示更少的信息，而不是加入更多指令。

DiDi 最初的意图验证设计遵循了一种直观方法。它将完整的联系原因树与对话并列展示，并要求模型判断客服代表选定的标签。

随后，模型会将所选标签与所有可用替代选项进行比较。当发现某个类别似乎稍微更精确时，它往往会否定原本合理的选择。

这种行为造成了过度纠正。被要求寻找最佳标签的模型，与被要求判断现有标签是否可接受的模型，其行为可能不同。在同一个提示词中合并这些决策，模糊了两者之间的区别。

DiDi 表示，多轮提示词调优未能解决这一问题。团队得出结论：模型被置于错误的决策环境中。

重新设计后的意图管道将验证与分类分开。在验证阶段，模型只接收对话内容和客服代表当前的联系原因。它判断该标签是否合理地符合这次互动。

完整分类树在这一阶段保持隐藏。这种信息隔离可防止模型在回答更狭窄的问题前，先搜索略微更优的替代选项。

只有验证失败才会开启分类阶段。随后，模型会接收完整分类体系以及第一阶段的推理结果。它推荐另一个类别，并提供置信度评分和理由。

DiDi 通过独立的三级流程处理“Other”标签。系统首先在同级类别中搜索合适匹配项；如果本地分支没有答案，则搜索整棵分类树。

如果两次搜索都未产生合适类别，管道会识别出潜在的分类体系缺口。之后，它可以建议运营人员新增标签，而不是强行将对话归入不合适的现有类别。

据 DiDi 称，这种两级设计将意图验证准确率从 38% 提升至 86%。根据该公司所述的生产验证，这增加了 48 个百分点。

这一机制为企业 AI 团队提供了实用启示。更多上下文并不自动意味着更好的上下文。额外选项可能改变模型看似正在解决的任务。

这很重要，因为许多企业提示词为提高效率而合并了多项决策。单个请求可能要求模型对一段对话分类、说明结果理由、检查政策合规性、总结案例并推荐行动。

每增加一个目标，指令与证据相互干扰的机会就更多。它也让失败分析变得更困难，因为开发人员无法轻易识别是哪部分上下文改变了答案。

DiDi 的方法则将上下文视为应用架构的一部分。团队决定每个决策点可见哪些信息，如同传统软件控制对变量和状态的访问一样。

这种设计还产生了更清晰的失败边界。可疑的验证结果属于第一阶段，糟糕的替换标签属于第二阶段，缺失的类别则属于分类体系治理。

这并非普遍宣称多阶段系统总是优于单一提示词。每增加一个阶段，都会带来延迟、运营复杂性和另一个需要监控的组件。

DiDi 尚未公布样本量、类别分布、置信区间，以及按语言和业务线划分的性能数据。这些缺失限制了与其他联络中心 QA 系统的比较。

不过，报告中的变化挑战了一种常见的企业习惯。面对令人失望的模型行为，团队往往会扩充指令或更换基础模型。DiDi 则改变了信息流。

这是一种更深层次的提示词工程。它将责任从巧妙措辞转移到系统设计、数据定义和明确的决策边界中。

自主掌控的系统让外包 AI 承受压力

DiDi 对第三方 QA 供应商最有力的挑战并非模型准确率的主张，而是判断逻辑已成为战略基础设施这一论点。

外包平台可以减少实施工作。它可以将转录、评估、仪表板和工作流打包为一款托管产品。买方无需自行维护每一个组件。

然而，当供应商不公开其如何得出判断时，这种便利就会成为约束。DiDi 表示，其先前的解决方案在做出 QA 决策时没有提供足够的审计线索。

随着标准不断变化，这一限制变得更加严重。网约车业务的西班牙语支持不一定使用与金融服务葡萄牙语支持相同的标准。新政策还会带来更多组合。

供应商控制的实施方案可能需要定制变更、再训练或产品更新，之后这些标准才能进入生产环境。在此期间，新旧规则可能并存。

DiDi 将政策定义移入外部配置。评估管道使用一个提示词模板，随后为每张工单注入语言、业务线、标准定义、通过规则和失败规则。

新增一项标准无需重写每个特定语言的提示词。运营人员更新配置后，应用程序会在接收对话时组装所需上下文。

该管道在一次模型调用中评估多项合规项目。它还会返回结构化业务洞察，包括与问题解决和客户满意度相关的衡量指标。

Amazon Bedrock Tool Use 将响应约束为预定义的 JSON 结构。每个评分项目都包含判断及其相应理由。相关的 tool-use capability 使应用程序能够描述预期的工具输入，并处理生成的结构化数据。

结构化输出只能解决响应格式问题。有效的 JSON 并不能保证底层评分正确。因此，DiDi 在生成后加入确定性检查。

例如，模型可以识别可能的拼写错误。应用程序代码随后只统计客服代表消息中的错误，并将既定阈值应用于经过验证的数量。

系统还会在代码中计算响应等待时间。它将这些数值注入提示词，而不是要求模型从时间戳中推断。

这种混合模式将语义判断交给语言模型，将可计算事实交给传统软件。它避免在直接计算能够提供可复现答案的场景中使用概率生成。

这种区分是自主掌控方法的核心。DiDi 可以检查哪些决策属于模型，哪些属于代码，以及哪些依赖业务配置。

该架构还使用 Amazon Bedrock，因为该服务通过通用接口提供多种基础模型。DiDi 表示，无需围绕另一种供应商特定集成重建每条管道，即可更换模型选择。

模型可移植性仍有局限。不同模型对提示词和模式的理解不同，因此更换模型需要重新评估。统一的 API 能减少部分集成工作，但并不能让行为实现可互换。

安全性带来了另一个压力点。客户对话可能包含姓名、联系方式、财务信息、位置数据和敏感投诉。将这些记录纳入 AI 工作流，扩大了需要治理的系统范围。

DiDi 表示，该部署通过 AWS PrivateLink 使用 VPC 终端节点，并采用加密和细粒度的身份与访问管理控制。AWS 文档指出，私有连接无需互联网网关或公网 IP 地址即可访问 Bedrock。

该系统还会在模型推理前应用 Amazon Bedrock Guardrails。它会掩盖个人可识别信息，并使用上下文依据检查来标记缺乏充分支持的回答。

AWS 将 Guardrails 描述为一类策略，用于评估提示词和回答中涉及敏感信息、禁止主题和不需要内容等领域。其护栏控制可根据配置的策略阻止或掩盖内容。

这些措施并不能消除治理工作。DiDi 仍必须为客户数据制定访问、保留、升级处理、审查和区域化处理规则。

同样的负担也适用于业务逻辑。拥有透明系统意味着需要维护其分类体系、评估标准、验证集和监控流程。该公司以内部问责取代了供应商的不透明性。

因此，第三方供应商正面临双重压力。他们既要匹配托管产品的便利性，又要提供足够的证据、可配置性和控制能力，让企业客户能够信任具有重要影响的判断。

应对方式不必是完整披露代码。供应商可以提供决策轨迹、版本化规则、评估工具、可导出的结果，以及模型输出与确定性检查之间更清晰的区分。

DiDi 的案例表明，简单的准确率仪表盘已经不再足够。买方日益需要知道，每项评分由哪个模型、哪个提示词版本、哪项策略定义和哪条后处理规则生成。

这一要求使可观测性成为产品功能。对于具备足够工程能力和高度专业化运营需求的公司而言，它也让内部自主管理更具吸引力。

准确率数字未能呈现的内容

报告中的提升具有意义，但公开证据无法证明该系统在所有市场、语言、类别或不断变化的政策下的表现。

38% 和 86% 的意图识别数字来自 DiDi 的生产验证。AWS 的文章未披露测试了多少段对话，也没有说明评估人员如何定义正确结果。

它也没有提供西班牙语与葡萄牙语的准确率对比。系统表现可能因口音、地区词汇、支持渠道、业务线和分类深度而有所不同。

类别平衡同样重要。若数据集主要由常见网约车问题构成，整体得分可能很高，却掩盖了较少见金融服务案例中的薄弱表现。

对超过 90% 的合规评分也应保持同样谨慎。公开材料没有说明纳入了多少项标准、各项标准是否权重相同，或人工如何解决分歧。

准确率还可能掩盖不同的错误成本。误判拼写违规虽然不便，但涉及受监管金融服务行为的错误评估可能带来更严重的后果。

因此，生产环境评估应追踪每项标准的精确率和召回率，而不只是一个平均值。它还应监控人工审核人员与自动化系统之间的分歧。

推理轨迹能帮助审核人员调查决策，但并非证据。语言模型可以为错误答案生成看似合理的解释。

确定性验证层可降低可衡量事实方面的这种风险，但无法将每项政策判断都转化为计算。语气、解决质量、同理心和情境适宜性仍需解释。

Guardrails 也带来另一项限制。它们可以过滤敏感信息并测试依据是否充分，但 AWS 自身建议，随着底层防护机制变化，仍应持续验证。配置好的控制措施不应被视为永久保证。

人工监督依然必要，尤其是在存在争议的评分和风险较高的标准上。审核团队需要一条申诉路径，既能纠正个别决策，也能修正底层规则。

公开介绍还缺少运营层面的指标。它没有报告模型延迟、处理成本、人工覆盖率、审核人员工作量，或需要升级处理的对话比例。

这些数据将揭示模型准确率提升是否真正转化为更好的运营效果。即使系统准确，如果响应过慢、需要频繁人工纠正，或在满负荷下成本过高，仍可能难以发挥作用。

与其他实施案例的比较提供了有益视角。金融服务提供商 Empower 此前介绍过另一套基于 Bedrock 的 QA 部署，每天处理数千份对话转录文本。

其自动化 QA 系统结合了 Amazon Connect Contact Lens 与 Bedrock。Empower 表示，该系统将 QA 覆盖范围扩大了二十倍，并将审核时间从数天缩短至数分钟。

这些实施方案无法直接比较。Empower 使用来自 AWS 联络中心技术栈的预先脱敏转录文本，而 DiDi 描述的是其自有预处理和三条管线架构。

不过，这两个案例都指向同一竞争方向：企业希望审核更多对话、解释评估结果，并缩短从客户问题到运营行动之间的间隔。

DiDi 的独特贡献在于它说明了一种失败设计。尽管反复调整提示词，将整个分类体系输入一次调用仍导致意图验证表现不佳。

这一失败使该案例比简单的供应商成功故事更有价值。它表明，仅有模型访问能力并不能带来可靠的质量保证。

剩余的不确定性在于维护。分类体系会变化，客户行为会转移，政策措辞也会演进。模型供应商同样会更新可用版本和配套功能。

DiDi 需要建立版本化评估集，保留各语言、渠道、业务线和高风险标准中的代表性示例。否则，某一领域的配置改进可能悄然降低其他领域的表现。

构建类似系统的团队应保留每次发布背后的证据。可搜索的工程知识库可以连接需求、测试结果、提示词版本和事故复盘，而不将生成的解释视为事实依据。

这种做法支撑了透明性的真正承诺。只有当团队能够重建发生了什么变化、为何变化以及新版本表现如何时，可见性才有价值。

下一个考验：DiDi 能否规模化管控能力

三个信号将决定 DiDi 的架构是成为持久的 QA 运营系统，还是仅作为一项公开验证有限的成功部署。

第一个信号是其在更多语言和业务线中的表现。DiDi 表示，计划将系统扩展到当前覆盖范围之外。

这一扩展将检验动态配置是否确实能够限制维护工作量。新增一种语言带来的不只是翻译后的指令，还可能引入地区表达、文化预期、转录错误和不同的政策要求。

如果准确率在新部署中保持稳定，结果将强化 DiDi 的上下文管理论点。若出现大幅下降，则表明当前收益高度依赖现有的西班牙语和葡萄牙语验证环境。

第二个信号是跨管线集成。DiDi 计划更深入地连接意图验证、合规评分和 VOC 分析。

目前，每条管线都有不同目的。集成可以形成反馈循环：投诉趋势揭示缺失分类，重复出现的分类失败推动分类体系更新，合规发现则塑造辅导工作。

但它也可能传播错误。错误的问题聚类可能影响分类体系变更，继而影响意图检查和管理报告。

因此，成功集成需要溯源能力。每项下游建议都应保留指向产生它的对话、提取字段、配置版本和模型输出的链接。

第三个信号是准确率之外的运营证据。未来披露应包括人工覆盖率、误报模式、处理延迟、审核时间和按类别划分的表现。

这些指标将显示该系统在初始验证期后是否仍然有用。它们也将帮助买方比较自主管理的架构与托管联络中心产品。

VOC 分析提供了最清晰的即时检验。DiDi 描述称，拉丁美洲市场取消费投诉激增。运营人员触发了一次分析，在数分钟内便对多语言对话进行了聚类，并生成结构化报告。

该管线首先并行从每段对话中提取字段。这些字段包括问题类型、情绪、结果和可能的根本原因。

随后，嵌入模型衡量问题标签之间的语义相似度。嵌入是将相关含义置于彼此相近位置的数值表示，使系统能够合并措辞不同的投诉。

这一阶段使用距离计算和频率排名，而非生成式输出。DiDi 表示，这一设计使聚类具有确定性和可复现性。

在生成报告时，语言模型只接收高频聚类。它基于更小、结构化的证据集生成管理层摘要、识别痛点并提出行动建议。

该管线再次采用了信息隔离。模型不会在一个过大的提示词中接收数千段原始对话；每个阶段都会缩小下一项决策所需的证据范围。

DiDi 表示，这一流程将原本需要数小时的工作缩短至数分钟。如果未来报告能显示运营团队是否更快采取行动，或是否减少了重复发生的客户伤害，这一说法将更具说服力。

速度本身并非目标。一份根本原因错误的快速报告，可能会将资源引向错误的干预措施。

最强的部署将更快检测与可衡量的结果结合起来。这些结果可能包括更少的重复联系、更好的问题解决效果、更低的投诉复发率，或更快纠正政策问题。

对开发者而言，直接的教训是在打磨提示词之前先设计模型边界。确定每次调用需要哪些证据、哪些输出需要模式，以及哪些事实应通过代码计算。

企业买方也应向供应商要求同样的清晰度。要求提供版本化规则、可审计决策、按类别验证、升级处理工作流，以及与对话数据敏感性相匹配的访问控制。

知识工作者也应关注，因为这种模式并不限于支持场景。任何对文档进行分类、评估工作或汇总重复问题的系统，在面对无关选项或混合不兼容任务时都可能出现问题。

因此，DiDi 客服中心 QA 不仅是对模型性能的考验，更是对组织能力的检验。该公司选择自行掌握上下文、定义与验证流程，而非将整个判断层完全外包。

随着语言、政策和模型不断变化，这种自主掌控能否带来稳定结果？不妨关注其扩展指标、跨流程证据链以及人工覆盖率。这些信号将表明，透明的企业 AI 能否长期胜过黑箱系统。