RAG 效果差？大多数问题出在检索而非生成

大多数让人失望的 RAG 聊天机器人，问题并不出在模型上，而是出在检索上。我之前写了一篇更完整的管道搭建教程（RAG Chatbot Development），本文则是关于 RAG 实际出问题的地方的观点汇总。

RAG 管道有六个步骤，但只有两个受到关注

Ingest、chunk、embed、store、retrieve、generate。近乎所有人都在最后一个步骤上投入精力——调整 prompt、换模型——以及在 store 步骤选择向量数据库。但答案的质量实际上在 chunk 和 retrieve 阶段就已经决定了，在模型运行之前。如果这两步做错了，再多的 prompt 工程也救不了你。

Chunking 是那个悄无声息却决定天花板的决策

糟糕的分块会给你正确的文档却搭配错误的段落，或者一个根本不包含答案的段落。按结构或意义而非盲目按字符数拆分，保持一定的重叠以防止答案被拦腰截断，并保留标题以便每个分块仍能感知自己所属的章节。这个不起眼的步骤为下游所有环节设定了性能上限。

根据数据存放位置而非基准测试来选择向量数据库

Qdrant、Pinecone 和 pgvector 做相似性搜索都没问题。真正的问题是运维层面的。当私有数据必须留在自有基础设施内时选择自托管（Qdrant 或 pgvector），当只是不想自己运维时就选择托管方案。相似性搜索已经商品化了；数据驻留和运维负担才是真正的差异化因素。

RAG 能减少幻觉，但无法根除

检索到的上下文让模型更有依据，但如果你放任它，模型仍会填补空白。要求提供引用、指示模型在检索上下文薄弱时说不知道，并展示来源以便人工验证。没有可追溯来源的自信回答正是用户记住的失败模式。

生产环境补上了 demos 总是一跳过的两个东西

每用户权限控制（确保检索永远不会返回当前用户无权查看的文档），以及定时重新索引（防止答案随源材料变化而悄悄过时）。这两点是一个流畅的原型变成真正的产品时最容易失败的地方。

把检索做对了，平庸的模型也能给出有据可查的好答案。做错了，市场上最好的模型也会自信地编造内容。完整的管道拆解，从 ingest 到 generate，见：RAG Chatbot Development: How It Works.

本文由 AI（Claude）辅助起草，经我审阅和编辑。