很多人搭RAG系统，上来就写代码，接个向量数据库，完事。跑起来一看，检索召回率六成不到，用户问的问题答非所问。更扎心的是API账单比预期高了两三倍。
问题不在代码写得差，在架构选错了。
RAG不是一种架构，是三类架构。选错模式，要么效果差到没法用，要么成本高到扛不住。这篇文章把三种模式的原理、成本和适用场景讲清楚，帮你少踩坑。
三种RAG架构，差别在哪
Naive RAG：索引-检索-生成
最基础的模式。文档切片、做embedding、存向量数据库，用户提问时检索相关chunk，拼到prompt里让LLM生成答案。
听起来没毛病对吧？实际上这个模式有三个硬伤：
第一，用户提问的方式和文档的表述往往不一致。用户问”怎么退款”，文档写的是”订单取消与资金返还流程”。语义相似度不一定能匹配上。
第二，检索结果排序粗糙。top-5里可能2条相关3条不相关，LLM拿到一堆噪音，回答质量直接拉胯。
第三，没有查询优化。用户提问过长、过短、有歧义，直接拿去检索，效果很差。
Naive RAG适合验证阶段，快速跑通流程。但如果你想做个能用的产品，这个模式撑不住。
Advanced RAG：查询改写+重排序
在Naive基础上加了两层：查询处理和结果重排。
查询改写做几件事：把用户的问题扩展成更完整的表述，或者分解成多个子问题分别检索。比如用户问”这个产品安全吗”，改写成”产品数据加密方式”、”产品合规认证”、”用户数据存储方案”三个子问题，分别检索再合并。
重排序用cross-encoder模型对初检结果做精细排序。bi-encoder（embedding模型）速度快但精度一般，cross-encoder精度高但速度慢。先用bi-encoder粗筛top-20，再用cross-encoder精排取top-5，效果显著提升。
据Cohere的公开评测数据，使用rerank模型后，搜索准确率平均提升15%到30%。这个数据在实际RAG系统中基本能验证。
代价是什么？成本上去了。每次查询多一次API调用（rerank模型），延迟也增加200到500毫秒。
Modular RAG：多路召回+路由+缓存
最复杂的模式，也是效果最好的。
核心思路是不只靠向量检索一条路。同时用关键词检索（BM25）、向量检索、知识图谱查询等多种方式召回候选，然后融合排序。
再加上查询路由：简单问题走轻量检索，复杂问题走全量多路召回。回答完的结果做缓存，相似问题直接命中缓存不走LLM。
Modular RAG的效果最好，但工程复杂度也最高。维护多套检索系统、设计路由策略、管理缓存失效，这些都不是小活。
三种模式成本拆解
以一个中等规模RAG系统为例：10万文档chunk，日均5000次查询，使用OpenAI text-embedding-3-small做embedding，GPT-4o-mini做生成。
embedding成本：10万chunk × $0.02/1M tokens ≈ $2（一次性，约2000万tokens）
查询成本拆开看：
Naive RAG每次查询：检索（免费/自建）+ 生成（约2000 tokens输入 + 500 tokens输出）。GPT-4o-mini定价输入$0.15/1M、输出$0.6/1M。单次查询约$0.0006，日均5000次约$3/天。
Advanced RAG每次查询多一次rerank。用Cohere Rerank 3，每1000次$2，5000次/天约$10/天。加上生成成本，总计约$13/天。
Modular RAG成本更难精确算，因为多路检索和缓存命中率因场景而异。粗估：多路检索增加30%到50%的检索成本，但缓存能节省20%到40%的生成调用。整体可能比Advanced RAG高20%左右，也可能持平，看缓存效率。
月成本对比：Naive约$90，Advanced约$390，Modular约$400到$500。
怎么选
别一上来就搞Modular。建议的路径是这样：
先用Naive RAG跑通流程，验证你的文档质量和用户问题分布。这一步最重要的事情是评估召回率。如果你用Naive RAG召回率已经超过70%，说明你的文档质量不错，问题表述和文档匹配度还行。
如果召回率低于60%，先别急着加架构，检查文档。切片太大、太小都会影响效果。常见做法是按语义段落切，每块256到512 tokens，重叠50 tokens。这个基础工作比换架构管用。
召回率到了70%以上但效果还不够，加rerank。这是性价比最高的一步。$10/天换来15%到30%的准确率提升，很值。
如果用户问题类型复杂，简单问题和复杂问题混在一起，再加查询路由。先做规则路由（按问题长度或关键词分类），别一上来就搞LLM路由，贵且不稳定。
缓存最后加。先跑一段时间收集查询日志，分析高频问题的比例，再决定缓存策略。如果top-100高频问题覆盖了30%以上的查询，缓存就有明显价值。
一个判断框架
做RAG系统之前，先回答三个问题：
你的文档规模多大？1万篇以下Naive够用，10万篇以上必须考虑Advanced。100万篇以上Modular是刚需。
你的用户问题复杂度如何？简单事实查询占比高，Naive+rerank就行。多步推理、对比分析类问题多，必须考虑查询分解和路由。
你的预算能撑多少？月$100以内只能Naive，$500以上可以考虑Advanced，$2000以上Modular才划算。
架构选择不是越高级越好，是越合适越好。见过太多人一上来就要搞Modular RAG，光架构设计就花了两周，最后文档质量没过关，多路召回检索出来的全是噪音。
先把基础做扎实，再逐步加复杂度。这个顺序不能反。
常见踩坑
切片太粗。一个chunk塞2000 tokens，检索精度直接腰斩。把chunk控制在256到512 tokens，配合50 tokens重叠，效果最稳定。
embedding模型和生成模型用一个厂商。不是技术问题，是成本控制问题。混用OpenAI和Cohere的模型，API账单管理成本翻倍。
不做检索效果评估。凭感觉调参数，改了半天不知道是变好还是变差。用ragas或TruLens做量化评估，每次改动有数据支撑。
忽略查询处理。用户输入很脏，有错别字、有歧义、有废话。加一步查询清洗和改写，效果提升立竿见影。
rerank模型不是越多越好。叠多个rerank不会让效果翻倍，只会让延迟爆炸。一个好的cross-encoder够了。
