从 Demo 到生产：一个 RAG 系统的工程化演进之路
做 AI 应用，最贵的教训不是技术选错了，而是以为 Demo 能跑就等于生产可用。
开场：为什么你的 RAG 系统上线就翻车
假设你花了一个周末，用 LangChain + Chroma + GPT-4 搭了一个企业知识库问答系统。
本地测试效果不错：上传 PDF、切 chunk、向量化、检索、回答，一条龙跑通了。你信心满满地部署上线，等着收获用户的赞美。
结果第一周就收到一堆反馈：
- "有时候答非所问"
- "同样的问题，上次回答得好好的，这次就不行了"
- "感觉不太靠谱，不敢当真"
你开始排查，发现：
- Token 消耗超出预期 3 倍
- 出了问题不知道哪里错了，只有简单日志
- 检索质量不稳定，但不知道具体是哪些场景有问题
欢迎来到 AI 工程化的真实世界：Demo 能跑和生产可用之间，隔着整整一套工程体系。
第一阶段：Demo 能跑（但仅此而已）
大多数 AI 项目的起点都差不多：
# 典型的技术栈
框架：LangChain / LlamaIndex
向量库：Chroma / Milvus / Pinecone
模型：GPT-4 / Claude / 开源模型
功能：上传文档 → 切分 → 向量化 → 检索 → 生成答案
这个阶段的核心目标是验证可行性，回答的问题是："这个方向能不能做？"
但 Demo 的局限性也很明显：
- 只在本地测试过，数据量小、场景单一
- 没有考虑并发、延迟、成本
- 没有监控、没有评估、没有兜底
- 代码是"脚本式"的，不是"工程化"的
很多团队的问题在于：把 Demo 当成了 MVP，直接推上线。
第二阶段：发现生产问题
上线第一周，问题会集中爆发。根据真实项目经验，最常见的问题有三类：
问题 1：检索质量不稳定
现象： 用户反馈"有时候答非所问"
原因分析：
- 实验环境用的是精心挑选的测试文档，线上文档质量参差不齐
- 没有评估机制，不知道哪些场景效果好、哪些差
- Chunk 策略、Embedding 模型、检索参数都是"拍脑袋"选的
真实案例：
某团队上线后检索召回率从实验环境的 85% 掉到 52%，后来发现是专业术语的向量化效果很差，但实验环境没有覆盖这些术语。
问题 2：Token 消耗失控
现象： 账单金额超出预期 3 倍
原因分析：
- Agent 多轮调用没有预算控制
- 没有缓存，相同问题重复消耗 Token
- Prompt 过于冗长，塞了大量无关上下文
真实案例：
某客服系统上线首月 Token 消耗 12 万，预算只有 4 万。排查发现是 Agent 在单个会话中平均调用 8 次模型，而实际 2-3 次就够了。
问题 3：出了问题不知道哪里错了
现象： 用户反馈问题，但无法复现和定位
原因分析：
- 没有链路追踪，只有简单日志
- 不知道是检索问题、Prompt 问题、还是模型问题
- 没有用户反馈收集机制
真实案例：
用户反馈"回答质量差"，但团队花了 3 天才定位到是某个特定文档的 chunk 切分有问题，导致检索召回了错误内容。
第三阶段：工程化改进
发现问题后，需要系统性地解决。以下是经过验证的改进框架：
1. 加可观测性
目标： 每一次请求都能追溯完整链路
实践：
# 记录以下信息
- 用户原始 query
- Query 改写后的版本（如有）
- 召回的文档列表（含相似度分数）
- Prompt 拼装后的完整内容
- 模型输出
- 延迟（P50/P95/P99）
- Token 消耗（输入/输出）
工具选型：
- 链路追踪：LangSmith、Arize Phoenix、自研日志系统
- 监控告警：Prometheus + Grafana，或云服务商自带监控
效果： 出问题后能在 5 分钟内定位到具体环节，而不是花几天猜谜。
2. 建评估集
目标： 量化评估效果，而不是凭感觉
实践：
1. 从用户问题里抽取 50-100 个典型场景
2. 为每个问题标注"标准答案"或"评分标准"
3. 每周回归测试，改 Prompt 后对比效果
4. 建立评估指标：准确率、召回率、用户满意度
评估集示例：
场景 1：产品功能咨询
问题："你们支持 API 调用吗？"
标准答案：应包含"支持"、API 文档链接、调用示例
评分：0-5 分
场景 2：技术问题排查
问题："上传文件失败，报错 500"
标准答案：应包含排查步骤、常见原因、联系方式
评分：0-5 分
效果： 每次改 Prompt 不再是"赌一把"，而是有数据支撑的决策。
3. 成本控制
目标： 在效果可控的前提下，降低 Token 消耗
实践：
1. 加缓存层
- 语义缓存：相似问题直接返回缓存结果
- 命中率通常可达 30-50%
2. 模型分级
- 简单问题走小模型（如 qwen-7b、gpt-3.5-turbo）
- 复杂问题走大模型（如 gpt-4、claude-3）
- 路由策略：基于问题分类或意图识别
3. Token 预算
- 每次请求上限 4000 tokens
- Prompt 精简：只保留最相关的上下文
- 输出约束：限制最大输出长度
效果： 某项目通过缓存 + 模型分级，Token 消耗降低 62%，效果基本持平。
4. 安全加固
目标： 防止滥用、泄露、注入攻击
实践：
1. 输入过滤
- 检测 Prompt 注入尝试（如"忽略之前的指令"）
- 敏感词过滤
- 问题分类：判断是否属于系统支持的范围
2. 输出审查
- 敏感词过滤
- 来源引用检查：确保回答有依据
- 一致性检查：与已知事实不矛盾
3. 权限控制
- 不同用户访问不同知识库
- 敏感文档需要额外授权
第四阶段：持续迭代
工程化不是一次性的，而是持续的过程。
关键实践：
1. 用户反馈闭环
- 点踩的问题自动进入复盘队列
- 每周回顾 Top 10 问题，找出系统性原因
2. 评估指标趋势
- 每月回顾准确率、召回率、满意度趋势
- 找出退化场景，针对性优化
3. Prompt 版本化管理
- 像代码一样管理 Prompt 的变更
- 每次变更有记录、有对比、有回滚方案
面试中怎么讲 AI 工程化
如果你被问到"你对 AI 工程化怎么理解"，建议按这个框架组织：
1. 先说核心挑战
"AI 系统的输出有不确定性，需要不同于传统软件的质量保障体系。"
2. 再讲关键维度（挑 2-3 个展开）
"我理解 AI 工程化至少包括可观测性、评估体系、成本控制、安全防护、持续迭代这五个维度。"
3. 结合项目经验
"比如我做 RAG 系统时，上线第一周就发现检索质量不稳定。后来我们建了一个 50 题的评估集，每周回归测试，才发现是某些专业术语的召回率特别低。"
4. 最后讲思考
"这件事让我理解到：AI 工程化不是'写更好的代码'，而是建立一套可观测、可评估、可迭代的系统。"
这样讲，比罗列技术栈有说服力得多。
一个实用的排查框架
RAG 系统上线后效果不如预期，按这个优先级排查：
1. 检索层问题（约 50%）
→ 检查 embedding 模型、chunk 策略、query 改写
2. Prompt 层问题（约 25%）
→ 优化 system prompt、增加约束、精简上下文
3. 模型层问题（约 15%）
→ 升级模型、领域微调、调整温度参数
4. 数据层问题（约 10%）
→ 清洗数据、补充文档、建立增量更新
结语
AI 工程化不是高深的理论，而是一系列务实的实践：
- 让系统可观测，出问题能快速定位
- 让效果可评估，改 Prompt 有数据支撑
- 让成本可控，不会上线就爆预算
- 让系统安全，防止滥用和泄露
- 让迭代可持续，越用越好
Demo 能跑只是起点，生产可用才是目标。
📂 本文整理自开源项目 AgentInterview，持续更新 AI Agent 面试知识库，覆盖开发技能、面试题库、项目建议。欢迎 Star ⭐
🔍 关注公众号「开源情报局」获取更多优质开源项目推荐。
