摘要
滴滴国际化事业群客户体验部门构建了一套覆盖西班牙语和葡萄牙语、横跨出行、外卖、金融三大业务线的智能客服质检系统。系统通过三条并行管线——意图验证、合规评估、VOC 趋势分析——将质检从依赖第三方黑盒方案升级为透明、可追溯、可自主迭代的自研 AI 架构。其中意图管线在调用架构重构与标签定义优化的双重驱动下，准确率从初期的不足四成提升至 86%；合规评估管线平均准确率达 90% 以上；VOC 管线将原本数小时的人工汇总工作缩短至数分钟完成。
本文记录这套系统的设计思路、工程判断，以及我们在 LLM 企业落地过程中沉淀下来的几点认知。
- 关于滴滴国际化事业群
滴滴国际化事业群（IBG）业务覆盖全球十余个国家和地区，运营出行、外卖、金融三大业务线，服务数千万用户。客户体验部门每月处理大量的西班牙语和葡萄牙语工单，渠道覆盖在线聊天和电话两种形式。
- 业务挑战
随着国际业务规模持续扩大，原有质检方案在四个维度上逐渐力不从心：
1. 质检结论缺乏可追溯性
传统 AI 质检方案只提供"黑盒"结果，判定逻辑不透明，人工抽检的覆盖率又受成本制约。一旦出现争议，既无法复现判断依据，也难以做标准化复核。
2. 场景组合复杂度高
多语种 × 多业务线的组合各有独立的合规标准和质检规则。随着组合数量增长，规则维护成本迅速攀升，人工维护已难以为继。
3. 质检标准变更响应滞后
业务侧质检标准频繁调整，每次变更都需重新培训，新旧标准并行期容易出现波动和不一致。
4. 缺乏主动的趋势发现能力
运营团队只能逐条阅读工单，手动汇总。在问题规模化之前，往往难以在早期发现系统性趋势并及时干预。
- 方案总览
针对上述挑战，我们设计了三条专用管线，每条管线聚焦质检的不同维度，每项判定均输出完整的推理过程，彻底告别黑盒：
-
意图管线： 验证客服代表（CSR）标注的进线原因（Contact Reason）是否准确，错误时推荐替代分类。
-
评估管线： 对每条工单进行多项合规（QA）评分与业务洞察（BI）分析。
-
VOC 管线： 针对特定时间窗口内的批量工单进行聚合分析，产出结构化管理报告。
双渠道数据（在线聊天 + 电话）经预处理后流入三条管线，输出结构化结果供运营团队查询和可视化。
- 意图管线：从不足四成到 86% 的架构演进
这条管线最初的结果让我们措手不及，也让我们对"LLM 应用如何调优"产生了更深的认识。
Contact Reason 体系
CSR 在处理每条工单时，需要从 CR 分类体系中选择对应的进线原因（Contact Reason），用于后续质检分析和运营优化。这套体系横跨多条业务线与多种用户类型，分类采用多级层级结构，条目数量可观，复杂度较高。
意图管线的任务，是自动验证 CSR 手动标注的 CR 是否准确，并在标注有误时推荐正确分类。
第一版：直接分类（失败）
最直接的做法：把 CR 体系全量交给 LLM，让它对照对话内容，直接输出最匹配的 CR 标签。结果不理想，准确率长期徘徊在低位。
我们反复调整 Prompt 措辞，都没有显著改善。直到深入分析错误案例才意识到，问题的根源不在 Prompt 怎么写，而在调用架构本身——在这类任务里，模型能"看到什么"，比被告知"该怎么做"影响更大。这是单纯优化 Prompt 无法触及的层面。
第二版：调用架构重构
基于上述判断，我们对意图管线的调用架构做了一次重构，核心是精确控制每一次 LLM 调用中模型能够接触到的信息范围，让模型在每个环节只面对与当前判断相关的最小必要信息，而不是一次性吞下全部上下文。
架构重构后，准确率有了显著提升。但我们很快遇到了新的天花板。
第三版：提升标签定义质量（数据层优化）
继续分析错误案例后，发现问题转移到了另一个维度：CR 标签本身的定义质量。
部分 CR 标签描述过于简短，边界模糊，LLM 无法从文字中区分相邻标签的差异。这时再怎么优化 Prompt 都没用，因为模型能理解什么，取决于数据层给它定义了什么。
优化方向是在数据层系统性地增强标签定义的完整度与区分度，并让这些增强后的定义在运行时参与到判断过程中，实现"数据驱动的标签定义增强"。这部分工作的回报，明显高于继续在 Prompt 上打磨。
最终准确率：86%。
核心洞察
这条管线的演进给了我们两个关键判断：
LLM 应用的性能瓶颈，往往不在 Prompt 措辞，而在调用架构——精确控制每次调用中模型能看到哪些信息，比反复优化 Prompt 指令更为根本。
LLM 分类质量的上限，由标签定义的质量决定。在模型能力固定的前提下，投资于数据层的定义质量，往往比投资于 Prompt 工程回报更高。
- 评估管线：一套模板覆盖所有语种 × 业务线
挑战：多种组合，如何不写多套规则
多语种 × 多业务线意味着每种组合都有独立的质检规则和上下文。如果为每个组合单独维护一套 Prompt 或配置，不仅工作量巨大，每次规则变更也会牵一发而动全身。
设计思路：配置外部化 + 动态组装
核心设计是把所有变化点从 Prompt 里抽离出来，沉淀到外部配置文件中：
-
质检标准以结构化文件管理，每条标准包含评分项描述、正确做法、错误做法等多个字段
-
BI 问题同样外部化配置，包含问题文本和选项定义
-
每次调用时，系统根据当前工单的语种（西班牙语 / 葡萄牙语）和业务线（出行 / 外卖 / 金融），动态拼装出完整 Prompt
新增一个评估项，只需更新配置文件；新增一种语种或业务线，只需添加对应的上下文块。一套模板，覆盖全部组合。
一次调用，多项同时完成
另一个关键设计是：多项合规评分（QA）和多项业务洞察（BI）在单次 LLM 调用中同时完成，通过 Tool Use 机制定义严格的 JSON Schema 约束输出格式，确保每项结果都包含判定结论和推理过程。
对于规则性强的指标（如拼写错误计数），系统还在 LLM 输出之后追加程序化校验，用确定性逻辑校准语义判断，避免模型在简单规则上的不稳定性。
此外，进入评估管线之前有一个对话过滤步骤：纯转接工单、客户无回复的工单等无效对话会被自动标记跳过，不进入 LLM 评估，既节省调用成本，也避免对无效数据打分污染结果。
合规评分平均准确率：90% 以上。
- VOC 管线：从人工汇总到数分钟出报告
问题
拉美市场覆盖多个国家，客服对话全部是西班牙语或葡萄牙语。运营团队发现问题趋势的方式，一直是人工逐条阅读工单，然后手动归纳。不仅耗时，还依赖个人经验，难以保证覆盖率和一致性。
三阶段 Pipeline
VOC 管线采用三阶段设计，针对特定时间窗口内的批量同类工单进行聚合分析：
第一阶段：并行提取
对每条对话独立调用 LLM，提取结构化字段：问题类型、用户情绪、解决结果、根因等。各工单之间无依赖，天然支持并行处理，吞吐量可线性扩展。
第二阶段：语义聚类
对提取出的"问题类型"标签做语义相似度聚类，合并同义表述（如 "unpaid cancellation fee" 与 "cancellation fee not paid" 会被归并为同一类），然后按工单频次排序，定位影响面最大的问题。这一阶段使用 embedding 相似度与统计排序，是确定性计算，聚类与排序结果本身可复现——上游提取仍依赖 LLM，但这一步不再引入新的随机性。
第三阶段：报告生成
基于高频聚类的结构化信息，LLM 生成管理层可直接阅读的分析报告，涵盖执行摘要、痛点分析、可执行改进建议。
真实案例
拉美市场短时间内集中出现大量取消费相关投诉。VOC 管线输出的报告直接定位了：主要根因、高频触发场景、以及针对性改进建议——运营团队无需阅读任何一条多语种原始对话，数分钟内完成问题定位。
效率提升：原本数小时的人工汇总，缩短至数分钟。
总结
这套系统的演进路径，也是我们对"LLM 在企业场景落地"这件事认知不断深化的过程。
几个核心判断沉淀下来：
架构先于 Prompt。信息隔离、分阶段调用、控制每次 LLM 调用的可见范围，是提升准确率的根本杠杆。把精力花在"模型应该看什么"上，往往比花在"Prompt 怎么写"上回报更高。
数据质量是上限。标签定义的完整度和区分度，决定了 LLM 分类能力的天花板。这不是 Prompt 工程能解决的问题，需要在数据层投入。
配置化是可维护性的基础。把所有变化点（语种、业务线、质检标准、BI 问题）外部化为配置文件，让系统能快速响应业务变化，而不需要每次改代码。
可追溯性是信任的前提。每项判定附带推理过程，让质检从"黑盒结论"变成"可复核的判断"，才能真正进入运营决策链路。
更重要的是，这套系统真正的壁垒并不在于某一处架构技巧，而在于持续沉淀的标签定义资产、质检标准库，以及围绕业务不断自主迭代的工程能力——这些是随时间复利、难以被快速复制的部分。
下一步，我们计划将这套系统扩展至更多业务线和语种，并探索三条管线之间的数据联动，让意图分析的结果能够反哺 VOC 的趋势归因。
如有技术交流，欢迎留言或联系滴滴 IBG 客户体验技术团队。