文档里说的“矢量”，就是“向量”（Vector）。文本、图片、音频经过 embedding 模型处理后，会变成一串浮点数，也就是高维向量。意思接近的内容，向量在空间里的距离也近。矢量检索要做的事很直接：在海量向量里，快速找出和查询最像的几条。
关键词检索靠字面匹配。用户搜“便宜的连衣裙”，如果商品标题写的是“平价裙子”，大概率搜不到。矢量检索能理解意思，把“平价裙子”“实惠款连衣裙”也找出来。现在做大模型应用，检索增强生成（RAG）基本都依赖这一步，知识库问答答得准不准，很大程度取决于召回质量。
阿里云的矢量检索能力分散在几个产品里，常见的有云原生向量数据库 Milvus 版、Tair 的向量检索功能、Elasticsearch 的向量字段，以及 AnalyticDB PostgreSQL 版的向量索引。各产品支持的索引类型、规格和价格差别不小，具体请以阿里云官方文档为准。
选型先看四件事
面对多个选项，团队一般会先回答下面四个问题：
- 数据规模：向量是百万级还是百亿级。规模越大，越需要分布式部署和专用索引。
- 查询方式：是纯向量查询，还是“向量加条件”的混合查询，比如只在某个类目、某个时间段内找相似内容。混合查询多的话，要确认所选产品的过滤性能。
- 写入频率：数据是一次性导入，还是每分钟都在更新。频繁更新的场景，要提前测写入延迟和索引更新的影响。
- 现有技术栈：如果团队已经在用 Elasticsearch 或 PostgreSQL，直接启用向量能力，运维成本通常最低。
一般来说，结构化数据已经很多、查询里常带业务过滤条件的，可以先在现有数据库或搜索引擎上试向量能力。向量规模大、增长快的，再考虑专用向量数据库，省得后期迁移。
案例一：电商以图搜图和相似推荐
某服装电商有约 300 万件商品，每件都有主图和文字描述。以前用户只能靠关键词搜。搜“碎花长裙”，风格相近但标题写成“印花连衣裙”的商品就漏掉了，转化一直上不去。
团队改了三步：
- 用图文 embedding 模型，把每件商品的主图和标题都转成向量，写入阿里云矢量检索服务。
- 用户上传照片时，先生成查询向量，再取 Top 50 相似商品。
- 召回结果再按库存、价格区间和类目过滤，已售罄或超出预算的商品直接剔除。
内部测试里，搜索结果页的点击率有提升。但团队没有只看点击，还同时跟踪加购率和退货率，确认推荐没有带来新的噪声。检索效果最终要用业务指标来判断，只盯召回率，很容易得出乐观的结论。
案例二：企业知识库问答
一家制造企业有上万页设备手册和维修记录。一线员工遇到故障，常常要在几十个 PDF 里翻找。团队想做一个问答助手，让员工直接提问。
方案分三步：
- 把文档切成约 500 字一段，每段带上设备型号、版本号等元数据。
- 用 embedding 模型把片段转成向量，存入矢量检索服务，元数据作为过滤字段。
- 员工提问时，先按设备型号过滤，再做向量召回，把相关片段交给大模型生成回答，并附上原文出处，方便核对。
切分粒度是个容易忽略的细节。切得太碎，上下文断掉，回答缺信息；切得太大，一个向量要代表好几件事，检索就不准。团队花了两周对比不同长度，才定下方案。元数据过滤同样关键。没有它，同一句故障描述可能召回其他型号的维修记录，员工照着错误步骤去修，问题反而更大。
上线前要确认的几件事
- 写入和查询必须用同一个 embedding 模型。换模型就要把全部向量重新生成，只补新数据是不够的。
- 索引参数要用真实数据压测。召回率和延迟互相牵制，默认值只能当起点，用自己的查询样本跑一遍再定。
- 权限要在检索时生效。企业文档可能含敏感内容，检索结果必须按用户权限过滤，不能让向量召回绕过访问控制。
- 先算成本再选维度。向量维度越高，存储和计算开销越大。验证阶段可以先用较低维度的模型跑通流程，效果够用再考虑升级。
小结
阿里云矢量检索解决的，是让系统按语义而不是字面找到内容。电商看转化，知识库看准确性，两者的评价标准不同。动手之前，先想清楚数据规模和查询方式，再选产品，最后用业务指标验证效果。
