滴滴国际业务集团与AWS合作，用Amazon Bedrock替换了不透明的第三方客服质检方案，覆盖西班牙语和葡萄牙语、出行/外卖/金融三条业务线。生产验证中，意图识别准确率从38%升至86%，合规评分准确率超过90%，人工摘要从数小时缩至数分钟。
AI解读：滴滴国际业务集团每天处理大量西班牙语和葡萄牙语的客服会话，质检结论直接决定合规审计结果和服务改进优先级。原来的第三方方案是个黑盒：系统打分不显示推理过程，规则变了没法快速迭代，业务方想追溯一次扣分的原因都做不到。这次换到Amazon Bedrock自建系统，核心不是换模型，而是把"模型每次调用能看到哪些信息"这件事管住了。意图校验被拆成两步——先只让模型看当前标签判断对错，判错才进入分类环节；合规评分不按语言×业务线维护几十套提示词，而是统一模板、外部配置动态注入；趋势分析则分三阶段处理，先逐条抽取再聚类再生成报告。生产数据是：意图识别准确率38%提到86%，合规评分超过90%，趋势归纳从几小时压到几分钟。对负责客服质检的团队，这套方案的直接价值是可追溯——每个分数都带推理链，人工复核和申诉有了依据。值得注意的限制是：三项指标都来自滴滴自己的生产验证，不是独立评测；准确率数字也没说明测试集规模和抽样方式。对普通用户和一线客服代表，短期内没有需要采取的行动。对管理者，真正的启示在于：买第三方黑盒方案省了搭建成本，但规则是动态的、审计是刚需的场景，自建的可控性反而决定系统能不能用起来。不过"自建更优"这个结论要限定在滴滴这种多语言、多业务线、规则频繁变化的场景，不能推广到所有客服质检需求。
滴滴国际业务集团（DiDi IBG）与AWS合作，在Amazon Bedrock上构建了一个自有的智能客服质检（QA）系统，替代原先不透明的第三方方案。该系统覆盖西班牙语和葡萄牙语，应用于出行、外卖、金融三条业务线。据AWS机器学习博客发布的技术文章，在滴滴的生产验证中，意图识别（intent verification）准确率从38%提升到86%，合规评分准确率超过90%，语音客户（VOC）趋势分析将原本数小时的人工阅读和摘要工作压缩到几分钟。
滴滴国际业务集团是滴滴全球的海外分支，业务覆盖14个国家和地区，运营出行、外卖和金融服务三条业务线，服务数千万用户。其客服（CX）部门每月通过在线聊天和电话渠道处理大量西班牙语和葡萄牙语工单。
原第三方方案的四项核心缺陷
滴滴IBG客服团队称，原有第三方质检方案存在四个核心问题。其一，质检判断缺乏可追溯性：质检判断直接决定合规审计结果和服务改进优先级，但旧系统被描述为不透明的封闭系统，不显示推理过程，而人工抽检又受吞吐量和成本限制，两种方式都无法提供过往决策的审计轨迹。其二，服务场景组合复杂：客服运营横跨多种语言和业务线，每种组合有各自的合规标准和质检规则，随着组合增多，规则维护成本上升、一致性难以保证。其三，质检标准变更响应慢：业务发展时QA标准频繁变化，每次变更都要重新培训质检分析师或更新执行指南，新旧标准并存期间容易出现不一致的结果。其四，缺乏主动趋势检测：当某个问题类型在短时间内激增，运营团队只能逐条阅读工单再手工统计，难以提前识别趋势并及时干预。
选Amazon Bedrock的三个理由
滴滴IBG客服团队与AWS合作，选择Amazon Bedrock有三个方面原因。第一，它通过单一API提供模型无关的访问，可以访问多种基础模型，团队能为每个流水线选择最合适的模型而无需重新架构。第二，其内置治理和安全控制可将敏感的客服数据保留在滴滴的网络边界内——控制措施包括通过AWS PrivateLink支持的Amazon VPC端点进行私有连接、传输和静态加密，以及通过AWS IAM进行细粒度访问控制。第三，Amazon Bedrock Guardrails提供可配置的安全防护，如内容过滤和敏感信息脱敏。
三条核心流水线：意图验证、合规评估与VOC分析
该系统在Amazon Bedrock上实现三条专门流水线，每条针对不同的质检维度，并为每次判断输出完整的推理链。预处理层接收在线聊天和电话数据（电话经语音转文字），经过各渠道特定的预处理后统一为通用会话格式，再分发到三条并行流水线。
意图流水线：先验证代表填写的联系原因（CR, Sub-CR）是否正确，错误时推荐替代分类；同时对标记为"其他"的工单进行独立的三级分析（先看同类标签中是否有更合适的，再搜索整个CR树，若无匹配则表明分类体系存在覆盖缺口，建议新增标签）。设计上把验证和分类分离：验证阶段模型只收到当前的联系原因标签，仅依据对话内容判断该标签是否合理；只有判定失败，才进入分类阶段，此时模型才收到完整的CR树及验证阶段的推理，并输出带置信度和理由的替代分类。文章称，这种"信息隔离"设计是为了解决"当LLM看到完整选项列表时会自动逐一比较，即使原标签完全合理，也会因找到更精确的选项而误判"的问题，且多轮提示词调优无法改变这一行为。
评估流水线：在一次LLM调用中同时执行多项合规评分和业务洞察（BI）分析。采用统一提示词模板加动态变量注入——语言上下文、业务上下文、每条标准的定义和判定规则存为外部配置，调用时根据工单元数据组装完整提示词。新增评估项、语言或业务线只需更新配置，无需改代码。输出通过Amazon Bedrock的Tool Use功能强制模型返回符合schema的JSON，每条评分都附推理链。对于规则确定性的指标（如代理响应等待时间、拼写错误），系统不依赖模型推理，而是在代码中确定性计算后注入提示词，或用程序化后验证层复核模型判断。
VOC流水线：按需触发，对特定时间窗口内的大批量相似工单进行聚合分析。采用三阶段流程——并行抽取（每通会话独立调用LLM提取问题类型、用户情绪、解决结果、根因等结构化字段）、问题聚类（用embedding模型计算语义相似度合并同义表述，如"未支付取消费"和"取消费未付"，按工单频率排序）、报告生成（LLM基于高频聚类生成包含执行摘要、痛点分析和可操作改进建议的分析报告）。文章举例：当拉美多个市场的取消费投诉短期内激增时，运营团队触发VOC分析，系统在数分钟内从多语言会话中识别出主要根因和高频触发场景，并生成带建议的结构化报告。
关于责任AI控制：文章称系统使用Amazon Bedrock Guardrails在模型之前屏蔽PII等敏感信息，并应用上下文接地检查（contextual grounding checks）标记无根据的响应，以减少幻觉判断。此外，系统不把模型输出当作最终结论：对规则确定性标准，用程序化后验证层对照原始会话复核模型判断；每个分数都附完整推理链供人工审查。
结论与归因
滴滴国际业务集团数据分析团队Raphael Hua在总结中表示："在国际运营中，多语言和多业务的客服质检是一个规模化挑战——现有方案不仅不透明，而且随着业务标准变化难以快速迭代。用Amazon Bedrock重建这个系统后，我们实现了质检判断的完全透明：意图验证准确率从38%提升到86%，合规评分准确率超过90%，大批量工单的趋势分析从数小时压缩到数分钟。这个项目教会我们一个根本道理：构建可靠的LLM应用，关键不在于工具本身，而在于团队对上下文管理和数据定义的深入掌握。这种能力无法外包——这也是这次合作最有价值的成果。"
本文信息主要来自AWS机器学习博客的技术文章《How DiDi built intelligent contact center QA with Amazon Bedrock》，作者为AWS的Fei Huang和滴滴的Raphael Hua，属于AWS提供的客户成功案例。文中提及的准确率等指标均来自滴滴的生产验证，文章未说明测试集规模与抽样方法。