RAG 技术 检索增强的生成系统（Retrieve Augment Generation）简称 RAG。 原理是在大语言模型的基础上，辅助检索技术，让大语言模型能够获得与用户问题相关的更多上下文信息，使得的大语言模型可以： 降低幻觉出现概率 适应垂直场景应用 弥补数据实时性不足 一个典型 RAG 系统的架构 RAG 系统的核心技术要素 文档导入 文档切分 文档向量化 向量数据库选型 检索算法 文档排序 Prompt 生成 $\dots$ 市面上大部分的关于 RAG 的介绍都是类似上面的逻辑进行的，然后就顺利的将 某一种 RAG 的方法 变成了 通用 RAG 的框架，从而让我们迷失了 RAG 的真正价值。 从定义出发，RAG 就是 检索 + 生成 Chat With Documents 属于 RAG 用户对话中保留历史记忆 属于 RAG 网页搜索 + LLM 属于 RAG 自动调用 API 接口获取信息 属于 RAG 调用数据库获取信息 属于 RAG $\dots$ 上面各种方法一起使用也属于 RAG RAG 究竟意味着什么？ 为什么我们要使用检索 人类行为的两种模式：主动获取信息（功利动机行为）和被动获取信息（共情动机行为）； 通常在产品上，我们可以用 Save time 和 Kill time 的模式来区分 主动获取信息的手段被称为信息检索。 RAG 更标准的说法应当是有了 LLM 能力加持的信息检索。 LLM 很难独立完成检索 最核心的问题是，对于如何引导大模型按照我们的意愿生成内容，我们无法直接控制，我们只能通过增加上下文的方式来影响生成结果。 对于大模型来说，它会如何回答一个问题依赖的不是训练框架，而是训练数据。 我们无法直接控制大模型的生成结果，但是我们可以通过增加上下文的方式来影响生成结果。 一个问题，我们可以提供相关的上下文，然后利用大模型的泛化能力，让它生成我们想要的答案。 大模型的“记忆力”并不可靠，不同的上下文会引导出怎样的结果是不确定的。 仅靠大模型，是无法取消幻觉的。 如果 RAG 做得不好，可能带来的是负面效果。 RAG 的核心 如何用好检索 检索的发展史 图书馆的索引式检索（Yahoo 等目录网页）； 关键词召回（传统搜索）； 向量相似度（个性化推荐）； 自然语言回答问题（大模型）； 这些方法不是递进的，而是并列的。 新概念下的 RAG 框架 对用户问题分类，判断使用哪些检索器； 根据用户问题，找到最适合的检索器检索方式（Query、SQL、API 调用等）； 召回的结果，判断与用户问题的相关性，进行合理过滤或改进； 用适合的方式组织召回结果，提供给 LLM 进行汇总并回答用户问题； （可选）判断是否很好的回答了用户的问题，是否需要重新再来一遍（这其实就进化成 Agent 了）。 可以使用不同的 LLM 来执行不同的任务，这样就可以在计算速度和资源上得到极大的节约，并针对特定问题取得更好的效果。 检索器的各种优化技术都值得使用： 包括传统的关键词搜索（QP） 向量检索只是其中的一种手段；同时向量检索也应当额外建立适合的索引。 知识图谱是有效的检索器之一。 利用好结构化信息（数据库 或 API）。 好的检索器依赖好的数据。 Q & A 如果我们有一些私有的数据，如何让大模型能够利用这些私有数据呢？ 通过微调的方式，将私有数据加入到大模型的训练数据中。 通过检索的方式，将私有数据加入到大模型的上下文中。 以上方法都用 怎样才能更好的提升 RAG 的效果？ 最核心的要素其实是：找到更优质的数据（准确、结构化） 产品和开发要深入研究 Prompt Engineering 吗？ 永远都不要这样做，这件事交给 SFT 概念对比 Let’s think step by step 通用优化 Prompt 的 Prompt function call Self RAG 让模型来学习如何 Prompt Engineering