RAG 与向量知识库——让 Agent 有知识这是「Agent 工程化」系列的第六篇。上一篇 Memory 解决了记住用户但还有个空白用户问机票怎么退改签这个知识不在模型训练数据里也不在用户记忆里。这篇讲 RAG 与向量知识库——让 Agent 在回答前先查资料也就是让 Agent懂业务。幻觉现场答不上来的问题它选择编先看一个 AI 助手常干的尴尬事用户你好我想改签机票有什么费用吗 助手根据规定起飞前 24 小时改签免费24 小时以内收取 20% 手续费。 用户你确定这个政策哪来的 助手……其实是编的问题出在哪模型的训练数据里根本没有你们公司的退改签政策。它只是猜了一个看起来合理的答案——这就是幻觉。为什么猜因为 LLM 的本质是预测下一个词遇到没学过的内容它也会硬着头皮往下编。它不知道我不知道。那怎么办两条路把政策文档塞进训练数据再训一遍——贵、慢、改一次政策就要重训不现实让它回答之前先查资料——这就是 RAGRAG 是什么让 LLM 从闭卷变开卷RAGRetrieval-Augmented Generation检索增强生成的核心理念一句话不让模型背知识而是让它查知识。用考试打比方闭卷普通 LLM开卷RAG知识来源训练时背过的现场翻资料新政策不知道只能编查一下就知道答案准确性靠记性靠资料更新成本重新训练更新文档即可RAG 的工作流程就一句话提问 → 去知识库检索相关资料 → 把资料拼进提示词 → 让模型照着资料回答。用户提问: 改签费用把提问转成向量在向量库检索相关政策片段取最相关的 Top-K 段资料资料拼进提示词LLM 照着资料回答回答 引用来源注意最后一环回答要带上我从哪份资料得出的。这是 RAG 和瞎编最大的区别——有据可查。RAG 全链路四步走完整落地一个 RAG分建知识库和答问题两个阶段四个环节在线: 每次提问都走用户提问提问转成向量向量库检索 TopK拼进提示词LLM 生成回答离线: 建知识库 做一次政策文档切成小段 chunk每段转成向量存入向量数据库环节 1文档切分chunk政策文档动不动几千字模型上下文放不下整份得切成小段再入库。切得好不好直接决定后面检索准不准切法问题太大整章一刀切一段混入多个主题检索精度下降太小按句硬切上下文不完整答非所问合适按语义边界切200-500 token每段一个完整主题检索最准经验按标题/章节切别按字数硬切。改签手续费应该作为一个完整段落存在而不是被拦腰截成两半。环节 2向量化把每段文本转成一串数字向量这是 RAG 的核心魔法——让语义相近变成距离相近。想象把文本放进一个多维空间北京下雨和北京降雨的坐标挨得很近北京下雨和火箭发射离得很远。模型不用理解文字只需要比距离。北京下雨 → [0.31, 0.78, 0.12, ...] ← 近 北京降雨 → [0.30, 0.79, 0.13, ...] ← 近 火箭发射 → [0.87, 0.22, 0.54, ...] ← 远转换的工具叫Embedding 模型如 OpenAI 的 text-embedding-3 系列转换后存进向量数据库Chroma 入门 / FAISS / Milvus 生产。环节 3检索提问来了同样转成向量在库里找距离最近的 K 段defanswer_rag(question:str)-str:q_vecembed(question)# 1. 提问向量化chunksvector_db.search(q_vec,top_k3)# 2. 检索最相关的 3 段context\n.join(c.textforcinchunks)prompt(请严格根据以下资料回答问题资料没有提到的就说不知道\nf{context}\n\n问题{question})returnllm(prompt)# 3. 带资料生成top_k就是翻几页资料一般 3-5 段够用复杂问题可以调大后面讲动态 TopK。环节 4带资料生成关键在提示词怎么写“严格根据资料回答资料没有的就说不知道。”这一句就把照着答和自由发挥分开了。一个常见误区RAG ≠ 向量搜索很多人把 RAG 当成向量搜索这是误解。向量搜索只是 RAG 的检索环节RAG 的最终产物是生成。检索只是手段目的是让生成环节有资料可依向量搜索RAG输出一堆文本片段一个完整的、有据可依的回答终点找到资料基于资料回答问题用户视角“给资料”“给答案”记住 RAG 的名字检索Retrieval 增强Augmented 生成Generation——检索是为了增强生成。生产级考虑检索质量决定一切RAG 的答案质量90% 取决于检索质量——资料都没检索对模型再聪明也白搭。生产环境有四个关键优化1. 多路召回 RRF 融合单一向量检索有盲区语义相近但关键词不同向量路强关键词精确命中关键词路强。生产做法是两条路都查结果融合用户提问关键词检索 BM25向量语义检索RRF 融合排序取融合后的 TopKBM25关键词检索类似搜索引擎那套负责精确词命中向量检索负责语义相近两者结果用 RRF 算法合并互补短板。2. 元数据过滤知识库往往有多个版本/领域。要支持按元数据过滤比如只查 2026 版、只查退改签域避免旧政策干扰新政策。这也是动态 TopK的前置——不同域不同检索策略。3. 动态 TopK简单问题取 3 段就够“改签收费吗”复杂问题要 8 段“帮我比较三种改签方式”。可以按问题长度/意图动态调整top_k省 token 又提准确率。4. 检索评测指标怎么知道检索好不好两个常用指标召回率Recall正确答案被召回的比率。10 次提问8 次正确答案被捞到召回率 80%MRR平均倒数排名正确答案排第几。排第 1 得 1 分排第 2 得 0.5 分……均值越高越好指标问什么好差召回率正确答案捞到了吗越高越好MRR正确答案排得靠前吗越接近 1 越好这些指标在第 11 篇评测篇还会展开这里先知道检索质量是可以量化的。踩坑资料没检索到就明说不知道这是 RAG 最容易翻车的点也是最难养成的习惯场景用户问改签要手续费吗但知识库里根本没有这份政策。向量检索返回的片段相似度都很低——这时候模型大概率会硬编一个答案。解法加一道置信度闸——检索结果相似度低于阈值时让模型明说不知道绝不编resultsvector_db.search(q_vec,top_k3)ifresults[0].score0.7:# 相似度太低 资料里没有return抱歉这个问题我没在资料里查到建议联系客服确认。不知道是 RAG 的正确输出。用户得到不知道顶多失望一下得到编造的政策就是信任危机。宁可承认无知绝不假装知道——这是所有 Agent 系统的铁律。小结RAG 的本质让 LLM 从闭卷变开卷回答前先查资料全链路四步切 chunk → 向量化入库 → 检索 TopK → 带资料生成RAG ≠ 向量搜索检索是手段增强生成才是目的生产四件套多路召回 RRF 融合、元数据过滤、动态 TopK、检索评测召回率/MRR铁律资料没命中就明说不知道绝不编记忆 vs 知识Memory 记住用户RAG 懂业务——一个记人一个记事下篇预告到这里Agent 会动手工具、能记住用户Memory、还懂了业务RAG——但有个尴尬同一个改签问题每次来都从头推理一遍白白浪费 token还可能每次答得不一样。下一篇讲Skill 系统把成功处理过的问题沉淀成技能下次遇到同类问题直接调用——让 Agent 从成功经验里学习越用越聪明。本系列路线从 0 到 1Agent 是什么 → 手写最小 ReAct → Function Calling 与工具设计 → 上下文管理 → Memory 记忆系统 → RAG 知识库 → Skill 自学习 → 编排模式与多 Agent → 给 Agent 装护栏 → 生产部署与可观测 → 评测与回归