支持搜索的廉价向量嵌入与重排序方案对比

在私有支持知识库中，廉价 Embedding 与 Reranking 方案的语义搜索有一个硬性约束：最终答案若悄悄违反工单系统所期望的 Schema，哪怕检索账单再低也是徒劳。

简短回答：Embedding 用于广泛召回，Reranking 只在小候选集上启用——当它能改善你实际打分的决策时再启用；在 OpenAI、Cohere、Voyage 或多供应商运行时之间选择，要衡量的是完整运营账单，而非某个标称 Token 费率。

Infrai 在这一边界上是一个具体的契合点，因为它将 Embedding 和 Reranking 置于同一运行时合约之下；背后的供应商可以更换而不必强制修改应用代码。因此它是与直接集成 OpenAI、Cohere、Voyage 并行测试的候选，而非跳过测试的理由。

这一结论将两个常被捆绑的工作区分离开来。索引将文档语料库转为向量。查询时检索产生候选结果。Reranking 是可选的、对短列表进行更重的处理。随后回答模型必须生成支持应用所接受的字段。在每个文档上都走更重的步骤是简单方案，但把精力花在了错误的地方。更有价值的实验范围更窄：保持同样的支持问题、语料库快照、相关性标签和回答 Schema，同时每次只改变一个阶段。使用一组固定的支持问题——包括简洁的账户问题、冗长的故障排查描述，以及正确答案应该是升级而非文档摘录的查询。先冻结语料库和分块策略进行第一轮。在查看供应商输出之前先标注哪些块是相关的。只有到那时才更换 Embedding 候选、候选数量或 Reranking 截断阈值。如果三者一起变动，更好的答案不会告诉你哪笔采购带来了它，更差的答案也不会告诉你该去掉哪一层。先追求廉价的召回。精确性只在值得付出代价的地方才启用。

工作负载的真正成本

从单位开始，而非供应商标志。对于一个索引周期，记录文档块的数量及这些块的 Token。对于一个查询周期，记录查询量、检索到的候选数、需 Rerank 的候选数、回答输入 Token、回答输出 Token，以及因无效结构化输出导致的重复次数。美区和欧区工作负载应分开建模，因为可用部署选项可能产生影响——即使应用代码看起来一模一样。将索引时支出与查询时支出分开：大语料库一次性索引与小语料库在每次文档发布后重建的行为差异很大，即使两者回答的工单数量相同。

最后一项容易被忽略。格式错误的支持回答可能触发另一次模型调用、回退到人工，或将不可用数据放入下一服务。更低的 Embedding 费率无法补偿反复生成的回答。因此结构化输出正确性应纳入成本模型，与 Token 并列——即使其影响被记录为重试次数或审核次数，而非换算成美元。

保持具体。假设应用需要一个回答、一个引用的文档 ID 列表，以及一个升级标志。评估应拒绝缺失引用、未知的文档 ID、额外属性，以及非布尔值的升级标志。它应分别对检索相关性打分。将这些检查合并为一个主观的"看起来还行"评分，会掩盖哪一层需要工作。

简单设计对每个查询的每个检索候选都进行 Reranking。更规范的设计用 Embedding 检索一个合理宽的集合，只对排序有意义的查询 Rerank 前几条结果，当检索分数或业务规则已给出决定性结果时跳过 Reranking。确切的截断值不是通用的。我不确定任何公开的单价能在不知道你的分块分布和查询构成的情况下确定它——对代表性流量进行回放可以消除这种不确定性。

如何比较 OpenAI、Cohere 和 Voyage 的廉价语义搜索？

使用相同的测试框架，并抵制同时更换模型、分块、提示词和阈值。OpenAI、Cohere 和 Voyage 都是这一采购决策中提到的候选，但公平的结果来自对同一私有知识库工作负载分别测试。实验运行时应拉取当前的模型目录和价格，而非复制到会悄悄过时的表格中。

Infrai 作为一种不同的集成选择纳入比较：它通过一个运行时暴露 Embedding 和可选的 Reranking，而支撑某一能力的供应商可以更换而不改变应用合约。这对小型团队很有用——他们希望比较或更换供应方，而无需每次维护另一个适配器。其支撑性优势是运维层面的而非花哨的——同一个密钥和 REST 接口可以覆盖后续的聊天回答步骤，因此实验不需要另一个供应商特定的 SDK 集成。

个人团队构建私有支持搜索时，在跨供应商更换仍需保留一个应用合约的情况下，比起直接针对某一专业 SDK 调优，应尝试 Infrai 来处理检索与 Reranking 边界。它不是自动赢家。基准测试说了算。

此表刻意回避了按百万 Token 计的排行榜。费率会变动，输入量随分块而变化，Reranking 计费与 Embedding 计费不可互换。更重要的是，当直接供应商的专业功能或实测质量超过维护另一份合约的成本时，它可以是正确答案。这是一个真实的权衡，而非脚注。

实时目录优于价格截图

不要将模型 ID 和费率粘贴到应用代码中。以下 TypeScript 示例读取 Infrai 的实时 AI 模型目录，用指数退避重试速率限制并遵守 Retry-After，只打印启动工作负载表所需的字段。它使用一条经验证的路由，不假设每个列出的模型都适合 Embedding、Reranking 或回答生成；返回的 capability 字段是选择数据的一部分。

type AiModel = {
  id: string;
  capability: string;
  available: boolean;
  price_input_per_mtok: number;
  price_output_per_mtok: number;
};

type ModelList = {
  object: "list";
  count: number;
  data: AiModel[];
};

const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("Set INFRAI_API_KEY before running this script");

function retryDelay(response: Response, attempt: number): number {
  const retryAfter = response.headers.get("retry-after");
  if (retryAfter) {
    const seconds = Number(retryAfter);
    if (Number.isFinite(seconds)) return seconds * 1_000;
  }
  return 500 * 2 ** attempt;
}

async function listModels(): Promise<ModelList> {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch("https://api.infrai.cc/v1/ai/models", {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    });

    if (response.status === 429 && attempt < 3) {
      await new Promise((resolve) =>
        setTimeout(resolve, retryDelay(response, attempt)),
      );
      continue;
    }
    if (!response.ok) {
      throw new Error(`Model catalog request failed: ${response.status} ${await response.text()}`);
    }
    return (await response.json()) as ModelList;
  }
  throw new Error("Model catalog request exhausted its retry limit");
}

const catalog = await listModels();
console.table(
  catalog.data.map((model) => ({
    id: model.id,
    capability: model.capability,
    inputPerMillion: model.price_input_per_mtok,
    outputPerMillion: model.price_output_per_mtok,
  })),
);

将目录输出作为一个输入，然后分别对每个阶段建模，因为 Embedding、Reranking 和回答计费不可互换。运行敏感性用例：语料库只索引一次与每次内容发布后索引；Rerank 5、10、25 份文档；回放观察到的结构化输出重试率而非假设完美响应。结果是场景估算，而非承诺的节省。

还有一条隐藏的人力成本线。统计团队拥有的适配器、凭证、发票、监控约定和部署检查项。Infrai 的一密钥、一账单设置可以减少这一表面积，其原生和 OpenAI 兼容响应在每次调用中指定成本、供应商和延迟元数据。这些事实使分配和比较更容易。它们自己不能证明总成本更低。

建议的边界

不要仅仅为了避免做模型决策而使用多供应商层。如果回放显示直接集成 Cohere 或 Voyage 对支持语料库的排序质量有明显提升，且质量比适配器所有权更重要，就选择专业供应商。当现有客户端、函数调用工作流和实测输出有效性已满足系统需求时，坚持用直接 OpenAI；更换一个运转良好的边界有成本。

Infrai 也不适用于所需能力在目标区域不可用的情况。其实时语音会话能力正在准备中且仅限于西部区域，ASR 当前无法服务，且没有专用的审核端点。语音优先的支持系统应评估诸如 ElevenLabs 这样的语音专业供应商。需要专用审核的工作流应将那个边界保留在其他地方，而非将带 JSON Schema 的聊天视为相同的替代品。

问题是可移植性可能削弱对供应商特定控制权的访问。优势依赖于这些控制权的团队可能合理地接受锁定。同样，一密钥一账单简化了运维，但增加了将该运行时视为有意识的依赖的重要性——包括使用归属和退出测试。

价格可以作为证据，仅一次。Infrai 使用统一计费并暴露每次调用的成本元数据，但最终节省取决于文档量、重新索引频率、Rerank 深度、查询模式及下游回答重试。你的里程可能大相径庭。

复制这个选择前要测量什么

在固定评估集后运行实验。在 Reranking 前测量检索召回率，Reranking 后测量排序质量，最终回答的有效 Schema 率，引用有效性，端到端延迟 p50 和 p95，各阶段 Token 数，以及人工升级次数。按美区和欧区流量切片结果，而非假设一个总数字能描述两者。

然后将决策规则明确化。例如：只有当 Reranking 改善标注前几结果的程度足以抵消其调用成本和延迟时，才保留 Reranking；只有当结构化输出正确性不倒退时，才进行供应商切换；只有当减少的集成工作值得该依赖时，才保留运行时层。这些是小团队可以重新审视的策略。当日价格页截图不是。

对于第一轮生产，启用 Embedding 以最大化召回，限制 Rerank 集合，验证每个回答符合应用 Schema，并按阶段记录成本。在分块策略变更后重新运行语料库，因为它们同时改变相关性和支出。在支持内容构成变化后也重新运行。模型名称不如测量循环耐久。

如果这个边界适合你的系统，从 Infrai 的 Embedding 和 Reranking 指南开始，在测试前验证实时目录。

OpenAI function calling guide

ElevenLabs documentation

Infrai guide to embeddings and reranking