8.6
深览指数
科技Bestblogs·大淘宝技术··AI 生成
淘宝 AI 购物助手在线评测落地实践
淘天团队公开了 LLM-as-a-Judge 方法在日均海量会话、多域异构的电商 AI 购物助手场景中，实现日级全量在线工业化评测的工程实践。文章指出，工业落地的核心瓶颈不在 Judge 模型本身，而在数据清洗和评测标准的持续校准。团队通过四层清洗管线、数仓与推理平台解耦的分布式批量架构、CNT 六层漏斗 Rubric 标准与短路机制等具体方案，构建了从日级观测到根因定位、再到修复核验的完整优化闭环。适合关注 LLM 评测工业化、AI Agent 质量保障的技术决策者和一线工程师阅读。原文 ↗
核心观点
- ▍LLM-as-a-Judge 在工业场景落地的核心瓶颈不在 Judge 模型本身，而在输入数据清洗与评测标准的持续校准。
- ▍给 Judge 模型更多上下文（如全对话工具链）不一定更好，反而会导致注意力分散与跨轮信息串扰。
- 01线上日志存在碎片化、卡片信息缺失、tool_calls 内部提示词噪声与语义不一致等问题，团队设计了四层清洗管线（格式修复、语义对齐、干扰屏蔽、入口过滤精化）来治理。
- 02采用「数仓与推理平台解耦」的分布式批量架构，预处理和后处理聚合全在数仓 SQL 完成，推理平台仅做模型调度，各域独立 workflow 并行运行。
- 03构建了 CNT 六层漏斗 Rubric 统一框架（CTX、OOSR、OOC、TCC、CNT、RED），串行层采用任一判 0 即短路的原则，RED 并联恒评。
- 04Prompt 工程中通过输入变量明确声明、反向证据摘录、提问时间戳拼接来解决时效误判。
- 05发现全对话工具链导致 Judge 用前几轮的工具返回评判当前轮回复，改为仅保留当轮 tool_calls 后，通过率大幅跃升。
- 06建立了四层归因框架（数据层、Prompt 层、Rubric 层、Agent 真实质量），避免盲目调优 Prompt 掩盖真问题。
反方 / 局限
- — 文章概述了工业实践，但未公开具体的 Rubric 评分标准细节、清洗管线的具体规则或不同 Judge 模型（如 GPT-4 对比开源模型）的评测成本与效果对比，限制了其他团队的直接复现。
- — 四层归因框架依赖的 SQL 可复跑规则如何设计以避免主观判断、是否可以做到自动化归因，文章未详细展开。
4 分钟 · 3 卡片 · 6 资料
读原文 →