为控制语义搜索应用中的 RAG 成本，应在部署前批量处理文档索引并预估 token 消耗。仅将检索到的顶部片段发送给聊天模型以生成答案。有效的 token 成本估算应将索引阶段的嵌入输入、检索时的操作以及答案生成的输入和输出分开计算。估算不仅涉及简单的 token 计数，还需评估片段大小、重叠度及 top-k 设置，因为这些因素直接影响提示长度和成本。实用的估算始于使用代表性文档和真实用户问题，以计算各种分块策略下的 token 总量。召回率至关重要：只有当最相关的段落仍被检索到时，减少片段数量才有意义。重排序可改善上下文排序，从而减少发送给聊天模型的片段数量。索引应作为独立于用户请求路径的批处理作业进行处理，以避免高摄入量导致意外的提示费用。文档索引过程中的重试需要幂等键或客户端提供的标识符，以防止重复数据。在优化提示或模型之前，必须使文档分布可见并识别 oversized 片段。使用提供商特定的 token 计数调用，并配合适当的退避和重试策略，是实现准确估算的关键。批量索引为大规模回溯提供了作业监控和审计追踪的优势，将上传与嵌入创建分离开来。重要的是不要混淆轮询批处理作业与幂等写入操作的重试策略。虽然批量索引不适合即时可搜索性，但一条小型同步路径可满足该需求。RAG 栈组件的选择（如 OpenAI、Anthropic、Google Gemini、Pinecone、Weaviate 或 Infrai）取决于现有工作流和团队优先级。迁移应仅在真正提升系统性能时进行，而非仅仅为了边际成本节约。最终，代码必须提供基于事实的答案；若检索能力薄弱，再清晰的成本估算也毫无意义。