做AI应用开发这几年，我遇到最多的提问其实不是"模型怎么调"，而是"模型又乱说了""模型怎么不知道这个""模型怎么说不到我系统里的数据"。坦白讲，大模型本身就像个博闻强识但性格固执的老朋友：你问他常识，他能滔滔不绝；你让他说点内部资料，他立马哑火；你再追问一次不确定的事，他干脆给你编一个像模像样的答案。这三个问题，就是圈子里常说的"记不住、会乱说、看不到私有数据"，而RAG（Retrieval-Augmented Generation，检索增强生成）几乎成了目前公认的解法里最务实、最接地气的一条路。
这篇东西写给正在做AI应用、或者正准备把大模型接入业务系统的程序员朋友。我会把RAG的原理拆开揉碎，讲清楚它到底怎么解决三大难题，再分享一套我可复现的落地步骤、代码片段和排坑记录。无论你是第一次听说RAG，还是已经踩过不少坑，应该都能找到点能用得上的东西。
1. 三大难题到底难在哪：先弄清楚大模型的"病根"
想理解RAG为什么能解决问题，得先理解大模型为什么会有这三个毛病。很多同学一上来就急着调API、拼Prompt，其实病根没看清，后面所有努力都是在打地鼠。
1.1 记不住：知识停留在训练时点
大模型的"记忆"不是像数据库那样一行一行存储的，它的知识其实是训练阶段从海量文本里学出来的参数化记忆。你问它"2024年某产品发布会的具体流程"，如果训练数据里没有对应的信息，它就只能靠推理去猜，或者干脆说"我不知道"。
更麻烦的是，你没法指望大模型终身学习。训练一次要烧掉大量算力，而现实世界的知识每分每秒都在更新。企业内部的制度文件、项目文档、客服话术、产品手册——这些内容根本不在模型的原始训练数据里，模型自然一个字都不记得。用技术术语讲，这叫知识时效性差和领域知识缺失，翻译成大白话就是：它记住的都是"过去的大众知识"，记不住"当下的私有信息"。
1.2 会乱说：幻觉不是Bug，是"性格"
幻觉（Hallucination）这个词听起来很吓人，实际上是大模型的生成机制决定的。语言模型本质是个概率系统，它生成每个词的时候，是根据前文预测"哪个词最可能出现"，而不是查证"哪个词是事实"。所以当你问一个它没把握的问题时，它不会诚实地摇头，而是从概率分布里挑一个词串填进去，说得越流畅，你就越容易信以为真。
我见过最典型的例子是：让模型回答某个内部系统的API返回格式，模型完全没见过这个API，但它会编出一个结构完整的JSON示例，字段名、注释、类型声明全都像模像样，甚至让经验不足的新人照着去联调，结果调了一下午才发现接口根本不存在。这就是幻觉的杀伤力——它不是简单的"答错"，而是"以极高的置信度答错"。
1.3 看不到私有数据：模型天生是"外人"
大模型训练用的是公开数据，企业内部的数据库、知识库、业务日志，它一概"看不见"。你不可能为了一个企业内部问答功能，把私有数据塞进模型的训练语料里——先不说安全性，光是数据脱敏、权限控制、增量更新这些问题就能让项目拖上几个月。
所以你会发现，直接拿通用大模型做企业应用，效果往往很尴尬：问它公开常识，它像个专家；问它"我们公司报销流程怎么走"，它一脸茫然；如果你把流程贴在Prompt里再问，它倒是能答，可Prompt长度有限，文档一多就放不下，成本也跟着飞涨。
这三个问题看着各不相同，实际上指向同一个根源：大模型的"知识来源"和"生成过程"是解耦的——它只会基于训练时学到的参数生成内容，而不会主动去外部世界查最新、最准确、最私有的信息。RAG的思路，就是在这中间架一座桥。
2. RAG是怎么设计出来的：一种检索+生成的新范式
RAG的全称是Retrieval-Augmented Generation，翻译过来就是"检索增强生成"。它的核心思想不复杂：别让模型裸奔，先从一个外部知识库中把和问题最相关的内容检索出来，把这些内容作为上下文交给模型，让模型基于这些真实材料来生成答案。说得更直白一点，就像开卷考试：模型不再是凭脑子里的存货闭卷作答，而是可以翻书、查资料、引用证据。
2.1 RAG的基本工作流程
一个标准的RAG系统通常包含四个环节，我用一句话分别概括：
- 知识入库：把私有文档拆成小段，经嵌入模型转成向量，存入向量数据库。
- 用户提问：把用户的问题也用同一个嵌入模型转成向量。
- 相似度检索：在向量库里找出与问题向量最相似的若干文档片段。
- 生成答案：把检索片段和原始问题一起塞给大模型，让它参照这些材料作答。
这四个环节环环相扣，任何一个环节出了问题，最终答案都会受影响。很多人以为RAG就是"向量检索+Prompt拼接"，这么说没错，但真正落地时，每个环节里都藏着不少学问。
为了让你看到全貌，我先给出一张典型的系统结构描述，后面会逐步展开：
私有文档 → 文档解析 → 文本切分 → 嵌入模型 → 向量数据库 ↑ 用户提问 → 查询改写 → 嵌入模型 → 向量检索 → 重排序 → Prompt拼接 → 大模型 → 回答左边是离线的"知识库构建管线"，右边是在线的"问答管线"。离线管线可以定时跑，比如每天凌晨把新增文档同步进去；在线管线则要求低延迟，通常控制在几百毫秒到几秒之间。
2.2 为什么要选RAG而不是微调
这是我被问得最多的问题，也是初接触RAG时最容易纠结的地方：既然模型记不住私有知识，那我直接用私有数据微调一个模型，不是更彻底吗？
微调（Fine-tuning）的思路是让模型把知识"背"进参数里，但这里有几个现实问题。第一，微调需要高质量的训练数据，企业内部文档往往格式混乱、口径不一，直接拿去微调可能让模型学到错误信息；第二，微调成本不低，尤其是大模型，一次全量微调可能要租几十张显卡，跑上几天；第三，知识更新不灵活，今天改了一条流程，难道明天又要重训一遍？
RAG的优势恰好在这三点上都是反过来的：知识不以参数形式存储，而是以"外挂资料"的形式存在，更新资料只需要改向量库，不用动模型；私有数据不需要进入训练管道，安全性更好；即使检索出来的片段有错，你也可以快速定位和修正，不用重新训练模型。
当然，RAG也不是万能的。如果模型本身复杂推理能力欠缺，比如要它做多步数学推导，RAG帮不上什么忙。更合理的策略常常是"RAG为主，微调为辅"：用RAG解决知识时效和私有问题，用轻量微调对齐模型回答的语气和格式。
2.3 RAG的适用场景
以我的经验，RAG最适合那些"答案就藏在某堆文档里"的场景：
- 企业知识库问答：内部制度、操作手册、历史项目总结，员工提问，系统基于文档回答。
- 客服机器人：产品信息、售后政策、常见问题，客服机器人先检索再回答，准确性明显提升。
- 代码库理解：让AI基于代码仓库里的README、接口文档、设计文档回答问题，辅助新同学上手。
- 智能投研/情报分析：从大量研报、新闻、公告中提取相关内容，辅助生成分析结论。
这几个场景有一个共性：知识集相对固定、可以被离线索引，且正确答案能从文档中找到依据。如果你的场景根本不是这种"查文档式"的需求，而是开放式创作、情感聊天，那RAG未必合适。
3. 从零搭一个RAG系统：检索增强生成的实操细节
理论讲完了，下面进入真正有意思的部分——动手搭一个RAG系统。我用过一个模拟项目（就叫"某企业内部知识问答系统"吧）来做验证，下面这套流程就是从那几次迭代中沉淀出来的，每一步背后都有踩坑的痕迹。
3.1 基础设施选型
在写代码之前，先把技术选型理清楚。RAG系统的核心组件有三个：嵌入模型、向量数据库、生成模型。
嵌入模型（Embedding Model）负责把文本变成向量。常见的开源选择是BGE系列、M3E系列，闭源的话可以用各种大厂API。选择时主要看两个指标：一是语义相似度效果，可以用公开的语义评测集跑一跑；二是文本长度上限，如果文档片段长达上千字，就得选支持长文本的嵌入模型。我第一次做的时候图方便，选了个只支持512字上限的模型，结果切分粒度被迫调得很碎，检索效果反而不理想。
向量数据库负责存储和检索向量。常用的有开源的Milvus、Qdrant、Chroma，也有直接基于Elasticsearch加向量插件的方案。选择标准很实在：你现有基础设施用什么，就优先用什么。如果公司本来就有Elasticsearch，再加个向量索引就行；如果从零开始，Chroma或Qdrant更轻量，部署成本低。我这里用Chroma演示，因为它代码最简单，适合讲清楚原理。
生成模型就是最终回答用户的大模型。可以是开源模型，也可以是API接口。RAG对生成模型的要求是"阅读理解能力强、能忠实引用材料"，你可以实测对比再定。
3.2 文档切分与索引
这一步最不起眼，却最影响RAG上限。很多同学RAG效果不好，根源就是切分策略不对。
文档切分的目标是：把长文档切成语义完整的片段，每个片段尽量独立成意。比如一篇项目总结，如果按固定字数硬切，很可能把一个小节的标题切给上一段，把内容留给下一段，检索时自然匹配不准。
我之前验证过一个经验：按结构切分比按固定长度切分效果好得多。Markdown的#、##标题、PDF的章节目录，都是天然的切分边界。中文场景下，还可以顺便清理一下换行符和空格，否则切出来的片段里全是奇奇怪怪的零散字符串。
下面是切分和入库的示例代码，我用了LangChain作为胶水层，方便阅读：
from langchain_community.document_loaders import TextLoader from langchain_text_splitters import MarkdownHeaderTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import Chroma # 1. 读取Markdown文档 loader = TextLoader("project_summary.md", encoding="utf-8") documents = loader.load() # 2. 按标题结构切分 headers_to_split_on = [ ("#", "章"), ("##", "节"), ] splitter = MarkdownHeaderTextSplitter(headers_to_split_on) splits = splitter.split_text(documents[0].page_content) # 3. 对过长的二级标题内容做二次切分 from langchain_text_splitters import RecursiveCharacterTextSplitter fallback_splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=50, ) final_chunks = [] for chunk in splits: if len(chunk.page_content) > 500: final_chunks.extend(fallback_splitter.split_text(chunk.page_content)) else: final_chunks.append(chunk) # 4. 生成向量并存入向量库 embeddings = OpenAIEmbeddings(model="text-embedding-3-small") vectorstore = Chroma.from_documents( documents=final_chunks, embedding=embeddings, persist_directory="./db/chroma", )几个细节要特别说明：
chunk_overlap（重叠长度）设为50个字符，目的是让相邻片段有必要的冗余，避免检索时正好卡在两个片段的缝隙里。- 切分粒度不是越细越好。片段太短，语义信息不足；太长，噪音太多。如果文档是FAQ形式，可以一条FAQ一段；如果是技术文档，500字左右是个不错的起点，后续再根据效果调整。
- 入库前记得做一下数据清洗：去掉页眉页脚、多余空行、表格中的无意义内容。脏数据进库，后面检索全是坑。
3.3 向量检索与生成管线的构建
向量库建好了，下一步就是写一条在线问答链路。流程是：用户提问 → 向量化 → 检索TopK → 生成答案。
这里最容易犯的错是"检索完就直接拼Prompt"，忽略了查询改写。用户的真实提问往往口语化、省略化，比如问"报销流程呢？"，直接拿这句话去向量库检索，效果一般。更好的做法是让模型先把问题改写成一个更完整的检索语句，或者同时生成多个角度的检索词，再去做多路召回。
下面这条链路加入了简单的查询改写和TopK召回：
def retrieve_and_generate(question: str, k: int = 5): # 1. 查询改写：让大模型把口语问题改写成适合检索的关键词 rewrite_prompt = f""" 请把下面的问题改写成适合检索的长尾中文查询词，只输出改写结果，不要解释。 问题：{question} """ rewritten = llm.invoke(rewrite_prompt) # 2. 向量化并检索 query_embedding = embeddings.embed_query(rewritten) retriever = vectorstore.as_retriever(search_kwargs={"k": k}) docs = retriever.invoke(rewritten) # 3. 拼装上下文 context = "\n\n".join([doc.page_content for doc in docs]) # 4. 生成回答 answer_prompt = f""" 你是企业内部知识助手，请严格基于下面的参考资料回答用户问题。 如果资料中没有答案，明确说“我无法从现有资料中找到答案”，不要编造。 参考资料： {context} 用户问题： {question} """ answer = llm.invoke(answer_prompt) return answer, docs这一段代码看着简单，但里面有两个point值得展开。
第一，检索的k值不是越大越好。我测试过：k=3时答案太干，有时候关键信息没召回；k=10时上下文太长，模型容易抓不住重点，还增加token消耗。k=5算是一个不错的平衡点，但具体项目要自己调。
第二，Prompt里那句"如果资料中没有答案，明确说无法回答"非常重要。这是抑制幻觉的关键手段之一。你不跟模型说这句话，它就会默认"既然你给了我上下文，我就必须从里面挤点东西出来回答"，于是开始脑补。加了这句话，等于给了它一个合法的"我不知道"出口，幻觉率肉眼可见地下降。
3.4 重排序：让最相关内容排到最前面
向量检索召回的是"语义上相近"的片段，但它不一定对"答案的正确性"敏感。你可能会遇到这种情况：召回的5个片段里，第1个片段只是沾点边，第4个片段才是真正能回答问题的，但模型优先看了第1个，回答自然偏了。
解决这个问题的主流方案是重排序（Rerank）：召回Top20或Top50个候选片段，再用一个专门的排序模型（比如开源的BGE-Reranker，或者各种大厂的Rerank API）对"问题-片段"对打分，最后取分数最高的Top5喂给生成模型。
重排序的收益在文档数量大、相似内容多的场景里尤其明显。我做过一个对比实验：不加Rerank时正确率大概70%，加了一个开源的Rerank模型后直接到了85%以上。代价是多了一次模型推理，延迟增加100毫秒左右，但为了答案质量，这个成本非常值得。
重排序的代码片段如下：
from FlagEmbedding import FlagReranker reranker = FlagReranker("BAAI/bge-reranker-v2-m3") def rerank_documents(question: str, docs, top_k: int = 5): # 构造问题和片段的对 pairs = [[question, doc.page_content] for doc in docs] scores = reranker.compute_score(pairs) # 按分数降序 doc_score_pairs = list(zip(docs, scores)) doc_score_pairs.sort(key=lambda x: x[1], reverse=True) return [doc for doc, _ in doc_score_pairs[:top_k]]实际项目中，我会在向量召回时取k=20，重排序后再截断到top_k=5。如果你不想引入额外的Rerank模型，也可以在向量检索阶段用"MMR"这类多样性算法，减少相似片段扎堆的问题，但效果不如专门的Rerank模型直接。
3.5 一个完整的Prompt模板参考
最后把生成阶段的Prompt模板分享出来。这个模板我在多个项目里改过好几版，核心思想就是"信息分层"和"行为约束"：
你是一名严谨的企业知识助手。 你必须基于下面的【参考资料】回答用户问题。 要求： 1. 如果参考资料中包含答案，请用简洁的中文回答，并尽量引用参考资料的原文。 2. 如果参考资料中不包含答案，请直接回答“无法从现有资料中找到答案”，不要做任何推测。 3. 不要重复问题，不要啰嗦，直接给出结论。 【参考资料】 {context} 【用户问题】 {question}多说一句：很多同学喜欢在Prompt里堆一大堆角色设定，比如"你是资深专家""你一定要友好热情"，结果模型把精力放在表演"人设"上，反而忽略了上下文里的信息。我的经验是，RAG场景下的Prompt越朴素越好，重点是告诉模型你要它做什么、什么情况下必须闭嘴。
4. 实战中的常见问题与排查技巧实录
写完了搭建流程，下面进入我最想分享的部分——实战中那些别人文档里不写，但你一定会遇到的各种问题。这一节按问题类型分类，每个问题都附上排查思路和解决办法，可以当速查表用。
4.1 检索召回不到相关内容，怎么办
你满怀期待地提问，结果模型告诉你"无法从现有资料中找到答案"，可你明明知道资料库里有这个答案。这种情况十有八九是检索环节出了问题，排查顺序从简到繁应该是：
第一步，检查切分质量。去向量库里翻一眼，看问题相关的那段原文是不是被切得七零八落，或者被塞进了某个无关片段里。我之前遇到一个典型案例：某个PDF转出来的文本里，一个表格被拆成了几十行碎片，检索答案时召回了一堆行碎片，上下文完全没法看。解决办法是在切分前做表格结构识别，表格整体保留。
第二步，检查嵌入模型的语义能力。如果你用的是通用嵌入模型，遇到大量专业术语时效果可能不佳。可以换个在垂直领域表现更好的嵌入模型，或是在入库前针对领域术语做一下词典替换。我有个朋友做法律知识库，他说他们的术语"执行异议""追加被执行人"通用嵌入模型经常分不清，后来换了一个基于法律语料微调的嵌入模型，效果立刻不一样。
第三步，调整检索参数。把k调大点，看看召回回来的片段里有没有正确答案，如果有，说明问题就出在排序上；如果没有，说明知识库里压根没有合适的内容，需要回到切分和索引环节。另外，可以启用混合检索（BM25关键词检索+向量检索），文档里经常有专有名词，向量检索容易把它"语义化"忽略掉，而关键词检索能精准命中，两者融合能大幅提高召回率。
4.2 上下文明明有答案，模型还是答错
这种情况最让人头大。排查后你会发现，不是没召回，而是模型被"噪音"干扰了。
一个常见原因是召回的多个片段里有互相矛盾的信息。比如知识库里有老版流程和新版流程，模型同时看到了两份，不知道该信谁。解决办法有两个：一是在入库时给每个片段打上来源元数据，比如"部门""生效日期""版本"，生成时要求模型优先采信版本最新的片段；二是在切分前做一遍去重和版本筛选，把过期文档排除在外。
另一个原因是提示词里上下文排布不合理。大模型对长上下文的注意力并不均匀，它对中间的文本往往关注较少，对开头和结尾更敏感。如果你把最重要的片段埋在长上下文中间位置，模型很可能忽略它。所以我会在生成Prompt时做一个简单排序：把重排序后得分最高的片段放在最前面，再放其他片段。别小看这个细节，效果差异很明显。
还有一种情况是完全反直觉的：检索到的信息太长了。你给了模型10页的参考资料去回答一个一句话就能说清的问题，模型反而被冗余信息带偏了。这时候可以考虑对检索结果做一个"摘要压缩"，只把每段的关键句提取出来喂给模型，而不是整段塞进去。这一步可以用一个小模型来做，整体效果会干净不少。
from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser compress_prompt = ChatPromptTemplate.from_messages([ ("system", "从参考资料中抽取与问题最直接相关的1-3句话，不要扩写。"), ("human", "参考资料：{context}\n问题：{question}"), ]) def compress_docs(question: str, docs): context = "\n\n".join([doc.page_content for doc in docs]) output = llm.invoke(compress_prompt.format_messages(context=context, question=question)) return output4.3 延迟和成本问题：检索快，生成慢
RAG的延迟主要由三部分构成：查询改写耗时、召回耗时、生成耗时。查询改写一次大模型调用大约几百毫秒，召回通常几十毫秒，而生成阶段随着输出长度增加，耗时呈线性增长。用户对问答场景的期望通常是3秒以内出结果，超过5秒体验就很差了。
降低成本最直接的方法是减少不必要的模型调用。查询改写不是每题都必须做的，如果问题本身已经结构清晰，可以直接跳过改写。另外一个容易被忽略的点是缓存：相同的用户问题在一段时间内大概率重复出现，把"问题→答案"缓存到Redis或者内存里，命中缓存就直接返回，省掉的不是一次API调用，可能是一整天的大量调用。我们在模拟项目里加了简单缓存后，系统整体成本下降了40%，平均延迟从3.5秒降到了0.2秒。
生成阶段如果总是输出长文，可以考虑调整max_tokens上限，或者用流式输出（SSE）让用户感受到"有反馈"，而不是傻等一整段文字生成完。RAG场景下，答案通常比较固定，流式输出对体验提升非常明显。
4.4 一个容易被忽视的坑：知识库不更新，答案永远过期
最后提醒一个很多人会忘记的点：RAG系统上线不是终点，而是运营的起点。你能轻松更新向量库，这本来是RAG最大的优势，但如果没人去做更新，优势就变成了劣势——用户过了一个月再来问，回答的还是上个月的流程，骂的还是你的系统。
我在实际项目里的做法是，写一个简单的定时任务，每天扫描指定目录，检测文件变更后自动增量更新向量库。为了维护方便，每条向量都带上文档ID和更新时间，同步变更代替全量重建，不然几十万条向量每次全量跑，既慢又多花额度。这个流程不难，但必须有，否则RAG系统就跟"新版大模型微调一次"一样，知识会逐渐腐烂。
def incremental_update(seen_docs: dict, docs_dir: str): for file in Path(docs_dir).glob("*.md"): mtime = file.stat().st_mtime if seen_docs.get(file.name) != mtime: # 重新加载并写入向量库，同时删除旧向量 vectorstore.delete(where={"source": file.name}) chunks = split_document(file) vectorstore.add_documents(chunks) seen_docs[file.name] = mtime5. 最后一个建议：先想清楚"答案从哪里来"
做了几个RAG相关项目之后，我个人最大的体会是：RAG的技术难点从来不在模型和代码，而在你自己对知识库的理解。你得先想清楚，用户问的问题，答案到底应该从哪一份文档的哪一段里来。如果这个问题在文档里本身就没有清晰的答案，RAG做得再精致也没有用。
所以我的习惯是，在动手搭建之前，先花时间梳理知识库：有哪些文档、哪些是权威版本、哪些已经过期、哪些信息互相冲突。这个梳理过程决定了后续检索质量的基线，基线高了，后面所有环节都会轻松不少。
RAG后续能玩的方向其实还很多，比如多路召回融合、图数据库结合知识图谱、自动评估检索质量的指标链，都是值得继续摸索的。不过对于刚开始接触RAG的团队，我建议别贪多，先把"切分→向量化→检索→生成"这条主线走通，再逐步往上加Rerank、缓存、增量更新这些增强项。等这一套稳定了，你会发现自己已经慢慢摸清了大模型的脾气——它确实记不住、会乱说、看不到私有数据，但只要你给对资料、管好流程，它就能给你足够惊喜的表现。
