Ragent day-03 RAG

大模型的局限性局限性在智能客服中的表现幻觉问题编造不存在的产品功能误导用户知识时效不知道上周刚发布的新产品专业深度对复杂的技术问题回答肤浅私有数据不知道公司的退换货政策不可追溯用户问这个说法哪里写的答不上来RAG 架构让大模型开卷考试大模型懂语义但没有私有知识传统搜索有数据但不懂人话。能不能把两者结合起来这正是RAGRetrieval-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 流程小结阶段步骤做什么准备阶段离线Ingest导入原始文档Chunk切成小块Embed转成向量Index存进向量数据库运行阶段在线Retrieve检索相关文档Answer大模型生成回答总的来说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 成本扛不住模型也容易被早期不相关的内容干扰。但如果只带最近几轮又可能丢失重要的上下文信息。记忆的压缩和摘要一种做法是对历史对话做摘要提取关键信息用摘要代替完整的历史记录。但摘要过程本身可能丢失细节摘错了后面就全错了。长期记忆有些场景需要跨会话的记忆。用户上周问过的问题这周再来的时候系统还能记得。这涉及到记忆的持久化存储和检索又是一套单独的机制。记忆的更新和遗忘用户在对话中纠正了之前的信息系统得能更新记忆。有些过时的信息需要遗忘不能一直带着。这些都需要额外的逻辑来处理。