写在前面欢迎大家关注Rocky的知乎Rocky Ding《三年面试五年模拟》AIGC/LLM/AI Agent算法工程师/开发工程师求职面试秘籍独家资源【三年面试五年模拟】WeThinkIn/AIGC-Interview-Book欢迎大家StarRocky最新撰写的10万字AI AgentAI智能体深入浅出全维度解析文章深入浅出完整解析AI AgentAI智能体的核心基础知识AIGC/LLM/AI Agent算法岗/开发岗求职面试内推学习社群涵盖AIGC、LLM大模型、AI Agent、传统深度学习、自动驾驶、机器学习、计算机视觉、自然语言处理、强化学习、大数据挖掘、具身智能、元宇宙、AGI等AI行业最新面试干货经验与核心知识欢迎大家加入https://t.zsxq.com/33pJ0大家好我是Rocky。核心判断Milvus 3.0 的价值不是再把 ANN近似最近邻搜索做快一点而是把“数据湖里的数据、向量索引、检索计算和离线迭代”重新接成一条链。它正在从向量数据库走向面向 AI 检索的湖原生数据基础设施。2026 年 7 月 29 日Milvus 3.0.0 正式发布。这个版本很容易被写成一张新功能清单External Collections、Storage V3、Snapshot、StructArray、SINDI、服务端排序、聚合、分面搜索……但真正值得讨论的并不是功能数量而是它改变了向量数据库的默认假设过去数据先搬进数据库数据库再负责索引和查询Milvus 3.0 开始尝试让数据继续留在对象存储和开放表格式中检索引擎主动“走向数据”。过去应用层负责召回、排序、聚合、切分和二次处理Milvus 3.0 开始把更多计算下推到引擎内部。这不是一次 API 叠加而是数据面和计算面同时变化。公众号文章《官宣开源Milvus 3.0 正式发布》把这条路线概括为“更 LakeNative 的服务更多的检索类型支持更少的服务端后处理”。官方 release notes、GitHub v3.0.0 发布说明和 LF AI Data 的公告基本印证了这条主线但生产团队仍然需要注意Storage V3 默认关闭新索引版本暂时需要手动启用某些能力仍处在后续路线图中。一、先把 Milvus 3.0 放回技术周期里Milvus 早期解决的是一个非常具体、也非常关键的问题如何在海量向量上提供高性能相似度搜索。随着 RAG、推荐、图像搜索和多模态应用进入生产问题已经变了。团队不再只问“向量能不能搜到”而会继续追问Embedding 是否必须复制一份到向量数据库Embedding 模型升级时是否需要停机重建整个 Collection检索后的排序、聚合、分面和 rerank 是否还要在应用服务里反复实现文档的多个 Chunk、图片的多个 Patch、商品的多张图片能不能以一个实体被管理在线检索和离线去重、聚类、评估、回填是否可以共享同一份一致数据视图Milvus 3.0 的回答不是“把向量数据库做成万能数据库”而是把向量检索放回 AI 数据生命周期数据湖负责开放、低成本和治理Milvus 负责索引、检索和一部分计算Spark 等批处理系统负责离线迭代应用只消费更接近最终业务语义的结果。本质上Milvus 3.0 不是从 2.x 走向更大的向量数据库而是在尝试定义一个 Vector Lake 的开源底座。二、Lake-native数据不搬家检索能力走向数据1. External Collections从“导入数据库”变成“注册数据湖”在传统 RAG 管道里团队往往要把 Parquet、Lance、Iceberg 或对象存储中的数据复制到向量数据库再生成索引。这条路径简单、延迟可控但代价也很现实多一份存储、多一套同步任务、多一个数据治理边界。Milvus 3.0 的 External Collections 提供了另一种路径把外部表或文件注册为 Collection字段映射到 Milvus SchemaMilvus 在原数据位置上建立向量、BM25、JSON 和标量索引并通过统一 API 提供检索。数据更新后系统按照 Manifest 识别新增分片避免每次都做全量复制。这个设计的关键不是“少写几行 ETL”而是把数据所有权和计算位置拆开了。数据团队可以继续用湖仓系统管理原始数据和 Embedding检索团队则可以把 ANN 和混合检索能力接到同一份数据上。但它有明确边界External Collections 适合数据源在 Milvus 之外、更新相对可控、需要长期留存或跨系统复用的场景。对于高频写入、极低延迟、强实时一致性的在线业务原生 Collection 仍然更合适。Lake-native 不是免费午餐它把复制成本换成了对象存储随机读取、Manifest 刷新和索引生命周期管理。2. Loon / Storage V3解决对象存储的随机点查只把数据放在 S3 兼容对象存储上还不能自动得到在线检索能力。ANN 索引通常先返回候选 ID再根据 ID 读取文本、标签和其他字段。如果底层格式只擅长全表扫描少量点查也可能造成巨大的读放大。Milvus 3.0 的 LoonStorage V3采用基于 Manifest 的列式布局把字段组织成可独立管理的 ColumnGroup并让索引和数据格式解耦。Lance、Iceberg、Parquet、Vortex 等开放格式可以进入同一条检索路径新增或删除字段主要修改元数据回填新字段则追加新的 ColumnGroup不必重写全部历史列。公众号文章引用了一个内部测试300 万行、128 维向量、S3 对象存储、256 个并发读取器条件下Parquet 单次点查 I/O 约 9.4 MBLoon Vortex 约 0.07 MB读取量减少约 135 倍。这个数字说明存储布局确实可能改变对象存储的可用边界但它不是所有数据规模、网络环境和查询模式下的保证。对象存储的网络往返和本地内存之间仍有物理差距未来的谓词下推和本地 Vortex 版本也说明这条路径还在继续演进。更值得关注的是兼容性v3.0.0 中 Storage V3 默认关闭依赖它的 Snapshot、TEXT 等能力需要手动开启。启用改变序列化数据格式的能力后2.6 到 3.0 的回滚保证不再适用。生产升级必须把“功能开关、数据格式、回滚策略”当成一个整体评估。3. Snapshot、Spark 和在线 Schema把数据迭代拉回同一条链AI 检索系统真正消耗工程时间的地方通常不在第一次建库而在第二十次模型升级、去重、评估和回填。Snapshot 提供某个时间点的只读视图主要记录现有数据文件、索引文件和元数据文件的引用而不是完整复制数据。因此它适合模型切换前的稳定输入、Embedding 重生成、回填校验、隔离测试和逻辑恢复。它不是长期灾备的 Backup底层对象存储和网络仍然是共享的这个边界不能被“低成本快照”四个字掩盖。Spark DataSource V2 Connector 则把这份一致视图接入 Spark、Databricks 和 EMR。去重、聚类、异常检测、生成新 Embedding、效果评估等离线任务可以直接读写 Milvus 数据不必每一步都把完整 Collection 导出到另一套系统。在线 Schema 变更补上了生产系统的最后一块拼图3.0.0 支持服务不中断地增加、填充和删除字段。内核内置 Backfill 可以从现有文本字段派生 BM25 或 MinHash 等结果外部 Backfill 则可以采用“Snapshot → Spark 计算 → 写回 → 增量建索引”的路线。当前版本对外部回填和谓词下推仍有路线图项不能把规划能力写成已经全面可用。三、检索引擎的变化少一点应用层拼装多一点端到端语义向量检索在生产中从来不是一个单独的 Top-K。用户最终看到的结果还要经过库存、价格、权限、时效、文档类型、租户和多路召回融合。Milvus 3.0 的第二条主线是把这部分原本散落在应用服务里的后处理下推到引擎。1. ORDER BY、聚合与分面让结果更接近业务答案服务端 ORDER BY 支持在 Query 或 Search 路径中按标量字段排序。对于 ANN Search它是在已经召回的候选集上做业务字段重排而不是扩大 ANN 召回范围。这个限定非常重要ORDER BY 可以减少网络传输和客户端排序但不能补救召回阶段漏掉的候选。Query Aggregation 支持 COUNT、SUM、AVG、MIN、MAX 以及 group-byFaceted Search 则把品牌、价格带、颜色、租户或文档类型的分桶统计接到搜索路径。商品搜索的筛选侧栏、知识库的文档类型统计可以由一次请求返回而不是客户端过度召回后再自己统计。这里要区分两种“精确”Query 侧聚合可以对过滤后的全量数据做精确统计Search 侧分面只对 ANN 已召回候选集统计是检索结果语境下的近似计数。端到端并不等于语义自动正确系统仍需要明确统计口径。2. StructArray不要把文档、商品和视频切碎后再假装它们不存在长文档包含多个 Chunk视频包含多帧商品包含多角度图片ColBERT/ColPali 还会为 Token 或 Patch 生成多向量。把每个片段单独存成一行会重复复制权限、标签和业务元数据也会让“命中一个实体”与“命中一个片段”之间产生缝隙。StructArray 允许一行实体保存一个变长结构化数组并在其中放置多个向量和子字段。实体共享一个 ID元数据只维护一次检索时又可以在实体级和元素级之间选择粒度。3.0.0 还补齐了空值、Bitmap 索引、动态字段、部分更新、嵌套过滤和元素级 group-by 等能力。对于大规模多向量语料TokenANN、Muvera、Lemur 和 DiskANN 提供不同的内存、索引体积、训练成本与召回率权衡。公众号文章引用的 Lemur、TokenANN 比较是特定数据集上的实验观察不应被简化为“所有 ColBERT 场景都只需要一个向量”。文档长度分布、查询类型和召回目标都会改变最优选择。3. Sparse Index 与 SINDI混合检索的成本开始成为一等问题RAG 需要语义匹配也需要关键词、实体名和精确术语匹配。BM25 和 Learned Sparse Retrieval 因此越来越重要但稀疏向量的倒排列表可能很大随机内存访问和重复距离计算会吞掉吞吐。Milvus 3.0 使用分块压缩 Posting List并对 Inner Product 和 BM25 权重做量化官方发布说明称在相近召回下压缩 BM25 索引约为 2.6 版本的三分之一。SINDI 则通过 SIMD 批量累加、顺序访问倒排列表和保召回剪枝减少随机访存与冗余计算。对应论文在 Recall50 超过 99% 的条件下报告了相对于 SEISMIC 和 PyANNs 的 4.2× 到 26.4× 单线程 QPS 提升Milvus 官方内部测试则称在四个 SPLADE 数据集上SINDI 最高约为 MaxScore 的 10 倍。这些数字共同说明的是“算法和数据布局需要协同设计”而不是“上线后 QPS 自动提升十倍”。新索引版本在 3.0.0 中暂时是 opt-in需要调整dataCoord.targetVecIndexVersion和dataCoord.targetScalarIndexVersion工作负载、召回阈值、线程数和硬件条件都要进入自己的基准测试。四、其他增强很重要但不要让清单遮住主线Milvus 3.0.0 还加入或完善了Function Chain在一次请求中组合分数变换、模型 rerank、排序和候选裁剪减少客户端编排。TEXT 长文本字段短文本内联长文本以 Vortex LOB 文件存储向量与原文可以在同一数据面完成读取。FAISS passthrough通过 index-factory 字符串复用已有 FAISS 配方。Vortex 与 Lance前者偏向内部混合向量/标量存储后者承担开放生态互操作。Woodpecker 独立部署把写入路径上的 WAL 做成可独立扩缩、隔离故障和观测的服务。MinHash、Entity TTL、FileResource、Force Merge、Nullable vectors 等面向生产运维和数据生命周期的能力。如果把这些能力只理解成“功能更多”会错过 Milvus 3.0 的真正方向它在把检索系统从“向量索引服务”推向“可演进的数据计算服务”。五、Milvus 3.0 的生产边界它解决了什么又没有解决什么它解决的三类结构性问题数据副本问题外部数据可以在原位置建立检索路径减少一份长期副本和同步链路。检索后处理问题排序、聚合、分面、rerank 和部分结果裁剪下推到引擎减少网络和重复代码。数据演进问题Snapshot、在线 Schema 和 Backfill 让 Embedding 模型、稀疏字段和业务标签可以渐进式变化。它没有自动解决的三类问题召回质量ORDER BY 只能重排已召回候选SINDI 的速度也不能替代 Embedding、切分和评估设计。一致性与灾备Snapshot 是低成本逻辑视图不是独立物理备份对象存储和网络依赖仍然存在。运维复杂度Lake-native 需要理解开放格式、Manifest、索引版本、数据格式兼容和对象存储成本系统边界变宽了运维责任不会凭空消失。因此生产选型不应该是“3.0 一定替代 2.6”而应该按工作负载分层实时写入和极低延迟优先原生 Collection湖仓复用、批处理迭代和多模型回填优先评估 External Collections多向量检索、混合检索和复杂业务排序则需要把端到端检索能力纳入基准。六、Milvus 3.0 与 Vector Lakebase开源底座和托管产品不是一回事指定公众号把 Milvus 3.0 与 Zilliz Vector Lakebase 放在一起讨论这个关系需要读得更准确。Milvus 3.0 是 LF AI Data 生态中的开源项目和可自行部署的软件发行版Vector Lakebase 是 Zilliz 对湖原生向量数据基础设施的产品化表达。两者可以共享架构方向和 API 兼容性但托管产品的弹性算力、跨区域容灾、BYOC、安全合规和 SLA 属于厂商产品能力不能自动归因于开源 Milvus 本身。公众号中的“10× 更快”“99.99% SLA”等表述应按厂商对其托管服务的声明理解不能当作开源版本的通用基准。这也是 AI 基础设施最容易被忽略的分界线开源项目提供可检查、可部署、可迁移的技术底座商业云服务提供运维、弹性、合规和交付确定性。二者可以相互促进但价值判断必须分开。七、Rocky 的跨周期判断向量数据库正在退到“数据基础设施”这个更大的位置向量数据库的第一阶段是证明“向量搜索值得独立出来”。第二阶段是把向量搜索做成可扩展、可观测、可被企业使用的服务。Milvus 3.0 暗示的第三阶段是让向量检索不再要求数据迁移并让检索、分析和离线迭代共享同一个数据面。真正的变化不是 Milvus 多了多少 API而是“数据在哪里”和“计算在哪里”不再被同一套数据库边界绑定。这件事对不同角色的启发也不同对 AI 算法工程师重点从“选一个最强索引”扩展到 Embedding、稠密/稀疏混合、数据格式、回填策略和评估闭环。对 AI 应用开发者重点从“把结果拉回来再处理”扩展到设计可下推的过滤、排序、聚合和 rerank 语义。对数据平台团队重点从“建一套向量库”扩展到管理湖仓、对象存储、Manifest、Snapshot 和索引版本的协同。对创业者和投资人真正应该问的不是“又一个向量数据库吗”而是它是否能在模型和 API 逐渐商品化后沉淀成数据、工作流、交付和运维基础设施。工具红利会被下一代平台吸收认知红利则来自对数据生命周期、检索机制和生产约束的理解。Milvus 3.0 的长期价值不在于让所有团队立刻迁移而在于它把 AI 检索的竞争从单点 ANN 性能推向了更难、也更有持续价值的系统问题数据副本、计算位置、检索语义、演进成本和可靠性边界。推荐阅读1. 深入浅出完整解析AI AgentAI智能体的核心基础知识2025年可以说是AI Agent全面落地应用的元年因此Rocky在持续撰写对AI Agent的全维度解析文章深入浅出完整解析AI AgentAI智能体的核心基础知识2. 深入浅出完整解析扩散模型DDPM、DDIM、Score-Based、SDE、LDM、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识Rocky对扩散模型的本质原理与和核心基础知识进行了全面系统的深入浅出分析讲解同时不断跟进补充扩散模型的最新技术发展希望能给大家带来帮助深入浅出完整解析扩散模型DDPM、DDIM、Score-Based、SDE、LDM、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识3. 入浅出完整解析FLUX.2、Seedream即梦、Z-image、GLM-Image核心基础知识Rocky对AIGC时代“中场时刻”之后的主流AIGC创作大模型的核心基础知识进行了全面系统的深入浅出分析讲解力求让大家通俗易懂理解AIGC时代的技术浪潮的本质价值入浅出完整解析FLUX.2、Seedream即梦、Z-image、GLM-Image核心基础知识4. 深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识Rocky对FLUX.1 Kontext和FLUX.1 Krea的核心基础知识作了全面系统的梳理与解析深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识5. 深入浅出完整解析DeepSeek系列核心基础知识Rocky对DeepSeek系列模型的核心基础知识作了全面系统的梳理与解析深入浅出完整解析DeepSeek系列核心基础知识6. 深入浅出完整解析Stable Diffusion 3SD 3和FLUX.1系列核心基础知识Rocky对Stable Diffusion 3和FLUX.1的核心基础知识作了全面系统的梳理与解析深入浅出完整解析Stable Diffusion 3SD 3和FLUX.1系列核心基础知识7. 深入浅出完整解析Stable Diffusion XLSDXL核心基础知识Rocky对Stable Diffusion XL的核心基础知识作了全面系统的梳理与解析深入浅出完整解析Stable Diffusion XLSDXL核心基础知识8. 深入浅出完整解析Stable DiffusionSD核心基础知识Rocky对Stable Diffusion 1.x-2.x系列模型的核心基础知识做了全面系统的梳理与解析深入浅出完整解析Stable DiffusionSD核心基础知识9. 深入浅出完整解析Stable Diffusion中U-Net的前世今生与核心知识Rocky对Stable Diffusion中最为关键的U-Net结构进行了深入浅出的全面解析包括其在传统深度学习中的价值和在AIGC中的价值深入浅出完整解析Stable Diffusion中U-Net的前世今生与核心知识10. 深入浅出完整解析LoRALow-Rank Adaptation模型核心基础知识对于AIGC时代中的“ResNet”——LoRA模型Rocky进行了深入浅出的全面讲解深入浅出完整解析LoRALow-Rank Adaptation模型核心基础知识11. 深入浅出完整解析ControlNet核心基础知识AIGC图像创作开源社区已经形成以Stable Difffusion/FLUX为核心ConrtolNet和LoRA作为首要AI辅助工具的变化万千的AIGC图像创作工作流。ControlNet正是让AI图像创作社区无比繁荣的关键一环它让AIGC图像创作过程更加的可控更有助于广泛地将AIGC算法解决方案应用到各行各业中深入浅出完整解析ControlNet核心基础知识12. 深入浅出完整解析Sora、Seedance、keling等AI视频大模型核心基础知识AI绘画和AI视频是两个互相促进、相互交融的领域2024年无疑是AI视频领域的爆发之年Rocky对AI视频领域核心的Sora、Seedance、Keling等大模型进行了全面系统的梳理与解析深入浅出完整解析Sora、Seedance、keling等AI视频大模型核心基础知识13. 深入浅出完整解析AIGC时代Transformer核心基础知识在AIGC时代中Transformer为AI行业带来了深刻的变革。Transformer架构正在一步一步重构所有的AI技术方向成为AI技术架构大一统与多模态整合的关键核心基座大有一统“AI江湖”之势。Rocky也对Transformer模型进行持续的深入浅出梳理与解析深入浅出完整解析AIGC时代Transformer核心基础知识14. 深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识AIGC创作框架正是AIGC算法工作流的运行载体目前主流的AIGC创作框架有ComfyUI、Diffusers、Stable Diffusion WebUI等。在传统深度学习时代PyTorch、TensorFlow以及Caffe是传统深度学习模型的基础运行框架到了AIGC时代Rocky相信ComfyUI就是AIGC时代的“PyTorch”、Stable Diffusion WebUI就是AIGC时代的“TensorFlow”、Diffusers就是AIGC时代的“Caffe”深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识15. 深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识在AIGC时代中如何快速转身入局AIGC产业如何成为AIGC/LLM/AI Agent算法/开发工程师如何在学校中系统性学习AIGC/LLM/AI Agent知识斩获心仪的AIGC/LLM/AI Agent算法/开发offerDon‘t worryRocky为大家总结整理了全面的AIGC/LLM/AI Agent算法/开发工程师成长秘籍为大家答疑解惑希望能给大家带来帮助手把手教你成为AIGC/LLM/AI Agent算法/开发工程师斩获AIGC/LLM/AI Agent算法/开发offer16. AIGC产业的深度思考与分析2023年3月21日微软创始人比尔·盖茨在其博客文章《The Age of AI has begun》中表示自从1980年首次看到图形用户界面graphical user interface以来以OpenAI为代表的科技公司发布的AIGC模型是他所见过的最具革命性的技术进步。Rocky也认为AIGC及其生态会成为AI行业重大变革的主导力量。AIGC会带来一个全新的红利期未来随着AIGC的全面落地和深度商用会深刻改变我们的工作、生活、学习以及交流方式各行各业都将被重新定义过程会非常有趣。那么在此基础上我们该如何更好的审视AIGC的未来我们该如何更好地拥抱AIGC引领的革新Rocky准备从技术、产品、商业模式、长期主义等维度持续分享一些个人的核心思考与观点希望能帮助各位读者对AIGC有一个全面的了解深入浅出全面解析AIGC时代核心价值与发展趋势2025年版17. AI算法工程师的独孤九剑秘籍为了方便大家实习、校招以及社招的面试准备同时帮助大家提升扩展技术基本面Rocky将符合大厂和AI独角兽价值的算法高频面试知识点撰写总结成《三年面试五年模拟》之独孤九剑秘籍:【三年面试五年模拟】AIGC时代的算法工程师的求职面试秘籍持续更新中18. 深入浅出完整解析AIGC时代中GANGenerative Adversarial Network系列模型核心基础知识GAN系列模型作为传统深度学习时代的最热门生成式Al模型在AIGC时代继续繁荣作为Stable Diffusion/FLUX系列大模型的“得力助手”广泛活跃于AlGC图像创作的产品与工作流中深入浅出完整解析AIGC时代中GANGenerative Adversarial Network系列模型核心基础知识