“ 元旦快乐！这一篇应该是算法心得这个合集里面最后一篇RAG的文章了。在要结束的这一年里面，大部分的工作精力都是大模型应用测的一些东西，简单聊一些过去一年在RAG系统模型侧感触比较多的2点思考。
前一篇[大模型检索增强生成（RAG）系统进化指南]文章（想看的可以从文末的合集进去），分享了对RAG系统的一些思考内容，重点是讨论一个RAG系统在上线后可能会存在哪些问题，以及一些简单的召回侧的优化思路。
这篇主要讨论RAG系统模型上的思考，观点比较片面，不涉及任何方面的技巧，全是 胡思乱想 。（保命要紧，这年头写点内容真不容易，上次还有人私信给召回一顿喷，说啥langchain在他们公司是公认的垃圾框架，真是服了~）
RAG系统与大模型之间存在临界点
在距离ChatGPT发布已经一年多了，GPT4也都出了很多版本，最新的版本支持到128k的上下文长度，经过大量的网友测试，对知识检索能力非常的出色。今年年中以来，整个开源社区在长度外推上进展飞快，从线性内插到后来一系列的外推方案，可以让大模型在不做微调的情况下支持更长的长度；后来又有了诸如longlora之类的低成本的外推微调策略；再往后，超长文本的微调的难度已经不是在显存，因为有了flash attentionv2 、8bit adamw等可以几百倍的降低长文微调显存的开源方案，如何做好微调的长文数据成为了新的问题。
对于一些实际的RAG场景，很多的问题都是简单的信息检索问题，例如“茅台Q3的净利润” 、 “茅台的买入评级” 。在不考虑召回漏召回的时候，更考验的模型知识检索能力。根据问题，从召回的候选片段中找到正确的答案在组织成易于理解的语言输出到前端。
笔者今年关于RAG部分的工作不仅是在做知识库问答，还有云文档的问答。在早期的时候，想通过RAG系统来回复 “第二部分讲了什么” 这种问题其实是非常痛苦的，因为没法通过一个简单的召回策略来召回“第二部分”的内容。
如果能纯粹用大模型解决的其实完全没必要采取切片召回的方式，可以通过一些策略来评测模型的知识检索能力，找到这中间的临界点，当然一个优秀的基础模型也是很重要的，很多开源模型虽然说是支持很长的上下文长度，但其实知识检索能力惨不忍睹。
总结 ：如果还没开始搭建一个RAG系统，到今天，可能得先想清楚，到底是否需要一个RAG系统，是必须RAG不可吗？虽然RAG的优势一大堆，很多时候属于理想很美好，现实很残酷。如果已经有一个完整的RAG系统了，有没有可能把RAG和纯粹的大模型结合到一起。
召回主导大模型还是大模型主导召回 ？
召回主导大模型的典型就是，常见的单轮的形式，根据用户query搜索到合适的知识片段，然后大模型来做决策生成最终的答案。这种方案搭建起来，确实非常的简单，把数据导入es，在挑个大模型，就可以完成最简单的系统构建。整体上相当于让大模型来完成问答任务的最后一公里，把所有的都准备好让模型来做总结或者抽取任务。
大模型主导召回，最早的时候openai的webgpt工作，再到meta的toolformer，再到后面很多工作都在聊这个事情。其实是大模型来决定合适来调用工具（召回），何时去做检索，检索的query是什么，整个系统的重心已经放在了大模型上。问答其实也可以了解成一个agent的系统，例如一个易于理解的例子如下：“武汉东湖和杭州西湖的面积差多少”，模型会在适当的时间来决策“武汉东湖的面积” “杭州西湖的面积” 以及 [计算器] 工具 来得到最终的答案。
今年Q1,Q2的时候，自研7B、13B的模型来作为基础模型，这个尺寸的模型比较大的问题是，不够听话，不能强求这个尺寸的模型完全遵循你的提示词指令, 所以适当的指令微调对于7B的模型来说是很重要的，相当于是个强prompt的约束，可以按照约束要求输出。这个大小的模型优点是可以轻松单卡在4090上部署（我们年初采购了几十台8卡4090，性价比较高，用来部署模型），通过适当的微调，以及一些对齐策略可以让模型在总结、抽取任务上获得很满意的结果。
后来学习外网的网友们，开始玩更大的模型，比如30B、70B，继续预训练一个中文30B的llama，在更大尺寸模型很容易的就出现了推理的能力。当时第一次跑的一个测试集case结果图片现在还保留着，如下图（图片不便展示，文字贴下面）：
Q：中航西飞2020年营业总收入是多少？
召回的候选片段忽略。
LLM：根据知识片段1，2020年中航西飞的员工薪酬/总营业收入为 18.6%。这意味着中航西飞2020 年的总营业收入是员工薪酬的 1/18.6%。
图 25 中给出的员工薪酬是 62.2 亿元，所以中航西飞 2020 年的总营业收入是:
62.2 亿元 / 18.6% = 334.4 亿元
因此，中航西飞 2020 年的营业总收入是 334.4 亿元。
其实召回的片段没有对应的营业总收入，但是模型能通过一些片段，图表的信息计算出结果，这种推理能力是7B、13B的模型很难做到的。30B这个尺寸，可以通过量化到int4部署在4090上（比较勉强，留给kv cache的地方不多了），或者多张卡通过张量并行、流水线并行部署，也不是太大的问题。幸运的是，中文开源社区在Q4季度，在大尺寸模型发力，Yi、Qwen等更大尺寸模型开源，对很多企业都是一个非常好的消息。
当模型尺寸更大，除了带来的更强大的推理能力，他对提示词的理解也更好了。可以转移一部分召回模块的负担到大模型上，而不是想各种办法去完善召回系统。至于如何由大模型来决策合适召回，生成哪种内容。2个思路，1个是从系统架构层搭建一个Agent平台，另外一个是纯RAG场景微调。对于第一个思路，有很多开源的方案，比如ReAct、AutoGPT、ToolLlama等等，不局限于知识召回，可以接入更多的能力，对于Agent系统的设计，后面在单独写把。对于第二个思路，其实就是构造合适的input - target 的数据集，target可以拆解成多个部分构成, 让模型学会在适当的时候触发召回，比如上例子“武汉东湖和杭州西湖的面积差多少”，target需要包含2个用于召回的问题，以及每个问题的候选片段。这些都可以通过开源API来完成数据的构造，整体难度不大。重点是需要保证数据多样性，分步构造来尽可能的减少训练数据的错误，而且还能在正式场景work。
RAG系统评价维度
以系统评估结尾。
召回工具的评估比较简单，评估正确答案片段的recall以及召回噪声（不相干）的比例。
生成的评估也是2个维度，幻觉（分为2部分，1.遗漏了知识片段的内容 2. 回复了知识片段意外的知识） 问题相关性（是否完整的回复了用户的问题）。
最后放一个openai devday的一张ppt，可以看出来大模型主导的优势。随着开源社区的大模型能力的越来越强，可能大模型主导各种场景是新的趋势。（跟标题呼应了？不做标题党🤡）
老规矩，算法交流可以私信或者加微信，微信号：nipi64310