向量搜索 vs 关键词搜索

Scrapeless Google Search API 提供结构化的公开搜索结果，这些结果可以在进入检索集合之前先进行检查和规范化。

比较匹配信号，而不是营销标签

向量搜索和关键词搜索使用不同的信号来对候选记录进行排序。关键词搜索使用词项及其分布等词汇特征。向量搜索使用数值表示，其相似性旨在捕捉由嵌入模型学习到的关系。

《 dense passage retrieval research 》展示了一种基于学习表示的段落检索方法。它的机制不同于精确字符串匹配，但这种差异并不意味着每个语义相似的段落都能回答用户的问题。相关主题仍然可能是错误的信息源。

对于技术知识库，实际问题在于你需要检索容忍哪种类型的不匹配。用户可能在不知道错误名称的情况下描述超时，也可能粘贴一个精确的错误标识符。这是不同的检索任务。围绕查询家族设计搜索路径，而不是假设某一种方法可以取代另一种。

向量与关键词检索一览

比较时应将有用的倾向与保证区分开来。配置、语料结构和查询语言都可能改变任一方法的结果。

两种方法都会返回候选结果，但都不能单独验证某个段落是否支持答案。在排序之后增加证据验证，尤其是在下游模型可能将一段松散相关的文字转化为自信回答时。

为什么精确标识符需要单独处理

标识符通常包含语义模型不应模糊化的差异。产品代码、API 参数或错误字符串可能在文本上只存在很小变化，却指向不同的实体。

检查你的词汇分析规则。标点、大小写归一化和分词方式会影响标识符是否仍然可被搜索。当应用需要时，定义一个用于精确查找的字段。已分析的全文字段和精确标识符字段承担不同的用途。

对于向量检索，直接用标识符查询进行测试。不要假设一个被训练来连接释义的模型一定能可靠地区分每个几乎相同的技术符号。高相似度结果可能属于一个相邻概念，而其故障原因不同。当用户提供精确标识符时，应保留精确查找路径。

支持助手可以先将标识符解析到一个特定记录，然后再从该记录中检索解释性段落。这种设计先在语义排序前收窄范围，也让答案来源的身份更易检查。

为什么释义问题受益于语义候选

当用户和文档用不同措辞表达同一需求时，语义检索很有用。关于页面看起来空白的问题，可能需要一个关于客户端渲染的段落，即便其中的表述不同。

有用的单位是包含解释的段落，而不一定是整个文档。选择能保留相关上下文的分块边界：包含标题、症状以及解释适用条件。过小的分块会丢失限定条件；过大的分块会稀释你所需的字段。

嵌入质量与所选模型及其输入密切相关。保留生成存储向量所用的模型信息，并使用兼容的查询表示。更换嵌入模型应被视为一次需要评估的检索变更，而不是透明的基础设施替换。

语义相似度也可能检索到具有吸引力却具有干扰性的内容。一个描述本地浏览器启动的段落，可能与一个关于远程浏览器连接的问题相似，但其运行边界却不同。在将某段内容作为回答证据之前，请检查该段内容的主题和范围。

混合检索需要排序设计

混合搜索结合了词法候选和向量候选，但合并列表本身并不会自动提升相关性。需要决定候选集合如何生成、合并、去重以及排序。

词法分数和向量分数可能来自不同的量纲和分布。在没有明确定义的校准或排序方法的情况下，应避免直接将它们相加。可以考虑使用基于排序的合并或重新排序阶段，但每种方法都会引入特定行为，必须在你自己的查询上进行测试。

在所有检索路径中一致地使用结构化过滤器。如果词法路径强制限定某个产品版本而向量路径没有这样做，那么合并结果可能会重新引入已被排除的段落。同样的风险也适用于租户边界和文档权限。在广泛合并之后再进行过滤，并不总等同于在候选生成阶段就进行严格限制。

请提供需要从英文翻译成中文的文本。 异构信息检索基准 支持在不同任务之间进行评估。对于本地混合设计，记录哪些查询类别有所提升、哪些有所下降。更高的平均值可能会掩盖在你们客服团队最常使用的那些错误代码上的退步。

将公共发现与您的索引分开

公共网页搜索和私有检索索引承担着不同的职责。搜索服务用于发现信息来源；你的索引用于存储和检索你选择保留的表示形式。

无抓取的 Google 搜索 API 可以提供结构化的公共搜索候选项。选择合适的来源后，在索引之前，将允许的内容与其 URL 和集合上下文一起规范化。 Google 搜索 API 参数和结果模型 属于获取阶段，而向量和关键词排序属于你的检索实现。

不要将片段索引为完整的出版方文档。若你的集合有意存储片段，应明确将这种表示标记为片段，并限制其可支持的论断范围。来源记录应说明观察到了什么以及遗漏了什么。

The 用于 RAG 的实时网络证据路径 为组合获取和检索提供上下文。 无抓取定价 用于发现成本，然后分别考虑索引、嵌入、存储和生成。

在证据到达模型之前应用访问规则

检索结果在进入模型上下文之前，必须满足调用方的访问范围。语义相关性并不授予阅读某段内容的权限。

使用显式文档元数据来进行授权和归属。验证所选存储系统如何应用过滤器，尤其是在涉及近似向量检索时。评估期间同时检查被接受的记录和被排除的记录。在某个问题上得到一个没有明显泄露的结果列表，并不能证明整个过滤器设计是健全的。

删除和修订处理也会影响相关性。如果在其来源被替换后，旧片段仍然可被搜索到，检索器就可能返回不再受支持的历史指令。跟踪哪些片段属于每个来源版本，并定义更新如何移除或取代较早的表述。

对于公共来源获取，请遵守 机器人排除协议 在适用的情况下保持授权独立。可搜索性和公开可见性是收集决策的输入，而不是对所有后续使用的一揽子许可。

构建能够揭示权衡取舍的评估集

一个有用的评估集应包含词汇检索和语义检索应表现不同的情形。先从真实的用户问题和预期的支持性段落开始，然后再加入刻意设计的边缘案例。

对于精确查找，使用具有共同前缀但不同后缀的测试标识符。对于释义，使用在源文中不存在但保留相同需求的表述方式。对于与版本相关的问题，同时包含一份相关的当前文档和一份看似过时的文档。对于不被支持的问题，要求系统显式暴露缺失的证据。

分别衡量候选列表和生成答案。记录相关段落是否出现，是否排名足够靠前以被纳入，以及最终答案是否准确引用了该段落。如果检索是正确的，但答案对该段落进行了夸大，则应调整生成边界而不是索引。

保留语料快照和检索配置以及评估结果。否则，之后得分的变化可能来自数据源更新，而不是排序改进。避免基于单个方便选取的查询演示就声称出现了普适意义上的“胜出”模型。

结论：保持精准与原意

在精确术语和标识符对决策至关重要的情况下，使用关键词检索。对于被改写的问题和概念相似性，评估向量检索。当问题集合有理由支持时，添加混合路径，同时在这两类候选结果流中保持元数据过滤、源版本以及证据检查的一致性。