过去两年，大模型应用从演示走向生产，检索增强生成、语义搜索、推荐召回与多模态检索等场景，让“向量”这一数据形态的体量迅速膨胀。企业要把文档、图片、音频和用户行为编码成高维向量，并在海量向量里毫秒级找出最相近的若干条。这个看似简单的需求，正在推动原有大数据栈调整存储、计算与检索的结构。

从百万到十亿 规模跨越量级

早期向量检索多停留在百万级规模，单机内存即可承载。随着企业知识库、商品库和视频素材库整体被向量化，十亿级向量开始出现。规模跃升带来的第一个问题是内存：一条 768 维或 1024 维的浮点向量占用数千字节，十亿条就是数 TB 级内存，成本难以承受。于是量化压缩、磁盘索引和存算分离被推到台前，成为绕不开的工程选项。

索引与压缩决定成本与延迟

向量检索本质是近似最近邻搜索，主流做法大致有三类：

实际部署往往是组合拳：热数据放内存、冷数据沉到磁盘，再按业务对召回率的容忍度调节参数。工程团队越来越清楚，向量检索没有免费的午餐，召回率、延迟与成本三者之间必须做出取舍。

混合检索与多模态成为标配

纯向量检索并非万能。面对人名、型号、编号这类精确匹配需求，关键词检索依然更稳。因此，把 BM25 等稀疏检索与稠密向量检索结果融合的混合检索，正在成为搜索系统的新默认配置。与此同时，文本、图像、音频的向量被映射到同一语义空间，跨模态检索开始落地，以图搜图、以文检索视频片段等应用不再停留在概念阶段。

与湖仓和流处理衔接

向量数据并非孤立存在，它需要与结构化数据一起过滤、一起更新。于是向量能力正在向既有系统靠拢：关系数据库加入向量类型，搜索引擎内置向量字段，湖仓平台提供向量索引与批量生成能力。在实时链路中，流处理任务在写入特征的同时生成向量，保证检索结果与最新业务状态一致。这种让向量能力下沉到数据平台的趋势，减少了数据搬运与系统割裂。

评测与治理仍需补课

向量检索的评测长期缺少统一口径。不同数据集、不同召回率下比较延迟，结论往往不可比。近两年出现的公开评测基准，开始同时报告召回率、吞吐与成本，让选型更有依据。治理层面，向量同样面临权限、血缘和过期清理问题：谁能检索到哪些向量，向量由哪份原始文档生成，文档删除后向量如何同步失效，都需要纳入数据治理体系。

从趋势看，向量不会取代传统数据管理，而是成为大数据栈中新增的一类负载。谁能把向量索引、混合检索与数据治理打通，谁就更可能在智能应用的基础设施竞争中占得先机。