三次重写搜索之后，我才明白智能搜索该先解决「接入」而不是「算法」
> 一个面向独立开发者的智能搜索落地复盘：从踩坑的反例出发，讲清楚为什么「先统一模型接入，再谈检索智能」是更稳的路径。
一、先讲我踩过的三个坑
去年我给自己的知识库工具加智能搜索，第一版方案看起来很「标准」：用户输入关键词 → 调用大模型改写查询 → 向量检索 → 拼装结果返回。逻辑没错，但我栽在了几个意想不到的地方。
坑一：模型调用散落在各处。 查询改写用了一家模型，结果摘要用了另一家，错误兜底又临时接了第三家。三个 SDK、三套配置、三份密钥管理逻辑，散在四个文件里。某天其中一家模型悄悄调整了限流策略，我的服务开始随机超时，我花了整整一晚上才定位到是哪个环节在报错。
坑二：一换模型就大面积改代码。 当我发现改写环节用的小模型效果不稳，想换一家试试。结果换模型意味着换 SDK、换参数结构、换错误码处理。换完还要回归测试全部搜索路径。换个模型比写新功能还累，最后我干脆不换了，硬着头皮忍受效果打折。
坑三：成本和用量完全看不清。 月底账单出来了，我不知道哪些调用是查询改写、哪些是结果摘要、哪些是无效的重试。没法归因就没法优化，只能笼统地觉得「AI 有点贵」。
这三个坑的共性是：我把精力全押在了「智能」上，却没给「接入」打好地基。 对独立开发者来说，智能搜索的算法部分其实有大量成熟范式可抄，真正拖垮项目的是接入层的维护成本。
二、业务痛点重新梳理
复盘之后，我把痛点重新排序：
- 多环节、多模型的必然性：查询改写要快和便宜，语义摘要要质量，这天然指向不同模型，无法「一个模型打天下」。
- 模型市场的快速变化：新模型每季度都在出现，价格和效果持续洗牌，应用层不该被任何一家绑定。
- 一人团队的精力约束：没有专门的基建同学，任何接入层的重复劳动都会直接挤占产品迭代时间。
- 可观测性缺失：不知道每个环节的调用量、延迟、失败率，就无法判断搜索体验的瓶颈在哪。
三、正确的架构：先做统一接入层
调整后的架构分成清晰的三层：
┌─────────────────────────────────────┐
│ 应用层：搜索业务逻辑 │
│ 查询改写 / 向量检索 / 结果摘要 / 兜底 │
├─────────────────────────────────────┤
│ 统一 AI API 网关（关键） │
│ · 统一 OpenAI 兼容协议 │
│ · 多模型路由与降级 │
│ · 密钥集中管理 │
│ · 用量与成本归因 │
├─────────────────────────────────────┤
│ 模型层：各厂商模型 + 自部署小模型 │
└─────────────────────────────────────┘核心原则：应用代码只认识一种协议、一个入口。 模型的差异、切换、重试、降级，全部收敛到网关层解决。
为什么统一网关能实实在在降低维护成本
这是我体会最深的一点，具体体现在四个方面：
- 协议统一：所有模型走同一套 OpenAI 兼容格式，业务代码里只有一种请求结构。换模型时改一个模型名参数，而不是重写一段集成代码。
- 密钥收敛：各厂商密钥只配置在网关侧，不进代码仓库、不进环境变量散布的各个服务。泄露风险面大幅缩小，轮换密钥也是一处操作。
- 降级内建：网关层配置「主模型失败自动切备用模型」，应用代码不用为每家模型单独写重试和超时逻辑。我坑一里那个「随机超时排查一晚」的问题，在这个模式下就是一次自动切换加一条告警。
- 成本可归因：按调用来源、模型、功能模块记录用量，月底能清楚看到「查询改写占 30%、摘要占 55%、重试浪费 15%」，优化有了靶子。
对独立开发者来说，这四点的本质是同一件事：把 N 份接入代码变成 1 份，把 N 处运维变成 1 处。 人越少，越需要这种收敛。
四、关键实现步骤
按这个顺序做，每一步都可独立验证：
1. 梳理搜索链路环节
□ 查询改写（要求：延迟低、便宜）
□ 向量检索（本地或托管向量库，与模型解耦）
□ 结果摘要（要求：质量优先）
□ 无结果兜底（要求：可降级到关键词搜索）
2. 搭建统一接入层
□ 注册统一 AI API 网关，获得单一入口地址和网关密钥
□ 为每个环节指定模型，全部走 OpenAI 兼容协议
□ 配置降级链：主模型 → 备用模型 → 关键词兜底
3. 应用层改造（伪代码）
const rewrite = await ai.chat({
model: "gateway:rewrite-model",
messages: [{ role: "user", content: rewritePrompt }],
tag: "query-rewrite" // 用于成本归因
});
const results = await vectorSearch(rewrite.text);
const summary = await ai.chat({
model: "gateway:summary-model",
messages: buildSummaryPrompt(results),
tag: "result-summary"
});
4. 验证与观测
□ 压测各环节延迟，确认改写环节 P95 < 800ms
□ 检查网关侧用量报表，确认 tag 归因正确
□ 手动触发主模型故障，验证自动降级生效注意第 3 步里的 tag 字段：这是成本归因的钩子，加的成本几乎为零，但月底复盘时价值巨大。
五、改造后的实际变化
重构后，我的搜索服务代码量减少了约三成（删掉的都是各家 SDK 的适配和重试逻辑）。后来有一次想测试新出的模型，我只改了网关配置里的模型名，全程没碰一行业务代码，十分钟后就拿到了对比数据——放在以前，这至少是半天的改造加回归。
更重要的是心态变化：当接入成本趋近于零，「尝试新模型」从一件需要下决心的事，变成了随手可做的实验。对独立开发者来说，这种试错自由度往往才是产品迭代的真正加速器。
六、小结
智能搜索落地的顺序，不是先把算法做酷，而是先把接入做稳。统一 AI API 网关把模型差异、密钥管理、降级容错、成本归因这四件维护负担最重的事收敛到一处，让一个人的团队也能拥有像样的模型治理能力。
如果你也准备给自己的产品加上智能搜索（或任何多模型 AI 功能），不妨从统一接入开始。可以在 https://api.thistoken.ai/register 注册一个网关账号，把多模型调用收敛到一个入口试试，先把地基打好，再谈智能。
---
不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。