企业官网建设流程全解析

大模型跑得好好的，结果一问到训练截止日期之后的事，它要么一本正经地胡说八道，要么直接告诉你"我的知识截止到某年某月"。这种"知识冻结"的尴尬，做过AI应用的人应该都深有体会。更麻烦的是，你想让它回答你企业内部的项目文档、产品手册、售后记录，它根本没见过这些资料，再大的模型也只能干瞪眼。

RAG（检索增强生成）就是冲着这个问题来的。思路特别直白：不让模型死记硬背所有答案，而是让它学会"查资料"。需要回答问题时，先从知识库里检索相关内容，再把检索结果连同问题一起交给大模型生成答案。相当于从"闭卷考试"变成了"开卷考试"——答案不用全背，知道去哪翻书就行。

这篇内容我会从"知识冻结"这个痛点的根源讲起，拆解RAG的核心流程，给出从零搭建一个RAG问答系统的实操步骤和参数选择，最后把我踩过的坑和排查思路整理成一份速查清单。适合正在做大模型应用落地、被"模型不懂业务知识"折磨的开发者和产品经理参考，即便你之前完全没接触过RAG，按文中的思路也能把系统搭起来。

1. "知识冻结"问题到底卡在哪

1.1 预训练就是"背课本"，背完就锁死了

理解大模型的知识边界，先要搞清楚它的知识从哪来。大模型在预训练阶段做的事情，本质上是把互联网上的海量文本"读"了一遍，然后通过数千亿参数把这些文本中的统计规律和事实性知识压缩存储起来。这个过程就像一个人在考前把整本教材背下来，但背完的那一刻，他的知识就定格在教材出版日期了。

模型训练完成后，参数矩阵就固定了。你之后跟它对话，它只是在这些固定参数上进行推理，不可能凭空产生训练时没见过的新知识。这就是"知识冻结"的根源——不是模型变笨了，而是它的"教材"只有那一个版本。

这里有个经常被误解的点：很多人觉得模型回答得不好是因为"没训练好"，于是不停调prompt或换模型。但实际上，只要问题涉及训练数据之外的事实信息，任何模型都没辙。比如你问它你公司最新的项目排期、上周刚发布的内部公告，模型参数里根本没有这些信息，你怎么引导都问不出来。

1.2 三大核心痛点：时效性、专业性、可追溯性

知识冻结带来的问题，在真实业务场景中会放大成三个具体的痛点。

时效性是最明显的。预训练数据有截止日期，而业务信息是持续产生的。产品版本更新、政策调整、内部流程变更，这些信息一旦出现，大模型就处于"盲区"。传统方案是等下一轮训练或微调，但一次全量训练动辄几周甚至几个月，等模型学会新知识，业务早就往前跑了好几轮了。

专业性是第二个大坑。通用大模型的训练数据偏向公开互联网内容，对特定行业的深度知识覆盖不足。你把某个细分领域的内部技术文档、操作手册、历史故障记录丢给它，它就算能生成流畅的回答，内容也往往张冠李戴。我见过有人用通用模型生成设备维护建议，表面看逻辑通顺，但关键参数完全是编的，真要照着操作是要出事故的。

可追溯性则关系到信任问题。模型生成的答案，你没法说清楚它依据的是哪份材料。在客服、法务、医疗这种需要出据可查的场景里，"根据某文档某章节"是基本要求。但普通对话式大模型给不了这种支撑，你只能靠人去复核，效率大打折扣。

1.3 为什么微调不能完全拯救

谈到解决知识冻结，很多人第一反应是微调。确实，微调可以把新知识塞进模型参数里，但它有天然的局限。

首先是成本。微调需要整理高质量的训练数据，需要算力资源，而且每次知识更新都要重新走一遍流程。如果你公司的知识库每周都有新增内容，你会发现自己陷入了一个永远做不完的微调循环。

其次是容量。模型的参数空间是有限的，强行注入大量碎片化的新知识，会挤占原有能力，甚至出现"灾难性遗忘"——学会了新东西，忘了老知识。更麻烦的是，微调让模型记住特定事实时，你很难控制它"记到什么程度"，可能背会了，也可能只背了个大概。

再一个就是可解释性。微调后的模型依然是个黑盒，你没法精确控制它回答时引用哪份证据。这跟RAG的"显式检索+显式引用"是本质区别。

我并不是说微调没用。实际上，微调适合改变模型的"行为方式"（比如语气、输出格式、推理习惯），但如果是注入事实性知识并保持实时更新，RAG是更合理的选择。

2. RAG的核心思路：把闭卷考试改成开卷考试

2.1 一句话讲清RAG的架构

RAG = 检索 + 生成，两段式结构。

你先准备一个知识库，里面存放所有你希望模型"懂"的资料。处理问题时，系统先从知识库中找出与用户问题最相关的若干文档片段，把这些片段和原始问题一起打包，发给大模型。大模型的任务不是"凭记忆回答"，而是"基于提供的材料回答"。

这样设计的好处是：知识不再存在模型参数里，而是存在知识库里。知识库可以随时增删改，模型本身不用动。今天就更新文档，明天回答就生效，知识冻结问题从机制上被绕开了。

用一句通俗的话总结：以前模型是"文科生考前背课本"，现在是"开卷考，带教材进场"。教材可以随时换新版，考生不用重新学习。

2.2 核心流程三步走：索引、检索、生成

一个最小可用的RAG系统，拆开来看就三个环节。

第一步是索引构建。把原始文档（PDF、Word、Markdown、网页等）切分成小段，每一段做嵌入（Embedding），也就是转成向量。再把所有向量存入向量数据库，方便后续按相似度搜索。这一步对应的是"整理教材目录和索引"。

第二步是检索。用户发起问题后，先将问题也做嵌入，然后在向量数据库里用相似度算法找出最接近的K个文档片段（K通常在3到8之间）。这一步相当于"带着问题去查目录，找到相关页码"。

第三步是生成。把检索到的文档片段和用户问题拼接成上下文，交给大模型生成回答。为了让模型严格按照材料作答，提示词里要明确"仅基于以下内容回答，不要使用先验知识；如果材料中没有答案，直接说不知道"。这一步相当于"翻到指定页码，照着内容作答"。

整个流程看起来不难，但每个环节都有不少细节坑，后面我逐个拆解。

2.3 RAG和微调，适合场景完全不同

我做一个直观对比。两者的目标和能力边界有明显差异。

看到这张表你应该也明白了：如果你想改变模型说话的"风格"，让它更像某个角色、某个专家的语感，微调合适；但如果你想让它准确回答某个知识库里的问题，RAG几乎永远是更优解。

3. 从零搭建RAG系统：实操步骤与参数选择

3.1 技术选型：嵌入模型、向量库、生成模型怎么配

既然要动手搭建，我先说说技术选型。市面上可选组件不少，我按关键环节分别给建议。

**嵌入模型（Embedding Model）**负责把文本变成向量。选择时主要看三点：语义理解能力、向量维度、中文支持。目前主流方案里，开源的BGE系列、M3E系列在中文场景表现都不错，闭源API也有不少选择。对一般业务场景，我建议优先用开源模型本地部署，成本低、数据不出内网，隐私上更可控。

向量数据库用来存储和检索向量。选择维度要从数据规模出发：几千条文档的轻量场景，用轻量级方案完全够；上百万条甚至更高的场景，需要考虑分布式能力。实际操作中，可以先从小规模开始，跑通流程后再考虑迁移，不必一上来就上重型组件。

生成模型就是实际回答问题的大模型。这个选择面最广，本地部署的开源模型和云端API都可以。一个关键原则是：生成模型的上下文窗口决定你能塞多少检索内容。如果你的窗口只有8K，检索片段加提示词很容易挤爆，按2K到4K的上下文预算来规划比较稳妥。

3.2 文档切分：chunk大小和重叠是第一个坑

很多人搭建RAG系统，首战即败在文档切分上。切分直接决定了检索质量，切得太大，一段里塞进太多无关内容，检索命中但答案被噪声干扰；切得太小，语义不完整，检索效果也差。

我这里直接给一个经验区间：常规文档，chunk size在300到800字之间，overlap在50到150字之间。这个数值不是拍脑袋，而是平衡了语义完整性和检索精度。你切出来的块太小，模型看不到完整上下文；太大，向量搜索时的语义焦点会被稀释。

具体操作中，我习惯按标题层级来切分，而不是死板地按字数硬切。比如一个文档有章节结构，先按"章"划分，再对超长的章节按段落切，最后用overlap拼接上下文。这样切出来的每个chunk都自带语义边界，检索时更容易命中真正相关的内容。

切分之后还有个细节：要把每个chunk的来源信息（文档名、章节路径、页号）作为元数据存进向量库。这不是可有可无的字段，而是后面做引用溯源的基础。如果没有元数据，模型即使找到了答案，也无法告诉你"这是从哪篇文档得来的"。

3.3 检索策略：向量检索之外，还要多留几条后路

纯向量检索看起来美好，但实测下来有一个明显问题：它对专有名词、缩写、编号类内容不敏感。比如你问"XX-2型设备的维护手册"，如果文档里写的是"XX系列设备维护手册"，向量相似度可能够，但如果文档里正好用的是完全不同的编号形式，向量检索就容易扑空。

所以我现在做RAG系统，基本都会在向量检索之外加一层关键词检索，两者结果合并后再去做重排。关键词检索用传统的BM25算法就行，这类工具很多，实现简单，对精确词匹配非常稳。把向量检索的top结果和关键词检索的top结果合并，相当于同时拥有了"语义理解"和"精确匹配"两套能力。

检索条数K的选择也有讲究。K太小，可能漏掉关键信息；K太大，噪声增多，生成质量反而下降，还浪费上下文窗口。实际调参时，我建议从K=5开始，根据回答质量上下调整。如果发现模型引用了不相关的内容，把K调小；如果发现答非所问、明显缺材料，把K调大。

3.4 生成环节：提示词决定了模型的"纪律性"

生成环节最容易忽视，但它恰恰决定了回答的最终质量。RAG系统的提示词，核心目标是约束模型"只基于材料回答"。

我常用的模板大致是这个逻辑："你是知识库问答助手。请仅根据下面提供的资料回答问题。如果资料中没有提及，请明确回答'资料中未提到'。不要编造，不要使用资料之外的知识。"

这套提示词背后解决的问题是：大模型天生倾向于"说正确的废话"。你给了它材料，它很可能把材料里的内容和它自己记忆里的知识混在一起，最后输出一个看着通顺但事实上混杂了幻觉的答案。明确约束"仅基于资料"能显著压低幻觉率，但注意，这个约束不是百分之百生效的，越是能力强的模型遵纪性越好，小模型容易出现"控制不住自己"的情况。

生成参数也需要调节。温度（temperature）建议调低，0.1到0.3的区间比较合适。温度越高输出越发散，越容易跑题；低温度能保证模型更贴近检索材料。这个参数在测试阶段值得反复试，找到你的业务内容最适合的值。

4. 实操过程中最常见的坑和排查思路

4.1 检索不到相关内容：先别怪模型

RAG系统效果差，十有八九是检索环节出了问题，而不是模型不行。检索不到相关内容时，我建议按下面这个顺序排查。

先检查文档切分是否合理。长文档如果被切得太碎，一个完整的知识点被拆到多个chunk里，检索时任何一个chunk和问题的相似度都不够高，自然就检不出来。我之前处理一份技术规范文档时，按200字切分，检索命中率惨不忍睹，调大chunk之后马上就好了。

再检查查询和文档的"表达鸿沟"。用户习惯口语化提问，文档里写的是书面技术描述，纯向量检索经常对不上。比如用户问"这机器坏了怎么修"，文档里写的是"故障诊断与排除流程"，语义相关但表达差距大。解决方法是引入同义改写，把用户问题改写成一个更贴近文档表达风格的查询，或者像上面说的，混合检索兜底。

最后检查嵌入模型本身。如果你用的是通用嵌入模型，而你的知识库是某个高度垂直的领域，向量空间可能表达不了你的领域相似度。这种时候，有条件的话用领域数据微调一个嵌入模型，效果会大幅提升，但成本也高。在项目早期，先用通用模型跑通流程，等确认瓶颈出在检索上，再考虑这步。

4.2 模型还在"编"，幻觉怎么压下去

RAG系统最大的承诺是减少幻觉，但减少不等于消灭。如果你发现模型仍然会一本正经地编答案，要分情况处理。

先看提示词有没有真正约束住。我测试过很多提示词模板，发现一个普遍问题：模板写得模棱两可，模型不知道什么时候该说"不知道"。改进方法是在提示词里明确告诉模型："如果资料中没有明确答案，必须回复'抱歉，在当前知识库中未找到相关信息'。"越接近输出端的约束越有效。

再看检索到的材料质量。有时候模型"编"不是因为想编，而是材料里根本没有完整答案，它被逼着强行回答。这时候你要做的是提高检索质量，或者在前端就加一层判断：当检索结果的最高相似度低于某个阈值时，直接告诉用户"没有足够把握回答"，不进入生成环节。这个套路在客服场景非常实用，宁可说自己不知道，也不要给用户错误答案。

最后提一个冷门但有效的思路：让模型在回答中标注答案来源。要求它引用文档编号或章节名，比如"根据《设备维护手册》第3章"，一旦模型被要求给出处，它编造的概率会显著下降。因为编造答案的同时还要编出处，对模型来说性价比太低，它会更倾向于守规矩。

4.3 性能与成本：检索很快，生成才是大头

RAG系统部署上线后，你很快会感受到两个性能瓶颈。

第一是检索模块。向量检索本身很快，但如果是海量知识库，索引构建的时间和内存占用都不可忽视。我的建议是：索引构建做成离线任务，定时更新；线上查询走缓存，常见问题命中后直接返回结果，减少重复计算。

第二是生成模块。大模型生成才是延迟和成本的大头，尤其在并发场景下非常吃算力。几个实用招数：一是控制检索片段数量，不要盲目贪多；二是采用流式输出，让用户先看到内容在动，体感延迟大幅下降；三是对高频简单问题做规则化回复，直接绕过模型生成，能省一大笔推理费用。

成本优化上还有一个思路值得尝试：多级策略。先用小模型处理简单问题，用规则或低阈值判断模型置信度，一旦发现小模型搞不定，再升级到更大模型。实际测试下来，这种做法能把整体成本降低30%到50%，而回答质量几乎不损失。

5. 进阶玩法：从"能用"到"好用"

5.1 重排序：让最相关的文档真正排到最前

前面说的检索流程，检索出来的top结果直接交给模型，其实还可以加一道重排序。重排序的原理是：向量检索只是用嵌入相似度粗筛，精度不够；重排序模型会结合查询和文档做更精细的相关性打分，把最相关的文档精准排到最前。

加上重排序之后，你会发现效果提升非常明显。原因也好理解：粗筛环节的目标是"别漏掉"，重排序环节的目标是"排准"，分工明确。代价是增加了一步推理耗时，但换来的是更精准的上下文，整体质量提升远大于这点延迟成本。

重排序模型的选择和嵌入模型类似，都有开源和闭源方案，一般直接对接即可。插入重排序之后，K可以适当调大，比如先粗筛20到30个候选，重排序后再取前5个进生成，效果通常比直接取5个要好。

5.2 知识库的更新节奏和生命周期管理

RAG的好处是知识更新方便，但这也带来了新问题：知识库该怎么管。

我建议把知识库当成一个真正的内容产品来运营。文档有版本、有审核、有过期时间，入库前要清洗格式，入库后要定期检查。一个很常见的坑是：知识库里同时存在新旧两版制度文档，模型检索时随机抽到旧版，给出过时答案。要解决这个，入库时就把版本信息写进元数据，检索时做版本过滤，或者干脆把过期文档标记为不可用。

更新节奏上，成熟的RAG系统大多不是一次性全量更新，而是增量更新：新增文档实时入库，修改文档按版本替换，删除文档打下线标记。配合定时重建索引的机制，既能保证数据新鲜，又不会因为频繁全量重建而占用大量资源。

5.3 什么场景不适合RAG，趁早搞清楚能省钱

RAG虽好，但真不是万能药。我见了不少项目上RAG之后效果反而不如纯生成，问题不在技术，而在场景选错了。

第一类不适合RAG的场景是"需要深度推理和综合判断"。比如让模型根据多份报告写一份行业分析，这种任务需要的是全局理解和创造性的信息重组，而不是单纯的资料堆砌。你把检索内容塞给它，它反而被绑住手脚，写出来的东西缺乏深度。这种场景，你可以考虑把RAG和模型推理能力结合，但期望值要现实。

第二类不适合RAG的场景是"知识更新频率极低且内容高度标准化"。比如固定的法律法规条文问答，内容基本不变，直接微调模型反而更高效，省去维护知识库的精力。

第三类是"问题极其简单、答案极其标准"的场景。比如"订单状态查询"，直接查数据库返回结构化结果，比走RAG快、准、省，何必绕一圈去检索生成。

我个人的判断框架是：如果问题答案需要"翻资料"才能回答，RAG是合理选择；如果答案是人人都知道的常识，或者需要创造性生成，那就不要硬套RAG。场景选对，技术才能发挥价值，这个判断比一切技术细节都重要。

6. 最后分享一点个人体会

RAG这套东西，原理听起来简单，但把每个环节真正调到顺手要花不少时间。我自己调试前面提到的"表达鸿沟"问题时就反复折腾了很久，后来加了混合检索和查询改写才稳定下来。遇到效果不好时，别急着甩锅给模型，耐心排查检索链路，问题通常都在那里。

还有个小建议：任何RAG系统上线前，一定要准备一套覆盖各种提问方式的评测集，固定下来，反复跑。不要凭感觉优化。评测集越贴近真实用户提问，你的调试越有方向。我见过太多项目上线后才发现模型不是不好，而是测试时的提问方式跟真实场景差异太大。

如果你正准备在业务里上RAG，建议先用小规模场景跑通全流程，验证数据质量、检索精度和生成效果，再逐步扩展知识库规模。这个节奏能省掉大量返工成本，比一开始就追求大而全稳妥得多。