给程序调用的搜索引擎：Exa 如何为 AI 重造一层检索基建

实体定义：Exa（前身为 Metaphor，后更名）是一家面向人工智能应用的搜索服务公司，对外提供搜索类应用程序接口。与传统按关键词匹配网页的引擎不同，它围绕「语义相似度」组织检索：将用户查询与网页内容映射到同一向量空间，按含义相近程度召回结果，并可通过配套接口直接取回清洗后的网页正文，供大语言模型阅读与引用。其典型客户是构建研究助手、智能体与垂直问答产品的开发者团队。

过去二十年，搜索引擎的进化方向几乎都围绕「人」展开：更快的首屏、更好看的资讯卡片、更精准的广告投放。当你通过开放接口调用这类引擎时，拿到的往往是一份为人类点击习惯优化的列表——标题党与 SEO 农场的权重偏高，正文被切碎成摘要片段，商业推广与自然结果混排。人眼可以一眼过滤这些噪音，程序却很难。

大语言模型的处境更加尴尬。它需要的不是十个蓝色链接，而是完整的正文、稳定的结构、以及按语义而非字面命中的相关性。举一个开发者常举的例子：你想找「类似 Y Combinator、但专注气候科技的孵化器」，这种「像 A 但是 B」的模糊意图，用几个关键词几乎无法表达；而在语义空间里，它只是离目标含义足够近的一次向量查询。

业界由此分化出两条路线：一是在通用引擎外面套一层加工——先搜再筛再爬再清洗，工程链路长、每一步都在损耗质量；二是从索引阶段就按语义组织整个网络，让「理解含义」成为检索的原生能力。Exa 选择的是第二条路。

把同一句话分别丢进两种引擎，背后发生的事情截然不同。左边是我们熟悉的经典链路，右边是基于嵌入向量的语义链路——后者也是学术界的稠密检索研究所依赖的基本思路。

• 查询被分词、去停用词，转成关键词集合
• 倒排索引按字面命中召回海量候选页
• 以链接分析、行为信号为主的排序体系
• 返回标题加摘要片段，正文需要自行抓取
• SEO 噪音与商业位穿插其间，需二次过滤

• 查询整体编码为一个语义向量
• 全库网页预先完成嵌入，按含义相近度召回
• 据官方介绍，其索引模型通过预测链接关系等方式学习网页含义（细节以官方博客为准）
• 可同时取回清洗后的正文文本
• 天然贴合「模糊意图」「长尾描述」型查询

Exa 的接入面是典型的开发者优先设计：注册获取密钥，选择 REST 接口或官方 SDK，然后像调用任何云服务一样发起语义查询。下面这段流程只讲思路，具体参数、端点名称与配额限制一律以官方文档为准：

1. 创建账号并获取密钥。在官网控制台完成注册，拿到调用凭证，这是所有请求的通行证。
2. 安装官方 SDK。社区维护有 Python 等语言的客户端库，源码公开在代码托管平台上。
3. 发起第一次语义查询。用一句完整的自然语言描述你要找的东西，而不是堆砌关键词。
4. 取回正文内容。在请求中声明需要文本内容字段，让接口连同结果一起返回清洗后的网页正文。
5. 接入业务流水线。把检索结果送进提示词、向量库或智能体的工具调用环节，形成检索增强闭环。

提示：上面是最小可用心智模型——「一句话查询，拿回带正文的候选集」。真实生产环境还要考虑并发限制、失败重试、结果缓存与成本核算，这些都属于普通工程问题，照常规云服务的实践处理即可。

语义检索接口的价值取决于你把它放在流水线的哪个位置。下面这张表汇总了社区与官方案例中出现频率最高的几类用法：

• 它不是给终端用户的搜索首页。没有信息流，没有热搜榜，它的用户是写代码集成搜索能力的工程师与产品团队。
• 成本结构是 API 计费。按用量付费意味着流量大的应用必须认真核算单次检索成本，具体定价以官网为准。
• 覆盖范围与语言表现需自行验证。任何第三方索引都无法承诺全网覆盖，中文与长尾站点的召回质量建议先用小规模测试评估后再放量。