企业官网建设流程全解析

作为写了三篇 AI Agent 实操系列后，一直有朋友在问：Agent 已经开始调用工具了，也会规划任务了，但一涉及公司内部那堆知识文档、产品说明、历史需求，就开始一本正经地胡说八道。这个问题其实特别典型。模型在训练时看到的只是公开语料，不可能知道你这边的私有知识和最新变更。你要让 Agent 真正敢回答，就必须给它接上一条知识获取管道，也就是 RAG（Retrieval-Augmented Generation，检索增强生成）。

这篇是系列的第四篇，我不打算泛泛聊概念，而是把 RAG 当成一条流水线来拆：你的文档如何变成能检索的索引，用户提问进来之后又如何变成精准的召回结果，中间涉及到哪些关键参数、哪些工具选型，以及最容易翻车的点在哪里。如果你正准备从 0 到 1 搭建一个 RAG 知识库，或者打算在 Agent 里加入 rag 检索能力，这篇内容值得你认真读完。

1. 知识从哪来：RAG 在 Agent 架构中的实际定位

先别急着写代码。很多教程上来就是load_document+split_text+embedding，看似跑通了，但放到 Agent 架构里你会发现它跟 Agent 的决策流程完全脱节。所以在动手之前，我非常建议你先搞清楚一个问题：在这套系统里，RAG 到底扮演什么角色。

1.1 为什么 Agent 的知识不能只靠模型自己

大语言模型本质上是一个“学完就封存”的参数化知识库。它可以背出《三体》的剧情，可以解释微积分的概念，但它不知道你昨天刚更新的产品维修手册，也不知道你们运营团队沉淀下来的用户投诉处理 SOP。这是固定的知识，不是管道，是“存量”，不是“流量”。

有人尝试用微调来解决这个问题。确实，微调可以把特定知识塞进模型的权重里，但代价是每次知识变更都要重训一次，而且小模型根本记不住太多细节，大模型的微调成本又不是一般团队扛得住的。还有人硬怼上下文窗口——用户问一句，就把 10 万字的手册全塞进去。先不说 token 成本，长上下文里有效信息密度的稀释问题，会让 Agent 连最基础的问题都开始乱抓。

RAG 的思路是彻底不同的：模型不认识你的知识没关系，它帮你做“找”的工作——先把你的知识拆开存好，用户提问时不读整本手册，只把最相关的几段落捞出来，作为辅助材料交给模型组织回答。模型的“推理能力”负责最后一步，而“知识的广度和时效性”完全由你自己的索引管道负责。

1.2 在 Agent 的思考循环里，RAG 是一类特殊工具

经过前三篇文章，你应该已经理解 Agent 是在一个循环里做事的：理解任务 → 规划步骤 → 调用工具 → 观察结果 → 修正计划指向最终答案。很多新手把 RAG 理解成一个单独的“问答引擎”，这没错，但没有体现 Agent 的进阶使用方式。

更合理的架构是：将你的知识库封装成一个可被 Agent 调用的检索工具。Agent 在思考过程中可以主动决定“我需要查一下公司政策”，于是触发检索工具，拿到上下文，再继续推理；如果检索结果不够，它可以改一个新的查询词，再检索一次。这就是所谓 agentic 的玩法，它消除了“一次检索定终身”的僵硬感——这一点我们后面章节再展开。

这里不过多深入。你现在只需要建立起一个心理模型：RAG 是给 Agent 配的“定向知识快递员”，由于 Agent 有了这个工具，它就有能力在回答时引用最新、最私有的信息，而这正是企业落地 AI 时最关注的能力。

1.3 三种知识注入方式的取舍，别一上来就站队

我见过不少团队，一聊到 RAG 就直接说“微调不用看了”，也有一听 RAG 就觉得“都不可靠”然后转身去研究超长上下文。这两类做法都偏了。我建议你用一个简单标准来做决策：

• 知识更新频率高、需要可溯源、团队没有太多训练资源 → 选 RAG，这是它的主场。
• 模型的表达风格、行业术语体系需要固定，或者推理时必须内化一套规则 → 微调或系统提示词。
• 知识总量不大（比如就是几千字的操作手册），Agent 在单次任务里必须完整阅读 → 直接塞进上下文可能更省事。

比较务实的做法是“微调 + RAG”并用：用微调让模型熟悉你的问答风格和组织术语，用 RAG 换知识的新鲜度。但在你还没有跑通基础管道之前，别急着上微调——先让 RAG 稳定，再谈优化。

2. 索引侧工艺：把知识库拆成可检索的颗粒

如果大家把 RAG 看作一条羊肠小道，那索引侧就是“铺路”的工作。用户看到的问答效果，绝大部分在索引阶段就已经被决定了一大半。后面检索算法再强，也翻不出“索引里就没有的东西”。这一节我们把这些内容、切分、向量化、存储的细节逐一对齐。

2.1 文档加载与清洗：垃圾进，垃圾出

RAG 的数据源形态比大多数人想象的复杂，大到几个 GB 的 PDF，小到 Excel 表格、网页、Notion 文档都有。我见过最典型的翻车场景是：团队拿来一批 PDF 直接切分丢给向量库，结果里面全是扫描件，OCR 都没有做，问出来的答案只剩字符碎片。

第一步的文档解析层，常常是被低估的。实际操作中我的标准做法是：

1. 先盘点来源格式，确定每一类文档用什么解析器。PDF 优先尝试正规库（如pypdf、pdfplumber），遇到扫描件就得接 OCR 引擎。
2. 对文本做清洗：去掉页眉页脚、页码、目录残留、超链接尾巴；统一换行符；处理无意义的重复标题。
3. 按文档逻辑结构抽取元数据——比如文档名称、章节号、发布时间、归属部门，这会在后续做过滤检索时极大提升精确度。

清洗这件事没有太多炫技空间，但它的 ROI 极高。一块干净的原料，比后面塞十个高级模型都管用。

2.2 切分策略：块大小不是拍脑袋定的

文档加载完，下一步是切分成“块”（chunk）。这里有两个互相拉扯的目标：块太小，语义不完整，检索系统只能捞到残肢断臂；块太大，一段混入多个主题，向量表示被平均掉，且接进上下文后浪费大量 token。

常见的切分方式有三种，我用一个表格讲清楚它们的适用场景：

关于分块大小，我给出一个经验范围：中文场景下，块大小在 300～600 字之间，重叠 50～100 字，算是一个比较稳妥的起点。为什么需要重叠？因为句子一旦被切断，前后语境的衔接就断了，重叠能让切分边界附近的语义有“冗余缓冲”，避免把关键信息正好断成两半。

如果你想要省心且效果在线，默认策略就选递归字符切分，别用固定长度硬切。我在实际项目里大量文档都是用递归切分直接处理的，效果比固定长度好很多。

2.3 嵌入模型选型：直接决定向量召回的天花板

把文本变成向量——这个环节叫向量化。一个容易被忽略的事实是：嵌入模型质量对 RAG 效果的影响，比向量数据库选型更显著，直接决定了检索系统对语义的理解能力上限。

业界现在的选择已经非常丰富。开源阵营里，主打中文场景的嵌入模型我建议优先考虑基于 BERT 架构的中文模型或近几年发布的新一代通用嵌入模型；英文能力强且多语言泛化出色的模型也值得测试。如果你的语料偏垂直领域（比如医疗、法律、制造），有条件的话，用领域语料微调一个专用嵌入模型会有非常明显的提升。

选择嵌入模型时，不要只盯着 MTEB 榜单评分，还需要关注：

• 支持的输入最大长度（比如 512 个 token，长文档切分块不能超过限制）
• 是否支持“查询指令”前缀。有的模型在检索时需要对查询添加策略性前缀，效果差距明显
• 向量维度，128 维和 1024 维之间的存储与速度差异很大
• 在同一向量库后端里能否和已有模型兼容

我自己拿多个模型做过 A/B 对比，结论是：在中文业务问答上，一个好的领域适配嵌入模型，能比通用模型把 hit rate 拉开 10 个百分点以上——这个数字在 RAG 里已经非常惊人了。

2.4 向量库选型：别为了“炫技”引入过重组件

向量数据库负责存储向量，并提供相似度检索。现在市面上的选择非常多：Chroma、Qdrant、Weaviate、Milvus，外加各大云厂商的托管向量服务。坦率说，这道选择题没有标准答案，只有匹配你现状的答案。

对于初期从 0 到 1 搭建的 RAG 知识库，我的建议非常简单：先用轻量级方案把流程跑通，数据量达到百万级向量之前，完全没有必要上分布式架构。生产环境再考虑迁移到性能更强、支持复杂元数据过滤的引擎。

另外，向量库都会提供 keyspace 或 collection 类似的概念，记住一点：一定要设计好元数据字段。你们公司的文档来源复杂，带部门、日期、文档类型字段，才能在检索阶段做 pre-filter 或 post-filter，这是命中率的隐形推手。很多人把向量库当成单纯的“寻址器”，等到效果不好时才追悔莫及。

3. 检索侧工艺：把查询变成一次精准的召回行动

索引做好，相当于弹药库已经备好。接下来是真正面对用户的环节：用户提一个问题，系统怎么从他的语言变成向量查询、怎么找出最相关的段落、怎么把段落组织成模型可用的提示词。这一步做得糙，前面一切精心的索引都会白白浪费。

3.1 查询改写：为什么不是选配

用户的问题往往很口语化、指代不明，甚至包含错别字。“那个昨天说的东西发我一份”这种话，直接拿去做向量检索，效果一定崩。嵌入模型处理短查询时，靠的是一整句的语义编码，指代不明等于让模型去猜上下文。

实操上，查询改写可以通过一个小一点的 LLM 提前完成，也可以做规则层面的标准化。比如：

• 自动扩充缩写和术语（“AGI” → “Artificial General Intelligence”）
• 补全指代（“那个文档” → 根据对话历史替换成具体文档名）
• 将口语问题改写成适合检索的关键词组合（“公司对加班有啥规定” → “公司加班管理规定 制度”）

你可能会觉得，这不就是一个 Prompt 的事吗？但真的把它放到 Agent 的决策规划里，事情就变得微妙起来。Agent 执行查询改写时，不是简单“转述”，而是根据历史对话判断用户真实意图，从而决定检索的语义重心。这是基础 Agent 开发中非常必要的技能。一般来说，我会让 Agent 在做工具调用前先思考一次查询改写，再把改写后的查询交给检索工具。

3.2 召回策略：向量检索不是唯一解

最常见的召回方式是向量相似度检索——把查询向量和库里的向量做相似度计算，返回 Top-K。简单直接，但有两个天然缺陷：一，纯向量检索对专有名词、产品型号这类“字面匹配型”问题反应迟钝，因为嵌入模型把语义抽象化之后，具体字符对不上的情况很常见；二，短查询往往只有一个主题，在向量空间里容易和很多不相干文本出现相似度噪声。

于是混合检索（Hybrid Search）方案被广泛采用。它的思路是：一条路走向量相似度，一条路走全文关键词匹配（BM25），然后把两边的结果做融合。处理产品型号、代码片段这类精确文本场景，BM25 往往能“一剑封喉”，而语义相近但字面完全不同的表达，靠向量线解决。

我在工程上测试过，混合检索确实能稳定提升召回效果，配合后面的重排，效果更好。现在，很多向量数据库已经内置了混合检索能力，不需要自己实现，接入成本进一步降低了。还有个更进阶的方向叫 Rerank（重排）。召回的 Top-K 中，真正匹配的文档可能仍被大量相似但不正确的内容淹没，这时就需要一个重排模型，对候选文档进行更细粒度的相关性打分，把最匹配的排在前面。常见做法是使用专门的重排模型（如 cross-encoder 架构），它对每一条候选文档和查询的组合进行打分，而不是像双塔式嵌入那样把文档和查询提前编码好。代价是推理成本高、速度较慢，但准确率提升显著。

我在生产环境里的建议是：召回阶段多放一点候选（比如 Top 30），重排阶段只取前 5 个精准注入给模型。这能较好地平衡质量和 token 成本。

3.3 上下文注入：如何让模型既不迷路又不超载

检索的结果要注入到大模型提示词中，这是 RAG 管道里最容易被低估的一步。如果你直接把 10 段文本全部倒给模型，结果往往不是答案更丰富，而是模型开始胡言乱语——因为噪声太多，真正能提供答案的段落被淹没。

个人经验是：上下文注入必须有设计，而不是简单拼接。推荐的做法是：

• 每条检索结果带上元数据（来源文档、章节、页码），在注入时用显眼的标记标识，让模型知道“这来自哪些资料”，必要时支撑引用。
• 控制注入条数，在 3～5 段之间。如果检索质量高，3 段足够；如果质量一般，5 段也不会让有效信息被完全冲淡。
• 在提示词中明确告诉模型：优先基于上下文回答，上下文无法回答时明确说不。别让模型去“揣测”资料里没有的原则。

这背后有个概念叫“上下文工程”——不是把所有内容丢到一起，而是把最相关的信息组织成一个对模型友好的结构。你会惊讶地发现，同样的检索结果，改一改注入格式，回答质量立刻会有肉眼可见的提升。

4. 手把手跑通一条 LangChain 基础 RAG 管道

前面说了很多“道”，现在落到“术”。我用 Python + LangChain 给你跑通一条最小可用的 RAG 链路，所有的组件都可以替换成你习惯的库或服务，关键是让你对整个流程有手感。

4.1 为什么要拿 LangChain 做示范

讲道理，LangChain 不是唯一选择，也未必是最好选择。LlamaIndex 在文档索引和检索微调上更聚焦，Spring AI 在 Java 生态里更合适，甚至你可以自己写几十行代码完成整个管道。但选 LangChain 做入门示范，是因为它有最完整的工具生态，里面封装了文档加载器、文本切分器、向量存储接口、Retriever 抽象，以及和各类模型的对接模块，能让新手最快看到全貌，也方便后续迁移。

4.2 最小完整实现细讲分块与检索

下面是一段可运行的代码骨架。假设你本地已经装好了langchain、langchain-openai、chromadb等依赖。实际使用时把模型名和密钥换成你自己的配置即可。

from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import Chroma from langchain_core.runnables import RunnablePassthrough # 1. 加载文档 loader = TextLoader("manual.txt", encoding="utf-8") documents = loader.load() # 2. 递归字符切分 text_splitter = RecursiveCharacterTextSplitter( chunk_size=400, chunk_overlap=80, separators=["\n\n", "\n", "。", "！", "？", " ", ""] ) docs = text_splitter.split_documents(documents) # 3. 向量化并写入向量库 embedding = OpenAIEmbeddings(model="text-embedding-3-small") vectorstore = Chroma.from_documents( documents=docs, embedding=embedding, persist_directory="./chroma_db" ) # 4. 构造检索器 retriever = vectorstore.as_retriever( search_type="similarity", # 还可选 mmr search_kwargs={"k": 5} ) # 5. 与模型串联，做 RAG 问答 from langchain_openai import ChatOpenAI llm = ChatOpenAI(model="gpt-4o-mini", temperature=0.2) def format_docs(in_docs): return "\n\n---\n\n".join(doc.page_content for doc in in_docs) rag_chain = ( {"context": retriever | format_docs, "question": RunnablePassthrough()} | llm ) print(rag_chain.invoke("你们公司的调休制度是怎么规定的？"))

如果你就是想把 RAG 接入 Agent，而不是单独跑一个问答链，通常的做法是：把retriever包装成一个工具函数，Agent 在需要知识时主动调用。我有一次做客户支持 Agent，用的就是这种套路——问题进来，Agent 自己决定是直接回答，还是先调检索工具，还是先查询工单系统，最终效果比强制每一步都必须检索自然得多。

4.3 跑通之后先验证三件事

代码能跑出答案只是开始。我会建议你立刻做三件事验证：

1. 换三个不同类型的问题测试：背答案型的定义问题、需要归纳的中长问题、包含生僻术语的精确问题。看检索效果是否稳定。
2. 打开检索器看实际召回的内容，不要只看最终回答。很多问题出在召回环节，你的答案再流畅，召回错了一切都白搭。
3. 测试噪声抵抗能力：故意问一个库里没有答案的话题，看模型会不会硬编造。一个负责任的 RAG 管道应该明确告诉你“这个我不知道”。

跑通这一步之后，你对 RAG 的整体手感才算建立起来。这时候再回头调索引、优化检索，方向感会完全不同。

5. 别只看感觉：用 hit rate 量化检索质量再调优

很多团队做 RAG，效果不好就加长上下文，再不行就换向量库，纯靠“感觉”在调参。实际上，RAG 完全是可以量化的工程系统，最重要的指标之一就是 hit rate。这一节带你明白这个词的真实含义，并给出一套可以落地的评测与调优方法。

5.1 什么是 hit rate，我该看哪个 top-k

hit rate（命中率）衡量的是：在评测集的每个问题上，我们预先标好哪几个段落是正确答案所在，经过检索后，这些正确段落是否被召回。如果正确段落在返回的 Top-K 中出现了，记为一次命中。“Top-K 取多少，命中率就多高”，一般报告里会用 recall @ 1、@ 3、@ 5 分开表述。

举一个简单的例子，你的评测集里有 100 个问题，每个问题标好了 1 段正确文本；系统在 Top-3 里命中了 60 个问题，那么 recall @ 3 就是 60%。数字越接近 100%，说明你的索引与检索配置越好，模型拿到有效上下文的概率就越高。

有一个容易踩的误区：hit rate 和“最终回答正确率”不是一回事。可能检索命中但模型回答错了，也可能检索没命中但模型靠自身知识蒙对了。我在工程上习惯的做法是：先把 hit rate 调到一个比较满意的水平，再去观察最终回答质量。那样如果回答还不好，问题多半在 Prompt 或模型选择上，而不是检索端。

5.2 建立一套轻量评测集

很多人一听到评测集就觉得是大工程。实际上你完全可以手动建一个 30～50 条的小集合，半天就能搞定。每条包含三个维度：问题、正确答案所在的源文本、问题类型类型标签（定义类、操作类、比较类、精确数值类）。

有了评测集，你可以把所有条件固定，只改动一个变量，反复跑召回结果对比 hit rate。这就是一种廉价但可靠的调优实验。我会把评测结果输出成表格，例如：

这样的表格能让你一眼看出哪个变量影响最大，而不是每次调整都凭记忆说“好像好了点”。

5.3 从 42% 到 68% 的一段真实调优记录

我过去帮一家制造业客户做设备维修问答的 RAG，初始 hit rate 只有 42% 左右。排查后发现三个问题：第一，原始文档是扫描件，OCR 掺杂了大量噪声；第二，维修手册里大量篇幅是配件表格，切分时表格被横七竖八拆开，语义没了；第三，通用嵌入模型对设备型号和故障代码理解得很差。

针对性地做了三步：先用结构感知切分把表格完整保留，每个表格独立成块；再把嵌入模型用客户的历史工单语料做了领域微调；最后在召回后接了一个重排模型。一轮下来 hit rate 到了 68%，最终问答质量也有明显提升。

这个案例想说明的是：调优不是“玄学”，而是 定位瓶颈 → 改一个变量 → 再评测 的循环。只有把评测机制立起来，循环才有意义。在 RAG 调优这件事上，直觉可以给你方向，但数据才给你答案。

6. 从调用到决策：RAG 如何演化成 Agentic RAG

当你把基础的 RAG 跑通以后，大概率会遇到一个新的不满意：用户的问题一变复杂，单次检索就不够用了。比如用户问：“对比一下过去半年哪几类故障出现最多，顺便给我推荐对应的预防措施。”这个问题其实包含两个完全不同的检索需求，一次性向量检索根本喂不饱模型。这时候，从“RAG”进化到“Agentic RAG”就非常必要了。

6.1 一次性检索与多步检索的本质差异

传统 RAG 是“一次检索，终身使用”：拿到一个相似度结果集，拼接提示词，输出答案。而 Agentic RAG 把检索行为嵌入了 Agent 的决策循环。Agent 不只是“调用一次检索”的人，它自己会判断：

• 当前信息够不够回答？
• 这个问题的不同侧面是否需要分别查不同知识源？
• 检索结果有歧义，需不需要换一个角度重新检索？
• 多篇文档信息冲突时，是继续检索核验，还是如实告诉用户存在矛盾？

这种设计带来的本质变化，是知识获取从“被动接收”变成了“主动探测”。我前不久参与一个法律咨询 Agent 的搭建，用户问的是“试用期被辞退有没有补偿”。如果只用一次检索，很容易只检索到“试用期可以解除合同”这一条，然后给出冷淡的结论。但用 Agentic RAG 的设计，Agent 可以先检索“试用期辞退条件”，再检索“经济补偿金规定”，甚至追问几个澄清问题，再综合回答。两类信息拼在一起，答案才完整。

6.2 让检索工具成为 Agent 的“决策型技能”

实现 Agentic RAG 最朴素的方式，就是把检索器包装成 Agent 的一个工具，并启用 ReAct 这样的循环模式。下面是一个高度简化的伪代码逻辑：

def search_knowledge_base(query: str) -> str: docs = retriever.invoke(query) return format_docs(docs) tools = [SearchHelp(search_knowledge_base), SearchPolicy(search_policy_db)] agent = create_agent( llm=llm, tools=tools, system_prompt="你是企业内部知识助手，回答前先判断需要查阅哪些知识库。" )

关键在于：Agent 的工具列表里不止一个检索入口，而是可以按知识域拆分。这样做的好处是，一个庞大而杂乱的向量库被拆成了领域化的子库，每个子库里的数据一致性更好，召回精度自然更高。对于已经出现“知识割裂”的团队来说，这种子库划分是从架构上缓解问题的关键一步。

6.3 从 RAG 到 GraphRAG / Ontology RAG：越想回答好，越需要结构

传统 RAG 的问题在于向量相似度只能表达语义接近，表达不好“多跳关系”。比如你在一个大型组织里检索“A 项目的负责人曾经负责过哪些跟 B 模块相关的迭代”，一次性向量检索几乎不可能回答完整。因为它的答案分散在多个文档中，且彼此之间不是文本相似的关系，而是实体关系。

GraphRAG（基于知识图谱的检索）就试图补上这一块：先抽取出实体（人、项目、模块）与关系（负责、依赖、影响），构建成图，然后在图上做多跳检索，把经过关系连接的相关段落找出来。Ontology RAG 更进一步，用本体论定义业务概念与关系，让检索能沿着语义层级展开。这类方案有门槛，工程量大，但回报也非常可观。

考虑到这只是一篇基础篇，我只想让你记住：单靠向量存储 + 相似度检索，解决不了复杂关系的推理问题。如果你的业务场景里充满了这类“多跳关系型提问”，那你的下一站就是 GraphRAG 或 Ontology RAG，而不是拼命调参堆算力。

7. 实战胜过教程：切分、嵌入与注入的踩坑清单

最后我想集中聊聊，过去一年里我看过、踩过无数次的各种 RAG 坑。大多数 RAG 项目在初始阶段效果不佳，其实不是算法有多高深，而是几个不起眼的细节在捣乱。梳理成清单，你逐条核对，能省下很多调试时间。

7.1 切分阶段最容易出的三个问题

第一个：一刀切。有人为了省事设置 chunk_size=800 然后不管了，结果把一整个表格切成两半，检索时只能搜到表头，完全丢失数据。第二个：忽视代码和术语。技术文档里的代码块、模块名、接口字段，切分时很容易被拦腰斩断，导致后续无法完整召回。第三个：没有保留文档外部的元数据。检索结果里只有文本，却不知道它来自哪个版本、哪个章节，注入后模型无法引用来源，回答的可信度大打折扣。

切分的终极目标不应该是“把文本切小”，而是“保住语义完整性”。所以结构感知切分值得优先考虑。如果文档有清晰的排版结构，一定要让切分器沿着结构走。

7.2 嵌入与检索的坑，效果不佳的首因

嵌入模型如果选错，后面再怎么调都是事倍功半。最常见的错误是拿一个偏英文语料训练的模型去处理中文领域文档，相似度计算时中文语义表达常常错位。建议在中文场景下，务必测试专门面向中文的嵌入模型，并考虑用领域术语做实际效果验证。

第二个很常见的坑是：忽略查询与文档之间的“表述风格鸿沟”。用户会问“为什么空调不制冷”，但文档里写的是“压缩机工作异常导致制冷失效”，两者字面上毫无重叠，语义上密切关联。如果嵌入模型能力不够，这一圈就转不过去。解决之道是，要么用更强大的嵌入模型，要么在建立索引时，为文档人工补充同义关键词的别名字段。

第三个是重排环节的缺失。很多人直接拿 Top-5 的向量检索结果塞进模型，但很多低质量相似文本混在其中，严重误导回答。建议在生产环境先召回 Top 20，再重排取 Top 3～5。这个操作带来几个百分点的准确率提升几乎是必然的。

7.3 上下文注入的坑，微调都不一定救得回来

上下文注入看似简单，却最容易搞砸。我见过团队在提示词里塞了 8 个大段落，以为“信息越多越好”。结果模型把一些不相关段落里的内容当成事实，回答得头头是道，但其实都是编的。上下文质量远胜数量，这一点再怎么强调都不过分。

另一个经典错误是注入时丢失了文档来源。回答一出，用户追问“这是哪份文件里的说法”，模型无法给出来源，信任感立刻坍塌。所以永远记得在格式化上下文时带上元数据标识，并引导模型在引用时标记来源编号。如果你的产品不需要引用，也建议至少保留一个可追溯的机制，方便排错。

还有一条容易被忽视的提示词优先级问题：如果系统提示词里说“你是内部知识助手，回答必须基于以下上下文”，但在实际注入时有的段落明显是闲杂信息，模型仍然会努力去迎合。你需要在提示词的最后一句加上类似于“如果上下文互相矛盾，说明矛盾存在于哪些资料，并给出你的判断”这样的指引，让模型在资料打架时能安全刹车，而不是硬编一个答案。

结语是最后一个主题的部分，而非空洞的总结

写到这里，整个 RAG 基础管道就算给你盘了一遍。我一直强调，RAG 不是一个可以一次性装好就完事的组件，而是一条需要持续维护的管道。新文档上线要重新切分、重新嵌入；业务术语在变，嵌入模型隔一年就值得重新评估；评测集也要跟着业务问题成长。

按照我个人的经验，最重要的心态是：从最小闭环起步，用数据说话，再逐步演进。不要一开始就追求 GraphRAG、Agentic RAG 这类高阶形态，而是先把基础索引和检索做扎实。当你手上有了一套可靠的评测指标，你会发现那些“感觉效果不好”的模糊问题，都会变成可以被定位和修复的工程问题。

下一篇我会沿着 Agentic RAG 这条线继续展开，聊一聊多工具协同下的自主检索与知识校验。如果这篇文章对你刚好有用，或者你有不同的踩坑经历，欢迎留言讨论，我也顺便避避雷。