先打一个比喻大模型像一个参加过海量知识竞赛的全能选手你问他光合作用的原理是什么他能一口气给你翻出教科书上的标准答案但如果你问我们公司昨天发布的新产品手册第17页的规格参数是多少他大概率会愣住然后开始一本正经地编。原因很简单他脑子里装的是训练截止日期之前的世界而 RAGRetrieval-Augmented Generation检索增强生成的出现就是给这位选手配了一个随时可翻阅的资料库让他从闭卷考试变成开卷考试。RAG 和大模型的关系这两年已经被聊得很高频了。但我在给企业做知识库、带团队落地大模型应用的过程中发现真正能把两者关系讲透的人并不多。很多人以为 RAG 就是先把文档喂给大模型再提问实际上远不止这么简单。这篇内容不会只给定义我会从原理、链路、落地、排错到选型把 RAG 与大模型之间的核心关系一次性拆开。适合正在做知识库问答、智能客服、文档分析或者只是单纯想搞懂这个热词背后逻辑的朋友。1. 两个学霸的分工先把RAG与大模型的本质掰开看1.1 大模型的本质一个闭卷考试的记忆型选手大模型本质上是一个在超大规模语料上做预训练的神经网络它的所有知识都以参数的形式压缩在模型内部。无论是 GPT 系列、开源社区的 Qwen、Llama还是国内各家商业模型核心机制都是一样的训练阶段见过海量文本推理阶段根据上下文预测下一个 token。这个机制带来一个很关键的特性——大模型的回答依赖的是训练时见过的统计规律。它学到的不是一份可以随时查阅的数据库而是一套概率分布。所以它能写出逻辑通顺、风格自然的回答也会在一些具体事实上翻车。你可以把大模型理解为一个阅卷无数的学霸他有很强的答题能力但他记忆里的世界是固定的不会因为你给他看了新资料就实时更新。这也解释了为什么大模型在通用问答、文本改写、代码生成、头脑风暴这些任务上表现惊艳但一旦涉及实时信息、企业内部私有文档、长尾专业数据就会显得力不从心。它并不理解事实与虚构的边界只是根据概率输出最顺滑的文本。如果你不给他足够的证据他会用最自信的语气把猜测说得像事实。1.2 RAG的本质一套开卷考试的检索外挂RAG 并不是一个新的大模型而是一种把检索和生成组合起来的架构模式。它的核心思路很直白在模型回答之前先从外部知识库中检索出与问题最相关的若干文本片段把这些片段作为上下文塞进提示词再让大模型基于这些资料生成答案。整个过程大致分成三段索引阶段把文档切块、向量化、存入向量数据库构建一个可供检索的外部知识库。检索阶段把用户问题转成向量从知识库中召回最相关的 Top-K 片段。生成阶段将检索到的片段和原始问题一起交给大模型让模型看着资料作答。这里的关键在于RAG 不改变大模型内部的任何参数。它做的是临场给资料让模型在生成时有了可以引用的上下文从而大幅度提升回答的准确性和时效性。这也是它被称为检索增强的原因——增强的是生成过程的信息供给而不是模型本身的记忆。1.3 两者不是竞品而是脑子和参考书的关系很多人会把 RAG 和大模型当成两条可以互相替代的技术路线这是最大的误解。实际上它们更像是脑子和参考书的关系大模型负责理解、推理和表达RAG 负责给它提供当下需要的素材。没有大模型RAG 检索出来的内容只是一堆文本没有 RAG大模型面对动态信息只能靠猜。我在企业项目里经常用一个比喻来解释两者的分工大模型是员工RAG 是文档柜。员工能力强不强取决于模型本身的水平但员工能不能准确回答公司内部问题取决于他能否快速查到正确的那份文件。你不可能要求员工把所有文件都背进脑子里也不可能把文件放在那儿不让他看就指望他答对。RAG 解决的正是在正确的时间把正确的资料送到模型面前这个问题。2. 大模型天生有三个短板RAG恰好补上的正是这些2.1 知识截止日期无法回答今天的事情大模型的训练语料有一个明确的收集时间点。训练完成之后它的知识就凝固了。哪怕你用的是最新最强的模型它也不知道发布日之后发生的新事件、新政策、新产品参数。比如我今年做某个新项目时客户问的是上月刚发布的内部采购流程最新版文档在内部 Wiki 上而大模型训练时根本没见过这份文档。这种情况下无论你怎么追问模型都无法给出正确答案。RAG 对这个问题几乎是天然解法。因为外部知识库是可以在服务运行期间随时更新的新增一份 PDF、改一条产品数据、同步一篇最新的运营日报检索链路立刻就能感知。用户提问时系统会把最新文档切片、向量化之后检索出来再交回给大模型。知识库一变回答就跟着变不需要重新训练模型也不需要等下一次迭代发布。2.2 幻觉问题一本正经地胡说八道幻觉是大模型最头疼的问题之一。因为生成机制本质上是对下一个 token 的概率采样模型为了生成通顺的回答会在不知道答案时编造看起来合理的内容。更危险的是这种编造往往语气坚定、细节丰富用户很难凭直觉分辨真假。比如让模型总结某篇不存在的论文它能给你列出作者、年份和结论让模型回答一个公司内部制度的细节它能编出完全不存在的条文。RAG 能显著缓解幻觉是因为它给模型提供了检索到的证据片段并在提示词中明确要求仅根据给定资料回答不要编造不在资料中的信息。有了这个约束模型从自由发挥变成了基于证据作答。但这不意味着 RAG 能 100% 消除幻觉——如果检索到的资料本身是错的或者提示词没有约束到位模型依然可能把噪声当成事实。所以 RAG 不是幻觉的银弹而是把幻觉风险从必然发生降低到了可控范围。2.3 私有和垂直领域知识大模型根本没见过大多数企业的核心知识——SOP、产品手册、工程图纸、客户案例、历史项目复盘——都不在互联网公开语料里。通用大模型对它们的了解约等于零。就算这些知识碰巧被写进了训练数据也是极少量的模型根本无法稳定、精确地复用。同时垂直领域还有很多独特术语和表达方式通用模型对这些内容的生成质量往往很飘。RAG 在这里发挥的作用是把私有知识导入模型的回答流程。你不需要把这些资料拿去训练大模型只需要把它们切块、建立索引、存入外部知识库。提问时系统检索出与问题相关的片段大模型就相当于开卷阅读了一份它从未见过的内部文档。这个特性让 RAG 成为企业私有化知识库建设的最主流方案也是为什么知识库这个关键词会跟 RAG 牢牢绑定在一起。下表可以快速回顾这三个短板与 RAG 的对应关系大模型短板典型表现RAG 的解法知识截止不知道新事件、新文档、新参数外部知识库实时更新问答时检索最新片段幻觉编造事实、伪造引用、自信胡说用检索片段约束生成要求无资料就说不知道私有领域知识缺失不懂企业内部文档和垂直术语把私有文档切块入库检索后注入上下文3. RAG全链路拆解从入库到出答案每个环节都在影响结果3.1 索引阶段先让知识住进能检索的房子初次接触 RAG 的人往往会把精力全放在模型选择和提示词上却忽略了真正决定上限的是知识库怎么建。索引阶段决定了你的知识能不能被检索到也决定了检索出来的内容是否完整可用。第一步是文档加载。PDF、Word、Markdown、HTML、TXT 是最常见的输入。这里有个容易被低估的坑不是所有文档都能被直接解析。扫描版 PDF 需要先做 OCRWord 里有复杂表格时需要保留结构PPT 和图片里的文字要走多模态识别。很多团队在第一步就丢掉了大量有效信息后面再怎么调都救不回来。第二步是文本切分。你可以把整份文档直接丢进去但实际效果非常差。因为大模型的上下文窗口有限检索单元过大会导致一个片段里混杂太多无关信息回答时会显得散切分单元过小又会把连续的语义切断模型拿到的只是碎片。常用策略是设置一个 chunk_size比如 300-800 字和 chunk_overlap比如 50-100 字或者按文档自带的结构标题切分。我自己的经验是技术文档按章节切法律法规按条款切问答类内容按单条记录切而不是一刀切地按固定字数处理。第三步是向量化。切好的文本片段要通过 Embedding 模型转成向量。这里需要重点选择 Embedding 模型通用领域可以用 OpenAI 的 text-embedding 系列、开源的 BGE 系列或 M3E 系列中文垂直领域尤其是有较多专业术语的场景建议用针对该领域微调过的向量模型。向量模型的维度决定了向量库的规格BERT 类模型常见是 768 维大规模检索时你需要考虑存储和检索成本。第四步是存储索引。向量数据库有 FAISS、Chroma、Milvus、Qdrant、pgvector 等多个选择。从轻量级项目到企业级分布式检索选型差异很大。除了向量索引很多团队会同时建立倒排索引用于后续的混合检索。切分后的文本块还要保存元数据比如来源文档、页码、章节标题等这些信息在后面回答追溯和引用标注时非常关键。3.2 检索阶段把最相关的片段准确捞出来检索是整个 RAG 链路里最容易被低估的环节。很多人以为向量检索就是无敌的实际跑起来会发现用户的问题是一句口语化的描述知识库里的答案是书面化的、包含大量同义词和缩写纯向量检索经常抓不准。一个更稳健的做法是混合检索。向量检索擅长处理语义相近但措辞不同的问题BM25 这种稀疏检索则擅长精确命中专业术语、型号编号、人名地名。两者结果合并后再交给重排模型。我先说说我在项目里常用的链路先把原始问题做一次改写比如帮我查一下上个月华东区的退款率改写为查询华东区上个月的退款率数据然后同时跑向量检索和关键词检索合并结果后再由一个 Rerank 模型如 BGE-reranker、Cohere Rerank对候选片段打分只保留 Top 3-5 个给大模型。这里有一个参数需要格外注意Top-K。K 设得太小容易漏掉重要信息K 设得太大会往上下文里塞入大量噪声反而干扰大模型生成。我从经验上建议如果采用检索后重排的方案前期召回可以取 20-50 条重排后取 3-5 条作为最终上下文。如果你不做重排直接取 5 条以下可能更稳妥。检索还有一个进阶玩法是知识库路由。当系统里挂了多个知识库时比如一个放产品文档、一个放运维手册、一个放客服话术你需要先让大模型判断这个问题该查哪个库或者用分类器做路由。这么做的意义在于缩小检索范围、提升命中率避免跨库检索时把完全无关的内容也捞进来。3.3 生成阶段让大模型看着资料作答检索到的片段最终要交给大模型生成阶段的设计同样决定回答质量。这里最核心的是提示词结构。一个典型的 RAG 提示词包含三个部分角色设定、检索资料、用户问题。尤其重要的是在提示词里明确约束生成行为。我会在 system prompt 里强调三点优先使用提供的资料不要使用资料之外的知识。如果资料中没有答案直接告诉用户未检索到相关内容不要猜测。尽量标注信息出处让用户知道答案来自哪份文档的哪一节。生成阶段还需要考虑引用溯源。很多产品要求答案后面附带参考来源让用户点击跳转到原文。要做到这一点需要在检索阶段记录每条片段对应的文档名和页码并在生成时要求大模型引用片段编号。这不仅是产品体验问题也是建立信任的关键。用户看到答案 引用后对系统判断的信任度会明显提升。生成阶段另一个容易忽略的点是上下文压缩。检索回来的片段有时很长可能超过上下文窗口或者占据大量 token 导致成本飙升。可以考虑对检索片段做一次抽取式摘要只保留与问题最相关的句子再交给大模型。我在处理超长技术文档时就遇到过这种情况检索命中了文档里的一个大章节里面有一大段背景介绍把上下文塞得满满当当。加上一个轻量级的上下文压缩步骤之后回答的准确率和接口响应速度都明显提升。4. 落地RAG的四种姿势自己写、用框架、拖平台、本地部署4.1 从零手写最轻量的 RAG 脚本长什么样最好的理解方式永远是动手写一遍。这里我给出一个非常简化的 Python RAG 流程示意没有依赖重型框架核心目的是让你看清 RAG 的数据流# 1. 加载并切分文档 from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter loader PyPDFLoader(product_manual.pdf) documents loader.load() splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) chunks splitter.split_documents(documents) # 2. 向量化并写入向量库 from sentence_transformers import SentenceTransformer import chromadb encoder SentenceTransformer(BAAI/bge-large-zh-v1.5) client chromadb.PersistentClient(path./chroma_db) collection client.get_or_create_collection(knowledge_base) for idx, chunk in enumerate(chunks): collection.add( ids[str(idx)], embeddings[encoder.encode(chunk.page_content).tolist()], documents[chunk.page_content], metadatas[{source: chunk.metadata.get(source, )}] ) # 3. 检索 query 产品支持的最大并发连接数是多少 query_vec encoder.encode(query).tolist() results collection.query(query_embeddings[query_vec], n_results5) # 4. 构造提示词并调用大模型 from openai import OpenAI context \n\n.join(results[documents][0]) prompt f仅根据以下资料回答问题资料中没有的信息请明确说不知道。 资料 {context} 问题{query} client OpenAI(base_urlhttp://localhost:11434/v1, api_keyollama) response client.chat.completions.create( modelqwen2.5:7b, messages[{role: user, content: prompt}] ) print(response.choices[0].message.content)这段代码虽然简化了很多细节但完整展示了 RAG 四个核心步骤。自己手写的好处是你对每个环节都有完全的控制力坏处是生产环境里还要处理并发、权限、增量更新、日志、评测、多知识库路由等问题全部从零造轮子会非常耗时。所以我通常建议初学阶段手写一个最小 Demo 来建立直觉生产项目还是优先考虑框架或平台。4.2 用现成框架LangChain 和 LlamaIndex 帮你省掉大量底层工作LangChain 和 LlamaIndex 是目前最主流的两个 RAG 框架。它们把文档加载器、文本切分器、向量数据库适配、检索器、重排器、提示词模板都封装成了组件你可以在几十行代码内拼出一条完整的 RAG 链路。框架的价值不只是帮你少写代码更重要的是它抽象了一套统一接口今天用 Chroma明天换 Milvus改动很小今天用 OpenAI明天换本地模型也只需要替换一个组件。在实际项目中我更多把 LangChain 当作胶水层来用用它的 DocumentLoader 统一管理不同格式的文档用它的 Retriever 接口对接不同的向量库和检索策略再用它的 Chain 机制把检索和生成串联起来。LlamaIndex 则在文档索引和结构化数据上更精细尤其是它对文档层级结构和元数据的处理更细适合做知识密集型场景的工具。两个框架都不完美但都比从零手写要稳太多。4.3 低代码平台Dify、FastGPT、RAGFlow们解决的真正问题如果团队里没有专业开发人员或者你需要快速验证一个业务场景低代码平台往往是最高效的选择。Dify、FastGPT、RAGFlow 这类平台把知识库管理、文档解析、文本切分、向量检索、模型调用、工作流编排都做成了可视化界面。你可以上传文档、选择 Embedding 模型、调大模型 API、配置提示词然后在平台上直接创建一个可对话的 RAG 应用。这些平台真正的价值在于把最佳实践内置进系统。比如 RAGFlow 在文档解析环节做了大量工作对复杂版式的 PDF 支持很好Dify 的工作流引擎允许你在 UI 里串联意图识别 - 多知识库检索 - 重排 - 生成这样的复杂逻辑。我用 Dify 给一个中小客户做过客服助手从数据准备到上线只花了一个下午这在纯编码路线上是不敢想象的。当然平台也有锁定的问题深度定制、性能调优、私有化部署的成本需要提前评估。4.4 本地化私有部署数据不出内网的 RAG 方案很多企业对数据合规要求极高文档不能出内网大模型 API 也不能直接调用外部服务。此时就需要一套完全本地化的 RAG 方案。典型组合是Ollama 运行开源大模型如 Qwen、Llama、DeepSeek 系列 本地向量数据库Chroma、Milvus 或 pgvector 本地 Embedding 模型。所有环节都在内网完成数据不出门。这里有一个很现实的建议本地部署大模型不是越强越好而是要匹配硬件预算。一个 7B 参数的量化模型在普通消费级显卡上就能跑得不错一个 70B 模型则需要多张高端显卡。RAG 的优势在于你可以用相对小的模型 高质量检索达到接近大模型的效果。因为模型的推理负担被检索减轻了它不需要记住大量细节只需要做好阅读理解。我帮客户做的很多私有化项目最终落地时甚至只用了一个 13B 或 7B 模型配合精心调过的检索链路效果已经足够满足业务需求。四种落地方式的选型对比可以画一张表方案优点缺点适用场景从零手写完全可控、理解最深开发量大、维护难学习、极简原型LangChain / LlamaIndex省事、组件丰富、切换灵活封装层学习成本、排查链路复杂中小型生产项目、有开发团队Dify / FastGPT / RAGFlow快速上线、内置最佳实践定制受限、依赖平台原型验证、业务人员自助搭建Ollama 本地向量库数据合规、成本可控受硬件限制、模型能力有限企业私有化、敏感数据场景5. 为什么你的RAG检索对了答案还是错六个最容易翻车的环节5.1 文档切分不合理一个表格碎成八块上下文全丢了很多 RAG 项目第一次 Demo 效果不错一上生产就崩最常见的原因就是切分策略有问题。比如一个技术参数表格被固定字数的切分器拦腰截断导致连接数上限和10000这两部分被分到不同的 chunk 里。模型检索到了前半个表格却看不到数字。类似的问题也会出现在代码示例、多级标题和列表场景。我现在的做法是优先识别文档结构标题层级、段落、表格、列表各自有对应的切分逻辑没有明显结构的纯文本再用固定 chunk_size overlap 做兜底。切分之后还要做一次完整性检查比如表格块是否完整、代码块是否包含开始和结束标记。这一步花费的时间不多但对最终的检索质量影响非常大。5.2 向量模型选得不合适语义相似不等于领域相关向量检索的本质是语义相似度但不同向量模型对相似的理解差别很大。通用向量模型在新闻、百科类文本上表现不错但面对企业内部的工程术语、行业黑话、多语言混排文本效果经常不尽人意。比如异常告警和故障通知在通用语义模型看来相似度很高但在运维知识库里二者可能对应完全不同的处理流程。解决思路有两个一是尽量选择与业务领域匹配的开源向量模型中文场景可以考虑 BGE 系列、M3E 系列、text2vec 系列二是收集一批典型的用户问题构建一个小规模的领域评测集对比不同 Embedding 模型的实际检索命中率。后者才是真正靠谱的做法因为模型档位说明写得再好也不如在自己数据上跑一遍来得直接。5.3 只用向量检索丢掉关键词这把利器向量检索擅长处理语义相似但表达不同的查询但它对精确匹配并不敏感。举个例子用户问如何升级到 v2.3.1 版本向量化后v2.3.1这个版本号可能被稀释在整句话的语义里导致召回结果不准确。还有工单号、产品型号、缩写、人名、Base64 编码等字符型信息向量模型的表现往往不如传统的倒排索引。最稳妥的方案永远是混合检索向量检索负责语义召回BM25 或 Elasticsearch 负责关键词精确匹配最后把两路结果加权合并。你可以把混合检索理解为语义 字面双保险。做过检索系统的朋友应该都有体会实际线上查询里既有大意相同的需求也有必须一字不差的需求两者缺一不可。5.4 没有重排环节召回20条里前5条其实是垃圾向量检索和 BM25 得到的 Top-K 结果顺序并不一定代表最相关的就在最前面。尤其是混合检索之后不同来源的结果直接拼接排序质量通常很差。如果不加处理只取前几条可能把一个次要相关片段送进大模型而真正有用的资料排在后面被丢弃。Rerank 模型交叉编码器专门解决这个问题它对每一条候选片段和用户问题做精细的相关性打分而不是像向量检索那样把问题、文档分别编码再算相似度。我的习惯是召回 20-50 条候选用 Rerank 重排后取 Top 3-5 条进入生成阶段。这样可以明显提升答案的准确性。唯一的顾虑是 Rerank 会带来额外的计算开销但在大多数业务场景中这个成本是值得的。5.5 提示词把资料变成了干扰即使检索出来的片段是正确的如果提示词设计有问题大模型依然可能答错。我见过一种很典型的失败模式开发者把检索到的所有片段一股脑塞进提示词结果上下文里有 80% 的内容和问题无关模型被这些噪声带跑偏给出的答案好像什么都说了一点又什么都没说到。这在检索质量不高、Top-K 取太大的时候尤其明显。我的提示词设计原则是明确告诉模型资料中可能包含无关内容请只依据与问题相关的部分回答如果资料互相矛盾让模型指出冲突而不是强行二选一资料不足时明确输出未找到相关信息。同时把问题和资料之间的分隔符做得足够清晰让模型能区分哪些是待回答的问题、哪些是需要参考的材料。5.6 没有一套评测集改完不知道是变好还是变坏RAG 项目的迭代非常依赖评测。很多团队上线之后只是人工抽测几个问题凭感觉判断效果感觉变好了就发版。但 RAG 链路里每一个环节的改动——换 Embedding 模型、改切分参数、调重排阈值、改提示词——都可能同时影响多个维度。没有稳定的评测集你根本说不清改动是在提升还是伤害效果。我建议每个 RAG 项目从第一天就开始积累评测问题集最好按业务类型分层常见问题 30 条、复杂多跳问题 20 条、边界情况 10 条。每个问题标注标准答案和关键来源文档。评测指标方面检索环节看重召回率、MRR、命中率生成环节更关注答案正确率、引用准确率、幻觉出现率。用这套评测集跑完一批变更再决定要不要上线比感觉有效要可靠得多。6. RAG的边界与下一步微调、长上下文、多模态和Agent化6.1 RAG和微调不是二选一而是组合拳我在文章开头说过RAG 不改变大模型参数。那如果需要改变呢比如你希望模型始终用某种固定的客服话术回复、希望它学会某种特殊输出格式、希望它掌握某个领域的思考方式这时候就需要微调Fine-tuning。微调是在模型内部调整权重让模型本身学会某种行为模式。合理的判断标准要看数据属性。如果数据是知识点层面的比如产品参数、政策条款、项目记录适合 RAG因为这类信息更新频繁用外部知识库可以随时改如果数据是行为模式层面的比如希望模型从特定角度回答问题、输出风格更像某个品牌、擅长解析某种行业表格适合微调因为这种能力对几乎每次生成都生效。实际项目里最常用的是组合方案先对基础模型做一次领域微调让它理解行业术语和回答风格然后在生产环节用 RAG 不断喂入最新知识。这样既有了专业素养又有了实时查资料的能力。两边的侧重点不同并不冲突。6.2 长上下文时代RAG还会被取代吗近两年大模型的上下文窗口一路飙升有的已经支持几十万甚至上百万 token。很多人开始讨论既然模型一次能看完那么长的内容是不是直接把文档全塞进去就行不需要 RAG 了我的看法是窗口变大确实能缓解一部分简单场景的压力但距离替代 RAG还有不小的距离。至少有三个现实问题第一成本。每次请求都带几十万字token 费用和延迟都会暴涨业务上很难接受第二大海捞针效应。即使模型有长窗口序列越长它对中间细节的关注度越低很容易忽略埋藏在长文里的关键信息第三权限和更新。你不可能每次文档更新都重新拼接整个上下文池也不可能为每个用户组装一份包含所有文档的超长上下文。RAG 用只捞最相关片段的策略以很小的成本实现了精准的知识供给在工程上依然是最优解。6.3 多模态RAG与RAG智能体下一代形态RAG 的边界正在从纯文本向多模态扩展。文档里的图片、表格、流程图、音视频都能成为检索对象。比如一份设备维护手册里有大量结构图你希望用户问根据图示如何更换滤芯时模型能够检索到对应图片并给出图片文字结合的答案。这就需要多模态文档解析、多模态 Embedding 和视觉语言大模型配合也就是多模态 RAG。另一个重要方向是 Agent 化。传统 RAG 是一次单轮检索生成而 RAG Agent检索增强智能体可以多轮规划它先判断这个问题需要哪些信息再多次调用检索工具一步步收集证据甚至临时生成检索请求、反思结果缺失继续第二轮检索。这种形态在复杂推理、多跳问答场景下效果提升明显比如对比 A 和 B 两款产品的售后政策差异并给出最近三个月哪款口碑更好——这类问题需要跨多个文档、多次检索、综合推理。作为收尾我把目前在实际项目中摸索出的一个体会放在这里RAG 和大模型的关系本质上是知识供给与智能内核的耦合。决定一个知识库问答系统能不能用的往往不是大模型本身多强而是检索链路是否扎实、知识库治理是否到位。如果你正在做 RAG 项目我的建议是先把精力放在文档解析、切分、检索和评测上模型可以往后放一放。把资料库管好把检索调准再配上合适的生成策略你会发现哪怕一个 7B 的本地小模型也能在企业场景里交出让人惊喜的答卷。 
长河君 · 2026/10/31 15:47:36 · 阅读 1.2k RAG与大模型：从原理到落地的完整拆解
先打一个比喻大模型像一个参加过海量知识竞赛的全能选手你问他光合作用的原理是什么他能一口气给你翻出教科书上的标准答案但如果你问我们公司昨天发布的新产品手册第17页的规格参数是多少他大概率会愣住然后开始一本正经地编。原因很简单他脑子里装的是训练截止日期之前的世界而 RAGRetrieval-Augmented Generation检索增强生成的出现就是给这位选手配了一个随时可翻阅的资料库让他从闭卷考试变成开卷考试。RAG 和大模型的关系这两年已经被聊得很高频了。但我在给企业做知识库、带团队落地大模型应用的过程中发现真正能把两者关系讲透的人并不多。很多人以为 RAG 就是先把文档喂给大模型再提问实际上远不止这么简单。这篇内容不会只给定义我会从原理、链路、落地、排错到选型把 RAG 与大模型之间的核心关系一次性拆开。适合正在做知识库问答、智能客服、文档分析或者只是单纯想搞懂这个热词背后逻辑的朋友。1. 两个学霸的分工先把RAG与大模型的本质掰开看1.1 大模型的本质一个闭卷考试的记忆型选手大模型本质上是一个在超大规模语料上做预训练的神经网络它的所有知识都以参数的形式压缩在模型内部。无论是 GPT 系列、开源社区的 Qwen、Llama还是国内各家商业模型核心机制都是一样的训练阶段见过海量文本推理阶段根据上下文预测下一个 token。这个机制带来一个很关键的特性——大模型的回答依赖的是训练时见过的统计规律。它学到的不是一份可以随时查阅的数据库而是一套概率分布。所以它能写出逻辑通顺、风格自然的回答也会在一些具体事实上翻车。你可以把大模型理解为一个阅卷无数的学霸他有很强的答题能力但他记忆里的世界是固定的不会因为你给他看了新资料就实时更新。这也解释了为什么大模型在通用问答、文本改写、代码生成、头脑风暴这些任务上表现惊艳但一旦涉及实时信息、企业内部私有文档、长尾专业数据就会显得力不从心。它并不理解事实与虚构的边界只是根据概率输出最顺滑的文本。如果你不给他足够的证据他会用最自信的语气把猜测说得像事实。1.2 RAG的本质一套开卷考试的检索外挂RAG 并不是一个新的大模型而是一种把检索和生成组合起来的架构模式。它的核心思路很直白在模型回答之前先从外部知识库中检索出与问题最相关的若干文本片段把这些片段作为上下文塞进提示词再让大模型基于这些资料生成答案。整个过程大致分成三段索引阶段把文档切块、向量化、存入向量数据库构建一个可供检索的外部知识库。检索阶段把用户问题转成向量从知识库中召回最相关的 Top-K 片段。生成阶段将检索到的片段和原始问题一起交给大模型让模型看着资料作答。这里的关键在于RAG 不改变大模型内部的任何参数。它做的是临场给资料让模型在生成时有了可以引用的上下文从而大幅度提升回答的准确性和时效性。这也是它被称为检索增强的原因——增强的是生成过程的信息供给而不是模型本身的记忆。1.3 两者不是竞品而是脑子和参考书的关系很多人会把 RAG 和大模型当成两条可以互相替代的技术路线这是最大的误解。实际上它们更像是脑子和参考书的关系大模型负责理解、推理和表达RAG 负责给它提供当下需要的素材。没有大模型RAG 检索出来的内容只是一堆文本没有 RAG大模型面对动态信息只能靠猜。我在企业项目里经常用一个比喻来解释两者的分工大模型是员工RAG 是文档柜。员工能力强不强取决于模型本身的水平但员工能不能准确回答公司内部问题取决于他能否快速查到正确的那份文件。你不可能要求员工把所有文件都背进脑子里也不可能把文件放在那儿不让他看就指望他答对。RAG 解决的正是在正确的时间把正确的资料送到模型面前这个问题。2. 大模型天生有三个短板RAG恰好补上的正是这些2.1 知识截止日期无法回答今天的事情大模型的训练语料有一个明确的收集时间点。训练完成之后它的知识就凝固了。哪怕你用的是最新最强的模型它也不知道发布日之后发生的新事件、新政策、新产品参数。比如我今年做某个新项目时客户问的是上月刚发布的内部采购流程最新版文档在内部 Wiki 上而大模型训练时根本没见过这份文档。这种情况下无论你怎么追问模型都无法给出正确答案。RAG 对这个问题几乎是天然解法。因为外部知识库是可以在服务运行期间随时更新的新增一份 PDF、改一条产品数据、同步一篇最新的运营日报检索链路立刻就能感知。用户提问时系统会把最新文档切片、向量化之后检索出来再交回给大模型。知识库一变回答就跟着变不需要重新训练模型也不需要等下一次迭代发布。2.2 幻觉问题一本正经地胡说八道幻觉是大模型最头疼的问题之一。因为生成机制本质上是对下一个 token 的概率采样模型为了生成通顺的回答会在不知道答案时编造看起来合理的内容。更危险的是这种编造往往语气坚定、细节丰富用户很难凭直觉分辨真假。比如让模型总结某篇不存在的论文它能给你列出作者、年份和结论让模型回答一个公司内部制度的细节它能编出完全不存在的条文。RAG 能显著缓解幻觉是因为它给模型提供了检索到的证据片段并在提示词中明确要求仅根据给定资料回答不要编造不在资料中的信息。有了这个约束模型从自由发挥变成了基于证据作答。但这不意味着 RAG 能 100% 消除幻觉——如果检索到的资料本身是错的或者提示词没有约束到位模型依然可能把噪声当成事实。所以 RAG 不是幻觉的银弹而是把幻觉风险从必然发生降低到了可控范围。2.3 私有和垂直领域知识大模型根本没见过大多数企业的核心知识——SOP、产品手册、工程图纸、客户案例、历史项目复盘——都不在互联网公开语料里。通用大模型对它们的了解约等于零。就算这些知识碰巧被写进了训练数据也是极少量的模型根本无法稳定、精确地复用。同时垂直领域还有很多独特术语和表达方式通用模型对这些内容的生成质量往往很飘。RAG 在这里发挥的作用是把私有知识导入模型的回答流程。你不需要把这些资料拿去训练大模型只需要把它们切块、建立索引、存入外部知识库。提问时系统检索出与问题相关的片段大模型就相当于开卷阅读了一份它从未见过的内部文档。这个特性让 RAG 成为企业私有化知识库建设的最主流方案也是为什么知识库这个关键词会跟 RAG 牢牢绑定在一起。下表可以快速回顾这三个短板与 RAG 的对应关系大模型短板典型表现RAG 的解法知识截止不知道新事件、新文档、新参数外部知识库实时更新问答时检索最新片段幻觉编造事实、伪造引用、自信胡说用检索片段约束生成要求无资料就说不知道私有领域知识缺失不懂企业内部文档和垂直术语把私有文档切块入库检索后注入上下文3. RAG全链路拆解从入库到出答案每个环节都在影响结果3.1 索引阶段先让知识住进能检索的房子初次接触 RAG 的人往往会把精力全放在模型选择和提示词上却忽略了真正决定上限的是知识库怎么建。索引阶段决定了你的知识能不能被检索到也决定了检索出来的内容是否完整可用。第一步是文档加载。PDF、Word、Markdown、HTML、TXT 是最常见的输入。这里有个容易被低估的坑不是所有文档都能被直接解析。扫描版 PDF 需要先做 OCRWord 里有复杂表格时需要保留结构PPT 和图片里的文字要走多模态识别。很多团队在第一步就丢掉了大量有效信息后面再怎么调都救不回来。第二步是文本切分。你可以把整份文档直接丢进去但实际效果非常差。因为大模型的上下文窗口有限检索单元过大会导致一个片段里混杂太多无关信息回答时会显得散切分单元过小又会把连续的语义切断模型拿到的只是碎片。常用策略是设置一个 chunk_size比如 300-800 字和 chunk_overlap比如 50-100 字或者按文档自带的结构标题切分。我自己的经验是技术文档按章节切法律法规按条款切问答类内容按单条记录切而不是一刀切地按固定字数处理。第三步是向量化。切好的文本片段要通过 Embedding 模型转成向量。这里需要重点选择 Embedding 模型通用领域可以用 OpenAI 的 text-embedding 系列、开源的 BGE 系列或 M3E 系列中文垂直领域尤其是有较多专业术语的场景建议用针对该领域微调过的向量模型。向量模型的维度决定了向量库的规格BERT 类模型常见是 768 维大规模检索时你需要考虑存储和检索成本。第四步是存储索引。向量数据库有 FAISS、Chroma、Milvus、Qdrant、pgvector 等多个选择。从轻量级项目到企业级分布式检索选型差异很大。除了向量索引很多团队会同时建立倒排索引用于后续的混合检索。切分后的文本块还要保存元数据比如来源文档、页码、章节标题等这些信息在后面回答追溯和引用标注时非常关键。3.2 检索阶段把最相关的片段准确捞出来检索是整个 RAG 链路里最容易被低估的环节。很多人以为向量检索就是无敌的实际跑起来会发现用户的问题是一句口语化的描述知识库里的答案是书面化的、包含大量同义词和缩写纯向量检索经常抓不准。一个更稳健的做法是混合检索。向量检索擅长处理语义相近但措辞不同的问题BM25 这种稀疏检索则擅长精确命中专业术语、型号编号、人名地名。两者结果合并后再交给重排模型。我先说说我在项目里常用的链路先把原始问题做一次改写比如帮我查一下上个月华东区的退款率改写为查询华东区上个月的退款率数据然后同时跑向量检索和关键词检索合并结果后再由一个 Rerank 模型如 BGE-reranker、Cohere Rerank对候选片段打分只保留 Top 3-5 个给大模型。这里有一个参数需要格外注意Top-K。K 设得太小容易漏掉重要信息K 设得太大会往上下文里塞入大量噪声反而干扰大模型生成。我从经验上建议如果采用检索后重排的方案前期召回可以取 20-50 条重排后取 3-5 条作为最终上下文。如果你不做重排直接取 5 条以下可能更稳妥。检索还有一个进阶玩法是知识库路由。当系统里挂了多个知识库时比如一个放产品文档、一个放运维手册、一个放客服话术你需要先让大模型判断这个问题该查哪个库或者用分类器做路由。这么做的意义在于缩小检索范围、提升命中率避免跨库检索时把完全无关的内容也捞进来。3.3 生成阶段让大模型看着资料作答检索到的片段最终要交给大模型生成阶段的设计同样决定回答质量。这里最核心的是提示词结构。一个典型的 RAG 提示词包含三个部分角色设定、检索资料、用户问题。尤其重要的是在提示词里明确约束生成行为。我会在 system prompt 里强调三点优先使用提供的资料不要使用资料之外的知识。如果资料中没有答案直接告诉用户未检索到相关内容不要猜测。尽量标注信息出处让用户知道答案来自哪份文档的哪一节。生成阶段还需要考虑引用溯源。很多产品要求答案后面附带参考来源让用户点击跳转到原文。要做到这一点需要在检索阶段记录每条片段对应的文档名和页码并在生成时要求大模型引用片段编号。这不仅是产品体验问题也是建立信任的关键。用户看到答案 引用后对系统判断的信任度会明显提升。生成阶段另一个容易忽略的点是上下文压缩。检索回来的片段有时很长可能超过上下文窗口或者占据大量 token 导致成本飙升。可以考虑对检索片段做一次抽取式摘要只保留与问题最相关的句子再交给大模型。我在处理超长技术文档时就遇到过这种情况检索命中了文档里的一个大章节里面有一大段背景介绍把上下文塞得满满当当。加上一个轻量级的上下文压缩步骤之后回答的准确率和接口响应速度都明显提升。4. 落地RAG的四种姿势自己写、用框架、拖平台、本地部署4.1 从零手写最轻量的 RAG 脚本长什么样最好的理解方式永远是动手写一遍。这里我给出一个非常简化的 Python RAG 流程示意没有依赖重型框架核心目的是让你看清 RAG 的数据流# 1. 加载并切分文档 from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter loader PyPDFLoader(product_manual.pdf) documents loader.load() splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) chunks splitter.split_documents(documents) # 2. 向量化并写入向量库 from sentence_transformers import SentenceTransformer import chromadb encoder SentenceTransformer(BAAI/bge-large-zh-v1.5) client chromadb.PersistentClient(path./chroma_db) collection client.get_or_create_collection(knowledge_base) for idx, chunk in enumerate(chunks): collection.add( ids[str(idx)], embeddings[encoder.encode(chunk.page_content).tolist()], documents[chunk.page_content], metadatas[{source: chunk.metadata.get(source, )}] ) # 3. 检索 query 产品支持的最大并发连接数是多少 query_vec encoder.encode(query).tolist() results collection.query(query_embeddings[query_vec], n_results5) # 4. 构造提示词并调用大模型 from openai import OpenAI context \n\n.join(results[documents][0]) prompt f仅根据以下资料回答问题资料中没有的信息请明确说不知道。 资料 {context} 问题{query} client OpenAI(base_urlhttp://localhost:11434/v1, api_keyollama) response client.chat.completions.create( modelqwen2.5:7b, messages[{role: user, content: prompt}] ) print(response.choices[0].message.content)这段代码虽然简化了很多细节但完整展示了 RAG 四个核心步骤。自己手写的好处是你对每个环节都有完全的控制力坏处是生产环境里还要处理并发、权限、增量更新、日志、评测、多知识库路由等问题全部从零造轮子会非常耗时。所以我通常建议初学阶段手写一个最小 Demo 来建立直觉生产项目还是优先考虑框架或平台。4.2 用现成框架LangChain 和 LlamaIndex 帮你省掉大量底层工作LangChain 和 LlamaIndex 是目前最主流的两个 RAG 框架。它们把文档加载器、文本切分器、向量数据库适配、检索器、重排器、提示词模板都封装成了组件你可以在几十行代码内拼出一条完整的 RAG 链路。框架的价值不只是帮你少写代码更重要的是它抽象了一套统一接口今天用 Chroma明天换 Milvus改动很小今天用 OpenAI明天换本地模型也只需要替换一个组件。在实际项目中我更多把 LangChain 当作胶水层来用用它的 DocumentLoader 统一管理不同格式的文档用它的 Retriever 接口对接不同的向量库和检索策略再用它的 Chain 机制把检索和生成串联起来。LlamaIndex 则在文档索引和结构化数据上更精细尤其是它对文档层级结构和元数据的处理更细适合做知识密集型场景的工具。两个框架都不完美但都比从零手写要稳太多。4.3 低代码平台Dify、FastGPT、RAGFlow们解决的真正问题如果团队里没有专业开发人员或者你需要快速验证一个业务场景低代码平台往往是最高效的选择。Dify、FastGPT、RAGFlow 这类平台把知识库管理、文档解析、文本切分、向量检索、模型调用、工作流编排都做成了可视化界面。你可以上传文档、选择 Embedding 模型、调大模型 API、配置提示词然后在平台上直接创建一个可对话的 RAG 应用。这些平台真正的价值在于把最佳实践内置进系统。比如 RAGFlow 在文档解析环节做了大量工作对复杂版式的 PDF 支持很好Dify 的工作流引擎允许你在 UI 里串联意图识别 - 多知识库检索 - 重排 - 生成这样的复杂逻辑。我用 Dify 给一个中小客户做过客服助手从数据准备到上线只花了一个下午这在纯编码路线上是不敢想象的。当然平台也有锁定的问题深度定制、性能调优、私有化部署的成本需要提前评估。4.4 本地化私有部署数据不出内网的 RAG 方案很多企业对数据合规要求极高文档不能出内网大模型 API 也不能直接调用外部服务。此时就需要一套完全本地化的 RAG 方案。典型组合是Ollama 运行开源大模型如 Qwen、Llama、DeepSeek 系列 本地向量数据库Chroma、Milvus 或 pgvector 本地 Embedding 模型。所有环节都在内网完成数据不出门。这里有一个很现实的建议本地部署大模型不是越强越好而是要匹配硬件预算。一个 7B 参数的量化模型在普通消费级显卡上就能跑得不错一个 70B 模型则需要多张高端显卡。RAG 的优势在于你可以用相对小的模型 高质量检索达到接近大模型的效果。因为模型的推理负担被检索减轻了它不需要记住大量细节只需要做好阅读理解。我帮客户做的很多私有化项目最终落地时甚至只用了一个 13B 或 7B 模型配合精心调过的检索链路效果已经足够满足业务需求。四种落地方式的选型对比可以画一张表方案优点缺点适用场景从零手写完全可控、理解最深开发量大、维护难学习、极简原型LangChain / LlamaIndex省事、组件丰富、切换灵活封装层学习成本、排查链路复杂中小型生产项目、有开发团队Dify / FastGPT / RAGFlow快速上线、内置最佳实践定制受限、依赖平台原型验证、业务人员自助搭建Ollama 本地向量库数据合规、成本可控受硬件限制、模型能力有限企业私有化、敏感数据场景5. 为什么你的RAG检索对了答案还是错六个最容易翻车的环节5.1 文档切分不合理一个表格碎成八块上下文全丢了很多 RAG 项目第一次 Demo 效果不错一上生产就崩最常见的原因就是切分策略有问题。比如一个技术参数表格被固定字数的切分器拦腰截断导致连接数上限和10000这两部分被分到不同的 chunk 里。模型检索到了前半个表格却看不到数字。类似的问题也会出现在代码示例、多级标题和列表场景。我现在的做法是优先识别文档结构标题层级、段落、表格、列表各自有对应的切分逻辑没有明显结构的纯文本再用固定 chunk_size overlap 做兜底。切分之后还要做一次完整性检查比如表格块是否完整、代码块是否包含开始和结束标记。这一步花费的时间不多但对最终的检索质量影响非常大。5.2 向量模型选得不合适语义相似不等于领域相关向量检索的本质是语义相似度但不同向量模型对相似的理解差别很大。通用向量模型在新闻、百科类文本上表现不错但面对企业内部的工程术语、行业黑话、多语言混排文本效果经常不尽人意。比如异常告警和故障通知在通用语义模型看来相似度很高但在运维知识库里二者可能对应完全不同的处理流程。解决思路有两个一是尽量选择与业务领域匹配的开源向量模型中文场景可以考虑 BGE 系列、M3E 系列、text2vec 系列二是收集一批典型的用户问题构建一个小规模的领域评测集对比不同 Embedding 模型的实际检索命中率。后者才是真正靠谱的做法因为模型档位说明写得再好也不如在自己数据上跑一遍来得直接。5.3 只用向量检索丢掉关键词这把利器向量检索擅长处理语义相似但表达不同的查询但它对精确匹配并不敏感。举个例子用户问如何升级到 v2.3.1 版本向量化后v2.3.1这个版本号可能被稀释在整句话的语义里导致召回结果不准确。还有工单号、产品型号、缩写、人名、Base64 编码等字符型信息向量模型的表现往往不如传统的倒排索引。最稳妥的方案永远是混合检索向量检索负责语义召回BM25 或 Elasticsearch 负责关键词精确匹配最后把两路结果加权合并。你可以把混合检索理解为语义 字面双保险。做过检索系统的朋友应该都有体会实际线上查询里既有大意相同的需求也有必须一字不差的需求两者缺一不可。5.4 没有重排环节召回20条里前5条其实是垃圾向量检索和 BM25 得到的 Top-K 结果顺序并不一定代表最相关的就在最前面。尤其是混合检索之后不同来源的结果直接拼接排序质量通常很差。如果不加处理只取前几条可能把一个次要相关片段送进大模型而真正有用的资料排在后面被丢弃。Rerank 模型交叉编码器专门解决这个问题它对每一条候选片段和用户问题做精细的相关性打分而不是像向量检索那样把问题、文档分别编码再算相似度。我的习惯是召回 20-50 条候选用 Rerank 重排后取 Top 3-5 条进入生成阶段。这样可以明显提升答案的准确性。唯一的顾虑是 Rerank 会带来额外的计算开销但在大多数业务场景中这个成本是值得的。5.5 提示词把资料变成了干扰即使检索出来的片段是正确的如果提示词设计有问题大模型依然可能答错。我见过一种很典型的失败模式开发者把检索到的所有片段一股脑塞进提示词结果上下文里有 80% 的内容和问题无关模型被这些噪声带跑偏给出的答案好像什么都说了一点又什么都没说到。这在检索质量不高、Top-K 取太大的时候尤其明显。我的提示词设计原则是明确告诉模型资料中可能包含无关内容请只依据与问题相关的部分回答如果资料互相矛盾让模型指出冲突而不是强行二选一资料不足时明确输出未找到相关信息。同时把问题和资料之间的分隔符做得足够清晰让模型能区分哪些是待回答的问题、哪些是需要参考的材料。5.6 没有一套评测集改完不知道是变好还是变坏RAG 项目的迭代非常依赖评测。很多团队上线之后只是人工抽测几个问题凭感觉判断效果感觉变好了就发版。但 RAG 链路里每一个环节的改动——换 Embedding 模型、改切分参数、调重排阈值、改提示词——都可能同时影响多个维度。没有稳定的评测集你根本说不清改动是在提升还是伤害效果。我建议每个 RAG 项目从第一天就开始积累评测问题集最好按业务类型分层常见问题 30 条、复杂多跳问题 20 条、边界情况 10 条。每个问题标注标准答案和关键来源文档。评测指标方面检索环节看重召回率、MRR、命中率生成环节更关注答案正确率、引用准确率、幻觉出现率。用这套评测集跑完一批变更再决定要不要上线比感觉有效要可靠得多。6. RAG的边界与下一步微调、长上下文、多模态和Agent化6.1 RAG和微调不是二选一而是组合拳我在文章开头说过RAG 不改变大模型参数。那如果需要改变呢比如你希望模型始终用某种固定的客服话术回复、希望它学会某种特殊输出格式、希望它掌握某个领域的思考方式这时候就需要微调Fine-tuning。微调是在模型内部调整权重让模型本身学会某种行为模式。合理的判断标准要看数据属性。如果数据是知识点层面的比如产品参数、政策条款、项目记录适合 RAG因为这类信息更新频繁用外部知识库可以随时改如果数据是行为模式层面的比如希望模型从特定角度回答问题、输出风格更像某个品牌、擅长解析某种行业表格适合微调因为这种能力对几乎每次生成都生效。实际项目里最常用的是组合方案先对基础模型做一次领域微调让它理解行业术语和回答风格然后在生产环节用 RAG 不断喂入最新知识。这样既有了专业素养又有了实时查资料的能力。两边的侧重点不同并不冲突。6.2 长上下文时代RAG还会被取代吗近两年大模型的上下文窗口一路飙升有的已经支持几十万甚至上百万 token。很多人开始讨论既然模型一次能看完那么长的内容是不是直接把文档全塞进去就行不需要 RAG 了我的看法是窗口变大确实能缓解一部分简单场景的压力但距离替代 RAG还有不小的距离。至少有三个现实问题第一成本。每次请求都带几十万字token 费用和延迟都会暴涨业务上很难接受第二大海捞针效应。即使模型有长窗口序列越长它对中间细节的关注度越低很容易忽略埋藏在长文里的关键信息第三权限和更新。你不可能每次文档更新都重新拼接整个上下文池也不可能为每个用户组装一份包含所有文档的超长上下文。RAG 用只捞最相关片段的策略以很小的成本实现了精准的知识供给在工程上依然是最优解。6.3 多模态RAG与RAG智能体下一代形态RAG 的边界正在从纯文本向多模态扩展。文档里的图片、表格、流程图、音视频都能成为检索对象。比如一份设备维护手册里有大量结构图你希望用户问根据图示如何更换滤芯时模型能够检索到对应图片并给出图片文字结合的答案。这就需要多模态文档解析、多模态 Embedding 和视觉语言大模型配合也就是多模态 RAG。另一个重要方向是 Agent 化。传统 RAG 是一次单轮检索生成而 RAG Agent检索增强智能体可以多轮规划它先判断这个问题需要哪些信息再多次调用检索工具一步步收集证据甚至临时生成检索请求、反思结果缺失继续第二轮检索。这种形态在复杂推理、多跳问答场景下效果提升明显比如对比 A 和 B 两款产品的售后政策差异并给出最近三个月哪款口碑更好——这类问题需要跨多个文档、多次检索、综合推理。作为收尾我把目前在实际项目中摸索出的一个体会放在这里RAG 和大模型的关系本质上是知识供给与智能内核的耦合。决定一个知识库问答系统能不能用的往往不是大模型本身多强而是检索链路是否扎实、知识库治理是否到位。如果你正在做 RAG 项目我的建议是先把精力放在文档解析、切分、检索和评测上模型可以往后放一放。把资料库管好把检索调准再配上合适的生成策略你会发现哪怕一个 7B 的本地小模型也能在企业场景里交出让人惊喜的答卷。