聊天机器人可能在忠实总结错误的文档

RAG 演示在搭建者自己写的问题上通常表现不错。真正的考验在用户用自己的话提问的时候。DeepLearning.AI 的课程 Advanced Retrieval for AI with Chroma 时长 1 小时 2 分钟，只讲一个环节：检索文档。

讲师是 Chroma 联合创始人 Anton Troynikov。课程包含 7 节视频课、5 个代码示例和 1 次计分测验。课程页面显示，最近一次更新是 2025 年 10 月 7 日。

对前线部署工程师（FDE）来说，范围窄反而是优点。客户抱怨聊天机器人“答错了”时，有一个假设值得尽早排查：模型其实是在忠实地总结一批不相关的文档。这门课讲了三种应对办法。

按什么顺序学？

值得掌握的三项技术是查询扩展、交叉编码器重排序和嵌入适配器。每节课都很短，重排序一节约 6 分钟，适配器一节约 8 分钟，一个晚上就能学完。

顺序是从便宜到昂贵。查询扩展和重排序只需在现有管道里加一步；适配器则需要标注数据来训练。到了客户现场，第一件事仍然是找出管道在哪里出了问题，之后再挑技术。

同一个问题，多种问法

查询扩展会给用户的问题补充相关概念和关键词。deepset 的 Haystack 文档通过 QueryExpander 描述了同样的思路：从一条查询生成几条意思相近的变体，以提高召回率。

假设你为一家保险公司部署内部文档助手。员工问“退保能退钱吗？”，文档里写的却是“合同提前终止”。

生成“提前终止”“退保手续费”这样几条变体，搜索命中正确段落的可能性就会更大。

Educative 用概率解释了其中的道理：同一个问题的问法越多，至少有一种问法在嵌入空间里靠近相关段落的机会就越大。

这是推理，不是测量结果。仍然要在客户的数据上实测。

先宽召回，再细打分

查询扩展的代价是检索量变大。假设有 1 个原始问题加 4 个生成的变体，每个检索 10 条结果，一共 50 篇文档，去重后大约剩 30 篇。30 篇不可能全部塞进上下文。

所以下一节课讲重排序：交叉编码器对检索结果重新排序，挑出与查询最相关的几条。这一步只处理已经拿到的候选，适合几十篇文档，而不是整个集合。从 30 个候选中，保留 5 篇交给 LLM。

为你的应用重塑嵌入空间

嵌入适配器这一节有整门课最有用的想法：加一个小层来重塑嵌入，让对你的应用重要的特征占更大权重。课程页面只说这“可以提升”检索效果，没有给出明确承诺。

Chroma 关于嵌入适配器的研究报告给出了更具体的数字，但需要仔细读。一个只作用于查询的线性适配器，与单独使用预训练嵌入模型相比，检索准确率提升“最高”达 70%。

这个结果来自报告自身的实验设置：在 CQADupstackEnglishRetrieval 数据集上用 NDCG 测量，基线是 all-MiniLM-L6-v2，而且适配器至少需要 1,500 对标注好的查询–文档对。不要向客户承诺 70% 的提升。

即便如此，“只作用于查询”这一点对 FDE 很有实际意义：不必重新嵌入客户的数百万篇文档，也不必换模型。如果从第一天起就记录问题，以及用户确认正确的文档，这些日志以后就能成为试用适配器所需的标注数据。

适合谁学，简历上写什么？

这门课适合已经有一套能跑的 RAG 系统、却总在问“为什么检索到的文档不对”的工程师。如果从没做过 RAG，先搭一个简单版本。只有亲自踩过这些坑，这些技术才讲得通。

要证明修对了地方，需要一个简单的指标。命中率（hit rate）只问一件事：对每条查询，系统在前 k 条结果里是否至少检索到一个正确段落？是记 1，否记 0。全部查询的平均值就是总体命中率。

取 20 个问题，k=5。重排序之前，有 11 个问题的正确文档在前 5 条里，hit rate@5 为 11 ÷ 20 = 55%。加上重排序后，如果有 16 个问题命中，hit rate@5 就是 80%。这些数字只是示例，你的数字必须来自自己标注的问题集。

阅读 FDE 或应用 AI 岗位的职位描述时，留意“retrieval quality”“RAG in production”“evaluation”这类说法。在简历上，“加入交叉编码器重排序，在 20 个真实问题上将 hit rate@5 从 55% 提升到 80%”这样一句，远比“熟悉 Chroma”有分量。

花一小时学完这门课，然后在客户现场的第一次工作里标注 20 个真实问题。只有拿到前后对比数据，才信任一项技术。