企业官网建设流程全解析

我之所以想认真写一篇RAG相关的梳理，是因为这几年在好几个模拟项目里，都见过同一个问题：大模型直接面对企业内部的文档提问，回答得自信满满却漏洞百出。比如某个模拟项目X里，A同学把一套客服手册丢给模型，结果模型在回答“退款流程怎么走”时，把一本十年前的旧版流程当成标准答案，还说得有板有眼。事后核对，发现手册里根本没有那段描述。这种一本正经地胡说八道，就是典型的模型幻觉。

RAG（检索增强生成）正是冲着这个问题来的。它先把用户问题变成一次检索，从外部知识库里找出真正相关的资料片段，再把这些片段和问题一起交给大模型，让模型“看着资料说话”。这篇内容不是概念科普，而是一份可以收藏的实操向指南，梳理RAG为什么有效、内部链路长什么样、每一环怎么调、有哪些坑，适合正打算把大模型接入业务系统的研发同学参考。

1. 为什么说RAG是大模型走向业务场景时绕不开的关键机制

1.1 模型参数里装不下实时知识

大模型的所有知识都来自训练数据，并且有明确的截止时间。企业内部的知识体系每天都在变化——流程更新了、产品改版了、公告撤掉了——这些都不可能等模型重新训练后再生效。模型对训练截止之后发生的事情一无所知，但问题在于：你不告诉它“不知道”，它也不会主动承认，于是就开始编。

举个很多人遇到的场景。某公司更新了IT报修流程，旧流程是发邮件申请，新流程是走工单系统。模型如果只靠着参数知识回答，十有八九会说“请发送邮件至IT支持邮箱”。用户照着操作，发现流程完全对不上，体验就是灾难性的。

RAG相当于给模型接了一个可以随时翻阅的资料库：不知道就去查，查不到就明确说查不到。知识更新变成改文档，从小时级、分钟级就能完成，成本几乎可以忽略。它不能替代模型对通用知识的理解能力，但能解决“知识新鲜度”和“知识归属权”这两个最关键的问题。前者解决内容过时，后者解决“哪些内容必须是你们内部说了算”。

1.2 RAG和微调：两条不同的道路

很多团队一上来就惦记微调，觉得把资料喂给模型训练一遍，模型就记住了。这个想法不能说错，但成本和效果之间往往不成正比。我用一张表来对比两者的差异。

从实践来看，RAG和微调不是互斥关系。更常见的路径是先通过RAG解决“知识从哪来”，再用少量微调解决“话应该怎么说”。知识错了，改文档；风格不对，再微调。分工明确，出错时也好排查。

1.3 什么场景下RAG并不合适

RAG不是万能钥匙。遇到纯数学推导、代码生成、开放创意写作这类任务，模型本身的推理能力才是关键，RAG帮不上太多。知识量极小的时候也不用强行上RAG，比如只有十条固定的内部规则，直接写进提示词要简单得多，为此搭一套索引反而增加维护负担。另外，如果知识高度动态，每几分钟都在变化，比如实时行情、抢票信息，那么抓取和流式更新才是重点，RAG只是其中一环，不能指望它单独解决问题。

判断方法很简单：问自己一句，这个问题的正确答案是否存在于某份静态或低频更新的文档里？如果是，RAG值得做；如果不是，先想清楚知识源到底在哪。

2. 拆开RAG的运行链路：从文档到答案会经过哪几站

2.1 离线阶段：从原始文档到可检索的向量库

所有RAG系统都有一条完整的链路。离线阶段的输入是一堆原始文档，输出是一个可供检索的索引库，中间要经过解析、清洗、分块、向量化四道工序。

解析环节最容易被低估。PDF可能是扫描件，Word里可能有表格，网页里混着导航和广告。这些都要先统一转成干净的纯文本或Markdown。清洗环节要把页眉页脚、水印、乱码、重复段落去掉。比如从网页转出来的文本经常带“上一篇”“下一篇”这种导航字样，不清理就会被当成正文检索到。分块就是把长文档切成合适大小的片段，这个后面单独展开。向量化则用嵌入模型把每块文本转成固定长度的数值向量，然后写入向量库。

向量库在这里的角色像一个专门的搜索引擎，只是它搜索的不是关键词，而是“语义相似的向量”。每个向量旁边通常还要挂上元数据，包括来源文件名、章节路径、更新时间、文档版本等。这些元数据在后续的引用展示、版本过滤、权限管理里都非常有用。

2.2 在线阶段：从用户问题到最终答案

在线阶段就是用户真正提问时发生的事情，链路通常是：用户输入 → 可选的问题改写 → 向量化 → 检索召回 → 重排过滤 → 组装上下文 → 生成回答。

用户的问题往往带着口语和指代，比如“它坏了怎么办”，这里的“它”指什么？机器不知道。所以很多生产级系统会先让大模型把用户问题改写成一个适合检索的独立问句，比如“打印机卡纸后如何处理”。改写后再做向量化，到向量库里做近似检索，找出最相关的前几十条候选片段。

这几十条候选不能全部塞给大模型，因此需要重排和过滤。重排模型会针对“查询-片段”这个配对做更精细的相关性打分，把最相关的几条排到最前面。最后组装提示词时，要明确区分哪些是检索出的资料、哪些是用户问题，再让大模型生成回答。回答返回前，应该把引用来源一起带上，方便用户或审核人员核对。

2.3 最小可用架构怎么搭

不用一上来就整复杂平台。我的经验是先搭一个最小可运行架构：一个解析脚本、一个嵌入模型服务、一个轻量级向量库、一个大模型推理接口，就能把链路跑通。

这里最关键的建议是：先手工跑一次全链路。准备几个测试文档，脚本完成解析、分块、入库，然后手动构造一个用户问题，逐段打印中间结果，重点看检索到了什么。很多问题在这个阶段就能暴露出来——比如分块把一句话切成了两半，或者扫描件解析出来的文本顺序是乱的。手工链路跑顺之后，再去考虑加缓存、加并发、加分布式，逻辑才不会乱。

3. 数据准备与分块策略：RAG效果的上限由这一步决定

3.1 脏数据进，脏答案出

这句老话在RAG里体现得淋漓尽致。索引的质量直接决定了检索的质量，检索的质量又决定了最后回答的质量。如果数据是脏的，后面几个环节再优化也补不回来。

解析阶段带来的问题尤其多。多列排版的PDF经常把左右两栏拆得乱七八糟；扫描件经过OCR之后会出现错别字，错到语义都变了。我见过某项目文档里“自动断电”被OCR识别成“白动断电”，模型检索到之后把“白动”当成一个功能名词，回答自然显得荒谬。表格被切碎、页眉混进正文、多级标题层级丢失，这些都是常见问题。

建议是入库前先做抽样检查。拿一批文档解析后的人工看一遍样本，确认正文顺序、标题结构、表格内容都没有丢失。统一把文档转成Markdown或结构化文本存放，会方便后续所有环节的处理。这一步花的时间，基本都能在后续调试中省回来。

3.2 分块大小和重叠：没有万能参数，但有经验值

分块是RAG效果好坏的胜负手。块切小了，一个信息被拆成两半，检索到一半也回答不了问题；块切大了，大量无关内容混进来，模型找不到重点，回答泛泛而谈。这里的核心矛盾是“召回准确性”和“上下文完整性”之间的平衡。

比较务实的做法是从固定窗口开始试：一般以512到1024个字符为一块，重叠10%到20%。重叠是为了避免关键句子正好卡在边界上。比如一份产品说明书里，参数A和参数B本来在同一段里，固定长度切块时被切成了两块。用户问参数A，检索到的块里没有参数B的对比信息，回答自然不完整。加了重叠后，这样的问题会缓解很多。

固定窗口只是起点。如果文档本身有清晰的标题层级，按结构分块往往比按字符数硬切效果更好。章节、小节、段落天然是语义相对完整的单元，切成这样比任何启发式规则都靠谱。

3.3 结构感知分块和父子分块：进阶但很有效

结构感知分块是让解析器先识别标题层级，再按标题结构切分。比如一份三十页的设备手册，按章节切分成“安装”“维护”“故障排除”几个大段，再按小节进一步细分。这样的召回命中率高，而且每一块自带上下文边界。

父子分块是另一个实用的技巧。它的思路是：用小分块做精确检索，命中之后，把所属的父块或整节内容一起提交给大模型。举个例子，某块只有“温度不应超过40℃”一句话，单独给模型，它不知道为什么会有这个限制；但如果把这一句所属的“运行环境要求”整节内容一起带过去，模型就能理解这是设备工作环境的一部分，回答会更完整。父子分块特别适合“需要精准定位，但回答要依赖整节背景”的说明类文档。

表格的处理也要单独注意。直接提取成纯文本，容易丢失列名与对应关系。建议保留为Markdown表格，或者转成自然语言描述，比如“型号X的功率为200W，待机功耗为5W”。格式对了，模型才能正确理解字段和值之间的关系。

3.4 元数据：经常被忽略，但价值极高

每一块文本入库时都应该附带元数据。最简单的也要有来源文件名、章节路径、更新时间、文档版本这几项。元数据有三个直接作用。

第一个是引用可回显。回答里附上“来源：设备手册V3-第三章-第2节”，用户能自行打开原文核对。第二个是按时间过滤。企业文档库里经常同时存在旧版和新版，检索时如果不加过滤，模型很容易把旧内容当成新知。第三个是权限控制。不同角色能访问的文档范围不同，元数据里挂上权限标识，查询时直接过滤，既能防止越权又减少无关噪声。

我之前处理过一个退款流程的项目，知识库里同时存在V1和V2两版文档。不加版本过滤时，模型经常把老流程和新流程混着回答。后来在查询时增加“状态=生效”“版本=最新”的元数据过滤条件，问题立刻消失了。

4. 检索侧的能力打磨：向量、召回深度与重排

4.1 嵌入模型选型：别只看排行榜

嵌入模型负责把文本变成向量，它决定了“语义相近”这件事在你的系统里到底怎么定义。选型时主要看四个点：领域匹配度、语种支持、向量维度成本、最大序列长度。一个在小语种或专业领域语料上表现平平的模型，就算通用榜单分数再高，实际召回效果也可能不如一个专项小模型。

实践里，我一般会准备一小批有代表性的业务问题，挨个测试不同嵌入模型的召回命中率。不看榜单分，只看真实业务数据上的效果。文档偏长、表格偏多的场景，还要确认模型支持的最大序列长度是否够用，或者干脆在嵌入前先把长文档切成语义完整的短块。

4.2 召回参数：top_k、相似度阈值与混合检索

top_k决定了把多少候选片段送给生成环节。太小容易漏掉正确答案，太大则噪声太多。我的习惯是从5开始，观察失败样本再调整：漏了就加大，回答太泛就减小。对于文档特别长、信息密度低的场景，可以先把召回调到几十条，用重排模型压缩到最后几条。

相似度阈值的作用是“守门”。当检索出的所有片段相关度都太低时，系统应该明确告诉用户“资料库中没有相关信息”，而不是硬着头皮让模型猜。这个阈值调太高容易什么都查不到，调太低又会放进大量无关内容。不同领域的最好值差异很大，需要通过测试集反复验证。

混合检索是我非常推荐的一个手段。向量检索擅长处理同义表述和语义关联，但遇到型号、编号、术语这类精确匹配时容易失手；关键词检索则相反。把两路结果合并后统一去重排序，效果通常优于任何一路单独工作。初始化权重可以按“0.3关键词分 + 0.7向量分”来配，再根据业务反馈调整。

4.3 重排模型为什么能救命

向量检索属于初筛，它用嵌入向量之间的相似度打分，速度快但比较粗。重排模型则基于“用户问题-候选片段”这个配对做更精细的语义交互，判断二者是否真的相关。一个常见场景是：用户问“发票抬头怎么修改”，向量检索召回了大量“发票开具流程”的内容，第一眼看上去都沾边，但重排后会发现真正回答“修改抬头”的那一小段排到了最前面。实践中先召回50到100条，再用重排模型压到前5条，效果通常明显好于直接取top_k=5。

资源充足的场景下，建议把重排做成默认环节。资源紧张或者问题非常简单时，可以配置为跳过，但至少要让重排模块在架构上留出来，而不是临时再补。

4.4 查询改写与多路召回

用户问“它坏了怎么办”，这个“它”必须被消解成实际对象，否则检索系统根本无从下手。生产级做法是先用大模型把用户问题改写成独立、明确的检索query。改写前后的召回效果差别非常明显。

多路召回则适合一次提问涉及多个信息点的场景。一个用户问“退货政策和退款周期”，系统可以同时生成“退货政策”“退款周期”“退货退款流程”三个角度去检索，合并结果后再重排。对于复杂问题，这种多路并行的召回方式往往比单条query命中更全面。类似HyDE的思路也可以尝试——让模型先生成一个假设回答，再用这个假设回答去向量库检索，能提升召回率，但会增加额外的大模型调用成本，需要权衡。

5. 生成侧的把关：提示词、引用与防御幻觉

5.1 设计一份约束力足够强的提示词

检索做得再好，最后一步仍然需要大模型配合。很多系统误以为只要把资料塞进上下文，模型就会老老实实照着回答。现实是模型经常有自己的想法。提示词必须写得足够具体，把边界约束清楚。下面给出一份我常用的模板结构。

系统指令： 你是一个严格基于资料回答问题的助手。请遵守以下规则： 1. 回答时只使用【资料】中提供的信息，不得使用你自己记忆中的外部知识。 2. 每个关键结论后，在括号中标注来源编号，如（资料3）。 3. 如果【资料】中没有足够信息回答用户问题，请直接回复“资料中没有找到相关信息”，不要猜测。 4. 不要把多个来源的信息混合成一段与原文不符的描述。 【资料1】 （检索到的第一段内容） 【资料2】 （检索到的第二段内容） 【用户问题】 （用户输入的问题）

这套模板的核心思想是“只依据资料、必须标来源、没资料就承认”。实际操作中，规则3尤其重要，它给了模型一个合法的出口，而不是逼着它在任何情况下都必须给出答案。

5.2 让“不知道”成为默认选项

大模型天然倾向于讨好用户，宁可编一段像模像样的内容，也不愿意承认自己不知道。所以在生成阶段要做的第一件事，就是给“不知道”留出明确的位置，并在提示词里反复强调。

参数层面，temperature建议调到0到0.2之间，避免模型发挥过头。max_tokens也要合理设置，特别是资料不足以支撑长篇大论时，限制长度能防止模型展开无意义的补充说明。生成之后还可以做一轮后置校验，比如用另一个模型核查回答是否完整覆盖了用户问题、是否有引用不存在的资料等情况。初期可以靠人工抽查，稳定之后再逐步自动化。

5.3 引用溯源：回答能不能被验证

引用溯源不是锦上添花，而是整个RAG系统可信度的基础。回答末尾附上“来源：设备维护手册V3-第三章-第2节”，用户就能自己打开原文核对；界面上再把引用的片段做成可展开的折叠卡片，点击就能看到原文内容找得到。这种可验证机制会让模型的编造无所遁形，也会反过来倒逼检索引擎和提示词设计做对。

如果模型引用了资料里没有的内容，那基本可以肯定问题出在提示词约束不够，或者分块把相关内容切丢了。顺着这个方向排查，能比瞎调参数更快定位根因。

5.4 两个典型的生成侧失败模式

第一种是资料正确，但模型按自己的理解回答。这种情况通常说明提示词约束不够硬。第二种是资料相关但不足，模型强行补充，把不存在的细节说得像真的一样。这时要回到数据侧去查：是分块切得不够完整，导致关键信息没有随检索候选进入上下文？还是资料库里本身就没有能回答这个问题的片段？如果是后者，更合理的做法是让系统明说“资料不足”。这比优化提示词更能解决底层问题。

6. 落地过程里的评测、踩坑与优化节奏

6.1 先手工跑通，再谈优化

很多团队一上来就搭复杂的评测系统，结果连最简单的链路都没跑通。我的建议很直接：先准备5到10个覆盖主要业务场景的真实问题，手工跑一遍全流程。记录三件事：检索是否命中相关块、命中块是否够用、最终回答是否忠实于资料。如果一个回答明显拼凑、前后矛盾，多半是分块或检索出了问题。

这一步过不了，再多的评测指标都是空谈。因为指标只能量化问题，不能帮你理解问题。手工跑链路时，你会亲眼看到资料到底是怎么被切碎、被检索、被拼接到提示词里的。

6.2 分层评测：检索层和生成层分开看

评测要分层进行，否则问题难以定位。检索层看命中率、Top5是否包含正确答案、MRR这类指标；生成层看回答的忠实度、相关度、引用准确率。两个层面分开评测，才能知道优化重点应该放在哪一步。

实际项目里，构建一个几十条样本的小测试集非常划算。每次改动分块策略、换了嵌入模型、调整提示词后，都跑一遍测试集对比结果。初期用人工打分更可靠，样本多了以后再引入一个评判模型做初步打分，人工负责复核。这一步能帮你建立回归意识，避免改一个地方坏掉另一个地方。

6.3 我踩过的一些典型坑

文档顺序错乱：多列PDF解析后，左右两栏的文字被串起来读，回答自然前言不搭后语。处理方法是针对这类特殊排版先做版面分析，再决定读取顺序。

整本文档塞进一个分块：上下文长度虽然够，但无关信息太多，模型抓不住重点。解决方案是按结构切块，必要时使用父子分块。

不同语言的嵌入模型混用：中英文内容用了不同的嵌入模型，检索时向量空间不一致，召回效果无从谈起。全链路必须使用同一套嵌入模型和预处理方式。

旧版文档没有失效：知识库里新旧版本共存，回答时新旧信息交叉出现。建立版本元数据，在检索时过滤掉已失效的旧版。

相似度阈值调太高：系统什么都回答不了，所有查询都被判定为“无关”。这种问题往往出现在上线前参数配置阶段，先调低阈值看召回，再逐步收紧。

引用不可验证：界面只给一句回答，没有来源展示。用户看到错误回答时无法自查，误判率会大幅上升。

6.4 推荐的优化顺序：数据大于算法，算法大于参数

一个我反复验证过的结论是：绝大多数RAG项目的效果提升，来自数据处理和分块策略的调整，而不是更换更强的嵌入模型或调参。数据清洗解决的是“索引能看到什么”，分块解决的是“检索能命中什么”，重排解决的是“命中之后能留下什么”，提示词解决的是“留下之后怎么解释”。前面任何一站没站好，后面都是在残次品上做文章。

上线之后一定要做日志监控。定期抽取一批真实用户问题，人工复核检索质量和回答质量。置信度低、用户反馈差的query要重点分析，看是数据缺失、分块不合理，还是提示词约束不足。RAG不是一次性项目，而是需要持续维护的流水线。资料库每次更新都意味着索引需要同步更新、效果需要回归验证。

说了这么多，如果只留一句话，那就是：RAG不是把大模型封装成一个黑盒，而是一条可以逐段检查、逐段优化的流水线。文档解析和分块决定了它能看到什么，检索决定了它记住什么，提示词决定了它怎么说。我在模拟项目X里遇到的大部分卡壳，都不是模型不够强，而是前面某一站没站好。希望这篇梳理能帮你把每一站都看明白。先从一份真实文档、一个真实问题开始跑，哪怕只是一个脚本，也比看一百篇原理文章更有用。