企业级大模型平台将库存系统幻觉率降至1.5%

一家大型零售企业将基于大模型的库存推荐系统投入生产后，首月约15%的智能体结果存在幻觉，即内容表述自信却缺乏事实依据。六个月后，幻觉率降至1.5%，关键并非更换基础模型，而是将大模型能力从应用业务逻辑中抽离，建设统一的平台基础设施。

该系统面向库存准确性管理，分析数百万个 SKU 和数十亿条历史库存记录中的异常信号，为库存审计、补货审查、差异分诊等数十个业务场景生成修正建议。平台由业务、产品、软件工程、数据科学和数据工程团队共同建设，并统一治理 Gemini、GPT 等模型。配套组件均提供在代码库中，刻意避免隐藏抽象；本地版本通过 Ollama 运行 llama3.1，经 LiteLLM 接入，可在无 API 费用的情况下端到端运行。

系统规模化后暴露出三类问题：真实流量触发模型服务限流，错误推荐往往源于输入数据质量不足，以及持续请求下难以避免的幻觉。传统健康检查只能看到低错误率和正常 P99 延迟，却无法发现输出质量下降；若不按请求、团队和应用统计 Token，成本也只能看到供应商提供的总账单。因此，重试与故障分类、提示词版本、Schema 校验、成本统计、行为观测、工具路由及权限控制等能力被统一放到平台层。

平台采用分层架构，唯一入口是网关，负责身份认证、签发带角色信息的 JWT、暴露智能体执行接口、提供用户和团队指标，以及管理员专用的提示词回滚。后端由基于谷歌智能体开发套件 ADK 的根协调智能体识别意图，并分发给绑定提示词和结构化输出 Schema 的专家智能体；专家通过 MCP 服务连接团队工具，服务端在执行前自行验证令牌并完成授权。ADK 回调还用于记录调用成本和延迟，LiteLLM 则允许通过修改模型标识切换本地模型或云端模型。

平台边界强制使用 Pydantic Schema 校验输出，失败时把校验错误追加到提示词并按配置重试，成功后下游才能收到结果。以文档专家为例，输出包含 answer、sources、grounded 和 out_of_scope 字段：只有回答完全由已获取文档支撑时 grounded 才为 true，问题超出范围时则返回结构完整但 grounded 为 false、sources 为空。字段缺失、格式错误、无法解析以及缺乏检索依据都会成为可监控的幻觉信号，而不是被看似合理的文本直接放行。模型只能通过平台接入的 MCP 工具获取上下文，从架构上强化结果的可追溯性。