LLM与RAG实战：从原理到落地的检索增强生成指南

1. 从模型会说话到模型懂你的业务LLM 与 RAG 到底在解决什么问题很多人第一次接触大模型注意力都放在它能不能写出一段通顺的话上。但真正把大模型往业务里落地的人很快会撞到另一堵墙模型确实会说话可它说的东西跟你的业务数据、内部文档、产品手册没有半点关系。你问它公司某个型号产品的保修条款它要么一本正经地编要么干脆说我不知道。这不是模型笨而是它的知识边界就停在那里——训练数据截止到某个时间点且不包含你私有的那部分内容。LLMLarge Language Model大语言模型本质上是一个在海量文本上训练出来的概率模型它做的事情是根据上文预测下一个 token。这个机制决定了它擅长语言组织、推理和泛化但它并不天然拥有查资料的能力。RAGRetrieval-Augmented Generation检索增强生成就是在这个缺口上补的一块板在模型生成答案之前先去一个外部知识库里把相关内容捞出来塞进上下文再让模型基于这些内容作答。我习惯用一个类比来解释LLM 像一位知识面很广但记不住细节的顾问RAG 则是给他配了一个随叫随到的资料员。顾问负责组织语言、做推理判断资料员负责在你说出问题后第一时间把相关的几页材料翻出来递到他手上。顾问再聪明没有资料员也只能凭印象回答资料员再勤快没有顾问翻出来的材料也没法变成一段人话。这套组合解决的核心问题有三个。第一是知识时效性模型训练有截止日期RAG 让知识库随时可更新改一条文档就生效不用重新训练。第二是私有数据接入企业内部的产品手册、工单记录、合同条款这些不可能拿去训练公共模型但可以通过 RAG 在推理时注入。第三是可溯源模型给出的答案可以标注来自哪份文档的哪一段这在客服、法务、医疗等场景里几乎是刚需。适合读这篇内容的人大致分三类一是刚入门、想搞清楚 LLM 和 RAG 各自定位的开发者二是正在做企业知识库、智能客服、文档问答的产品或技术负责人三是已经跑通了 Demo但发现效果不稳定、想搞清楚底层原理再优化的实践者。不管你是哪一类接下来的内容都会从原理讲到实操尽量把为什么这么做讲透而不是只丢一堆步骤。2. LLM 的工作机制为什么它既强大又不可靠2.1 自回归生成一个 token 一个 token 地猜LLM 的生成过程叫自回归autoregressive。给定一段输入prompt模型输出第一个 token然后把这个 token 拼回输入再预测下一个如此循环。每一步它输出的其实是一个在整个词表上的概率分布采样策略决定最终选哪个词。这里就引出一个常被问到的问题temperature 到底在干什么。简单说模型输出的原始分数叫 logits经过 softmax 变成概率。temperature 是作用在 softmax 之前的一个缩放因子温度趋近 0分布变得尖锐几乎总是选概率最高的词输出稳定但可能死板温度调高分布被拉平低概率词也有机会被选中输出更多样但更容易跑偏。做 RAG 问答时我一般把 temperature 压到 0.1 到 0.3因为这时候我们要的是忠实于检索到的材料不是发挥创意。理解这一点很关键模型没有事实数据库它只有概率。所谓幻觉本质上是模型在概率上选了一条语言上通顺、但事实上错误的路径。RAG 的价值就在于把事实这部分从模型的参数记忆里剥离出来交给外部检索来保证。2.2 上下文窗口RAG 的物理边界每个 LLM 都有一个上下文窗口context window也就是一次能处理的 token 总量输入加输出都算在内。早期模型只有 4K现在主流模型动辄 32K、128K 甚至更长。这个数字直接决定了 RAG 能塞多少检索结果进去。很多人以为上下文窗口越大越好塞得越多越准。实测下来完全不是这么回事。有个现象叫lost in the middle当上下文很长时模型对开头和结尾的信息利用得比较好中间部分容易被忽略。所以 RAG 的关键不是塞满而是塞准。检索回来的十段内容里如果只有两段相关剩下八段反而会稀释注意力甚至引入矛盾信息让模型犯迷糊。这就解释了为什么 RAG 系统里检索质量比生成质量更值得投入。生成那部分你基本只能靠选模型和调 prompt但检索那部分从切块策略到召回排序每一步都有大量可优化的空间。2.3 模型选型不是越大越好实际项目里选模型我一般看四个维度能力、成本、延迟、可控性。能力包括推理、指令遵循、多语言成本按 token 计费长文档问答场景下差异巨大延迟直接影响用户体验可控性则涉及能否本地部署、能否微调、数据是否出域。一个常见的误区是无脑上最强的模型。如果你的场景是内部文档问答问题相对固定一个中等规模的模型配合好的检索效果往往不输顶级模型成本却低一个数量级。反过来如果问题需要多步推理、跨文档综合那模型能力就是瓶颈省不得。还有一点模型是会迭代的。今天选定的模型半年后可能被新版本替代。所以架构上要把模型调用抽象成一层接口别把某个模型的特性写死在业务代码里。这一点在后面讲工程实现时会再展开。3. RAG 的完整链路从文档到答案中间发生了什么3.1 索引阶段切块是门手艺RAG 的第一步是把知识库文档处理成可检索的形式。原始文档可能是 PDF、Word、网页、数据库记录格式五花八门。处理流程通常是解析出纯文本按某种策略切成块chunk每块转成向量embedding存进向量数据库。切块chunking这一步看似简单实则最影响效果。切太大一块里混了好几个主题检索时噪声大切太小语义不完整模型拿到半句话也没法用。常见的做法是按固定 token 数切比如 512 或 1024块之间留一点重叠overlap避免把一句话从中间劈开。但固定长度切块对结构化文档很不友好。比如一份产品手册按 512 token 硬切很可能把参数表和注意事项切到一块里。我的经验是优先按文档的自然结构切——按标题层级、按段落、按表格边界。如果文档本身有 Markdown 或 HTML 结构就顺着结构走如果是纯文本至少按段落和句子边界切别硬按字符数。重叠部分设多少也有讲究。一般设块大小的 10% 到 20%。重叠太少跨块的语义接不上重叠太多检索结果里全是重复内容浪费上下文。我做过一个对比同样一份技术文档重叠从 0 调到 15%问答准确率能提升七八个百分点再往上加收益就很小了。3.2 检索阶段向量相似不等于语义相关检索的核心是把用户问题也转成向量然后在向量库里找最相似的块。相似度常用余弦相似度。这一步听起来很直接但坑不少。第一个坑是embedding 模型和生成模型要匹配语言和领域。如果你的文档是中文技术文档用一个主要在中英文通用语料上训练的 embedding 模型效果通常还行但如果是法律、医疗这种专业领域通用 embedding 可能抓不住术语之间的细微差别。这时候要么换领域 embedding要么在检索后加一层重排rerank。第二个坑是纯向量检索会漏掉关键词匹配。向量擅长语义相似但对精确匹配不敏感。用户问XX-2000 型号的保修期向量检索可能返回一堆讲保修政策的段落却没命中那个具体型号。解决办法是混合检索向量检索加关键词检索比如 BM25两路结果融合。这个组合在实战里几乎是标配。第三个坑是召回数量。召回太少可能漏掉关键信息召回太多噪声大。我一般先召回 20 到 50 条再用 rerank 模型精排到 3 到 8 条塞进上下文。rerank 模型比 embedding 模型重但只对少量候选做精排成本可控效果提升明显。3.3 生成阶段prompt 决定了模型怎么用材料检索回来的内容怎么交给模型全靠 prompt 设计。一个基本的 RAG prompt 通常包含三部分系统指令你是谁、要遵守什么规则、检索到的上下文、用户问题。系统指令里最关键的一条是只根据提供的上下文回答如果上下文里没有相关信息就说不知道。这条能大幅降低幻觉。但光写这一条还不够模型有时候会脑补上下文里没有的细节。我的做法是再加一条回答时引用来源编号逼模型把答案和具体材料对应起来既方便溯源也减少了自由发挥。上下文怎么排列也有讲究。前面提到lost in the middle所以最相关的内容应该放在开头或结尾。如果检索结果有明确的相关性排序就按最相关放两头、次相关放中间来排。另外每段材料前面加上来源标识比如文档名、章节模型引用时会更准确。还有一个细节上下文里的材料之间如果互相矛盾模型会怎么处理实测下来它倾向于选先出现的那个或者干脆把矛盾都列出来。所以检索阶段的相关性排序很重要别把低质量内容排在高位。4. 把 RAG 跑起来一个可复现的最小实现4.1 技术栈选择与理由讲原理容易落地是另一回事。这里给一个最小可跑的 RAG 实现思路语言用 Python因为生态最成熟。核心组件四个文档加载、切块、embedding、向量库。文档加载用unstructured或pypdf这类库能处理 PDF、Word、HTML。切块用langchain-text-splitters里的RecursiveCharacterTextSplitter它支持按分隔符优先级递归切分比硬切字符数合理。embedding 可以用开源的sentence-transformers本地跑也可以用云端 API。向量库本地开发用chroma或faiss就够了生产环境再考虑milvus、qdrant这类。选本地 embedding 还是云端 API主要看两点数据敏感性和成本。数据不能出域就本地跑模型小一点、慢一点也能接受数据不敏感、追求效果就上云端。我一般先用本地模型把流程跑通效果不够再换云端对比。4.2 核心代码骨架下面是一个简化版的索引和查询流程重点看结构具体参数按你的数据调。from langchain_text_splitters import RecursiveCharacterTextSplitter from sentence_transformers import SentenceTransformer import chromadb # 1. 切块 splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap120, separators[\n\n, \n, 。, , , , ] ) chunks splitter.split_text(raw_text) # 2. 向量化 model SentenceTransformer(BAAI/bge-small-zh-v1.5) embeddings model.encode(chunks, normalize_embeddingsTrue) # 3. 入库 client chromadb.PersistentClient(path./rag_db) collection client.get_or_create_collection(docs) collection.add( documentschunks, embeddingsembeddings.tolist(), ids[fchunk_{i} for i in range(len(chunks))] ) # 4. 查询 query XX-2000 型号的保修期是多久 q_vec model.encode([query], normalize_embeddingsTrue) results collection.query(query_embeddingsq_vec.tolist(), n_results5) context \n\n.join(results[documents][0])这段代码跑通不难难的是效果调优。chunk_size和chunk_overlap这两个参数我建议你拿一批真实问题做评测别凭感觉设。评测方法很简单准备 50 到 100 个问题每个问题标注正确答案所在的文档段落然后看检索能不能把那段召回回来。召回率上不去后面生成再强也白搭。4.3 从 Demo 到可用必须补的三件事第一件是重排。纯向量召回的前 5 条里经常混着不相关的。加一个 rerank 模型比如bge-reranker对召回的 20 条重新打分排序取前 5 条。这一步通常能把准确率拉高一大截代价是几十到几百毫秒的延迟。第二件是查询改写。用户的问题往往口语化、有指代、缺上下文。比如多轮对话里用户问那它的价格呢单看这句根本不知道它指什么。做法是用 LLM 把当前问题结合历史对话改写成独立完整的查询再去检索。这一步对多轮问答场景几乎是必需的。第三件是引用与兜底。答案里要能标出引用了哪几段材料用户点开能看原文。同时要有兜底逻辑检索结果的相关性分数低于某个阈值时直接回复知识库里没有找到相关内容而不是硬让模型编。这个阈值需要根据你的 embedding 模型和相似度分布来定一般取一个能过滤掉明显不相关结果的分数。5. 那些文档里不会写的坑RAG 实战中的真实问题5.1 检索到了但模型没用这是最让人抓狂的情况你明明看到检索结果里有正确答案模型却答非所问。原因通常有三个。一是上下文太长关键信息被淹没。解决办法是减少召回数量、提高相关性或者把最相关的内容放在上下文开头。二是prompt 指令不够强。模型可能觉得自己的知识比上下文更可靠。这时候要在系统指令里明确上下文是唯一事实来源甚至可以要求模型先复述相关材料再作答。三是材料格式混乱。如果检索回来的文本里夹杂大量表格符号、页眉页脚、乱码模型理解起来会吃力。索引阶段做好清洗比生成阶段调 prompt 更有效。5.2 多轮对话里的指代和漂移单轮问答好做多轮就复杂了。用户第一句问你们有哪些产品第二句问那个最贵的多少钱第三句问保修呢。每一句都依赖前文直接拿去检索必然失败。我的做法是维护一个对话历史每次检索前用 LLM 做一次查询改写把当前问题补全成独立查询。改写时把最近几轮对话作为上下文让模型判断指代关系。改写完的查询再走检索流程。这样即使用户说话很省略检索也能命中。但改写也有风险模型可能改错把原本明确的问题改得偏离。所以改写后的查询最好也做一次相关性校验或者保留原始查询做双路检索取并集。5.3 知识库更新与一致性知识库不是一次建好就完事。文档会更新、会新增、会作废。如果只往向量库里加不删旧版本的内容会和新版本一起被检索出来模型拿到矛盾信息就懵了。工程上要给每个块打上文档 ID 和版本号更新文档时先按文档 ID 删掉旧块再插新块。向量库一般支持按 metadata 过滤删除用起来不难但要在流程里设计好别等到线上出问题才补。另外文档更新后 embedding 要不要重算如果只是文字微调块内容变了就得重算因为向量是基于内容生成的。这一步可以增量做只处理变化的文档不用全量重建。5.4 成本与延迟的平衡RAG 的每一步都在烧钱和时间embedding 调用、向量检索、rerank、LLM 生成。线上系统要在效果和成本之间找平衡点。几个实用的优化方向embedding 可以缓存相同查询不用重复算rerank 只对 Top-N 做N 别设太大生成时控制上下文长度别把无关材料塞进去简单问题可以走小模型复杂问题才路由到大模型。这些策略叠加起来成本能降一半以上体验基本不受影响。6. RAG 之外Agent、MCP 与知识库的边界6.1 RAG 和 Agent 是什么关系热词里经常出现 agent、agentic rag 这些词很多人搞不清它们和 RAG 的区别。简单说RAG 是一个检索-生成的固定流程一问一答。Agent 则是一个能自主决策的系统它可以根据任务需要自己决定要不要检索、检索什么、检索几次甚至调用外部工具。Agentic RAG 就是把检索能力作为 Agent 的一个工具。Agent 面对复杂问题时可能先检索一次发现信息不够再换个关键词检索或者去查数据库、调 API最后综合所有信息作答。这比固定流程灵活得多但也更难控制容易陷入循环或者调用过多工具导致延迟飙升。我的建议是如果你的场景是相对固定的文档问答老老实实用标准 RAG稳定可控。如果问题需要多步推理、跨数据源综合再考虑 Agent 化而且要设好最大步数和超时别让它无限循环。6.2 MCP 解决的是另一个问题MCPModel Context Protocol常被拿来和 RAG 比较其实它们不在一个层面。RAG 解决的是怎么把外部知识喂给模型MCP 解决的是模型怎么标准化地调用外部工具和数据源。一个是知识注入一个是能力扩展。打个比方RAG 是给顾问配资料员MCP 是给顾问配一套标准化的电话接口让他能直接打给财务、法务、仓库问实时数据。两者可以共存也可以独立使用。做企业知识库时RAG 是主力做需要实时数据的业务助手时MCP 这类工具调用协议就更重要。6.3 什么时候该考虑微调RAG 不是万能的。有些场景 RAG 效果就是上不去比如需要模型掌握特定的输出格式、特定的推理风格或者领域术语极其密集。这时候微调fine-tuning可能是更好的选择。但微调有代价需要标注数据、需要算力、模型更新后要重新调。我的经验是先用 RAG 把能解决的问题解决掉把 RAG 解决不了的问题收集起来看它们有没有共性。如果共性明显、数据量够再考虑微调。很多时候优化检索和 prompt 就能解决八成问题剩下的两成再评估要不要微调。7. 我踩过的几个具体坑和对应的解法第一个坑是切块把表格切碎了。一份产品参数表按固定长度切参数名和参数值被分到不同块里检索出来只有半张表模型根本没法用。后来改成按表格整体切表格作为一个块问题就解决了。如果你的文档里表格多一定要在切块阶段特殊处理。第二个坑是embedding 模型选错语言。早期用了一个英文为主的模型处理中文文档检索效果惨不忍睹。换成中文优化的模型后同样的数据、同样的流程召回率直接翻倍。选 embedding 模型时先确认它的训练语料和你的文档语言匹配这是最基本的要求。第三个坑是相似度阈值设太高。一开始为了过滤噪声把阈值设得很高结果很多本该召回的内容被挡在外面模型频繁说不知道。后来把阈值调低配合 rerank 精排效果好很多。阈值这个东西没有标准答案要拿你的数据跑分布看相关和不相关结果的分界在哪里。第四个坑是忽略了对多轮对话的查询改写。上线初期用户反馈聊两句就答非所问排查后发现是检索时没带上下文。加上查询改写后多轮场景的满意度明显提升。这个功能看起来简单但对多轮体验的影响是决定性的。第五个坑是没有做检索评测。一开始全靠人工试几个问题觉得差不多能用就上线了。后来建了一个小评测集才发现某些类型的问题召回率只有一半。有了评测集每次调整参数都能量化对比优化方向也清晰了。如果你只做一件事来提升 RAG 效果我建议就是建评测集。8. 给不同阶段实践者的建议如果你刚入门别急着上复杂框架。先用几十份文档、一个本地 embedding 模型、一个轻量向量库把切块-检索-生成这条链路手动跑通。跑通之后你会发现大部分问题都出在检索环节而不是生成环节。理解这一点后面的优化方向就不会跑偏。如果你已经在做企业知识库重点投入在检索质量上混合检索、rerank、查询改写这三样是性价比最高的优化。同时把评测体系建起来没有评测就没有优化。生成那部分选一个指令遵循好的模型把 prompt 写清楚基本就够了。如果你在考虑 Agent 化先问自己标准 RAG 到底哪里不够用是问题太复杂还是数据源太多如果只是效果不好那大概率是检索没做好Agent 化解决不了这个问题反而增加复杂度。Agent 是给需要自主决策的场景用的不是给效果不好的场景用的。最后说一句关于模型选型的体会别追新追稳。生产系统里一个你摸透了脾气、知道它在什么情况下会出错的模型比一个刚发布、效果榜上第一但你完全不了解的模型更有价值。RAG 这套架构的好处就在于模型是可以替换的零件检索和知识库才是你真正的资产。把资产经营好换什么模型都能跑得不错。