评估了一个RAG聊天机器人，最昂贵的模型表现最差。关于真正影响性能的因素的笔记。

我们有一个客户支持RAG机器人。标准配置：ChromaDB、系统提示词、一个用于生成的LLM。之前没有人真正衡量过回复质量。在评估的名义下，我只有一个关键词匹配脚本，产生一些看起来像分数但毫无意义的数字。我着手正确修复这个问题。分享我的发现，因为大多数结果出乎我的意料。 **1. 检索问题常伪装成LLM问题。** 用户问：“嘿，你们是做什么的？”机器人回答：“我没有关于公司服务的具体信息。”每个人的第一反应是调整提示词或更换模型。错。ChromaDB中的相似度阈值设置为0.7（余弦距离，值越小越相似，所以这里实际上很严格）。日常开场白产生的嵌入向量不足以接近任何文档块，无法通过这个过滤器。零文档被检索到。模型诚实地报告了它没有信息。教训：在指责生成问题之前，始终记录LLM实际收到的上下文。如果检索返回空，再多的提示词工程也无法解决。 **2. 启发式评估器比没有评估器更糟糕。** 统计关键词和来源引用会得到一个数字。这个数字与用户是否得到帮助毫无关联。更糟的是，它让你误以为你在测量某些东西。我咬咬牙，使用LLM评判器（通过OpenRouter的Claude Haiku 4.5）对相关性、准确性、帮助性和整体效果进行0-10分评分。每次完整运行花费几美分。便宜的保障。 **3. 在将块发送给模型之前去重。** 我们的两个轮次中，上下文窗口里有三个几乎相同的FAQ块。添加了一个检查：来自同一源文件的标记重叠超过80%。上下文更干净，标记更少，并且代理在一个轮次中停止了幻觉产品名称（很可能是因为噪声消失了）。 **4. 更严格的基于文档的约束在帮助性和准确性之间取舍。** 添加了一条规则：代理只陈述检索文档中出现的事实。准确性提升了。但在知识缺口轮次中，帮助性下降了，因为机器人开始说“文档未说明这一点，请联系支持”，而不是猜测。对于事实性支持机器人来说，这是正确的选择，但你需要有意识地做出这个决定。否则，用户会抱怨机器人变差了，即使你的分数显示它变好了。 **5. 运行模型扫查。默认值通常是错误的。** 我原本运行的是Gemini 3.1 Flash Lite Preview。用相同的评估框架扫查了5个模型。Gemma 4 26B得分更高（7.88 vs 7.33），而且每次会话成本降低了75%。Mistral Small 3.2紧随其后。Nova Micro最便宜，但简洁的回复因不够可操作而受到惩罚。重点不是Gemma是最好的模型。重点是，你的生产模型很可能不在帕累托前沿上，而你只有通过测量才能发现这一点。 **端到端结果：** 质量从6.62提升到7.88（+19%），每次会话成本从0.002420美元降至0.000509美元（-79%）。两个方向，同一轮运行。 整个评估使用的是Neo AI Engineer。它构建了评估框架，处理了带检查点的运行，解决了超时和上下文限制问题，并整合了结果。我手动审查了所有内容，并对哪些内容上线做了决策。完整的分步操作指南在评论区，如果有人想在自己的系统上复现的话。**👇**