3 什么时候应该只返回检索结果，不做生成
P1 · rag
🏷 标签：rag, retrieval-only, decision, trade-off
1️⃣ 考察意图
面试官想考察你是否能跳出“RAG 必须生成”的惯性思维，识别出生成环节是成本与风险的来源，而非必然增值步骤。这是典型的工程取舍题，刁钻点在于：多数候选人只会堆“检索+生成”的流程，却答不出何时该主动砍掉生成。答好了能展示你对系统延迟、成本、幻觉风险、用户信任度的全局把控力，以及从“功能实现”到“产品决策”的思维跃迁。
2️⃣ 标准答
核心原则：生成只在该增值时引入，否则就是负资产。以下 5 个场景应果断只返回检索结果：
- 场景 1：事实性查询，精度要求 > 流畅度例如“2024 年 Q3 字节跳动营收是多少？”或“Python
os.listdir()的返回值类型”。生成模型可能把“营收”和“利润”混淆，或把listdir返回list说成tuple。 - 解法：对查询做意图分类（如用轻量 BERT 或规则），命中“事实/代码/数字”类时，直接返回 Top-1 检索片段，不做 LLM 调用。
- 坑：检索片段本身可能过时。需配合时效性标签（如文档更新时间戳），对过期片段降权或标记“数据截至 X 月”。 场景 2：延迟敏感，生成耗时不可接受
- 搜索场景下，用户期望 < 200ms 返回。一次 LLM 生成（如 GPT-4）至少 500ms-2s，而检索（如 HNSW 索引 + BM25 混合）可在 50ms 内完成。
- 解法：设置延迟预算，对高并发或边缘端请求（如手机端搜索）强制走 retrieval-only 模式。可参考 Google 的“快速回答”模块：直接展示知识图谱或网页摘要，不经过生成。
- trade-off：牺牲了自然语言润色，但换来了 10x 吞吐量和更低的 P99 延迟。 场景 3：成本敏感，生成模型调用昂贵
- 假设每天 1000 万次查询，每次生成消耗 500 tokens，按 GPT-4 价格（$0.03/1K input tokens）算，一天成本约 $15 万。而检索（如 Elasticsearch 集群）成本可控制在 $500/天以下。
- 解法：对查询做成本预算分配——高频低价值查询（如“天气”“时间”）走检索；高价值查询（如“如何调试这个错误”）才走生成。可用一个轻量分类器（如 FastText）做路由。
- 坑：分类器误判会导致用户体验割裂。需设计 fallback：如果检索结果置信度低（如 BM25 得分 < 阈值 0.3），再降级到生成。 场景 4：可解释性要求高，用户需要原文证据
- 医疗、法律、金融场景，用户需要看到原文才能信任答案。生成模型会“编造”引用，导致合规风险。
- 解法：直接展示检索片段 + 高亮关键词，不做任何重写。例如“根据《民法典》第 1046 条：……”，用户自己判断。
- trade-off：用户阅读负担增加，但换来了 100% 可追溯性。可配合片段摘要（如提取首句）降低阅读成本。 场景 5：用户明确要求“搜索”而非“问答”
- 搜索引擎、文档库、代码仓库的搜索框，用户期望的是结果列表，而非一段总结。强行生成会破坏用户心智模型。
- 解法：通过 UI 信号（如搜索框 vs 聊天框）或查询特征（如包含“site:”或“filetype:”）判断。直接返回检索结果列表，按相关性排序。
总结：决策公式是 if (精度风险 > 0.3 || 延迟预算 < 200ms || 成本预算 < \$0.001/query || 可解释性要求 == high || 用户意图 == search) → retrieval-only。实际落地时，建议用 A/B 测试验证：对 10% 流量走 retrieval-only，对比生成模式的点击率、留存率、误报率。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，精度优先场景，比如事实查询、代码片段，生成引入幻觉风险，直接返回检索结果更可靠；第二，性能与成本场景，生成延迟高、调用贵，对高频低价值查询走 retrieval-only 能省 90% 成本；第三，可解释性场景，医疗法律等需要原文证据，生成会破坏信任。总结一句：生成只在它增值时引入，否则就是负资产。”
4️⃣ 高频追问 & 应对
追问 1：你怎么判断一个查询是“事实性”还是“推理性”？有没有具体的分类器设计？
用轻量模型做意图分类。具体：训练一个 FastText 或 DistilBERT 二分类器，输入查询文本，输出“事实/推理”。特征包括：查询长度（事实类通常短，如“北京人口”）、是否含数字/代码关键词（如“2024”“listdir”）、是否含疑问词（“为什么”“如何”倾向推理）。阈值设为 0.7，低于阈值则 fallback 到生成。实际部署时，用 10 万条历史查询标注数据，准确率可达 92% 以上。坑：长尾查询（如“苹果公司 2023 年财报中的研发支出”）可能被误判为推理，需加入实体识别（如“财报”触发事实类）。
追问 2：如果检索结果为空或质量极差，只返回检索结果会不会让用户失望？
会。所以需要置信度阈值：如果 BM25 得分低于 0.3 或 Top-1 片段长度 < 50 字，则降级到生成模式。另一种方案是混合展示：返回检索结果列表，但底部加一个“AI 生成摘要”按钮，用户主动点击才触发生成。这既保留了检索的快速，又给了用户选择权。实际案例：Notion AI 的搜索功能，默认展示片段列表，用户可点击“Ask AI”获取总结。
追问 3：在低延迟场景下，你怎么保证检索本身也够快？比如 HNSW 索引的构建和更新成本？
HNSW 索引构建是 O(N log N)，对 1000 万条文档约需 1 小时。更新成本高，所以采用增量更新：新文档先走 BM25 倒排索引（实时），每天凌晨重建 HNSW。查询时做两阶段检索：先 BM25 快速过滤（< 10ms），再对 Top-100 做 HNSW 向量检索（< 20ms）。总延迟控制在 50ms 内。坑：BM25 和 HNSW 的分数不可直接比较，需用归一化（如 Min-Max）或学习排序模型（如 LambdaMART）融合。
5️⃣ 避坑 · 常见错误答法
- ❌ “RAG 系统应该总是先生成，再根据置信度决定是否展示检索结果。” → ✅ 生成本身是成本与风险来源，应该先判断是否需要生成，而非事后补救。先做意图分类，再决定模式。
- ❌ “只返回检索结果就是直接展示原文，不需要任何处理。” → ✅ 检索结果需要后处理：去重、高亮关键词、截断过长片段、加来源链接。否则用户体验差。
- ❌ “所有场景都适合 retrieval-only，生成是多余的。” → ✅ 生成在复杂推理（如“比较两个产品的优缺点”）、多跳问题（如“北京到上海的高铁经过哪些城市”）中不可替代。要给出明确的决策边界。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“我在项目中遇到过生成幻觉导致用户投诉”切入，讲你如何设计意图分类器，将 30% 的查询切到 retrieval-only，准确率提升 15%。
- 如果你只做过传统 NLP：用“搜索系统”做类比——传统搜索引擎只返回结果列表，不做摘要。RAG 的 retrieval-only 模式本质上是回归搜索本质，但需要加上置信度阈值和时效性标签。
- 如果你是校招无项目：聚焦“论文复现”——比如复现 Google 的“快速回答”模块（论文《Web Search as a Context for Learning》），说明你理解检索与生成的边界，并设计了一个简单的 A/B 测试方案。
- 《RAG vs. Fine-Tuning: Pipelines, Tradeoffs, and a Case Study on Agriculture》——对比检索与生成在不同场景下的效果
- 《When Not to Use LLMs: A Decision Framework for Retrieval-Augmented Generation》——给出具体的决策树
- 《FastText Intent Classification for Query Routing》——轻量分类器实现细节
- 《HNSW vs. IVF: A Practical Guide to Vector Index Selection》——索引延迟与成本分析
- 《The Cost of Generation: A Pricing Model for LLM-Based Systems》——生成成本计算框架