RAG 项目为什么常常“看起来能跑，实际不好用”
很多团队做 RAG 的起手式是：导入文档、接上向量库、开一个问答页面。Demo 阶段往往很顺，但一到真实用户，问题就会冒出来：答非所问、引用不准、答案风格飘忽、同问不同答。
问题通常不在“模型不够聪明”，而在于系统结构没分层。你把所有复杂度压在一次检索和一次生成里，稳定性当然会差。
先把 RAG 拆成 4 层
文档层：保证输入干净
先解决版本、去重、分段和标签。文档脏，后面所有优化都会被抵消。
检索层：保证召回相关
设定检索窗口、召回数量、重排策略。检索层要解决的是“把正确材料找出来”。
回答约束层：保证输出可控
明确回答模板、引用规则、拒答条件和置信度提示。它决定了“模型怎么用材料回答”。
反馈层：保证系统能进化
记录用户追问、点踩、人工改写，定期回流到文档和检索策略。没有反馈层，RAG 只会原地打转。
RAG 三个高频误区
- 误区一：把“召回到内容”误当成“答对问题”。
- 误区二：只调模型参数，不修文档结构。
- 误区三：没有人工抽检机制，质量全靠感觉。
更稳的落地顺序
第一周先做文档清洗和标签，第二周做检索评测，第三周再做回答模板和引用规范，第四周上线反馈闭环。这样速度不慢，且可持续优化。
RAG 不是一个插件，而是一条知识生产线。生产线不分层，质量就不会稳定。