ARTICLE · 1269085

云栖实录|从代码上下文到千亿级文档:Qoder * 阿里云 Elasticsearch 落地生产级Agent向量检索

发布时间：2026-10-28 19:44:11 最近访问：2026-10-28 19:44:12

从代码上下文到千亿级文档：Qoder × 阿里云 Elasticsearch 落地生产级向量检索阿里巴巴 ATH 事业群 Qoder 技术专家夏晓文分享大规模代码检索的架构选择、工程实践与运行效果，并展望代码、记忆和企业知识的融合检索

9月23日上午，在2026云栖大会 AI 搜索分论坛上，阿里巴巴 ATH 事业群 Qoder 技术专家夏晓文发表《Qoder × 阿里云 Elasticsearch：千亿向量检索引擎的生产级落地》主题演讲，系统介绍 Qoder 如何借助阿里云 Elasticsearch Agent 引擎版构建代码上下文检索底座，并分享从多租户隔离、索引构建到高可用、可观测和成本控制的生产实践。

在 Agentic Coding 场景中，模型能否理解一个真实软件项目，不只取决于代码生成能力，还取决于能否在有限上下文中准确找到相关代码、符号、提交记录和 Wiki。上下文是否准确、完整，会直接影响 Agent 后续的代码理解和修改效果。随着代码库和用户规模持续增长，检索系统也必须同时满足成本、时延、隔离和稳定性要求。

检索不是"塞入更多代码"，而是找到完成任务所需的上下文

Qoder 面向个人和团队提供 Agentic Coding 平台，产品形态覆盖 Desktop、IDE、JetBrains 插件、CLI 和 Mobile，并通过 Agent SDK、Cloud Agents 等方式开放 Agent 能力。不同入口背后有一个共同需求：让 Agent 理解用户正在处理的任务，以及任务背后的项目上下文。

以修改一个功能为例，Agent 不仅要知道相关代码在哪里，还要理解调用关系、项目约定和历史变更。全量代码难以直接放入模型上下文，检索系统需要先定位与当前任务相关的信息，再补充必要依赖和背景。这类检索会贯穿开发任务的多轮交互，单次查询的延迟和成本会直接影响整体体验与服务成本。同时，不同代码库的访问频率差异明显：活跃工作区需要持续、快速地获取上下文，低频代码库则需要低成本保存，并在再次访问时及时响应。Qoder 因此提出多项基础设施目标，包括单个代码库月成本不超过1元、P95 检索耗时不超过100毫秒、支撑千万级租户，并兼顾热点数据访问与冷数据首次查询。（注：这些数字是选型与架构目标，不等同于当前生产实测规模。）

一个 Codebase 对应一个 Slice，让全局规模不成为单次查询负担

面向海量多租户场景，阿里云 Elasticsearch Agent 引擎版通过 Collection 与 Slice 组织业务数据。在 Qoder 的映射关系中，同维度向量进入对应 Collection，一个 Codebase 对应一个 Slice，一段代码 Chunk 对应一个 Document。查询限定在目标 Slice 内，只触达当前代码库的数据，既保持租户隔离，也避免让全局数据规模直接转化为每次检索的扫描负担。

演讲材料展示，在特定参考负载下，热查 P99 约为60毫秒、召回率不低于95%；亿级租户和千亿级向量则代表产品设计容量，而非 Qoder 当前租户数。成本侧采用对象存储承载大容量数据，以 SSD 和内存缓存服务活跃访问，冷数据无需全部长期占用高性能介质。一个 Codebase 对应一个 Slice，是 Qoder 在多租隔离、资源共享和按需访问之间取得平衡的关键。

一次用户查询进入 Qoder 后，会先经过查询处理、改写和意图识别，再通过向量、关键词、符号、提交记录和 Wiki 等通道进行多路召回。结果合并去重后，系统继续构建子图、扩展调用与依赖关系，最后完成排序和上下文融合。夏晓文表示："ES Agent 引擎版承担其中的向量召回能力，完整检索链路还包括前后的理解、扩展和结果处理。"

从请求成功到业务成功，生产化要覆盖每一个工程环节

索引构建从上传开始：Manager 接收任务并通过消息队列调度 Workers，Workers 调用 Embedding Service 生成向量，再分别写入 KV Cache 和 Elasticsearch。业务侧通过统一接口提供写入、查询和生命周期能力，同时持久化每个 Codebase 的实际后端路由，确保后续读写落到一致的存储目标。

进入生产后，系统需要处理大量容易被忽略的细节。Collection 和 Slice 在首次非空写入时按需创建；Bulk 请求按报文大小分批提交，并逐项检查执行结果，因为 HTTP 成功并不代表每条写入都成功；查询必须明确指定 Slice 和过滤条件，限定召回范围；底层分数还要经过归一化处理，与上层阈值语义保持一致。

安全与可靠性同样贯穿全链路。演讲介绍，Qoder 在 Elasticsearch 中只保存向量及必要的位置等元数据，不保存原始代码或代码 Chunk 正文。查询侧采用多节点和副本配置，客户端区分读写地址，并对适合重试的暂态错误进行处理；运维侧通过 Trace 和 Codebase 串联入口、实际后端、HTTP 请求、Bulk 单条结果和耗时。生产可靠性的验收标准不是"接口返回成功"，而是业务读写成功、数据完整，并能够在故障后恢复。

千亿级文档进入生产运行，性能、吞吐与成本按明确口径评估

根据演讲披露，Qoder 当前相关存储文档规模已达到千亿级，写入资源为30多台 ECS，查询资源为5台以上 ECS；最高支持查询 QPS 1000，Agent 并发检索 QPS 超过20，写入峰值超过1GB/s。以每个代码库1万条向量、共享集群及指定折后价格估算，单 Codebase 月均基础设施成本约为0.016元。该数字是特定假设下的基础设施分摊估算，不是固定价格，也不代表完整业务成本。

在演讲展示的 Qoder 测试口径中，Elasticsearch 纯向量召回阶段的 P50 和 P95 分别为11.73毫秒和14毫秒，同类产品分别为30.47毫秒和36.25毫秒，P95 降幅约61.4%；写入带宽展示值为2GB/s，对比400MB/s，约为5倍；以同类产品总体成本为100%，Elasticsearch 对应值约为15%。上述时延、写入和成本数据采用不同测试与测算条件，不应组合外推为所有负载下的统一结果；实际表现会随数据规模、资源配置、并发和缓存状态变化。

从代码检索走向代码、记忆与知识的融合检索

代码检索只是 Agent 上下文工程的一部分。Qoder 还计划将同一套工程能力扩展到用户与项目记忆、企业知识库和跨仓库知识：记忆需要关注隔离、时效和删除机制；企业知识库需要在文档与 Wiki 混合检索时执行权限过滤，并保留来源和版本；跨仓库知识则需要关联代码、Issue 与评审记录，为跨项目任务补充可追溯背景。

未来，Agent 可先识别任务目标与授权范围，再选择代码、记忆或知识库检索器，对不同来源的结果统一去重和重排。在有限 Token 预算内保留最有帮助的内容，同时保留证据来源，是融合检索继续演进的核心方向。演讲提出，Qoder 将继续探索代码、记忆与企业知识的融合检索，让 Agent 获得更相关、来源更明确、也更可解释的上下文。