13.1.3 一个最小 Demo 最应该先保证什么，而不是先优化什么？

先给结论：最小 Demo 最重要的是“闭环 + 可复现”，而不是“高质量答案”。你需要先确保链路跑通，再谈效果优化。

优先保证的三件事

1. 闭环

从“文档”到“答案”的路径必须完整：

• 文档能被解析
• chunk 能被召回
• 生成能基于证据输出

只要闭环不成立，所有优化都没有意义。

2. 可复现

同一个问题，答案必须稳定。
最小 Demo 的核心是“可重复定位问题”，而不是“偶尔生成正确答案”。

3. 可观察

你必须能看到每一步的产物：

• 切块结果
• 召回结果
• 使用的证据

否则你无法判断问题发生在检索还是生成。

最小 Demo 不要优先做的事

1. 复杂检索策略

多路召回、路由检索、重排序等优化在最小 Demo 阶段会掩盖问题。

2. 大规模数据

数据规模大了，问题定位变慢。先用小规模高质量数据跑通。

3. 复杂评估体系

评估当然重要，但最小 Demo 阶段只需要 5-10 个问题集即可。

一个务实的优先级顺序

1. 闭环：跑通全链路
2. 可观察：看到每步输出
3. 可复现：稳定复现结果
4. 再优化：提升召回、生成质量

常见误区

误区一：把 Demo 当成产品

Demo 的目的不是“上线”，而是“验证链路可行性”。

误区二：一开始就追求最强模型

最小 Demo 更需要“可控性”，而不是“效果极限”。

误区三：把评估做成重工程

你需要的是快速反馈，而不是复杂系统。

自检清单

• 是否能稳定跑通“文档 -> 召回 -> 生成”？
• 是否能快速定位问题出在哪一步？
• 是否有最小问题集验证效果？

一句话总结

最小 Demo 的第一优先级是闭环与可复现，优化应该排在后面。