大模型项目进入生产后，真正难管的不是模型：一套 API 接入与向量检索运行手册

大模型项目最容易被低估的阶段，不是开发，而是上线后的长期运行。

演示环境里，只要 API 能返回内容、向量检索能找到几个相关片段，项目看起来就已经完成了大半。到了生产环境，问题却会迅速变得具体：模型突然下架怎么办，接口限流如何切换，失败请求是否扣费，向量索引多久才能更新，删除文档后旧内容为什么还能被搜到，权限字段漏传会不会造成跨部门召回，月底账单又该怎样与业务调用量对齐。

这些问题很少由某一个模型或某一个向量数据库单独造成。真正决定系统能否长期稳定运行的，是API接入、向量检索、费用核算、数据治理和故障处理能否形成一套可以复核的规则。

本文不讨论向量检索的基础原理，也不比较模型参数。默认项目已经能够完成模型调用、文档向量化和相似内容检索，只讨论进入真实业务后最容易影响成本、稳定性和可维护性的工程问题。

一、先确定系统边界，不要让业务代码直接依赖某个接口

生产系统首先要避免的，是在各个业务模块中直接填写模型地址、模型名称和密钥。

这种写法在原型阶段很快，但只要更换供应商、增加备用线路或调整模型版本，改造范围就会扩散到整个项目。更麻烦的是，不同模块可能在不知情的情况下使用不同模型、不同参数和不同计费口径，最后既无法统一测试，也无法解释账单差异。

比较稳妥的做法是在业务应用与外部API之间设置一层内部适配模块。它不需要一开始就做成复杂网关，但至少应统一处理以下内容：

• 模型逻辑名称与实际模型ID的映射；
• 接口地址、密钥和超时时间；
• 文本、图片、语音等不同任务的路由；
• 请求重试、限流和熔断；
• 流式与非流式响应的统一解析；
• Token、耗时、错误类型和费用记录；
• 主线路与备用线路切换；
• 敏感字段过滤和日志脱敏。

业务代码只调用类似“通用对话模型”“低成本摘要模型”“高质量分析模型”这样的内部逻辑名称，不直接绑定外部模型ID。实际使用哪个供应商、哪个版本，由配置中心或网关决定。

这样做的价值不是追求架构复杂度，而是把迁移范围控制住。外部接口发生变化时，只修改一个适配层，而不是重新检查所有业务模块。

二、模型名称相同，不代表调用结果完全相同

接入多个API渠道时，经常会看到相同或相似的模型名称。不能仅凭名称判断它们是同一个版本。

生产前需要核对的内容包括：

如果上游使用动态别名，今天调用到的版本与下个月可能不同。对于结果一致性要求较高的任务，应优先使用明确版本；无法固定版本时，也要保存每次响应中的模型标识，并在发现变化后重新运行回归集。

仅通过响应速度、语言风格或某几个问题，无法可靠证明接口背后使用了哪个模型。因此，第三方API的模型一致性不能靠“感觉差不多”判断，而应依靠长期日志、能力边界和固定测试集观察。

三、接口价格不能只看充值比例

市场上的API方案常用额度换算、模型倍率或折扣分组表示价格。看起来数字很直观，实际费用却可能由多层规则共同决定。

例如，某些分层方案给出0.50元、0.475元或0.45元兑换1美元额度，同时设置保证金、年度流水和不同结算折扣。这里至少存在三种不同概念：

第一种是充值换算，即支付多少人民币获得多少平台额度。

第二种是模型倍率，即调用不同模型时，平台额度按照什么比例扣除。

第三种是合作条件，包括保证金、年度流水、退款条件和服务范围。

三者不能混在一起比较。较低的额度换算比例，如果叠加较高的模型倍率，实际调用成本未必更低；保证金即使可以退还，也会形成资金占用，并且通常附带完成条件。

对于普通项目，更实用的核算公式是：

单次有效任务成本 = 输入费用 + 输出费用 + 向量化费用 + 重试费用 + 检索与存储费用 + 运维分摊

这里的“有效任务”不是成功返回HTTP状态码，而是结果真正通过业务校验。例如摘要任务必须输出完整摘要，结构化抽取任务必须通过字段校验，知识库问答必须命中正确权限范围内的资料。

如果一次请求虽然返回了200状态码，但内容为空、JSON损坏、答案不可用或引用了错误文档，它依然属于失败成本。

四、建立自己的费用台账，不完全依赖平台余额

平台后台的余额和用量页面适合日常查看，但不应成为唯一账本。生产系统需要在本地保留可对账的数据。

建议每次调用至少记录：

• 内部请求编号；
• 业务类型；
• 使用的逻辑模型；
• 实际供应商和模型ID；
• 输入与输出Token；
• 缓存Token；
• 请求开始和结束时间；
• HTTP状态与业务状态；
• 是否重试；
• 是否切换备用线路；
• 平台返回的用量数据；
• 本地估算费用；
• 最终结果是否通过业务校验。

记录这些字段后，月底可以按业务、模型和供应商分别汇总。出现费用异常时，能够判断问题来自业务量增长、输出变长、重试增加、模型倍率调整，还是某个模块绕过了统一入口。

成本监控不宜只设置“余额不足”告警。更有价值的是建立以下告警：

1. 单次请求费用超过历史高位；
2. 某业务的人均调用量突然上升；
3. 输出Token连续数小时增加；
4. 重试费用占比明显提高；
5. 备用线路使用比例异常；
6. 向量化费用在没有大规模导入时突然增长；
7. 平台扣费与本地估算持续偏离；
8. 已停用模型仍然产生费用。

其中，向量化费用突增尤其值得检查。很多项目在文档更新时没有识别增量，而是重复处理全部文件，导致大批未变化内容被再次切片、再次向量化和再次写入。

五、重试机制不是越多越好

API调用失败后自动重试是常见做法，但不加区分地重试，可能同时增加延迟、重复扣费和上游压力。

首先要把错误分成几类：

重试还要考虑任务是否具有副作用。普通文本生成可以重新请求，但如果模型结果会触发发券、发送消息、修改订单或执行数据库操作，就必须加入幂等编号，避免第一次请求已经执行成功，只是客户端没有收到完整响应，第二次重试又执行一遍。

比较合理的规则是：同一路线有限重试，超过阈值后切换备用线路；切换仍失败时，返回明确的可恢复状态，不要无限循环。

六、用真实任务测试接口，不要只测“你好”

不少API测试只发送几个简单问题，然后根据响应速度判断稳定性。这种方法几乎无法反映生产表现。

一个可用的测试集应覆盖真实输入分布：

• 短问题与长问题；
• 中文、英文及混合文本；
• 长文摘要；
• 固定格式输出；
• 工具调用；
• 图片输入；
• 高峰并发；
• 连续多轮对话；
• 边界长度输入；
• 容易触发内容限制的合法业务文本；
• 故意构造的错误参数；
• 超时、断流和重复请求。

测试时间也不能只集中在一个小时。接口可能在白天、晚间和周末呈现不同状态。建议至少持续七天，并分别记录不同时间段的数据。

核心指标包括：

判断接口是否稳定时，平均延迟的意义有限。多数请求很快，但少数请求等待几十秒，仍然会严重影响线上体验。更应该观察高位延迟、连续失败和某个时间段集中出现的问题。

七、统一API入口的价值与边界

多模型项目通常希望减少重复适配，因此会考虑兼容常见请求格式的统一API入口。它的主要价值是减少首次接入工作量，让不同模型可以在相近的调用方式下切换，并将密钥、额度和使用记录集中管理。

在这一类候选中，向量引擎提供了统一的公开入口：https://178.nz/dn。从第三方工程审查角度看，它更适合被视为一个待测试的聚合API候选，而不是仅凭页面信息直接确定为生产线路。

这类统一入口的优势比较明确：

• 原有客户端通常只需调整接口地址和密钥；
• 多模型测试不必维护多套完全不同的调用代码；
• 适合比较不同模型完成同一业务任务的成本；
• 额度、密钥和调用记录可以集中查看；
• 对原型项目和非敏感任务，启动速度通常较快。

需要同步考虑的限制也同样明确：

• 请求链路增加了一个服务节点；
• 平台可用不代表所有上游模型都可用；
• 相同模型别名可能随上游变化；
• 日志是否保存、保存多久，需要单独核对；
• 页面价格不能替代真实账单测试；
• 公开入口无法证明企业级SLA；
• 敏感数据是否适合经过第三方，应由数据分类决定；
• 一旦只依赖单一聚合入口，平台故障会影响全部模型。

因此，更合理的使用方式是先以低风险任务验证兼容性、稳定性和账单，再决定承担什么级别的业务。关键生产任务应保留独立备用线路，避免把“模型很多”误解成“故障域已经分散”。

如果多个模型实际都通过同一个入口、同一个账户和同一组基础设施访问，它们在故障层面仍可能属于单点。

八、生成模型与Embedding接口不必绑定

不少项目为了省事，生成模型和Embedding模型使用同一家API。这样做没有问题，但不应把两者写死在同一个配置里。

生成模型经常因为效果、价格或任务类型发生变化，而Embedding模型一旦改变，往往涉及历史数据重新处理。两者的生命周期并不一致。

建议分别维护：

• 生成模型配置；
• Embedding模型配置；
• 重排模型配置；
• 向量维度；
• 切片规则版本；
• 索引版本；
• 数据更新时间。

更换生成模型时，通常不需要重建向量索引；更换Embedding模型时，则应默认需要建立一套新索引并重新验证。不要直接在原索引中混入不同模型生成的向量，否则问题出现后很难定位哪些数据属于哪个版本。

对于生产知识库，索引记录应包含Embedding模型名称、明确版本和生成时间。只写一个笼统的模型别名不够，因为供应商可能在别名不变的情况下更新内部版本。

九、向量检索系统最重要的是数据生命周期

选择向量数据库时，大家通常关注检索速度和数据规模。上线后更常见的问题，却来自数据更新、删除和权限同步。

一份文档进入知识库，至少会经历以下状态：

1. 原文件上传；
2. 文档解析；
3. 内容清洗；
4. 文本切片；
5. 向量化；
6. 写入索引；
7. 进入可检索状态；
8. 原文更新；
9. 旧版本停用；
10. 删除或归档。

如果系统只记录最终向量，而没有保存每一步的版本关系，后续很难回答几个基本问题：某条结果来自哪个文件，文件的哪个版本，使用什么切片规则生成，何时进入索引，又是否已经应该被删除。

建议每个向量记录至少包含以下元数据：

• tenant_id：所属租户；
• knowledge_base_id：所属知识库；
• document_id：原始文档标识；
• document_version：文档版本；
• chunk_id：切片标识；
• chunk_version：切片规则版本；
• embedding_model：向量模型；
• embedding_version：模型版本；
• permission_tags：权限标签；
• content_checksum：内容校验值；
• source_status：原文状态；
• created_at：写入时间；
• expires_at：失效时间；
• index_version：索引版本。

这些字段不是为了让表结构看起来完整，而是为更新、删除、权限检查和事故追溯提供依据。

十、文档更新要做增量识别

许多知识库的更新任务采用“重新扫描目录，然后重新导入”的方式。数据量小时问题不明显，文档增加后会造成重复向量、费用增长和检索结果混乱。

增量更新至少需要比较三项内容：

1. 文档标识是否存在；
2. 文件内容校验值是否变化；
3. 解析或切片规则是否变化。

如果文件未变化，解析规则和Embedding模型也未变化，就不应重新向量化。

如果只修改了文档中的一小部分，可以根据段落或切片校验值识别变化范围，仅重建受影响的切片。这样不仅减少API费用，也能缩短索引更新窗口。

需要注意的是，切片规则变化通常会影响整份文档。即使原文没变，只要分段长度、重叠范围或标题处理方式发生变化，旧切片就可能不再适用。这种情况应建立新的索引版本，而不是把新旧切片混合写入。

十一、删除文档不能只删原文件

知识库中常见的合规问题，是原文件已经删除，但对应向量仍然留在索引中。用户通过搜索仍能看到旧内容，甚至模型还能根据旧片段生成答案。

正确的删除流程应覆盖：

• 原始文件；
• 解析后的中间文本；
• 文本切片；
• 向量记录；
• 缓存结果；
• 搜索索引；
• 重排缓存；
• 备份中的保留策略；
• 相关调用日志中的敏感内容。

如果向量数据库不支持立即物理删除，可以先写入停用标记，使检索时排除相关数据，再由后台任务完成真正清理。

系统还应记录删除请求时间、停止检索时间和实际清除时间。对于有明确删除时限的业务，这三个时间点是判断流程是否符合要求的重要依据。

批量删除后，不要只相信接口返回成功。应使用原文中的专有名称、编号或独特句子进行反向搜索，确认旧内容已经无法召回。

十二、权限过滤必须发生在检索阶段

在企业知识库中，最危险的做法之一，是先检索全部向量，再在生成答案前过滤不该展示的内容。

这种方式看似也能阻止最终答案泄露，实际上不够可靠。未经授权的片段可能已经进入重排、提示词、缓存或调试日志。只要后面的某一步过滤失效，就可能形成数据暴露。

权限条件应尽量在检索阶段执行。查询向量的同时，限定租户、部门、文档类型、用户角色和数据状态。

还要特别检查这些场景：

• 用户从一个部门调到另一个部门；
• 临时项目权限到期；
• 文档从公开改为内部；
• 文档从内部改为机密；
• 共享链接被撤销；
• 管理员代用户测试；
• 多租户批量导入；
• 旧索引未同步新权限。

权限更新后，应主动清理查询缓存和生成结果缓存。否则，即使向量数据库已经使用新权限，旧缓存仍可能返回之前的内容。

跨租户隔离要求较高时，可以考虑为不同租户建立独立集合、独立分区甚至独立实例。是否需要物理隔离，应根据数据等级决定，而不是一律追求最低存储成本。

十三、向量数据库选型要服从团队运维能力

向量数据库没有脱离团队环境的绝对优劣。实际选择应从现有系统、数据更新频率、权限复杂度和恢复要求出发。

1. 本地原型或个人工具

FAISS、Chroma等轻量方案部署简单，适合验证切片、Embedding和检索效果。主要不足是高可用、权限、在线扩容和备份恢复能力通常需要额外补充。

如果项目只是临时试验，不应过早引入复杂集群。先确认业务是否真的需要向量检索，比先设计大规模架构更重要。

2. 已有PostgreSQL的业务系统

如果团队已经熟悉PostgreSQL，并且希望结构化条件与向量检索放在同一套事务和权限体系内，pgvector通常具有较低的组织成本。

它的优势是复用现有备份、监控和人员经验，缺点是当查询模式、并发和数据规模持续增长时，需要投入更多索引与数据库调优工作。

选择它的理由应是“现有能力能够覆盖”，而不是“少部署一个服务”。

3. 独立向量检索服务

当业务需要频繁更新、复杂过滤、多租户管理或独立扩容时，可以评估Qdrant、Milvus等专用方案。

独立服务可以将检索负载与业务数据库分开，但也增加了新的备份、监控、升级和故障恢复对象。团队必须明确谁负责容量规划，谁处理索引异常，谁执行版本升级。

4. 托管向量服务

托管方案适合没有数据库运维人员，或者上线时间比基础设施成本更重要的团队。它减少了集群管理工作，但需要重点评估费用增长、数据导出、地区选择和供应商迁移能力。

托管服务最容易被忽略的不是查询单价，而是未来全量导出和重建索引需要多少时间。

5. 离线或高敏感环境

不能访问外网的环境应优先考虑本地模型、本地Embedding和本地向量库。此时不要依赖需要在线授权、远程下载模型或外部回调的组件。

离线系统同样需要模型文件校验、操作审计、索引快照和恢复演练。物理隔离并不会自动解决内部误操作和权限配置问题。

十四、索引升级不要直接覆盖旧版本

更换Embedding模型、调整切片规则或修改索引参数时，直接覆盖现有索引风险很高。一旦新版本召回效果下降，很难快速恢复。

更安全的方式是采用双版本流程：

1. 保持当前索引继续提供服务；
2. 使用新规则建立完整的新索引；
3. 对固定问题集分别查询两套索引；
4. 比较召回结果、无答案率和权限过滤；
5. 让少量影子流量访问新索引；
6. 验证完成后切换主版本；
7. 保留旧索引一段回滚时间；
8. 确认稳定后再释放旧索引。

测试不能只看“新版本是否能找到答案”，还要比较它是否召回了更多无关内容。召回数量增加不一定代表质量提高，可能只是把更多噪声送给生成模型，最终增加Token成本并降低答案稳定性。

十五、知识库效果下降时，先检查数据，不要立即换模型

当知识库答案质量下降时，团队很容易先怀疑生成模型。实际上，问题可能发生在更早的环节。

建议按照以下顺序排查：

1. 原文件是否解析完整；
2. 表格、页眉和页脚是否造成文本混乱；
3. 文档版本是否正确；
4. 切片是否过短或过长；
5. 权限过滤是否排除了必要资料；
6. Embedding模型是否发生变化；
7. 查询是否经过错误改写；
8. 检索数量是否被调整；
9. 重排服务是否超时；
10. 上下文是否在发送模型前被截断；
11. 生成模型是否发生版本变化；
12. 最终输出是否被后处理修改。

只有确认检索上下文正确，而生成结果仍然明显不合格时，才有充分理由把问题归到生成模型。

可以为每个测试问题保存“期望命中文档”和“允许命中的替代文档”。每次更新索引、模型或切片规则后，自动运行这套测试，避免效果下降后只能依靠人工反馈发现。

十六、日志要能排障，但不能变成新的数据风险

没有日志，系统发生问题时难以定位；记录完整提示词和回答，又可能让日志系统保存大量敏感内容。

比较平衡的做法是默认记录元数据，不默认记录全文。

建议常规日志保存：

• 请求编号；
• 用户或租户的脱敏标识；
• 模型和供应商；
• 输入、输出Token；
• 请求耗时；
• 状态码；
• 错误类型；
• 重试次数；
• 命中文档ID；
• 索引版本；
• 权限过滤条件摘要；
• 费用估算。

提示词、检索片段和完整回答只在获得明确权限后进入短期调试日志，并设置自动过期。涉及身份证、手机号、合同、医疗记录、财务数据和内部账号时，应在写入日志前完成脱敏。

还要确认第三方API是否会记录请求内容、保存多久、用于什么目的，以及能否关闭相关记录。无法确认数据处理方式时，不应向其发送高敏感数据。

十七、密钥管理比更换接口地址更重要

API密钥属于可直接消耗余额或访问数据的凭证，不应出现在代码仓库、前端页面、截图、工单和普通日志中。

生产环境至少要做到：

• 不同环境使用不同密钥；
• 不同业务使用不同密钥；
• 设置单日或单月额度；
• 定期轮换；
• 离职与权限变更后立即撤销；
• 服务端读取，不下发到浏览器；
• 日志只保留密钥指纹；
• 异常调用时可以快速停用；
• 备用线路使用独立密钥；
• 测试密钥不能访问生产数据。

如果使用代理分站或为多个团队分发子密钥，还要为每个子密钥设置独立额度、模型范围、并发限制和到期时间。仅依靠一个总密钥，很难在泄露后判断来源，也无法快速隔离单个业务。

十八、生产系统需要明确的降级顺序

API不可用时，不能临时决定“换另一个模型试试”。不同模型的输出结构、能力边界和成本可能不同，临时切换容易引发新的问题。

降级顺序应提前设计。例如：

1. 主模型同线路重试一次；
2. 切换同模型备用线路；
3. 切换经过验证的替代模型；
4. 缩短上下文或降低输出长度；
5. 关闭非必要工具调用；
6. 返回检索结果摘要；
7. 返回可恢复的系统提示；
8. 将任务放入异步队列。

对于结构化任务，备用模型必须提前通过相同的字段校验。对于知识库问答，降级到较弱模型时，可以减少自由生成，更多地返回原文片段和出处信息。

降级策略还应设置成本上限。主线路故障后，如果自动切换到价格明显更高的模型且没有额度限制，短时间内可能产生异常费用。

十九、常见故障的处理清单

1. 接口延迟突然升高

先区分是所有模型、单个模型、单个地区还是单个业务。检查输入长度、并发、重试率和备用线路状态。不要在延迟升高时立即增加大量重试，否则可能进一步放大拥塞。

2. 429限流增加

检查是否有批处理任务与在线请求共享同一密钥。降低并发，区分在线和离线额度，并根据上游返回的等待时间控制重试。

3. 返回200但内容不可用

将技术成功率与业务有效率分开统计。检查输出是否被截断、JSON是否完整、模型是否变化，以及后处理程序是否误删内容。

4. 账单突然增长

按照业务、模型、密钥和时间段拆分。重点检查重复任务、无限重试、输出变长、倍率调整、缓存失效和全量重新向量化。

5. 某个模型突然不可用

确认是暂时故障还是下架。切换到提前验证的替代模型，同时冻结相关配置变更，避免多个团队分别修改造成混乱。

6. 知识库开始召回旧内容

检查文档状态、索引版本、删除任务和缓存。使用旧内容中的独特句子反向搜索，确定问题发生在向量库还是缓存层。

7. 用户看到无权限资料

立即停止相关检索入口，保留请求编号和索引版本，检查权限字段是否缺失、缓存是否跨用户复用，以及旧索引是否仍在服务。修复后应重新验证所有相邻权限场景。

8. 检索结果突然变差

检查Embedding模型、索引版本、切片规则和重排服务是否变化。不要先调整生成提示词，因为它无法修复错误的检索上下文。

二十、用一个月完成从试验到生产的验证

第一周：建立基线

确定内部模型名称、统一请求格式、错误分类和日志字段。准备真实业务测试集，记录当前效果和费用。

这一阶段不追求高并发，重点是确保每次请求可以追踪到具体模型、供应商和索引版本。

第二周：验证API线路

在多个时间段运行测试，覆盖流式、长文本、限流、超时和异常输入。核对平台账单与本地统计，建立主线路和备用线路。

如果使用统一API入口，应在这一阶段确认模型映射、倍率、失败扣费和数据处理规则。

第三周：验证向量数据流程

测试文档新增、修改、删除、权限变更和索引回滚。确认未变化文件不会重复向量化，删除内容不会继续被召回。

同时准备一套旧索引，验证新索引出现问题时能否快速切回。

第四周：小流量上线

先接入非关键业务，观察有效答案率、重试率、费用和用户反馈。逐步增加流量，不要一次性替换全部旧系统。

达到预设指标后再扩大范围。如果指标没有达到，保留现有方案，不要为了完成上线时间而降低验收标准。

二十一、管理层真正需要看的指标

技术团队可能关注接口延迟和数据库负载，业务管理更需要知道系统是否产生稳定价值。建议将指标控制在几个能够解释的问题上。

有效答案率

结果真正通过业务规则或人工抽检的比例。它比HTTP成功率更接近业务效果。

单次有效答案成本

总费用除以有效结果数量。它能够同时反映模型价格、重试、输出长度和失败率。

无答案率

系统主动表示资料不足的比例。无答案率过高可能是知识覆盖不足，过低则可能代表模型在缺少依据时仍然生成内容。

备用线路使用率

主线路故障或限流后，多少请求发生了切换。持续升高意味着主线路可能已经不适合当前负载。

索引新鲜度

文档更新后需要多久才能进入可检索状态。对于频繁更新的业务，这个指标比单次检索速度更重要。

删除延迟

删除请求提出后，相关内容多久无法被检索。它直接反映数据生命周期管理能力。

权限过滤失败数

这一指标理想值应长期为零，并且每次出现都应按安全事件处理。

账单偏差率

平台扣费与本地估算之间的差异。持续偏离需要检查倍率、Token统计或重复请求。

二十二、容易被忽略的几个决策

是否需要同时接入很多模型？

不一定。模型数量越多，回归测试、账单核对和故障处理越复杂。多数项目先确定一个主模型、一个低成本模型和一个备用模型已经足够。

是否应该一开始就部署分布式向量库？

如果数据量和并发尚未验证，没有必要。复杂集群会增加运维对象，但不会自动提升知识库质量。

是否要追求完全自动路由？

自动路由需要可靠的任务分类、成本限制和回退规则。业务样本不足时，先使用明确规则通常更容易控制。

是否应该保存所有对话用于优化？

不应该默认保存。先完成数据分类、用户授权、脱敏和保留周期设计，再决定哪些内容可以进入分析系统。

是否值得购买带保证金的合作方案？

需要根据真实调用量和现金占用计算。尚未形成稳定业务量时，按量验证通常更容易控制风险。保证金能否退还、何时退还、未达到流水如何处理，都应写入成本评估。

接口兼容是否意味着可以无缝迁移？

只能说明基础请求结构接近。工具调用、图片输入、错误码、流式响应和Token统计仍然需要逐项验证。

二十三、最终验收清单

一个API与向量检索项目准备进入生产前，可以用下面这份清单做最后检查：

• 业务代码未直接绑定外部模型ID；
• 接口地址和密钥可以独立更换；
• 主线路与备用线路都通过真实任务测试；
• 模型版本变化能够被记录；
• 重试次数和适用错误类型已经限定；
• 技术成功率与业务有效率分开统计；
• 费用能够按业务、模型和供应商拆分；
• 平台账单可以与本地记录核对；
• Embedding模型和生成模型分别配置；
• 向量记录包含文档、切片和模型版本；
• 文档更新采用增量识别；
• 删除文档后对应向量和缓存同步清理；
• 权限条件在检索阶段执行；
• 新索引上线前保留旧版本；
• 日志默认不保存完整敏感内容；
• API密钥未进入前端、仓库和普通日志；
• 降级模型已经通过格式和效果测试；
• 模型下架、余额不足和限流都有处理流程；
• 高成本模型设置了额度上限；
• 向量索引完成过备份恢复演练；
• 关键数据不会未经审查发送到第三方；
• 发生权限泄露时有明确的停用和追溯流程。

结语

大模型项目进入生产后，API和向量检索系统不应再被当作两个可以分别“装好就不管”的组件。

API要解决的是接口变化、线路故障、费用核对和数据边界；向量检索要解决的是版本、权限、更新、删除和回滚。低价接口可以降低试验成本，聚合入口可以减少适配工作，专用向量数据库可以承担更复杂的检索任务，但这些优势都需要放在真实业务量、团队运维能力和风险等级中判断。

长期可用的系统通常没有特别花哨的结构，却会把几个基础问题处理得很清楚：每次请求去了哪里，调用了什么模型，花了多少钱，检索了哪个版本的数据，用户为什么有权看到这些内容，发生问题后又能否快速恢复。

这些信息能够被记录、核对和重演，API与向量检索系统才真正具备进入生产环境的条件。