零售企业库存系统幻觉率从15%降至1.5%，靠的不是换模型而是平台化工程重构

在一家大型零售企业的库存准确性平台上线首月，其多智能体大模型系统生成的修正建议中，约15%存在严重幻觉——输出内容逻辑自洽、语言流畅，却完全脱离事实依据。六个月后，这一比例稳定下降至1.5%。值得注意的是，性能提升并非源于更换更强大的基础模型（如从GPT-4切换至Gemini Ultra），而是源于一次架构层面的根本性转变：团队决定不再将大模型能力视为单个业务应用的附属功能，而是将其作为平台级基础设施进行统一建设与治理。

该平台服务于数十个应用团队，覆盖库存审计、补货审查与差异分诊等核心场景。其目标是解决实体零售中长期存在的库存偏差问题：因错放、损坏、盗窃或人工计数错误，系统记录库存与货架实际商品数量持续偏离，进而影响采购决策与供应链效率。系统需对数百万SKU、数十亿条历史库存记录中的异常信号进行分析，并生成可执行的修正建议。

早期原型阶段一切顺利，但首次生产部署后，三类典型故障迅速浮现：首先是LLM API限流，在真实流量下频繁触发厂商配额限制；其次是上下文污染问题——当推荐结果明显不合理时，根因往往出在输入数据质量而非模型本身；最棘手的是幻觉问题：单次请求中概率低，但在持续高并发调用下稳定出现，且传统健康检查无法捕获。

这些故障之所以难以在开发阶段暴露，是因为它们属于“非崩溃型失效”：模型输出语法合法、HTTP状态码正常、延迟指标达标，但语义错误已悄然导致下游业务误操作。例如，系统可能建议“将A商品替换为B商品”，而B商品根本不存在于该门店SKU库中。此类错误往往在数日后才被业务人员发现，造成补货失误或库存盘点混乱。

面对重复出现的问题，团队意识到：若每个应用团队各自实现重试机制、提示词版本管理、Token用量统计与输出校验，不仅成本高昂，更会导致能力碎片化。于是，项目在第二个大模型应用启动前，果断转向平台化路径——这成为后续效率跃升的关键决策点。

平台的核心设计原则是“契约驱动”：应用方声明所需能力（指定模型、提示词版本、结构化Schema、工具集及评估规则），平台负责可靠交付。这种模式使新应用可在数日内上线，因为最复杂的工程问题已被抽象并标准化。

平台架构采用分层解耦设计。外部请求首先经由API网关处理身份认证与JWT签发，网关同时暴露智能体执行接口，并提供按用户/团队维度的指标聚合能力。网关之后是基于Google Agent Development Kit（ADK）构建的根协调智能体，负责意图识别与任务分发；其调度多个专家智能体，每个绑定注册表中明确版本的提示词与强制Schema输出规范。

关键组件包括：

Prompt Registry：支持提示词版本化与回滚，确保变更可控；
Custom LLM Agent：内置Token计算器、重试策略、幻觉追踪器与Schema强制执行器，所有逻辑透明无隐藏抽象层；
Authorization Middleware：实现跨工具服务的身份认证与权限控制；
Observability模块：实时监控成本归属（按请求/团队）、幻觉率、应用健康度与日志追踪，将原本不可见的行为问题转化为可量化、可修复的指标；
MCP Servers（Model Control Plane）：统一管理底层模型调用路由，支持Gemini、GPT等多模型动态切换与负载均衡。

平台另一重要特性是端到端本地可运行性。配套GitHub代码库使用Ollama运行Llama 3.1本地模型，通过LiteLLM对接，避免依赖云端API费用。所有组件均以最小抽象层实现，代码直接取自生产环境简化版，便于理解与复用。

工程实践表明，大模型落地最难的部分并非模型选型或提示词优化，而是构建能支撑企业级流量的可靠性基座。当多个团队共享同一套能力时，重复造轮子的成本迅速超过平台建设投入。更重要的是，平台强制形成的“能力契约”提升了协作效率与系统可维护性。

行业观察显示，当前多数企业仍处于“单点应用”阶段，每个业务线独立接入LLM服务，导致监控割裂、成本不可追溯、幻觉问题反复发生。而真正进入规模化阶段的企业，正逐步将LLM能力纳入与身份认证、日志中心同等地位的基础设施层。这一趋势与微服务架构演进路径高度一致：当某类能力被多个服务高频复用时，下沉为平台服务是必然选择。

值得指出的是，该平台并未追求“通用智能体”，而是聚焦具体业务闭环——库存修正建议必须可验证、可执行、可追溯。例如，所有输出必须符合预定义JSON Schema，缺失字段或非法值会被拦截；工具调用结果需经二次校验；幻觉检测模块会比对输出与知识库中的实体关系，标记高风险响应。

在成本控制方面，平台实现了细粒度Token计量。过去每月账单仅显示总用量，无法定位高消耗应用；现在可精确归因至具体团队与场景，为预算分配与模型选型提供数据支撑。某次排查发现，一个补货审查应用因未限制上下文长度，单请求消耗超20万Token，占全平台12%流量——该问题在平台化前几乎不可能被发现。

从15%到1.5%的幻觉率下降，表面看是技术优化成果，实质是一次工程范式的迁移：从“把LLM当作API调用”转向“把LLM当作需要治理的系统组件”。这种转变要求团队具备平台思维——关注可观测性、可维护性与契约一致性，而非仅追求单次输出质量。

目前该平台已稳定运行超18个月，支撑日均千万级推理请求。后续扩展方向包括引入离线评估流水线、支持多模态输入（如货架图像辅助判断错放），以及将部分专家智能体迁移至轻量级专用模型以降低延迟。但核心原则不变：任何新增能力，优先考虑是否应纳入平台层统一提供，而非作为应用私有逻辑。