深圳Meetup回顾｜Zilliz、货拉拉、Teamily 、MemoraX 、Google Cloud的Milvus实践分享

10 月 31 日， Unstructured Data Meetup 更名为Milvus Meetup 后，首站来到深圳。这一次，讨论仍然围绕AI与非结构化数据展开，但我们所关注的问题，已经延伸到了检索系统之外。

当向量检索落地到实际业务，团队需要同时处理精确匹配与语义召回，在持续增长的数据规模下控制延迟和成本。在 Agent 场景中，检索对象又进一步扩展：除了文档和图片，还有 Agent 本身、任务交付物、用户偏好和历史执行经验。数据能否被找到，找到以后能否被正确理解，以及这些信息能否帮助下一次任务，都是我们要关心的重点。

本次活动的五场分享，从不同层面给出了他们的解法。Zilliz 介绍了 Milvus 3.0 的全文检索与混合搜索能力；货拉拉拆解了风控、GraphRAG 和 NL2SQL 的生产实践；Teamily AI 分享了小团队如何通过统一检索服务支撑多 Agent 产品；MemoraX AI 讨论了记忆如何通过学习得到改善；Google Cloud 则将视角扩展到企业上下文与数据平台。

01 Milvus 3.0：在同一套引擎中连接关键词与语义

Zilliz 首席开源布道师李成龙带来的主题是《Milvus 3.0：更快、更强的全文检索》。这场分享围绕一个常见的工程问题展开：当业务同时需要关键词检索和向量检索时，系统应该怎样组织这两种能力？

关键词与语义承担着不同的职责。API 名称、版本号、商品型号和错误信息，需要保留准确的字面信号；用户用自然语言描述需求时，又需要系统理解表达背后的含义。例如，“如何让数据导入更快”和某个具体配置项可能指向同一份技术文档，但适合采用的召回方式并不相同。

过去，这类需求经常通过 Elasticsearch 与向量数据库组合实现。两套系统分别召回，再由应用层完成融合。这意味着团队需要维护两条写入链路、处理数据同步，并解决不同打分方式之间的衔接。随着数据规模和查询复杂度增加，这些工作也会成为检索系统的一部分成本。

Milvus 在多个版本中持续补充全文检索能力，让开发者能够在同一套引擎中组合 BM25、向量检索和标量过滤，并通过 RRF 或加权方式融合结果。围绕这条查询链路，多语言分析、自定义词典、短语匹配和高亮等能力，帮助系统保留更完整的文本信号；分组、聚合与业务排序，则让搜索结果能够进一步适应具体的产品需求。

实际生产中，已经有美团将百亿级数据从 ES 迁移至 Milvus，单表支持 20 亿条向量，1 亿条 768 维向量场景下 QPS 可达 1000，P99 延迟仅 8.1 毫秒。快手使用 Milvus 解决 ES 读写资源争用、维度上限仅 4096 的问题，内部已部署 100 余套生产集群，最大 QPS 超 1 万。

02 货拉拉：风控、GraphRAG 与 NL2SQL 的业务实践

货拉拉大数据技术与产研部资深大数据工程师高佳庆的分享，讲述了货拉拉如何将向量检索用于文本风控、图片风控、GraphRAG 和 NL2SQL 等多个场景。

风控首先面临的是表达变化。广告和引流文本可以通过插入空格、符号或替换措辞绕过关键词规则，但它们的意图仍然接近。货拉拉选择将已经识别的风险样本沉淀为向量，在新文本进入时检索相近样本，再结合相似度阈值和规则引擎完成判断。需求上，货拉拉文本风控的日均检索量达到百万级，P99 检索延迟需要控制在 50 毫秒以内。最终货拉拉选择了Milvus 负责提供候选，后续的拦截、标记和人工复核继续由风控策略决定。为了兼顾延迟与召回要求，团队选择 HNSW 索引，并在低峰期批量更新风险样本，将一部分构建成本移到离线链路。

图片侧面对的则是日均千万级装卸货凭证。链路从 Spark 批处理开始，经过图片下载、自研视觉特征模型推理，再将向量批量写入 Milvus。团队通过异步请求减少等待，并控制送入 Triton 的批次大小，提高 GPU 利用率。在线查询使用同一套特征提取方式，将新图片与历史样本进行比较。

到了 GraphRAG，向量检索开始与团队原有的知识图谱能力结合。用户文档经过分块、实体与关系抽取后，分别进入 HugeGraph 和 Milvus。两个系统通过统一的实体标识连接起来：查询先在 Milvus 中找到语义相关的种子实体，再到图中展开邻居和关系，补充单个文本片段之外的关联知识。

知识更新的方式同样重要。团队通过内容指纹判断哪些片段发生了变化，避免相同内容重复嵌入和重复建图。同时，实体抽取受预定义类型约束，以减少模型自由生成带来的噪声。借助这一链路， GraphRAG 场景的问答准确率由 56% 提升至 78%。

NL2SQL 延续了这套设计，但对精确匹配提出了更高要求。用户问“上个月各个城市的完单量是多少”，模型需要知道完单量的定义、对应的数据表、城市维度的关联方式，以及退款订单是否纳入口径。其中一部分信息存在于元数据系统，另一部分分散在业务文档中。

货拉拉将两类信息对齐到同一套实体体系，并通过向量、全文和图谱检索组合召回。向量负责连接自然语言与业务概念，全文检索保留表名、字段名等精确信息，图谱则补充关联路径。最终交给模型的是经过组织的表、列、指标和业务规则上下文。

生成以后，SQL 还要经过静态校验与引擎预检。对于不存在的表列、语法错误和类型冲突，系统将错误反馈给模型继续修正。现场交流也明确了这套机制的边界：能够执行的 SQL，仍然需要接受业务口径和结果正确性的检查，重要报表尤其如此。

03 Teamily AI：小团队如何构建统一检索服务

相比货拉拉的规模化业务，Teamily AI 的王祥更关注中小团队如何组织工程能力。他带来的《Agent 场景下的 Retrieval Serving 实践》，讨论了一个多 Agent 产品如何通过统一检索层减少重复建设。

Teamily AI 的产品形态，是让多个 Agent 和人在同一个群里协作。这会产生几类相互关联的需求：用户需要找到合适的 Agent，协作产生的文档、PPT 等交付物需要被搜索和推荐，用户与 Agent 的历史交互也需要沉淀为长期记忆。

这些业务的检索对象和排序策略各有差异，但底层操作有很强的共性。写入时，都需要定义字段、生成向量、保存记录并维护索引；读取时，都需要编码查询、召回候选、过滤和排序。如果分别实现，模型接入、失败重试、监控和索引维护就会在不同业务中重复出现。

为此，团队构建了统一的 Retrieval Serving 层，将 Milvus、模型推理服务及内容曝光状态管理等能力进行统一封装。上层业务负责定义检索对象、过滤条件与排序策略，底层则提供可复用的检索读写流程、性能优化与容错机制。例如，在模型服务层引入性能与成本感知的动态路由及自适应回退策略，根据服务延迟、成本和可用性选择合适的模型服务；当重排服务超时或异常时，自动回退至原有排序结果；同时结合内容曝光记录，对已读内容进行动态降权，提升检索结果的多样性与用户体验。

关于如何优化延迟，团队发现，多数场景下可省略 rerank 步骤，将在线串行 Reranker 替换为轻量逻辑回归打分，并调整召回策略，让原子事实参与检索。在测试环境的不同并发档位下，P90 延迟降低了 27%—72%。与此同时，LoCoMo 总体准确率由 88.96% 变为 88.12%，总体差异未达到统计显著。

04 MemoraX AI：让历史记忆参与下一次任务

MemoraX AI CTO 李栋在《从记忆系统到记忆基模》的主题分享中，介绍了 MemoraX 在学习式 Agent Memory 与记忆基模训练方面的技术探索。Agent 可以保存大量历史记录，但仍可能在新任务中遗失偏好、使用过期信息，或重复经历已经走过的试错过程。长期记忆的真正价值，不仅在于保存历史，更在于让有效信息与经验持续作用于未来任务。

不同于传统以信息存储和检索为核心的记忆系统，MemoraX 正在推动 Agent Memory 从依赖固定工程策略的外挂式系统，向具备自主学习能力的记忆模型演进。通过大模型专项后训练，让模型学习什么值得记住、如何精准检索，以及如何将历史经验转化为解决新问题的能力。

在技术实践中，MemoraX 基于大量真实 Agent 执行轨迹开展记忆模型训练，使模型能够自主提炼对未来任务有价值的事实、约束与可复用经验。同时，结合学习式检索、复杂查询编译与程序性记忆等技术，持续提升长期记忆的精准调用和跨任务复用能力。目前，相关模型训练与技术研究已取得显著成效，在多项记忆评测和复杂 Coding Agent 任务中展现出更强的记忆能力、更加稳定的任务表现及更高的执行效率。

面向未来，MemoraX 正进一步探索通过真实任务反馈驱动记忆模型持续训练，让记忆能力随着数据、训练规模与任务经验的积累不断提升，逐步从学习式记忆系统走向记忆原生模型，为 Agent 的长期学习与持续进化提供核心能力支撑。

05 Google Cloud：面向 Agent 的企业上下文与数据平台

Google Cloud 数据分析解决方案专家王淼的演讲《构建智能体时代的数据平台》则分析了当越来越多的数据访问由 Agent 发起，平台如何优化业务上下文、访问边界和运行成本。

人类分析师查询数据时，通常带着很多没有明确写下来的知识。他们知道哪些表可信、某个指标应该怎样计算，也能够察觉一个结果是否明显偏离常识。Agent 要完成同样的工作，就需要通过系统获得这些信息，否则即使 SQL 执行成功，也可能沿着错误口径继续推进后续任务。

因此，与此同时，数据平台负载从人类操作转向大量智能体访问，需要支撑更高并发，同时适配智能体编排、主动趋势预判等新场景。

给每个 Agent 编写 Skill 或指标说明，是一种直接的做法。但当企业中的 Agent 数量增加，指标定义又持续变化时，分散维护的文件会面临版本同步问题。同一个概念可能在不同工具中保留着不同解释，更新业务口径也可能需要修改多处内容。

Google Cloud 中，可以通过 Knowledge Catalog 产品统一聚合多源元数据，构建企业级统一上下文平台，解决智能体访问时口径不一致、上下文过期等问题。

另外，考虑到企业知识可能同时存在于数仓、业务数据库、对象存储和文档系统中。Google Cloud 与Zilliz都围绕开放湖仓、多模态 AI 函数和跨系统访问做了大量优化，帮助开发者减少为使用 AI 而反复导出、处理、回写数据的工作。比如，Milvus与Zilliz Cloud的 External Collection 能力可以直接访问湖仓数据。数仓中的分析能力、上下文层中的业务定义，以及向量系统中的检索能力，可以共同参与一次任务。