Ragent day-03 RAG

大模型的局限性

RAG 架构：让大模型开卷考试

大模型懂语义但没有私有知识，传统搜索有数据但不懂人话。能不能把两者结合起来？这正是RAG（Retrieval-Augmented Generation，检索增强生成）要解决的问题。

简单说就是：

• 1.把公司的产品文档数据存到一个能理解语义的知识库里；

• 2.用户提问时，先从知识库检索相关内容；

• 3.把检索到的内容和用户问题一起发给大模型；

• 4.大模型基于这些参考资料来回答。

2. RAG 核心流程

2.1 Ingest：把数据导进来

这步的目标就一个：拿到干净的纯文本。

2.2 Chunk：把长文档切成小块

常见做法是 500-1000 字一块，相邻块之间有一定重叠（比如重叠 100 字），防止重要信息正好被切断。

2.3 Embed：把文字变成向量

向量就是一串数字，比如[0.23, -0.45, 0.67, ...]，可能有几百上千维。这串数字编码了这段文字的语义信息，意思相近的文字，向量在空间中的距离也近。

"打印机怎么用" → [0.23, -0.45, 0.67, ...] ​ "产品使用方法" → [0.25, -0.42, 0.65, ...] ← 很接近 ​ "今天天气不错" → [-0.89, 0.12, 0.03, ...] ← 差很远

这个转换由专门的 Embedding 模型完成，比如 Qwen3 的 Qwen3-Embedding-8B，或者开源的 bge、m3e。

2.4 Index：存进向量数据库

常见的向量数据库有Milvus、Pinecone、Weaviate，轻量级的有Faiss、Chroma。

存的时候，向量和原文要一起存。后面检索出来，得把原文拿给大模型看。同时还要有元数据（简单理解是个 JSON）的概念，方便检索时进行筛选精准数据。

2.5 Retrieve：检索相关内容

• 1.把用户问题也转成向量；

• 2.拿这个向量去向量数据库搜，找出最相似的几个文档块。

2.6 Answer：大模型生成回答

最后一步，把检索到的内容和用户问题打包发给大模型。

2.7 流程小结

总的来说，RAG 适合知识密集、更新频繁、需要可追溯的场景。但它不是银弹，效果好不好，得看知识库建得怎么样、系统设计得合不合理。

RAG 实际应用场景

1. 企业内部知识库

2. 智能客服

3. 专业领域助手

4. 代码与技术文档助手

做好 RAG 并不容易

1. 数据入向量库

企业里的知识不会乖乖地以纯文本形式等着你。PDF、Word、PPT、网页、Markdown、数据库，什么都有。光是把这些东西解析成干净的文本，就是一堆脏活累活。PDF 里的表格、扫描件、双栏排版，每一个都是坑。

2. 问题重写

用户输入的问题，往往不能直接拿去检索。

• 口语化：用户问“报销咋整”，你拿这四个字去做向量检索，效果能好吗？得把它展开成“公司报销流程是什么，需要准备哪些材料”之类的完整表述，检索效果才会好。

• 多轮对话：用户第一轮问“年假有多少天”，第二轮接着问“怎么申请”。这个怎么申请单独拿去检索，系统根本不知道在问啥。得把上文的年假补进去，变成年假怎么申请，才能检索到正确的内容。

• 多意图：“请假流程是什么，另外帮我查下我还剩几天年假”——这其实是两个问题，一个要检索知识库，一个要查业务数据。你得先把它拆开，分别处理。

• 复杂问题：用户问“我想申请调岗到上海，需要满足什么条件，流程是什么，大概要多久”——这个问题涉及多个方面，可能散落在不同的文档里。直接检索未必能覆盖全，拆成几个子问题分别检索，再合并答案，效果会更好。

3. 意图识别

• 闲聊：用户说“你是ChatGPT么？”，这种情况去知识库里检索，能检索出什么？这种情况应该直接让模型回复，不用走检索。

• 工具调用：“报销制度是什么”需要检索知识库，“我这个月的报销单到哪一步了”需要调用业务系统接口。走错了路，答案肯定不对。

• 多知识库路由：企业里可能有多个知识库——HR 政策库、产品文档库、技术文档库。用户问的问题应该去哪个库里找？如果每个库都搜一遍，成本高、噪音大；如果只搜一个库，选错了就什么都检索不到。

• 该不该回答：有些问题不该回答。涉及敏感信息的、超出系统能力范围的、恶意试探的，都需要识别出来，给出合适的拒绝或引导。

4. 数据检索

向量检索的局限：纯向量检索对语义相似性很敏感，但对精确匹配很弱。用户问“BRD-2024-0312 这个需求的状态”，这是个精确的编号，向量检索可能完全找不到。类似的还有人名、产品型号、订单号这些，光靠向量不够。

• 混合检索的取舍：为了弥补上面这个问题，通常会把向量检索和关键词检索结合起来。但两边的结果怎么融合？权重怎么设？不同场景可能需要不同的策略。

• top-k 选多少：检索返回多少条结果？选少了可能漏掉关键信息，选多了塞给模型一大堆内容，它可能反而被干扰。而且返回越多，后续处理的成本也越高。

• 结果重排序：向量相似度高的，不一定是最相关的。很多时候需要再加一层重排序（Reranking），用更精细的模型对检索结果重新打分排序。这一步能明显提升最终效果，但也增加了延迟和成本。

• 召回了但不该用：检索到的内容不一定都该用。有些可能是过时的版本，有些可能相关度其实不够，有些可能用户没有权限看。在塞给模型之前，还需要做一轮过滤和筛选。

5. 会话记忆

• 上下文要带多少：用户聊了 20 轮，你把所有历史对话都塞给模型？Token 成本扛不住，模型也容易被早期不相关的内容干扰。但如果只带最近几轮，又可能丢失重要的上下文信息。

• 记忆的压缩和摘要：一种做法是对历史对话做摘要，提取关键信息，用摘要代替完整的历史记录。但摘要过程本身可能丢失细节，摘错了后面就全错了。

• 长期记忆：有些场景需要跨会话的记忆。用户上周问过的问题，这周再来的时候系统还能记得。这涉及到记忆的持久化存储和检索，又是一套单独的机制。

• 记忆的更新和遗忘：用户在对话中纠正了之前的信息，系统得能更新记忆。有些过时的信息需要遗忘，不能一直带着。这些都需要额外的逻辑来处理。