嵌入（embedding）是将文本转换为向量的过程，它是 RAG 系统构建知识库的必经之路。然而，嵌入环节也会产生实实在在的成本，尤其在文档规模大、更新频繁或模型选择不当时，这笔开销可能远超预期。本节从三个角度拆解嵌入成本的构成，并提供实用的控制思路。
1. 批量嵌入：首次建库的一次性成本
首次构建知识库时，需要将所有历史文档全部切分并向量化，这就是批量嵌入。它的开销主要取决于三个因素：
- 文档总量：总 token 数直接决定调用量。
- 嵌入模型的计价方式：商业 API 通常按 token 计费（如每百万 token 几美元到十几美元不等），开源模型本地部署则需考虑 GPU 或 CPU 的算力消耗。
- 是否可并行：多数嵌入服务支持批量请求，合理利用并发能显著缩短处理时间，但不减少总 token 消耗。
一个真实案例：某中型企业准备将 2 万份内部文档接入 RAG，总文本量约 5000 万 token。使用某主流商业嵌入模型（每百万 token 0.13 美元），一次性嵌入成本约为 6.5 美元。即便算上网络开销和重试，总费用也远低于一次模型微调。但如果需要先用 OCR 处理扫描件、提取文字，前置数据处理成本可能远高于纯文本嵌入，需要一并纳入评估。
实用建议：
- 先做规模估算：抽选一批典型文档统计平均 token 量，再乘以文档总数，推算总成本。
- 利用免费额度：多数云厂商和模型服务对新注册用户提供首月免费额度，可用于测试和首次构建。
- 批处理与断点续传：脚本记录已处理文档 ID，失败后可从中断点继续，避免重复消费。
2. 增量嵌入：知识更新的持续成本
知识库建成后，日常更新的嵌入成本通常远低于首次批量构建，但若管理粗放，也可能逐渐累积成不可忽视的开支。增量嵌入的触发场景包括：
- 新文档入库；
- 旧文档内容修订；
- 版本替换（删除旧版、嵌入新版）。
成本的“隐形膨胀”往往来自两个方面：
- 无效重复嵌入：未做变更追踪，每次更新都将整个文档重新嵌入，而不是只处理变化的部分。一份 200 页的手册只改了一个段落，却重新向 API 发送了全部内容。
- 废弃切片未及时清理：旧版本切片保留在向量数据库中，不仅占用存储空间，还会在检索时混杂过期信息，变相增加后续生成中的澄清成本。
控制增量的实用做法：
- 文档级哈希指纹：对每个切片计算内容哈希，更新时与原哈希比对，只嵌入内容实际变化的切片。
- 日志与监控：记录每次嵌入的 token 消耗，设置周度或月度用量预警，避免异常飙升。
- 迟滞更新策略：对于非紧急修订，可合并在低峰期批量处理，减少频繁小量调用的网络开销和调度复杂度。
总体而言，增量嵌入的月成本通常仅为首次构建的 5%–20%（取决于更新频率），是一种可预测的持续支出。
3. 模型选型：性能、成本与资源的平衡
嵌入模型的选择直接决定嵌入的质量和成本，是系统设计阶段最需要权衡的决策之一。关键考量包括：
- 商业 API vs 本地部署
- 商业 API（如 OpenAI、Cohere 的嵌入接口）：按量付费，零前期投入，适合快速启动或文档规模不大的场景。对于每月嵌入量在千万 token 以下的项目，API 成本通常远低于自建 GPU 服务器的折旧、电费和运维人力。
- 开源本地部署：使用 Sentence‑Transformers、BGE 等开源模型，借助自有或租用的 GPU 推理。当每月嵌入量达到数亿 token 时，API 的累计费用可能超过一台 GPU 服务器的月成本，此时自建更有经济优势。
- 模型规格与效果
- 高参数、高维度的嵌入模型（如 1024 维或更高）通常检索精度更好，但计算量和存储成本更高。向量维度每增加一倍，检索时的内存和距离计算开销也会显著上升。
- 轻量化模型（如 384 维）响应快、占用少，适合对精度要求不极端的内部问答。建议先用小模型快速验证业务可行性，再根据检索质量决定是否升级。
选型实用清单：
- 评估数据集：准备 50–100 条典型问答对，对比候选模型的召回率，发现差距再算经济账。
- 关注多语言和垂直领域：有的模型对中文、法律、医疗等场景做了优化，可能用中等规格就达到通用大模型的检索质量，间接节省嵌入成本。
- 留意存储成本：向量维度 × 切片数量 × 4 字节（float32），一次计算就知道数据库和内存需求的大致量级。
综合来看，嵌入成本在 RAG 总体支出中占比通常不高（大多情况下远低于生成模型调用费用），但通过合理估算、增量控制和模型选型，仍可避免不必要的浪费，让整个系统的性价比保持在健康水平。