把幻觉率从15%砍到1.5%：LLM生产环境平台工程实战

如果你的团队正在把大模型从原型推向生产，大概率会遇到这样一个场景：demo跑得欢，上线第一周指标也漂亮，然后某天运营突然说“这个推荐怎么这么离谱”——系统给出一个自信满满、煞有介事的建议，但实际上这个SKU根本不存在。这就是幻觉，它不像报错那样会弹堆栈，它通过所有传统健康检查，下游服务照常消费，等有人发现时已经产生了实际损失。这篇来自零售业库存准确性平台的技术复盘，讲的就是如何把幻觉率从15%压到1.5%，而撬动数字的杠杆不是换更强的基座模型，而是把LLM栈从“应用层的事”升级成“平台基础设施”。

项目背景是一家大型零售组织，库存记录在物理货架与系统之间会因为错放、损坏、盗窃、误点而产生偏差，多智能体LLM系统要分析数百万SKU和数十亿历史库存记录中的差异信号，生成纠偏建议。团队在beta测试时暴露了三个问题：一是LLM API限流，真实请求量一上来就被供应商掐；二是上下文，推荐不匹配的根因几乎总是喂给模型的数据不对，而非模型本身；三是幻觉，单个看偶发，但生产流量下变成稳定比例。这三个问题有一个共同点：它们都不是应用程序的bug，而是平台层的缺失。

作者的核心洞察是：幻觉率其实是一个“平台可控指标”。他们没有去微调模型，而是在模型外面包了一层自动化重试循环，实时捕获格式错误、接地性（grounding，即回答是否基于给定事实）错误和基础设施错误，再配合意图校验门控——当意图无法被明确分类时返回“unclassified”，而不是默认交给得分最高的那个agent，从而消除了跨agent路由时的离题幻觉。六个月内，生产环境幻觉率从15%降到1.5%。

更值得借鉴的是他们定义的一组平台原语。首先是提示词注册表，把提示词存进带历史记录的仓库，而不是硬编码进应用文件，运行时可以瞬间更新或回滚，改提示词不留审计线索是最容易悄悄破坏AI行为的方式。其次是工具授权，直接在资源服务器上执行严格的默认拒绝（default-deny）策略，只靠API网关校验意味着编排器（orchestrator，负责调度agent协作的组件）任何一个bug都会瞬间暴露所有连接的工具。然后是token成本归因，标准APM工具无法检测语义退化，必须在请求入口（ingress）就埋点统计幻觉率和每个团队的token消耗，事后再想给生产路径补这种归因，会花掉数周工程时间。

架构上，他们把平台做成一个入口网关加根协调器（coordinator agent，使用Google的ADK构建）加多个专家agent（specialist agent），每个专家绑定自己注册表解析的提示词和结构化输出schema，工具连接则是多个独立MCP服务器（Model Context Protocol，模型上下文协议，让模型能调用外部工具的标准化接口），按团队或用途分区，每个服务器在执行工具前自己验证调用者的JWT并强制授权策略。整套代码在配套GitHub仓库里完全可见，不藏抽象，用LiteLLM接本地llama3.1跑通全链路，零API成本就能复现。

看到这套方案时，最让我意外的是作者对“什么时候该建平台”的判断——不是第一个LLM应用，而是第二个。当你有十个团队各发各的LLM功能时，再想在底下塞一层平台，迁移成本会拖垮你。这和当年中心化认证、日志、service mesh的争论几乎一模一样：一旦超过一个应用有同样的横切需求，重复造轮子的成本就开始超过建共享基础设施的成本。

这对我能直接落地的启发有几个：如果你的应用涉及多agent协作，先想清楚“意图分类失败时怎么办”，不要默认选最高分；提示词必须版本化，回滚要在运行时可达；工具权限要下沉到资源端，不信任中间层；从第一天就在请求入口埋token成本和幻觉率，别等出事了再补。坑也明显：这套平台本身有学习成本，而且强制契约（应用声明要什么，平台管怎么给）会限制那些想绕过平台直接调模型的团队。但对于库存、审计、风控这类“AI建议会被自动执行”的场景，把幻觉当基础设施故障来治理，远比每次出问题去追某一个agent的上下文来得靠谱。