1.3 关键特性与典型应用场景

1.3 关键特性与典型应用场景

概念和历史都备齐了，本节回答一个更现实的问题：这套技术到底被谁在用、用的时候依赖它哪些特性。一家电商平台的图像搜索团队遇到的问题，会把你带进真实场景；我们先归纳关键特性清单，再扫一遍六大应用场景，最后完整拆解以图搜图这个案例——它的每个环节都会在后面对应的章节里被放大讲透。

一份关键特性清单

把市面上主流系统的能力归纳起来，向量数据库区别于"自己拿个库拼一套"的关键特性有这些：高维近似检索，毫秒级返回 TopK，这是立身之本；元数据过滤，检索时叠加标量条件，比如限定类目、租户或时间窗，没有它业务根本没法用；混合检索，同时利用向量相似与关键词倒排两路信号再做融合排序，对抗嵌入模型在专有名词上的盲区；实时更新，新写入的数据能在秒级被查到，而不是等批处理重建；水平扩展，数据与流量涨了就加节点，索引随之分片复制；多租户与权限隔离，一个集群服务多条业务线而不串数据。第六章选型时，这份清单就是逐项打分的评分表——各家产品在这些特性上的实现深度差异极大。

六大场景与它们的要求

图 1-2 典型应用场景与能力要求矩阵

这张矩阵的用法不是背结论，而是学会从负载倒推要求：检索增强生成要求低延迟，是因为生成式回答的等待时间里检索占去一大截；推荐召回要求全项拉满，因为它同时面对亿级库存、强个性化过滤和秒级的商品上新；内容去重反而对延迟宽容——晚几秒判重不影响业务，但吞吐必须高，因为每天要过亿的增量。场景要求决定索引与架构选择，这是第三章和第四章反复出现的推理链。

案例拆解：电商以图搜图从零到上线

背景。 某电商平台的搜索团队发现，相当比例的购买意向无法用文字表达：用户看到街拍里的鞋、朋友家的灯，直接拍照搜索的转化意愿远高于翻类目。团队决定上以图搜图，约束是：图库规模在千万级，线上要求八成请求在两百毫秒内返回，且移动端上传的图片存在光照、裁剪、水印差异。

操作。 技术方案分四步落地。第一步选嵌入模型：用在商品图上微调过的图像模型而非通用模型，因为通用模型对"同一款鞋不同角度"的判别力不够；所有商品主图离线跑一遍，产出维度为几百的向量，连同商品 ID、类目、上架状态写入向量库。第二步选度量与索引：图像向量先做归一化，于是内积与余弦等价，取内积；索引选分层可导航小世界图，内存换速度。第三步搭查询链路：用户上传图后先过一遍中心裁剪与压缩水印检测，再送嵌入服务，拿查询向量到向量库里取 TopK 一百条，叠加"仅上架商品"的过滤条件，再交给排序层精排出 TopK 二十条。第四步灰度验证：先切百分之五流量，对照转化率与人工标注的相关性。

结果。 灰度期间，首屏两百毫秒达标率约八成五，人工评估的相关性合格率约八成八；全量后该入口的转化率显著高于文字搜索的平均水平，成为核心入口。但也暴露了两个问题：部分长尾类目（手作、古董）的召回相关性明显偏低；大促期间商品批量换图，写入峰值让索引构建延迟明显上升。

解读。 长尾类目的问题是嵌入模型的盲区——训练数据里这类商品太少，向量没有拉开区分度，解法不是调数据库，而是补充该类目的训练样本做模型迭代，这正是"嵌入模型决定召回上限"的实例；写入峰值则是典型的动态索引问题，3.3 节会讲分段构建与后台合并怎么吸收写入毛刺，4.3 节会讲更新语义怎么设计才能避免检索质量抖动。

变式。 同一套链路换掉嵌入模型就能衍生出多种产品：换成图文对齐模型，查询端既可传图也可传文字，就成了多模态搜索（7.1 节）；把查询向量换成用户历史行为序列的聚合向量，就成了推荐召回（4.2 节的分片方案正是为它这种亿级规模准备的）；把相似度阈值抬高用于查重，就成了内容去重工具。一条链路、多种业务，这也是为什么这本书把它当作贯穿案例。

反面清单：什么时候不该用

把场景矩阵翻过来同样重要，三类需求不适合为它单独立向量库。纯精确匹配需求：订单号查找、状态过滤、主键点查，倒排或 B 树便宜又准确，向量索引在这里纯粹是负资产。词面即语义的需求：日志关键字检索、代码符号搜索、合规词表筛查，查询词本身就是全部语义，倒排检索的性价比高得多。数据量远低于复杂度阈值的需求：几千条数据暴力扫描微秒级完成，引入一套向量设施的运维成本永远回不了本。真实项目里最常见的浪费是第二类——团队被"语义检索"的热度推动，给本质是关键词匹配的场景上了嵌入管道，结果检索质量反而不如原来的倒排，因为嵌入模型对型号、错误码这类符号串的编码能力很弱。先问"我的查询里，语义模糊的部分占几成"，再决定投入。

问题：检索增强生成里，检索环节的目标和普通搜索有什么不同？

普通搜索的目标是把"最相关"的结果排前面，人工会看排在前面的几条；检索增强的目标是给生成模型凑一份"刚好够用且互相不重复"的上下文。两者对排序的要求不同：前者在意第一名有多准，后者在意前十名覆盖了多少答案侧面、有没有同源片段互相挤占。这解释了为什么检索增强场景对后处理（去重、多样性、重排）更敏感，也解释了为什么它的 K 值受上下文预算而不是页面容量约束。把这两个目标混为一谈，常导致用搜索的指标去优化一个本质是"上下文组装"的环节，指标好看而回答质量平平。

问题：项目冷启动时，嵌入管道和数据库哪个先搭？

先搭嵌入管道并小规模验证质量。原因很直接：嵌入模型决定召回上限（本章案例已演示），数据库决定的是逼近这个上限的效率。如果模型选错了，再好的数据库也只是高效地返回不相关结果；反过来，先用几百条真实查询与文档验证嵌入质量（人工评估相关性合格率），确认上限可接受，再投入数据库选型与容量规划，返工风险最小。冷启动顺序的口诀是：先证明"相似性存在"，再解决"找得快"。

本节要点回顾

• 六大关键特性：近似检索、元数据过滤、混合检索、实时更新、水平扩展、多租户隔离。
• 场景要求倒推技术选择：延迟敏感度、规模、过滤强度各不相同。
• 检索增强生成的检索环节直接决定回答质量上限，是当前最大的需求来源。
• 以图搜图案例的两大教训：模型盲区要用数据侧迭代解决，写入毛刺要用索引与更新机制吸收。
• 同一条检索链路换嵌入模型即可衍生多模态搜索、推荐召回与内容去重。

第一章到此收束。下一章深入表示层：嵌入向量是怎么生成的，以及为什么度量口径选错会让上面这一切前功尽弃。