企业官网建设流程全解析

做生成式AI的这几年，最让我头疼的从来不是模型能力不够强，而是它会在毫无征兆的情况下开始“一本正经地胡说八道”。明明问的是上季度的销售数据，它能给你编出一个根本不存在的产品线；明明内部文档白纸黑字写着A方案，它能自信地跟你说是B方案。这种幻觉问题，一度让我不敢把大模型直接丢进生产环境。直到我把RAG技术引入整个体系之后，情况才真正发生了质变。这篇内容就是我自己从零搭建RAG系统、把幻觉按下去的真实经历，不讲空泛的概念，全部是可落地的方案和踩过的坑。

如果你也正被AI幻觉折磨，或者想搞清楚RAG到底是怎么让大模型变得可信的，这篇内容应该能给你一套能直接用起来的思路。我会从最底层的工作机制开始拆解，再一步步深入到工程实现、参数调优和边界排查，全程沿用我在真实项目里的处理方式和思考逻辑。

1. 为什么大模型总爱“脑补”，以及RAG是从哪个环节动手的

1.1 先搞清楚“AI幻觉”到底是什么

AI幻觉根本不是什么玄学，甚至不涉及“模型不诚实”这类拟人化的解释。大模型本质上是一个概率化的文本生成器，它在预测下一个词的时候，是依据训练阶段见过的海量文本规律来给出候选词的。这就像一个人背了很多书，但他记性好不代表他能把每本书的原文都一字不差地复述出来。遇到陌生的、细节密集的、或者训练数据里压根儿没覆盖好的内容，模型就会走“合理瞎猜”这条路：根据上下文语境，补一段读起来通顺、逻辑上自洽、但大概率与事实对不上的内容。

我在业务里见过最典型的三种幻觉表现：

• 事实张冠李戴。问“某某产品的退货流程”，模型把售前咨询流程讲了一遍，听起来还像那么回事，环节又全又顺，但和真实制度完全不符。
• 凭空捏造数据。问“上月各区域营收”，它给出一串精确到小数点两位的数字，实际上这些数字根本没有出现在任何输入资料里。
• 逻辑断裂自洽。问“为什么系统宕机”，它能编出一个包含整个链路原因的分析，逻辑完美，原因全是编的。

这里有个关键点要反复强调：幻觉不是某个模型的“bug”，而是生成机制本身的一种天然属性。只要模型还在用概率推断未覆盖到的知识，就一定存在幻觉风险。问题的关键不在于“能不能完全消除”，而在于“在生产场景里能不能把幻觉代价降到业务可接受的范围”。RAG就是在这一层切入的。

1.2 RAG不是给模型“加资料”，而是改变了模型回答的证据链

很多人第一次接触RAG（Retrieval-Augmented Generation，检索增强生成）时，理解成“让模型联网查资料”。这个说法太粗了。RAG并不是简单地把外部资料扔给模型看，它彻底改变了模型在回答每个问题时引用证据的方式。

传统大模型是一个封闭的知识容器，你问什么，它就靠参数里存的记忆来“回忆”。这种记忆本身是模糊的、压缩过的、有损的。而RAG的思路是：在每次提问的时候，先根据问题去外部知识库中检索相关片段，把检索结果作为“参考资料”注入到提示词里，然后让模型基于这些资料来组织回答。这样，模型不再靠回忆硬编答案，而是变成“先读材料、再作答”的模式。

我打一个生活化的比方。传统模型像一个上了年纪的专家，你问他某个数据，他凭经验给你报一个可能大概的数字；RAG则让这个专家在回答问题之前，先被要求打开指定的文件柜、翻出对应的档案、再照着档案念答案。档案里有就答，档案里没有就明说没有。这种工作方式从根本上改变了回答的证据来源，从“模糊记忆驱动”变成“外部证据驱动”。

所以，RAG解决的并不仅仅是“知识不够新”的问题——这确实是一层收益，但更核心的收益是它给模型划定了回答的内容边界。只要检索到的知识片段覆盖了问题的正确答案，模型输出的准确性就会成倍提升，因为它不再需要靠内部记忆去猜，只需要正确复述和整理外部证据。

2. 一套能上生产的RAG系统，核心构成到底有哪些

很多教程讲RAG只讲“装个向量库+调个Embedding”，这离能上生产还差得远。我搭建RAG系统时，把整个链路拆成了离线和在线两条线，一条负责准备知识，一条负责实时应答。任何一条出问题，幻觉都可能死灰复燃。

2.1 离线链路：知识库的清洗、切分与向量化

离线链路的目标只有一个：把散落的文档变成可检索的高质量向量切片。这个环节看似机械，实际上决定了整条检索管道的上限。我的经验是，垃圾进垃圾出，文档处理阶段做得多细，直接决定后续模型回答会不会跑偏。

第一步是文档清洗。原始文档格式五花八门，有PDF、Word、Markdown，甚至还有扫描件。PDF里的表格经常被解析成乱码，Word里的页眉页脚会污染正文，扫描件不跑OCR的话内容完全不可用。我之前处理一份产品说明书时，目录、页脚、水印全被解析进了正文，结果模型在回答时把页脚的公司编号当成了产品参数。所以第一步必须做清洗，把无用信息、重复内容、超链接、签名栏全部剔除干净。

第二步是切分（Chunking），这也是整个离线链路里最讲究的部分。很多新手直接按固定字数切，比如一刀切512个token，这种做法的后果就是切出来的片段语义割裂严重。一段业务规则被拦腰切断，前半截讲适用条件，后半截讲例外情况，检索时只召回其中一半，模型自然只能靠猜来补齐另一半，幻觉就是这么来的。我用的切分策略是“结构优先、长度兜底”：先按照文档的章节、标题、段落层级把内容切成语义完整的块，只有在单块长度超过上限时才考虑进一步拆分。对技术文档来说，这样切出来的块基本能保持一个完整信息的闭环。

第三步是向量化。选Embedding模型时，我一开始想当然用了通用的开源模型，但实测下来效果一般，因为业务文档里的专业术语和行业表达，通用模型根本理解不到位。后来我改用领域微调过的Embedding模型，或者在下游检索效果达标的前提下选择适合业务的模型，召回准确率有明显提升。向量化之后还需要做归一化处理，保证后续计算余弦相似度时有统一的量纲。

2.2 在线链路：检索、重排与提示词组装

在线链路是用户在提问时实际经历的部分。标准流程是：拿到用户问题，先做查询改写，然后向量检索Top K个候选片段，再用重排序模型把候选片段重新打分，最后把最相关的片段拼进提示词里送给大模型。

查询改写这一步很多人会忽略，但我建议务必加上。用户真实问法和知识库文档里的表达往往有很大差异，比如用户问“这单怎么办”，知识库里写的是“退货流程”，两者语义上有距离。我用一个轻量级LLM对用户问题做扩展和改写，把口语化的问法转换成更贴近知识库术语的表达。这一步直接提高了检索的命中率。

检索阶段，向量召回负责找出语义相似的片段，Top K我一般设置在20到30之间，先铺开召回，避免漏掉关键信息。但向量检索的结果是有噪声的，光靠它直接喂给大模型很容易让模型被无关或弱相关的资料带偏。所以我会接一个重排阶段，用更精细的重排序模型（Reranker）对召回的候选片段逐一打分，只取前3到5个片段作为最终的参考资料，保证喂给大模型的都是高浓度相关的内容。

最后一步是提示词组装。提示词不是简单地把片段拼接进去，而是要明确告诉模型：你只能基于给定的资料回答，资料里没有的信息，要直接说不知道。我在生产环境里的提示词模板一般会包含角色设定、资料内容、回答要求三个部分，回答要求里一定要写“不要根据常识或内部记忆补充”这类限制性指令。这个看似简单的动作，实际上是对幻觉的又一次截杀。

3. 我踩过的分块坑、检索调优和工程避雷实录

3.1 分块切得好不好，直接决定召回效果

我在这上面吃过很大一次亏。一开始做RAG原型时，为了图省事，用定长句子切分器把所有文档统一切成256个字符的块。原型跑起来看着还行，问什么都能答，但一问到细节就露馅。比如用户问“违约金的计算上限是多少”，系统召回的块只包含了违约金计算方式的开头部分，上限条件在下一块里，最终模型只能自己脑补一个上限比例，编得还挺像。

后来我把切分逻辑换成了基于文档结构来做。对每个文档，先解析标题层级和段落边界，确保每个知识块都尽量是完整的逻辑单元；再为每个块生成标题摘要和元数据标签，检索时顺便带上这些标签做过滤。改完之后，同样的查询，召回的片段从“半句话”变成了“完整条款”，模型的回答准确率直线上升。

如果你在用现成的RAG框架，不要全信默认切分器，一定要自己检查切分后的块是否有语义断裂。我建议你做一次全量抽查：把切分结果随机抽几十条打印出来看看，如果每一条都能独立读懂，说明切分质量过关；如果大量块的开头或结尾是半句话，那就赶紧调整。

3.2 召回率低，别急着怪Embedding模型，先查这三点

我见过太多人一遇到检索效果差就换模型，换了几个大模型回来，问题还在。实际上很多检索问题根本不是Embedding模型造成的，问题往往出在以下三个地方。

第一，查询与文档的表述差异过大。用户说“怎么退货”，知识库写的是“退款及退货流程”，这时候直接用原问题去向量检索，得分必然低。加了查询改写之后，我会把问题扩展成“退货流程”“退款流程”“退货退款操作”“退货条件”等多个查询变体，分别检索再合并结果。

第二，切分粒度与检索目标不匹配。你需要先搞清楚业务问题的粒度是怎样的，如果用户问的都是“某类场景怎么处理”这类宏观问题，切分得太细反而不好，因为单个碎片的信息量撑不起一个完整答案。反过来，如果用户问的是“某个具体参数是多少”，切分太大又会把答案淹没在噪声里。我的经验是先设定多套切分策略，用一批真实问题去跑离线评测，对比不同切分粒度下的召回命中率，再定正式方案。

第三，元数据过滤被忽视了。如果你在清洗阶段就给每个知识块打上了文档类型、时间、所属业务线等标签，检索时就可以根据问题特征做条件过滤。比如用户问“2025年政策”，那么2021年的内容就算语义相似也应被过滤掉。加了这个过滤之后，我系统里的无用召回率明显降下来了。

3.3 重排阶段是决胜局，别跳过去

有段时间我天真地以为向量检索Top K直接喂给大模型就行，实测发现模型经常会从20个候选片段里选到“看起来相关但实际错误”的内容，因为Top 20里塞了不少弱相关的片段，大模型的注意力被噪声干扰了，取用了一些不该用的信息。

加装Reranker是我处理这类问题最有效的一招。Reranker和向量检索不一样，它不是在高维空间里做近似搜索，而是对“查询+候选文档”做深度语义匹配打分，精度更高但速度较慢，所以很适合放在粗召回之后做精排。我用的策略是：向量召回Top 30，Reranker精排后再取Top 4到6个片段送进生成模型。这一步改造完成后，模型引用的资料质量明显上了一个台阶，幻觉的出现频率也肉眼可见地减少了。

重排模型的选型也要根据业务场景来。短文档场景和长文档场景对重排模型的要求不太一样，短文档更看重语义重合度，长文档更看重局部相关段落。我建议你在精排阶段保存几组真实question-answer记录，定期抽查重排结果，确认模型的排序倾向没有明显不合理。

3.4 提示词里的“约束”，是最后一道防线

我在调试RAG系统时发现一个现象：即使检索返回的相关资料完全正确，大模型还是会在回答里“自由发挥”。后来问题定位到提示词模板，因为原来的模板只说了“根据以下资料回答”，没做严格限制。模型觉得，根据资料回答的同时，我还可以用自身知识补充两句，于是幻觉就冒出来了。

我的提示词模板现在是这样设计的：

• 明确身份：你是一个严谨的客服助手，只能回答知识库覆盖范围内的问题。
• 提供资料：以下是检索到的参考资料，请优先采用。
• 输出约束：如果资料中找不到答案，请直接回答“根据现有知识库，我无法回答该问题”，严禁根据常识推测或编造。
• 引用要求：请在回答末尾标注引用资料的来源编号。

加了输出约束后，模型“强行加戏”的情况少了一大半。这个思路不复杂，但很多人会忽略，总觉得提示词写“根据资料回答”就够了，实际上大模型对模糊指令的理解，远比你想象的更离散。

4. 什么时候RAG也会失效，以及我的保底方案

4.1 知识库本身就是错的，RAG只会加重错误

RAG的有效性高度依赖知识库的“纯度”。如果你喂进去的原始文档本身就是错的、过时的、或者相互之间充满矛盾的，那么检索增强不但救不了幻觉，反而会让模型一本正经地用错误资料来编回答。因为RAG只是忠实搬运工，它不负责判断资料本身的真假。

我曾经处理过一个内部知识库，里面有多个版本的制度文档同时存在，新版条款和旧版条款对同一业务的判定标准完全不同。模型在检索时把新旧两版内容都召回了，它也不知道该信哪个，最后直接输出了一段自相矛盾的答案。这个问题不是靠RAG技术能解决的，必须先做知识库治理。我后来在离线链路里加入“版本审查”机制，每条制度文档只保留最新有效版本，旧版本进入归档库不再参与检索，才从根源上清掉了这个雷。

4.2 文档结构过于复杂，检索精确度会下降

RAG对“内容型文档”的检索效果好，对“关系型文档”的效果就差很多。比如一份百页的合规手册，里面有大量交叉引用、条件分支、例外条款，一个条款的正确理解可能要串联三个不同章节。即使检索时把相关片段都召回了，模型也不一定具备把这些片段正确组装成完整答案的能力，因为它看到的只是片段，不是整份文档的全局逻辑。

面对这种场景，我的做法是引入多跳Retrieval：第一轮先检索与问题直接相关的条款，然后在这些条款的基础上做第二轮扩展检索，再把两轮结果合并去重后一起交给模型。另外还可以引入知识图谱，把实体之间的关系结构先建出来，检索时沿着实体关系做定向发散。这些方案成本更高，但在复杂文档场景下确实能补上普通向量检索的短板。

4.3 我的保底思路：退化策略要前置设计

RAG系统在生产环境里最忌讳的事情是“模型不懂装懂”。为了杜绝这种情况，我在生成阶段做了两个保底策略。

第一，给模型设定“最低可信度门槛”。在提示词里加入一个指令：如果给定资料中对某问题的支持度不足，必须明说“信息不足”，不能硬答。同时在后端加了答案与参考资料的相似度校验，如果生成结果与引用片段的相关性过低，系统自动拦截并返回“需要转人工处理”的兜底话术。

第二，针对高风险场景配置“人工审核队列”。不是所有业务都适合完全自动作答。我在涉及资金、法律、合同等高风险问答场景时，RAG生成的答案会先进入审核队列，由人工确认后再正式回复。这套设计牺牲了一些实时性，但在业务安全性上做出了重要保障。

5. 生产环境里的常见问题速查表与避坑清单

我把在实际项目中反复遇到的问题整理成了速查表，方便你对照排障：

这里面有一条通用原则：幻觉每出现一次，就要沿链路追问一次，问题出在输入资料、检索还是生成环节，不要盲目调参。我习惯每次把错误答案连同检索到的Top K资料一起打印出来，看一眼就知道是召回问题还是生成问题。

还有两个工程细节值得单独说：

• 向量库的版本管理。知识库会持续更新，每次重新向量化后不能直接覆盖旧版本，最好保留版本记录，方便回溯和AB测试。
• 检索结果的可观测性。线上系统必须能把每次问答对应的检索片段、重排分数、生成时取消的Token都记录下来。否则模型答错了，你连从哪里排查都不知道。

6. RAG的发展方向上，我更看好哪些新组合

RAG并不是终点，它本身也在持续进化。我在关注几个比较有潜力的技术组合方向，如果你也在做相关项目，可以提前考虑进去。

第一个方向是模块化RAG。传统RAG的检索、重排、生成是固定串联流水线，所有问题都走同一条链路，效率不高。模块化RAG允许系统根据问题类型动态编排不同模块——简单问题直接靠向量检索生成，复杂问题自动启用多跳检索和知识图谱检索。这个思路对降低成本和提升复杂问题回答质量都很有帮助。

第二个方向是Agent与RAG的融合。纯粹的RAG是静态的“查一次资料回答一次”，面对复杂型问题会力不从心；而Agent可以把任务拆成多个子任务，每个子任务执行一次RAG，再把中间结果整合推理。这种“Agent+RAG”模式能有效解决“资料分散在不同文档、答案需要综合多段信息”的场景，我觉得会是各行业落地的重头戏。

第三个方向是图检索增强生成（GraphRAG）。它的核心思路是把知识库转化为实体关系图，把传统向量检索升级成“向量检索+图谱遍历”的组合，适合强关系型数据。做企业知识中台的时候，这个方向很值得关注。

但不管RAG的形态怎么变，底层逻辑我从头到尾都没变过：可信不是模型自带的能力，而是靠工程手段约束出来的结果。RAG的核心贡献就是让模型的输出从“概率猜测”变成“有据可依”，把每一次回答都锁回到可控的知识边界内。做生产级AI应用，这点比模型本身的参数大小更要紧。

我个人在实际操作中的体会是：一套稳健的RAG系统，七成精力花在知识处理，两成花在检索调优，生成阶段的提示词约束只是最后一小步。但恰恰是这小步，常常成为幻觉能不能被压住的关键闸门。先把知识库做“干净”，再让检索变得“精准”，最后用约束把模型输出框“稳”，这条链路走扎实了，你也能让大模型从一个张口就来的“瞎编者”变成一位只念材料、不自由发挥的可靠助理。