企业官网建设流程全解析

跟大模型打了一段时间交道的人，多少都见过它“一本正经地胡说八道”的场面：你问它一个企业内部的报销制度，它能给你编出一套像模像样的流程，连发文编号都现造一个；你问它某款产品的参数上限，它张口就给你一个不存在的数值。这就是大模型领域常说的AI幻觉。企业知识库一旦放这种模型进来，问题就从“图一乐”变成了“要命”——员工按错误制度操作、客户拿到虚假参数，每一处都可能是事故。

这篇文章我想重点聊聊企业知识库场景里，幻觉为什么会集中爆发，以及我在实际项目中总结出的一套“管住胡说”的工程方法，从RAG检索增强、提示词约束、模型参数调优，到评估闭环和知识库治理机制，适合正在做企业问答助手、智能客服、内部知识中台的同学参考。内容不涉及某个具体商业产品，更多是我自己踩坑之后沉淀下来的通用经验，照着落地就能看到效果。

1. 先搞清楚幻觉的根因：模型本来就不是“查资料”，是“编故事”

1.1 生成式模型的本质决定了它会信口开河

大模型的推理过程，本质上是一个“接龙游戏”。它并不像搜索引擎那样在一堆文档里匹配答案，而是根据前面的文字预测下一个最可能出现的词。训练阶段它见过海量文本，学会了语言规律和知识轮廓，但到了具体回答问题时，它不是在调取某份确切文档，而是在做概率化补全。

打一个生活比方：你把一个没看过公司制度的人突然叫上台，让他讲讲报销标准。他话可以说得很顺，每句话都像那么回事，但里面的金额、日期、流程全是即兴发挥。大模型的幻觉和这个差不多，只不过它的语言能力太强，把编出来的内容包装得比真人还流畅，你很难在第一时间察觉哪里不对。

这里面还有两个推波助澜的因素。一是训练语料天然有滞后性和覆盖盲区，企业内部制度更新到2025年，模型的知识可能还停在2024年；二是细粒度的事实性知识（比如某个项目的编号、某份合同的条款措辞）在你的私有语料里，模型在训练时根本没机会见到，它只能靠“猜一个最合理的”来应对。

1.2 企业场景为什么是幻觉的重灾区

两类幻觉最值得警惕：事实性幻觉，指内容本身是错的，例如把某个产品的保修年限说成3年而实际是2年；逻辑性幻觉，指内容前后矛盾或推导过程站不住脚，例如回答前半段说需要审批，后半段又说可以直接执行。企业场景下事实性幻觉的危害显然更大，因为它直接误导决策。

为什么企业知识库格外严重？三个原因叠加。第一，知识密度高但覆盖度低，制度、产品文档、项目复盘这类资料在开放语料里几乎没有，模型没有兜底知识；第二，用户提问往往带着具体数字、日期、人名，模型记不住这些细节，只能靠概率填空；第三，错误代价不对称，闲聊答错一句最多被嘲笑，制度答错了员工照着执行，轻则返工重则合规事故。

还有一个常见误区：有人觉得“那我直接用企业文档微调一下模型不就行了”。我见过不少团队在这上面栽跟头。微调擅长改变模型的风格和格式，但它非常不适合注入新事实。你把一份新制度放进训练集，模型可能在别的旧制度问题上又把旧答案带出来，因为微调会让参数发生全局扰动，新旧内容互相打架。更现实的问题是，企业制度每周都在变，你不可能每周重新微调一次模型。所以，把事实信息放到模型外部、用检索的方式动态注入，才是更稳的路线。

2. 一条主线：用RAG把事实“焊”进生成链路

2.1 RAG是怎么把“闭卷考试”变成“开卷考试”的

检索增强生成是目前治理幻觉最核心的手段，没有之一。它的设计思路很简单：回答问题之前，先从企业知识库里检索出与问题最相关的若干段落，把这些段落作为参考资料塞给大模型，再让模型基于资料作答。

这个改动命中了幻觉的要害。原来模型需要“凭记忆”回答，记忆一旦模糊就编；现在模型面前摆着原文片段，它需要做的只是“阅读并转述”，编造概率大幅下降。我把它理解为考试形式的转变：闭卷考的是记忆力，开卷考的是阅读理解能力，后者的错误率天然低得多。

RAG完整链路分离线与在线两个阶段。离线阶段做知识入库：文档解析、清洗、切块、向量化、建索引；在线阶段做问答：理解用户问题、召回相关段落、重排、拼接上下文、调用模型生成。整个链路上任何一环做得粗糙，最终回答质量都会被拉低，而幻觉往往是多环节缺陷共同作用的结果。

2.2 入库环节：切块和向量化是最容易出问题的地方

入库的第一步是文档解析。PDF转文本要特别小心表格，很多解析工具会把表格内容按行打散，表头信息丢失，比如“部门”这一列的值和“负责人”这一列的值错位。我常用的做法是：优先找结构化源格式（如Markdown、Word原文），实在只有PDF时，用专门的表格解析组件单独提取表格区域，再把表格转成Markdown格式存入知识库，而不是直接转纯文本。

第二步是切块，这是直接影响检索效果的环节。切太大，一个块里混杂多个主题，向量表示被“平均化”，召回时相关性被稀释；切太小，一个完整知识点被拆得七零八落，上下文信息残缺，模型再聪明也拼不出完整答案。我的经验是：章节点+自然段优先，块大小控制在300~500字之间，并设置80~120字的重叠窗口，确保跨段落的语义不断裂。制度类文档按章节标题切分，产品手册按功能模块切分，避免机械地按固定字数硬切。

第三步是向量化。这里有个很多团队忽略的坑：通用领域的embedding模型在专业术语上表现不稳定。我在一个法律文档项目里测过，某个通用模型对“不可抗力条款”的语义匹配还行，但问到“情势变更制度”时召回效果明显下滑，原因是训练语料里这类专业表达太少。方案是，要么选针对垂直领域微调过的embedding模型，要么在真实业务语料上做小规模评测之后再定模型，不要凭榜单分数盲目选型。向量相似度阈值也要测，阈值设置太高导致召回为空，模型只能瞎编；阈值太低又召回一堆无关段落，污染生成上下文。

3. 工程侧的组合拳：提示词、参数、评估一个都不能少

3.1 提示词里要埋“锚点”，但别指望提示词包治百病

知识库问答的提示词和普通对话的提示词完全是两码事。我用过比较有效的系统提示词结构是这样几层：首先明确角色与任务边界，告诉模型它只能根据提供的资料回答企业相关问题；其次规定信息不足时必须明说“资料中没有找到相关信息”，禁止猜测补全；然后要求引用来源，回答里涉及制度条款或具体指标时，必须标注来自哪份资料的哪个章节；最后给一两个few-shot示例，示例直接演示“无法回答时该怎么说”，效果比单纯用禁止性描述好得多。

这里要泼一盆冷水：提示词能降低幻觉概率，但不能根治。模型在某些时候还是会忽略系统提示，尤其是上下文里有多个相似段落时，它可能选了优先级更高的那个，或者被用户追问带偏。所以提示词只能算第一道防线，后面必须配合检索质量、参数调优和结果校验来兜底。

我实际用过的提示词骨架大概长这样（可直接抄）：

你是企业知识库助手。 回答规则： 1. 只能依据【参考资料】中的内容作答，禁止引用自身常识。 2. 若参考资料不足以回答问题，请明确回复“资料库中没有找到相关信息”。 3. 涉及金额、日期、比例等具体数值时，必须使用资料原文表述，不得自行换算或推测。 4. 引用来源时请注明“资料名称+章节”，例如：根据《费用报销管理办法》第二章。 5. 禁止总结资料中未出现的结论。 【参考资料】 {context} 【用户问题】 {question}

3.2 模型参数不是万能的，但调错一定出事

大模型API里有几个参数直接关系幻觉倾向。生成温度控制随机性，值越高回答越发散。知识库问答场景下，我把temperature稳定在0.1~0.2，小数点后每多一位数都是在拿确定性换创造性，企业问答不需要创造性，需要的是忠实原文。top_p我也习惯限定在0.9以下，进一步压缩解码空间的随机路径。还有一个容易被忽视的是max_tokens，如果限制太短，模型会在回答写到一半时被截断，截断后它有时会“硬收尾”，补一个看似合理的结论，这个结论往往是幻觉。

模型选型上有一条经验：长上下文模型对长文档友好，但成本高、响应慢；小参数模型本地部署省钱，但指令遵循能力弱。我在实际项目里测过某开源小模型，它能把资料里的句子完整复述出来，但一旦用户提问涉及多跳推理（比如“A部门依据哪个制度审批B类项目”），它就开始答非所问。后来折中方案是：简单事实问答走小模型，复杂推理请求走大模型API，按问题分类路由，成本和效果兼顾。

3.3 没有评估指标，你就永远在“感觉它在变好”

治幻觉这件事，最怕的是全靠人工抽查。今天测了5个问题感觉还行，明天换一批问题就崩了，你根本不知道改动是变好了还是变坏了。我强烈建议知识库上线前先建一套评测集，至少覆盖三类样本：常见业务问题、高频易错问题、知识库边界之外的问题（用来测模型会不会“不知道装知道”）。每条样本标注标准答案以及对应参考资料的文档路径。

评估维度我用四个：答案正确率，由标注人员或业务方判断回答是否与真值一致；幻觉率，回答中是否存在资料里没有的信息；引用准确率，模型引用的来源是否真实存在且与回答内容一致；拒答率，对超出知识库范围的问题，模型是否诚实地回答不知道。每次修改知识库或提示词后跑一遍回归，对比前后指标变化。没有这个闭环，前面所有优化都是盲调。

4. 我踩过的坑：召回失败、切块错误、引用编造、上下文污染

4.1 召回失败是“无中生有”的元凶

有一回用户问“报销打车费要什么发票”，知识库里有《费用报销管理办法》，但向量检索没有召回这一段。系统把用户问题抛给模型，模型没有任何资料可用，就开始自由发挥，说了一堆“通常需要增值税普通发票”之类的话。听起来很有道理，但跟该公司内部规定完全不同。

问题出在哪？用户提问是口语化的“打车费”，而文档里写的是“交通费用”，embedding模型对这两个表述的语义关联不够敏感，相似度没达到召回阈值。后来我做了两个改进：一是引入混合检索，向量检索负责语义理解，BM25负责关键词精准匹配，两者结果做加权融合，召回率有明显提升；二是做查询改写，在检索前先把用户口语问题改写成一个更接近文档术语的检索式（比如把“打车费”改成“交通费用报销”），这一招对专业文档尤其好用。

4.2 切块粒度不对，答案张冠李戴

还有一个印象深刻的坑。某份制度文档里，“适用范围”和“违规处理”在同一个大段落里，切块时按固定字数截断，结果“适用范围”的内容被切到了上一块，“违规处理”的内容留在了下一块。用户问“这个制度适用哪些部门”，模型从下一块里找到了一段“对于违规行为处以警告或罚款”，生搬硬套成适用范围，答得牛头不对马嘴。

排查时对照了原文才发现是切块位置不对。后来我改成按文档语义结构切分：先识别章节标题，以标题为边界分段；段落较长时再按句子边界切子块，并保留标题作为子块的前缀元数据。模型每次看到的内容都是“标题+正文”，上下文信息完整，类似问题出现频率低了很多。

4.3 模型编造引用来源，比答案错了更难发现

答案内容可能是对的，但引用来源是编的，这是最隐蔽的坑。有次模型回答“该制度已在2024年修订”，引用了“《员工手册》第三章”，但实际情况是员工手册根本没有这个表述，这个修订信息是模型从用户问题的措辞里推断出来的。用户如果不去查原文，根本发现不了。

治这个问题的办法是引用校验后处理：模型回答完，系统解析出它引用的文档名和章节，去知识库索引里比对是否存在，不存在就拒绝输出该引用，并触发一次重新检索；同时把模型引用的原文段落附在回答后面，让用户可以点开核对。这一步相当于给模型的“参考文献”做了查重。

4.4 多轮对话里，模型会把上一轮的错话当真理

单轮问答做稳了，多轮对话又会冒出新问题。用户先问“公司年假几天”，模型答错成15天；用户继续追问“那我可以拆分休吗”，模型基于上一轮的错误结论继续推演，说什么“15天年假可拆分为两次申请”。对话历史里存的是模型上一次的输出，这个输出本身是错的，被当成了下一轮的事实基础。

我后来做了一个调整：对话上下文里只保留用户的原话和检索到的参考资料，不把模型自己的回答拼进下一轮的上下文；每轮问题都独立完成检索，模型只能依据实时资料作答，不能依赖上一轮“记忆”。这个改动显著减少了多轮场景下幻觉的累积效应。

5. 知识库治理才是长期稳态的关键

5.1 文档生命周期管理：过期文档比没有文档更危险

知识库里的制度文档会版本迭代，旧版本如果没有被及时标记，模型检索时可能优先命中旧版本，导致用户拿到过时信息。我见过最离谱的情况是：公司报销标准已经在年初上调，知识库里还留着去年版本的制度，模型精确地复述了去年的旧标准，数字还对得上原文，员工拿旧标准去报销被财务打回。

解法是给每一份文档打上有效时间标签，检索阶段强制过滤已过期文档；文档更新时走版本发布流程，新版本入库的同时把旧版本标记为失效，但保留历史版本供审计查询。知识库的维护频率，至少要跟企业的制度更新频率对齐。

5.2 权限过滤与最小上下文暴露

企业知识库里有很多文档不是所有人都能看，比如薪酬制度、内部审计报告。检索如果不做权限过滤，模型可能获取到了权限外的内容，要么直接透露给提问者，要么在不该引用时引用了内部信息，产生越权泄露风险。

正确的做法是：用户发起查询后，先用身份信息过滤出他有权限访问的文档集合，再在这个集合内做检索。这一步必须在检索之前完成，不能等向量召回了再过滤。同时控制注入给模型的上下文总量，我通常控制在4~6个片段、总字数1500字以内，片段多了模型会“挑花眼”，反而更容易混入无关信息。

5.3 线上反馈闭环：点踩数据要回流到评测集

知识库问答上线之后，不能停下来。我在项目里做了一个反馈通道：回答下方提供“有帮助/没帮助”按钮，用户点“没帮助”时系统自动记录该问题和回答。运营每周把这些badcase拿出来分析，归类原因——是召回没命中，还是答案质量差，还是资料缺失。每周更新一次评测集，把新出现的badcase加进去，然后就形成了“发现问题→补资料/改参数→回归验证”的闭环。

做了几个月之后，我的体会是：AI幻觉没办法归零，但完全可以被压到可接受范围。关键在于别把希望全押在模型本身，你要靠工程机制、评估闭环、知识库治理这几层网，一层一层把错误拦截在外面。每次看到某个badcase因为调整了切分策略而消失，都会更坚定一个看法：企业知识库的核心工作，不是在调模型，而是在管知识。把知识的获取、更新、过滤、引用校验做扎实，模型的表现自然就稳了。

最后分享一个实用细节：给每条知识库文档打上负责人字段，线上问答如果连续出现某类文档相关的错误回答，系统能自动生成一条待办推送给对应负责人。把AI质量问题和文档维护责任绑定起来，知识库才不会越用越旧，幻觉治理才不是一次性工程。