你的RAG落地效果不好？可能缺的不是技术，而是运营

知识检测与更新机制

很多RAG项目中之所以感觉检索结果不准，仔细分析日志往往会发现一个用户提问实际会检索出多条相似的知识，专家都很难分辨出哪条知识是对的，语义相似度都很接近，怎么调整检索算法都没用。

向前追溯，就会发现还是知识维护的质量太差，无论是QA类知识，还是文本类知识，知识库中充斥着大量冗余类似的知识。因为不同的人在做知识维护，大家都只管往知识库里加知识，没有人去做重复检测与梳理合并。

除了要做好重复冗余知识梳理的基础要求外，一些行业性和专业性高的知识库，在知识更新上的处理要求会更高，尤其是维护政策类知识，当新政策要处理时，往往需要将历史政策中某些条款（对应分块）失效掉，或者有可能要将历史知识设置好有效期，这样才能满足政策可追溯性检索场景，根据用户问题中时间要素，匹配到不同有效期的知识分块。

所以在基础的知识库底座之上，按不同的业务场景，需要构建起特色化的知识检测与更新机制，确保知识管理和运营同学，能有序做好知识合并与更新处理。

上图只是简单罗列了一下笔者碰到过的几种处理机制，实际业务中往往会更复杂，比如在检测环节，图中只标注了按语义相似度去检测历史知识，实际政策类场景中，政策中往往会明确列出本政策发布后，XXX政策失效，这时可以根据文件名去做更精确检索，另外在处理环节，同样要根据实际业务需要去扩展，比如直接覆盖等。

知识验证与发布机制

在知识检测和更新机制有了以后，面对新增或更新的知识，还需要进一步完善知识验证与发布机制：

在严肃的业务场景中，考虑自动切片、自动打标结果不准等情况，都需要安排相应的环节去做审核校准和调整。

同时针对新增和修改的知识，如何确保在线上检索和问答过程中符合预期呢，新增了知识，结果发现线上总是检索不到，如果能先验证或测试下，就会尽可能减少这类情况的发生，尽可能提前发现问题。

当然验证和测试的方法是要结合业务场景去考虑的，简单一点就让运营人员做个简单问答验证，极端严肃场景，最好是有一套测试集，任何知识变化，都要完整测试集过一遍，当然代价也是极大的，这就和算法优化升级一样，也是要有测试集来保障，避免负向优化和开盲盒。

要做验证测试，就要考虑和线上检索做隔离，没验证通过前不能影响线上检索结果，这就涉及到知识如何便捷的发布和生效。

线上评价反馈运营机制

以上知识检测和更新机制以及知识验证与发布机制，都是用于保障知识维护过程的质量，那么在知识发布使用以后，还能如何持续提升准确度呢？

仔细观察公网上的大模型应用，在对话输出结束后，总会有个点赞点踩的标记，用于收集用户使用的评价和反馈，大厂做这个功能，背后是可以利用这些信息，来构建大模型微调的标注数据集，甚至是下次预训练时的训练集。

那除了优化大模型之外，回到本文主题，也就是提升RAG效果来说，我们可以充分借鉴以上做法，构建线上反馈评价和运营处理的闭环机制：

对收集的线上反馈评价，经过后台运营人员核实后，根据业务场景需要可以提供不同的运营处理方法：

比如针对用户点赞的评价，可考虑将用户提问和回答结果作为新的QA问答知识补充到知识库中去。

针对用户不满意的评价，核实后如果是知识质量不高引起的，则可以按需去调整已有知识或补充知识，如果知识没问题，再考虑如何进行检索算法优化等。

还可以从反馈回流信息中，抽取相应问题和预期结果来构建测试集，用于知识维护过程中的验证测试，甚至用于SFT微调的标注数据集等。