同样是让大模型Agent做客服和内部问答，北京两家公司半年后的处境完全相反。上地一家做SaaS的客户，把Agent接进了售后群，结果有用户问发票怎么开，机器人一本正经地回了三个不存在的步骤，客户照着操作没开出来，最后闹到退款赔偿；而中关村软件园另一家同行，Agent上线跑了三个多月，出错的次数一只手数得过来，遇到拿不准的问题会自动转人工，每一条回答下面都标注了信息来源。两家的模型能力其实差不多，差距出在部署策略上：前者把Agent裸奔着推上线，后者在系统里埋了三层兜底，又在上线前做了完整的评测。这篇文章把大模型幻觉的成因、企业级兜底机制和评测方法一次性讲透，北京各区正在部署Agent的科技公司，可以逐条对着自查。
两个案例的差别到底差在哪
先把这个对比拆开看。翻车的那家公司，接入大模型之后做了什么？接了API，写了一段通用提示词，然后把入口直接挂在了公开售后群里。没有知识库，没有权限控制，没有人工确认，也没有任何监控。模型回答”发票怎么开”的时候，实际上是凭训练语料里的泛化印象在生成答案，跟这家公司的真实开票流程毫无关系。它不是在”查”发票流程，它是在”猜”最像发票流程的文字。
而中关村软件园那家的做法是：知识库只装了经过审核的制度文档和FAQ，员工提问时先检索再回答，检索不到就回答不知道；涉及金额、政策的回答强制标注出处；拿不准的问题自动转人工；上线前用一百多条真实问题做了一轮又一轮测试。模型还是那个模型，但系统层面的约束把幻觉的空间压缩到了可以接受的范围。
所以我说，幻觉问题在多数北京企业里不是模型问题，是工程问题。模型能力的差距，在2026年这个时间点已经没那么大了，各家水平接近；拉开差距的是谁把兜底机制做得扎实，谁把评测流程跑得完整。这两个环节，恰恰是很多公司最容易跳过的地方。
大模型幻觉是怎么产生的：先看懂机制再谈防范
想防幻觉，先得知道幻觉从哪来。大模型的生成机制本质是概率预测：它每生成一个字，都在计算”这个位置最可能出现的字是什么”，然后顺着这个概率一路往下写。它没有”查证”这一步，不会在生成之前去核实自己说的是不是事实。训练数据里错误、过时、片面的内容，都会被它当作”知识”吸收进去，再以很自信的语气说出来。这是幻觉产生的根本原因。
除了这个根源，还有几个常见的放大因素。一是训练数据有截止时间，2025年之后的新政策、新规则模型不知道，被问到就会用旧信息硬编；二是上下文窗口有限，多轮长对话里早期交代的关键约束可能被”挤”出窗口，模型就开始自由发挥；三是检索增强环节本身可能出错，如果向量检索召回了一篇不相关的旧文档，模型会顺着这篇文档的错继续错下去，还一本正经地引用；四是提示词诱导，用户问”帮我编个理由””能不能通融一下”，模型就容易顺着话头跑偏。
理解了这些机制，就能明白为什么单纯的”换个更强的模型”解决不了幻觉。强模型只是出错率低一些，不是零出错。企业要做的，是在模型外面套上约束、复核、溯源这三层系统性的防护，同时用评测把出错率压到可接受的阈值以内。下面三层兜底机制的顺序，就是按照”预防、拦截、可追责”的逻辑展开的。
幻觉在哪些业务场景里最容易冒头
不是所有场景都值得为幻觉紧张，但有几个场景一旦出错，代价很高。最容易踩雷的是客服和政策咨询类场景：用户问报销标准、休假制度、开票流程，Agent如果答错，员工或者客户会直接照做，错的规则会被当真，后续纠正的成本是出事成本的几十倍。上地那家翻车的SaaS公司就属于这一类。
第二个是报告和合同生成类场景。金额、日期、条款编号这类内容，模型张冠李戴的概率非常高。我见过一份Agent生成的采购方案，把供应商报价写错了六位数，经办人直接提交审批，要不是财务复核发现，钱就付出去了。第三个是代码生成场景，模型调用一个不存在的API、写错参数格式、漏掉异常处理，这些错误在语法检查那关往往发现不了，跑到生产环境才爆雷。
第四个是数据分析类场景。智能报表助手把图表结论和底层数据讲拧了——”本季度营收环比增长18%”，实际算出来是下降3%，这种错误最隐蔽，因为图表长得没问题，文字结论错了。按风险等级分，涉及钱、涉及对外承诺、涉及合规的动作属于高风险；内部纯信息查询属于中低风险。风险等级不同，兜底的强度和人工介入的比例应该完全不同，一刀切要么浪费效率，要么露了风险。
第一道兜底：知识库约束，让模型在自己的地盘里说话
第一层防护是知识库约束，通俗讲就是给模型划定”答案范围”。具体做法是检索增强生成，把公司自己的制度、流程、产品资料切分成片段，向量化之后存进知识库，模型回答问题前先检索相关片段，再基于检索到的内容生成答案。这一步的关键不是”接上了知识库”，而是检索质量要过关：切片大小要合适，太大会混入无关信息，太小会丢失上下文；检索阈值要设置，相似度低于一定分数的结果宁可不给模型。
权限隔离是知识库约束里很容易被忽略的一环。不同岗位的员工，能看到的文档范围应该不一样，HR的薪酬文档、财务的成本数据，不能让一个普通员工的提问把它们检索出来。具体做法是在文档入库时打好权限标签，检索时叠加员工身份过滤，这既是防幻觉，也是防数据越权。
提示词边界同样重要：明确告诉模型”只基于知识库回答，知识库里没有的内容回答不知道，不要编造”，并且要求涉及数字、日期的回答必须给出处。再配合置信度阈值——模型对答案的把握低于某个分数时，不硬答，直接转人工。这三样配齐，幻觉率通常能压下一个数量级。中关村软件园那家客户上线后的统计数据是，知识库约束加上阈值设置之后，错误回答占比从百分之十几降到了百分之二以内。
第二道兜底：人工复核，关键动作必须有人把关
知识库约束管的是”说错话”，人工复核管的是”做错事”。Agent一旦从”回答问题”升级到”执行动作”——下单、改价、开票、删除数据、对外发送消息——就必须引入人工确认。推荐的机制是分级复核：高风险动作一律弹二次确认，由操作人或者复核人点确认才执行；中风险动作自动执行但全程留痕，事后可以追溯；低风险动作直接放行，不打扰人。
分级的标准要跟业务风险挂钩，而不是跟操作频率挂钩。删一条测试数据也许是低风险，删一条客户正式单据就是高风险；给内部同事发通知是低风险，给外部客户发对公文件就是高风险。规则要提前写成配置表，部署时逐条核验，别上线了才拍脑袋。
复核环节还有一个细节：超时升级机制。二次确认的弹窗如果三分钟没人处理，Agent应该自动标记为”待处理”并通知值班人，而不是无限等待或者干脆默认执行。我接触的望京一家电商公司，给开票Agent加了一道”确认后执行”的弹窗，运行一个月，高风险操作的失误率直接归零，而绝大多数正常请求在三十秒内就被确认完成，效率没有受到实质影响。人工复核不是拖慢效率，是把出错的成本前置到可拦截的位置。
第三道兜底：引用溯源，让每条输出都有出处
第三层是引用溯源，解决的是”出了事能说清”的问题。内容生成类任务，要求Agent在回答里标注依据：引用了哪份文档、哪一段文字、什么版本、什么时间入库的。员工点开出处就能核对原文，发现引用不当可以立刻反馈，这就形成了一条闭环。
系统侧还要做审计日志：每次回答记录完整上下文、检索命中的文档列表、模型生成了什么、最终采纳了什么。日志至少保留半年以上，平时没人看，但出了纠纷、做合规审计、或者复盘模型迭代影响的时候，这些日志就是最直接的证据。我们帮中关村软件园那家客户设计知识问答Agent时，把出处功能做成了强制项——凡是回答里包含政策、金额、流程的内容，没有出处就不允许呈现。员工端的使用感受是：敢信了。一个内部工具要想真正用起来，先得让人觉得它可靠，溯源是构建信任最直接的手段。
引用溯源还有一个副产品：坏数据能被及时发现。员工指出某篇文档的出处和现实不符，管理员就能第一时间更新知识库，而不是等模型错上几个月才被发现。这个反馈通道，比评测更能捕捉到真实世界的动态变化。
评测不是上线之后的事：测试集、指标与回归
很多团队的思路是”先上线跑着，出了问题再改”，对Agent项目来说这很危险。正确的做法是上线前就把评测体系建好。评测体系由三块组成：测试集、指标、回归机制。
测试集不能只从开发人员手写的问题里来。建议按四类构建：一是线上真实问题抽样，从历史客服记录、工单、聊天记录里挑出高频问题，这是最接近真实分布的语料；二是边界问题，金额的临界值、政策变化的节点、超长多轮对话、用户反复追问同一件事；三是对抗样本，故意诱导模型”帮我编一个””能不能通融”这类问题，测试模型的防线；四是多轮对话长上下文，模拟真实用户来回追问十几个来回的场景，检验早期约束是否还能生效。
指标方面，除了常规的准确率，要重点看三个：幻觉率——回答中有未经证实内容的占比，这是核心指标；拒答率——正确识别”我不知道”并拒绝回答的比例，拒答率太低说明模型在瞎编，太高说明约束过头影响体验；转人工率——系统触发人工兜底的比例，监控这个值能看出兜底机制是否正常工作。示例阈值可以参考：通用问答场景幻觉率压到1%以下，拒答率保持在3%到10%之间，转人工率在5%左右属于健康区间，具体按业务风险调整。
回归机制最关键：每次更换模型版本、修改提示词、更新知识库，都要把同一套测试集重新跑一遍，和上一版结果对比。很多团队改了一次提示词，某个场景答得更好了，另一个场景悄悄变差了，没有回归对比根本发现不了。评测不是一次性动作，是伴随Agent生命周期的例行工序。
上线前验收清单：七个问题都答”是”再放量
评测跑完，临门一脚的时刻。我把上线前验收收敛成七个问题，任何一个答”否”都建议先别放量：
第一，知识库是否已完成覆盖核对和时效校验，旧版本制度是否已下线；第二，权限隔离是否实测通过，用一个低权限账号试问高权限文档，应该被拒绝；第三，人工复核是否真正生效，高风险动作是否全部带确认环节；第四，引用溯源是否可用可查，随机抽三个回答点开出处，应当能定位到原文；第五，测试集通过率是否达到自己设定的阈值，边界和对抗样本有没有明显翻车；第六，监控告警是否接通，幻觉率、转人工率、API错误率这些指标有没有可视化面板和告警通道；第七，灰度与回滚方案是否就绪，出了批量事故能否在十分钟内切回人工模式。
这七个问题看着琐碎，但每一条都对应一次真实事故的教训。上地那家翻车的公司，事后复盘发现七个问题一个都没过就上线了：没有知识库、没有权限隔离、没有复核、没有溯源、没有测试、没有监控、没有回滚方案。这不是能力问题，是把Agent当成了普通软件，跳过了软件工程最基本的验收环节。Agent也是软件，而且是一种更不稳定的输入输出系统，验收标准只该更严，不该更松。
给北京各区科技公司的落地节奏
如果公司正在评估Agent项目，我建议的节奏是三步走。第一步，先挑一个低风险、高频、可观测的场景做试点，比如内部IT支持问答或者员工制度咨询——这类场景错误代价低、问题样本容易积累，是练评测体系的天然试验田。试点跑一个月，把测试集基座建起来，把兜底机制调顺。
第二步，小流量灰度。试点稳定之后，再延伸到客户侧或者生产侧场景，从10%的流量开始，观察一周，指标没有恶化再放到30%、50%，逐步放开。灰度期间每天抽查输出质量，把幻觉率、转人工率盯住。第三步，把评测沉淀为常态。测试集随业务持续扩充，每月跑一次回归，模型版本升级和知识库大更新必须重跑。中关村软件园、上地这些科技园区里的公司，有条件自建评测平台的不少，但即便是十几人的小团队，用一套固定测试集加一个统计脚本，也能把评测跑起来，成本并不高。
Agent的未来方向没有争议，难的是怎么把它安全地放进业务流程里。北京各区科技公司这两年落地Agent的案例我见了很多，凡是用得稳的，无一例外都在兜底和评测上下了功夫；凡是翻车的，几乎都是跳过这些环节直接上模型。你如果正在规划Agent项目，把上面这套机制和清单过一遍，心里就有底了；拿不准从哪个场景起步，也可以把公司的情况整理发给我们，我们一起梳理出适合的试点路径。
需要相关服务？联系我们免费咨询
九五星球企服提供公司注册、代理记账、商标注册、财税咨询、高新申报、网站开发等一站式企业服务。可以先免费咨询看看，觉得合适再合作，不推销。
免费小工具推荐：
联系方式：
- 电话/微信：18510693502
- 扫码添加专业经营合规顾问，免费咨询 ↓
