昨天，在做完了RAG的工程链路之后还是很开心的。
"这RAG好像也没什么难的嘛。就是在调用LLM之前做一次 Retrieval-augmented，只要数据准备好了，掉一下查询就完事儿啦。从工程上来看，实现就是很简单啊。"
今天上午，当我坐在工位上的时候，脑子里突然闪过一个念头。
"数据从哪儿来？怎么知道当前的数据好不好？怎么优化我的数据集？"
想到这里的时候，我发现昨天在设计系统时，还是在用以前的岗位和职责来思考这件事儿。
昨天构建的系统有个隐含的前提"数据要提前准备好"。
这在以前确实是由专门的算法工程师，配合运营来收集、整理，然后沉淀进向量库里。数据相关的事儿压根就不在我的考虑范围，我只管工程链路的搭建，保证服务的稳定。
但，现在根本没有这两种角色来配合我。后续的数据收集、整理，以及数据的持续更新等等都需要我来做。这个时候我一个人得担任好几个角色，才能把整个系统跑起来。
而当我看待这件事儿的角度变了之后，我发现我所需要构建的系统也应该调整。
评估系统的构建想法
**在线的RAG数据埋点。**之所以埋点，除了监控服务的稳定之外，还有一个好处是，可以定期抽样进行评估。
这里的关键点是，日志需要保存查询到的chunk_id以及调用LLM时的完整上下文。
**构建评估体系，**肯定是需要有些明确的指标才能比较方便地进行。
召回率 (Recall@K) ：在检索返回的前K个结果中，包含的相关文档块占所有相关文档块的比例 。低召回率意味着"漏掉了"，可能因为分块太细或检索方法不佳。
精确率 (Precision@K) ：在检索返回的前K个结果中，真正相关的文档块所占的比例 。低精确率意味着"搜偏了"，返回了很多不相关的内容。
平均倒数排名 (MRR)：衡量第一个正确答案在搜索结果中的排名的倒数平均值 。MRR越高，说明正确答案的排名越靠前。
快速判断 ：如果Recall低，问题可能出在分块（切得太碎）或检索（Embedding模型不佳）上；如果Precision低，问题可能出在分块（块太大，信息混杂）或检索（检索到太多噪音）上。
**离线的RAG评估。**这里是最关键的一步，我在实践中有两条路。
一是从在线的埋点数据中抽部分数据出来，接着由人去根据问题写答案，然后丢给模型去找人和现有RAG之间的差距。
如果人写的答案，明显好于RAG的答案。那说明之前的文档内容不对，需要根据埋点日志中的chunk_id定位文档，看看怎么优化文档内容。
二是让模型根据文档的内容，同时扮演提问者和回答者来生成Q&A。接着，这些Q拿去跑一遍RAG，让模型去对比RAG生成的内容和之前的虚拟回答。如果模型的生成的答案是优于现有RAG的答案，那说明要么是chunk有问题，要么是文档内容不行。
