你有没有遇到过那种时刻问大模型一个挺正经的问题它一本正经地给你编了一个答案逻辑通顺、头头是道甚至还有“专业术语”加持结果你一查资料全是凭空捏造的。行业里把这种现象叫幻觉Hallucination。说实话我这几年做AI应用开发被它坑过不止一次直到系统性地把RAGRetrieval-Augmented Generation检索增强生成用进项目幻觉问题才算有了真正可落地的解法。这篇内容我打算不绕弯子从“大模型为什么会胡说八道”这个根源讲起再把RAG的离线索引、在线检索、答案生成整条链路拆开给出可以直接抄的代码和选型建议最后聊Graph RAG、Agentic RAG这类进阶方向以及我自己踩过的坑。适合刚接触大模型应用开发、想给自家知识库接上“可问答”能力的工程师也适合准备RAG相关面试、想系统补一遍知识框架的同学。1. 大模型为什么会“一本正经地胡说八道”先搞清楚幻觉的根源先说一个我自己的真实经历。之前做一个企业内部知识库客户要求把几百份技术手册喂给大模型让员工直接对话查参数。原型阶段我随手问了句“XX设备的最高工作温度是多少”模型回答得非常流畅还给了一个看起来特别精确的数值。结果我翻原始手册一核对发现这个数值根本不存在。为什么因为大模型本质上不是一个“数据库”你问它问题它不是去查表而是根据自己学过的所有文本做文字续写。1.1 语言模型的本职工作是“续写”不是“查资料”大模型的底层逻辑是给定前面一段文字预测下一个最可能的token。你问它“北京到上海的高铁最快多久”它内部真正在做的事情是根据“北京到上海的高铁最快”这些前缀去预测后面最像人话的连续输出到底是什么。它知道“约4.5小时”这个答案是因为海量语料里无数篇文章提到过而不是因为它动态查询了铁路时刻表。这就带来两个致命问题。第一训练数据有时间截止点2024年5月才发布的产品、刚刚生效的政策、昨天才更新的参数模型根本没见过只能靠“语感”硬猜。第二长尾知识在语料里出现次数太少模型大概率会把相似信息混在一起比如把A型号的重量安到B型号头上。但凡涉及专业知识问答“自信的胡说”几乎是必然事件。你可以做一个很简单的实验拿一个没微调过的通用大模型问一条你所在行业里非常冷门、但你能百分百确认的细节。十个问题里它至少会编一两个。这不是模型质量问题而是架构本身的限制它把“知识记忆”和“知识推理”耦合在了同一套参数里遇到不熟悉的领域只能靠想象力补全。1.2 靠Prompt约束幻觉效果为什么不稳定既然模型会乱说很多人第一反应是在提示词里加一句“请基于事实回答不要编造”。我在早期项目里也这么干过实测下来对一部分问题有效对另一部分完全无效。无效的那部分恰恰是最危险的因为模型并不是“知道自己不知道”而是“以为自己知道”。你现在让它复述一个烂熟于心的概念它当然不会怀疑自己记得不对于是依然理直气壮地输出错误内容。这就像一个人喝醉了不会承认自己醉幻觉最大的问题不是模型刻意撒谎而是它在自己的“记忆幻觉”里毫无觉察。Prompt约束还有一个硬伤就算模型这次愿意承认“我不确定”它也只是停止输出而已并不能真正帮你找到正确答案。企业知识库场景里用户要的是答案或者可追溯的线索不是一个诚实的“不知道”。所以说靠提示词“堵”幻觉是一条走不通的路核心思路应该是别再让模型凭内部记忆单打独斗而是先给它一份和问题高度相关的、可信的参考材料再让它基于这份材料作答。这就是RAG的核心思想——用外部检索结果钳制生成内容让模型从“闭卷考试”变成“开卷考试”。2. RAG检索增强生成的完整链路从文档到答案的四次关键转换RAG整体可以分成离线索引和在线检索两大部分中间夹着一次关键的用户查询向量化。我习惯把它拆成四个阶段文档加载、文本切块、向量化入库、检索生成。下面逐个说清楚里面每一步到底在干什么、为什么必须这么干。2.1 离线索引清洗、切块、向量化、入库离线索引阶段的目标是把一堆原始文档变成可检索的向量库。首先处理的是文档加载。PDF、Word、Markdown、HTML各有各的坑PDF要处理扫描件OCR表格容易错位Word要抽取正文别把页眉页脚带进去Markdown相对友好但也得去掉代码块之外的噪声。这一步花的时间通常比想象中多我见过不少项目在演示时“看起来能用”一上真实文档就崩八成是加载解析环节没做干净。接下来是文本切块Chunking。很多人不理解为什么不能把整篇文档直接拿去向量化。原因有两个一是嵌入模型的输入长度有限超长文本会被截断二是切块越短每个向量表达的主题越聚焦检索时越容易命中精确位置。反过来块太小又会让上下文不完整一条技术参数被切成两半检索召回一半就废了。这里给出一个可参考的经验值中文场景块大小chunk size设在256到512个字符之间相邻分块重叠overlap10%到15%。为什么要有重叠因为硬按字符切会把一句话从中间劈开重叠区域相当于给上下文加了个“缝合补丁”让上一块末尾的信息在下一块开头再出现一次避免语义断裂。如果你的文档是Markdown或HTML更推荐按标题层级切块把“### 二级标题”作为天然边界这样切出来的每个块内容主题完整检索命中率明显更高。切块之后就是把每一段文本变成向量。这一步会用到专门的嵌入模型比如目前中文场景表现不错的BAAI/bge-m3系列。嵌入模型做的事情是把一段文本映射成一个固定维度的浮点数数组常见的有768维、1024维。原理说起来也不复杂它把语义相近的句子映射到向量空间里距离更近的位置。你可以把它理解为给每段文字算了一套GPS坐标“猫喜欢抓沙发”和“猫咪对家具有抓挠行为”这两句话虽然字面完全不一样但坐标距离很近。向量化完成后会得到一个文本块和向量的映射关系然后全部写入向量数据库。轻量场景用FAISS就够它是Meta开源的一个库直接内嵌在Python进程里要上生产、数据量大到几百万条再用Milvus或Qdrant这种独立服务它们支持分布式和水平扩容。另外如果公司已经有PostgreSQLpgvector也能凑合但别指望高效索引能力对标专业向量库。2.2 在线检索Dense Vector Search 的运作逻辑在线检索阶段用户输入一个问题后系统做三件事把问题用同一个嵌入模型转成向量拿这个向量去向量库里做相似度计算取相似度最高的topK个文本块返回。问题向量和库里的文档向量计算相似度最常用的是余弦相似度。在我上面的例子里嵌入模型在编码时已经做了向量归一化归一化之后用内积Inner Product算出来的结果就等价于余弦相似度省一趟计算。实际项目里向量库底层不会真的一条条暴力比对而是用HNSW这类近似最近邻索引把检索耗时从毫秒级“暴搜”压缩到亚毫秒级代价是极小概率漏掉真正最相似的结果工程上完全可以接受。这里有一个经常被忽略的关键点用户问题也必须经过和文档完全相同的嵌入模型、相同的归一化处理。如果文档用的bge-m3查询却用了另一个模型两个向量根本不在同一个语义空间里检索效果会断崖式下跌。topK的取值也值得琢磨。K太小可能漏掉答案K太大无关上下文又会污染生成结果。我在常规知识库项目里通常取K5如果文档本身碎片化严重会适当调大到8到10再交给下游的重排序模块进一步筛选。2.3 答案生成把上下文交还给模型而不是让它凭记忆硬编检索到相关片段后最后一步是把这些片段作为参考上下文连同用户问题一起拼进Prompt再请求大模型生成答案。这一步的核心在于Prompt模板的设计必须明确告诉模型“如果参考资料里没有答案就直说没有”并且要求它只依据给定资料作答而不是动用自己的世界知识。下面这个模板是我项目里一直在用的简单直接请基于以下参考资料回答问题。如果参考资料中没有答案请直接说“资料中未找到相关信息”不要自行编造。 参考资料 [片段1] [片段2] ... 问题{query} 回答看到没有关键动作有两个一是把检索结果放在模型“眼前”让它照着念二是明确给了“未找到”的逃生通道避免模型为了完成回答硬凑。实际体验下来加了这条“逃生通道”之后模型的拒答率会提高但幻觉率会显著下降对于企业知识库场景宁可不答也不能乱答。到这里一条最基础的RAG链路就已经闭环了。接下来的问题是这条链路到底怎么落地到真实工程里需要选什么框架、跑什么模型、写什么代码。我在下一节给出可以直接抄的完整方案。3. 从零搭一套RAG系统框架选型、本地部署与真实代码很多初学者一上来就纠结LangChain还是LlamaIndex其实在动手之前应该先想清楚一个更底层的问题你的数据量和复杂度到了需要重量级框架的程度吗如果只是几千条文档的Demo项目自己写一百行代码完全够用还能把所有流程控制在自己手里如果要做持续迭代的商业系统再考虑上框架的抽象能力。3.1 框架选型LangChain、LlamaIndex 还是手写我把三者放在一起做过对比各自优劣势非常明显。LangChain是目前生态最全的框架RetrievalQA、MultiQueryRetriever、ConversationalRetrievalChain这些组件开箱即用社区资料多网上随手一搜都是案例。缺点是抽象层级太多排查问题时要一层层扒封装反而增加心智负担。LlamaIndex的定位更聚焦在“索引”这件事上它对文档结构的理解、知识图谱的接入、以及“从文档到结构化索引”这一整个流程做得比LangChain细。如果你的核心诉求是让知识库更接近“数据基础设施”而不是“对话机器人”可以优先考虑LlamaIndex。完全手写则适合学习阶段以及那些对延迟和成本极度敏感、要把每一个环节都仔细调优的团队。它没有框架版本升级的兼容性包袱出问题也好排查。我在给客户做POC概念验证时反而经常手写一个最小实现因为最快、最容易定位问题。如果团队技术栈是Java也不用纠结Python框架Spring AI 2.0里已经提供了RAG相关的抽象和示例VectorStore、QuestionAnswerAdvisor这些组件可以直接对接和Spring Boot的工程化体系融合得很好。3.2 本地化部署Ollama 开源嵌入模型 向量库RAG的一大落地场景是数据敏感的企业内部知识库很多客户明文要求文档不许出内网。这时候本地化部署就是必选项我推荐用Ollama来跑生成模型和嵌入模型轻量、上手快而且安装之后提供了一个和OpenAI兼容的本地接口代码层几乎不用改就能切换。Windows用户装Ollama之后有个高频问题模型默认下载到C盘不一会儿就爆满。解决办法是给Ollama设置一个环境变量OLLAMA_MODELS指定到D盘目录然后重启Ollama服务即可。这个过程不复杂但你不提前设置备份模型文件的时候会非常痛苦。生成模型我用的比较多的是qwen2.5系列7B到14B参数在消费级显卡上都能跑中文能力在开源里是第一梯队。嵌入模型推荐BAAI/bge-m3它对中文长文本的语义理解很稳支持1024维输出而且在检索任务里做了专门优化。如果你想先快速验证效果不折腾本地显卡也可以直接用各家云厂商的免费模型API额度配合同一个RAG链路去跑。本地还是API只影响大模型这层前面的索引和检索逻辑完全不变。3.3 最小可用代码不依赖重量级框架的RAG实现下面这个实现是我给团队做内部培训时用的最小版本。不依赖LangChain只用sentence-transformers做嵌入、FAISS做索引、Ollama的OpenAI兼容接口做生成每一步都可控、可调试。import faiss from sentence_transformers import SentenceTransformer CHUNK_SIZE 300 OVERLAP 50 K 5 EMBED_MODEL_NAME BAAI/bge-m3 def split_text(text: str, size: int CHUNK_SIZE, overlap: int OVERLAP): 按字符切分带重叠窗口避免把关键句拦腰截断 chunks [] start 0 while start size len(text): chunks.append(text[start:start size]) start size - overlap if start len(text): chunks.append(text[start:]) return chunks def build_index(chunks): model SentenceTransformer(EMBED_MODEL_NAME) vectors model.encode(chunks, normalize_embeddingsTrue) index faiss.IndexFlatIP(vectors.shape[1]) index.add(vectors) return model, index def search(model, index, query, kK): q_vec model.encode([query], normalize_embeddingsTrue) scores, idxs index.search(q_vec, k) return idxs[0], scores[0] def build_prompt(query, chunks, idxs): context \n\n.join( f[片段{i1}]\n{chunks[idx]} for i, idx in enumerate(idxs) ) prompt f请基于以下参考资料回答问题。如果参考资料中没有答案请直接说“资料中未找到相关信息”不要自行编造。 参考资料 {context} 问题{query} 回答 return prompt然后调用Ollama本地模型from openai import OpenAI client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama, # Ollama本地接口不校验key占位即可 ) def ask_with_rag(query, doc_text): chunks split_text(doc_text) model, index build_index(chunks) idxs, scores search(model, index, query) prompt build_prompt(query, chunks, idxs) resp client.chat.completions.create( modelqwen2.5:7b, messages[{role: user, content: prompt}], temperature0.2, ) answer resp.choices[0].message.content sources [chunks[i] for i in idxs] return answer, sources这段代码看着简单但已经把索引、检索、生成三个核心环节全覆盖了。注意几个细节embedding编码时设了normalize_embeddingsTrue这样后面用FAISS的IndexFlatIP就算内积等价于余弦相似度生成时temperature设到0.2尽量压低随机性因为知识问答场景要的是稳定和准确不是花哨。实际项目里你还需要把chunks缓存起来每次查询都重新切分、嵌入是很大的浪费正确做法是文档变化时增量更新索引。3.4 用LangChain实现的对比版本如果你想用LangChain快速迭代代码会更简洁但内部逻辑完全一样。核心区别在于LangChain把DocumentLoader、TextSplitter、VectorStore、Retriever、LLM这些组件全抽象成了统一接口替换组件只需改一行配置。from langchain_community.embeddings import HuggingFaceBgeEmbeddings from langchain_community.vectorstores import FAISS from langchain_community.llms import Ollama from langchain.chains import RetrievalQA from langchain_text_splitters import RecursiveCharacterTextSplitter # 1. 切分 splitter RecursiveCharacterTextSplitter( chunk_size300, chunk_overlap50, separators[\n\n, \n, 。, , ], ) chunks splitter.split_text(doc_text) # 2. 向量化 入库 embeddings HuggingFaceBgeEmbeddings(model_nameBAAI/bge-m3) vectorstore FAISS.from_texts(chunks, embeddings) # 3. 组装检索问答 llm Ollama(modelqwen2.5:7b, temperature0.2) qa RetrievalQA.from_chain_type( llmllm, retrievervectorstore.as_retriever(search_kwargs{k: 5}), return_source_documentsTrue, ) result qa.invoke(你的问题)RecursiveCharacterTextSplitter里的separators参数值得细看它先按“连续换行、单个换行、句号、逗号、空格”的优先级去切能最大程度避免把完整句子劈成两半。对于中文场景在separators里加入“。”和“”非常有效比我之前傻傻按字符硬切的效果好很多。4. 当基础RAG不够用混合检索、Graph RAG 与 Agentic RAG跑通基础RAG只是开始。真实业务里文档形态千奇百怪问题类型多种多样纯向量检索会碰壁专业编号查不准、多跳问题答不全、需要反复检索的场景会“卡壳”。所以进阶方向要了解清楚。4.1 混合检索与重排序召回质量提升的第一步先说检索召回里的一个经典问题向量检索擅长语义匹配但它对精确关键词不敏感。你搜索“H3C-S5120V2-28P”这个交换机型号向量化之后可能把“H3C”和“S5120”都当成语义特征处理结果召回一堆“H3C其他型号”的片段精确编号反而排名靠后。解决办法是引入稀疏检索。稀疏检索的代表是BM25它通过词频和逆文档频率计算文本和查询的字面匹配程度对精确型号、编号、人名这类强标识符非常友好。工程上的标准做法是混合召回把BM25检索结果和Dense向量检索结果都取回来合并去重后再用一个Reranker模型做精细排序。Reranker和普通嵌入模型最大的区别在于嵌入模型是一次性把所有文档向量化再用向量距离衡量相似度速度快但精度有上限Reranker则是把query和每一篇候选文档拼在一起用cross-encoder方式逐对打分精度高很多但计算开销大。所以Reranker只用来精排前几十条候选不负责海量粗筛。实践里我常用的组合流程是BM25取top50 Dense Vector Search取top50 → 合并去重 → Reranker取top5 → 送入大模型。这个流程已被验证能显著提升答案命中率和最终回答的稳定性尤其是那些夹杂大量专业名词的行业文档效果几乎立竿见影。4.2 Graph RAG让多跳问题有谱可依基础RAG还有一个结构性问题它把每个文本块当成独立片段难以表达“片段之间谁影响谁、谁依赖谁”。当用户问的问题需要跨多个文档做推理时比如“A项目用了哪些B项目的模块”普通向量检索只能分别召回A项目文档和B项目文档但这些文档之间的关联关系根本没建立起来答案自然残缺。Graph RAG的思路是先从文档里抽取实体和关系比如“模型A”“部署环境B”“依赖关系C”构建成一张知识图谱然后在图谱上做检索和多跳推理。它和图数据库天然契合这也解释了为什么“graph rag图搜索”会成为热门搜索词。还记得搜到的“ontology rag”吗它在图谱构建前先定义一套本体约束也就是规定好“哪些实体类型、哪些关系类型是合法的”能有效过滤掉文本抽取时的噪声让图谱更干净。开源生态里微软开源的GraphRAG方案已经能直接用来搭建“文档 → 实体关系图谱 → 社区总结 → 检索问答”的完整链路虽然资源开销比普通RAG大不少但面对“关系密集型”的知识库比如组织架构、供应链、故障传播链值得投入。4.3 Agentic RAG从“查一次”到“想清楚再查”如果说Graph RAG解决的是“怎么把关系找全”Agentic RAG解决的就是“该不该查、查几次、查完怎么处理”。普通RAG是一次性检索、一次性生成属于“单轮开卷考试”Agentic RAG则让大模型扮演一个智能体自己决定整个检索策略。一个典型场景用户问“帮我对比这三款产品的授权协议区别”。普通RAG很可能只根据用户问题里的模糊语义检索到某几段相关文本然后就生成答案了三款产品的信息可能只覆盖了一款半。Agentic RAG会怎么做呢它会先规划先分别查产品A、B、C各自的协议段不够就再查“对比”相关的信息最后把检索结果汇总成一个对比表格。落地方式主要有三种模式。第一种是Router模式模型先判断问题类型是闲聊直接回答是知识问答才走检索第二种是Retriever Tool模式把检索封装成一个工具模型在需要时主动调用可以调多次、每次换不同的查询词第三种是Self-RAG模式模型在生成过程中不断自我评估“查到的资料够不够支撑回答”不够就重新生成更合适的查询继续查。我把Agentic RAG看作“RAG ReAct”的组合。实现时可以基于LangChain的Agent框架也可以自己定义工具调用循环。这里最大的坑不是技术实现而是策略设计如果不给智能体设置检索次数上限它会陷入无限循环延迟和成本都会爆炸。我一般设置最大3轮检索超过就强制进入生成阶段。5. RAG效果测评到底好不好不能靠感觉做RAG项目最怕听到的一句话是“感觉效果还行”。感觉不靠谱尤其是幻觉率这种指标人工抽几条问答根本看不出真实水平。要让系统持续迭代必须把评价体系建立起来。5.1 三个测量维度检索、生成、端到端RAG的效果可以拆成三个独立的层面每一层都要单独测。检索层看召回质量判断“该找到的片段有没有被找到”。常用指标包括Recallk、Precisionk、MRR和NDCG。其中Recallk最重要因为生成层的上限被检索层锁死——如果正确答案压根不在召回的片段里生成模型再强也无能为力。生成层看答案质量判断“模型读着这些片段有没有忠实作答”。核心指标是Faithfulness忠实度也就是生成答案里的信息是不是都能从参考片段里找到依据。这根指标直接对应幻觉率是RAG项目里最应该盯的一个数字。除此之外还要看答案相关性和事实正确性。系统层则要看端到端的可用性问题是否被有效回答、回答延迟、每次请求的token成本、引用来源可验证率。这层指标决定了产品能不能真正上线。5.2 从指标到工具RAGAS和人工评测集手动算这些指标很痛苦好在社区已经有了RAGAS这个开源评测框架。它的思路是用大模型来评估大模型给定问题、参考答案、检索到的上下文片段、生成的最终答案RAGAS能自动算出Context Precision、Context Recall、Faithfulness、Answer Relevancy四类分数。实际用下来和人工标注的相关性相当高可以作为日常迭代的“仪表盘”。但RAGAS这类工具有一个前提你需要一份高质量评测集。我的经验是至少准备50到100条评测问题并且覆盖三类第一类是答案明确在文档里的原始问题验证基本查找能力第二类是跨段落、跨文档的多跳问题验证检索链条第三类是“资料里根本没有答案”的对抗问题专门测模型会不会硬编。第三类是幻觉检测的重中之重因为用户问出知识库范围外的问题系统能不能正确拒答直接决定可信度。5.3 一个可落到团队里的评测流程我现在团队里的做法很简单一共四步第一步建评测集。让业务方提供真实高频问题加上我们补充的对抗问题做到100条左右。每条问题配套标准答案以及禁止答错的“红线问题”。第二步跑多个候选配置。在分块大小、topK、是否用Reranker、不同Embedding模型这些维度上组合出至少三到五组配置全部跑一遍评测集用RAGAS算出指标。第三步人工抽检。自动指标跑完人工再抽20条看输出重点看模型有没有“聪明地拒绝”、有没有引用正确来源、有没有在前置对话里被“带偏”。第四步坏case回归。把评测中发现的Bad Case列入回归集每次改完索引策略、提示词之后重新跑一遍防止改了A问题又搞坏B问题。这套流程建好之后RAG系统才能从一个“实验脚本”变成一个“可维护的产品”。我见过太多项目死在“改一下分块、重新测两条、看起来好了再改回来”的循环里根本原因就是没有评测集兜底。6. 踩坑复盘我把这些教训写在代码注释里最后这一节说说我自己在RAG项目里踩过最狠的几个坑也顺手把规避方法写清楚。这些都是文档里不会细讲、但实战中一定会遇到的东西。6.1 分块大小和重叠窗口是第一个坑最初做知识库时我图省事把chunk_size设为1024字符想着“每块信息越全越好”。结果检索回来的片段经常包含大量无关内容模型生成的答案被噪声带着跑Faithfulness指标惨不忍睹。后来我把尺寸调到256到512之间问题大幅缓解。还有一次我把chunk_overlap调到了0想着“少存点重复数据省钱”。结果一个涉及代码块的技术文档里函数的签名刚好被切在上一块末尾注释和实现全在下一块检索命中后上下文断裂答案看着就像半句话。从那以后我再也不敢不设重叠。真正的解法是结构化切块先尝试按Markdown标题切再对大段正文按段落切最后才用字符窗口兜底。一句话分块不是纯技术参数而是和你的文档结构强相关的设计决策。6.2 嵌入模型和生成模型的搭配有讲究另一个容易踩的坑是把“聊天厉害”的模型直接拿来做Embedding。曾经有同事想把GPT级别的大模型同时用来向量化和生成结果检索回来一堆语义相似但实质无关的内容原因就是通用聊天模型的输出分布面向文字生成并不适合做语义匹配的向量表达。嵌入模型这个环节一定要用专门训练的Embedding模型。再一个搭配问题是语言匹配。如果知识库是全中文的就选BGE这类中文优化的嵌入模型如果知识库是中英混合的要选支持多语言的模型并适当提高topK因为混合语境下检索精度天然会受一些影响。实际测试里同一个RAG链路只是把嵌入模型从通用多语言模型换成中文专用模型Recallk可以提升十几个百分点这是性价比非常高的优化。6.3 别拿RAG解决所有问题什么时候该放弃它必须承认RAG不是银弹。第一类不该硬上的场景是“通用开放问答”问“怎么学Python”这种问题模型自己的知识就够硬套RAG反而把回答局限在知识库范围内。第二类是实时性要求极高的数据比如股价、天气、库存这些数据即使进了索引也有延迟更适合直接调API。第三类是内容量极少、关系极简单的场景比如就一份百来字的规章直接用Prompt把全文塞进去就行何必拆分成向量检索。还有一类情况要特别提醒如果模型本身能力很弱或者你的知识库质量极差RAG救不了。RAG解决的是“知识获取链路”的问题不是“内容质量”的问题。如果员工手册本身互相矛盾索引建得再好也是垃圾进垃圾出。我做的第一个商业化RAG项目被客户吐槽根因不是检索链路坏了而是知识库源文档没做一致性治理——这个教训值一整篇文章。说回开头的那个问题。到现在我依然会在每次给大模型接新知识库前问自己一遍这套知识到底是不是模型内部已有的如果是直接生成如果不是才认真考虑RAG。不是所有场景都需要RAG但凡是“特定领域、答案藏在文档里、回答必须可追溯”的需求RAG目前就是最靠谱的方案。无论是本地Ollama跑通最小链路还是引入Graph RAG、Agentic RAG做进阶核心思路都相通让模型为了回答去“查资料”而不是“拍脑袋”。 用RAG终结大模型幻觉：从原理到代码的完整指南
你有没有遇到过那种时刻问大模型一个挺正经的问题它一本正经地给你编了一个答案逻辑通顺、头头是道甚至还有“专业术语”加持结果你一查资料全是凭空捏造的。行业里把这种现象叫幻觉Hallucination。说实话我这几年做AI应用开发被它坑过不止一次直到系统性地把RAGRetrieval-Augmented Generation检索增强生成用进项目幻觉问题才算有了真正可落地的解法。这篇内容我打算不绕弯子从“大模型为什么会胡说八道”这个根源讲起再把RAG的离线索引、在线检索、答案生成整条链路拆开给出可以直接抄的代码和选型建议最后聊Graph RAG、Agentic RAG这类进阶方向以及我自己踩过的坑。适合刚接触大模型应用开发、想给自家知识库接上“可问答”能力的工程师也适合准备RAG相关面试、想系统补一遍知识框架的同学。1. 大模型为什么会“一本正经地胡说八道”先搞清楚幻觉的根源先说一个我自己的真实经历。之前做一个企业内部知识库客户要求把几百份技术手册喂给大模型让员工直接对话查参数。原型阶段我随手问了句“XX设备的最高工作温度是多少”模型回答得非常流畅还给了一个看起来特别精确的数值。结果我翻原始手册一核对发现这个数值根本不存在。为什么因为大模型本质上不是一个“数据库”你问它问题它不是去查表而是根据自己学过的所有文本做文字续写。1.1 语言模型的本职工作是“续写”不是“查资料”大模型的底层逻辑是给定前面一段文字预测下一个最可能的token。你问它“北京到上海的高铁最快多久”它内部真正在做的事情是根据“北京到上海的高铁最快”这些前缀去预测后面最像人话的连续输出到底是什么。它知道“约4.5小时”这个答案是因为海量语料里无数篇文章提到过而不是因为它动态查询了铁路时刻表。这就带来两个致命问题。第一训练数据有时间截止点2024年5月才发布的产品、刚刚生效的政策、昨天才更新的参数模型根本没见过只能靠“语感”硬猜。第二长尾知识在语料里出现次数太少模型大概率会把相似信息混在一起比如把A型号的重量安到B型号头上。但凡涉及专业知识问答“自信的胡说”几乎是必然事件。你可以做一个很简单的实验拿一个没微调过的通用大模型问一条你所在行业里非常冷门、但你能百分百确认的细节。十个问题里它至少会编一两个。这不是模型质量问题而是架构本身的限制它把“知识记忆”和“知识推理”耦合在了同一套参数里遇到不熟悉的领域只能靠想象力补全。1.2 靠Prompt约束幻觉效果为什么不稳定既然模型会乱说很多人第一反应是在提示词里加一句“请基于事实回答不要编造”。我在早期项目里也这么干过实测下来对一部分问题有效对另一部分完全无效。无效的那部分恰恰是最危险的因为模型并不是“知道自己不知道”而是“以为自己知道”。你现在让它复述一个烂熟于心的概念它当然不会怀疑自己记得不对于是依然理直气壮地输出错误内容。这就像一个人喝醉了不会承认自己醉幻觉最大的问题不是模型刻意撒谎而是它在自己的“记忆幻觉”里毫无觉察。Prompt约束还有一个硬伤就算模型这次愿意承认“我不确定”它也只是停止输出而已并不能真正帮你找到正确答案。企业知识库场景里用户要的是答案或者可追溯的线索不是一个诚实的“不知道”。所以说靠提示词“堵”幻觉是一条走不通的路核心思路应该是别再让模型凭内部记忆单打独斗而是先给它一份和问题高度相关的、可信的参考材料再让它基于这份材料作答。这就是RAG的核心思想——用外部检索结果钳制生成内容让模型从“闭卷考试”变成“开卷考试”。2. RAG检索增强生成的完整链路从文档到答案的四次关键转换RAG整体可以分成离线索引和在线检索两大部分中间夹着一次关键的用户查询向量化。我习惯把它拆成四个阶段文档加载、文本切块、向量化入库、检索生成。下面逐个说清楚里面每一步到底在干什么、为什么必须这么干。2.1 离线索引清洗、切块、向量化、入库离线索引阶段的目标是把一堆原始文档变成可检索的向量库。首先处理的是文档加载。PDF、Word、Markdown、HTML各有各的坑PDF要处理扫描件OCR表格容易错位Word要抽取正文别把页眉页脚带进去Markdown相对友好但也得去掉代码块之外的噪声。这一步花的时间通常比想象中多我见过不少项目在演示时“看起来能用”一上真实文档就崩八成是加载解析环节没做干净。接下来是文本切块Chunking。很多人不理解为什么不能把整篇文档直接拿去向量化。原因有两个一是嵌入模型的输入长度有限超长文本会被截断二是切块越短每个向量表达的主题越聚焦检索时越容易命中精确位置。反过来块太小又会让上下文不完整一条技术参数被切成两半检索召回一半就废了。这里给出一个可参考的经验值中文场景块大小chunk size设在256到512个字符之间相邻分块重叠overlap10%到15%。为什么要有重叠因为硬按字符切会把一句话从中间劈开重叠区域相当于给上下文加了个“缝合补丁”让上一块末尾的信息在下一块开头再出现一次避免语义断裂。如果你的文档是Markdown或HTML更推荐按标题层级切块把“### 二级标题”作为天然边界这样切出来的每个块内容主题完整检索命中率明显更高。切块之后就是把每一段文本变成向量。这一步会用到专门的嵌入模型比如目前中文场景表现不错的BAAI/bge-m3系列。嵌入模型做的事情是把一段文本映射成一个固定维度的浮点数数组常见的有768维、1024维。原理说起来也不复杂它把语义相近的句子映射到向量空间里距离更近的位置。你可以把它理解为给每段文字算了一套GPS坐标“猫喜欢抓沙发”和“猫咪对家具有抓挠行为”这两句话虽然字面完全不一样但坐标距离很近。向量化完成后会得到一个文本块和向量的映射关系然后全部写入向量数据库。轻量场景用FAISS就够它是Meta开源的一个库直接内嵌在Python进程里要上生产、数据量大到几百万条再用Milvus或Qdrant这种独立服务它们支持分布式和水平扩容。另外如果公司已经有PostgreSQLpgvector也能凑合但别指望高效索引能力对标专业向量库。2.2 在线检索Dense Vector Search 的运作逻辑在线检索阶段用户输入一个问题后系统做三件事把问题用同一个嵌入模型转成向量拿这个向量去向量库里做相似度计算取相似度最高的topK个文本块返回。问题向量和库里的文档向量计算相似度最常用的是余弦相似度。在我上面的例子里嵌入模型在编码时已经做了向量归一化归一化之后用内积Inner Product算出来的结果就等价于余弦相似度省一趟计算。实际项目里向量库底层不会真的一条条暴力比对而是用HNSW这类近似最近邻索引把检索耗时从毫秒级“暴搜”压缩到亚毫秒级代价是极小概率漏掉真正最相似的结果工程上完全可以接受。这里有一个经常被忽略的关键点用户问题也必须经过和文档完全相同的嵌入模型、相同的归一化处理。如果文档用的bge-m3查询却用了另一个模型两个向量根本不在同一个语义空间里检索效果会断崖式下跌。topK的取值也值得琢磨。K太小可能漏掉答案K太大无关上下文又会污染生成结果。我在常规知识库项目里通常取K5如果文档本身碎片化严重会适当调大到8到10再交给下游的重排序模块进一步筛选。2.3 答案生成把上下文交还给模型而不是让它凭记忆硬编检索到相关片段后最后一步是把这些片段作为参考上下文连同用户问题一起拼进Prompt再请求大模型生成答案。这一步的核心在于Prompt模板的设计必须明确告诉模型“如果参考资料里没有答案就直说没有”并且要求它只依据给定资料作答而不是动用自己的世界知识。下面这个模板是我项目里一直在用的简单直接请基于以下参考资料回答问题。如果参考资料中没有答案请直接说“资料中未找到相关信息”不要自行编造。 参考资料 [片段1] [片段2] ... 问题{query} 回答看到没有关键动作有两个一是把检索结果放在模型“眼前”让它照着念二是明确给了“未找到”的逃生通道避免模型为了完成回答硬凑。实际体验下来加了这条“逃生通道”之后模型的拒答率会提高但幻觉率会显著下降对于企业知识库场景宁可不答也不能乱答。到这里一条最基础的RAG链路就已经闭环了。接下来的问题是这条链路到底怎么落地到真实工程里需要选什么框架、跑什么模型、写什么代码。我在下一节给出可以直接抄的完整方案。3. 从零搭一套RAG系统框架选型、本地部署与真实代码很多初学者一上来就纠结LangChain还是LlamaIndex其实在动手之前应该先想清楚一个更底层的问题你的数据量和复杂度到了需要重量级框架的程度吗如果只是几千条文档的Demo项目自己写一百行代码完全够用还能把所有流程控制在自己手里如果要做持续迭代的商业系统再考虑上框架的抽象能力。3.1 框架选型LangChain、LlamaIndex 还是手写我把三者放在一起做过对比各自优劣势非常明显。LangChain是目前生态最全的框架RetrievalQA、MultiQueryRetriever、ConversationalRetrievalChain这些组件开箱即用社区资料多网上随手一搜都是案例。缺点是抽象层级太多排查问题时要一层层扒封装反而增加心智负担。LlamaIndex的定位更聚焦在“索引”这件事上它对文档结构的理解、知识图谱的接入、以及“从文档到结构化索引”这一整个流程做得比LangChain细。如果你的核心诉求是让知识库更接近“数据基础设施”而不是“对话机器人”可以优先考虑LlamaIndex。完全手写则适合学习阶段以及那些对延迟和成本极度敏感、要把每一个环节都仔细调优的团队。它没有框架版本升级的兼容性包袱出问题也好排查。我在给客户做POC概念验证时反而经常手写一个最小实现因为最快、最容易定位问题。如果团队技术栈是Java也不用纠结Python框架Spring AI 2.0里已经提供了RAG相关的抽象和示例VectorStore、QuestionAnswerAdvisor这些组件可以直接对接和Spring Boot的工程化体系融合得很好。3.2 本地化部署Ollama 开源嵌入模型 向量库RAG的一大落地场景是数据敏感的企业内部知识库很多客户明文要求文档不许出内网。这时候本地化部署就是必选项我推荐用Ollama来跑生成模型和嵌入模型轻量、上手快而且安装之后提供了一个和OpenAI兼容的本地接口代码层几乎不用改就能切换。Windows用户装Ollama之后有个高频问题模型默认下载到C盘不一会儿就爆满。解决办法是给Ollama设置一个环境变量OLLAMA_MODELS指定到D盘目录然后重启Ollama服务即可。这个过程不复杂但你不提前设置备份模型文件的时候会非常痛苦。生成模型我用的比较多的是qwen2.5系列7B到14B参数在消费级显卡上都能跑中文能力在开源里是第一梯队。嵌入模型推荐BAAI/bge-m3它对中文长文本的语义理解很稳支持1024维输出而且在检索任务里做了专门优化。如果你想先快速验证效果不折腾本地显卡也可以直接用各家云厂商的免费模型API额度配合同一个RAG链路去跑。本地还是API只影响大模型这层前面的索引和检索逻辑完全不变。3.3 最小可用代码不依赖重量级框架的RAG实现下面这个实现是我给团队做内部培训时用的最小版本。不依赖LangChain只用sentence-transformers做嵌入、FAISS做索引、Ollama的OpenAI兼容接口做生成每一步都可控、可调试。import faiss from sentence_transformers import SentenceTransformer CHUNK_SIZE 300 OVERLAP 50 K 5 EMBED_MODEL_NAME BAAI/bge-m3 def split_text(text: str, size: int CHUNK_SIZE, overlap: int OVERLAP): 按字符切分带重叠窗口避免把关键句拦腰截断 chunks [] start 0 while start size len(text): chunks.append(text[start:start size]) start size - overlap if start len(text): chunks.append(text[start:]) return chunks def build_index(chunks): model SentenceTransformer(EMBED_MODEL_NAME) vectors model.encode(chunks, normalize_embeddingsTrue) index faiss.IndexFlatIP(vectors.shape[1]) index.add(vectors) return model, index def search(model, index, query, kK): q_vec model.encode([query], normalize_embeddingsTrue) scores, idxs index.search(q_vec, k) return idxs[0], scores[0] def build_prompt(query, chunks, idxs): context \n\n.join( f[片段{i1}]\n{chunks[idx]} for i, idx in enumerate(idxs) ) prompt f请基于以下参考资料回答问题。如果参考资料中没有答案请直接说“资料中未找到相关信息”不要自行编造。 参考资料 {context} 问题{query} 回答 return prompt然后调用Ollama本地模型from openai import OpenAI client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama, # Ollama本地接口不校验key占位即可 ) def ask_with_rag(query, doc_text): chunks split_text(doc_text) model, index build_index(chunks) idxs, scores search(model, index, query) prompt build_prompt(query, chunks, idxs) resp client.chat.completions.create( modelqwen2.5:7b, messages[{role: user, content: prompt}], temperature0.2, ) answer resp.choices[0].message.content sources [chunks[i] for i in idxs] return answer, sources这段代码看着简单但已经把索引、检索、生成三个核心环节全覆盖了。注意几个细节embedding编码时设了normalize_embeddingsTrue这样后面用FAISS的IndexFlatIP就算内积等价于余弦相似度生成时temperature设到0.2尽量压低随机性因为知识问答场景要的是稳定和准确不是花哨。实际项目里你还需要把chunks缓存起来每次查询都重新切分、嵌入是很大的浪费正确做法是文档变化时增量更新索引。3.4 用LangChain实现的对比版本如果你想用LangChain快速迭代代码会更简洁但内部逻辑完全一样。核心区别在于LangChain把DocumentLoader、TextSplitter、VectorStore、Retriever、LLM这些组件全抽象成了统一接口替换组件只需改一行配置。from langchain_community.embeddings import HuggingFaceBgeEmbeddings from langchain_community.vectorstores import FAISS from langchain_community.llms import Ollama from langchain.chains import RetrievalQA from langchain_text_splitters import RecursiveCharacterTextSplitter # 1. 切分 splitter RecursiveCharacterTextSplitter( chunk_size300, chunk_overlap50, separators[\n\n, \n, 。, , ], ) chunks splitter.split_text(doc_text) # 2. 向量化 入库 embeddings HuggingFaceBgeEmbeddings(model_nameBAAI/bge-m3) vectorstore FAISS.from_texts(chunks, embeddings) # 3. 组装检索问答 llm Ollama(modelqwen2.5:7b, temperature0.2) qa RetrievalQA.from_chain_type( llmllm, retrievervectorstore.as_retriever(search_kwargs{k: 5}), return_source_documentsTrue, ) result qa.invoke(你的问题)RecursiveCharacterTextSplitter里的separators参数值得细看它先按“连续换行、单个换行、句号、逗号、空格”的优先级去切能最大程度避免把完整句子劈成两半。对于中文场景在separators里加入“。”和“”非常有效比我之前傻傻按字符硬切的效果好很多。4. 当基础RAG不够用混合检索、Graph RAG 与 Agentic RAG跑通基础RAG只是开始。真实业务里文档形态千奇百怪问题类型多种多样纯向量检索会碰壁专业编号查不准、多跳问题答不全、需要反复检索的场景会“卡壳”。所以进阶方向要了解清楚。4.1 混合检索与重排序召回质量提升的第一步先说检索召回里的一个经典问题向量检索擅长语义匹配但它对精确关键词不敏感。你搜索“H3C-S5120V2-28P”这个交换机型号向量化之后可能把“H3C”和“S5120”都当成语义特征处理结果召回一堆“H3C其他型号”的片段精确编号反而排名靠后。解决办法是引入稀疏检索。稀疏检索的代表是BM25它通过词频和逆文档频率计算文本和查询的字面匹配程度对精确型号、编号、人名这类强标识符非常友好。工程上的标准做法是混合召回把BM25检索结果和Dense向量检索结果都取回来合并去重后再用一个Reranker模型做精细排序。Reranker和普通嵌入模型最大的区别在于嵌入模型是一次性把所有文档向量化再用向量距离衡量相似度速度快但精度有上限Reranker则是把query和每一篇候选文档拼在一起用cross-encoder方式逐对打分精度高很多但计算开销大。所以Reranker只用来精排前几十条候选不负责海量粗筛。实践里我常用的组合流程是BM25取top50 Dense Vector Search取top50 → 合并去重 → Reranker取top5 → 送入大模型。这个流程已被验证能显著提升答案命中率和最终回答的稳定性尤其是那些夹杂大量专业名词的行业文档效果几乎立竿见影。4.2 Graph RAG让多跳问题有谱可依基础RAG还有一个结构性问题它把每个文本块当成独立片段难以表达“片段之间谁影响谁、谁依赖谁”。当用户问的问题需要跨多个文档做推理时比如“A项目用了哪些B项目的模块”普通向量检索只能分别召回A项目文档和B项目文档但这些文档之间的关联关系根本没建立起来答案自然残缺。Graph RAG的思路是先从文档里抽取实体和关系比如“模型A”“部署环境B”“依赖关系C”构建成一张知识图谱然后在图谱上做检索和多跳推理。它和图数据库天然契合这也解释了为什么“graph rag图搜索”会成为热门搜索词。还记得搜到的“ontology rag”吗它在图谱构建前先定义一套本体约束也就是规定好“哪些实体类型、哪些关系类型是合法的”能有效过滤掉文本抽取时的噪声让图谱更干净。开源生态里微软开源的GraphRAG方案已经能直接用来搭建“文档 → 实体关系图谱 → 社区总结 → 检索问答”的完整链路虽然资源开销比普通RAG大不少但面对“关系密集型”的知识库比如组织架构、供应链、故障传播链值得投入。4.3 Agentic RAG从“查一次”到“想清楚再查”如果说Graph RAG解决的是“怎么把关系找全”Agentic RAG解决的就是“该不该查、查几次、查完怎么处理”。普通RAG是一次性检索、一次性生成属于“单轮开卷考试”Agentic RAG则让大模型扮演一个智能体自己决定整个检索策略。一个典型场景用户问“帮我对比这三款产品的授权协议区别”。普通RAG很可能只根据用户问题里的模糊语义检索到某几段相关文本然后就生成答案了三款产品的信息可能只覆盖了一款半。Agentic RAG会怎么做呢它会先规划先分别查产品A、B、C各自的协议段不够就再查“对比”相关的信息最后把检索结果汇总成一个对比表格。落地方式主要有三种模式。第一种是Router模式模型先判断问题类型是闲聊直接回答是知识问答才走检索第二种是Retriever Tool模式把检索封装成一个工具模型在需要时主动调用可以调多次、每次换不同的查询词第三种是Self-RAG模式模型在生成过程中不断自我评估“查到的资料够不够支撑回答”不够就重新生成更合适的查询继续查。我把Agentic RAG看作“RAG ReAct”的组合。实现时可以基于LangChain的Agent框架也可以自己定义工具调用循环。这里最大的坑不是技术实现而是策略设计如果不给智能体设置检索次数上限它会陷入无限循环延迟和成本都会爆炸。我一般设置最大3轮检索超过就强制进入生成阶段。5. RAG效果测评到底好不好不能靠感觉做RAG项目最怕听到的一句话是“感觉效果还行”。感觉不靠谱尤其是幻觉率这种指标人工抽几条问答根本看不出真实水平。要让系统持续迭代必须把评价体系建立起来。5.1 三个测量维度检索、生成、端到端RAG的效果可以拆成三个独立的层面每一层都要单独测。检索层看召回质量判断“该找到的片段有没有被找到”。常用指标包括Recallk、Precisionk、MRR和NDCG。其中Recallk最重要因为生成层的上限被检索层锁死——如果正确答案压根不在召回的片段里生成模型再强也无能为力。生成层看答案质量判断“模型读着这些片段有没有忠实作答”。核心指标是Faithfulness忠实度也就是生成答案里的信息是不是都能从参考片段里找到依据。这根指标直接对应幻觉率是RAG项目里最应该盯的一个数字。除此之外还要看答案相关性和事实正确性。系统层则要看端到端的可用性问题是否被有效回答、回答延迟、每次请求的token成本、引用来源可验证率。这层指标决定了产品能不能真正上线。5.2 从指标到工具RAGAS和人工评测集手动算这些指标很痛苦好在社区已经有了RAGAS这个开源评测框架。它的思路是用大模型来评估大模型给定问题、参考答案、检索到的上下文片段、生成的最终答案RAGAS能自动算出Context Precision、Context Recall、Faithfulness、Answer Relevancy四类分数。实际用下来和人工标注的相关性相当高可以作为日常迭代的“仪表盘”。但RAGAS这类工具有一个前提你需要一份高质量评测集。我的经验是至少准备50到100条评测问题并且覆盖三类第一类是答案明确在文档里的原始问题验证基本查找能力第二类是跨段落、跨文档的多跳问题验证检索链条第三类是“资料里根本没有答案”的对抗问题专门测模型会不会硬编。第三类是幻觉检测的重中之重因为用户问出知识库范围外的问题系统能不能正确拒答直接决定可信度。5.3 一个可落到团队里的评测流程我现在团队里的做法很简单一共四步第一步建评测集。让业务方提供真实高频问题加上我们补充的对抗问题做到100条左右。每条问题配套标准答案以及禁止答错的“红线问题”。第二步跑多个候选配置。在分块大小、topK、是否用Reranker、不同Embedding模型这些维度上组合出至少三到五组配置全部跑一遍评测集用RAGAS算出指标。第三步人工抽检。自动指标跑完人工再抽20条看输出重点看模型有没有“聪明地拒绝”、有没有引用正确来源、有没有在前置对话里被“带偏”。第四步坏case回归。把评测中发现的Bad Case列入回归集每次改完索引策略、提示词之后重新跑一遍防止改了A问题又搞坏B问题。这套流程建好之后RAG系统才能从一个“实验脚本”变成一个“可维护的产品”。我见过太多项目死在“改一下分块、重新测两条、看起来好了再改回来”的循环里根本原因就是没有评测集兜底。6. 踩坑复盘我把这些教训写在代码注释里最后这一节说说我自己在RAG项目里踩过最狠的几个坑也顺手把规避方法写清楚。这些都是文档里不会细讲、但实战中一定会遇到的东西。6.1 分块大小和重叠窗口是第一个坑最初做知识库时我图省事把chunk_size设为1024字符想着“每块信息越全越好”。结果检索回来的片段经常包含大量无关内容模型生成的答案被噪声带着跑Faithfulness指标惨不忍睹。后来我把尺寸调到256到512之间问题大幅缓解。还有一次我把chunk_overlap调到了0想着“少存点重复数据省钱”。结果一个涉及代码块的技术文档里函数的签名刚好被切在上一块末尾注释和实现全在下一块检索命中后上下文断裂答案看着就像半句话。从那以后我再也不敢不设重叠。真正的解法是结构化切块先尝试按Markdown标题切再对大段正文按段落切最后才用字符窗口兜底。一句话分块不是纯技术参数而是和你的文档结构强相关的设计决策。6.2 嵌入模型和生成模型的搭配有讲究另一个容易踩的坑是把“聊天厉害”的模型直接拿来做Embedding。曾经有同事想把GPT级别的大模型同时用来向量化和生成结果检索回来一堆语义相似但实质无关的内容原因就是通用聊天模型的输出分布面向文字生成并不适合做语义匹配的向量表达。嵌入模型这个环节一定要用专门训练的Embedding模型。再一个搭配问题是语言匹配。如果知识库是全中文的就选BGE这类中文优化的嵌入模型如果知识库是中英混合的要选支持多语言的模型并适当提高topK因为混合语境下检索精度天然会受一些影响。实际测试里同一个RAG链路只是把嵌入模型从通用多语言模型换成中文专用模型Recallk可以提升十几个百分点这是性价比非常高的优化。6.3 别拿RAG解决所有问题什么时候该放弃它必须承认RAG不是银弹。第一类不该硬上的场景是“通用开放问答”问“怎么学Python”这种问题模型自己的知识就够硬套RAG反而把回答局限在知识库范围内。第二类是实时性要求极高的数据比如股价、天气、库存这些数据即使进了索引也有延迟更适合直接调API。第三类是内容量极少、关系极简单的场景比如就一份百来字的规章直接用Prompt把全文塞进去就行何必拆分成向量检索。还有一类情况要特别提醒如果模型本身能力很弱或者你的知识库质量极差RAG救不了。RAG解决的是“知识获取链路”的问题不是“内容质量”的问题。如果员工手册本身互相矛盾索引建得再好也是垃圾进垃圾出。我做的第一个商业化RAG项目被客户吐槽根因不是检索链路坏了而是知识库源文档没做一致性治理——这个教训值一整篇文章。说回开头的那个问题。到现在我依然会在每次给大模型接新知识库前问自己一遍这套知识到底是不是模型内部已有的如果是直接生成如果不是才认真考虑RAG。不是所有场景都需要RAG但凡是“特定领域、答案藏在文档里、回答必须可追溯”的需求RAG目前就是最靠谱的方案。无论是本地Ollama跑通最小链路还是引入Graph RAG、Agentic RAG做进阶核心思路都相通让模型为了回答去“查资料”而不是“拍脑袋”。