Agent 更需要正确的上下文
一个 Agent 能否在真实业务中完成复杂任务，取决于两个关键能力：一是模型能否理解、推理和规划，二是它能否在正确的时间获取正确的上下文。企业知识分散在文档、图片、日志、代码、数据库和业务系统中；数据持续变化，并受到租户、权限、时效和合规边界约束。即使模型具备很强的推理能力，如果进入上下文窗口的信息不准确、不完整或已经过时，最终回答和行动仍然可能偏离事实。
如果说大模型决定 Agent 如何思考，那么搜索决定它能看到什么。搜索，正成为 Agent 最重要的上下文基础设施。面向 Agent 的 AI Search，需要同时完成四层工作：
- 模型理解：把文本、图片、PDF 页面等不同类型的数据转化为可比较的语义表示。
- 多路召回：让全文、稀疏向量和稠密向量分别处理精确匹配、语义扩展与意图理解。
- 融合与重排：将多路结果组合、校准并重新排序，为 Agent 提供更准确的上下文。
- 引擎执行：在持续写入、复杂过滤、高并发和大规模数据下，稳定地完成毫秒级查询。
本文所说的阿里云 AI Search，正是由模型、检索链路与阿里云 Elasticsearch 引擎共同构成的整体技术体系。
一张成绩单，看懂从引擎到模型的技术突破
能力层 |
评测或数据集 |
关键结果 |
考察维度 |
向量检索 |
VDBBench，Cohere10M（Top10） |
向量检索 QPS 82,520.18，P99 为 1.8 ms |
高维、千万规模向量下的吞吐与延迟能力 |
传统检索 |
ES Rally Big5 |
查询耗时几何平均数由 48.609 ms 降至 7.076 ms，整体加速约 6.87 倍 |
对过滤、排序、聚合等 ES 典型查询热路径的整体优化 |
全文检索 |
Tantivy Search Benchmark |
整体相对 Tantivy 0.26 提升 2.00 倍，相对 Lucene 10.4.0 提升 1.82 倍 |
Native 执行能力覆盖 Top K、Count 与结果收集路径 |
多模态模型 |
MMEB VisDoc |
Ops-Colqwen3-4B 以 84.12 的 Visdoc-Overall 得分位列第一 |
从引擎能力延伸到多模态文档理解与语义表示 |
向量检索登顶：高召回、低延迟和高吞吐如何同时成立
先看向量部分。这次 VDBBench 结果来自阿里云 Elasticsearch 自研 FalconSeek 云原生内核的向量引擎优化。在本次 VDBBench 公开对比中，服务端采用 32 vCPU g9i 实例。Cohere10M、Top10、Recall 约 0.98 时，查询吞吐达到 82,520.18 QPS；独立延迟测试中的 P99 为 1.8 ms。公开图表中，各对比对象的服务规格并不完全一致，因此这里保留原始数据和测试条件，不把结果再换算成统一的跨产品倍数。
FalconSeek对 HNSW 算法的端到端查询路径重构
FalconSeek 对 HNSW 算法的优化仍然遵循 HNSW 的图遍历和候选队列语义，但把一次查询拆成两个职责清楚的阶段。查询向量使用量化向量，用它遍历图并缩小候选范围；候选 ID 确定后，系统再按需读取对应的原始向量，批量计算相似度，最后截取 Top K。
围绕两阶段路径，工程优化主要落在四个地方：
- 批量距离计算：将同一批邻居节点的距离计算组织成批次，利用硬件向量指令、指令级并行和预取，减少逐节点计算开销。
- 面向访问模式的数据布局：把图邻接表、量化向量和辅助信息组织为紧凑的只读布局，让查询热路径上的数据尽可能相邻。
- 原始向量按需重排：原始浮点向量与图遍历数据分开存放，只对候选集合进行批量精确计算。
- 融入 Segment 生命周期：向量索引随 Elasticsearch 的 refresh、segment 和 merge 过程一起生成与发布，不要求业务另行维护一套向量数据生命周期。
82K QPS 和 1.8 ms P99 因而不是某个单独优化的结果，而是候选生成、精排计算、数据布局和 Segment 生命周期共同作用后的端到端表现。
传统检索链路的内核优化与性能突破
Agent 搜索并不会用向量彻底替代关键词检索。产品型号、错误码、代码符号、专有名词和结构化条件仍然依赖全文与精确查询；实时日志、高基数聚合和复杂过滤也仍然考验传统搜索引擎的执行效率。阿里云 Elasticsearch 自研的 FalconSeek 云原生内核。不只在向量赛道上优化。也在传统文本搜索、分析领域进行了深入优化。
FalconSeek 不是要替换 Elasticsearch。ES 继续负责 API、Query DSL、集群状态、Shard 分配、写入生命周期和安全权限；FalconSeek 则把倒排遍历、列式读取、排序、聚合和向量召回等查询热路径下沉到 C++ Native 内核。对于暂未覆盖或需要保持原生行为的查询，系统可以回退到 ES 原生执行路径。
FalconSeek 云原生内核更多的技术细节可参见：《FalconSeek 技术解析：阿里云 Elasticsearch 云原生内核如何让查询性能飙升600%》
Rally Big5 数据集：整体加速约 6.87 倍
在 Rally Big5 数据集上，FalconSeek 将查询耗时的几何平均数从 ES 9.4 的 48.609 ms 降至 7.076 ms，整体加速约 6.87 倍 (本次Benchmark采用 16 vCPU g9i 实例，两组测试在相同数据，通过动态开启FalconSeek查询加速测试得出）。
Big5 数据集覆盖排序、范围过滤、Query String、Terms、Composite Aggregation 和 Date Histogram 等典型查询形态。拆解代表性 Case 后可以看到，收益既出现在复杂聚合、范围查询和排序路径上，也覆盖关键词查询与基础检索。
Big5 中 12 个代表性 Case 的查询耗时对比，数值越低越好。个别 Case 的高倍数收益与具体查询结构、索引和测试环境相关，整体结论以 6.87 倍几何平均加速为准。
Tantivy Search Benchmark：五组测试均保持领先
在 Tantivy Search Benchmark 的同一测试口径下，结果覆盖 TOP_10、TOP_100、TOP_1000、TOP_100_COUNT 和 COUNT 五组测试，共 4,810 个查询样本。
FalconSeek 的整体平均耗时为 912 μs，低于 Tantivy 0.26 的 1828 μs 和 Lucene 10.4.0 的 1663 μs，整体性能加速比提升 2.00 倍和 1.82 倍。五组测试中，FalconSeek 均保持领先；其中同时包含 Top K 结果收集和命中文档计数的 TOP_100_COUNT，相对 Tantivy 提升 2.28 倍，相对 Lucene 提升 3.37 倍。
FalconSeek、Tantivy 0.26 与 Lucene 10.4.0 在五组 Search Benchmark 中的平均查询耗时指标，数值越低越好。
两组传统查询测试背后是相近的工程思路：通过请求级内存池减少短生命周期对象和回收成本，直接读取 Lucene 的 FST、Postings、BKD 与 DocValues 等索引结构，把逐文档执行改造成更适合预取和 SIMD 的批量路径，并针对 Range、Count、排序和聚合等热点查询族做专项优化。
对用户而言，查询执行时间降低不仅意味着响应更快。更少的 CPU 时间、临时内存和线程占用，也会为提高并发密度、延缓扩容和改善高峰期尾延迟提供空间。但具体资源收益仍取决于查询结构、数据分布和集群配置，不能由单个 Benchmark 直接外推为统一降本比例。
从引擎到模型：Ops-Colqwen3-4B 登顶 MMEB VisDoc
当企业知识从纯文本扩展到 PDF、图片、表格、扫描件和演示文稿，传统的“先 OCR、再切分、再做文本向量”并不总能保留完整的页面结构与视觉语义。Agent 不仅要找到包含关键词的页面，还要理解文本、布局、图片、图表和表格之间的关系。
为此，阿里云 AI 搜索团队发布并开源了多模态文档 Embedding 模型 Ops-Colqwen3-4B。该模型基于 Qwen3-VL-4B-Instruct，采用 ColPali 风格的多向量表示，将文本查询与图片、PDF 页面映射到统一的语义空间，并通过 MaxSim 完成细粒度匹配。
在 MMEB VisDoc 榜单中，Ops-Colqwen3-4B 以 84.12 的 Visdoc-Overall 得分长期领跑榜单，位列第一。根据榜单快照，其得分高于多款更大参数规模的模型，相比简单强调“参数更大”，这一结果更重要的信号是：通过训练策略和表示方式优化，较小模型同样可以获得更高的文档检索精度。
MMEB Visual Doc 榜单截图。Ops-Colqwen3-4B 的 Visdoc-Overall 得分为 84.12，位列第一。榜单会持续更新，排名以访问时页面为准。
该模型采用多阶段训练策略，将大规模文本检索数据与多样化视觉文档数据结合，并引入高质量数据合成、文本 Embedding 模型蒸馏、单向量与多向量混合训练、模型融合等手段，提升跨模态对齐和复杂语义场景下的检索效果。
这一步让阿里云 AI Search 的优化从“把查询执行得更快”进一步延伸到“让系统更准确地理解要检索的内容”。前者决定上下文能否以足够低的成本和延迟被取回，后者决定进入候选集的内容是否真正相关。
榜单之外：走向可落地的 AI Search 全栈能力
从 VDBBench、Big5、Tantivy 到 MMEB，这些结果覆盖了不同数据集和评价维度，但共同指向一个变化：AI Search 的竞争正在从单点能力转向全栈协同。
层次 |
阿里云 AI Search 的优化方向 |
对 Agent 的直接价值 |
模型 |
文本与多模态 Embedding、语义对齐 |
更准确地理解问题和企业文档 |
检索 |
全文、稀疏与稠密向量多路召回 |
同时保留精确信号与语义信号 |
编排 |
融合、过滤与 Rerank |
生成更高质量、更符合权限边界的候选上下文 |
引擎 |
FalconSeek、Native 查询与向量索引 |
在规模增长后仍保持低延迟、高吞吐与资源效率 |
当前，FalconSeek 云原生内核可在阿里云 Elasticsearch 8.17.0 和 9.4.0 版本中开启，并处于限量免费测试阶段。用户仍然使用熟悉的 ES API、Query DSL、客户端和运维体系，对适合下沉的查询使用 Native 执行路径，不支持的查询可以按照策略回退至 ES 原生引擎。具体使用方法可参考阿里云官方文档。
Ops-Colqwen3-4B 已在 Hugging Face 开源。后续，团队计划将其接入 AI 搜索开放平台，为企业多模态文档检索提供模型服务；具体上线时间、服务形态和支持范围以正式发布信息为准。
结语
Agent 的能力上限不仅取决于模型，也取决于它获得了怎样的上下文。面向这一变化，搜索必须同时回答四个问题：数据能否被正确理解，候选能否被全面召回，结果能否被准确融合，以及查询能否在生产规模下稳定执行。
这也是阿里云 AI Search 从引擎到模型推进全栈优化的原因。VDBBench 的向量成绩、Big5 与 Tantivy 的查询加速，以及 Ops-Colqwen3-4B 在 MMEB VisDoc 的榜首，并不是终点，而是这条全链路已经具备工程基础与算法能力的阶段性证明。
欢迎申请体验阿里云 Elasticsearch 9.4 与 FalconSeek 云原生内核。如果您正在建设企业知识库、RAG、Agent Memory、多模态文档检索或其他 AI 搜索场景，也欢迎联系阿里云 AI Search 团队交流。
阿里云ES免费试用：https://free.aliyun.com/?spm=5176.14058969.J_3759233040.1.1c5069afFW3p4q&productCode=elasticsearch
扫码进群了解更多：
