RAG 失败实验
Production Lab 预览上下文工程20 分钟
从一个故意配置得很差的检索系统开始。一次只改变一个工程决策，看看为什么“检索确实返回了文档”仍然可能得到很差的答案。
RAG 的可靠性不是“尽量多找资料”，而是在足够的相关证据和尽量少的无关上下文之间做权衡。
存在缺陷的生产场景确定性教学模拟
初始配置会把过多的大 Chunk 塞进固定的 8,000 Token 上下文预算。你的目标是提高答案质量，而不是把“更多上下文”当作默认正确答案。
固定上下文预算：8,000 Token。这样检索压力会直接暴露出来，而不是被一个越来越大的 Context Window 隐藏掉。
系统现在看到了什么
Recall
—
—
Precision
—
—
Context
—
—
质量分数
—
—
延迟
—
—
成本指数
—
—
当前诊断: —
失败基线大 Chunk · Top-K 12 · 仅 Vector
→实验启动时已经保存为 Engine Checkpoint。
当前配置
等待参数变化……
关键结论
Recall 不是唯一目标找回更多相关证据仍可能让答案变差，因为无关上下文可能增长得更快。
Top-K 有真实代价K 增大通常提高覆盖率，同时增加 Context 占用、延迟和检索噪声。
Chunking 改变的是搜索表面Chunk 太大容易携带无关信息，太小又可能把必须一起理解的事实拆散。
Reranker 是精度工具，不是免费午餐它可以在更宽的第一阶段候选集上提高排序精度，但也增加延迟和计算成本。
为什么 Retrieval“正常返回结果”，RAG 仍然会失败？
检索 API 成功返回文档，只能证明 Pipeline 没报错。真正决定答案质量的是：模型有没有拿到正确证据、覆盖是否足够、无关内容是否过多，以及这些内容能否放进合理的上下文预算。
Chunk Size 是信息表示决策
大 Chunk 能保留更多上下文关系，也更容易把无关文本一起带进来；小 Chunk 更容易精准匹配，却可能拆散需要联合判断的事实。没有对所有数据都正确的 Chunk Size。
Top-K 同时改变 Recall 和 Noise
提高 Top-K 往往增加相关证据出现的机会，也同步增加 Token 数和干扰项。只优化 Recall，可能让 Generation 阶段反而更差。
Hybrid Retrieval 与 Reranking 解决不同问题
Hybrid Search 组合不同的一阶段检索信号；Reranker 则对候选集做第二阶段排序。它们可以一起用，但都会增加系统复杂度与延迟。
这里哪些东西是模拟的？
所有分数都是稳定的教学模拟指标，不是 Embedding 模型、向量数据库、Reranker 或 LLM 的真实 Benchmark。目标是让因果关系可以重复观察。
常见问题
是不是应该永远把 Recall 拉到最高？
不是。生产答案质量同时依赖证据覆盖和 Context 精度。
把 Context Window 换得更大能解决坏检索吗？
不一定。更多 Token 容量不会自动把无关证据变成有用证据。
Hybrid Search 一定优于 Vector Search 吗？
不是。价值取决于数据、查询类型和评测集。
AhaFrame 教学模拟说明 · 内容复核 2026-08-13. 指标是教学模拟值；生产决策必须回到真实数据、真实查询和代表性 Evaluation。