大模型必学：从RAG到Agent的演进，向量数据湖如何重构上下文工程？【收藏】

高级绘画师PP

652人浏览 · 2026-03-02 21:03:11

高级绘画师PP · 2026-03-02 21:03:11 发布

这是基于2025 AICon大会的Milvus负责人刘力《RAG+不止是检索：Milvus在Context Engineering中的湖仓一体实践》整理出的核心观点与关键技术要点总结。我认为接收一些会议/演讲类材料可用快速了解行业动态和趋势。

在这里插入图片描述

从 RAG 到 Agent：向量数据湖驱动下一代 Context Engineering

随着大模型应用从单轮问答（Chatbot）迈向多轮、有状态的智能体（Agent），上下文工程（Context Engineering） 成为提升 AI 应用能力的关键基础设施。传统 RAG（Retrieval-Augmented Generation）仅聚焦于“检索”，而现代 Agent 需要长期记忆、环境感知和动态上下文管理——这催生了对统一、可扩展、高性能的非结构化数据底座的需求。

向量数据湖

如上，向量数据湖（Vector Data Lake） 被提出作为新一代 Context 存储与处理平台，其核心目标是：以湖仓一体架构，统一管理多模态、海量、异构的上下文数据，并支持高效搜索、灵活演进与低成本治理。

一、Context Engineering 的三大支柱

1. 上下文的搜索

• 不再依赖单一稠密向量检索，而是融合 Dense + Sparse（如 BM25）+ Graph + 标量（时间、地理、JSON 等） 的混合搜索。
• 引入 Rerank、Time Decay、Highlight 等后处理机制，提升召回质量，避免“上下文污染”（Context Poisoning/Clash）。

1. 上下文的处理

• 支持多模态数据（文本、图像、表格、图谱）的统一建模，通过 语义宽表（Semantic Wide Table） 将一个业务实体（如一篇文档）完整表达为一行，避免多表 JOIN。
• 原生支持 Struct、JSON、Array、Geo、Time 等复合类型，并提供列式索引与自动 Schema 演进（Schema Evolution）。

1. 上下文的管理

• 构建 向量数据湖 作为非结构化数据的统一底座，兼容 Parquet、Lance、Vortex 等格式，通过 宽窄列分离、外部 Blob 存储、RowGroup 优化 解决传统 OLAP 格式在点查与向量场景下的性能瓶颈。
• 索引即数据：每种字段类型均可构建 SOTA 索引，支持百万级批量检索与低延迟在线查询。

二、湖仓一体架构的关键创新

• 存算完全分离：基于 S3 + Kubernetes + etcd 构建云原生架构，计算（查询、索引、Compaction）微服务化，弹性伸缩。
• 一份数据，多引擎协同：通过 Apache Arrow 生态对接 Spark、Flink 等计算引擎，支持离线批处理与在线查询共用同一份存储。
• 增量同步与外表支持：无需数据冗余，外置向量处理能力可直接作用于湖中数据，实现“移动计算而非移动数据”。

三、面向生产的大规模治理能力

• 多租户隔离：支持三种策略（Collection-per-Tenant、Partition Key、共享 Collection + 过滤），平衡隔离性与性能，可支撑百万级租户。
• 智能冷热分层：数据在 RAM / NVMe / S3 间自动流动，按时间或容量驱逐，小租户按租户粒度、大租户按聚类粒度管理，实现毫秒级热数据响应与低成本冷存储。
• 内置治理原语：原生支持 KMeans 聚类、去重、特征提取等，降低运维复杂度。

三大核心要点总结

1. RAG 正在进化为 Context Engineering：AI 应用从无状态问答走向有状态 Agent，要求上下文具备长期记忆、环境感知与动态管理能力，推动基础设施从“检索工具”升级为“上下文操作系统”。
1. 向量数据湖 = 统一底座 + 湖仓一体 + 多模态索引：通过兼容开放格式、存算分离、多引擎协同和 SOTA 索引体系，构建高性价比、高灵活性的非结构化数据管理平台，解决 RAG 中的数据孤岛与扩展瓶颈。
1. 生产级能力 = 多租户 + 冷热分层 + Schema 演进：面向企业级落地，必须支持细粒度隔离、智能存储分层、零停机字段变更与自动 JSON 结构优化，确保系统在规模、成本与敏捷性之间取得平衡。

从 RAG 到 Agent 时代的技术演进路径，可用看到出：未来的 AI 应用竞争力，不仅在于模型本身，更在于上下文基础设施的深度与效率。而 Milvus 所代表的向量数据湖确实在AI时代必不可少。