把 LLM 从实验室搬到生产环境，远不只是加个 API 调用。记录一次完整的 LLM 工程化过程中的关键决策与踩坑。

起因

每次看到”5 分钟用 ChatGPT API 做一个 XXX”的教程，我都会想：然后呢？

Demo 和生产之间隔着的不是代码量，而是一系列工程决策。这篇文章记录我在一个真实项目中，把 LLM 能力从 Demo 推到生产的过程。

Demo 阶段的假象

Demo 通常是这样的：调一次 API，拿到结果，展示到界面上。看起来一切正常。

但真实场景里，你会遇到：

  • 延迟不可控：LLM 响应时间从 1 秒到 30 秒不等，用户体验怎么设计？
  • 输出不稳定：同样的 Prompt，不同时间的输出格式可能完全不同
  • 成本不透明：Token 计费 + 并发场景下，成本会指数级增长
  • 错误处理缺失：Rate limit、超时、幻觉内容，这些 Demo 里都不存在

关键工程决策

1. Prompt 管理必须工程化

Prompt 不是写在代码里的字符串，它是一个需要版本控制、A/B 测试、持续优化的工程产物。

我们的做法：

  • Prompt 模板与代码分离，存储在配置系统中
  • 每次修改都有版本记录，可回滚
  • 关键 Prompt 有对应的评测数据集

2. 结构化输出是刚需

自然语言输出对人友好，但对下游系统不友好。我们强制要求 LLM 输出 JSON 格式，并用 schema 校验。

输出校验失败率从最初的 15% 降到了 2%。

代价是 Prompt 变得更复杂，但可靠性是值得的。

3. 流式响应 + 缓存策略

  • 流式输出解决了长等待的用户体验问题
  • 对于高频相似请求，引入语义缓存（不是简单的字符串匹配）
  • 缓存命中率稳定在 40% 左右，直接砍掉了近一半的 API 成本

4. 可观测性

你无法优化你看不到的东西。我们给 LLM 调用加了完整的可观测性：

  • 每次调用的 Prompt、输出、Token 消耗、延迟
  • 输出质量的自动评分（基于规则 + 人工采样）
  • 成本仪表盘和预警

真正的难点

技术实现反而不是最难的部分。最难的是：

如何定义”好”的输出？

LLM 的输出是概率性的，不像传统代码有确定性的对错。你需要建立一套评估体系——这个体系本身就需要不断迭代。

结论

LLM 工程化不是”把 API 包一层”，而是围绕一个不确定性组件构建可靠系统。这需要：

  • 工程思维（而不只是算法思维）
  • 系统设计能力（而不只是调参能力）
  • 对成本和质量的持续关注

如果你正在做类似的事情，希望这些经验有所帮助。

本文来自真实项目实践，欢迎交流探讨。