★ FEATURED ARTICLE 上个月某开发者跟我说他们要把公司内部的几十份产品手册做成一个“智能问答机器人”一开始直接用大模型套提示词结果模型对常见问题答得不错换个问法就开始一本正经地编答案。我当时只给了一个建议先别急着微调把RAG跑通再说话。RAGRetrieval-Augmented Generation检索增强生成现在几乎是小白程序员掌握大模型应用最友好的技术路线不用训练、不用高端显卡只要会写Python、懂一点数据处理就能让大模型“借用”你的私有知识回答问题。这篇“收藏版”就是把RAG从原理到落地、从小白到进阶的完整路径一次讲清楚。1. 先聊透彻为什么大模型需要RAG这根“外接U盘”1.1 大模型的简答题成绩为什么忽上忽下你肯定遇见过这种场面问大模型“公司年假怎么休”它能给你一套非常流畅的答案但里面的具体天数、审批流程和你公司制度完全对不上。原因很简单——通用大模型训练时根本没见过你公司的内部文档它的所有知识都来自公开语料。当问题超出它的知识范围它就只能靠“语言惯性”编一个听起来合理的回答这就是所谓的“幻觉”。以前解决幻觉的办法是让模型说“不知道”但模型很难判断自己到底知不知道。更靠谱的思路是既然它不知道那就把相关资料翻出来喂给它。就像考试开卷一样允许它查资料答案自然就有了依据。RAG做的就是这件事先从你的文档里检索出和问题最相关的内容再把内容拼进提示词交给大模型让它基于这些内容作答。这个思路对小白程序员特别友好因为它不改变大模型本身的参数。大模型还是那个大模型只是你给它加了一个“外接知识库”就像一个外接U盘。资料更新、换业务、加新文档只需要改库存模型权重完全不用动。1.2 微调、长上下文、RAG三选一怎么选网上讨论这问题时总有人争论微调和RAG谁更强。其实它们解决的侧重点不一样。微调是让模型“学会某种风格或能力”比如让模型模仿客服语气RAG是让模型“知道某份资料里的信息”比如回答时引用你的规章制度。两者不冲突甚至可以同时用。方案是否需要训练知识更新速度硬件要求小白上手难度主要风险全量微调是慢每次都要重训高普通显卡跑不动高过拟合、灾难性遗忘轻量微调是但参数少仍然要训练中等中需要大量高质量问答对RAG否快改文档即可低CPU也能跑低检索质量决定答案上限超长上下文否相对快低但费用随长度增加低成本高、长文信息密度低、易遗漏另一个常见的诱惑是“直接用超长上下文把整本文档塞进去”。比如新推出了一些支持百万级token的模型看起来能把几十万字全部塞进去省掉检索。但这样做有三个问题一是成本按token算每次都完整读一遍长文本非常贵二是一旦文本过长模型对中间部分的事实记忆会变差反而不如“只读几段最相关的”效果好三是文档一旦更新你所有的会话都要重新准备上下文很不灵活。所以对多数实际业务场景RAG依然是性价比最高的默认选项。2. 把RAG拆成零件检索、增强、生成到底在干什么2.1 离线准备文档切块与向量化RAG流程分两段离线准备索引在线回答问题时检索。离线准备的第一步是读文档比如PDF、Word、Markdown、HTML统一抽成纯文本。但原始文本往往太长不能整个塞进向量库所以要切块。切块没有唯一的“正确尺寸”。切太大会混入无关信息检索时召回的片段不够精准切太小会丢失上下文模型看到的片段缺少前后逻辑。我通常从“一句话大概20到50个字”出发把块大小设在300到800字之间重叠100字左右。重叠是为了避免把一个完整的句子或段落从中间截断让关键信息同时出现在相邻两块里。处理完文本块后要把每个块转成向量。怎么转用一个嵌入模型Embedding Model把文本映射成一个高维向量比如几百到几千维的浮点数数组。这个嵌入模型是专门训练过的它的核心能力是让“意思相近的句子在向量空间里的距离也相近”。比如“年假怎么申请”和“休假流程是什么”这两个句子虽然字面差异很大向量距离却很近。2.2 在线流程用户提问后发生了什么当用户提出一个问题在线流程同样要把问题做一次向量化得到问题向量。然后拿着这个向量去向量数据库里做相似度搜索找出距离最近的前K个文本块。这里K就是你要召回的数量通常取3到10。召回的顺序会影响最终答案最相关的排前面。拿到K个文本块后把它们拼接成一段“参考资料”再连同用户问题一起放进提前设计好的提示词模板里抛给大模型生成最终回答。这一步就是“增强生成”。提示词模板很关键它会告诉大模型只许根据以下资料回答资料中没有的信息不要脑补如果答不出来就直说。2.3 一个具体类比图书馆管理员帮你查资料想象一下你走进一个超大图书馆直接问管理员“这本书里有没有提到某产品参数”。如果管理员不查目录凭记忆瞎答就会幻觉。RAG相当于给管理员配了一个智能检索系统先根据你的问题关键词搜图书索引快速锁定几本最相关的书翻到具体页码然后把那几页的内容放在桌上给你看你再根据这些内容写出答案。你不需要管理员把整本书背下来也不需要管理员重新学习所有书的内容只需要他每次按你的问题去翻书。你的文档就是图书馆的藏书向量数据库就是图书索引卡嵌入模型负责把问题翻译成索引卡能识别的编码。这个类比几乎能对应RAG的每一步。3. 从零搭一个最小RAG系统代码骨架与跑通路径3.1 准备数据从几份Markdown或TXT开始我建议别一上来就搞PDF解析PDF里的表格、页眉页脚、图片文字都会带来一堆麻烦。先用几个干净的TXT或Markdown文件把内容整理成“产品手册第一章”“产品手册第二章”这样的结构把RAG链路跑通。数据量不用多20到50个小文档就够演示。切块这一步可以写得很简单def chunk_text(text, chunk_size500, overlap100): if not text: return [] chunks [] start 0 text_len len(text) while start text_len: end start chunk_size chunks.append(text[start:end]) if end text_len: break start end - overlap return chunks这里chunk_size按字符数算中文下一般500个字符对应几百字的段落比较合适。overlap取100保证首尾信息有衔接。如果你文档里已经有明显的标题和章节结构更好的是按标题层级切块保留标题作为每个块的元数据后面对检索做过滤很有用。3.2 向量化和检索的核心流程向量化需要调用嵌入模型。现在主流的做法是调用某个大模型厂商提供的Embedding接口也可以本地跑开源嵌入模型。作为最小Demo我建议先调用现成API把返回的向量存进任意一个支持向量检索的数据库中。以下是核心流程的示意代码不依赖任何特定产品# 示意代码请根据你实际选用的嵌入接口和向量库调整 def embed_text(text): # 调用嵌入接口返回一个长度为N的列表 return embedding_api.encode(text) # 建索引 def build_index(documents): collection vector_store.create_collection(manual) for doc in documents: chunks chunk_text(doc[text]) for idx, chunk in enumerate(chunks): vec embed_text(chunk) collection.add( idf{doc[id]}_{idx}, vectorvec, payload{text: chunk, source: doc[source]}, ) # 检索 def search(query, top_k5): query_vec embed_text(query) hits vector_store.search(query_vec, top_ktop_k) return [hit.payload[text] for hit in hits]需要注意embed_text这个函数会被反复调用。如果你要处理几千个文档建议批量调用一次性传一批文本进去既能省时间也能避免触发接口频率限制。向量库侧一定要做持久化存储不要把向量只放在内存里否则程序一重启索引就丢了。3.3 和生成器接缝提示词模板与输出最后把检索到的文本交给大模型生成回答。这里最容易被忽略的是提示词模板的写法。我会用这样一段固定格式SYSTEM_PROMPT 你是一个基于参考资料回答问题的助手。请严格遵循以下规则 1. 只依据“参考资料”中的内容回答不得使用资料之外的知识。 2. 如果参考资料中没有明确信息直接回答“资料中没有提到”不要编造。 3. 回答时可以使用资料中的原文但尽量用通顺的语言重新组织。 def ask(question): hits search(question) context \n\n.join(hits) user_prompt f 参考资料 {context} 问题 {question} response llm_chat(SYSTEM_PROMPT, user_prompt) return response第一次跑通时别急着调参先拿三五个“标准问题”试一下。比如“产品X支持哪些格式导出”“系统要求的最低内存是多少”——这些问题都能在文档里直接找到答案。如果回答正确说明链路没问题如果答错了先看看检索出来的几段文本里到底有没有正确答案。如果检索结果本身就不相关问题出在检索侧如果检索结果相关但大模型回答错误问题大概率出在提示词或生成侧。4. 小白最容易踩的五个坑切块、元数据、提示词和评估4.1 切块不是切西瓜长度和重叠率要一起调很多小白第一次切块时喜欢照搬教程里的500和100结果遇到自己的文档就翻车。比如有些技术文档一个表格占了500字切成两块后表格结构断了检索到的内容缺失一整列。这时候你需要针对文档特征调整切块策略。一个非常有效的做法是“按语义切块”而不是纯按字符切。先判断文本里有没有标题、段落标记、列表项、表格行尽量让每个块是一个完整的语义单元。如果文档有清晰的Markdown标题就按标题把章节分成块块太大再递归切。如果文档是纯文本没有结构可以稍微增大重叠比例到20%左右。经验法则块越小检索精准度越高但上下文越碎块越大上下文越完整但可能混入噪声。你可以在200到1000字之间多试几个值找到准确率的拐点。4.2 不加元数据过滤检索结果就像超市乱堆只做向量相似度检索会遇到一个尴尬场景用户问的是“产品A的安装步骤”结果召回的10段文本里有6段都在讲产品B。原因很简单不同产品的文档内容很像向量空间里距离很近。这时候就要给每个文本块打标签比如产品名称、文档类型、版本号、适用业务线然后检索时先按标签过滤再做向量搜索。具体实现上向量数据库一般支持filter参数。比如用户明确提到“产品A”你可以先把产品字段等于“A”的文档过滤出来再在范围内做相似度搜索。这一步能大幅提升准确率。如果你的系统需要支持“指定产品/指定模块/指定版本”的问答建议在数据准备阶段就为每个块维护一个元数据字典。4.3 提示词里少了这句话答案质量差一截我见过不少RAG系统检索做对了但大模型给的答案依然很差。打开提示词一看只有一句“根据以下资料回答问题”没有任何约束。大模型看到资料里有相关信息但资料外的常识也可能混进回答里导致答案超出范围。至少要在提示词里加三个约束一是“只依据参考资料回答”二是“如果参考资料没有相关信息请明确回答不知道或用资料中已有的近似信息做推断但必须说明”三是“不要在回答中重复资料原文大段内容而是要提取有效信息”。对于专业场景还可以加一个“引用来源编号”让答案后面带上[1][2]这样的标记方便用户核验。这个技巧也叫“检索增强生成的可解释性”是生产环境落地时很重要的能力。4.4 向量数据库选型不用纠结先跑通再优化很多小白会在选型上消耗大量时间纠结到底用哪个向量数据库。我的建议是个人项目或最小Demo阶段在本地文件系统里用某种序列化方式把向量存下来或者直接用一个轻量级支持向量搜索的开源库就够了。只有当你需要处理百万级以上向量、要求毫秒级响应、需要高可用时才需要上分布式向量数据库。选型的关键指标无非是是否支持标量过滤、是否支持混合检索、持久化方式、运维成本、社区活跃度。但不管用哪个核心代码结构都一样建索引入库、查索引召回。先把一个最简单的方案跑通再因需替换成本远低于一开始就纠结架构。4.5 没有评估指标你只是在感觉里调优RAG的评估是很多人最后才想的问题但恰恰是最该提前做的事情。你改了切块参数、调了召回数量怎么知道是变好了还是变差了靠肉眼一个个问题看根本不可靠而且没法自动化。最基础的评估方法是准备一组测试题每条题目包含问题、标准答案、应该命中哪几个文档。然后跑一遍RAG计算三个简单指标答案正确率、检索命中率、忠实度。答案正确率可以直接让大模型打分也可以人工打分检索命中率看召回的K个文本块里是否包含标准答案所在的块忠实度看最终答案是否完全基于检索内容、有没有额外的编造内容。有了这套评估集你就能用数据驱动的方法调参而不是靠感觉。5. 进阶升级混合检索、重排序、缓存一个都不能少5.1 关键词向量混合召回覆盖面更稳纯向量检索对“语义相似”处理得很好但它有一个弱点对精确词项匹配不敏感。比如用户问“有效期多久”文档里写的是“质保期12个月”语义相近的倒还好但如果用户直接搜一个专有名词“ABC-X100型号”向量模型偶尔会“想当然”地把它跟别的型号混淆。这时候关键词检索就非常有用了。混合检索的做法是同时跑两路召回一路向量检索捕捉语义相关的长尾说法一路BM25这类关键词算法捕捉精确术语、型号、编号。然后把两路结果合并去重再统一打分排序。这样做的好处是召回覆盖面更稳不容易漏掉关键信息。代价是工程复杂度增加了但代码量其实不大值得在规模稍大的业务里采用。5.2 重排序模块用交叉编码器校准相关度向量检索用的是“双塔”模式问题向量和文档向量是两个独立编码器算出来的虽然快但交互信息不足。举例来说问题“怎么退款”和文档“退款流程不支持”看起来语义相关但实际意思是负向的。重排序者Reranker会把问题和每一个候选文档拼在一起送入一个交互式模型输出相关度分数。这个分数比向量距离要准确得多。引入重排序的流程是向量检索先召回20到30个候选片段然后用重排序模型精排取前5个交给大模型。第一次召回可以粗一点因为最终答案只取决于精排后的几个片段。重排序会增加一些延迟但效果提升非常明显尤其是当你召回的文本块里混着很多相似但不准确的片段时。个人实测里加入重排序后答案正确率往往能提升10到20个百分点。5.3 缓存与文档更新让RAG系统越用越顺手RAG系统的成本主要在嵌入调用和生成调用。同一类问题反复问每次都重新检索、重新生成很浪费。可以做一个语义缓存把用户问题向量化先在缓存库里搜索如果跟之前的问题相似度超过某个阈值就直接复用上一次的回答。这样做能大幅降低响应延迟和成本特别适合客服、答疑这类重复度高的场景。文档更新则是另一个常被忽视的问题。你的知识库不可能永远不变新版本手册发布后旧内容还留在向量库里会导致新旧信息混在一起。简单的做法是给每个文档块标记版本号查询时过滤旧版本或者后台定期重建索引并切换。生产环境里建议把文档更新做成后台任务每次更新后重新处理增量文档并同步清理不再使用的旧向量。6. 最后说点实用心得怎么从Demo做成产品6.1 最小可行性实验要做到什么程度做RAG Demo不要求高大上但一定要跑通闭环。至少要做到给系统一份你自己的文档问一个在文档中能明确找到答案的问题系统能给出正确回答并且你能清楚说出这个回答依据了哪段资料。如果这都做不到后续优化无从谈起。在此基础上第二个里程碑是“可控性”问一个文档里没有答案的问题系统会老实告诉你查不到而不是硬编。第三个里程碑是“可评估”你能用一套测试集量化回答准确率随便调一个参数后能说出涨了还是跌了。做到这三点你就算真正入门了后续加功能都是锦上添花。6.2 迭代路线图与常见的取舍判断我建议从小项目做起的顺序是这样先做最小链路再评估效果然后逐步加元数据过滤、混合检索、重排序。每一步都重新上线评估集看看提升是否值得那部分复杂度。千万不要一上来就全套上否则出了问题都不知道是哪个模块引起的。关于取舍我的经验有这些如果文档量少于一两千段优先关注切块策略和提示词质量向量库随便选如果文档量大但业务比较单一优先加元数据过滤而不是换更强的嵌入模型如果回答经常错但检索结果相关优先改提示词和生成参数如果检索结果本身就不相关优先做混合检索和重排序不要盲目换更大的模型。6.3 给收藏党的一句话提醒既然这是“收藏版”你很可能收藏完就吃灰。所以我想提醒别只收藏花半天时间把你手头随便一份工作文档跑通RAG。你会发现原理再复杂真正动手时障碍并没有想象中那么多。踩过几个坑之后你对大模型应用的理解就不再只是调API而是真正知道怎么让模型“用”你的数据。这一步跨过去后续不管是接新的知识库、做Agent还是做行业问答你都能比别人更快上手。
阅读完成 · 觉得有帮助？
