在现代人工智能堆栈中，应用程序通过多种检索模式动态获取上下文。这些模式给人灵活性的错觉，但也将检索的鲁棒性进行了抽象封装，而这份鲁棒性不能仅仅交由应用逻辑来保证。为了大规模支持 Agentic AI 工作负载，底层基础设施必须能够保证延迟边界、执行治理并确保结果相关性。
本章的重点从“选择哪种模式”转向了如何将分布式SQL数据库作为可靠的基底进行落地实现。我们将看到，一个分布式 SQL 数据库如何兑现这些检索模式背后的承诺，让应用程序只需简单地提问，而系统则能可靠地交付答案。
延迟：负载下强制执行速度
对应用程序的最终用户而言，检索应当是即时完成的，即使在高并发状态下也应如此。然而，应用程序自身无法可靠地保证这一点。相反，基础设施必须提供保障，即便在需求增长时也能实现毫秒级的响应。索引优化、边缘缓存和自适应预取等技术因此成为关键的基础设施策略。延迟有多种表现形式，每一种都带来了必须在系统层面应对的独特挑战：
最佳情况（或平均路径）延迟
这是在最有利条件下请求所需要的时间，例如缓存命中、资源闲置且查询简单的情况。它反映了用户在大多数时间里所期望的“理想路径”性能。确保这条路径保持低延迟，需要依赖快速的索引、内存访问和最小的内部开销。
尾部/最坏情况延迟
即使中位数延迟表现优异，那些最慢的响应（例如处于第95、99百分位的响应）也可能主导用户体验，甚至违反服务等级协议。异常值可能源于资源争用、后台任务干扰或排队延迟。系统必须通过冗余设计、投机执行、智能调度和资源隔离等手段，主动缓解这种尾部风险。
冷查找和缓存未命中延迟
当请求的数据项不在高速缓存中时，系统必须回退到更深层的存储（如磁盘、远程分片）或执行索引遍历。这条“冷路径”的成本要高得多。基础设施必须运用预取技术、高效的索引结构以及智能的缓存失效策略来优化冷路径，避免出现巨大的延迟峰值。
网络/跨节点延迟
在分布式系统中，节点间的协调、数据分区和远程查询会在访问所需数据前引入额外的延迟。即便是优化良好的本地索引，也可能被跨节点通信所拖慢。基础设施必须通过减少跨节点调用、将相关数据共置、利用数据本地性以及批量请求等方式来降低这部分开销。
索引维护/更新延迟
系统会随着写入、删除、重建索引、数据压缩或模式变更而演进。这些后台操作在不降低读取性能的前提下，其影响传播的速度至关重要。如果索引更新过慢或阻塞了读取操作，就会导致数据过时或延迟激增。检索基底必须能够在不损害响应能力的前提下，管理增量更新、后台压缩和一致性。
这些延迟模式共同定义了真实的性能边界。为了达到目标，系统应当做到：
- 集成快速索引、支持多模态的统一搜索以及高效的数据结构，确保普通查询和冷路径查询都能迅速运行。
- 通过智能分区、路由和数据本地性感知，严格控制网络和协调带来的延迟。
- 利用投机执行、资源隔离和自适应管理等手段，监控并约束尾部延迟。
- 确保索引更新操作（写入、重建索引、模式变更）带来的延迟，不会显著拖累读取性能。
当底层基础设施运行良好时，应用程序便可以信赖地认为，所有的检索请求都能在策略约束范围内快速、可靠地返回。检索不再需要每个微服务各自为政地实现缓存或隔离策略，而是成为了一个真正可靠的、值得信赖的基础层。
分布式SQL中的弹性与隔离：为什么它重要
分布式SQL系统的设计目标，是在将存储和计算分散到多个节点的同时，提供一个单一的逻辑关系型接口。为了高效承载AI和记忆密集型工作负载（尤其是检索、向量嵌入查找或混合查询），这些平台必须具备响应式、安全且无跨租户干扰的扩展能力。在实践中，那些将弹性和工作负载隔离内化于系统设计的分布式SQL平台，能够通过以下方式规避架构的脆弱性：
按需水平扩展
由于数据在节点间进行了分区和复制，分布式SQL可以在查询或索引负载增加时横向扩展，在空闲时收缩。这种弹性确保了系统能够吸收检索流量的突发峰值，而无需过度预置资源。例如，TiDB将数据划分为多个“Region”，并能动态地重新分布负载，从而防止热点产生。
跨租户或代理工作负载的资源隔离
多个代理（或用户）共享同一个分布式SQL集群，并不意味着它们必须共享底层资源。系统可以强制执行资源限制（CPU、内存、查询配额）并对工作负载进行隔离，从而确保一个租户的高流量查询不会影响其他任务的检索质量。分布式SQL的多租户能力必须超越简单的模式隔离，需要将资源级别的控制内嵌到查询引擎和调度器中。
分区感知的数据本地性与共置
为了最小化跨节点延迟，分布式SQL必须能够识别哪些分区或分片经常被一起访问，并尝试将它们共置在相同节点，或至少减少访问它们所需的网络跳数。这显著降低了那些需要跨分片连接，或需要为单个检索管道获取多个上下文块的查询的协调成本。
弹性的计算-存储解耦
许多分布式SQL系统将计算层与存储层解耦。这使得系统能够独立地扩展无状态的SQL查询处理节点和有状态的存储/副本节点，并根据基于嵌入的查找或检索扇出等具体需求来分别调整它们。这种解耦为检索密集型路径提供了极大的灵活性，允许计算集群积极扩展，而不会干扰存储层的稳定性。
安全且影响最小的扩展与版本管理
在添加节点、重新平衡分片或变更数据模式时，分布式SQL必须支持滚动升级和透明的数据迁移，同时不牺牲一致性或造成查询中断。在内存支持的检索场景中，系统无法承受在再平衡期间出现“数据冷间隙”或查找速度骤降的情况。因此，系统必须能够优雅地处理这些操作。
缓解跨租户的“噪音邻居”行为
在共享的分布式系统中，突发的、繁重的索引更新或大量向量嵌入插入，可能会压垮共享资源。此时，工作负载隔离机制就至关重要，它可以将此类突发流量进行限流或沙箱化处理。这确保了即使某个租户正在执行繁重的后台操作，其他租户的延迟和检索质量保证依然有效。
多范式存储
新一代分布式数据库正在兴起，以满足事务处理、分析计算和AI驱动型工作负载日益融合的趋势。这些系统利用云原生对象存储将计算与存储分离，使其能够弹性扩展，并在波动的需求下保持强一致性。除了传统SQL能力，它们也越来越多地支持向量、JSON和知识图谱数据，以支持更丰富、更智能的查询，同时提供长时记忆和版本化数据存储能力。
整合起来
一个遵循上述原则进行优化的分布式SQL平台，能够带来以下成果：
- 应用程序可以信赖地认为，随着负载增长，平台会以弹性的方式无缝扩展，无需人工干预或造成服务中断。
- 每个代理或租户都可以放心地运行复杂的检索、嵌入查找或向量增强查询，无需担心受到其他工作负载的性能干扰。
- 分片本地性、数据共置和资源隔离共同作用，减少了跨节点通信，确保了检索路径的低延迟。
- 升级、再平衡和动态模式变更等操作的影响被降至最低，从而保障了系统的高可用性和数据一致性。
简而言之，利用具备原生弹性和工作负载隔离能力的分布式SQL，可以将原本脆弱、需要手动调优的检索架构，转变为一个强韧的、生产就绪的基础层。
治理：内嵌，而非叠加
访问控制、合规性要求和可审计性，通常被视为次要问题，通过包装器、中间件或API网关附加在应用之上。这种做法在小规模场景下或许可行，但在企业级规模下，它会变得脆弱、不一致且充满风险。相反，治理必须被嵌入到检索层本身——在处理查询、获取上下文并响应代理请求的基础设施之中。这主要通过以下几种方式实现。
每个请求的标准化元数据
每一次检索事务都应携带一套一致的元数据，例如：请求上下文、数据源或分片信息、请求时间戳、版本或修订ID、用户或主体身份，以及数据来源（上下文是如何组合而成的）。这确保了系统在后续环节能够知晓检索发生的原因、获取了什么数据以及数据来自何处。缺乏这种标准化，审计、调试和合规性审查将变得脆弱且难以保持一致。
边界处的强制访问控制
访问控制逻辑可能出现在应用或服务层，但检索层自身也必须强制执行访问控制。这样，即使应用程序存在漏洞或遭到破坏，未经授权的数据也无法通过检索系统被获取。基于角色的访问控制（RBAC）是大型系统中广为人知的范式，即定义角色、为角色分配权限，再将用户或代理映射到角色，而非直接管理每个用户的权限。将访问控制执行点下沉到检索层，可以集中策略管理、减少重复配置，并避免跨多个服务的策略分歧。
每次获取操作的不可变审计日志
每一次检索事件——无论是成功还是被拒绝——都应该生成一条不可篡改的审计日志。日志内容应包括：请求者身份、请求内容、相关元数据、访问是否被授权以及精确的时间戳。这类日志对于实现可追溯性、满足合规要求、进行取证审查和明确责任归属至关重要。与主要用于调试的常规日志不同，审计日志旨在以一种不可修改的方式，忠实记录“谁在何时何地做了什么”。
将这些治理机制内嵌到检索基础设施中，可以最大限度地降低因应用程序各自实现策略而可能产生的安全漏洞或策略不一致风险。
准确性：一项持续的、系统性责任
应用程序或许会尝试通过编写自定义的排序启发式规则、应用过滤器或组合多种信号源来提升结果相关性。然而，真正的检索准确性——即在最小化噪声和最大化相关性的前提下，返回正确上下文的能力——并非一项可以可靠地交由应用代码负责的特性。它是系统设计的一个内在属性，必须被当作系统工程来对待。实现它需要持续的度量和反馈循环。
系统级的监控与度量
为了使“准确性”变得可度量、可监控，系统必须在真实流量中持续地对其进行测量。这意味着需要系统地统计诸如精确率、召回率、平均倒数排名、归一化贴现累计增益以及相对于基准答案的命中率等指标。如果没有系统级的反馈机制，应用层的逻辑会逐渐“漂移”，因为模型、启发式规则和过滤器会随着数据分布变化、上下文演进和领域漂移而累积误差，逐渐失效。将监控能力内嵌到检索引擎中，可以确保你能够及时检测到相关性下降、特定查询模式表现不佳，或者新的数据模式导致原有启发式规则失效的情况。这种检测能力是进行主动适应、而非被动修补的基础。
基础设施支持的反馈循环
度量是基础，但仅仅是第一步。真正的力量来自于系统能够支持的反馈循环——它将来自用户、错误或下游组件的信号，转化为持续的系统性调整。
设想这样一个系统：它能捕获用户的显式纠正或相关性判断（例如“相关/不相关”的标注、点击行为、星级评分），并将这些信号输入到重排序模块或排序调优逻辑中。同时，系统还能检测模型之间的“分歧”——例如，当一个生成式模型拒绝使用某段上下文、修改了其答案，或返回了低置信度时——并将这些信号作为监督信息反馈回来，促使系统重新评估或调整候选上下文的优先级。
这种反馈机制促成了所谓的“活索引”。检索引擎不再是一个静态的、一次性的索引，而是变得具有自适应性，能够随着时间推移，在排序权重、评分融合策略甚至定期的向量嵌入更新中进行学习与改进。由于所有这些反馈处理都内置于基础设施中（而非分散在各个独立应用里），系统能够保持一致的更新逻辑、强制执行版本控制、允许安全回滚，并避免跨服务出现重复的反馈处理管道。最终，我们将获得一个能够从错误中学习，并能在生产规模上持续优化其相关性行为的检索基础层。
应用负责使用；系统负责保障
归根结底，核心原则在于：应用程序的角色是“使用”检索能力，而系统的责任是“保障”检索的可靠性。在一个成熟的架构中，可靠性的重担不应落在各个微服务身上，迫使它们编写大量的临时代码来修补延迟、安全或相关性方面的漏洞。相反，检索基础设施本身就必须提供这些保障。
应用程序只需发出查询请求，而系统的任务则是以高速、可信且有意义的方式完成它。当这条责任边界变得清晰而稳固时，记忆基础层才能真正成为一个可靠的基石。系统因此变得可组合，智能体可以在不重构检索逻辑的情况下持续演进，而信任则被内建到了架构之中。这种从脆弱的、应用层的启发式方法，向坚实的、基础设施级的保障体系的转变，正是将“记忆”从一个微不足道的脚注，提升为智能系统一流支柱的关键所在。
1 Jeffrey Dean and Luiz André Barroso, “The Tail at Scale”, Communications of the ACM, 56 (2013): 74–80.
2 Ben Meadowcroft, “Introducing TiDB X: A New Foundation for Distributed SQL in the Era of AI”, PingCAP (blog), October 8, 2025.
3 Rocio Aldeco-Pérez and Luc Moreau, “Provenance-Based Auditing of Private Data Use”, paper presented at Visions of Computer Science, BCS International Academic Conference, August 2008.
4 Chen Shi et al., “User Feedback and Ranking In-a-Loop: Towards Self-Adaptive Dialogue Systems”, in SIGIR ’21: Proceedings of the 44th International ACM SIGIR Conference on Research and Development in Information Retrieval: 2046–2050.
发表于 昨天 09:28
|
查看: 6|
回复: 0
