做AI应用开发这几年我遇到最多的提问其实不是模型怎么调而是模型又乱说了模型怎么不知道这个模型怎么说不到我系统里的数据。坦白讲大模型本身就像个博闻强识但性格固执的老朋友你问他常识他能滔滔不绝你让他说点内部资料他立马哑火你再追问一次不确定的事他干脆给你编一个像模像样的答案。这三个问题就是圈子里常说的记不住、会乱说、看不到私有数据而RAGRetrieval-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, encodingutf-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_size500, chunk_overlap50, ) 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(modeltext-embedding-3-small) vectorstore Chroma.from_documents( documentsfinal_chunks, embeddingembeddings, 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值不是越大越好。我测试过k3时答案太干有时候关键信息没召回k10时上下文太长模型容易抓不住重点还增加token消耗。k5算是一个不错的平衡点但具体项目要自己调。第二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(keylambda x: x[1], reverseTrue) return [doc for doc, _ in doc_score_pairs[:top_k]]实际项目中我会在向量召回时取k20重排序后再截断到top_k5。如果你不想引入额外的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(contextcontext, questionquestion)) 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、缓存、增量更新这些增强项。等这一套稳定了你会发现自己已经慢慢摸清了大模型的脾气——它确实记不住、会乱说、看不到私有数据但只要你给对资料、管好流程它就能给你足够惊喜的表现。