现代 AI 的检索骨干

如果你剥开当今大多数成功的 AI 应用的表层，就会发现检索是其核心。现代 AI 系统的有效性，取决于它们能否在正确的时间将正确的数据引入上下文。这个检索层支撑着从企业级 RAG 系统，到对账管道，再到个性化引擎等一切。

本周我与 Databricks 的 AI 团队产品经理 Adam Gurary 进行了深入交流，他的工作完全聚焦于搜索和检索。Adam 并非一开始就从事 AI 检索领域。他此前在 C3.ai 的工作聚焦于模型服务，这让他得以近距离了解数据科学家如何构建依赖于 LLM 推理和检索的管道。

如今在 Databricks，Adam 在数百家客户中观察到各种检索模式和痛点，这让他对 AI 采用背后真正发生的事情拥有独特的视角。

在我们的对话中，有三个主题变得格外清晰：

1. 数据工程和数据摄取是一个关键瓶颈。
2. 评估债务是许多 AI 项目在进入生产前停滞不前的原因。
3. 元数据（以及批处理系统）是极少被讨论、却能显著提升质量和差异化的杠杆。

下面我将详细拆解这些洞见，并分享 Adam 对那些构建在以检索为核心的技术栈之上的创始人的指导。

检索在现实世界中的应用场景

检索几乎无处不在。 正如 Adam 所说，检索适用于“任何拥有内部知识库、需要进行匹配，或具备搜索栏的人”。

在各个行业中，检索工作负载通常可归为以下三类之一：

1. RAG 与知识系统： 这类系统包括基于内部或半结构化数据的聊天和问答、知识助手，以及内部支持或销售赋能工具。凡是员工需要快速、高质量访问组织知识的场景，都属于这一范畴。
2. 匹配引擎： 从将求职者与职位发布进行匹配，到将金融交易与实体进行对账，再到为推荐和个性化管道提供动力。任何需要“找到最接近匹配”的工作流都属于这一类。
3. 搜索与发现： 内部知识搜索、内容和电商搜索栏，以及输入预测 / 自动补全体验，都在相关性和速度方面高度依赖向量搜索。

在这三种情况下，检索从一开始就决定了系统能够获得哪些信息。

最难的部分是将数据放入索引中

Adam 指出，大家都在讨论该使用哪种向量数据库，但几乎没有人谈论数据摄取管道，而这正是大多数团队卡住的地方。“假设你想在某个知识库之上提供搜索……你必须真正把数据放进那个索引里，对吧？而这绝非易事，”Adam 说道。

一个数据摄取管道通常需要：

• 检测源系统中的更改 / 新增 / 删除。
• 从源系统中拉取数据，例如 SharePoint、S3 以及其他来源。
• 增量式解析、分块、清洗和预处理。
• 对内容进行嵌入。
• 向指数中插入或从中删除。
• 随着时间推移，保持与源系统的一致性。

这需要数据工程，而大多数 AI 团队在一开始都严重低估了它的重要性。正如 Adam 所说：“只是为了让 SharePoint 可以被搜索，对大多数客户来说几乎是不可能的，因为你需要一支数据工程师团队来做这件事。”

真正困难的不是第一个索引，而是之后的一切。真实系统必须在接近实时的情况下检测变更，并且只对新增或被修改的文档进行增量式的解析、分块、嵌入和索引，同时正确移除已被删除文档的条目。在此之上，还需要处理版本控制，并强制执行用户和群组级别的访问控制，确保人们只能检索到他们被允许查看的内容。上述每一项要求都会增加状态管理、协调成本以及故障模式。

Adam 在一个又一个顾客身上都看到了这一点。许多团队一开始会争论是选择 Milvus 还是 OpenSearch，或者其他自托管方案，但他们很快就意识到，“他们最终把所有时间都花在了数据工程上，因为必须构建这些管道，随着时间推移让源系统和索引保持同步。”正是这种运维负担，使得托管、具备源感知能力的方法如此有吸引力。正如 Adam 所解释的那样，“我们之所以能在 lakehouse 数据上的搜索工作负载中胜出，一个主要原因就是 Delta Sync。你给我们一张表，我们就在这张表上给你一个索引，并负责管理所有用于计算 embeddings 并保持同步的管道。”

Adam 建议，在选型过程中将供应商对你源系统的支持程度（以及这种支持为团队节省了多少数据工程工作）作为一项重要考量，“要真正想清楚你将要在哪些数据源上进行搜索、如何处理它们，以及哪些供应商能让这些事情更简单，因为你并不一定希望把所有时间都花在数据工程上。”

例如，如果你的数据在 DynamoDB 中，Amazon OpenSearch 可以为你节省大量管道工作。而如果你的数据在 SharePoint 中，Azure AI Search 和 Databricks 都提供原生集成。如果你的数据已经在 Databricks lakehouse 上，那么选择 Databricks Vector Search 是一个安全的默认方案，可以避免繁重的数据工程工作。

源系统优先的思维方式并不是从选择使用哪种数据库开始，而是从你的数据存放在哪里入手，选择能够将摄取和同步成本降到最低的工具，使这些数据可用，从而让你把精力集中在应用本身，而不是数据管道上

评估债务

Adam 经常观察到的第二种模式是，团队无法交付产品，因为他们无法衡量质量。“能够评估你的系统看起来是很基础的事情，”他说，“在传统的机器学习中，这一直是开箱即用的。直到现在，几乎没有人真正认真地去思考评估。”

没有评估，团队就不知道这些改动是否真的有帮助。Adam 对我说：“他们每做任何事情，都无法证明它比之前更好。”这种不确定性在系统尚未进入生产阶段时最为痛苦，此时团队还没有带来业务影响，也无法证明自己正在更接近这一目标。没有展示进展的方式，项目甚至在有机会证明其价值之前就会停滞不前。

挑战的一部分在于，检索质量主要取决于是否能检索到“正确”的文档，但“正确”的含义会因业务场景而有巨大的差异。而且，通常构建这些系统的软件工程师并不知道什么才是相关文档，因为他们并不是自己所构建应用的领域专家（SME）。

在某些用例中，时效性比语义接近度更重要；在另一些用例中，检索结果集合的多样性至关重要。有时，业务逻辑甚至会完全凌驾于相关性之上——例如，出于合同或商业因素而对某些结果进行加权提升。这些信号很少体现在 embedding 中，而且除非你直接与领域专家沟通，否则它们往往是不可见的。

这正是许多检索系统崩溃的地方。Adam 认为之所以这是一个如此严重的问题，很大程度上是因为角色不匹配：“软件工程师不习惯将评估作为开发周期的一部分，这并不是他们的本能。”工程师往往针对泛化的相似性概念进行优化，但真正决定质量的因素存在于元数据、排序规则和领域约束中，而这些与向量距离毫无关系。要把检索“做对”，关键在于将业务逻辑编码进检索层，使系统能够呈现对特定工作流真正重要的内容。

要把这件事做好，Adam 表示需要：

• 与领域专家（SMEs）交流，了解什么才算“好”。
• 构建一个真实问答对的种子数据集。
• 使用合成数据生成来扩展覆盖面。“我们在 Databricks 花了大量时间去做的一件事，就是让开箱即用地生成合成评估数据变得非常容易，”Adam 告诉我。“大多数团队都知道他们需要更广泛的覆盖，但他们没有时间或工具来手工整理大型评估集。”
• 使用 LLM judges 来评估 groundedness。“我们投入了大量精力，让评判工作流能够开箱即用，因为尽管它们在衡量进展方面极其强大，但大多数团队并不想从零开始构建这些基础设施。”团队通常会使用与生产环境中运行的模型不同的模型来评估其系统，这有助于避免模型“给自己的家庭作业打分”。虽然 LLM judges 可能无法高置信度地告诉你一个系统是否恰好有 60% 的准确率，但它们在衡量随时间推移的相对改进方面非常强大。如果你做出一次更改，而评估分数从 60% 跃升到 78%，这就是你正朝着正确方向前进的强烈信号。

构建检索技术栈：性能、元数据与现实约束

不同的 UX 界面会带来不同的检索预算。例如，输入时搜索（又称自动补全）对延迟极为敏感，无法承担高负载的检索或 LLM 重排序，因为响应必须在几十毫秒内返回。相比之下，对话式代理可以容忍 1–3 秒的延迟，从而使多阶段检索和 LLM 重排序成为可行方案。

正如他所说：“在开始做出任何决策之前，你必须首先考虑延迟和性能方面的因素。”

如果你的延迟预算更高，还可以叠加以下能力：

• 混合搜索 ：将词法搜索（关键词、过滤条件、元数据）与向量搜索（embeddings）相结合，以在精确率、召回率和语义理解之间取得平衡。
• 重排序 ：获取初始检索到的一组候选结果，并使用成本更高的模型（通常是 LLM 或交叉编码器）根据相关性对其重新排序。
• 查询重写与扩展 ：将用户的原始查询转换为更清晰、更完整或多个相关查询，以提升检索质量。
• 更大的嵌入模型 ：容量更高的嵌入模型能够捕捉更丰富的语义细微差别和领域上下文，通常以更高的延迟和计算成本为代价来提升召回率。

在所有这些方法中，Adam 认为最被低估的杠杆仍然是元数据。正如他所说：“如果你拥有元数据，它可能是提升检索质量的最大杠杆。”元数据可以是产品目录、PDF 存储库，甚至是时间新近性——这是最简单但也是最强大的过滤条件之一。

他举了一个简单的例子：如果一位顾客搜索“blue Toyota”，而你的数据集中有诸如品牌、型号和颜色等结构化元数据字段，你可以在运行任何语义搜索之前，先将语料筛选为品牌 = Toyota 的行。与其在数百万辆车中进行向量嵌入搜索，不如先将搜索空间约束到一个更小且高度相关的子集，从而提升准确性。在实践中，这种以元数据为先的筛选往往比升级到更大的嵌入模型或添加复杂的重排序器更重要。

对于选择检索基础设施的团队，Adam 建议根据你所拥有的元数据类型来选择供应商，例如地理空间约束、时效性、访问控制、分层分类体系，或其他在实质上定义相关性的特定领域属性。Adam 强调道：“很多时候你并不需要花哨的嵌入模型，也不需要混合搜索，你只需要在查询之前直接基于元数据进行筛选。”这一洞见直接来源于 Databricks 在生产环境中的实践经验，这也是他们为何在强大的元数据筛选能力上投入如此之多的原因，而整个市场如今也正逐步朝这个方向收敛。

下一前沿：离线批量 LLM 系统

当我问 Adam 在 AI 领域里他最感到兴奋的是什么时，他表示，是那些不需要实时返回答案的批量 AI 系统的兴起。

他说：“围绕实时生成式 AI 的炒作很多，但真正应该进入人们视野的，是离线批量系统。”

Adam 描述了一种他在成熟团队中越来越常见的模式：你提交一个问题，等待一小时甚至更久，但输出结果却显著更好。他解释说：“我看到客户在构建这些疯狂的批处理管道。他们拉取海量数据，运行一个廉价的 LLM 来提取并丰富元数据，对其进行筛选和结构化，然后将其传递给另一个模型生成报告。整个过程可能需要八个小时，但最终产出的是高管级质量的成果。”

在实践中，这些系统看起来很像传统的 ETL 任务，只不过在整个管道中穿插了 LLMs，作为灵活的语义转换层。

这些系统的技术风险更高，因为它们无法用现成的框架直接组装。你不能只是让 LangChain 摄取十亿份文档、从 PDF 中提取图表，并合成一份高管报告。“没有开箱即用的东西，”Adam 对我说，“构建起来更困难、耗时更长，而且伴随着真实的技术风险。”

批量系统清晰地揭示了企业级 AI 中大量真实工作的所在。Adam 的观点一以贯之：企业 AI 部署中最困难、也最具价值的工作，尤其是在传统行业里，发生在模型之前以及模型周边，而不是模型内部。检索迫使团队直面诸如数据杂乱、时延预算和评估等问题，而这些正是大多数项目成败的关键所在。