拆解 RAG 成本链路后我发现 Embedding 根本不是预算杀手
我最近针对 OpenAI 的模型做了一次实测，结果非常直观：处理一份 1000 页的文档，一次性全部向量化的成本大约只有 0.18 美元。在大多数企业的预算规模面前，这个数字几乎可以忽略不计。然而，很多团队在生产环境下依然面临成本激增的问题，这主要是因为他们陷入了“局部优化”的误区。
一个典型的 RAG 成本分布逻辑其实是这样的：从上传 PDF 开始，经过文本提取、清洗、查重校验，最后才到达 Embedding 环节。很多人认为 Embedding 是最贵的一步，但实际上，真正的成本压力分布在两个极端：一是前端的重复处理，二是后端的持续运行。
首先，最容易被忽视的成本点在于“文档查重校验（Dedup Check）”。绝大多数知识库的更新是渐进式的，很多文档在版本更新时，其实 80% 的内容并没有发生变化。如果你在构建 Pipeline 时缺乏有效的 Diff 对比机制，每次更新都将整份文件当作新文档重新跑一遍流程，那么你浪费的不仅仅是 Embedding 的钱，而是整个预处理链路的计算资源。正确的优化路径应该是：先进行内容比对，仅针对变更部分进行切片和向量化，这样才能在源头上砍掉无效开销。
其次，精细化的切片与元数据管理至关重要。如果文档中只有一个章节被修改，而你的系统设计是全量重跑，那么这种粗犷的管理方式会随着文档数量的增加而产生指数级的成本浪费。通过在元数据中精准记录页码、章节和版本号，可以实现局部更新，避免不必要的重复计算。
而最核心的成本压力其实来自向量数据库的基础设施。大家需要意识到，你支付的费用并不是为了存储那些向量本身，而是为了维持一个能够支持毫秒级检索、处理百万级数据的 24/7 运行实例。在小规模 Demo 测试阶段，这种成本感知不明显，但一旦进入生产环境，这种实例的固定运行费以及大规模索引检索产生的开销，其增长速度远超 Embedding 的线性增长。
最后，最昂贵的环节依然是 LLM 的生成阶段。当检索到的 Chunk 被喂给大模型进行回答时，这里才是真正的资金和延迟黑洞。相比于 0.18 美元处理千页文档的 Embedding 成本，LLM 每次推理消耗的 Token 费用要高出好几个数量级。
总结这次实操经验，优化 RAG 成本不能靠直觉，必须盯着实际账单看。不要在 Embedding 这种低成本环节过度纠结，而应该把精力放在“去重校验”和“基础设施实例优化”上，这才是真正能把成本压下来的关键。
