评估客服聊天代理系统的笔记：启发式评估器给出虚假信号，检索错误伪装成LLM失败，成本/质量的帕累托前沿往往不在你想的地方 [D]

分享来自对生产级客服RAG系统进行结构化审计的一些实际发现。先说方法和注意事项。 **方法：** * 来自真实生产会话的6个代表性轮次作为评估集（较小，已知局限性） * 使用Claude Haiku 4.5作为LLM裁判，对相关性/准确性/有用性/总体打分（0-10分），返回每轮推理字符串以供验证 * 所有条件下使用同一裁判，相同问题，尽可能保持相同检索状态 * 保持生产模型不变，隔离检索变化，然后检索固定后横跨5个LLM进行扫查 * 使用OpenRouter /models API的实时定价而非估算 **发现：** 1. **启发式评估产生零信号。** 现有评估器统计关键词和来源引用。输出是数值，但与回复质量不相关。带有明确评分标准的LLM裁判能捕捉幻觉、识别零检索轮次，并生成可抽查的推理。相比发布未发现的回归，其成本是实际存在但较小（每次运行几美分）。 2. **检索失败表现为生成失败。** 代理说"I don't have information about our company"的轮次看起来像是模型知识问题。追踪显示检索到零文档。根本原因是相似度阈值（Chroma中余弦距离0.7）对随意开场白过于严格。在调整生成步骤之前，始终检查进入上下文窗口的内容。 3. **生产模型不在帕累托前沿上。** 扫查了Gemini Flash Lite Preview（原有模型）、Gemma 4 26B、Mistral Small 3.2、Nova Micro以及另一个。Gemma 4 26B在两个维度上都优于原有模型：更高的质量得分（7.88 vs 7.33），成本降低75%。原有模型既不是最便宜的也不是最好的。 4. **接地约束有可衡量的有用性成本。** 在系统提示中添加"only state facts present in retrieved documents"提高了准确性得分，但在文档未完全回答问题的轮次中降低了有用性得分。裁判一致标记"the documents don't specify this, contact support"的回复为准确但可操作性较低。这是一个值得在部署前揭示而非事后发现的真实权衡。 **我想坦诚说明的局限性：** * n=6很小。将差值视为方向性指示，而非置信区间。 * 作为裁判的LLM存在已知偏差（长度、冗长、自我偏好）。使用与生产模型不同的系列可以减少但无法消除这一点。已通过阅读推理字符串进行一致性检查。 * 这里的"质量"由裁判定义，而非用户定义。适当的下一步是将裁判得分与用户满意度信号相关联。端到端差值：质量+19%，成本-79%。成本优势是稳健的，因为定价是机械的。质量优势我希望在更大的评估集上看到复现后才声称其具有泛化性。我还写了一篇详细的文章，供想深入了解评估过程细节的人参考。在下方评论中提及 **👇**