在前两天的版本中我一直在重复地进行评估 - 补数据 - 重建数据集。看上去像是在告诉大家只要数据整好了RAG就可用了。但是真实情况不是这样。之所以我在不停的补数据其实是因为自己还是有一点咖啡知识的。作为一个手冲咖啡党我知道平时我买豆子的时候关心什么问题哪些数据是一定要的我是有感觉的。只是我一下子没法全给你列出来所以我需要通过不断地评估来让我回想起一些关键的行业知识。回到正题。要想对上个版本进行优化我们还得先看看数据集补充完了之后的效果。这里我想提醒下Agent 给的建议只能参考不能全信。首先 R13、R21 这两个问题不属于产品的范围准确地说这是冲煮咖啡的知识。这类问题完全依赖模型的回答是对的没有必要把所有通用的知识补充给模型。在我看来重点问题是R14和R23。这两个问题的答案确实是文档中有的但是仍然召不回。还有 R09看上去是召回了但实际上我重跑一遍之后发现这个问题的在实际RAG的时候也是没有被召回的这里Agent 属于是解读错误。反正不管怎么看召回的问题都很大。所以我们接下来优先需要解决的是召回漏的问题。由于我也没有什么很好的优化手段所以我还是让 Agent 给我出了优化的建议。基于 Agent 的建议这里我的判断是 P0 问题并不关键。因为在选择方案之前我还把这些问题一个个去跑了RAG。看了返回的 结果 和 chunks 之后发现本质问题还是上下文不对上下文召回的top-5中和问题相关联的内容还是太少了有些顺序还在很后面。而且Promt 应该是在上下文正确的情况下去优化而不是在上下文都不对的情况下去优化这是在浪费时间。因此我还是决定先解决召回的问题。Hybrid Search混合检索其实就是结合RAG和全文匹配。RAG 能召回语义相近的 chunks而全文匹配能精确的知道 query 中的词根在 chunks 中出现的频率。利用语义和词频加权得到的结果能提升精确查找这种场景下的召回率。为了方便计算我并没有直接使用全文搜索引擎。而是通过 jieba 给 query 分词然后遍历所有文档用 rank_bm25 来计算得到 query 在每个文档中的 score。这种方式最简单。因为我只有十个不到的文档遍历本身就很快。而且这样还不需要额外引入一个搜索引擎一举两得。Rerank这里的重排有个理解上的误区。它的意思并不是在召回的 top-5上去给chunks排序而是在超额召回的基础上利用 Rerank 来计算 score。最后再在 score 排序之后的列表中取 top-5。在上个版本中我召回数量是5。很多时候召不回真正相关的文档因为真正相关的文档排名比较靠后。我推测是因为当前的 embedding 模型是 Chroma 的默认模型语义匹配能力比较弱。我这个版本的 Rerank新增了一个 RERANK_RATIO4 参数作为放大召回的倍数。也就是说召回从5个变成了20个。然后再在20个中间做 CrossEncoder 计算 score最后取 top-5。下面是我集成 Hybrid Search 和 Reranker 之后的效果可以看到现在召回的内容很全召回的问题基本被解决了。接下来再通过 Prompt 解决质量问题就比较快啦。我把我做的项目也贴上感兴趣的朋友们可以去看看。GitHub - dkisser/rag_learn: rag study · GitHub