Agents 需要向量搜索，超过 RAG 以往的需求
Source: VentureBeat
Source: …
向量数据库在 Agentic AI 领域中的角色
过去几个月，组织一直在思考这个问题：
在日益以代理为中心的 AI 世界中，向量数据库扮演什么角色？
主流叙事
当大语言模型（LLMs）开始支持 百万 token 上下文窗口 时，企业架构师中出现了一个常见的论点：
- 前提： 为检索增强生成（Retrieval‑Augmented Generation，RAG）专门构建的向量搜索仅仅是一个 临时方案——一个暂时的层。
- 预测： 随着 agentic memory 的成熟，它将吸收检索问题，使向量数据库成为 RAG 时代的产物。
实际情况
市场正朝相反的方向发展。
- Qdrant，这家总部位于柏林的开源向量搜索公司，宣布完成 5,000 万美元 Series B 融资（VentureBeat，2024）——仅在两年前完成 2,800 万美元 Series A 融资后。
- 同时，该公司发布了平台 v1.17 版本。
这些里程碑共同传达了一个明确的信息：
检索问题并没有因为代理的出现而缩小；相反，它变得更大、更复杂。
Qdrant CEO 的引用
“人类每隔几分钟才会发起几次查询，” Qdrant 的 CEO 兼联合创始人 Andre Zayarni 对 VentureBeat 说。
“代理每秒会发起数百甚至数千次查询，只是为了收集信息以便做出决策。”
为什么这种转变重要
| 方面 | RAG 时代部署 | Agentic 时代部署 |
|---|---|---|
| 查询频率 | 低（人类规模） | 高（代理规模） |
| 延迟要求 | 中等 | 超低 |
| 吞吐需求 | 每分钟数十至数百次 | 每秒数百至数千次 |
| 数据新鲜度 | 定期更新 | 近实时摄入 |
| 基础设施设计 | 为偶发检索优化 | 为持续高频检索构建 |
查询量的激增迫使我们重新思考核心基础设施：
- 可扩展的索引，能够快速处理插入和删除。
- 低延迟、高吞吐的服务，保持代理的响应性。
- 成本效益的存储 策略，因为向量数量会急剧增长。
- 强大的监控与可观测性，在瓶颈影响代理决策之前及时发现。
结论
向量数据库 不是 RAG 时代的遗物。它们正成为 agentic AI 系统的 支柱，负责在规模化的实时检索中提供 海量、即时 的支持。随着代理在企业中的普及，对高性能向量搜索的需求只会进一步加剧。
为什么代理需要检索层，而记忆无法取代
代理必须处理它们从未接受过训练的信息：
- 专有企业数据
- 当前信息
- 持续变化的数百万文档
虽然上下文窗口管理会话状态，但它们 并不 提供：
- 高召回率搜索 跨这些数据。
- 一致的检索质量 随着数据演变。
- 可扩展的查询量 由自主决策产生。
“市面上大多数 AI 记忆框架都在使用某种向量存储。” — Zayarni
这直接意味着：即使标榜为记忆替代方案的工具，也依赖于底层的检索基础设施。
当检索层不是为此专门构建时的三种失败模式
| 失败模式 | 影响 |
|---|---|
| 文档规模的漏检 | 这不是延迟问题，而是 决策质量 的问题，会在单个代理回合的每一次检索过程中累积。 |
| 写入负载下的相关性下降 | 新写入的数据会停留在未优化的分段中，直到索引赶上，这会使对最新数据的搜索变慢且不够准确——恰恰在当前信息最重要的时候。 |
| 分布式基础设施中的延迟峰值 | 单个慢副本会拖慢代理回合中每个并行工具调用的延迟。人类用户会感到不便；而自主代理则无法容忍这种情况。 |
Qdrant 1.17 如何解决这些问题
- 相关性反馈查询 – 通过使用轻量的、模型生成的信号在下一次检索时调整相似度评分来提升召回率，无需重新训练嵌入模型。
- 延迟分流 – 当第一个副本的响应超过可配置的延迟阈值时，查询第二个副本，防止慢节点阻塞整个请求。
- 集群范围遥测 API – 用单一视图取代逐节点排查，简化诊断和性能监控。
Source: …
为什么 Qdrant 不再想被称为 向量数据库
几乎所有主流数据库现在都支持向量作为数据类型——从超大规模云服务到传统关系系统。这一转变改变了竞争焦点：数据类型已经是基本配置。仍然需要专注的，是生产规模下的检索质量。
正是这种区别让 Zayarni 不再希望 Qdrant 被称为“向量数据库”。
“我们正在为 AI 时代构建信息检索层，”他说。
“数据库是用来存储用户数据的。如果搜索结果的质量重要，你需要的是搜索引擎。”
给团队的入门建议
- 使用你技术栈中已有的向量支持。
- 只有在规模迫使时才迁移到专门构建的检索方案。
“我们每天都看到公司来找我们，说他们一开始用了 Postgres，觉得够用了——其实并不够。”
Qdrant 的独特之处
- Rust 架构——提供内存效率和底层性能控制，较高级语言在同等成本下难以匹配。
- 开源基石——社区反馈和开发者采纳让 Qdrant 能与拥有更大工程资源的厂商竞争。
“没有它，我们根本不可能达到现在的状态，” Zayarni 说。
两个生产团队发现通用数据库的局限
GlassDollar
GlassDollar 帮助企业（包括西门子和马勒）评估初创公司。其核心产品是搜索：用户用自然语言描述需求，系统从数百万家公司中返回排序后的候选名单。
架构
- 查询扩展 在每一次请求上运行。
- 单个提示会分发为多个并行查询，每个查询从不同角度检索候选。
- 将结果合并后重新排序。
这是一种 agentic retrieval（而非 RAG）模式，需要专门的搜索基础设施才能在高并发下支撑。
迁移到 Qdrant 的影响
| 指标 | 迁移前（Elasticsearch） | 迁移后（Qdrant） |
|---|---|---|
| 索引文档数 | ~10 M | ~10 M |
| 基础设施成本 | – | ‑40 % |
| 基于关键词的补偿层 | 使用中 | 已移除 |
| 用户参与度 | – | ×3 |
“我们用召回率来衡量成功，” Kamen Kanev，GlassDollar 产品负责人说。“如果最好的公司不在结果里，其他一切都无关紧要。用户会失去信任。”
“那是基础设施问题，而不是对话状态管理任务，” Kanev 补充道。“这不是通过扩展上下文窗口可以解决的。”
&AI
&AI 为专利诉讼构建基础设施。其 AI 代理 Andy 在数亿份跨年代、跨司法管辖区的文档中进行语义搜索。因为专利律师不会直接采用 AI 生成的法律文本，代理展示的每一个结果都必须有真实文档作支撑。
“我们的整体架构旨在通过把检索设为核心原语、而非生成，来最小化幻觉风险，” Herbie Turner，&AI 创始人兼 CTO 说。
对 &AI 来说，代理层与检索层本身就是分离设计的：
“Andy，我们的专利代理，构建在 Qdrant 之上。代理是接口，向量数据库是事实真相。” – Herbie Turner
结论
这两个团队都表明，当检索是主要原语时，像 Qdrant 这样的专用向量数据库能够：
- 大幅降低成本
- 提升相关性
- 减少幻觉
这些是通用数据库难以提供的能力。
Source: …
三个信号表明是时候摆脱当前设置
实际的起点是 使用你现有技术栈中已经具备的向量能力。评估的关键不在于 是否 添加向量搜索，而在于 何时 你的当前设置不再足够。
表明需要升级的三个信号
- 检索质量直接影响业务结果——错过或不相关的结果会对收入、合规或用户满意度产生真实的后果。
- 复杂的查询模式——你需要扩展、 多阶段重新排序，或并行调用工具，而现有系统无法高效处理。
- 数据量扩展到数千万文档——庞大的规模会超出当前方案的性能和存储限制。
只要出现上述任意信号，关注点就会转向运营层面的问答：
- 你的当前设置能在分布式集群中提供多少可视化的活动监控？
- 随着代理查询量的增加，性能余量还能剩多少？
“现在关于检索层的替代方案有很多噪音，”Kanev 说。“但对于任何把检索质量当作产品核心、错过结果会带来真实业务后果的产品来说，你需要专用的搜索基础设施。”