RAG成本实测：别再被「Embedding很贵」给骗了

很多开发者在构建RAG（检索增强生成）工作流时都有个根深蒂固的误区，觉得 Embedding 阶段最烧钱，所以拼命想方设法减少向量化次数。但我最近把自己的 pipeline 每一环节的开销拆解了一遍，发现事实完全相反：Embedding 其实是整个链路里最便宜的一环。

我用 OpenAI 的模型实测过，一份 1000 页的文档，一次性向量化的成本大概才 0.18 美元。相比之下，真正吃掉预算的其实是后面那些被忽视的环节。

一个典型的 RAG 成本分布逻辑是这样的：

上传PDF 
  │
  ▼
文本提取与清洗 ── 隐形成本开始累积
  │
  ▼
文档查重校验 ── 这里才是省钱的关键
  │
  ┌──┴──┐
  相同  变更
  │     │
  跳过  继续
  │     │
  ▼     ▼
仅对变更部分切片
  │
  ▼
附加元数据
  │
  ▼
Embedding (极便宜，1000页 ≈ $0.18)
  │
  ▼
存储至向量数据库 ── 24/7 运行的实例费才是大头
  │
  ▼
索引与检索 ── 规模扩大后成本远超 Embedding
  │
  ▼
LLM 读取 Chunk 并回答 ── 真正的资金和延迟黑洞

通过这次实操，我发现两个关键的优化点：

• 去重校验（Dedup Check）的权重极高。 绝大多数知识库的更新是渐进的，很多文档 80% 的内容其实没变。如果你每次更新都把整份文件当新文档重新跑一遍流程，那就是在浪费钱。正确的做法是做 Diff 对比，只处理变动的部分。
• 精细化切片与元数据管理。 如果只有文档的一个章节改了，没必要重新切片整个文件。通过在元数据里记录页码、章节和版本号，可以实现精准的局部更新。

至于向量数据库，大家要意识到你付的钱不是为了那些向量本身，而是为了维持一个能毫秒级检索百万级数据的基础设施。在小规模测试时没感觉，但一旦进入生产环境，这种 24 小时运行的实例费和索引检索成本，增长速度远快于 Embedding。

说白了，优化 RAG 成本不能靠直觉，得盯着账单看。