背景：从演示原型到生产系统
某技术团队为内部开发者构建智能问答助手，原型阶段采用通用大模型加简单向量检索，演示效果尚可，但进入真实流量后暴露出答非所问、响应时间波动和答案不可追溯等问题。团队的目标不是继续堆叠模型参数，而是把人工智能与机器学习能力工程化：在可接受延迟内返回有依据的答案，并让系统具备持续评估与回滚能力。这一案例的重点，是把检索增强生成链路从实验脚本改造成可运维的智能系统。
挑战：原型到生产的三个断层
第一个断层是检索与生成脱节。向量召回对同义表达友好，却容易漏掉包含精确标识符的文档；生成模型拿到低质量片段后，会以流畅语言掩盖事实错误。第二个断层是延迟波动。查询理解、召回、重排和生成串行执行，任一环节抖动都会放大首字延迟。第三个断层是质量不可观测。离线评估集覆盖不足，线上缺少引用覆盖率、召回命中率和降级触发率等指标，导致问题只能靠用户反馈定位。对技术开发者而言，这些不是单点调参问题，而是数据契约、服务边界和评估机制的系统性问题。
方案：检索增强链路与分层降级
团队将链路拆为查询理解、混合检索、重排、生成和引用校验五个环节。查询理解负责意图分类与关键词抽取；混合检索同时使用BM25与向量召回，并通过去重合并候选集；重排环节采用轻量机器学习模型对候选片段打分，保留高相关内容；生成侧要求模型输出引用编号，再由引用校验模块核对原文。为控制延迟，系统增加语义缓存与片段缓存，对高频问题直接复用结果；生成采用流式输出，并设置超时降级策略，在重排服务异常时回退到基础检索。团队还建立了离线评估集与线上A/B机制，围绕答案准确率、引用覆盖率和首token延迟持续迭代。线上监控看板记录检索命中率、重排分数分布、降级触发率和用户追问率，badcase按周回流到评估集，形成数据飞轮。
评估与灰度：把上线风险拆小
团队没有一次性全量切换，而是按流量比例灰度发布。评估集分为核心事实题、长尾标识符题和多轮追问题三层，每次变更先跑离线回归，再进入5%流量观察。指标门槛明确：引用覆盖率下降超过两个百分点或首token延迟上升超过20%即自动停止放量。检索前执行权限过滤，文档版本与索引版本绑定，避免旧索引返回过期内容。灰度机制让智能问答系统的每次调整都可度量、可回退，也降低了模型升级对开发者的干扰。
效果：延迟与准确率的可量化改善
上线四周后，系统P95首token延迟由2.8秒降至1.4秒，端到端P95延迟由9.5秒降至5.2秒；检索命中率从71%提升到88%，答案引用覆盖率从54%提升到91%。在固定评估集上，人工抽检准确率由76%提升到86%，用户追问率下降约三成。更关键的是，团队可以在出现质量波动时快速定位到检索、重排或生成环节，而不是整体回滚。资源侧通过缓存与重排模型小型化，单位请求的推理开销同步下降，说明工程优化与智能系统效果可以并行推进。
经验总结：可观测性先于模型升级
这个案例说明，人工智能应用落地并不等于换更大的模型。对技术团队而言，优先建设评估集、引用校验和分层降级机制，往往比继续微调模型更能提升稳定性。机器学习负责排序与召回，智能系统负责编排与治理，两者需要清晰边界。建议在项目早期就定义可观测指标，把检索质量、生成质量和延迟拆开度量；同时为每个环节设置可回退路径，避免单点故障拖垮整体体验。只有把AI能力放进可评估、可监控、可降级的工程框架中，智能问答才能从演示走向生产。