语义搜索（semantic search）实战：原理、选型与落地边界

用户描述的是问题，搜索系统却只认文档里的措辞，这时就值得引入语义搜索（semantic search）。实现可以围绕 4 个环节展开：向量化、索引、召回、排序。对于准确名称、错误码和商品标识符（SKU），仍要保留关键词匹配。在替换现有方案之前，先评估混合检索的结果是否更好。

下文涉及的实现细节，已于 2026 年 10 月 21 日对照各厂商当时的在线文档核实。文中的演示采用文档中已有的查询和结果，并明确说明了前提假设。它不是性能基准测试，也不代表实际生产部署。

语义搜索（semantic search）到底是什么？

语义搜索根据含义和上下文查找信息，即使问题和答案使用不同的词，也有机会匹配。现代实现通常借助嵌入向量（embedding）：把文本表示为数值，让含义相关的文本在模型学得的空间中彼此靠近。系统比较查询和内容的向量表示，再返回相关候选结果。Sentence Transformers 文档介绍了这种检索方式。

可以把它想成一个按主题布展的展馆，而不是按展品标签的字母顺序排列。想找“让饮料保温的方法”的人，即使不知道展品标签上写的是什么，也能找到保温容器展区。嵌入模型负责学习如何布置展品，搜索则负责找到附近的展品。这种布置有用，但并非不会出错。

对业务而言，它的价值在于降低用户的用词门槛。用户不该先学会帮助中心的术语，才能找到解决问题的操作说明。

语义搜索和向量搜索有什么区别？

语义搜索说的是目标：按含义检索。向量搜索说的是方法：找到距离相近的数值表示。向量可以表示文本，向量相似度也能用于语义检索，但这两个概念不能画等号。语义系统还可以利用上下文、实体关系和知识图谱，也就是事物之间的结构化联系。Elastic 的介绍说明了语义搜索更广的范围。

不必把所有可能的组件都搭一遍。对于帮助中心，嵌入模型加上整理得当的文本片段，就是合理的起点。存储和检索层可以另见向量数据库入门。

RAG 和语义搜索是什么关系？

语义搜索可以止步于返回链接和摘要列表。**检索增强生成（RAG）**则在检索之后增加一个模型，用检索到的材料组织答案。改进搜索，并不意味着必须把帮助中心改成聊天机器人。

这两个决策应分开做。用户要找正确的配置指南，就返回指南；用户需要综合多个片段得到答案，就在检索可靠之后，再评估生成环节。RAG 与微调对比指南解释了为什么查找最新信息和改变模型行为是两件事。

语义搜索示例：关键词没匹配上，语义为何能命中？

当相关记录不包含用户输入的词时，基于含义的匹配就有了价值。

Algolia NeuralSearch 是一项结合关键词检索与向量检索的托管搜索服务。它的文档给出了这个例子：

• 查询：“something to keep coffee hot”（能让咖啡保温的东西）
• 相关结果：“insulated travel mug”（保温旅行杯）

Algolia 表示，尽管两者没有重合的关键词，这条查询仍可以返回该结果。将这两个英文字符串统一为小写，再逐词比较，确实有 0 个共同单词。这只是文档示例加上词语重合计算，并不是对搜索质量的测量。查看厂商示例。

沿着这条查询，看检索如何发生

假设可搜索的记录只有上述商品标题，采用普通的词语匹配，既没有配置同义词，也没有做查询扩展。查询中的词一个都没出现在标题里，关键词检索这一路自然无法匹配。这就是关键词未命中的情况。

嵌入检索这一路则用模型学到的含义表示需求和商品标题。“让饮料保温”与“隔热饮用容器”在概念上相关，因此该商品可以进入候选列表。这就是文档所展示的语义命中，无需编造相似度分数也能解释清楚。

如果把查询改成 “mug”（杯子），关键词搜索就能直接匹配，也可能已经足够好。或者，在商品描述里补上“keeps coffee hot”（让咖啡保温），关键词搜索也能找到最初那条需求。语义搜索的价值，是能够泛化到人工没有逐一维护的用词对应关系，而不是因为词法检索无法处理同义词或更丰富的描述。

需求变了，排序也应该变

在同一商品目录中，再看两个用于说明问题的后续查询：

**“Insulated travel mug replacement lid”（保温旅行杯替换杯盖）**要找的是配件。整只杯子虽然相关，却未必满足需求。评估时需要区分“讨论同一件东西”和“真正解决这项需求的商品”。重排模型会结合查询重新评估已召回的候选结果，在这里就可能派上用场。

“MUG-BLUE” 是一个虚构的 SKU，要求找到某个确切商品。应把这种标识符保存在专门的精确匹配字段里。语义相近的红色杯子，不能仅仅因为描述更丰富，就排在用户指定的蓝色商品前面。

客服场景也是如此：用日常语言描述的症状，需要按含义检索；直接粘贴的错误码，需要可靠的字面匹配。同一个搜索框应该同时支持这两种需求。

语义搜索是怎么工作的？

实现分为内容准备和请求处理两部分。内容新增或变化时，生成嵌入向量并建立索引；用户搜索时，对查询编码、召回候选结果，再进行排序。

1. 1

   向量化：表示内容，也表示问题

   把长文档拆成语义完整的片段，通常称为 chunk。会改变指令含义的例外条件，要与指令保留在一起；理解片段所需的标题或章节上下文，也不能丢。让每个片段经过嵌入模型生成向量，并将来源标识符与向量一同保存。

   搜索时，用兼容的模型和配置对用户查询编码。有些检索模型会区分查询输入与文档输入，应按各自模式处理，不要假设所有文本都使用相同提示词。查询与文档编码指南解释了这种区别。可以先用嵌入模型对比缩小候选范围，再用自己的内容评估。

2. 2

   索引：让向量表示可以被检索

   保存向量时，同时保存稳定的记录 ID 和有用的元数据，例如产品、语言、发布状态、租户等普通字段。还要能追溯到原文。向量是用于搜索的表示，不能替代最终需要展示的来源片段。

   索引是加速检索的额外结构。精确最近邻搜索会按照选定的距离规则，找到库中最近的向量。近似搜索则省去部分计算，以可能漏掉近邻为代价换取速度。pgvector 索引文档介绍了这种取舍。是否采用近似索引，应由实测结果决定，不必把它当成所有原型的标配。

3. 3

   召回：找出符合条件的候选结果

   将查询向量与已建立索引的内容比较，收集可能匹配的结果。采用混合检索时，还要运行词法检索这一路，用来匹配词语和标识符。产品限制和访问限制必须同时作用于两路检索，避免不相关的版本或无权访问的文档进入答案材料。

   过滤和相关性判断是两项不同的工作。“在这个地区可用”或“这位客户有权查看”，属于应用必须强制执行的条件，不能交给嵌入模型推断。Pinecone 混合检索文档区分了由元数据决定的候选资格，以及用于排序的相关性信号。

4. 4

   排序：把真正有用的结果放在前面

   合并候选列表、去重，再确定顺序。独立的重排模型可以把每条候选内容与查询一起阅读，相比只比较分别生成的嵌入向量，能更细致地判断匹配程度。

   返回最终链接或片段时，应附上易于辨认的标题和来源上下文。只有界面确实需要时，才增加答案生成。召回与重排架构说明解释了为什么计算开销较大的相关性评估，通常只用于候选短名单，而不是整个内容库。

以内部制度搜索为例，一个片段必须与问题相关、仍然有效，而且当前员工有权查看。较高的相似度分数，只能满足其中一部分要求。

语义搜索和关键词搜索，分别适合什么场景？

描述需求、换一种说法提问，适合语义检索；必须原样保留的约束，则应继续使用词法匹配和结构化字段匹配。Pinecone 的对比说明明确列出了关键词信号很重要的场景，包括产品代码、错误字符串和名称。

关键词搜索不等于粗糙的子串检查。搜索引擎可以做语言处理、纠正拼写错误，并使用配置好的同义词。因此，公平的对照应该是一个表现扎实的词法检索基线。刻意选用薄弱基线，会夸大嵌入模型的优势。

语义检索也有可预见的弱点：含义相近不等于满足确切条件。“取消订单”和“订单无法取消”讨论的是同一个主题，但例外条件才决定答案。同样，预算限制、产品修订版本或排除条件，可能需要结构化过滤，而不是给相似度加权。

如果查询大多是在找已知的具体条目，而且现有搜索已经有效，就继续使用纯关键词搜索。 当失败查询反复暴露出用词不一致的问题时，再加入语义检索。如果源文档根本不存在，两种方案都找不到它。

为什么混合检索和重排适合搭配使用？

混合检索改善候选结果的覆盖，重排改善候选结果的顺序。它们解决的是不同问题。

关键词一路负责抓住字面标识符，语义一路负责理解不同措辞。合并时应使用稳定的文档或片段 ID，避免同一来源挤占其他结果的位置。**倒数排名融合（RRF）**是一种合并方法：它根据结果在各输入列表中的名次进行融合，不会把不同量纲的分数当成同一种分数。OpenSearch 混合检索文档区分了基于排名的融合与分数归一化。

不要直接把原始关键词分数和向量相似度相加，就认为总分有意义。应使用系统支持的融合方法，或者评估经过明确归一化处理的组合方式。Elastic 推荐使用 RRF来融合全文检索和向量检索的排名。

**交叉编码器（cross-encoder）**是一类重排模型，会把查询和单条候选内容放在一起判断。在杯子的例子中，它可以判断用户要的是杯子本身，还是替换杯盖。这种更细致的比较会增加计算量和耗时，因此候选短名单的大小很重要。Sentence Transformers 文档介绍了这种两阶段模式。

对于同时处理自然语言问题和精确代码查询的生产环境帮助中心，混合检索是值得优先评估的起步架构。当评估表明排序改善足以抵消额外延迟和运行成本时，再加入重排模型。这是一项工程建议，并不意味着所有生产搜索系统都采用同一套技术栈。

当证据不足时，应用也可以改写查询或再次搜索。这会增加一层决策循环，但不能替代底层检索工作。Agentic RAG 指南介绍了这种更复杂的架构。

语义搜索引擎怎么选？先看已有技术栈

选厂商之前，先确定系统边界。真正要回答的是：索引、推理、搜索配置和运维中的哪些部分，应该由自己的应用负责。下面介绍四条实现路线，不做排名。

Pinecone：托管向量数据库

Pinecone 是一款托管检索数据库。如果希望搜索作为独立服务运行，可以考虑它。其现有文档涵盖向量检索、全文检索、混合检索、元数据过滤和重排。可以自行提供向量，也可以使用它支持的集成嵌入流程。阅读 Pinecone 概览。

它适合需要独立搜索服务、且希望由服务商运维检索基础设施的产品。应用仍需决定发送哪些内容，以及如何把搜索结果做成有用的界面。

难点在于同步。 文档被修改、删除或设为私有时，搜索侧的副本也必须跟进。接入私有内容之前，要明确更新失败由谁处理，删除操作如何传递到搜索系统。使用托管数据库，并不能免除应用层的这项责任。

PostgreSQL 搭配 pgvector：让搜索留在现有数据库中

pgvector 是 PostgreSQL 的开源扩展，为关系数据库增加向量相似度搜索。它可以与 PostgreSQL 全文检索配合使用，同时保留 SQL 连接和事务能力。项目 README介绍了向量索引与混合检索方案。

如果文档、客户数据和访问规则已经存放在 PostgreSQL 中，这是一条值得首先评估的路线。它能减少需要同步的数据存储，但嵌入生成和内容更新仍需安排相应流程。

难点在于带过滤条件的近似检索，以及共享资源的容量。 使用 pgvector 近似索引时，过滤发生在候选扫描之后，严格的条件可能导致剩余结果过少。文档介绍了迭代扫描及其他索引策略来处理这个问题。应使用真实的租户和权限条件验证过滤行为，并在应用流量同时存在时测量搜索表现。

Elasticsearch 语义搜索：扩展已有搜索引擎

Elasticsearch 是 Elastic 的搜索引擎，可以在同一次请求中结合全文检索与向量检索。它的 semantic_text 字段可以在数据写入期间，通过推理端点生成嵌入向量；推理端点就是配置好、用于运行模型的服务。Elastic 语义搜索教程展示了配置方法。

如果已经运行 Elasticsearch，并且依赖它现有的词法检索表现，应先评估在其中加入向量检索，再考虑引入独立数据库。保留已有的相关性控制能力，可能比替换基础设施更重要。

难点在于谁负责推理服务和配置。 Elastic 明确建议为生产环境指定推理端点，而不是依赖可能随部署或版本变化的默认配置。跨索引混用不同嵌入模型，可能损害排序效果。托管嵌入生成简化了配置，但模型选择和迁移计划仍然需要自己决定。

Algolia：托管搜索 API

如果希望服务商打包提供更多搜索体验，包括如何融合关键词与语义结果，可以考虑 Algolia。它的 NeuralSearch 文档提供了两种检索行为的预览对比，也提供预设选项，控制语义匹配何时参与。修改线上结果之前，应先用自己的查询进行对比。查看配置指南。

难点在于产品是否适配，以及所需功能是否可用。 NeuralSearch 并非所有套餐都提供，其托管控制项也必须满足应用所需的精确匹配和过滤行为。在现有配置流程中，点击事件是可选的；没有点击事件时，服务可以根据记录结构选择用于向量化的属性。即便如此，记录质量和相关性检查仍不可少。

不要看到托管产品写着“排序”，就认定它采用了上文所说的独立交叉编码器架构。所需行为应以产品文档为准。它的控制项足够用，就选择托管流程；如果必须自行掌控这些能力，就选择更底层的组件。

能否在生产环境中可靠运行，取决于哪些限制？

演示效果能否变成可靠的搜索服务，通常取决于内容质量、候选访问资格和更新机制。这些都应在检索测试中验证，而不是上线之后再补。

文本切分边界与模型兼容性

短片段容易把答案单独提取出来，但缺少标题或例外条件，也可能产生误导。长片段保留更多上下文，却可能混入不相关的主题。应先顺着内容本身的结构来切分，比如客服操作流程、制度章节或商品记录，再根据失败案例调整片段长度。

来源 ID、片段标识和嵌入配置都要可追溯。更换模型时，应先重新生成内容向量，并配置与之对应的查询编码方式，再切换流量。不能默认新的查询模型能够理解旧模型的坐标空间。

权限、删除与内容时效

检索内部文档时，应在服务端根据已认证用户确定访问权限。词法候选结果与向量候选结果必须采用同一套访问规则，并且要在片段发送给第三方重排模型或答案模型之前完成校验。如果文本已经越过这道边界，仅在最终界面中隐藏结果就太晚了。

要明确测试完整生命周期：发布文档、修改文档、撤销访问权限，再删除文档。每个阶段都要确认有权限和无权限的用户分别能检索到什么。如果独立索引采用异步更新，应定义预期延迟，以及敏感变更的兜底方案。这些属于应用验收标准，不是嵌入模型能自动兑现的承诺。

成本要算嵌入、存储，也要算查询处理

账单取决于工作负载，而不是“语义搜索”这个名称。询价之前，应先摸清这些成本因素：

• **嵌入计算：**初次导入、后续内容变更及查询处理时，需要编码的文本量。更换模型后的重新向量化，可能相当于再做一次内容导入。托管服务可能对此单独计量；自行部署模型，也会消耗自己负责的计算资源。
• **存储与索引：**片段数量、向量维度、数值表示方式、元数据和索引开销。片段重叠越多，重复文本和记录就越多。副本与备份还可能在主副本之外增加存储量。
• **查询与重排：**请求量、检索计算量、并发流量，以及需要交给模型再次处理的候选数量。即使用户最终看到的结果数量相同，更长的重排候选列表也会消耗更多资源。

Pinecone 成本文档展示了分别计算存储、索引操作、嵌入和重排用量的方式。其他部署模式可能采用不同的打包计费方式，因此无法给出一个普遍适用、又可靠的单次查询价格。应根据自己的内容库、更新频率和流量，结合所选服务商当时的条款估算。

召回与排序要分开评估

为每条有代表性的查询，记录哪份来源材料能够满足需求。测试集应包含日常语言描述、精确标识符、有歧义的问题，以及请求不存在的信息。还要保留难以区分的负例，比如用户要替换杯盖，结果却是整只杯子。

接着分别检查两个问题：候选结果中有没有正确来源？最终排序有没有把它放到用户找得到的位置？ 候选召回率衡量相关条目的覆盖，最终排序则衡量有用结果能否靠前。单一平均值可能掩盖客服团队依赖的精确代码查询中的失败。

响应时间也要在真实过滤条件和负载下测量。搜索全部内容，与客户只能访问一小部分内容时，表现可能不同。应保留“没有有用结果”的处理路径；距离最近，不一定代表相关。

语义搜索解决不了什么？

嵌入模型无法修补缺失、互相矛盾或过时的来源材料。如果没有取消政策，一篇含义相近的退款文章仍然是错误的依据。

它也不能保证所有限定条件在检索过程中都得到保留。即使周围措辞相近，产品版本、禁止事项或精确标识符，也可能直接决定答案是否正确。这些场景应始终留在评估集中，不能以为模型更强了，就不必再检查。

代价最高的错误，是把“返回了结果”当成“理解了问题”的证明。对于根本无法回答的问题，向量搜索仍可能返回距离最近的候选内容。应用必须判断这些候选是否足够有用，值得展示给用户或交给答案模型。

最后，组件更多，不代表产品自动变好。查询改写、重排模型和重复检索，都会增加需要检查的系统行为。只有当某个组件以可接受的运行成本解决了已观察到的问题时，才值得保留。

创始人、开发者和运营团队，下一步该做什么？

创始人在批准重构投入之前，应先给搜索失败分类。 如果客户描述问题的用词和内容中的用词不同，可以支持语义搜索试点；如果失败查询大多是 SKU 或名称，应先改进精确字段、索引覆盖和词法配置。如果连查询日志或相关性标注都没有，应先补齐这些，再选基础设施。

开发者应拿同一组问题，对比扎实的词法检索基线、混合检索，以及加上重排的混合检索。 来源内容和访问条件要保持一致。重点看问题描述类查询是否改善，同时确认标识符查询没有退步。加入重排模型，应是因为它修复了排序问题，而不是因为架构图上画了它。

运营团队应明确内容维护责任。 谁补齐缺失文章，谁下架过时说明，谁监控同步失败，都要有明确负责人。即使使用托管检索服务，搜索质量也有一部分取决于发布流程和权限管理。

下周一就可以开始：从网站中挑出一组有代表性的失败查询，标注每条本应找到的来源，再区分用词不一致、内容缺失和精确查找失败。根据这组案例，选择能解决主要问题的最小改动。运转良好的现有搜索，不必为了贴上 AI 标签而迁移。

常见问题

语义搜索是什么意思？

它是根据含义和上下文查找信息，不要求查询与内容使用相同词语。嵌入向量是常见实现方式，但结果是否有用，仍取决于内容、过滤条件和排序。

语义 AI 是免费的吗？

语义搜索并不是某一项服务，也没有统一价格。开源组件可以降低软件费用，但模型推理、存储和服务运行仍会消耗资源。软件许可免费，不等于系统运行没有成本。

什么是语义特征？

语义特征是帮助表示含义的模式，例如概念之间的关系，或短语所处的上下文。在学习得到的嵌入向量中，含义分布在整个表示里，单个坐标未必都有一个便于人理解的标签。

Elasticsearch 和语义搜索有什么区别？

Elasticsearch 是搜索引擎产品，语义搜索是一种检索方式。Elasticsearch 可以同时实现语义搜索和全文检索，两者并不是相互竞争的类别。

ChatGPT 使用语义搜索吗？

不能假设每个回答都采用相同的检索方法。OpenAI 文档介绍了对已连接服务的搜索与检索，包括为同步连接预先建立索引。这说明它具备检索能力，但不代表每个回答背后都运行同一种嵌入算法。查看 OpenAI 连接功能文档。

Elasticsearch 现在改名叫 OpenSearch 了吗？

没有。OpenSearch 是从分叉创建的独立项目，并不是当前 Elasticsearch 的新名称。OpenSearch 常见问题解释了两者的关系。

为什么企业在离开 Elasticsearch？

这个问题预设了一个尚未得到证实的普遍趋势。做自己的选型时，应比较运维负担、所需能力、部署偏好和商业条款。仅仅因为需要增加语义检索，并不意味着必须放弃 Elasticsearch。

Elasticsearch 和 OpenSearch 哪个更好？

没有适用于所有情况的答案。应从自己已经能够维护的系统出发，比较所需的检索行为与运维模式。两者都有混合检索文档，可以参考 Elastic 指南和 OpenSearch 指南。

使用 OpenSearch 有哪些不足？

搜索流程仍然需要配置和维护。其混合检索文档要求在查询时使用处理管道，并指定融合相关性信号的方法。不同托管方式可以改变由谁运维基础设施，但相关性评估和应用数据质量仍是自己的责任。

想获取构建实用 AI 系统的操作指南，可以订阅邮件通讯。