企业官网建设流程全解析

一个很现实的问题：现在的 AI 模型，尤其是大语言模型，知识储备确实让人惊叹，但“一本正经地胡说八道”也是常态。你问它一个稍微冷门的问题，或者涉及实时信息的问题，它可能给你一个流畅但完全不着调的答案。这种“幻觉”问题在企业落地场景里几乎致命，客户问产品规格，AI 答得天花乱坠但型号对不上，谁敢用？

我自己的经验是，想要让模型“绝对听话”，靠调 prompt 是治标不治本，真正能兜底的技术方案还是 RAG——检索增强生成。它的核心思路说穿了不复杂：与其让模型凭空回忆，不如先从一个可信的资料库里把相关内容捞出来，再让模型基于这些资料作答。答案是“查出来”的，不是“想出来”的，幻觉自然被压到最低。

这篇文章我会从原理讲到实操，再讲到怎么排查问题，把 RAG 防止幻觉的完整链路拆开揉碎，尽量让刚接触这个概念的人也能直接上手。

1. 先从源头看：幻觉到底从哪来，RAG 为什么是对症下药

很多人以为幻觉是模型“笨”，其实不完全是。要理解 RAG 为什么有效，得先搞清楚模型在什么情况下会产生幻觉。

1.1 模型“死记硬背”的局限性

大语言模型的训练过程，说玄乎点叫“学习知识”，说直白点就是让模型记住海量文本里统计规律。训练完的模型，本质上是一个巨大的“概率预测器”，它并不是在数据库里查答案，而是在算“下一个词最可能是什么”。我常用的一个类比是，模型像一个读了十万本书但没做笔记的人，你问它问题，它靠“印象”回答，印象深就答得准，印象模糊就自己脑补。

两个直接后果：

• 训练数据和真实世界有时差。模型的知识截止到训练那一刻，之后发生的事情、新出的参数、刚上的产品特性，它一概不知道，但为了回答你的问题，它只能硬着头皮编一个最像那么回事的答案。

• 训练数据本身覆盖不均。冷门知识、垂直行业细节、企业内部资料，在公开语料里占比很低，模型见过的次数不够多，“印象”就模糊，一模糊就给了幻觉可乘之机。

这两个问题叠加，就是你问一个专业问题，模型给你一个流畅但错误答案的根本原因。

1.2 RAG 的核心思路：把“回忆题”变成“开卷考试”

RAG 的英文全称是 Retrieval-Augmented Generation，中文叫检索增强生成。它的思路非常直白：模型不擅长自由发挥，那就限制它的发挥范围。

我把这个过程比作“开卷考试”：普通模式是让模型闭卷作答，全靠记忆；RAG 模式是先给它一本可信的参考资料，然后要求它“根据参考资料回答问题”，答不上来就老实说不知道，不许自己编。

这个思路在防幻觉上有三个立竿见影的效果：

• 信息新鲜。实时检索外部最新资料，解决了模型知识过时的问题，问了新问题，查到了最新稿，答案自然不会落后。
• 事实可控。模型必须基于检索到的证据作答，“参考答案”就在眼前，编造的难度和可能性都大幅下降。
• 答案可溯源。每段回答都能对应回具体的资料原文，这个回答靠不靠谱，一查便知。

说白了，RAG 不是让模型变得更聪明，而是给模型划定了一个明确的答题范围，“胡说”的空间被从机制上压缩了。

1.3 一个容易踩的认知误区：RAG 不等于“百分百防幻觉”

这里必须先泼一盆冷水。RAG 能大幅降低幻觉，但不能彻底消除幻觉。一个常见的误区是“上了 RAG 就能绝对听话”，实际上 RAG 系统里的任何一环出了问题，幻觉就会以新的形态出现。

有些幻觉是“检索端没找到对的资料”导致的——资料库本身就缺这块内容，或者查到了但排序排得太靠后，模型被迫硬答；有些幻觉是“生成端理解错了资料”导致的——资料是对的，但模型解读过程跑偏了；还有一些是“生成端放大细节”导致的——资料里只提了一句话，模型把它扩写成了一段。所以真正落地 RAG，要做的不只是“装个框架、连个库、丢几份文档进去”，而是把整条链路每一环都盯紧了。这篇文章后面的所有内容，都围绕“把每一环做扎实”展开。

2. RAG 的完整链路：索引、检索、生成，三个环节各自怎么防幻觉

一套标准的 RAG 系统长这样：先有资料准备阶段，把原始文档切块、向量化，建好索引；然后有检索阶段，接到用户问题后，把问题转成向量，去索引里找相关度最高的几个片段；最后有生成阶段，把这些片段作为上下文拼进 prompt 里，让模型基于上下文作答。

三个环节环环相扣，任何一个环节糊弄了，最终答案都会出问题。

2.1 资料准备阶段：分块不合理，后面全白费

这个阶段俗称“建索引”，是 RAG 的地基。地基没打好，后面检索再精确也救不回来。核心工作是两步：把长文档切成小片段，把每个片段变成向量。

分块这件事，很多人都低估了它防幻觉的重要性。如果一块内容太长，比如把一篇三千字的文章整个塞进一个向量里，那检索的时候，单独查某一段细节，匹配到的“整体文章”向量能反映的信息就很模糊，相关的细节反而被稀释掉了。如果切得太碎，又容易把一句话从上下文里割裂出来，单独看完全不知道它在说什么。我的经验是，分块策略必须结合你实际的文档类型来定。

参数分块示例（我个人常用的起始配置）：

chunk_size = 500 # 按字符切分 chunk_overlap = 50 # 相邻片段重叠 50 字符

这个配置只适合通用场景，如果你的资料是技术手册或法律条文，这种固定窗口切法会拦腰截断逻辑完整的条款，建议改成“按标题和章节边界切分”的语义分块策略。倒不是因为这个数字有什么魔力，而是很多资料片段的语义完整性差不多在这个长度附近，太小容易信息残缺，太大检索精度明显下降。

另一个关键步骤是向量化。这一步本质是把文字变成一串数字向量，让模型算“哪些片段和问题最像”。选 Embedding 模型的时候容易踩两个坑：一是直接用原版英文模型处理中文资料，效果差得离谱；二是没有做针对领域数据的微调，通用模型对行业术语的理解往往不够精准。中文场景下我个人更推荐用针对中文语料优化的模型，处理效果明显更好。

2.2 检索阶段：光靠相似度往往不够，召回策略要分层

检索环节的目标是从资料库里捞出“和当前问题最相关”的 Top-K 个片段。这个环节对幻觉的影响最直接——喂给模型的资料对不对，答案就倚仗这个。

纯靠向量相似度检索，有个比较实际的痛点：向量模型擅长捕捉语义相近的内容，但精确的关键词匹配能力偏弱。举个例子，如果你搜的是一段产品型号“XRS-2000 因接口松动导致信号中断”这种包含大量精确代码的技术文本，向量检索可能把“型号相似但不同型号”的内容排到很前面，反而把正确型号的内容排到后面了。这种场景下，我一般建议把关键词检索加进来，做个混合检索：向量检索负责“语义相似”，关键词检索负责“字面精确”，然后两路结果合并去重重排，召回质量会提升不少。

还有召回数量（Top-K）这个参数也要留心。K 值太小，比如只召回 1 个片段，一旦这一个片段没检索准，模型只能对着错误的资料硬答；K 值太大，比如召回了 10 个片段，里面混入大量不相干的内容，模型的选择困难症就犯了，反而容易被干扰项带着走。我常用的经验值：K 设为 4-6 左右，再结合重排序把最靠谱的片段排到最前面。

2.3 生成阶段：Prompt 约束和参数控制，双管齐下

生成环节是最后一道闸门。在这个阶段，防幻觉的核心原则是：明确告诉模型“你只能使用给定的资料回答，不能依赖自己的知识”，并且通过生成参数降低模型的“自由发挥”倾向。

先说 Prompt，一个我实际验证过有效的系统提示词框架（防幻觉向）：

你是一个严谨的问答助手。请基于【资料】中的内容回答用户问题。 规则： 1. 只能引用【资料】中的内容作答，禁止编造资料中不存在的事实。 2. 如果【资料】中没有足够信息回答，请直接回复“我无法从提供资料中找到答案”。 3. 回答中涉及数据、型号、日期等关键信息时，必须严格与资料保持一致。 4. 不要把你自己的推测和资料中的事实混在一起，如果有推测成分，请单独注明“以下为推测”。

这套提示词看起来简单，但每一条都是针对具体的幻觉形态设计的。第一条防“自由发挥”，第二条防“强行作答”，第三条防“细节篡改”，第四条防“推理扩大化”。需要注意的是我是实际操作中踩过坑的，规则写得再细，模型有时还是会忽略低优先级的规则——所以最好别只靠 Prompt 硬约束，配合下面的参数控制一起上。

参数控制主要看三个：temperature、top_p、max_tokens。

• temperature（温度）：控制随机性。值越高越天马行空，值越低越保守务实。RAG 问答场景里我一般把 temperature 调到 0.1-0.2 之间，几乎只选最可能的答案路径，胡说概率显著下降。
• top_p（核采样）：保留累计概率达到阈值的最可能词，一般配合低温，设置在 0.6-0.8 之间。
• max_tokens：限制回答长度。长度受限，模型就没有空间“展开想象”，能有效压缩发散空间。

这套组合拳打下来，生成端的幻觉基本能被压到一个比较可控的范围。

3. 实操落地：从零搭一个能防幻觉的最小 RAG 系统

理论讲完了，直接上实操。这里我用一个最小可用的方案演示，技术栈尽量简单，重点在让你看得懂每行代码在做什么、每个参数在调什么。

3.1 环境准备：装好基础依赖

pip install langchain langchain-community chromadb sentence-transformers

说明一下选型思路：

• LangChain 用来编排 RAG 流程，它把加载文档、切分、向量化、检索、生成这几个步骤封装好了，省去大量胶水代码。
• ChromaDB 做本地向量数据库，轻量、免部署，做原型演示刚好。
• sentence-transformers 负责加载本地 Embedding 模型，生成向量。

3.2 核心代码：建索引加检索加生成，一条龙跑通

from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma from langchain.chains import RetrievalQA from langchain_community.llms import Ollama # 1. 加载文档 loader = TextLoader("product_manual.txt", encoding="utf-8") documents = loader.load() # 2. 分块：每块 500 字符，重叠 50 字符 text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=50, separators=["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""] ) texts = text_splitter.split_documents(documents) print(f"文档被切分为 {len(texts)} 个片段") # 3. 向量化：使用中文优化模型 embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-large-zh-v1.5") # 4. 存入向量库并构建索引 vectorstore = Chroma.from_documents(texts, embeddings) retriever = vectorstore.as_retriever(search_kwargs={"k": 5}) # 5. 配置生成模型：低温、低随机性 llm = Ollama(model="qwen2.5:7b", temperature=0.1, top_p=0.7) # 6. 组装 RAG 问答链 qa_chain = RetrievalQA.from_chain_type( llm=llm, retriever=retriever, return_source_documents=True ) # 7. 测试 question = "XRS-2000 的接口中断故障怎么处理？" result = qa_chain({"query": question}) print("答案:", result["result"]) print("依据片段:", result["source_documents"][0].page_content)

# 输出示例 文档被切分为 26 个片段 答案: 根据产品手册，XRS-2000 接口中断故障首先检查连接线是否松动... 依据片段: 4.2 接口中断排查：若 XRS-2000 接口指示灯闪烁...

几个关键点拆解一下。

那个separators参数我特意把中文标点加进了分割符列表，这是中文文档切分的常见坑，默认分割符对英文句子友好，但中文文案靠标点断句，不加进去就容易把完整句子拦腰切断。

bge-large-zh-v1.5是国产开源中文向量模型，对中文语义的理解比通用模型更好，实测检索准确率提升明显。如果你的是纯英文语料，换回英文模型即可，不必盲从。

k=5表示检索 5 个片段喂给模型，这个值兼顾了信息充分性和上下文长度。片段太少了怕漏，太多了容易引入噪声。

temperature=0.1是防幻觉的关键，我实际测试过用 0.1 和默认值 0.7 做对比，同一个系统问同一个问题，低温模式出现幻觉的频率显著更低，但代价是回答风格更“机械”，不那么灵活。这个权衡大家自己判断。

3.3 上线前必须做的两件事：无答案测试和边界测试

很多新手 RAG 做完能回答问题了，就急着上线。我建议再补两轮测试，专门考它的防幻觉能力。

第一轮是无答案测试。专门挑一些资料库里根本不存在的、但和你的资料主题沾边的问题去问。比如你的资料库里只有产品 A 的手册，你就问“产品 B 的参数是多少”。合格的 RAG 系统应该回答“资料中找不到相关信息”，而不是自己编一个参数。这轮测试如果发现模型答得很“自信”，通常说明你的提示词里“禁止编造”和“无信息时明确拒绝回答”的规则不够强硬，或者还在用高热度的生成参数。

第二轮是边界测试。把问题问得模糊一些、口语化一些，比如“那个新款的接口问题是不是要换线？”你的问题里既有干扰信息又有模糊指代，看检索结果能不能命中正确片段。如果返回的片段跟问题完全不相关，那大概率是分块策略的问题，或者文档格式太乱导致解析失败。

4. 让防幻觉再上一个台阶：重排序、引用溯源与评估体系

最小系统能跑通之后，想要真正把幻觉压到极致，还得上几个进阶手段。

4.1 重排序：别让正确答案排在第二名

不管用的是向量检索还是混合检索，初步检索结果都只是“粗排”，相关度不是特别精准。更好用的做法是加一个重排序层。

重排序的原理是：粗排阶段为了在几十万条数据里快速过滤，用的都是轻量算法，精度有限；重排阶段候选数量已经很少了（一般几十条），可以用更重但更精准的模型来重新打分。行业里常用的是交叉编码器模型，把问题和一个候选片段拼在一起输入模型，让它直接判断“这个片段是否真正回答了这个问题的程度”，相比向量相似度计算，精度高了一大截。

集成方式非常轻，LangChain 里用 ContextualCompressionRetriever 包一层就可以：

from langchain.retrievers.document_compressors import CrossEncoderReranker from langchain.retrievers import ContextualCompressionRetriever from sentence_transformers import CrossEncoder # 加载重排序模型 reranker_model = CrossEncoder("BAAI/bge-reranker-large") compressor = CrossEncoderReranker(model=reranker_model, top_n=3) # 用重排序器包裹原始检索器 reranker_retriever = ContextualCompressionRetriever( base_compressor=compressor, base_retriever=retriever )

用重排序之后，Top-5 中的错误片段基本会被新的排序顶出上下文窗口，模型看到的资料更“纯净”，幻觉率肉眼可见地下降。代价是多一层模型推理耗时，但为了准确性这个花销是值得的。

4.2 引用溯源：让 AI 为它的每一句话负责

实际企业场景里，光“答案正确”还不够，还要“敢于负责”。最好的做法是在 RAG 系统里加上引用溯源机制：每个回答的关键句后面都标注来源片段编号，用户点击就能跳到最原始的文档。

这个机制对防幻觉的意义有两层。

一是外部约束。当模型知道它的回答会配上出处、会被用户逐条核对时，它编造的心里压力会大幅上升，“反正有人查”这个机制本身就是一种很强的约束。在提示词规则里明确写上“回答末尾必须列出引用片段编号”比写十遍“不要编造”都管用。

二是溯源能力。一旦答案出了错，运维人员能顺着引用快速找到是哪个环节出了问题——是原始资料就错了，还是检索召回了错误片段，还是模型理解偏差。没有引用机制，排查就像大海捞针。

4.3 建立评估集：让防幻觉能力可量化、可回归

最后强烈建议维护一个固定的评估集。这套评估集一般包含三类问题：

• 答案有明确定论的事实类问题，用来考察基本准确率。
• 需要从多个片段拼接信息的问题，用来考察综合能力。
• 资料库里没有答案的问题，用来考察“拒答”能力（能不能老实说不知道）。

评估指标不用搞得太复杂，对防幻觉场景我自己常用三个：

• 忠实度（faithfulness）：检查答案的事实是否都能在检索到的资料片段里找到依据。实现上可以让一个独立的强模型来打分，或者手工抽检。
• 命中率（hit rate）：正确答案的片段是否被成功召回。如果答案错了，先看是不是召回的时候就漏了，用这个指标定位问题环节。
• 拒答率：无答案问题的正确拒绝比例。一个 RAG 系统如果什么问题都硬答，那它的防幻觉能力基本不及格。

每次修改分块参数、更新 Embedding 模型、调整提示词，都跑一遍评估集对比分数，你的系统防幻觉能力就从一个“感觉差不多”的经验活，变成了一个能持续迭代的数据活。这一步可能比较枯燥，但长期来看比任何技巧都值钱。

5. 常见问题与排查技巧实录：我实际踩过的坑

最后分享一下我在真实项目中遇到频率最高的几个问题和排查思路，算是实战速查表。

案例一：答案流畅但在编造，检索引擎看起来没问题

我一开始排查方向错了，总觉得答案是“编”的那就是生成端的问题，一顿调 prompt，效果有限。后来认真比对检索结果，发现模型手头根本没有相关资料，才会开始硬编。原因是用默认的向量检索，Top-5 结果里相关片段排在第一位，但我当时用的模型语义理解太弱，前 5 个都是无关内容。后来引入重排序模型，把真正相关的片段稳定送到模型手里，问题消失。

我的排查心得：先看喂给模型的片段对不对——把检索结果打印出来看一眼，再决定是调检索还是调生成。

案例二：检索到了，但答案还是错的

这种情况通常不是“没查到”，而是“查到的内容不够全”。资料切分太碎，导致一个完整的技术流程被拆到了多个片段里，模型只看到第一段就开始作答，后面关键的细节全漏了。

排查方式：看检索回来的片段序号，如果发现一片讲症状、另一片讲原因，但两者被切得驴唇不对马嘴，那就是分块策略的问题。把 chunk_size 适当调大，或者改成按章节切分，一般能改善。

案例三：模型对“查无此事”的拒绝能力不足

我遇到过一种情况：资料库没有答案，模型还是会礼貌地给出一个看似合理的解释，虽然解释的内容全是编的。原因是我的提示词规则写得太温和，模型以为“给出最可能的解释”比“老实说不知道”更符合指令。修正方法是把拒绝规则写得极端一些，比如“如果资料中没有明确记载，必须直接回复‘我无法从提供资料中找到答案’，禁止进行任何猜测或推测”。另外把 temperature 调低也有帮助。

案例四：K 值设置不当带来的幻觉

这个比较隐蔽。之前我把 K 调到 8，想着信息多一点模型选择更丰富，结果是混入了好几个不相关片段，模型在里面挑了个顺眼的片段开始“发挥”，答出来的内容反而比 K=3 时更离谱。后面改成先粗召回 Top-20，重排后取 Top-3，效果才稳定下来。K 不是越大越好，上下文里噪声一多，模型就是会“被带偏”。

提示：遇到任何幻觉问题，排查顺序建议是“资料完整性 -> 分块质量 -> 检索召回 -> 重排序 -> 生成参数 -> 提示词规则”，从数据链路的前端往后查，通常能更快定位根因。

6. 最后分享一点我对防幻觉的体会

做 RAG 防幻觉这一年多，我最深的体会是：不要指望某一个环节“一劳永逸”。防幻觉是整条链路的综合结果，从文档切分到向量检索到重排序到生成控制，每一环都得做扎实，哪里有疏漏，幻觉就会从哪里钻出来。

我个人在实际操作中验证下来，投入产出比最高的三件事是：把分块策略调对、把 temperature 调低、引入重排序。前两件事基本零成本，效果立竿见影；第三件事稍微多一点计算开销，但防幻觉的提升非常显著。

还有一个经常被忽略的细节：资料库本身的质量。去重、格式清洗、版本管理，这些看起来跟“AI”没关系的工作，其实直接影响检索效果和答案准确性。源头是脏数据，下游再多的技巧都是白搭。

最后一个小建议，如果你刚开始做 RAG，千万别急着追求复杂架构，先用最小系统跑通，把评估集建起来，再一步步加能力。等你的系统能对“查无此事”的问题坚定地说“不知道”的时候，你就知道防幻觉这条路，算是走对方向了。