1. 从一个真实困惑说起为什么你的AI助手总在“编答案”很多人第一次接触大语言模型时都会经历一个相似的阶段问它一个专业问题它回答得头头是道语气笃定结构清晰但等你拿去和权威资料一对照发现里面有一半是它“编”出来的。这种现象在圈子里有个专门的说法叫“幻觉”。它不是模型故意骗你而是因为模型本质上是在做“下一个词的概率预测”它并没有一个内置的、可随时查阅的事实数据库。我最早踩这个坑是帮一个做法律咨询的朋友搭一个内部问答工具。他手里有几千份合同模板和判例摘要想让模型直接回答“这类条款一般怎么写”。结果模型给出的条款引用案号是假的法条编号也是错的但读起来特别像真的。那一刻我就意识到光靠模型自己脑子里的“记忆”是不够的必须给它配一个能随时翻查的资料库。这个思路就是现在大家都在聊的知识库和RAG。所谓知识库你可以把它理解成一个专门整理好的、结构化的资料仓库。它可以是几万份文档也可以是一套产品手册甚至是你自己整理的笔记。而RAG全称是检索增强生成核心逻辑特别朴素先找资料再据此回答。模型不再凭空回忆而是先去知识库里检索出最相关的几段内容然后把这些内容作为“参考材料”塞进提示词里让模型基于这些材料来组织答案。这样一来答案有据可查幻觉大幅降低而且还能给出引用来源。这套东西适合谁如果你是开发者想给自己的应用加一个“懂业务”的问答能力如果你是产品经理在评估要不要做企业知识库或者你只是一个普通用户好奇为什么有些AI回答得那么准——那这篇内容就是写给你的。我会从设计思路、核心细节、实操落地到问题排查把整个链路拆开讲清楚尽量让你看完就能动手试。2. 整体设计思路为什么是“先检索再生成”2.1 不微调模型而是外挂一个“参考书库”一提到让模型懂某个领域的知识很多人第一反应是“微调”。微调确实有用但它有几个现实问题。第一成本高你需要准备大量高质量的问答对还要租算力跑训练。第二更新慢今天新出了一份文档微调过的模型不会自动知道你得重新训练。第三微调后的模型依然可能幻觉因为它学到的是一种“风格”和“倾向”而不是精确的事实索引。RAG的思路完全不同。它不动模型本身而是在模型外面套一层检索系统。你可以把模型想象成一个很会写文章但记性不太可靠的写手知识库就是他的资料柜。每次写之前先让他去资料柜里翻出相关的几页摆在桌面上然后照着这几页写。资料柜可以随时增删改写手的能力不用重新培训。这个设计最大的优势就是灵活和可追溯。你改了知识库里的内容下一次问答立刻生效答案里引用了哪几段也能明确标出来。从工程角度看RAG把一个大问题拆成了两个相对独立的部分检索和生成。检索负责“找得准”生成负责“说得好”。这两部分可以分别优化互不干扰。比如检索效果不好你可以换嵌入模型、调分块策略生成效果不好你可以换更大的模型、改提示词。这种解耦让整个系统更容易调试和维护。2.2 检索和生成的分工边界在哪里很多人刚开始做RAG时容易把两件事混在一起既希望检索能理解复杂语义又希望生成能自己判断资料对不对。实际上一个健康的RAG系统里检索的职责是召回也就是尽可能把相关的片段都找出来宁可多找一点也别漏掉关键信息。生成的职责是精炼和表达它要在给定的材料里筛选、整合、组织语言而不是自己去补充材料里没有的事实。这个边界划清楚之后很多设计决策就顺了。比如分块的时候块可以切得稍微小一点让检索更精准但块与块之间要保留一定的重叠避免上下文被切断。再比如提示词里要明确告诉模型“只根据以下材料回答如果材料里没有就说不知道。”这句话看起来简单但能挡掉一大半幻觉。还有一个容易被忽略的点检索和生成之间需要一个“重排序”环节。初步检索可能会召回几十个片段但真正有用的可能只有三五个。如果一股脑全塞给模型不仅浪费上下文窗口还会引入噪声干扰模型判断。所以通常会在检索之后加一个重排序模型对候选片段做一次精细打分只把最相关的几条送给生成模型。这个环节对最终效果的影响往往比换一个更大的生成模型还明显。2.3 知识库不是“扔进去就行”预处理决定上限我见过不少项目知识库搭得很快把PDF往系统里一传就完事了结果问答效果一塌糊涂。问题往往出在预处理上。原始文档里可能有页眉页脚、表格、图片、多栏排版直接按固定字数切块切出来的内容可能是半句话加一个页码检索出来根本没法用。所以知识库的建设核心工作量其实在预处理。你需要把文档解析成干净的文本去掉无关的格式噪声识别出标题层级然后按照语义边界来分块。比如一份产品手册按章节切就比按500字硬切合理得多。表格要单独处理因为表格里的信息用普通文本切块会丢失结构。图片如果包含关键信息还得做图文理解把图里的文字提取出来。这些预处理步骤听起来琐碎但它们直接决定了检索的上限。检索是在块级别做的如果块本身质量差后面再好的模型也救不回来。我的经验是在预处理上花的时间至少应该和调模型的时间一样多。很多人反过来模型换了好几个效果还是不行最后发现是分块没做好。3. 核心细节解析把“找资料”这件事做扎实3.1 文档解析与分块切得好检索就成功了一半分块是RAG里最容易被低估的环节。块太大检索出来的内容包含太多无关信息模型容易被带偏块太小上下文不完整模型可能理解错意思。那到底切多大合适没有一个绝对的数字但有一些经验规律。一般来说中文文本的块大小在300到800字之间比较常见。如果是技术文档、法律条文这种信息密度高的可以切小一点300到500字如果是叙述性的内容可以切大一点500到800字。更重要的是块与块之间要保留10%到20%的重叠防止一个完整的句子或段落被硬生生切断。比如你按500字切那下一块可以从第450字开始这样边界处的信息不会丢。但比大小更关键的是切在哪里。理想情况下应该按语义边界切比如一个完整的段落、一个小节。很多工具支持按标题层级切先识别出文档的章节结构然后在章节内部再按长度切。这样切出来的块语义完整性好很多。我试过同一份文档按固定长度切和按标题切检索准确率能差出两成。还有一个细节给每个块加上元数据。比如它来自哪个文档、哪个章节、第几页。这些元数据在检索时可以用来过滤比如用户问的是“2024年的政策”你就可以只检索2024年的文档。元数据还能在生成时作为引用来源展示增加可信度。3.2 嵌入模型的选择把文字变成可比较的向量检索的本质是计算相似度。计算机不认识文字所以需要把文字转换成向量也就是一串数字。这个转换过程叫嵌入用的模型叫嵌入模型。嵌入模型的好坏直接决定了“找得准不准”。选嵌入模型时有几个维度要考虑。第一是语言支持如果你的知识库主要是中文那就要选中文表现好的模型不能直接用英文模型硬套。第二是维度向量维度越高表达能力越强但存储和计算成本也越高。常见的有768维、1024维、1536维。第三是最大输入长度有些模型只能处理512个token那你的块就不能超过这个长度。实际选型时我一般会先拿一批真实问题做测试。准备20到30个问题每个问题人工标注出最相关的几个块然后看不同嵌入模型的召回率。召回率就是“该找出来的有没有找出来”。这个测试花不了太多时间但能避免后面大量返工。有些模型在通用 benchmark 上分数很高但在你的垂直领域里可能表现一般所以一定要用自己的数据测。另外嵌入模型和生成模型可以是不同的。嵌入模型通常比较小跑起来快成本低生成模型大负责最终表达。两者分开选各自优化灵活性更高。3.3 向量数据库存得快查得准向量算出来之后需要存起来并支持快速检索。这就是向量数据库的作用。它的核心能力是“近似最近邻搜索”也就是在几百万甚至上亿个向量里快速找到和查询向量最接近的那几个。选向量数据库时要考虑几个点。第一是规模你是几千个块还是几千万个块规模不同选型差别很大。小规模用内存索引就够了大规模需要分布式方案。第二是过滤能力能不能在向量搜索的同时按元数据过滤比如“只搜某个文档类型”。第三是更新频率知识库是每天更新还是每月更新频繁更新对索引结构有要求。我个人的经验是刚开始不要过度设计。几千到几万个块用轻量级的本地库完全够用部署简单调试方便。等数据量真的上来了再考虑迁移到更重的方案。很多项目一上来就搭复杂的分布式架构结果数据量根本没到那个级别反而增加了维护负担。还有一个实操细节向量和原始文本要一起存。检索出来的是向量ID你需要根据ID去取回对应的文本块送给生成模型。这个映射关系要维护好别到时候检索到了却找不到原文。3.4 提示词设计让模型“照着材料说”检索做完接下来就是把材料交给模型。这一步的关键是提示词。提示词写得好模型就老老实实基于材料回答写得不好模型又开始自由发挥。一个有效的提示词通常包含几个部分。首先是角色设定告诉模型“你是一个严谨的问答助手”。然后是任务说明“请根据以下参考资料回答问题”。接着是约束条件“只使用参考资料中的信息如果资料中没有相关内容请明确说明无法回答”。最后才是参考资料和用户问题。这里有个技巧把参考资料放在用户问题之前并且用明确的分隔符标出来比如用三个井号或者XML标签。这样模型能清楚知道哪部分是材料哪部分是问题。另外可以要求模型在回答时标注引用来源比如“根据文档A第3节”。这不仅方便用户核实也能倒逼模型更认真地对待材料。还有一个常见问题材料太多超出模型的上下文窗口。这时候要么减少检索返回的块数要么用重排序只保留最相关的几条。不要硬塞塞太多反而会让模型抓不住重点。4. 实操过程从零搭一个最小可用的RAG系统4.1 环境准备与依赖安装动手之前先把环境理清楚。你不需要一开始就上很重的框架用Python加上几个核心库就能跑起来。我建议的准备清单是这样的Python 3.9以上太老的版本有些库不支持。一个嵌入模型可以用开源的也可以用API。开源的好处是本地跑数据不出域API的好处是省事效果通常也不错。一个向量库轻量级的本地库就够比如基于FAISS或者类似的方案。一个生成模型同样可以选开源或API。如果只是验证流程用API更快。文档解析库处理PDF、Word、Markdown等格式。安装的时候注意版本兼容。嵌入模型和向量库之间有时候会有版本要求装之前看一眼文档。我踩过一次坑嵌入模型输出的向量维度是768但向量库初始化时默认设成了1536结果写入的时候直接报错。这种问题不复杂但排查起来费时间提前对齐好能省事。4.2 文档入库解析、分块、向量化、存储这是整个流程里最基础也最重要的一步。我把它拆成四个动作。第一步是解析。把各种格式的文档统一转成纯文本。PDF要处理扫描件和文字版两种扫描件需要OCR。Word要提取段落和标题样式。Markdown相对简单但要注意代码块和表格。解析完之后最好人工抽查几份看看有没有乱码或者格式丢失。第二步是分块。按照前面说的策略先按标题层级切再在章节内按长度切保留重叠。每个块生成一个唯一ID并记录元数据来源文档、章节标题、页码、块序号。第三步是向量化。把每个块的文本送进嵌入模型得到向量。这一步可以批量做提高效率。注意有些模型对输入长度有限制超长的块要先截断或者再切分。第四步是存储。把向量、块ID、元数据、原始文本一起写入向量库。写入之后做一次简单的检索测试随便输入一个问题看看能不能召回合理的块。这一步能提前发现很多问题比如向量维度不匹配、元数据没写进去、索引没建好。4.3 检索与重排序把最相关的几条挑出来用户提问之后系统要做的第一件事是把问题也向量化然后用这个向量去向量库里搜。搜的时候可以设置返回条数比如先返回20条候选。这20条是按向量相似度排的但相似度高不代表一定相关所以需要重排序。重排序可以用一个专门的模型它对“问题-片段”对做精细打分比单纯的向量相似度更准。重排序之后取前3到5条作为最终的材料。这个数量不是固定的要看块的大小和模型的上下文窗口。如果块比较小可以多取几条如果块很大就少取几条。这里有个实操技巧如果检索结果里有多条来自同一个文档的相邻块可以把它们合并成一个更大的上下文这样信息更完整。但合并之后要注意别超过长度限制。4.4 生成与引用让答案有据可查最后一步是把材料、问题和提示词组装起来送给生成模型。模型返回答案后最好把引用的来源也一并返回。来源可以是从元数据里取的文档名和章节也可以是块ID。组装提示词的时候我习惯用这样的结构你是一个严谨的问答助手。请只根据以下参考资料回答问题。 如果参考资料中没有相关信息请直接说明“根据现有资料无法回答”不要编造。 参考资料 [1] 块内容 [2] 块内容 [3] 块内容 问题用户的问题这个结构简单直接实测下来能有效降低幻觉。如果希望答案更结构化可以在提示词里加一句“请分点作答”或者“请用一段话概括”。但不要加太多格式要求否则模型可能为了满足格式而牺牲内容准确性。生成之后可以做一个简单的后处理检查答案里有没有出现材料里没有的专有名词或数字。如果有标记出来人工复核。这个检查可以用规则做也可以用另一个模型做看你的资源情况。5. 常见问题与排查技巧实录5.1 检索不准该找的没找出来这是最常见的问题。表现是用户问了一个问题检索出来的块和问题关系不大导致模型回答“无法回答”或者答非所问。排查思路可以按这个顺序来。先看分块。把检索出来的块打印出来看看内容是不是完整的。如果块里全是半句话那肯定是分块出了问题。调整分块策略按语义边界切增加重叠。再看嵌入模型。拿几个典型问题手动看看最相关的块在向量空间里是不是真的离问题近。如果不是可能嵌入模型不适合你的领域。换一个中文表现更好的模型或者用你的数据微调一下嵌入模型。还要看查询本身。用户的问题可能很短比如“怎么退款”这种短查询向量化之后信息量少检索效果差。可以做一个查询扩展用模型把短问题改写成更完整的描述再拿去检索。比如“怎么退款”扩展成“用户申请退款的流程和条件是什么”检索准确率会明显提升。5.2 答案幻觉材料里没有模型自己编即使检索到了正确的材料模型有时还是会编。这时候要检查提示词。是不是没有明确说“只根据材料回答”是不是材料太多模型分不清哪些是参考哪些是问题把提示词改得更严格加上“如果材料中没有就说不知道”的约束。另一个原因是材料本身有矛盾。比如两份文档对同一个问题说法不一致模型可能会自己“调和”编出一个中间答案。这种情况需要在预处理阶段做去重和冲突检测或者让模型把矛盾点指出来而不是强行统一。还有一种情况是模型太“聪明”。有些大模型倾向于给出完整、流畅的答案即使材料不完整它也会补全。这时候可以换一个更“听话”的模型或者在提示词里强调“宁可回答不完整也不要编造”。5.3 速度太慢检索和生成的时间都花在哪了RAG系统的延迟主要来自三块检索、重排序、生成。检索通常很快几毫秒到几十毫秒。重排序如果用的是大模型可能几百毫秒。生成最慢取决于模型大小和输出长度几秒到十几秒都正常。如果整体太慢先看生成。能不能换一个更小的模型能不能限制输出长度能不能流式输出让用户先看到部分内容这些都能改善体验。检索和重排序的优化空间也很大。向量库的索引类型、检索的候选数量、重排序的批量大小都会影响速度。我一般会先保证效果再逐步压速度。不要为了快而牺牲准确率那样用户体验更差。5.4 知识库更新新文档怎么加旧文档怎么删知识库不是一次建好就完事了。新文档要加旧文档要删文档改了要更新。这些操作要设计好流程。新增文档相对简单解析、分块、向量化、写入就行。但要注意如果新文档和旧文档有重叠内容检索时可能召回重复信息。可以在写入前做一次去重或者用元数据标记版本来过滤。删除文档时要同时删除对应的向量和元数据。如果向量库不支持按元数据批量删除就要维护一个映射表先查到向量ID再删。这个映射表要定期备份别丢了。文档更新最麻烦。如果只是小改可以删旧块加新块。如果改动很大建议整份文档重新处理。更新之后最好跑一遍回归测试用之前的问题集看看检索和回答有没有变差。5.5 常见问题速查表问题现象可能原因排查动作解决方向检索结果不相关分块不合理打印检索块看完整性按语义边界切增加重叠检索结果不相关嵌入模型不匹配人工检查向量相似度换中文模型或领域微调答案编造事实提示词约束不足检查提示词是否明确限制加“只根据材料回答”约束答案编造事实材料有矛盾检查材料一致性去重、冲突检测回答“无法回答”检索没召回看召回块是否包含答案调整检索条数、查询扩展响应速度慢生成模型太大测各阶段耗时换小模型、流式输出更新后效果变差新旧内容冲突对比更新前后检索结果版本过滤、回归测试6. 一些踩坑之后的个人体会做RAG这段时间我最大的感受是检索的质量决定了系统的上限生成的质量只决定了下限。很多人把精力花在换生成模型上从一个小模型换到一个大模型效果提升有限。但如果把分块和嵌入模型调好同样的生成模型效果能上一个台阶。另一个体会是不要追求一步到位。先搭一个最小可用的版本用真实问题测找到最痛的瓶颈再针对性优化。我见过太多项目一开始就设计得很复杂结果卡在某个环节迟迟上不了线。RAG的好处就是可以增量迭代今天改分块明天换嵌入后天调提示词每次改动都能看到效果变化。还有一点知识库的内容质量比技术方案更重要。如果原始文档本身就有错别字、格式混乱、信息过时再好的RAG也救不回来。在入库之前花时间清洗数据比后面调参划算得多。最后分享一个小技巧建一个“问题-答案-引用”的测试集每次改动之后跑一遍看准确率和召回率的变化。这个测试集不用很大二三十条就够但能帮你避免“改了一个地方坏了另一个地方”的情况。我现在的习惯是任何改动之前先跑测试集改动之后再跑一遍对比数据说话不靠感觉。