大模型落地 6 个月从 PoC 到生产的差距比想象大基础设施不需要漂亮话。2024 年初我们团队启动了一个大模型落地项目目标是用大模型优化客服系统的自动回复能力。PoC 阶段 2 周就跑通了但真正上线到生产环境花了 6 个月。这篇文章记录的是从 PoC 到生产的完整过程重点在那些 PoC 阶段不会暴露、但生产环境必须解决的问题。一、PoC 阶段的假象PoC 阶段我们用 100 条真实客服对话做测试模型回复的准确率达到了 85%。团队很兴奋觉得马上就能上线。但现在回头看PoC 的测试条件太理想化测试集太小100 条对话覆盖不了真实场景的长尾问题。没有考虑延迟PoC 阶段单次调用 3 秒出结果觉得可以接受。但生产环境要求 P95 延迟 1 秒。没有考虑成本PoC 阶段用了 GPT-4单次调用成本约 0.5 元。如果每天 10 万次调用月度成本 150 万业务方不可能批准。没有考虑安全合规PoC 阶段直接把用户对话发给第三方 API安全团队直接叫停。PoC 通过后我们列了一个生产就绪检查清单最终发现需要解决的问题有 30 个。二、生产落地的核心挑战挑战 1延迟优化——从 3 秒到 800msPoC 阶段的调用链路用户输入 → 调用 GPT-4 API → 返回结果 → 展示给用户生产环境要求P95 延迟 1 秒意味着必须把 3 秒的延迟压缩 70%。我们做了四层优化优化 1Prompt 缓存客服场景有大量重复问题比如怎么退款运费多少这些问题不需要每次都调用大模型。我们做了一个本地缓存把历史问题和对应的优质回复存入向量数据库Milvus新请求先检索相似问题如果相似度 0.95直接返回缓存结果。效果缓存命中率 40%这部分请求的延迟降到 50ms 以内。优化 2模型路由不是所有问题都需要 GPT-4 级别的大模型。我们训练了一个分类模型把用户问题分成三级简单问题占比 60%用 7B 参数的开源模型本地部署中等复杂度占比 30%用 GPT-3.5 Turbo高复杂度占比 10%用 GPT-4通过这个路由策略平均延迟降到 800ms成本降低 70%。挑战 2成本控制——从 150 万/月到 30 万/月PoC 阶段没考虑成本生产环境这是必须解决的。我们的成本优化方案优化手段成本降幅实现复杂度Prompt 缓存40%低模型路由30%中自建推理集群部分场景20%高批量调用非实时场景10%低自建推理集群的决策过程对于简单问题我们评估了自建推理集群的成本云服务 GPU 实例A10月租 8000 元/卡需要 4 卡月成本 3.2 万调用第三方 APIGPT-3.5每次 0.002 元月 1000 万次调用月成本 2 万算下来当月调用量超过 1600 万次时自建更划算。我们当前月调用量是 1200 万次暂时不值得自建。但如果业务增长符合预期6 个月后调用量会达到 2000 万次/月那时候自建推理集群就有必要了。挑战 3安全合规——数据不能出域PoC 阶段直接调用第三方 API这在生产环境是不可接受的。金融行业的合规要求用户数据不能发送到第三方系统。我们的解决方案是混合架构type ComplianceRouter struct { sensitiveDetector *SensitiveDetector localModel ModelAdapter cloudModel ModelAdapter } func (r *ComplianceRouter) Chat(ctx context.Context, req *ChatRequest) (*ChatResponse, error) { // 检测是否包含敏感信息 if r.sensitiveDetector.ContainsPII(req.UserInput) { // 包含个人隐私信息必须用本地模型 return r.localModel.Chat(ctx, req) } // 不包含敏感信息可以用云端模型成本更低 return r.cloudModel.Chat(ctx, req) }这个方案通过了安全审计但引入了新的问题本地小模型的准确率比云端大模型低 15%。这是必须接受的妥协。三、上线后的真实数据系统上线 3 个月我们统计了关键指标业务指标自动回复率从 20% 提升到 65%人工客服工作量下降 40%用户满意度从 4.2 分降到 4.0 分有得有失技术指标P95 延迟850ms勉强达标可用性99.5%目标 99.9%未达标单次调用成本0.12 元比 PoC 阶段降了 76%未达标项分析可用性 99.5% 不达标主要原因是第三方 API 有间歇性超时占比 0.3%向量数据库偶尔有性能抖动占比 0.2%解决方案加了一层 fallback 机制如果大模型调用失败降级到规则引擎回复。四、那些书里不会写的问题理论和实践之间有一道鸿沟。这几个问题是我们踩了坑才知道的问题 1模型的幻觉在生产环境是致命的PoC 阶段模型偶尔会编造信息我们觉得问题不大。但生产环境模型给用户的错误回复可能导致客诉甚至法律风险。解决方案所有模型生成的回复都要经过一层事实性校验对比知识库确认信息准确后才能发出。问题 2Prompt 工程不是一劳永逸的模型升级后比如 GPT-3.5 升级到 GPT-4原来的 Prompt 可能失效。我们遇到过一次模型升级后回复格式从 JSON 变成了自然语言导致下游解析失败。解决方案每次模型升级都要做完整的回归测试Prompt 要版本化管理。问题 3用户反馈闭环比模型本身更重要上线后发现用户对不同类型问题的接受度差异很大。比如查询订单状态这类事实性问题用户接受度高但推荐商品这类主观性问题用户接受度低。我们建立了一个用户反馈收集机制每次对话结束后让用户评价回复是否有帮助。这些数据用来持续优化模型路由策略。五、复盘大模型落地的方法论6 个月落地一个大模型应用时间比预期长但交付质量比预期高。如果重来一次我会调整几个做法PoC 阶段就要考虑生产约束延迟、成本、安全合规这些应该在 PoC 阶段就做初步评估而不是等到 PoC 通过后才发现不可行。先做 MVP 再优化我们花了太多时间在延迟优化上其实可以先上线一个体验版接受较高延迟用真实用户反馈来指导优化方向。建立评估体系比优化模型更重要没有量化的评估指标优化就无从谈起。我们应该在 project 第一天就建立评估体系。最后说一句大模型落地技术只是手段业务价值才是目的。如果模型准确率从 85% 提升到 95%但业务指标没有显著提升那这个优化就没有意义。基础设施不需要漂亮话。能解决实际问题的方案就是好方案。