Databricks 原型走向生产，但高 QPS 仍需规划
Databricks 将原型到生产环境之间的鸿沟简化为一项配置，使标准 AI Search 端点能够承载每秒数千次查询。这项新的高 QPS 功能已于 2026 年 7 月 28 日正式全面推出。它改变了团队将 Databricks 原型推广上线的方式，无需围绕原有索引重建搜索基础设施。
这一承诺附带一个重要前提。团队仍需选择目标值、为流量峰值做准备、测试检索质量并监控延迟。Databricks 负责配置容量，但并不会消除决定搜索体验是否可靠的工程决策。
此举也让 Databricks 与专用搜索平台及云托管向量服务展开更直接的竞争。Google 已将 Vertex AI Vector Search 面向大型低延迟工作负载进行推广。专业数据库也在吞吐量、筛选能力和运维简易性方面展开竞争。
Databricks 押注的是平台连续性更为重要。随着流量增长，同一套受治理的数据、索引和同步路径可以继续保留。对于已经在其湖仓环境中开发的团队，这可缩短部署工作。
这并不只是一次更快搜索能力的发布。它试图让受治理的企业数据基础设施在无需单独检索栈的情况下服务交互式应用。真正的考验，将在这些应用面对不可预测的生产流量时开始。
Databricks 原型如今拥有生产环境配置
Databricks 将复杂的容量规划工作简化为声明式 QPS 目标，同时保留现有索引和治理模型。
QPS 是每秒查询数，即一个端点在一秒内处理的搜索请求数量。当每次页面浏览、按键或推荐面板展示都会产生请求时，这项指标就变得至关重要。
Databricks 表示，标准 AI Search 端点现在可扩展至数千 QPS。开发者可在创建端点时设置 target_qps，或通过界面、SDK 或 REST API 更新现有端点。
随后，该服务会计算并配置所需基础设施。根据该公司的高 QPS 公告，开发者无需管理副本数量、节点规格或外部负载均衡器。
这正是核心变化。在此次发布前，一个成功的 Databricks 原型在用户数量增长后可能暴露新问题。搜索体验本身可用，但服务架构需要额外的容量规划和流量分发。
一些团队通过创建重复端点来完成这一过渡。另一些团队则增加客户端路由，或构建独立的服务层。这些权宜之计增加了运维工作，也引入了更多配置漂移的风险点。
新配置针对的正是这一边界。当现有标准端点的索引下次创建或同步时，它可以获得额外容量。Unity Catalog 治理和 Delta Sync 仍然是部署的一部分。
Unity Catalog 是 Databricks 面向数据和 AI 资产的治理层。Delta Sync 可使 AI Search 索引与其源表保持一致。保留两者十分重要，因为迁移往往会在性能问题之外带来第二个治理问题。
该端点还会通过其 scaling_info 字段展示扩缩容进度。团队可看到状态从 SCALING_CHANGE_IN_PROGRESS 变为 SCALING_CHANGE_APPLIED。
Databricks 增加了端点级别的请求速率、延迟和健康状况可见性。这些信号可在 AI Search 界面中查看，帮助运维人员将计划容量与实际表现进行比较。
该公告涵盖标准端点，并且无需选择加入流程即可正式使用。团队可为新端点应用目标值，也可更新已在为应用提供服务的端点。
这使 Databricks 的原型故事显得格外直接。零售商可以基于受治理的商品目录数据开发商品发现功能，然后提升服务容量，而无需将该目录复制到另一个搜索系统。
流媒体服务可以采用相同路径提供内容推荐。企业应用则可将其用于实体匹配，在这种场景中，每条传入记录都必须与现有目录进行比对。
这一变化并不会将笔记本实验直接变成成熟的消费者应用。它消除了实验与该应用之间经常出现的一项基础设施过渡。
因此，Databricks 销售的是连续性，而不只是速度。此前用于回答测试查询的端点，可以继续成为生产流量背后的端点。当治理、同步和服务原本会分属不同系统时，这种价值会更加明显。
这种连续性也提高了预期。一旦基础设施扩缩容成为配置项，应用团队就少了一个解释搜索缓慢或不可靠的理由。查询设计和工作负载测试会更接近核心位置。
高 QPS 将搜索置于营收路径之上
这一功能之所以重要，是因为交互式搜索流量具有突发性、直接面向用户，而且往往与交易或推荐直接相关。
传统分析查询有时可以等待。商品搜索框不行。用户会注意到输入联想结果延迟、推荐不完整，以及页面在检索完成前停滞。
输入联想搜索带来不同寻常的压力，因为一次用户操作会产生多次请求。除非应用对输入进行防抖或批处理，否则每输入一个新字符都可能触发一次查询。
推荐系统也会形成类似模式。主页在一次访问中可能请求多组个性化结果。流量会集中在内容发布、促销、直播活动和各地区观看高峰时段。
实体解析的用户体验不同，但运维需求相同。系统必须在另一项业务流程等待答案的同时，匹配记录、账户、产品或身份。
这些应用将检索置于关键路径上，也就是说，后续工作无法在搜索响应前继续。端点过载因此可能拖慢整个面向客户的工作流。
Databricks 指出三项预警信号：HTTP 429 错误、P95 延迟上升，以及涉及重复端点的权宜之计。P95 延迟是 95% 的请求可达到或优于的响应时间。
尾部延迟很重要，因为平均值可能掩盖糟糕体验。大多数查询或许能快速返回，但在流量攀升期间，仍有相当一部分查询会变慢。
即使平均利用率看起来处于中等水平，团队也可能遇到问题。短时流量突发可能在每小时或每天的平均值暴露问题之前，就耗尽可用容量。
这正是声明式目标的价值所在。团队可以按照预期请求速率进行容量规划，并为已知峰值预留余量。可观测性随后会显示这一假设是否符合实际。
不过，目标值的价值取决于其背后的流量模型。每周平均值无法描述上线首日的流量峰值。单用户测试也无法复现数千个并发会话。
搜索框还说明了，为什么向量检索如今正与成熟的关键词搜索竞争。基于嵌入的搜索将项目表示为数值向量，使系统能够检索语义相关的内容。
即使用户采用不同措辞，这种方法也能找到相关产品或文档。然而，精确名称、产品代码和罕见术语通常仍更适合关键词匹配。
混合搜索结合了语义检索和关键词检索。Databricks 建议将其作为实用的通用起点，但其性能指南指出，混合请求通常会消耗约为近似最近邻查询两倍的资源。
近似最近邻搜索，即 ANN，可在不穷尽比较每个项目的情况下找到相近向量。它通过接受受控近似来提高服务效率。
这一选择同时影响相关性和容量。使用简单 ANN 请求规划容量的工作负载，在团队启用混合检索、筛选或重排序后，表现可能有所不同。
重排序会在检索后应用另一个模型，对候选结果重新排序。它可以提升精确度，但 Databricks 表示，其交叉编码器重排序器可能增加延迟，通常每次查询额外增加不到一秒。
对于内部研究工具而言，这种延迟或许可以接受。但在每次按键后都会更新的商品搜索框中，它可能显得长得多。
因此，生产环境的问题不只是“端点能否处理数千个请求？”而是“它能否在所需延迟范围内处理这种确切的查询组合？”
这种区别同时给应用负责人、平台工程师和数据团队带来压力。应用负责人定义体验，平台团队管理容量，而数据团队则保障数据新鲜度和检索质量。
对于处理内部文档的团队，搜索行为还取决于信息被采集和组织的一致性。可搜索的知识库可以改善访问体验，但服务速度无法修复缺失的上下文。
高 QPS 扩大了可访问索引的用户数量。它并不能保证索引包含正确材料，或返回正确结果。
Databricks 原型挑战独立搜索栈
Databricks 正在挑战这样一种假设：生产级检索必须离开数据平台，转移到专用服务基础设施中。
一种常见架构将数据准备与应用搜索分开。团队在一个平台中转换和治理数据，然后将记录或嵌入导出到另一个专为在线检索构建的系统。
这种分离具有优势。专用搜索产品可提供专业的索引控制、熟悉的相关性工具，或针对特定工作负载经过验证的性能。
但它也带来了同步和治理工作。团队必须决定更新应以多快速度迁移、哪些权限需要转移，以及如何协调跨系统故障。
Databricks 希望客户避免这一交接。AI Search 将源数据、同步流程、治理控制和查询端点保留在同一个更广泛的平台内。
高 QPS 扩缩容使这一主张对于交互式应用更具可信度。若吞吐量不足，平台统一性只会在真实用户到来前显得有吸引力。
因此，主要对手并非某个特定数据库，而是独立服务栈，包括围绕它构建的复制、路由和运维层。
Google 提供了一个有益的比较，因为 Vertex AI Vector Search 同样将容量视为托管服务关注点。Google 文档介绍了自动扩缩容、多副本，以及用于召回率和延迟的调优控制。
Google 曾报告向量搜索基准测试，在公开数据集上达到数千 QPS。这些数据采用特定的数据集、维度、副本数量和召回率目标，因此不能直接与 Databricks 进行比较。
这一限定至关重要。供应商吞吐量数据描述的是经过测试的配置，而非普遍性能。索引规模、向量维度、筛选条件、结果数量、查询类型和并发度都可能改变结果。
Databricks 发布的是参考区间，而非单一的头条基准。其性能指南列出的标准端点延迟约为 20 至 50 毫秒，基准吞吐量则为每秒 30 到 200 多个查询（QPS）。
这些数据反映的是常规配置，而非新推出的高 QPS 容量。该公司表示，新设置可通过在目标端点后增加基础设施，将标准端点的处理能力提升至数千 QPS。
索引规模仍然重要。Databricks 表示，一个标准向量搜索单元可容纳约 200 万个向量，而一个标准端点最多支持 3.2 亿个向量。
当索引扩展至更多单元时，基准 QPS 可能逐渐下降，并最终在 ANN 查询场景下趋于约 30 QPS 的平台期。高 QPS 容量解决的是服务请求需求，但团队仍需理解索引的结构特征。
存储优化端点遵循另一种性能模式。Databricks 记录的容量最高可达 10 亿个向量，但其延迟更高，基准吞吐量低于标准端点。
这些端点于 2026 年 5 月正式全面推出。Databricks 表示，它们的数据索引速度可比标准端点快 10 至 20 倍，并支持规模大得多的集合。
不过，7 月发布的高 QPS 功能尚未扩展至存储优化端点。Databricks 表示，相关支持计划于 2026 年晚些时候推出。
这一限制界定了当前的竞争边界。在低延迟标准服务与超大规模存储优化索引之间做选择的团队，不能假定新扩展模型同样适用。
Google 的服务提供了另一套控制方式。开发者可以调整副本数、机器类型、搜索比例和邻居数量。这种灵活性可帮助经验丰富的团队细致调优性能。
Databricks 则为这一功能采取了更具声明式的路径。开发者设定期望的请求速率，平台负责计算所需容量。
这种权衡在托管基础设施中很常见。更高的抽象程度可减少日常工作，但也可能掩盖针对特殊优化或成本调查所需的底层机制。
Databricks 确实提供了已应用的扩展状态和端点指标。不过，该服务的 API 将 target_qps 描述为尽力达成的目标，而非绝对保证。
这在选择平台时尤为重要。目标值可简化资源配置，但生产服务级别目标仍应由应用团队负责。
继续留在 Databricks 内部的最强理由，出现在数据治理和新鲜度与原始检索速度同等重要时。避免额外复制一份数据可降低运维和安全复杂性。
采用独立技术栈的最强理由仍是工作负载专用性。团队可能需要其数据平台未提供的搜索功能、查询语言、区域拓扑或调优控制。
高 QPS 缩小了这一决策差距，但并未消除它。
一个配置参数无法取代负载测试
Databricks 可自动完成容量配置，但生产可靠性仍取决于具有代表性的测试和严谨的查询设计。
该公司自己也建议客户对端点进行负载测试。一项有用的测试应模拟真实的流量规模、并发度、过滤条件、查询类型和结果大小。
只测试纯净的 ANN 查询可能造成虚假的信心。生产应用往往会在首个原型成功后，加入元数据过滤、混合检索和重排序。
每种选择消耗的资源不同。Databricks 表示，混合搜索消耗的资源约为 ANN 的两倍，而返回更多结果也会增加扫描工作量。
其指南指出，将请求结果数增加十倍，可能使延迟翻倍，并使 QPS 容量降至原来的三分之一。具体影响取决于索引和配置。
向量维度又增加了一个变量。嵌入维度是用于表示一个项目的数值特征数量。
更大的嵌入可以保留更多信息，但也需要更多计算。Databricks 表示，将维度从 768 降至 384，通常可将 QPS 提升约 1.5 倍，并将延迟降低约 20%。
这并不意味着应缩小每一种嵌入。如果表示损失了对应用至关重要的信息，检索质量可能下降。
团队必须同时衡量相关性与速度。即使吞吐量图表看起来健康，一个快速返回低质量候选结果的端点也不能算是生产就绪。
身份验证也可能成为瓶颈。Databricks 建议生产应用使用搭配 OAuth 的服务主体，而非个人访问令牌。
服务主体是供软件使用的非人类身份。它支持托管式权限管理，而不会将应用访问权限绑定到某位员工的凭据上。
Databricks 表示，服务主体流量会使用经过性能优化的网络路径。其查询文档称，与其他路由方式相比，该方法每个请求最多可节省 100 毫秒。
该公司还表示，个人访问令牌流量的上限仅为几十 QPS。因此，使用该身份验证路径的原型，可能在端点达到计划容量之前就先行失败。
团队应从真实的应用环境进行测试。同一工作区中的笔记本无法复现公共网络路径、令牌生成、应用重试或区域距离等因素。
重试行为值得特别关注。当应用收到 429 响应时，立即重试可能会放大原有的流量峰值。
退避和抖动可将重试分散到不同时间点。没有它们，暂时的容量问题可能演变为自我延续的请求风暴。
目标值本身也需要余量。将其设为平均流量水平，几乎无法防范流量突发、客户端同步请求或特殊活动。
将其设得远高于预期需求，则会带来另一个问题。Databricks 指出，一旦配置目标值，额外容量就会产生额外成本。
该公告并未提供通用的成本对比。容量需求取决于索引、查询工作负载和性能目标，因此采购方需要自行测量。
自动扩展并不属于当前发布内容。团队需在流量到来前声明容量，而不是让系统在无需手动估算的情况下持续响应。
这在计划性扩展和弹性扩展之间形成了运维差异。计划目标可应对已知的发布活动，但意外激增的流量可能超过最初估算。
Databricks 表示，针对流量高峰的自动响应计划于 2026 年晚些时候推出。在此之前，可观测性和目标值更新仍是服务运营的一部分。
API 还将该目标描述为尽力达成。这一措辞意味着开发者不应将 target_qps 理解为针对任何查询组合的合同式保证。
大型索引带来了另一项风险。Databricks 的存储优化端点提供更高容量，但高 QPS 目标设置目前仅适用于标准端点。
接近标准端点上限的团队可能面临架构选择：对数据进行分区、复制索引，或等待存储优化选项获得高 QPS 支持。
Databricks 建议，当单个端点无法满足极高吞吐量时使用并行端点。团队可以将不同索引分布到多个端点，或复制热门索引并分发流量。
这些建议听起来很像该版本旨在减少的基础设施工作。它们表明，这一配置模型存在实际边界。
该功能为受支持的工作负载免除了常规的副本容量估算。它并未消除分布式系统的约束。
可信的部署计划应测试三种情况：正常流量、预期峰值，以及由故障触发的重试激增。它应记录每种情况下的延迟和相关性。
团队还应评估负载期间的索引同步情况。数据新鲜度是搜索质量的一部分，快速提供过时信息的端点仍可能损害用户体验。
只有在这些测试通过后，Databricks 原型才能称为生产就绪。新设置缩短了路径，但证据必须来自实际工作负载。
三个信号将表明高 QPS 是否会改变生产搜索
下一阶段取决于弹性扩展、存储优化支持，以及来自客户的独立工作负载证据。
第一个信号是针对流量高峰的自动扩展。Databricks 表示，该能力计划于 2026 年晚些时候推出，无需手动规划或估算容量。
如果它能够推出并维持稳定的尾延迟，该公司的生产场景论证将更具说服力。团队将不再需要在配置容量前估算每一个峰值。
如果自动扩展响应过慢，客户仍可能需要预留大量余量。这将削弱平台已经消除了大部分服务运维工作的说法。
时间点对于受监管环境也很重要。Databricks 表示，使用其合规安全配置文件的工作区，应在 2026 年 8 月下旬默认获得高 QPS 功能。
这次扩展将表明，该能力能否超越常规部署，而不产生独立的运维路径。企业采购方通常需要性能与合规控制并存。
第二个信号是对存储优化端点的支持。这些端点面向规模更大的索引，但目前延迟更高，也没有新的高 QPS 配置。
加入该功能将连接产品叙事的两个部分：十亿级容量与高请求吞吐量。在此之前，客户必须谨慎选择端点类型。
成功意味着大型目录可采用同样的声明式服务模型。延迟或严格限制将继续为专业向量数据库和云服务保留空间。
第三个信号是客户证据。Databricks 已宣布该容量机制，但尚未发布足够的独立生产结果，以定义其在多样化工作负载下的性能。
有价值的证据应包括索引规模、向量维度、查询组合、过滤条件、请求结果数、并发度、P95 延迟和实际达到的 QPS。缺少这些细节的头条数字几乎没有指导意义。
客户报告还应描述运营工作。最重要的问题不是 Databricks 是否增加了容量，而是团队是否真正移除了基础设施。
如果一家零售商淘汰了重复索引和客户端路由，就会支持平台连续性的论点。如果某个团队为安全起见保留了这些层，则会对此形成限定。
开发者还应关注服务在同步期间的表现。新容量会在索引创建或同步后生效，这可能影响紧急扩展变更的时机。
这一行为或许适合计划内活动。除非端点已经保留足够余量，否则它不太适合突发、不可预测的需求。
竞争对手的回应将很有启发性。托管向量服务已提供自动扩展或副本控制，专用系统也持续改进混合检索和过滤能力。
Databricks 不需要赢得每一项基准测试。它需要让足够多已经使用受治理湖仓数据的客户认为，独立的服务平台并无必要。
这一价值主张不止适用于产品搜索。企业 AI 助手同样依赖于跨文档、记录和权限的快速检索。
当团队设计这些系统时，它们既需要服务容量，也需要可靠的信息层。个人知识系统处理个人上下文，而企业检索则增加了治理与共享规模方面的要求。
7 月的发布为后者建立了更清晰的生产路径。它为工程团队提供了一个简单控制项，用于解决过去会触发额外基础设施的问题。
不过，这项公告应被视为运行模式的变化，而非对性能的普遍保证。Databricks 会在既定端点边界内自动完成容量计算。
下一步应当具体而明确：选取现有的 Databricks 原型，复现其完整的生产查询组合，并在常规与流量高峰时段进行测量。
跟踪 P95 延迟、错误率、相关性、同步行为和容量成本。还应在实际应用环境中测试服务主体认证与重试行为。
随后提出决定性的问题：target_qps 是否消除了一个服务层，还是仅仅将其规划工作转移到了新的设置中？答案将决定 Databricks AI Search 是否已弥合适用于你工作负载的生产差距。
