批量发布触发全量向量重建：先算清75.6M令牌的费用敞口

费用的单位不是发布次数，而是实际重新处理的内容

编辑器里的一次批量发布，可能对应240篇变更文档，也可能让连接器扫描18,000篇全文。预算不能写成一次发布约多少美元；必须先确认连接器如何判断变更、是否重新分块，以及失败后从断点继续还是整批重跑。

最基本的输入令牌公式是：处理文档数×每篇平均分块数×每块平均令牌。供应商价格只是最后乘上的单价，因此先用令牌量表示敞口，可以避免模型价格变化后整套计算失效。

把18,000篇与240篇放进同一张计算表

按18,000篇、每篇6个分块、每块700令牌计算，全量重建在重试前需要75,600,000个输入令牌。增量更新240篇只需要1,008,000个输入令牌，两者相差75倍。这个数量级差异足以成为发布审批项，而不是等账单出来后再解释。

重试也应显式计算。若历史上失败和重复带来8%的额外处理，全量方案变为81,648,000个令牌，增量方案为1,088,640个令牌。将两者分别除以一百万，再乘供应商当前公布的输入单价，才得到可用于审批的费用区间。

先证明增量更新不可行，才批准全量重建

全量重建有时确实必要，例如分块算法、嵌入模型或规范化规则改变，旧向量已不能与新查询一致比较。仅修改文章标题、正文或元数据，则通常应要求连接器说明为何不能只更新受影响文档。审批记录要写明技术原因，而不是使用为了保险这样的模糊理由。

还要核对删除和重命名。只新增变更内容却不删除旧向量，会造成搜索结果重复；把清理旧记录作为增量更新的验收项，才能避免用一次便宜发布换来长期检索错误。

给每次发布设置可执行的索引额度

额度至少包括最大文档数、最大令牌数、允许重试比例和中止条件。若连接器在前10分钟内已经处理超过批准文档数，系统应暂停队列并等待复核，而不是因为任务已开始就继续消耗完整预算。

发布前保存语料清单哈希、变更文档列表、连接器版本和费率来源。发布后记录实际处理数、实际重试与供应商用量；估算和实绩的差异会成为下一次额度的依据。

不要用较便宜的模型掩盖错误的处理范围

更换低价模型可能降低本次账单，却没有修复每次改一篇文章都扫描全库的问题。先把处理范围恢复为增量更新，再根据检索质量、维度兼容性和价格选择模型，顺序相反会让质量与费用两个变量同时变化。

计算表应直接支持发布与否的决定

完整的嵌入向量重建测算表必须让审批人一眼看到全量、增量、最坏重试和当前单价来源。若全量有充分技术理由，就在费用上限内安排窗口；若没有，就拒绝本次全量任务并修复连接器。查看产品价格与保护范围时，应以价格页的当前信息为准。

把“批量发布触发全量向量重建：先算清75.6M令牌的费用敞口”的嵌入向量重建测算表用于第一次真实安装。免费下载 AI Cost Circuit Breaker，先从 Monitoring 开始，验证预期信号和回退方式后再启用强制控制。