从 RAG 到 Agent：Milvus 向量数据湖与 Context Engineering 实践

导语

随着 AI 应用从无状态的 Chatbot 向有状态的 Agent 演进，系统的交互模式从单次推理转变为依赖长周期上下文的动态决策。在这一演进中，Context Engineering（上下文工程）取代单纯的提示词工程，成为决定 Agent 智商上限的关键。传统向量库在应对海量多模态数据时，暴露出扩展性差、成本高及访问灵活性不足的短板。本文将拆解基于 Milvus 构建向量数据湖的湖仓一体架构实践，探讨如何解决多模态存储、Schema 演进、多租户隔离及冷热分层问题，为 Agent 提供高质量的上下文底座。

核心问题与挑战

在向 Agent 架构跃迁的过程中，传统数据基础设施面临以下核心冲突：

• 存储格式错配：Parquet 作为 OLAP 时代的利器，其固定的 RowGroup 设定在向量点查与宽窄列共存的场景下性能极差，宽列读取引发大量无效 I/O。
• 多租户计算扇出：多租户场景下，离散的租户数据导致查询时的计算扇出严重，标量过滤开销急剧上升。
• Context 质量低下：单一检索通道返回的上下文质量差，直接引发大模型的幻觉放大、推理失焦与上下文冲突。
• 非结构化索引缺失：传统数据湖对非结构化数据缺乏原生的搜索与索引支持，无法满足语义检索需求。

方案与实践

向量数据湖：非结构化数据的统一底座

要解决 Parquet 在向量点查下的原罪，核心在于打破固定 RowGroup 的束缚，实施宽窄列分离。窄列合并存储以提升点查效率，宽列分离存储以避免误读，同时 RowGroup 大小支持动态调整。在格式统一上，远端存储采用适应对象存储的格式，近端内存则通过 Apache Arrow 统一内存布局，兼容多执行引擎，各取所长。

针对动态 Schema 场景，引入 JSON Shredding 机制：自动分析字段频率，高频字段提取为独立列，低频字段构建倒排索引。无需人工配置，即可将查询性能提升 14~89 倍。对于结构化多模态数据，利用 Struct 实现语义嵌套建模，业务实体与 Row 一一映射，降低冗余存储的同时支持列式索引。

湖仓一体架构：移动计算与高质量搜索

在数据湖基础上构建湖仓一体架构，核心逻辑是移动计算而非移动数据。通过1’对于已有数据湖的场景，向>&8@向量(向量处理能力作为外置能力通过, 通过外表架构实现全局一份数!拒绝&拒绝数据冗余。底层基于 S3、etcd 与 Kubernetes 构建云原生基座，实现存算完全分离与多引擎协同。

搜索层面，单一稠密检索无法满足 Agent 对高质量 Context 的苛求。必须引入 Sparse+Dense 混合检索、GraphRAG 以及 Rerank 流水线，通过多路召回与重排，精准过滤噪声，解决幻觉与失焦问题。数据类型层面，原生覆盖 FloatVector、SparseFloatVector、地理空间与文本等复合类型，从底层支撑多模态统一检索。

海量数据治理：多租户与冷热分层

多租户架构需要在隔离性与性能间取得权衡。相比于粗粒度的 Collection 级隔离，采用 PartitionKey 分桶策略，在保障数据隔离的前提下，大幅降低资源开销。针对租户数据离散写入导致的计算扇出，引入后台数据重构富集机制，结合 LSM 模式分摊写放大，将同租户数据物理聚集，显著减少查询时的过滤开销。

在成本侧，实施智能冷热分层存储。基于时间与容量维度设计动态驱逐策略，热数据驻留内存与 SSD，冷数据沉降至对象存储，实现性能与成本的最优解。

原则/方法论沉淀

在向量数据湖的工程实践中，以下四项原则被验证为架构演进的基石：

1. 索引是向量数据湖的一等公民：索引即数据，向量数据湖不仅服务于批处理查询，更需通过 SOTA 索引保障在线检索的极低延迟。
2. 移动计算比移动数据更划算：在湖仓架构中，将向量检索能力推向数据侧，避免 PB 级数据的跨系统搬移。
3. 语义宽表建模避免 JOIN/聚合损耗：单表承载完整业务实体，消除多表关联与聚合带来的性能损耗与开发负担。
4. Schema Evolution 需支持零重建与无缝回填：数据在持续挖掘中迭代，Schema 变更不能阻断业务，需支持即时即用与列级权限控制。

总结与行动建议

从 RAG 到 Agent 的演进，本质是对 Context 质量与数据规模的极限挑战。Milvus 通过向量数据湖与湖仓一体架构，将非结构化数据的存储、索引、检索与治理拉通，为有状态 Agent 提供了坚实的记忆底座。

行动建议：

• 重构存储选型：如果你的向量库仍在强依赖 Parquet 的宽表读取，立即评估宽窄列分离方案，解决点查 I/O 放大问题。
• 升级检索链路：放弃单路 Dense 检索，尽快上线 Sparse+Dense+Rerank 流水线，这是目前压制大模型幻觉性价比最高的手段。
• 审视多租户模型：评估当前多租户架构的扇出比，若过滤开销居高不下，着手引入 PartitionKey 分桶与后台数据富集重构。

开放问题与延伸方向

1. 宽窄列分离的基准验证：十亿级向量点查与标量过滤混合场景下的 P99 延迟与 IOPS 基准数据是多少？（需量化验证方案的实际收益边界）
2. PartitionKey 的数据倾斜极限：超大规模租户是否会导致单桶热点并击穿存算上限？（关联多租户分桶方案的容灾设计）
3. 湖仓外表的元数据一致性：高频 Schema 变更下，跨系统松耦合是否易引发幽灵故障？（关联移动计算原则的工程落地风险）
4. Schema Evolution 的版本隔离：能否引入类 Git Branch 机制支持 Agent 多分支上下文的 A/B 测试？（关联零重建原则的延伸能力）
5. 索引下推与 OLAP 引擎复用：索引作为一等公民，能否让传统 OLAP 引擎直接复用向量索引下推？（关联索引原则的生态收益）
6. 跨云联邦查询的移动计算失效：跨可用区或跨云场景下，带宽与合规是否导致该原则彻底失效？（关联移动计算原则的物理边界）
7. 混合搜索流水线的性能剖析：Sparse+Dense 与 GraphRAG 流水线中，重计算 Rerank 是否成为吞吐绝对瓶颈？（关联高质量搜索方案的工程调优）
8. 大模型驱动的动态无 Schema：是否考虑引入 LLM 作为 Schema 推断引擎实现实时向量化？（关联 JSON Shredding 与多模态归纳的替代路径）
9. Agent 架构的工程验证优先级：长上下文持久化回放与多轮推理并发一致性，哪个更亟待验证？（关联有状态 Agent 演进的核心阻塞点）
10. 冷热分层的雪崩风险：Agent 记忆召回的强时效突发特征，是否会导致冷数据频繁回热引发 IO 雪崩？（关联智能驱逐策略的稳定性挑战）