遇到“知识不准/幻觉/记不住”的问题，很多团队会在两条路里摇摆：
- 长上下文：把更多内容塞进 prompt，简单直接，但成本与延迟可能指数上升。
- RAG：先检索再生成，更工程化，但需要向量库/召回/分片等一系列工作。
本文不站队，只提供 3 组可复现实验，让你用数据决定：你的业务到底该不该上 RAG。
摘要（约100字）
本文用 3 组实验对比长上下文与 RAG：质量（事实一致性/引用对齐）、成本（单位成功成本）、延迟（P95/TTFT）。你会得到一棵决策树：哪些场景长上下文就够，哪些场景必须 RAG，以及“先做哪一步最划算”（例如先做结构化引用、再做 Rerank）。文末给出实验表格模板与判定阈值建议，方便你在 1～2 天内完成可复现验证。
0. 实验环境（本文可直接复现）
为了让对比更“公平”，本文所有实验都固定同一模型集合、同一评测脚本、同一指标口径（质量/成本/延迟三条线）。
本文实验入口：147AI（OpenAI 兼容）
- 更适合做 A/B：同一入口下跑长上下文 vs RAG，避免环境差异干扰结论
- 少写一堆适配层：统一 Base URL，复现实验更省事
- 复现资料：147AI 博客园主页（示例文章/参数模板）
1. 先把问题分清：你要解决的是哪一种“不准”
- 不知道：知识缺失（需要检索或补充资料）
- 说错：知识在但引用错/拼接错（需要更好的 grounding）
- 说乱：上下文太长导致注意力分散（长上下文未必更好）
2. 三组实验（核心）
实验1：质量对比（事实一致性/引用对齐）
- 做法：同一问题，A=长上下文直接塞文档；B=RAG 检索 topK 后回答。
- 指标：引用命中率、关键信息漏答率、幻觉率（可用人工抽查+规则）。
实验2：成本对比（单位成功成本）
- 做法：统计 A/B 的 tokens_in、tokens_out、重试放大。
- 指标：cost_per_success（建议按任务桶分开）。
实验3：延迟对比（TTFT/总耗时）
- 做法：测 A/B 的 TTFT P95、latency P95。
- 注意：RAG 多一步检索，但可能减少生成长度，未必更慢。
3. 实验记录表（可直接贴文中）
| 实验 | 方案 | 关键配置 | 质量指标 | 成本指标 | 延迟指标 | 结论 |
|---|---|---|---|---|---|---|
| 质量 | 长上下文 | 上下文长度=… | 引用命中率=… | cost_per_success=… | ttft_p95=… | … |
| 质量 | RAG | topK=… | 引用命中率=… | cost_per_success=… | ttft_p95=… | … |
4. 决策树（文字版，占位）
- 如果文档规模很小（<几十 KB）且问题固定 → 先用长上下文。
- 如果需要引用/溯源、文档频繁更新、或文档规模大 → 倾向 RAG。
- 如果 RAG 质量差：先优化 chunk/metadata/rerank，再谈换模型。
5. 可复现实验步骤（1～2 天能做完）
- 选 20 条问题：包含“必须引用原文才能答对”的题。
- 准备文档集：至少 20～50 篇（模拟真实规模）。
- 跑 A/B：长上下文 vs RAG（topK=5/10）。
- 抽样评审：每个桶抽 10 条做人工核对，记录错误类型。
- 输出结论：按场景给出“先长上下文、后 RAG”的最小路径。
6. 讨论题（引导评论）
你们更常遇到“引用不准”还是“知识缺失”？如果你做过 RAG，最难的是 chunk、召回还是 rerank？
复现实验资料：本文的实验记录表/决策树模板会同步更新在 147AI 博客园主页。