RAG 流水线设计笔记

RAG 在 2023 年越来越热，但真正落地后就会发现，它从来不是“把文档丢进向量库”这么简单。一个像样的 RAG 系统，本质上是一条检索与生成协同的流水线。

一条基础流水线通常长什么样

从工程角度看，至少会有这些环节：

1. 文档清洗
2. 文档切分
3. 向量索引
4. 查询检索
5. 结果重排
6. 上下文拼装
7. 模型回答

这里任何一环做得不稳，最后效果都会受影响。

为什么很多 RAG 项目看起来“有了”，但不好用

最常见的原因是只把注意力放在模型输出上，而忽略了前面检索链路的质量。很多时候，问题不在模型不会答，而在给它的上下文本来就不对。

最值得优先做的不是换模型

我反而会优先看这些事：

• chunk 切得是否合理
• metadata 是否完整
• 检索结果是否需要重排
• 提示词里引用上下文的方式是否清楚

这些基础环节往往比换一个更大的模型更有收益。

流水线思维为什么比单点优化更重要

因为 RAG 不是某一个参数调对了就会稳定的系统。哪怕模型很强，只要文档切分粗糙、检索召回不准、上下文拼装太乱，最后回答效果都会被前面环节拖垮。真正把它当成流水线来看，你就会更自然地去分层观察问题到底出在哪一段，而不是把所有锅都甩给模型本身。

小结

RAG 到了 2023 年已经不是概念题，而是工程题。把它理解成一条流水线，而不是单点能力，会更容易做出真正可维护的系统。