企业官网建设流程全解析

前阵子在帮一个团队调内部知识库问答系统，模型时不时就把产品手册里没有的政策“圆”出来，气得业务负责人直拍桌子。后来把整套方案从“裸奔的大模型”改成“检索增强生成（RAG）”架构，所谓的幻觉才终于被按住了。这篇就把 RAG 防幻觉的底层逻辑、落地步骤、踩坑点和评测方法一次讲透，适合正在做大模型应用、又被幻觉折腾得够呛的读者。

1. 幻觉为什么治不住：先看大模型“编答案”的三个根源

要理解 RAG 为什么能防幻觉，先得搞明白大模型为什么会一本正经地胡说八道。很多人以为幻觉是“模型不聪明”造成的，其实根源更深，至少有三个层面。

1.1 参数化记忆：模型大脑里没有“数据库”

大模型对外部世界的所有知识，都被压缩进了几十亿到几千亿个参数里。训练时它看到的是海量文本，但学进去的不是“事实条目”，而是词与词之间的统计规律。你可以把参数想象成一张巨大的概率地图，模型回答问题的方式，是沿着地图上的高概率路径一路往前走，而不是去查某张表。

这带来一个致命问题：参数化记忆没有“原始记录”。它知道“地球直径约12742公里”，是因为训练语料里这句话出现的次数够多，被烙进了参数。可如果你问一个训练语料里只出现两次的冷门公司报销政策，它没有任何参数能对应，只能在概率空间里“猜一个最像答案的组合”。猜对了算运气，猜错了就是幻觉。

我在实际项目中遇到过最典型的例子：同一套模型，问它“我国现行增值税基本税率是多少”，答得又快又准；问它“某事业部内部报销上限是多少”，它竟然编出一个看似合理、实际完全不存在的数字。原因很简单——后者根本不在训练语料里，参数里没有的东西，它只能靠“像不像”来凑。

1.2 概率生成：流畅性优先于正确性

大模型生成文本时，每一步都在从词汇表中挑选下一个 token，挑选依据是前面所有 token 下的条件概率。这个机制保证了输出在语法上极通顺、逻辑上极连贯，但没有任何机制保证它与事实一致。

问题在于：流畅性的“得分”往往高过正确性的“得分”。一段编得滴水不漏的假政策说明，比一段正确但磕磕巴巴的真实引用更容易被模型选中，因为训练语料里出现的多数文本本身就是通顺的，通顺在概率上占了压倒性优势。

这解释了为什么幻觉特别容易被“有经验的非专业用户”接受——编出来的答案往往结构完整、语气笃定、细节齐全。越是自信的输出，越容易被当成权威结论。这也是为什么我在团队里反复强调：大模型的“语气”不等于“证据”，流畅度不能作为正确性的代理指标。

1.3 时空错位：知识截止日与私有知识的真空

模型的知识停在训练截止日，之后发生的一切对它来说都是“未来”。即使你持续用最新数据微调，也不可能覆盖所有变化，更不用说企业内部那些从未公开发布过的流程和规范。

私有知识是幻觉的重灾区。公开互联网上关于“某产品的用户手册”可能只有营销稿，真正的内部操作规范只存在于企业 Wiki、飞书文档或个人邮件里。大模型既没看过，也没有途径知道，你问它“这份合同按什么版本走审批”，它就只能靠通用行业的经验脑补。

所以幻觉不是“修一修 prompt 就能解决”的表面问题，而是模型知识获取方式的结构性缺陷。RAG 的整个思路，就是不再逼模型把知识装进参数，而是在回答时临时“翻书”——这正是对症下药的关键。

2. RAG 是怎么把模型绑在事实上的：最小系统全景

RAG 的核心思想一句话就能讲清：不让模型凭记忆作答，先让模型去外部知识库里检索相关内容，再把检索到的内容作为证据拼进 prompt，让模型“看着证据回答”。这个流程拆开来看，包含离线索引、向量检索、受限生成三个环节。

2.1 离线索引：把文档库变成可检索的碎片

第一步是把你手头的文档（PDF、Word、Markdown、HTML、数据库记录）全部读取、清洗、分块、向量化，然后存进向量数据库。这一步在问答发生之前完成，所以叫“离线”。

分块是个容易被低估的环节。文档不能整本塞进模型，因为大模型有上下文窗口限制，而且检索时需要的是“与问题相关的片段”，不是整本书。我通常把文档按 400 到 800 字切成块，块与块之间保留 50 字左右的重叠，尽量避免把一个完整知识点拦腰切断。

切好的每个块都要过一遍 embedding 模型，变成一串固定长度的浮点数向量。向量的几何意义是：语义越接近的文本，在高维空间里的距离越近。这一步是整个 RAG 能否防幻觉的地基——嵌入质量差，检索到的证据自然不靠谱，后续生成再强也白搭。

2.2 向量检索：用语义距离找“长得像”的证据

用户提问时，先把问题用同一个 embedding 模型向量化，然后在向量数据库里做最近邻搜索，找出与问题向量最相似的 Top-K 个文档块。

这里的“相似”是语义层面的，不只是关键词重合。比如用户问“报销要填什么表”，如果文档里写的是“费用申报单据”，传统的关键词检索很难命中，而向量检索可以靠语义关联把它捞出来。这也是 RAG 相比早年基于 Lucene 的知识库问答的根本优势。

对应到防幻觉上，向量检索的意义在于：模型不再需要从参数里“回忆”答案了，它手里已经有了最相关的几段原文，只要照着念就行。证据从“概率想象”变成了“实际检索”，这是幻觉被压制的第一步，但不是唯一一步。

2.3 受限生成：让模型只对着证据说话

拿到 Top-K 个文档块之后，把它们和用户问题拼成一个新的 prompt，交给大模型生成答案。关键在 prompt 的约束方式：

prompt = f""" 请根据以下参考片段回答用户问题。 规则： 1. 只能使用参考片段中出现的信息，不得使用片段外的知识。 2. 如果参考片段不足以回答，请明确回复“资料不足，无法回答”，不要猜测。 3. 回答中涉及的事实必须能在参考片段中找到对应原文。 参考片段： {top_k_chunks} 用户问题：{question} """

这个 prompt 的意义是把模型的“发散空间”强行收窄。没有约束时，模型会把检索结果当成一个“提示”然后自由发挥；有了“只能使用片段信息”和“资料不足就明说”两条硬规则，模型才真正被绑在证据上。

我在实践里还会加一条：要求模型在回答末尾用 [1] [2] 这样的标记指出每条信息来自哪个片段。这不仅是给用户看的引用，更是给模型自己戴的“紧箍咒”——它知道信息要被追溯，就不敢太随意。

2.4 最小系统骨架代码

用伪代码把完整链路串一遍，方便理解：

# 离线索引 docs = load_files("knowledge_base/") chunks = split_docs(docs, chunk_size=500, overlap=50) vectors = embed_docs(chunks) # 每个片段 -> 向量 build_vector_index(vectors, save_path="idx") # 在线问答 def rag_answer(question): q_vec = embed_query(question) # 问题 -> 向量 top_k = search_index(q_vec, k=5) # 取最相似的5个片段 evidence = [chunks[i] for i in top_k] prompt = build_prompt(question, evidence, rules) answer = call_llm(prompt) # 受限生成 return answer, evidence

这套最小系统已经能解决 60% 的幻觉问题。剩下的 40% 藏在细节里，接下来的五个翻车环节，几乎每一个我都亲手踩过。

3. 从索引到生成：搭 RAG 最容易翻车的五个环节

网上讲 RAG 的教程很多，但大多数只讲到“把文档切碎–存向量–检索–拼 prompt”就结束了。真上线后，你会发现每一步都有隐藏的坑。

3.1 分块切分：粒度决定召回上限

分块过大或过小都会直接影响检索质量。块太大，一个块里混了多个主题，查询向量算出来的相似度被“平均”了，容易召回一堆沾边但不够精准的内容；块太小，语义信息不完整，模型拿到的证据残缺，照样编。

我常用的策略是根据文档类型定粒度：

• 规章制度类：按章节切，每章一块，适合回答“某政策是什么”；
• 产品手册类：按步骤或按功能小节切，适合回答“怎么操作”；
• 表格类：单独处理，把表格转成 Markdown 或“键:值”文本后再切，避免表格被拆散。

切分后建议人工抽样检查五到十个块，看有没有把一个完整定义拦腰切断。这个小习惯能省掉后面大量调优时间。

3.2 Embedding 模型：匹配度的地基

Embedding 模型决定了“语义相似”的判断标准。不同模型的语言理解水平差异巨大，有的能理解“报销”和“费用申报”是同义表述，有的只能做表面同义词替换。

真实项目里，我至少会对比三到五个 embedding 模型，用一组有代表性的问题做召回率测试。测试方法很朴素：每个问题提前标好“应该检索到哪几个文档块”，然后看模型能不能把这几个块排进 Top-10。

这里要给一个很多教程不会提的忠告：不要盲目追求榜单上排名第一的模型，要结合文档语言和领域。中文文档用中文预训练语料占比高的模型往往效果更好，通用英文模型在中文场景下经常出现语义偏移。成本也要算进去——千万级文档做向量化，embedding 的调用费用和耗时都不是小数目。

3.3 Top-k 与重排：召回数量不是拍脑袋

Top-k 设得太小，相关证据可能被漏掉；设得太大，不相关的内容混进 prompt，模型会“被带偏”或者让上下文超长。我一般先从 k=5 起步，根据评测结果调到 3 到 10 之间。

更稳妥的做法是加一层重排序。向量检索负责“海选”，重排序模型负责“精选”。海选时放宽到 Top-20 或 Top-50，再用重排序模型把最相关的 3 到 5 个片段精排出来。重排模型会综合语义、上下文、问题意图做更细粒度的打分，能显著提升证据质量。

这一步对防幻觉的影响非常大。检索回 5 个片段里有 2 个不相关，模型就可能在回答里混进错误信息；重排能把不相关的踢出去，证据纯净度直接决定幻觉率。

3.4 上下文组装：超长截断是“幻觉温床”

把检索到的片段拼进 prompt 时，最容易犯的错是“一股脑全塞进去”。上下文窗口有限，塞太多内容必然导致截断。如果被截断的恰好是结论部分，模型就只能靠上下文猜，幻觉又回来了。

我的组装规则是：按相关性从高到低排列片段，超出窗口的部分果断丢弃，而不是截断。同时控制每个片段在 prompt 中的呈现格式，用分隔符明确标出“片段一”“片段二”，让模型清楚地知道哪些是证据、哪些是问题。

另外，系统提示词里“只能使用片段内信息”这句约束，要放在 prompt 的前部或后部，不要在中间被长片段淹没。实测中，约束放在 prompt 末尾、紧接问题之前，效果往往更好。

3.5 引用机制：给答案“贴发票”

我在最小系统里已经提到引用标记，这里展开说一下它的防幻觉价值。要求模型在答案中标注“根据片段2”，本质上是在强制模型做“事实来源校验”。模型要学会把每个论断和某个具体片段对应起来，编造的难度就大幅上升。

评测时，引用标记还给了我们一个自动化抓手：可以写脚本检查答案里的每个事实句是否能在对应片段中找到原文支持。找不到支持的句子，基本可以判定为幻觉候选。

这一点是我在所有项目里坚持保留的，哪怕业务方说“我们只要答案，不要引用”。我会告诉他们：引用不只是给用户看的，还是给质检系统看的第一道过滤网。

4. RAG 的边界：哪些场景它救不了，以及怎么补

RAG 不是万能药。它把“模型记不住”的问题变成了“系统查得到”的问题，但“查得到”本身也会失败。搞清边界在哪里，才知道怎么补。

4.1 检索为空：再强的模型也只能“编”

如果知识库里根本没有用户问的内容，检索返回空或者全是低相关片段，那模型手里没有证据，只能调用参数记忆硬答。这种情况 RAG 不仅防不了幻觉，反而可能更糟——prompt 里那段低相关证据还会干扰模型判断。

必须给系统设计“拒答”路径：检索相关性低于阈值时，直接回复“知识库中没有相关信息”，而不是硬着头皮生成。这个阈值需要实测校准，调得太严会误伤很多本可回答的问题，调得太松又等于没说。

4.2 证据冲突：比没证据更危险

同一事件在不同文档里说法不一致，或政策更新后旧文档没删除，检索结果里就可能同时存在互相矛盾的证据。模型面对矛盾时往往不做取舍，而是平滑地揉成一个答案，反而产生一种“看似正确、细究全错”的新幻觉。

我会在索引阶段做版本标记，检索时优先返回当前生效版本的文档；同时在 prompt 里加一条规则：“如果参考片段之间存在矛盾，请指出矛盾并优先采用标注为最新版本的内容”。矛盾本身也是信息，让模型明说，比让它默默编一个折中答案安全得多。

4.3 长尾与反直觉知识：向量相似度不是万灵药

向量检索的本质是语义相似度，而相似度不等于正确性。用户的提问方式如果特别口语化、特别隐晦，或者问题的核心是一个专有名词的拼写变体，向量检索就可能完全找错方向。

比如用户问“那个月底要交的表”，知识库里写的是“月末费用结算单”，语义相近，容易命中；但用户问“上个月那个红色的流程截图里提到的事”，如果“红色截图”只是某次会议里的口头描述，没有在文档里体现，向量检索几乎没有命中可能。

这类场景需要引入关键词检索做混合召回，把 BM25 这类传统算法和向量检索的结果合并。两者互补性强：向量管语义，关键词管精确匹配，混合后覆盖度明显提升。

4.4 常见补强：HyDE、重排、意图路由

针对检索质量不足，业界有几个成熟补强手段：

• HyDE（假设性文档嵌入）：让模型先根据问题生成一个“假设答案”，再用假设答案做检索。这种方法在问题表述与文档风格差异大时非常有效。
• 重排序：前面已经提过，向量海选加精排，是投入产出比最高的一步。
• 意图路由：先判断用户问题属于“查询事实”还是“闲聊寒暄”还是“需要摘要总结”，再路由到不同流程。闲聊问题根本不该走知识库检索，路由能省资源也能减少误检干扰。

这些补强手段不是每个项目都必须上，但当你发现幻觉率压在 5% 以内怎么都降不下去时，大概率该往这个方向找突破口。

5. 防幻觉的评测与调优：把“感觉变好了”变成指标

很多团队做 RAG 的调优停留在“感觉变好了”的层面，这种状态很危险。没有量化指标，你无法确定改动是变好还是变坏，更无法向业务方交代。这一节讲讲我实际在用的评测方法。

5.1 用忠实度和支持度量化幻觉

评测 RAG 防幻觉效果，我主要看两个指标：

• 忠实度（Faithfulness）：生成的回答中有多少事实能直接从检索到的证据片段中找到支持。评估方式是逐句比对，找不到原文支持的句子算作“不忠实”。
• 支持度（Answer Relevancy）：检索到的证据片段是否真的回答了问题。如果证据本身就跑偏，生成再忠实也没有意义。

这两个指标一个管“有没有瞎说”，一个管“证据对不对题”，缺一不可。实践中我建议把忠实度作为主指标，因为它是幻觉的直接度量；支持度作为辅助指标，帮助判断问题到底出在检索还是生成。

5.2 评测集构造：别只拿几个问题自测

评测集至少要覆盖三类问题：

• 知识库内高频问题（验证基本能力）；
• 知识库内冷门问题（验证召回深度）；
• 知识库外问题（验证拒答能力）。

每类准备 30 到 50 条就够初期使用。标注答案时分两个维度：给每条问题标注“标准答案”和“应检索到的证据片段编号”。前者用于判断回答正确性，后者用于单独评估检索模块。

我在评测时习惯跑三个版本的对比：纯大模型、简单 RAG、加了重排和拒答逻辑的完整 RAG。四组结果一对比，哪些改进真实有效、哪些只是自我安慰，一目了然。

5.3 我的调优顺序和三个教训

如果只让我说一套调优顺序，我会按这个来：

1. 先修检索：用支持度指标定位召回率，优先解决“证据没找对”的问题。没找对证据，后面全是白搭。
2. 再修生成：证据对了但还在编，就去调 prompt 约束和引用机制，必要时换更强的生成模型。
3. 最后修拒答：把所有场景跑一遍，校准拒答阈值，确保“不知道时真的敢说不知道”。

三个教训值得写在这里：

• 教训一：不要一上来就调 prompt。多数幻觉问题出在检索质量，不是生成约束不足。prompt 再漂亮，证据是错的，输出照样是幻觉。
• 教训二：不要迷信更大的模型。在 RAG 架构里，生成模型的任务被简化成“根据证据作答”，能力差距被大幅拉平。小模型配合高质量检索，在垂直领域常常吊打大模型裸奔。
• 教训三：上线后要持续监控。文档库会更新、用户问法会变，RAG 系统不是“调完就完”的一次性工程。每周抽 20 条真实线上问题做人工抽检，是成本最低的防回退手段。

我在实际项目中体会最深的一点是：RAG 防幻觉的本质不是“把模型变聪明”，而是“把模型的输出从猜测变成引用”。理解了这一点，你在设计系统时的每个决策都会不一样——分块是为了引用更准，检索是为了引用更对，引用机制是为了让引用可追溯。按这个思路落地，在线知识库问答的幻觉率控制在 2% 以下，是完全做得到的事情。