1 一个 Demo 版和生产版最大的差别是什么
P1 · rag
🏷 标签：rag, production, scalability, reliability
1️⃣ 考察意图
面试官想看的不是“Demo 简单、生产复杂”这种废话，而是你能否从系统设计角度拆解差异，并给出具体工程取舍。这是典型的系统设计 + 工程取舍题，刁钻点在于：Demo 往往跑通即可，生产版要扛住数据规模、延迟、可靠性、成本四重压力。答好了能展示你对 RAG 整条链路（检索、生成、监控）的落地经验，以及从“能用”到“好用”的工程思维。
2️⃣ 标准答
Demo 版和生产版的核心差异，我归纳为 4 个维度：数据管道、检索系统、生成模块、运维体系。
1. 数据管道：从静态到动态
- Demo：手动上传几份 PDF，用固定 chunk_size=500 切分，一次性写入向量库（如 Chroma）。数据源单一，无更新。
- 生产版：需支持多源异构数据（数据库、API、实时日志），用 Apache Airflow 或 Prefect 编排增量更新管道。坑：增量更新时，旧 chunk 可能失效（如文档被修改），需用版本号 + 时间戳标记，并定期清理孤儿向量。取舍：全量重建 vs 增量更新——全量重建保证一致性但成本高，增量更新快但需处理冲突，我倾向用双缓冲策略：新数据写入影子索引，切换原子操作。
2. 检索系统：从线性到分层
- Demo：单路检索，用 OpenAI embedding 直接查向量库，Top-K=5，延迟 200ms 也能接受。
- 生产版：必须多路召回 + 重排序。典型方案：BM25（稀疏检索）+ DPR/ColBERT（稠密检索）并行，结果用 Cohere Rerank 或交叉编码器重排。取舍：稠密检索对长尾 query 效果差，BM25 对同义词不敏感，两者互补。坑：向量库选型——FAISS 适合离线，Milvus/Pinecone 适合在线，但 Milvus 的 HNSW 索引在 10 亿级数据下内存爆炸，需用量化（PQ） 压缩向量到 1/4 大小，代价是召回率降 1-2%。延迟目标：P99 < 100ms，通过缓存高频 query（Redis，TTL=5min）和异步预取（用户输入时提前检索）优化。
3. 生成模块：从单轮到可控
- Demo：直接调 GPT-4，prompt 写“根据上下文回答”，无约束。
- 生产版：需幻觉控制和安全护栏。具体做法：检索增强：强制模型只引用检索到的 chunk，用引用标注（如 [1][2]）让用户可验证。
- 输入/输出过滤：用 Guardrails 或 NeMo 检测敏感词、PII，拒绝恶意 query。
- 温度控制：事实性任务用 temperature=0.1，创意任务用 0.7，避免胡编。
- 成本优化：用级联模型——简单 query 用 GPT-3.5-Turbo，复杂 query 用 GPT-4，节省 60% 成本。取舍：级联增加延迟，需用超时降级（若 GPT-4 超时 2s，回退到 GPT-3.5）。
4. 运维体系：从手动到自动化
- Demo：本地跑 Jupyter，失败重启。
- 生产版：必须监控 + 告警 + 回滚。关键指标：检索质量：MRR（Mean Reciprocal Rank）、Recall@K，低于阈值触发告警。
- 生成质量：用 GPT-4 作为 evaluator 打分（如 1-5 分），或人工标注的 golden dataset 做自动化测试。
- 系统指标：QPS、P99 延迟、错误率，用 Prometheus + Grafana 可视化。
- A/B 测试：新模型/新 chunk 策略上线前，用 10% 流量对比，统计显著性（p<0.05）才全量。
总结：Demo 是“跑通”，生产是“跑稳、跑快、跑省”。每个决策背后都是 trade-off：一致性 vs 性能、成本 vs 质量、灵活性 vs 可控性。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从数据管道、检索系统、生成模块、运维体系四个层面回答。数据层面，Demo 用静态小数据，生产版需增量更新和版本管理；检索层面，Demo 单路召回，生产版多路召回 + 重排序，并用缓存和量化控制延迟；生成层面，Demo 直接调模型，生产版加幻觉控制、安全过滤和级联降本；运维层面，Demo 无监控，生产版需 MRR、Recall 等指标和 A/B 测试。总结一句：Demo 解决‘能不能用’，生产版解决‘好不好用、稳不稳、贵不贵’。”
4️⃣ 高频追问 & 应对
追问 1：你提到增量更新，具体怎么处理文档删除或修改？
用版本号 + 时间戳策略。每个文档有唯一 ID 和 version，chunk 继承文档 version。更新时：新文档写入新 chunk（新 version），旧 chunk 标记为过期（不删除，避免影响正在进行的检索）。后台定时任务（如每小时）扫描过期 chunk，批量删除。坑：删除期间若有检索请求，需过滤掉过期 chunk（在 query 时加 version 条件）。取舍：实时删除 vs 延迟删除——实时删除保证一致性但增加写入延迟，我选延迟删除，因为 RAG 对一致性要求不高（用户容忍几秒的旧数据）。
追问 2：多路召回后，重排序的延迟怎么控制？
重排序是瓶颈，因为交叉编码器（如 Cohere Rerank）复杂度 O(n^2)。优化：1）限制重排数量：只对 Top-50 结果重排，而不是全量。2）异步并行：BM25 和稠密检索并行跑，结果合并后异步调用 rerank API。3）缓存：对高频 query 缓存 rerank 结果（TTL=10min）。4）降级：若 rerank 超时（如 200ms），直接返回检索结果（用线性加权融合，如 BM25 权重 0.3，稠密 0.7）。实测：P99 延迟从 500ms 降到 120ms，MRR 仅降 2%。
追问 3：生产版怎么评估检索质量，没有人工标注怎么办？
用间接指标：1）用户行为：点击率、停留时间、复制率——如果用户复制了回答，说明质量高。2）LLM-as-Judge：用 GPT-4 对检索结果打分（如“是否相关”），但注意 GPT-4 有偏见（偏好长文本），需校准。3）伪标注：用用户反馈（点赞/点踩）作为正负样本，训练一个轻量级分类器（如 XGBoost）做在线评估。坑：伪标注有噪声，需定期人工抽检（如每周 100 条）修正。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“生产版就是加个缓存和负载均衡” → ✅ 正确切入：缓存只是冰山一角，核心是数据管道、检索质量、生成控制、监控体系的整条链路设计，每个环节都有 trade-off。
- ❌ 说“生产版用更好的模型就行” → ✅ 正确切入：模型只是组件，生产版更关注系统稳定性（如降级、超时、重试）和成本控制（如级联模型、量化），模型质量提升 10% 可能带来 50% 成本增加。
- ❌ 说“Demo 用 Chroma，生产版用 Pinecone” → ✅ 正确切入：向量库选型只是细节，关键是要理解为什么需要多路召回、增量更新、监控指标，否则换了库也解决不了根本问题。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“我做的 XX 项目从 Demo 到生产”切入，具体讲数据管道（如增量更新）、检索优化（如多路召回）、监控（如 MRR 指标），用数字证明（如 P99 延迟降 60%）。
- 如果你只做过传统 NLP：用“传统 NLP 的模型部署经验”类比，比如“文本分类模型从 Jupyter 到 Flask 服务，和 RAG 生产化一样，都需要处理并发、监控、回滚”，然后迁移到 RAG 场景。
- 如果你是校招无项目：聚焦“论文复现”或“开源项目贡献”，比如“复现了 ColBERT 论文，并思考了生产化时如何用量化压缩索引”，展示对 trade-off 的理解。
- 《RAG 生产化最佳实践：从 Demo 到百万 QPS》（博客，LangChain 官方）
- 《Dense Passage Retrieval for Open-Domain Question Answering》（Karpukhin et al., 2020）
- 《ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction》（Khattab & Zaharia, 2020）
- 《FAISS 量化技术：Product Quantization 原理与实现》（Facebook AI 博客）
- 《A/B 测试在 RAG 系统中的应用：统计显著性计算》（Evan Miller 博客）