在前两天的版本中，我一直在重复地进行评估 - 补数据 - 重建数据集。
看上去像是在告诉大家只要数据整好了，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_RATIO=4 参数，作为放大召回的倍数。也就是说，召回从5个变成了20个。然后再在20个中间做 CrossEncoder 计算 score，最后取 top-5。
下面是我集成 Hybrid Search 和 Reranker 之后的效果
可以看到，现在召回的内容很全，召回的问题基本被解决了。接下来再通过 Prompt 解决质量问题就比较快啦。
我把我做的项目也贴上，感兴趣的朋友们可以去看看。