rag实际工程中好用的技巧

rag fusion

这是一个论文来着我记得。而且在langchain官方教学里也有。思路是一个query生成多个同样语义但是表述不同的query，然后分别进去rag，得到多个回答，最后把多个回答fusion，即总结。

这个法子能很好滴增加正确文档的召回率。

稀疏向量、稠密向量、关键词一起用

稀疏向量是指维度极大的query embedding，这种向量做完对齐基本上是维度冗余的，但是在query极度像训练数据里的query时，就很容易匹配到正确的chunk。
稠密向量，就是bge那些。
关键词，可以是bm25，也可以是你用小模型抽出来的关键词，再按metadata搜索。

这三种各自有各自的优势，所以一起用吧，废文档靠后面相关性检查模块就好啦。

信息追问

这个机制是在llm参数量足够大，能力够强，然后能识别出给的context不足以回答问题的时候，引导llm生成三个追问问题的机制。完成这个机制只需要prompt就行，但是能极大提高用户体验。例如kimi也每次都会在答案后面给你生成一些追问问题，以前的ai医疗问答也会这么干，不如说追问是基操。

embedding微调的小技巧

有些bad case出现，是因为用户在query提了一个很稀有但是与他的询问没多大关系的词，这个稀有词极大地影响了embedding，导致召回失败。
首先，你得分从语义层面分割句子，让不相关的两句话拆开，尽量剔除无关句子。然后分割完你也不知道前面是问题还是后面是问题，所以都得拿去召回，并且还得分别获得信息，最后再fusion所有信息。
训练的时候，训练的query语义分割了，我们会认为一个query分割成几段，都是要得到同样的chunk，所以都要与chunk对齐。

作为一个产品，用户用你的东西检索，但是你后面有好多个数据库，全量检索的话，这rag基本等于废了。所以如何引导用户选择他感兴趣的库？而不是直接开问？

注册的时候就就得给用户几个引导性提问，就跟短视频平台一进去让你选的那些似的。
如果用户想切换了，其实完全可以让用户给出一些描述，他想问哪类问题，你先根据库的特征匹配一些，如果用户反复修改描述，就等于是你没找对，总之这个过程是收集正负例的过程。数据多了，就能做描述和数据库的匹配了，或者是query-db对齐，或者是query-query的对齐。没有现成的好办法。

多轮对话里，有时候用不到知识库，只是闲聊天。有时候召回得太杂，有些文档纯纯没用，还是塞进来了，llm很可能把没用的信息也融进输出。

对于区分闲聊天和检索，可以用意图识别or训练llm自动识别是否检索。前者好说，一个轻量级模型能做到。后者，你得走self-rag的路子(我看kimi就是用的self-rag)。
用selfrag架构要比意图识别好，把所有事都在一次生成里干完，是最快的。

还是召回无关文档的问题

假设你向量模型调得挺好，我可以说相关和无关的向量分数会有明显的分布差距。你找个阈值，一般设两段，一硬一软，例如0 8和0.6，低于0.6的直接扔，不到0.8的rerank往后排，过了的排前面。
还有，你知识库生成的时候先来生成一些QA对，直接query-Q匹配，然后拿召回的几个Q对应A来生成针对query的回答，注意此时的A就全是llm生成的了。

用户想查数据库，本质是个统计问题，例如想查xx年的总支出

这种问题就只能意图识别 or tools引导到对应的专门处理text2sql的llm了，注意这里面重写query使其规范是一个很重要的事，最好还让用户确认一下，否则用户写的乱七八糟也不好直接生成sql。