滴滴国际化客服质检智能化之路：基于 Amazon Bedrock 的多语种多业务线质检实践

摘要：滴滴国际化事业部客户体验部门与 AWS 合作，基于 Amazon Bedrock 构建了一套覆盖西班牙语和葡萄牙语、横跨出行、外卖、金融三大业务线的智能客服质检系统，将客服质检能力从依赖第三方的黑盒方案迁移为透明可控的自研 AI 架构。系统包含三条核心管线——意图验证、合规评估和 VOC 聚合分析：进线原因验证准确率从 38% 大幅提升至 86%，合规评分准确率达 90% 以上，VOC 聚合分析则将原本耗费数小时的人工汇总工作缩短至数分钟完成。

01 一、关于滴滴国际化事业部

02 二、业务挑战

03 三、方案总览

04 四、总结

一、关于滴滴国际化事业部

滴滴国际化事业部是滴滴出行的海外业务板块，业务覆盖全球 14 个国家和地区，运营出行、外卖、金融三大业务线，服务数千万用户。客户体验部门每月处理大量西班牙语和葡萄牙语工单，覆盖在线聊天和电话两种服务渠道，服务质量直接影响用户体验与品牌信任度。

随着业务规模持续扩大和质检标准的频繁迭代，原有的第三方质检方案在透明度和灵活性方面已难以满足需求。为此，滴滴国际化事业部与 AWS 展开深度合作，基于 Amazon Bedrock 构建了自研的客户体验智能质检系统。本文将详细介绍这套系统的三条核心管线——意图验证、合规评估和 VOC 聚合分析，并分享构建过程中的关键设计决策与实践经验。

二、业务挑战

滴滴国际化事业部客户体验团队在质检工作中面临以下核心挑战：

质检结论缺乏可追溯性：质检判定直接影响服务改进方向与合规审计结果，但在既有方案中，AI 质检是一个“黑盒“过程，判定逻辑不透明；人工抽检则受限于效率和成本，覆盖率有限。无论 AI 还是人工，其判定结论均难以实现标准化的追溯与复核。
场景组合复杂度高：客服业务覆盖多语种、多业务线，每种语言与业务的组合各有独立的合规标准和质检规则。随着组合数量增长，规则维护成本迅速攀升，一致性保障难度加大。
质检标准变更响应滞后：质检标准随业务发展频繁调整，每次变更都需要重新培训质检员或更新执行规范。过渡期内新旧标准并行，质检结果容易出现波动和不一致。
缺乏主动的趋势发现能力：当某类问题在短时间内集中涌入时，运营团队只能逐条阅读、手动汇总，难以在早期快速识别趋势并及时采取干预措施。

三、方案总览

为应对上述挑战，系统基于 Amazon Bedrock 构建了三条专用管线，分别聚焦质检的不同维度，每项判定均输出完整的推理过程，彻底告别黑盒。意图管线聚焦单条工单的用户进线原因分类准确性，评估管线审查服务合规性并挖掘业务洞察，VOC 管线则对大量同类工单进行聚合分析，识别系统性趋势。

[图 1：系统整体架构——双渠道数据经预处理后分流至三条管线，由 Amazon Bedrock 驱动输出结构化结果]

数据预处理层接入在线聊天和电话双渠道数据，经标准化处理后分流到三条并行处理管线。整体工作流程如下：

1. 数据接入与预处理：在线聊天和电话两种渠道经各自的预处理脚本，输出统一的标准化对话格式，供后续管线处理。

2. 意图管线（Intent）：验证客服标注的进线原因（CR / Sub CR）是否准确，错误时推荐替代分类；对标注为 “其他”（无法归入现有分类）的工单进行独立分析，识别分类体系的覆盖缺口。

3. 评估管线（Evaluation）：逐条工单进行多项合规（QA）评分 + 业务洞察（BI）分析，在一次 LLM 调用中同时完成。

4. VOC 管线：由运营团队按需触发，针对特定时间窗口内的批量同类工单进行聚合分析，产出结构化管理报告。

5. 结果输出：输出各管线的结构化结果，供运营团队查询和可视化。

3.1 意图管线：验证与分类分离架构

每条工单由客服在处理过程中标注进线原因标签。滴滴的进线原因分类体系（CR Tree）从大类逐级细分到子类，层级多、路径广。层级越深，类别间的区分越细微，人工误标在所难免。系统需要自动验证这些标注是否准确，错误时推荐替代分类；同时反向审计 CR Tree 本身——识别覆盖缺口，建议新增标签，形成从质检到体系优化的闭环。

最直接的做法是将完整的 CR Tree 和对话内容一次性交给 LLM，同时完成标注验证和”其他”标签审计。但这一方案准确率远低于预期。根因在于：LLM 看到完整选项列表后，会自动逐一比较——即使原始标注完全合理，只要找到一个”看起来更精确”的替代选项，就判定当前标注错误。多轮 Prompt 调整均无法改变这一行为，问题出在调用架构而非 Prompt 措辞。

团队从两个层面重新设计了管线。

任务隔离：进线原因验证和”其他”标签分析是性质不同的任务，将两者拆分为独立路径。”其他”标签走专门的三级分析：先检查同层级下有没有更合适的标签；如果没有，再搜索整棵 CR Tree；如果仍然没有匹配，说明 CR Tree 存在覆盖缺口，系统会建议新增标签。
信息隔离：对于常规进线原因，流程进一步拆分为验证和分类两个阶段。验证阶段只给 LLM 当前标注的进线原因标签，LLM 基于对话内容判断当前标注是否合理。仅当验证判定未通过时，才进入分类阶段：此时给 LLM 完整的 CR Tree，连同验证阶段的推理过程，让它推荐替代分类并输出置信度和理由。

通过这一双层设计，进线原因验证准确率从 38% 提升至 86%。

3.2 评估管线：动态组装覆盖多语种多业务线

评估管线对每条工单同时完成多项合规评分和业务洞察分析。面对语种×业务线的组合复杂度和频繁变更的质检标准，逐一维护独立 Prompt 的方式难以为继。

为此，评估管线采用统一 Prompt 模板 + 动态变量注入的设计：语种、业务线、每项评估标准的定义和判定规则均作为外部配置，在每次调用时根据当前工单动态组装为完整 Prompt。新增评估项只需更新配置文件，新增语种或业务线只需添加对应的上下文块——一套模板覆盖所有组合，在一次 LLM 调用中完成全部评估项。

[图 2：评估管线——外部配置动态组装为统一 Prompt，经 Amazon Bedrock 输出结构化的合规评分与业务洞察]

输出通过 Amazon Bedrock 的 Tool Use 能力约束为结构化 JSON，每项评分包含判定结果和推理过程。对于规则性强的指标，系统在 LLM 返回后进行程序化校验，用确定性逻辑校准语义判断。

在生产数据验证中，合规评分平均准确率达 90% 以上。管线同时输出多项业务洞察（BI），涵盖问题解决率、用户满意度等维度，为运营团队提供超越”合规/不合规”的多维视角。同时，推理过程的透明化使质检从单向的合规考核转变为双向的服务改进机制，使客服人员能够基于具体的判定依据改进服务。

3.3 VOC 管线：主动趋势发现

VOC 管线由运营团队按需触发，针对特定时间窗口内的大量进线进行批量聚合分析，识别高频问题，支撑系统性改进决策。挑战在于如何从大量对话中高效提取结构化洞察——最直接的做法是将所有对话一次性交给 LLM 生成报告，但这种方式产出的分类过于粗放，关键细节容易被淹没。

VOC 管线采用三阶段 pipeline：并行提取 → 问题聚类 → 报告生成，每个阶段精确控制 LLM 看到的信息范围。

并行提取：每条对话独立调用 LLM，提取问题类型、用户情绪、解决结果、根因等结构化字段。各工单间天然可并行。

问题聚类：使用 embedding 模型对提取出的问题类型标签进行语义聚类，合并同义表述（如 “unpaid cancellation fee” 与 “cancellation fee not paid”），再按工单频次排序，定位影响面最大的问题。此阶段依赖 embedding 相似度与统计排序，确保结果的一致性。

报告生成：LLM 根据高频聚类的结构化信息生成管理报告，涵盖执行摘要、痛点分析和可执行的改进建议。

以取消费投诉为例：当拉美市场短时间内集中出现大量同类投诉时，运营团队触发 VOC 分析。系统从多语种对话中自动识别出投诉的主要根因和高频触发场景，并生成包含根因分析和可执行改进建议的结构化报告。运营团队无需逐条阅读大量多语种对话，就能在几分钟内获得结构化的问题全貌和行动建议。

四、总结

在国际化业务中，多语种、多业务线的客服质检是一个规模化难题——原有方案不仅是黑盒，还难以随业务标准的变化快速迭代。借助 Amazon Bedrock 重新构建这套系统后，我们实现了质检判定的完全透明化：进线原因验证准确率从38% 提升至 86%，合规评分准确率超过 90%，大量工单的趋势分析从数小时压缩至数分钟。这个项目让我们真正理解了一件事：构建可靠的 LLM应用，关键不在工具本身，而在于团队对调用架构和数据定义的深度掌握——这是靠外包无法获得的能力，也是这次合作带给我们最有价值的东西。

—— Raphael Hua，数据分析团队，滴滴国际化事业部

滴滴基于 Amazon Bedrock 构建的智能质检系统，通过意图验证、合规评估和 VOC 聚合三条管线，实现了从第三方黑盒到透明可控的转变：

进线原因验证准确率从 38% 提升至 86%：通过验证与分类分离架构，消除 LLM 的”过度纠错”倾向，大幅提升意图判定的可靠性。
合规评分准确率达 90% 以上：动态组装 Prompt 覆盖多语种×多业务线的全部组合，同时输出推理过程，使质检判定可追溯、可改进。
VOC 聚合分析将数小时的人工汇总缩短至数分钟：三阶段 pipeline 从大量多语种对话中自动提取结构化洞察，支撑运营团队快速识别系统性趋势。

构建过程中的核心经验是：LLM 应用的性能瓶颈往往不在 Prompt 本身，而在调用架构——精确控制每次调用中模型可见的信息范围，比反复优化 Prompt 措辞更为关键。这一原则贯穿意图管线的信息隔离、评估管线的动态组装和 VOC 管线的分阶段提取，是三条管线共同的设计基石。

展望未来，滴滴计划将系统扩展至更多业务线和语种，并探索管线间的数据联动和更深层次的智能化分析，进一步拓宽质检系统的能力边界。

如果您对构建类似的智能质检系统感兴趣，欢迎了解 Amazon Bedrock 或联系 AWS GenAI Innovation Center。

➡️ 下一步行动：

相关产品：

Amazon Bedrock — 用于构建生成式人工智能应用程序和代理的端到端平台

相关文章：

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

亚马逊云科技中国峰会

开发者挑战赛现场开启，基于真实业务场景亲手构建 Agent。

亚马逊AWS官方博客