独立开发者接了三个客户的搜索定制需求后，我把模型调用收进了同一道闸门
业务痛点：智能搜索看起来简单，管起来会失控
我带着一个三人的小团队，主营业务是给中小商家做小程序和工具站。去年开始，客户陆续提出“智能搜索”的需求：电商客户想要“搜红色连衣裙但不要收腰的”，内容站客户想要语义检索替代关键词匹配，还有一个做本地服务的客户想让用户直接用一句话描述需求。
这些需求单独看都不难——接一个向量模型做 Embedding，接一个 LLM 做查询改写，一个 Demo 一周就能跑出来。真正让人头疼的是落地之后的运营：
第一，模型分散在四个供应商。 Embedding 用一家的，查询改写用另一家的，意图分类又倾向用第三家的小模型。每家一个账号、一套计费、一套 SDK、一套限流规则。某个客户的服务半夜报错，我得先确认是哪家供应商的 API 挂了，还是我们的代码问题。
第二，客户之间不能互相影响。 A 客户做活动流量暴涨，如果不做隔离，B、C 客户的搜索就会变慢甚至失败。但让小团队给每个客户单独搭一套调用链路，维护成本直接乘以三。
第三，模型不能锁死。 上季度效果最好的改写模型，这季度可能就被新模型碾压，或者涨价了。如果在代码里硬编码供应商，每次换模型都是一次全量回归测试，小团队耗不起。
作为管流程的人，我的判断是：问题不在算法，在治理。 我们缺的不是模型能力，而是一道统一的控制层。
架构设计：把“调模型”这件事从业务代码里挪出去
重构后的架构分成四层：
业务层：各客户的搜索入口（小程序 / H5 / API）
↓ 统一请求格式
网关层：统一 AI API 网关（多模型路由 / 限流 / 预算 / 日志）
↓ 按路由规则分发
模型层：Embedding 模型 / 查询改写模型 / 意图分类模型（可替换）
↓
检索层：向量库 + 倒排索引混合检索核心原则有三条：
- 业务代码只认识“任务”，不认识“供应商”。 业务层发出的是“embedding 任务”或“改写任务”，具体路由到哪个模型，由网关的配置决定。
- 按客户做配额隔离。 每个客户一个独立的 Key 或命名空间，限流和预算在网关层生效，A 客户的流量峰值不会拖垮 B 客户。
- 所有调用留痕。 谁、什么时候、调了什么模型、花了多少 Token，统一记录，方便成本分摊和故障回溯。
为什么统一网关能降低维护成本
这是整个方案里我最想强调的部分，从管理者的账本看，成本降在四个地方：
一是接入成本从 N 倍降到 1 倍。 网关对上暴露统一接口，业务代码写一次。之后无论新增多少供应商、换多少模型，业务代码零改动——换模型从“全量回归”变成“改一行路由配置”。对小团队来说，这等于把最贵的工程师时间从重复接入里释放出来。
二是排错路径变短。 以前出问题要在多家供应商的后台之间切换查状态；现在所有调用的日志、错误码、延迟数据在一个地方，配合统一监控，故障定位从“猜”变成“看”。
三是风险有了刹车。 网关层的预算控制可以给每个客户设硬上限，某个客户被恶意刷接口时，烧的是他自己的配额而不是整个账户。密钥也统一收在网关侧，业务服务器上不存放任何供应商密钥，泄露面大幅缩小。
四是供应商议价空间变大。 调用量集中到一处后，模型选择完全解耦，哪家性价比高就用哪家，切换成本趋近于零。
关键实现步骤
落地时我们按四周推进，关键动作如下：
第 1 周：梳理与冻结
□ 盘点所有 AI 调用点（改写/Embedding/意图分类），明确输入输出契约
□ 定义统一的任务描述格式与错误码规范
□ 在网关注册各模型，用真实流量样本做基准确认效果无损
第 2 周：灰度迁移
□ 新旧链路并行，10% 流量切到网关
□ 对比延迟、Token 消耗、检索命中率，连续 3 天达标后逐步放大到 100%
□ 旧直连代码保留一周作为回滚通道
第 3 周：治理配置
□ 按客户配置独立 Key、限流阈值、月度预算上限
□ 配置告警：错误率 > 2%、延迟 P95 > 3s、预算用量 > 80% 时通知
□ 建立变更流程：换模型必须先在灰度客户验证 48 小时
第 4 周：收尾固化
□ 下线旧直连代码与散落的供应商密钥
□ 输出一页运维手册：常见错误码含义、降级预案、模型切换 SOP
□ 每月复盘各客户的 Token 成本与搜索质量指标其中最值得强调的是降级预案：网关配置了模型备选链，主改写模型超时三次自动切到备用小模型，效果略降但搜索不中断。上线三个月，我们经历过两次供应商抖动，客户侧完全无感知。
效果与几点管理心得
迁移后最直观的变化：模型相关的维护工时从每周约 6 小时降到 1 小时以内；新增一个客户的智能搜索需求，接入周期从两周压缩到三天，因为调用链路和治理配置全是复用的。
如果同样带小团队做类似落地，我的三条心得：
- 先治理，后智能。 搜索效果不好可以慢慢调，但调用链路失控会直接烧钱、丢客户。先把闸门建好，再往里加模型。
- 灰度不是流程负担，是回滚保险。 任何模型变更都走灰度，小团队没有专门的 QA，灰度就是最低成本的质量防线。
- 给客户的承诺要留余地。 有了备选模型链和预算上限，你才敢在合同里写可用性承诺。
智能搜索的算法门槛正在快速降低，真正拉开差距的，是谁能把模型调用管得又稳又便宜。如果你也准备把模型调用统一收口，可以先在统一 AI 网关上注册试用，把现有的一条调用链路迁移过去跑一周，成本和稳定性账自然就清楚了：https://api.thistoken.ai/register
---
本文的示例只需一个 API Key 就能复现：在 https://api.thistoken.ai/register 注册即用。