某零售企业构建生产级大模型平台工程架构

本文基于一家大型零售企业的库存准确性平台实战经验，阐述了为何及如何将大模型能力从应用层剥离，构建统一的企业级平台基础设施。核心观点在于：当幻觉率从 15% 降至 1.5% 时，关键并非更换更强的基础模型（如 Gemini 或 GPT），而是通过平台层统一处理 Token 消耗不可控、行为不可观测及幻觉等规模化故障。 文章详细拆解了实现这一转型的六大工程决策点。首先是强制结构化输出（Schema）校验，利用 Pydantic 在平台边界拦截非预期结果，并将校验失败转化为可统计的幻觉信号而非静默异常；其次是带分类的重试编排，区分 Schema 违规、幻觉信号与基础设施故障，分别采用追加上下文、增强锚定和指数退避策略，并设置硬上限防止流量风暴。此外，平台还实现了提示词的版本注册与运行时回滚，确保变更可审计且无需重新部署应用。 在架构层面，系统采用网关模式进行身份认证与意图路由，结合 MCP 协议隔离工具调用权限，并通过 OpenTelemetry 实现按团队维度的成本归因与行为可观测性。评估体系则引入基准测试用例集作为 CI/CD 门禁，在提示词上线前验证工具调用轨迹与事实锚定得分。文中所有组件均开源于配套 GitHub 仓库，支持本地 Ollama 运行，强调无隐藏抽象层的透明设计。 事实：该平台服务于数十个应用团队，覆盖库存审计、补货审查等场景，代码库包含完整的路由、认证、Schema 校验及评估逻辑。 推断：这种“契约式”平台架构能显著降低多团队协作时的重复建设成本，使新应用能在几天内上线。 猜测：对于缺乏成熟数据工程管线的初创团队，直接套用此架构可能面临较高的初期投入门槛，需权衡短期交付速度与长期维护收益。