20.人工智能实战：大模型项目如何从 Demo 走向生产？一套可落地的上线验收清单与工程治理方案
人工智能实战：大模型项目如何从 Demo 走向生产？一套可落地的上线验收清单与工程治理方案
一、问题场景：Demo 很惊艳，上线就翻车
很多大模型项目都有一个相似过程：
第一周：Demo 效果很好 第二周：老板觉得可以上线 第三周：接入真实用户 第四周：问题集中爆发常见翻车点包括：
1. 回答不稳定 2. 接口偶发超时 3. RAG 检索不到资料 4. 模型幻觉严重 5. GPU 显存爆 6. 高峰期服务崩 7. 日志查不到原因 8. 数据更新后仍回答旧内容 9. Agent 工具调用错误 10. 输出 JSON 解析失败这些问题单独看都不难，但放在一起就说明：
项目还停留在 Demo 阶段，没有进入生产工程阶段。这篇文章不是讲某一个技术点，而是总结一套大模型系统上线前必须做的工程验收方案。
二、Demo 和生产系统的区别
Demo 关注：
能不能跑 效果是否惊艳 能不能展示生产系统关注：
能不能稳定 错了能不能查 慢了能不能定位 挂了能不能恢复 数据变了能不能更新 成本能不能控制一句话：
Demo 证明可行性，生产验证可靠性。三、生产级大模型系统架构
一个相对完整的架构应该包含：
Client ↓ API Gateway ↓ Auth / RateLimit ↓ Model Gateway ↓ RAG / Agent / Tool Router ↓ Queue / Scheduler ↓ LLM Inference Service ↓ GPU旁路能力包括：
监控 日志 Trace 评测 灰度 回滚 数据更新 权限控制如果系统缺少这些能力，上线后一定会踩坑。
四、上线验收维度
我建议从八个维度做验收：
1. 功能正确性 2. 检索准确性 3. 生成稳定性 4. 性能与并发 5. 容错与降级 6. 可观测性 7. 数据更新机制 8. 安全与权限五、功能正确性验收
首先要建立测试集。
test_cases=[{"question":"一线城市住宿费最多报销多少？","expected_keywords":["500元","一线城市"],"category":"报销制度"},{"question":"生产环境发布前需要做什么？","expected_keywords":["代码评审","自动化测试","灰度发布"],"category":"上线规范"}]简单评测脚本：
defevaluate_answer(answer:str,expected_keywords:list[str]):missing=[]forkeywordinexpected_keywords:ifkeywordnotinanswer:missing.append(keyword)return{"passed":len(missing)==0,"missing":missing}不要只靠人工体验。
必须有固定测试集。
六、RAG 检索验收
RAG 系统必须评估：
1. Recall@K 2. MRR 3. 引用正确率 4. 无答案拒答率示例数据：
rag_eval=[{"query":"员工入职多久有年假？","positive_doc_id":"leave_policy"}]评估逻辑：
defevaluate_retrieval(retrieved_doc_ids,positive_doc_id,k=3):top_k=retrieved_doc_ids[:k]return{"hit":positive_doc_idintop_k,"rank":top_k.index(positive_doc_id)+1ifpositive_doc_idintop_kelseNone}上线要求：
高频问题 Recall@3 至少达到可接受阈值具体阈值要按业务定，但不能没有。
七、生成稳定性验收
生成侧要检查：
1. 是否严格基于资料回答 2. 是否引用资料 3. 是否会编造 4. 是否输出格式稳定 5. 是否允许无法确定结构化输出场景还要验证：
defis_valid_json_output(output:dict):required_fields=["name","skills","level"]forfieldinrequired_fields:iffieldnotinoutput:returnFalsereturnTrue如果 JSON 解析失败率很高，不能上线。
八、性能压测验收
必须压测：
1. 单用户延迟 2. 并发 QPS 3. P95 / P99 4. 错误率 5. GPU 利用率 6. 队列等待时间Locust 示例：
fromlocustimportHttpUser,task,betweenclassLLMUser(HttpUser):wait_time=between(0.5,2)@taskdefchat(self):self.client.post("/chat",json={"prompt":"解释一下公司报销制度","max_tokens":128})上线前不要只看平均延迟。
必须看：
P95 / P99因为用户投诉通常来自尾延迟。
九、容错验收
必须验证：
1. 主模型失败是否 fallback 2. 队列满了是否拒绝 3. 工具调用失败是否兜底 4. Redis 挂了是否有错误提示 5. vLLM 超时是否熔断模拟模型失败：
defmock_llm_call(prompt:str):raiseRuntimeError("model unavailable")系统应该返回：
服务繁忙，请稍后再试而不是：
500 堆栈错误十、监控验收
上线前必须有这些指标：
QPS 错误率 P95 / P99 队列长度 GPU利用率 显存占用 模型调用耗时 fallback次数如果没有监控，系统上线后就是裸奔。
Prometheus 指标示例：
fromprometheus_clientimportCounter,Histogram REQUEST_TOTAL=Counter("llm_request_total","LLM request total",["status"])REQUEST_LATENCY=Histogram("llm_request_latency_seconds","LLM latency")十一、日志验收
每次请求必须记录：
trace_id user_id question retrieved_docs model_used latency status error示例：
log={"trace_id":trace_id,"user_id":user_id,"model_used":model_name,"retrieved_docs":doc_ids,"latency_ms":cost_ms,"status":"success"}没有这些字段，出了问题无法排查。
十二、数据更新验收
知识库系统必须验证：
1. 文档更新后是否重新切分 2. 向量是否更新 3. 旧版本是否失效 4. 回答是否引用最新版本测试流程：
1. 导入 v1 文档 2. 提问，确认回答 v1 3. 更新为 v2 4. 重新提问，确认回答 v2 5. 确认旧版本不再参与检索十三、安全与权限验收
企业场景必须考虑：
1. 用户是否只能访问有权限的文档 2. Prompt 是否可能泄露系统提示词 3. 是否过滤敏感信息 4. Agent 工具是否有权限控制 5. 高风险操作是否二次确认错误示例：
普通员工问到了财务内部制度这不是模型问题，是权限系统问题。
十四、上线 Checklist
功能： [ ] 高频问题测试通过 [ ] 结构化输出可解析 [ ] 无答案能拒答 RAG： [ ] Recall@K 达标 [ ] 引用正确 [ ] 文档版本正确 [ ] 数据更新可验证 性能： [ ] P95 达标 [ ] P99 可接受 [ ] 错误率达标 [ ] 队列无异常积压 稳定性： [ ] 限流可用 [ ] 熔断可用 [ ] 降级可用 [ ] fallback 可用 监控： [ ] QPS [ ] 错误率 [ ] 延迟 [ ] GPU [ ] 队列 运维： [ ] 日志可追踪 [ ] 支持灰度 [ ] 支持回滚 [ ] 有告警十五、踩坑记录
坑 1：没有测试集就上线
Demo 看起来好，不代表真实问题能答好。
必须有评测集。
坑 2：只测正常问题
必须测试：
无答案问题 模糊问题 超长问题 恶意问题 高并发问题坑 3：没有回滚
模型升级、Prompt 修改、知识库更新都可能引入问题。
必须能回滚。
坑 4：没有 trace_id
线上排查时会非常痛苦。
坑 5：只关注效果，不关注成本
大模型系统上线后，成本会变成真实问题。
必须统计：
tokens 调用次数 模型成本 GPU成本十六、经验总结
大模型项目从 Demo 到生产，最大的变化不是模型，而是工程体系。
生产系统必须具备：
可评测 可监控 可追踪 可回滚 可降级 可扩展一句话总结：
大模型上线不是把接口暴露出去，而是建立一套能长期运行的工程系统。十七、后续优化建议
后续可以继续做：
1. 建立自动化评测流水线 2. 每次 Prompt 修改都跑回归测试 3. 每次知识库更新都做抽样验证 4. 引入灰度发布 5. 建立线上 badcase 回收机制 6. 定期复盘错误回答 7. 按业务线统计模型效果 8. 建立成本看板最后一句经验：
能演示的 AI 很多，能稳定上线的 AI 很少。差距就在工程治理。