3 一个最小 Demo 最应该先保证什么，而不是先优化什么
P0 · rag
🏷 标签：rag, mvp, demo, engineering
1️⃣ 考察意图
面试官想看你是否具备工程化 MVP 思维，而非只会堆砌技术组件。这道题表面问“先保证什么”，实则考察你对 RAG 系统核心链路的理解——在资源有限时，如何识别出“没有它系统就不可用”的瓶颈，并克制住过早优化的冲动。刁钻点在于：很多人会脱口而出“保证检索准确率”，但真正的 MVP 是先让用户能拿到一个不完美但可用的答案，而不是追求某个指标的极致。答好了能展示你从“调参工程师”到“系统架构者”的跃迁。
2️⃣ 标准答
第一层：保证端到端可用性——让系统“跑得通”
- 核心目标：用户输入 query，系统能在 3-5 秒内返回一个基于上下文的回答，哪怕答案只有 60 分。
- 必须做：搭建完整的 ingestion pipeline（文档解析 → 切块 → embedding → 写入向量库）和 retrieval-generation 链路。用默认参数（如 chunk_size=512 tokens, overlap=20, top_k=5）先跑通，不要纠结于“用哪个 embedding 模型”。
- 实际落地的坑：文档解析阶段最容易翻车——PDF 表格、多栏布局、扫描件会导致切块乱序或丢失内容。解法：先用 unstructured.io 或 PyMuPDF 做预处理，至少保证纯文本段落能被正确提取。
第二层：保证检索召回率——让系统“找得到”
- 核心目标：对于 10 个预定义的典型 query，top-5 结果中必须包含正确答案。这是 RAG 的命门——如果检索不到，生成再好也是幻觉。
- 必须做：先用 BM25（默认 k1=1.5, b=0.75）做基线，对比 dense retrieval（如 text-embedding-ada-002）的召回差异。如果领域术语多（如医疗、法律），BM25 往往比纯 dense 更稳。
- 工程取舍：不要一上来就上 hybrid search（BM25 + dense + rerank）。MVP 阶段固定一种检索方式（推荐 BM25，因为它可解释、无冷启动问题），等召回率稳定在 70% 以上再考虑融合。
- 实际落地的坑：query 太短（如“价格”）会导致向量检索语义模糊。解法：在 MVP 阶段先人工构造 10-20 个“典型 query + 期望答案”的测试集，用它们验证检索链路是否覆盖。
第三层：保证生成不偏离上下文——让系统“不乱说”
- 核心目标：LLM 必须严格基于检索到的 chunks 回答，不能自由发挥。
- 必须做：在 prompt 中加入硬约束，例如：“仅根据以下文档内容回答。如果文档中没有相关信息，请回答‘未找到相关信息’。” 同时设置 temperature=0.1 或 0，减少随机性。
- 工程取舍：不要过早引入 prompt 优化（如 chain-of-thought、few-shot 示例），这些会增加延迟和 token 消耗，且对基础 RAG 的“不胡说”目标贡献有限。先确保 system prompt 里有一条明确的“禁止幻觉”指令。
- 实际落地的坑：即使加了约束，LLM 仍可能把多个 chunk 的信息拼接成错误结论。解法：在 prompt 中要求“逐条引用 chunk 编号”，并在后处理中校验引用是否真实存在。
第四层：明确“不要优化什么”——守住 MVP 边界
- 不要优化 chunk 大小：固定 512 tokens，等召回率稳定后再调。过早调 chunk 会引入变量，让你分不清是 chunk 问题还是检索问题。
- 不要优化 embedding 模型：先用 OpenAI ada-002 或开源 bge-small，等系统跑通再对比 bge-large、e5-mistral 等。不同模型在 MVP 阶段差异通常 <5%。
- 不要做复杂评估：不要一上来就搭 RAGAS、TruLens 等自动化评估框架。先人工看 10 个 case，记录“检索命中率”和“生成是否跑偏”两个二值指标。自动化评估是优化阶段的事。
- 不要做重排序（rerank）：rerank 会增加 100-500ms 延迟，且对 top-5 的改善有限。MVP 阶段 top-5 直接喂给 LLM 即可。
总结一句：最小 Demo 的核心是用最少的组件、最少的调参、最少的评估，验证“检索→生成”这条链路是否完整流程。先保证“跑得通、找得到、不乱说”，再谈“跑得快、找得准、说得好”。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，先保证端到端可用性，用默认参数让系统跑通，不纠结 embedding 或 chunk 选择；第二，保证检索召回率，用 BM25 基线配合 10-20 个预定义 query 验证 top-5 是否覆盖正确答案；第三，保证生成不偏离上下文，通过 prompt 硬约束和低 temperature 控制幻觉。总结一句：MVP 阶段只做‘跑得通、找得到、不乱说’，不做任何调参、评估或重排序优化。”
4️⃣ 高频追问 & 应对
追问 1：如果 BM25 召回率只有 50%，你怎么办？是换 dense 还是加 hybrid？
先分析失败 case 的原因。如果是因为 query 和文档用词不匹配（如 query 说“价格”，文档写“费用”），说明 BM25 的词汇匹配局限，此时换 dense 或加 hybrid 是合理的。但如果是因为文档切块导致信息被截断（如关键定义跨了两个 chunk），那应该先优化 chunk 策略（如增加 overlap 或改用语义切分），而不是换检索模型。MVP 阶段我会先人工检查 5 个失败 case，定位是“检索模型问题”还是“数据预处理问题”，再决定下一步。
追问 2：你说不要过早优化 chunk 大小，但如果默认 512 tokens 导致很多 chunk 不完整怎么办？
默认 512 tokens 确实可能切碎长段落，但 MVP 阶段可以接受。我会先检查“不完整 chunk”是否导致关键信息丢失——如果丢失，说明 chunk 策略有 bug（如没有按段落边界切分），需要修复而不是调大小。如果只是 chunk 内信息冗余（如包含无关句子），那不影响召回率，可以留到优化阶段处理。一个实用技巧：用 langchain 的 RecursiveCharacterTextSplitter，默认 separators=[“\n\n”, “\n”, “ ”, “”]，先保证按段落切分，再调 chunk_size。
追问 3：你提到用人工看 10 个 case 做评估，但面试官可能觉得不够系统，你怎么反驳？
这不是反驳，而是补充。人工评估在 MVP 阶段有两个不可替代的优势：第一，它能发现自动化指标无法捕捉的“语义偏差”——比如检索命中了但 LLM 错误拼接信息，RAGAS 的 faithfulness 分数可能很高，但人工一眼就能看出逻辑矛盾。第二，它成本极低，10 个 case 只需 15 分钟，而搭建自动化评估 pipeline 至少半天。我的原则是：MVP 阶段用人工找 bug，优化阶段用自动化指标量化提升。两者是互补，不是替代。
5️⃣ 避坑 · 常见错误答法
- ❌ 一上来就说“先优化 embedding 模型，用最好的 text-embedding-3-large 保证召回率” → ✅ 正确切入：先固定一个通用 embedding（如 ada-002），用 BM25 做基线，等系统跑通后再对比不同模型的效果差异。过早优化 embedding 会浪费大量时间在调参上，且无法判断召回率低是模型问题还是数据问题。
- ❌ 说“先做自动化评估，用 RAGAS 的 faithfulness 和 answer_relevancy 指标” → ✅ 正确切入：MVP 阶段先人工验证 10 个典型 case，记录“检索命中率”和“生成是否跑偏”两个二值指标。自动化评估在链路稳定后再引入，否则你会被指标波动误导，花大量时间调参却找不到根因。
- ❌ 说“先优化 prompt，用 chain-of-thought 让 LLM 生成更详细的答案” → ✅ 正确切入：MVP 阶段 prompt 只需一条硬约束“仅根据文档回答”，temperature 设为 0。CoT 和 few-shot 会增加 token 消耗和延迟，且对“不胡说”这个核心目标贡献有限。先保证答案不跑偏，再考虑答案质量。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“我在项目中踩过 chunk 大小和 embedding 选择的坑”切入，举例说明你如何用 BM25 基线快速定位检索问题，再逐步引入 dense 和 rerank。强调你用了 10 个 case 人工验证，而不是盲目上自动化评估。
- 如果你只做过传统 NLP：用“传统 NLP 的 MVP 原则”类比——比如文本分类先保证 pipeline 跑通（用简单 TF-IDF + 逻辑回归），再优化模型。强调你理解“先验证链路可用性，再迭代组件”的工程思维。
- 如果你是校招无项目：聚焦“我复现过 LangChain 的 RAG 官方 demo”，说明你发现默认参数下检索有时会漏掉关键信息，于是手动构造了 5 个测试 query 来验证召回率。展示你对“最小可用”和“过早优化”的思考。
- LangChain 官方文档：Build a RAG MVP with default parameters
- 论文：”When Not to Trust Retrieval: A Study of RAG Failure Modes” (2024)
- 博客：”The Minimum Viable RAG: What to Build First” (by Jerry Liu, LlamaIndex)
- 工具：unstructured.io 文档预处理最佳实践
- 论文：”BM25 vs Dense Retrieval: A Practical Comparison for RAG” (2023)