15. 你怎么看待大模型应用中"Demo 容易、Production 难"的问题？具体难在哪？

简单回答

Demo 阶段只需要在少数精选 case 上表现好就行，Production 需要在所有真实用户的所有请求上稳定可靠。难在四个层面：效果的长尾问题（80% 的 case 好做、最后 20% 极难）、可靠性和稳定性（LLM 的输出不确定性、外部依赖的故障）、成本和性能（从一天 10 次调用到一天 10 万次调用完全不是同一个问题）、以及持续运维（知识库更新、Prompt 维护、效果漂移监控）。

详细解释

Demo 和 Production 的根本差异

Demo 的目标是证明"这个方案可行"——你可以精心挑选几个能展示效果的 case，在理想条件下运行，不需要处理异常情况，不需要考虑成本和性能，不需要长期维护。

Production 的目标是"在所有真实场景下持续可靠地工作"——你无法预测用户会问什么（包括恶意输入、无意义输入、极端边缘 case），系统要 7×24 运行不能挂，成本要可控，效果不能随时间劣化。

效果的长尾问题

这是从 Demo 到 Production 最核心的挑战。在 Demo 阶段你覆盖了最常见的 80% 的问题类型，效果看起来很好。但上线后会遇到你从没想到过的问题——用户用方言提问、问题包含了多个意图、问题的答案跨了多个文档、用户基于前面的错误回答继续追问导致对话偏离正轨……

这些"长尾 case"每一个的占比可能不到 1%，但加起来可能占用户反馈的 50%。解决这些长尾问题往往比做出最初的 Demo 花费多得多的时间——每解决一个边缘 case 可能需要调 Prompt、加特殊处理逻辑、甚至修改架构。而且解决了 A 的问题可能引入了 B 的回归。

可靠性和稳定性

Demo 阶段一次失败了可以重试、可以换个 case、可以手动干预。Production 不行——每个请求都要有合理的返回，不能白屏、不能挂起、不能返回乱码。

LLM 的输出是不确定的——同一个输入两次可能给出不同的回答。在 Demo 阶段这不是问题（挑好的那次展示就行），在 Production 中就需要处理：输出格式偶尔不对怎么办？结构化输出解析失败怎么办？模型突然开始胡说八道怎么办？

外部依赖的故障——API 限流、网络超时、向量数据库抖动、Embedding 服务挂了……每个外部依赖都可能出问题，都需要有超时、重试、降级、熔断的机制。Demo 阶段网络好好的什么都正常，不代表线上也是。

成本和性能

Demo 一天跑 10 次，用 GPT-4 随便调，不在意成本。Production 一天跑 10 万次，用 GPT-4 一个月可能几万美元。这时候成本优化、模型路由、缓存策略就变得不可或缺了。

延迟在 Demo 阶段等 5 秒无所谓，Production 中用户可能等 2 秒就离开了。需要 Streaming 输出、需要优化检索延迟、需要 Prompt 精简。

并发——Demo 是一个人在用，Production 可能几百人同时在用。需要考虑排队、调度、扩缩容。

持续运维

Demo 做完就放在那里，Production 需要持续维护。知识库更新了要重新索引。模型 Provider 更新了 API 版本要适配。用户的提问模式在变化——上线初期大家问简单问题，三个月后开始问复杂问题。Prompt 需要持续迭代。效果需要持续监控——不是上线了效果好就一直好，模型版本更新、数据分布变化都可能导致效果漂移。

工程化基建

从 Demo 到 Production 的真正跳板是工程化基建：评测体系（自动化回归测试）、日志和监控（每次请求的全链路追踪）、版本管理（Prompt、模型、配置的版本控制）、灰度发布（新版本先放 5% 流量验证再全量）、告警系统（效果指标下降自动告警）。

这些基建在 Demo 阶段完全不需要——但没有它们 Production 就是在裸奔。

面试时可以这样答

"Demo 容易 Production 难"这个问题我感触很深，我觉得难在四个层面。

效果的长尾。Demo 覆盖了最常见的 80% 问题类型，看起来效果很好。上线后那 20% 的长尾 case 会占据大量精力——每一个边缘 case 都可能需要单独处理，而且解决 A 的问题可能引入 B 的回归。

可靠性。LLM 输出不确定、外部依赖可能故障、格式解析可能失败——Demo 阶段这些都不是问题，Production 中每个都需要有应对方案。

成本和性能。一天 10 次和一天 10 万次完全不是同一个问题。成本控制、延迟优化、并发处理在 Demo 阶段零感知，在 Production 中是核心工程挑战。

持续运维。知识库更新、模型版本变化、用户提问模式变化都会导致效果漂移。上线不是终点，是持续优化的起点。

从 Demo 到 Production 的关键跳板是工程化基建——评测体系、日志监控、版本管理、灰度发布。没有这些基建，Production 就是在裸奔。这也是为什么很多看起来 Demo 效果惊艳的项目最终落地困难——不是技术不行，是工程化投入不够。

常见追问

1. 你实际经历中"Demo 到 Production"最大的坑是什么？
2. 你觉得 Production 化需要多少额外的工程投入（相对 Demo）？
3. 怎么向非技术的产品/业务方解释"为什么 Demo 效果好但上线还要这么久"？