引言
您是不是也有这样的问题？RAG是技术的事情，产品经理没啥要设计的。接下来，我会以真实项目经历分享我对RAG的理解。通过这篇文章，您可以获得如下信息：
1. 什么是RAG
2. 为什么要用RAG
3. RAG的流程及局限性
4. 产品经理能做哪些工作
5. 总结及展望
6. 预告
01
什么是RAG？
RAG（Retrieval-Augmented Generation）是一种结合了信息检索（Retrieval）和文本生成（Generation）的自然语言处理技术。它通常用于提升语言模型在特定任务上的表现，特别是在需要广泛知识背景支持的情况下。RAG模型的基本思想是利用预训练的检索系统来从大量文档中检索相关信息，然后将这些信息作为上下文输入到语言模型中，以生成更加准确和相关的输出。
产品经理评注：
RAG技术可以通俗理解成，为了让模型表现更符合我们的预期而产生的一种检索增强技术。
R - Retrieval（检索）：
检索意味着“寻找”或“查找”。就像在图书馆里找到一本你需要的书一样，RAG模型会在知识库中找到相关的信息；
A - Augmented（增强）：
增强意味着“改进”或“强化”。在RAG模型中，检索到的信息被用来改进或增强生成的回答。这部分就像你找到的书不仅仅是用来阅读，还用来帮助你更好地理解和回答问题；
G - Generation（生成）：
生成意味着“创建”或“产生”。在RAG模型中，最终会基于检索到的信息生成一个完整的回答。这就像图书馆员根据书籍的内容，用自己的语言向你解释问题的答案。
02
为什会用到RAG？
2023年3月，大模型刚火的时候，我们也在思考切入点，因为之前做智能终端项目，结合大模型特性，以此为切入点，开始了我的第一个AIGC项目。
1. 项目背景
小A某科技公司CEO，深耕智能终端十余年，公司需要投入大量的人力，充当客服回答用户重复的问题，投入产出极低。
2. 项目目标
7 x 24h回应客户的问题；
保证客服回复的质量；
节约员工在客服场景投入时间，去做一些更有价值和创造性的工作。
3. 产品验证
在此之前，我们尝试搭建一套chatbot，通过大模型自身能力解决用户问题（即：通过prompt约束模型的输出），一方面探索模型的能力边界，另一方面控制成本。MVP版很快出来了，主要存在3个问题：
部分企业内部设备信息查不到；
无法辨别回复内容真伪；
幻觉问题（如：存在明显的胡编乱造）；
产品经理评注：
以上问题可以看作模型的回复不遵从事实，事实应来自于可靠的信息源，比如：企业内部信息资产、央视公开新闻报道及互联网部分信息数据等。通常，我会简单将模型能力理解为：共情能力、知识能力和推理能力，主要是模型自身的知识能力不足。
4. 为什么不直接预训练一个大模型
那各大模型厂商或企业，为何不训练无所不知的超级大模型呢？理论上当然可以，但从模型三要素算法、算力和数据上看，要训练一个大模型（这里指的是预训练模型，不是微调模型），还需要从实际出发，综合权衡成本和效果，主要体现：
从投入成本角度看，从问题定义->数据采集->数据处理->训练集&测试集->模型->效果评估，这里需要投入大量的人力和算力，如果仅仅是想通过训练来提示模型的知识能力，投入产出比太低；
从效果角度看，如果没有可信的数据源，即使训练出了一个大模型，结果可能也会差强人意。
产品经理评注：
无论是A1.0还是A2.0时代，理解业务场景，定义问题，基于问题收集高质量的数据，决定模型落地的效果。
5. 解决思路
那如何低成本解决大模型回复不遵从事实的问题呢？其实，这里面的核心是如何获取高质量、可靠的信息源（如：互联网、数据库、知识库和知识图谱等）。当时主流的两种方案：
毕竟是MVP版本，权衡成本和可控性后，最终决定通过RAG技术来提升模型回复准确性。
03
RAG流程？
接下来，我们的目标就是：以大模型为驱动，外挂企业知识库，通过RAG技术，提升回复准确性（即：希望模型回复，遵从知识库内容）。
整个RAG主要分成文档上传和用户请求两个部分：
第一部分：用户上传知识库
上传文档
当用户希望模型按照私有文档内容回答或生成内容时，可上传准备好的文档。支持pdf、word和excel格式，其中：
pdf和word适用场景：非结构化；
excel适用场景：智能客服和问答对；
对文档进行分块
根据一定的规则对上传的文档进行分块，切分规则通常包括：
换行符；
句号；
字数等；
向量化存储到向量数据库
将所有分块，通过embedding模型转化成向量的形式，再存储到向量数据库。
第二部分：用户请求
问题向量化
使用同样的embedding模型，对用户问题进行向量化（注：为了匹配的精准度，文档和问题向量化模型需要一致）。
匹配
去向量库进行相似匹配，会经历“召回 -> 排序”，得到相似度最高的知识块，即：context;
请求大模型
将“prompt + 用户问题 + context”作为request，发送给大模型，得到模型回复；
对齐
对输出进行二次处理，比如：是否敏感，如果需要兜底回复，还需要工程侧配合处理。
产品经理评注：
这里有必要提一下向量化，可以简单看成把复杂的信息变成数字列表，让电脑能更容易理解和处理它们。为了更好理解，我简单画了个图，不一定科学，但尽可能通俗易懂。
04
产品经理要怎么做？
当前目标已经很明确了，就是回复的内容需要遵从事实，也就是说，给大模型框定一个边界，利用模型理解能力，拿到与用户请求最相关的知识片段，通过大模型回复。接下来，我们将RAG流程中可能存在的问题，转化成具体的业务问题：
问题1：知识库巨大，可能导致匹配准确性和效率，如何让解决？
产品经理评注：
如何引导用户创建高质量知识库（比如：对超长文本，按场景进行拆分成多个文档，根据意图识别来“路由”对应的文档），提升召回的准确率，这样输入给大模型内容会更可靠，对大模型来讲，好的输入才会有好的输出；
问题2：现有分片规则，容易导致同语义内容被截断，如何避免？
产品经理评注：
当知识库文本长度有限时，用户可以基于自己的行业认知，通过自定义特殊的“符号”，对文档进行拆分，尽可能保证同一段落的完整性（注：针对大文档，人工“标记”效率较低，不建议采取该方法）；
问题3：相比非结构化数据，结构化数据表现更佳，如何优化？
产品经理评注：
可以将非结构化文档，通过模型转化成问答对，人工核验后，用于用户问题匹配；
问题4：通常用户问法比较随意，导致结果不理想，如何处理？
产品经理评注：
把大模型看作人，你的问题描述的越清晰，他回答的越好。针对模糊问法，用多轮对话方式澄清问题，可能是个不错的方式；
当然，除了产品侧，技术侧同样有很多优化的空间，比如：
选择什么样的embedding模型；
如何保证召回的内容的准确性；
如何选择模型（综合成本和效果）；
如何通过“问题 + 召回内容 +prePrompt”构建一个适合模型的prompt；
05
总结及展望
本文通过真实的项目，以产品视角，思考RAG流程各环节优化方向，现阶段RAG依旧是主流的知识检索增强技术，确实在某种程度上提升了知识问答的准确率，但针对低容错率的场景，仍然存在提升空间。
如何结合“知识图谱 & RAG”，进一步提升准确率和减少幻觉方面，提供了另一种可能性，期待～
特别感谢，黄钊老师（公众号：hanniman）一句话一直深深影响我，让用户完成AI设计的最后一公里，我简单理解为，AI技术能力不够，产品设计来凑，让用户来将产品中不确定的因素给明确掉，以达到理想的业务目标。
06
预告
前面提及，可靠的事实来源互联网、数据库、知识库和知识图谱等，本文基于大模型理解能力，外挂知识库核心是弥补模型知识能力不足，减少幻觉。接下来，分析“大模型 +工具”获取更多业务沉淀的数据，探索工具在大模型时代，给业务带来的价值。
