1. 先搞清楚RAG 到底解决了什么问题先抛个最直观的场景。你手头有一套内部的设备运维手册几百页包含各种故障码、报错日志和处置流程。你把它丢给大模型直接问“设备报 50212 错误怎么处理”大模型大概率会一本正经地胡说八道因为它训练的时候根本没见过你这份手册。这不是模型笨而是它的知识有“截止日期”和“学习范围”。对于组织内部的数据、最新的业务规则、实时行情、个人笔记这类信息模型天然是不知道的。RAG也就是检索增强生成就是冲着这个问题去的。它的核心思路很朴素模型不知道没关系我帮它查。在模型回答之前先把问题拿到一个外部知识库里检索一遍找出最相关的段落再把“问题检索到的资料”一起塞给模型让它基于这些资料来回答。我见过不少刚接触大模型开发的人一上来就想着微调觉得把文档喂给模型训练一遍模型就能“学会”这些知识了。其实大多数场景根本用不着微调RAG 更合适。原因也很简单RAG 不需要训练改资料只需要换数据库里的内容成本低、见效快而且回答时可以溯源用户能知道答案是依据哪段文档生成的这对企业应用来说非常重要。打一个不严谨但好理解的比方微调是让一个人把某门课背下来RAG 是考试时允许他带一本随时可以翻的参考书。背下来的好处是快速、不需要外部依赖但知识更新慢还可能背串翻参考书则灵活、准确、可核对代价是每次答题都要多花一点翻书的时间。这篇文章就是写给刚接触大模型开发、想做点落地东西的年轻同行看的。我尽量不堆概念把 RAG 的每个环节拆开讲包括为什么要切分、为什么要把文字转成向量、检索里的 top-k 到底怎么选、提示词要怎么写最后再给出一套可以直接上手改的 Demo 代码和一些真实踩坑记录。1.1 大模型的三个“先天缺陷”先说第一个缺陷就是知识滞后。模型训练完的那一刻它的知识就冻结了。你问它今年最新发布的一款芯片型号它如果训练数据里没有就只能靠推理去猜。猜对算运气好猜错就是常识性错误。很多业务场景恰恰对时效性要求很高比如客服系统要跟进最近的活动规则财经系统要参考当天行情这种场景不引入外部检索模型能力再强也白搭。第二个缺陷是缺少私域知识。企业内部资料、个人文档、行业报告这些东西根本不会出现在公开的训练语料里。大模型再大也看不到你公司那套遗留系统的接口文档。如果非要用大模型处理这类问题只有一个办法把知识在问答时实时“喂”给它。第三个缺陷是幻觉。模型在不确定答案时会基于概率生成一个看起来合理的回答而不是诚实地告诉你“不知道”。这个问题的本质是模型没有记忆只有概率。你在提示词里强行规定一万遍“不知道就说不知道”也拦不住它在资料不足时自行脑补。RAG 解决的恰好就是这三个问题。知识滞后通过检索最新资料来弥补私域知识通过把企业内部文档向量化来补全幻觉通过强制把回答建立在外挂资料上来压制。所以你会发现现在绝大多数面向生产环境的大模型应用骨架都是 RAG。1.2 微调和 RAG别再纠结选谁很多人会问我那我到底该微调还是用 RAG我的习惯是先看两个问题。第一知识是否需要频繁更新第二你需要的是“会用”这个知识还是“背诵”这个知识如果你们公司每个月都在调整产品价格和售后政策用微调就非常痛苦因为每改一次价格都要重新训练一次代价极高。RAG 只需要更新向量库里的文档数据库里旧文档换掉新文档写入同一套流程立刻能用新知识回答。如果需求是让模型模仿某种特定的语气、结构、业务逻辑比如让它学会按固定格式生成合同那微调可能更合适因为它调整的是模型的行为习惯不是知识。还有一个实战经验很多人觉得微调可以顺带注入知识其实效果并不好特别是知识量比较大的时候。微调适合注入“风格”和“格式”不适合注入“海量事实”。事实型知识最靠谱的载体就是检索库。所以我的建议是两者不是二选一而是可以组合。系统先通过 RAG 检索事实再通过微调让输出格式贴合业务需求。但如果你刚开始做项目建议从纯 RAG 起步把流程跑通再考虑要不要加微调。2. 拆解一遍一个典型 RAG 流程是怎么跑起来的RAG 的完整流程可以拆成四个环节知识库准备、向量化、检索、增强生成。我这里先把这个流程在宏观层面上讲清楚让你脑子里有个整体图景后面再讨论每一步的具体操作。想象你在一个巨大的图书馆里找资料。第一步图书馆得有书书要编好目录按主题分好类这就是知识库准备。第二步每本书都有一个索书号方便你按照检索规则快速锁定这里的索书号就是向量。第三步你带着问题到目录里去检索找到最相关的几本书这就是检索。第四步你坐在阅览室里把找到的资料摊开在桌面上边看边写答案这就是增强生成。很多教程喜欢一上来就堆概念什么 Embedding、向量数据库、相似度计算、top-k、召回率。其实你只要抓住图书馆这个类比RAG 的整个链路就通了。唯一和图书馆不同的是书变成了一段一段的文字索书号变成了一串高维浮点数检索方式从“按书名查找”变成了“按语义相似度匹配”。2.1 为什么要切分文档做过真实 RAG 项目的人都知道文档切分是第一步也是最容易翻车的一步。如果你把一本 100 页的手册当成一整段文字丢进向量库检索的时候就有个问题用户的提问通常只涉及手册里的一小部分内容你用一个短问题和一大段长文本去做相似度计算匹配出来的是“整个手册打开了”但真正相关的细节被淹没在了无关内容里召回精度极差。模型拿到了整篇长文反而找不出关键句子来回答。所以一定要切分。切分就是把长文档按照一定策略切成小段落比如按段落切、按固定长度切、按 Markdown 标题切、按代码的类和方法切。切分目标只有一个让每一段成为一个语义相对完整的独立单元。说得通俗点就是每一块豆腐要切得齐整下锅不至于散架。切分粒度怎么把握太长语义太杂检索不精准太短语义不完整可能单独看根本不知道在说什么。实际项目中我一般从一个经验值开始普通文本控制在 200 到 500 个字符之间相邻段落之间保留少量重叠比如 20 到 50 个字符的重叠避免一句话被拦腰截断。如果文档结构清晰比如有明确的章节标题我建议优先按结构切而不是按固定长度切。因为按标题切出来的段落语义边界天然完整效果通常比硬切好很多。还有一类文档是非结构化的比如 PPT 转出来的文字、PDF 扫描件。这类文档的问题更大因为格式信息丢了段落顺序可能还是乱的。我的处理方式是先做文本清洗把页眉页脚、年份单位、重复的标题都清理掉再做段落合并最后才切分。洗数据这个环节很容易被忽略但洗得好不好直接影响后面的检索效果甚至比选什么向量模型都重要。2.2 向量化的原理其实很简单切完之后每一段文字都要变成一个向量。向量是什么简单理解就是一组数字这组数字能代表这段文字在“语义空间”里的位置。比如“苹果”和“香蕉”这两个词的向量距离就很近而“苹果”和“汽车”的向量距离就远。把文字变成向量的过程叫 Embedding也就是嵌入。做这件事的工具通常是一个专门训练过的模型输入文字输出一串几百维甚至上千维的浮点数组。你不需要自己训练 Embedding 模型现在有很多开源的、预训练好的模型可以直接用。选模型有几个指标值得关注一是中文效果好不好这很关键很多英文模型跑英文很棒一碰上中文就抓瞎二是输出维度维度越高通常表示区分力越强但存储和计算成本也越高三是输入长度上限如果你的段落比较长模型装不下就得提前截断或者缩小切分粒度四是推理速度在线场景对延迟很敏感Embedding 模型不能选个动辄几百毫秒的。这里顺便说一个我踩过的坑一开始我图省事直接用某个通用 Embedding 模型去向量化专业的法律文书结果检索出来的内容驴唇不对马嘴。后来换成在法律法规语料上做过的领域适配模型效果立刻上来了。如果你的业务领域比较垂直比如医疗、法律、金融一定要留意有没有针对这个领域的 Embedding 模型或者自己用领域语料做一下适配微调。盲目的通用模型检索这一环就会拖后腿。2.3 向量数据库和检索流程向量化之后的文本段落需要一个地方存起来。普通的关系型数据库不太适合做高维向量的相似度检索所以一般会用专门的向量数据库或者在某些数据库的向量检索插件。向量数据库做的事情有两个核心存储向量以及在大规模向量集合里快速找到与查询向量最相似的 Top-N 个向量。这里我不展开讲具体的向量索引算法你只要知道一个概念就行暴力比对就是拿查询向量和库里每一个向量算一遍相似度结果最准但慢为了提速向量数据库引入了各种近似最近邻索引算法用一点精度换大量速度。实际项目里库的数据量到几十万条之后暴力检索基本不可接受必须上索引。建索引有几个参数会影响召回效果比如每个向量分多少个桶、搜索时遍历多少候选集这些参数通常要在召回率和速度之间做权衡。检索的时候把用户的问题也做一次 Embedding得到查询向量然后去数据库里找最相似的若干条。返回结果一般会带相似度分数或者叫距离。这里有个常见误解相似度分数只在同一个 Embedding 模型下有意义换了模型分数区间全变了不能拿来做横向比较。所以如果你调整了向量模型原来设定的阈值可能需要重新标定。检索环节还有几个细节要关心。第一个是 Top-K也就是返回多少条相关段落。K 太小可能漏掉关键信息K 太大又会把不相关的内容塞进上下文。第二个是相关度阈值低于某个相似度分数的不返回宁可答不上来也不要硬扯。第三个是排序问题有些项目会加一个重排序的步骤先用向量检索粗筛出一批候选再用更精细的重排序模型把最准确的几条排到前面。这个技巧对提升效果非常明显代价是多一次模型调用。2.4 增强生成把资料拼进提示词里检索到的资料怎么用这步叫增强。常规做法就是拼提示词系统提示词负责规定身份和行为检索结果按顺序嵌入其中最后是用户问题。模型拿到这些资料后基于资料内容生成回答。这一环节最容易被低估其实它大有门道。提示词写得好不好直接决定模型会不会照抄资料、会不会自己发挥、引用格式能不能保持规范。我常用的模板结构是先声明身份和任务再写明“请严格基于以下资料内容回答如果资料中没有相关信息请直接说不知道不要编造”接着把检索到的段落按来源编号列出来最后放用户的问题。把“基于资料回答”这个约束写得越死幻觉出来得越少。这里要提醒一个细节有些模型的指令遵循能力不强提示词写得太长、约束语义太大模型会失焦。解决办法是把关键约束放在提示词的开头和结尾中间放资料这样模型对首尾内容的注意力会更强。这个现象你写代码的时候可能感受不到但做几次对比试验就会明显发现。还有一点如果你有多个来源的资料最好在提示词里显式区分来源比如“【资料1】来自操作手册第3章”“【资料2】来自故障排查指南”。这样模型在回答中引用的时候你能顺着线索去核对回答是否真实基于资料也方便后续做答案溯源。3. 亲手搭一个最小可用的 RAG Demo理论讲得再多不如跑一个例子实在。我用一段简洁的 Python 代码把上面说的整条链路串起来读取文档、切分、向量化、存库、检索、生成。代码我尽量写得直白不依赖重量级框架方便你自己改动。3.1 准备环境和数据先准备一个 Python 环境需要安装以下依赖一个向量数据库的 Python 客户端一个 Embedding 模型库以及调用大模型的 SDK。我这里用虚拟库名代替不绑定具体商业产品。我习惯把流程分成两个阶段一个离线阶段负责把文档切分、向量化、写入库这个过程可以慢慢跑一个在线阶段负责实时接收问题、检索、调用模型这个过程对延迟敏感。这种分离设计很重要因为离线阶段你不想拖累线上服务而线上阶段又不希望每次都要重新加载全部文档。准备几段测试文本就行比如从网上找一篇设备使用说明的公开资料存成一个 txt 文件。我在这里虚构一个场景某公司内部有一套访客登记系统有一份使用手册里面提到了“访客预约、临时权限、超时提醒”等功能。一个小型 RAG 项目就从这种小文档开始完全够用别一上来就处理几十 G 的语料。3.2 切分与向量化入库文本读进来以后先用简单规则切分。我提供一个梗概性代码具体接口名可能因库而异但你照思路写就行def split_text(text, chunk_size300, overlap40): # 按字符滑动窗口切分并保留重叠 chunks [] start 0 while start len(text): end min(start chunk_size, len(text)) chunks.append(text[start:end]) if end len(text): break start max(0, end - overlap) return chunks chunks split_text(raw_text)切分完成以后把每段文字交给 Embedding 模型生成向量然后连上向量库写入记录。每一条记录至少包含两部分向量本身和原文段落。我还会额外存一个文档来源字段方便后续溯源。embeddings embed_model.encode(chunks) for chunk, vec in zip(chunks, embeddings): vector_db.insert(vectorvec, textchunk, metadata{source: visitor_manual_v1})写完之后可以做一个简单的自检随机拿一个段落里的句子去做查询看能不能通过检索把它自己找回来。这个自检能快速发现切分粒度是不是太碎、向量模型是不是选得不对。如果连自己都找不回来后面用户的问题更不可能找得准。3.3 实现检索与生成查询时把用户问题做同样的 Embedding得到查询向量再去向量库做相似度检索。这里选择的 Top-K 可以先取 3 到 5 条后面再根据实际效果调整。检索结果拼接成上下文放入提示词。query_vec embed_model.encode(question) results vector_db.search(query_vec, top_k4) context for i, r in enumerate(results, 1): context f【资料{i}】{r[text]}\n prompt f你是一个专业的客服助手。请严格基于以下资料回答用户问题。 如果资料中没有相关答案请直接回答“资料中未找到相关内容”不要编造。 {context} 用户问题{question} 然后调用大模型接口把 prompt 传进去拿到回答。整个在线过程通常能控制在 2 到 4 秒内其中大头是线上模型生成的时间检索本身一般只要几十毫秒。如果这个延迟你接受不了可以考虑把生成模型换成更小的蒸馏版本或者引入流式输出让用户看到逐字生成的效果体验会好很多。3.4 用一个测试集评测效果代码能跑通只是第一步你要验证效果好不好。我的建议是准备一个小的测试集比如 10 到 20 个问题每个问题提前写好标准答案然后跑一遍系统人工检查每个回答的质量。评测维度我一般分三个准确性也就是回答内容是否和标准答案一致完整性回答是否覆盖了用户关心的所有要点可溯源也就是回答是否能对应到检索出来的资料。其中第三个维度很容易被忽略但生产环境里特别重要。如果模型答得很好但完全不是来自你的资料那这样的答案在金融、医疗领域是不可用的因为没人能核实它的真实性。我跑过的很多项目里第一轮评估准确率往往只有五六成但别慌这是正常的。RAG 项目是一个调优循环发现问题、调整切分或提示词、重新检索、再评估。几轮下来准确率能做到八到九成。关键是你要有一个评测闭环不然改了半天都不知道改得是好是坏。4. 最容易踩的坑检索不准、答案混乱、耗时爆炸RAG 看着简单真正用起来以后问题会一个个冒出来。我在这里把最常见的几类问题集中整理出来附带我的排查思路希望你能少走一些弯路。4.1 切分粒度不当导致检索失准切分太粗比如整篇文档一大块查询时会算出“这篇文档相关”但模型看完整篇也找不到具体答案。切分太细比如一句话一刀切很多信息被切断连贯的上下文被击碎语义就残缺了。我遇到过一次很典型的案例某同事把合同文档按每 100 个字符切分结果“违约方应赔偿守约方因此遭受的全部损失包括但不限于律师费、诉讼费、保全费”这句话被拦腰截断检索时匹配到了半句话生成模型给出的答案就明显不完整。后来改成按语义边界切分也就是在句号、分号、自然段之后再合并到目标长度效果马上好了很多。实战里我一般会写一个“智能切分”函数先用正则把文本按段落拆开然后看每一段的长度超长的段落再按句子边界细切最终目标是每段控制在 200 到 500 字之间尽量不把逻辑上应该在一起的句子分开。这种切分方式比单纯按字符滑动窗口效果好得多。4.2 向量化和检索策略不佳这一类问题更隐蔽。常见的表现是相似度分数很高但返回的段落跟用户问题完全对不上。出现这种情况通常有两个原因一是 Embedding 模型不合适二是检索只用了向量匹配缺少关键词或者重排序的辅助。我有个建议如果你发现纯向量检索效果不行可以先做一个混合检索把向量检索和传统的关键词匹配都跑一遍然后合并结果去重。关键词匹配能精准命中包含特定术语的文档向量检索能命中语义相近但用词不同的内容两者互补效果好得多。这是很多系统在工程落地时的标配思路不要迷信任何一个单一方案。另外一个值得调试的参数是 Top-K。K 值太小召回信息不足模型要么答不上来要么瞎猜K 值太大无关信息混进来模型容易被干扰。我一般建议先设置一个中间值比如 K5然后观察答案的质量。如果答案有缺失说明关键信息可能没召回试着加大 K如果答案跑题说明无关信息太多试着减小 K。这种参数调整没有银弹只能靠评测来标定。4.3 生成阶段幻觉依然存在很多人以为装了 RAG 就不会有幻觉了这是误解。RAG 只能降低幻觉概率并不能根除。根因有两类一是检索回来的上下文本身就无关模型只好硬着头皮瞎编二是提示词里的约束不够强模型在资料不足时自作主张补充了信息。针对第二类问题提示词的写法要刻意强调“没有资料就承认不知道”。我的经验是这句约束要在提示词里出现两次开头一次结尾一次。另外如果你生成的答案面向客户可以考虑加一层校验生成完答案后再做一次检索比对看答案中的关键事实是否在资料里出现过。这个校验步骤成本不低但面对高要求的业务场景值得为准确性多花这一道工序。我还碰到过一种情况模型面对多段资料时把不同资料的信息混在一起造成事实冲突。比如一段资料说“保修期一年”另一段说“保修期三年”模型可能会绕开具体年限给一个模糊表述。这类问题要靠资料的层级管理来解决比如做元数据筛选让不同品类、不同年份的文档分开维护而不是一股脑塞进同一个库里。4.4 性能与成本失控很多人第一个版本用得很爽等到数据量涨到几百万条之后就崩溃了每次检索慢得让人无法容忍构建索引的时间越来越长GPU 资源的账单也在飙升。性能优化的核心是分层第一层是索引优化给向量库建合适的索引把搜索范围缩小第二层是缓存把高频问题和对应的检索结果缓存起来这种命中可以直接省掉检索和模型调用第三层是模型轻量化Embedding 模型可以换更小更快的版本生成模型可以走批量处理或流式输出。我见过一个很典型的优化案例某问答系统原本对每一个请求都实时调用大模型生成答案高峰期延迟高达十几秒。后来给最常见的一百多个问题做了缓存命中率达到百分之三十高峰延迟一下子降到两秒以内。RAG 项目做久了你会发现很多优化不是在算法层面而是在工程调度层面缓存往往是最便宜又最见效的手段。5. 把效果做上去的五个经验法则这一部分我把从多个项目里沉淀下来的调优经验总结一下按优先级排好。你会发现大多数改进不需要换复杂的模型而是把基础工作做扎实。5.1 先调数据再调模型不要一上来就换这个模型换那个模型。RAG 的效果上限很大程度上由数据质量决定。数据里的脏文本、切分不合理、元数据缺失这些问题不解决换什么模型都白搭。我见过一个项目把带页眉页脚和重复落款的 PDF 直接入库检索结果里充斥着“第 1 页”“本资料仅供参考”之类的垃圾内容怎么调提示词都没用。把数据清洗干净之后效果立竿见影。所以每次效果不好第一步永远是检查数据和切分而不是怀疑模型。这一步可以解决一半以上问题。5.2 让召回结果“尽量少但尽量准”对生成端来说输入太多垃圾信息反而是一种干扰。我倾向于把召回的数量控制在 3 到 5 条并且要求这 3 到 5 条必须真的相关。宁可召回少而准不要多而杂。很多教程喜欢堆top-K但实际业务里如果你给模型塞了八条相关信息其中五条是噪声模型很难分辨出哪些是真正可靠的。这也是为什么混合检索和重排序值得做先用多个渠道召回再用重排序把最准的几条顶到最前面。5.3 提示词是控制幻觉的最后防线模型生成时提示词的约束力直接决定了它在事实边界之外会不会胡乱发挥。我的模板里必带这样几句话“仅根据以下资料作答”“如果资料中没有信息请直接说不知道”“不要推测或编造”。有时候我会再加上一句“如果资料之间互相矛盾请指出矛盾之处。”这几句话不复杂但能立竿见影地降低幻觉率。还有一个容易被忽略的点要给模型留出拒绝回答的空间。很多公司做客服机器人恨不得模型对每个问题都能给出答案。可如果模型连问“今天天气怎么样”都非要基于内部资料回答一遍那它只能靠编。正确的做法是设计一套兜底逻辑检索结果的相关度低于阈值时直接返回“我暂时无法回答这个问题请联系人工客服”而不是强行进入生成环节。5.4 评估必须量化没有量化评估的调优等于摸黑走路。我用的评估方式很朴素一套固定测试集每次改动后跑一遍人工或半自动地给结果打分。打分维度前文提过准确性、完整性、可溯源。只要得分在提升改动就是有效的得分下降说明改动引入了新的问题。你还可以记录一些失败样本定期复盘。失败样本是最有价值的资产因为它们能让你总结出共性原因。比如我后来发现自己项目的多数失败案例都集中在“数字信息检索不到”这一类于是专门优化了切分和检索对数字的敏感性效果提升很明显。5.5 缓存和分层是提效捷径开篇提到的缓存再展开说几句。缓存不是只对最终答案缓存中间结果一样可以复用。比如针对热门问题Embedding 和检索结果都是稳定的完全可以缓存检索结果。如果连用户问题都一样那就连生成环节都省了直接返回提前生成好的答案。分层的意思是把系统拆成快速通道和慢速通道。简单问题走缓存和关键词匹配复杂问题才走完整 RAG 流程。这样既保证了响应速度又控制了模型调用的成本。很多高并发业务系统靠这一招把成本降了百分之四十以上效果非常可观。6. 工具选型参考与学习路径建议初学者面对一堆开源组件最容易陷入选择困难。我把选型思路和我的习惯列一下不吹捧任何一家纯粹从项目需要出发。6.1 组件怎么选看三个维度第一个维度是模型生态。你选 Embedding 模型和生成模型时要优先看它对中文的支持程度和社区活跃度。社区活跃意味着踩坑的人多、教程多、问题方案多新人能少走很多弯路。第二个维度是易用性。对新手来说API 设计是否简洁、文档是否友好、有没有现成的示例非常重要。我见过有些工具功能强大但学习曲线极其陡峭不适合刚上手的人。先选一个用起来顺手的等项目跑通后再考虑替换更强大的工具。第三个维度是扩展性。项目如果只是 Demo随便选都行如果是要上生产就要考虑它是否支持分布式部署、是否方便监控、数据迁移是否容易。很多新人做的第一个 RAG 项目都死在“从 Demo 到生产”这一步因为有些组件在单机上跑得很好一上生产就各种问题。我的建议是不要为了选型而耽误学习进度。先用最简单、社区相关的方案把流程跑通再逐个替换不满足需求的环节。技术选型是一个动态过程不是一锤子买卖。6.2 学习路径从 Demo 到项目实践第一步照着一份现成的教程跑通一个最简的 Demo先建立对整条链路的直观感受。第二步改参数改切分、改 Top-K、改提示词观察效果变化。这一步很重要因为只有亲手调过你才知道这些参数带来的是判断题不是选择题。第三步换一种文档类型比如从纯文本换成 PDF 或者是带有复杂表格的文档逼自己处理新问题。第四步加评估做测试集、打分、迭代。第五步考虑性能和生产化加缓存、加监控、加日志。这条路走下来两到三周时间就能有不错的产出。很多人学大模型应用开发的时候总想着先把理论吃透再动手我的观点恰好相反动手做出来一个能跑的东西再去反推理论效率会高得多。你只需要几个小时的代码时间就能体会到从原理到落地的完整链路这种成就感是看多少篇文章都替代不了的。最后再分享一个我自己的习惯每完成一个功能模块我都会在本地留一份带注释的简化版代码方便以后回顾。RAG 这个方向变化很快新的模型、新的向量库、新的框架层出不穷但底层的链路没有变过理解好切分、检索、生成这三件事之间的关系之后无论技术怎么演进你都能快速跟上。希望这篇指南能帮你建立一张清晰的地图接下来的路就可以放心大胆地自己走了。