生产级大模型平台工程实战手册：从百万 SKU 库存推荐到全链路可观测体系构建

一句话结论

该生产级大模型平台通过严格的 Schema 校验与数据治理，将库存推荐系统的首月 15% 幻觉率降至六个月后的 1.5%，验证了工程化落地价值。

关键要点

• 该库存推荐系统处理数百万 SKU 及数十亿条历史库存记录，服务数十个应用团队，技术栈包含谷歌 ADK（Agent Development Kit）编排层与 LiteLLM 统一路由。
• 故障根因分析显示数据质量而非模型是推荐错误主因，系统通过 Pydantic 结构化校验及 `grounded` 布尔字段强制要求所有结论需文档支撑，否则标记为幻觉。
• 提示词管理采用唯一 ID 与版本控制机制，当前活跃版本 v2.0.0 限定输出 DocsOutput JSON Schema，支持独立部署与回滚，杜绝盲目重试。
• 多团队部署采用 RBAC（基于角色的访问控制）与 PyJWT 无状态令牌，权限策略存于 YAML 且默认拒绝，每个 MCP（Model Context Protocol）服务器独立校验权限。
• 评估层使用 JSON 基准用例集，CI（持续集成）门禁要求工具调用轨迹平均分不低于 0.8，可观测性通过 OpenTelemetry 上报 Token 消耗与成本数据。

背景与事实

在大规模企业级 LLM（大语言模型）应用落地过程中，库存推荐系统面临着处理数百万 SKU 及数十亿条历史库存记录的高并发挑战。该系统服务于数十个应用团队，其技术架构核心包括谷歌 ADK（Agent Development Kit）编排层以及 LiteLLM 统一路由层。LiteLLM 支持连接 Gemini、GPT 等主流模型，同时通过 Ollama 接入本地部署的 llama3.1 模型，实现混合算力调度。在工具服务层面，系统基于 FastMCP 和 Model Context Protocol 构建，确保工具调用的标准化与互操作性。代码库设计摒弃了隐藏抽象层，支持本地端到端运行，极大地降低了开发调试门槛。

在生产环境运行的首月，系统监测到的幻觉率约为 15%。经过六个月持续优化，该指标显著下降至 1.5%。这一改进并非单纯依赖模型升级，而是源于对故障类型的精细化分类。系统将故障划分为 Schema 违规、幻觉信号及基础设施错误三类。在 Schema 设计中，引入了 `grounded` 布尔字段，强制要求所有生成结论必须有文档支撑，否则将被标记为幻觉。此外，系统明确禁用了盲目重试策略，以防止错误信息的累积。根因分析数据表明，数据质量问题而非模型本身是推荐错误的主要原因，这促使团队将重心转向数据治理。

提示词管理方面，平台采用唯一 ID 与版本控制机制，例如将 DocsAgent 划分为 v1.0.0 和 v2.0.0 版本，支持回滚与独立部署。当前活跃版本 v2.0.0 严格限定输出为 DocsOutput JSON Schema，并集成了 Context7 接口。在多租户部署场景中，系统采用 RBAC 与 PyJWT 无状态令牌实现权限管理，权限策略存储于 YAML 文件，遵循“默认拒绝”原则，且每个 MCP 服务器独立进行权限校验。注册中心目前基于内存实现，文档指出在生产环境中需切换至数据库以增强持久性与稳定性。意图验证路由采用 YAML 关键词规则或基于 Transformer 及 scikit-learn 的轻量分类器，当意图未匹配时，系统显式返回“未分类”而非默认选择最高分结果，以避免误判。

可观测性与评估体系是平台工程的关键组成部分。系统追踪幻觉率、成本及 Token 消耗，示例数据显示单次请求包含 191 个输入 Token 和 79 个输出 Token，成本记录为 0.0 美元，延迟为 11.145 秒，数据通过 OpenTelemetry 上报。在评估层，团队构建了基于 JSON 的基准用例集，CI 门禁要求工具调用轨迹平均分不低于 0.8 方可通过。该工程实践确立了六项核心决策：建立可观测层、坚持平台思维、实施提示词版本管理、强制 Schema 校验、添加成本归因标签及构建基准评估集。

影响分析

对于中文开发者与技术从业者而言，该实战手册提供的最大价值在于澄清了 LLM 应用落地的误区。过去许多团队将幻觉率降低归因于更换更强的大模型，但本文事实表明，数据质量与 Schema 约束才是关键。这种“数据质量非模型主因”的认知对正在构建企业级 RAG（检索增强生成）系统的团队具有直接指导意义。开发者应重新审视数据清洗流程，而非盲目堆砌算力。此外，提示词版本控制与独立部署机制解决了多团队协作中的灰度发布难题，使得 A/B 测试与快速回滚成为可能，降低了生产环境变更的风险。

从工程架构角度看，采用 LiteLLM 统一路由与 MCP 协议，为企业提供了从云端模型到本地模型（如 Ollama 运行的 llama3.1）的平滑迁移路径。这对于受限于数据隐私合规或成本控制的国内企业尤为重要。RBAC 与 YAML 权限策略的组合，展示了如何在微服务架构下实现细粒度的 LLM 权限隔离。CI 门禁中“工具调用轨迹平均分不低于 0.8”的标准，为团队量化模型行为稳定性提供了可执行的指标，避免了仅关注最终答案正确性而忽视过程可靠性的片面评估。这一系列工程化手段证明了，生产级 LLM 平台的核心竞争力不在于模型本身，而在于围绕模型构建的可观测、可验证、可控的工程体系。

适用边界

该结论与架构主要适用于高并发、多租户、且对数据准确性有严格要求的 B 端库存或推荐类场景。对于低延迟要求极高的实时交互场景（如 100 毫秒以内的响应），文中提到的 11.145 秒延迟及复杂的工具调用轨迹可能不符合性能边界。此外，基于内存的注册中心虽支持本地端到端运行，但在超大规模集群或强一致性要求的金融核心系统中，切换至数据库的实现细节尚未在文中完全展开，因此该架构在极端高可用场景下的适用性需结合具体数据库选型进一步评估。轻量分类器（Transformer/scikit-learn）适用于意图相对固定的场景，若业务意图动态变化剧烈，可能需要更复杂的语义理解模型，届时现有 YAML 关键词规则可能失效。

孤本观察

本文揭示的工程范式表明，LLM 平台的成熟度不取决于模型参数量，而取决于对“不确定性”的工程封装能力，特别是通过 Schema 校验将非结构化输出转化为可审计的结构化数据。这种将“幻觉”从模型缺陷转化为可监控指标的做法，是技术从业者在生产环境中建立信任体系的关键转折点。

来源：InfoQ 中文 AI