前几天整理活动材料时我又把唯品会、虎牙、YY三家放在同一场分享里的PPT翻出来看了一遍。当时台下不少人以为这只是一个“电商、直播、娱乐社区凑一起聊AI”的套路环节但听完前半场就发现三家虽然业务形态完全不同在数据处理上却撞进了同一个问题海量非结构化内容怎么在毫秒级时间内匹配到用户最想要的那个结果。这背后绕不开的就是向量检索。这场活动里没有太多花哨的概念包装大量时间都在讲真实链路怎么搭、索引参数怎么调、延迟和成本怎么平衡。我把当时记下的重点和后来自己实践消化出来的经验整理成这篇回顾想给正在做搜索、推荐或者内容匹配的同学一些可以直接参考的东西。1. 为什么是这三家场景痛点高度重合的三个App唯品会做的是特卖电商商品池体量大、上架节奏快、用户搜索意图非常明确但表达方式极其发散。虎牙的核心是直播直播间内容天然是视频流标题、标签、弹幕这些文本信息稀疏且噪音大。YY这边则是泛娱乐社区语音、短视频、动态各种UGC内容混在一起大量内容根本没有结构化标签可以依赖。这三个场景放到同一场活动里聊最有价值的地方在于它们覆盖了文本匹配、视频内容理解、用户兴趣建模三个方向但最终都落到同一个底层能力上——向量检索。活动上有一个例子我印象很深有人在电商平台搜“小个子显高穿搭”如果只靠分词和倒排索引去匹配结果会丢掉大量“矮个子怎么穿显高”这种语义等价但词面完全不同的商品。直播场景更明显一个用户看着某个游戏主播的切片视频时产生了兴趣但直播间标题里可能根本没有出现这个游戏的名字。三家在做技术选型时都发现关键词匹配擅长处理短、明确、高频的检索请求但真实世界里的用户表达充满了同义词、口语词、省略语和错误输入。倒排索引可以解决字面匹配解决不了语义匹配。向量检索的意义就是把“找字”变成“找意思”用向量空间中距离度量来代替字符串上的重合度判断。1.1 电商、直播、社区本质都在做同一件事如果退一步看三家业务的数据流动模式会发现路径惊人一致用户侧产生一个query或者一段浏览轨迹或者一句弹幕资源侧是商品、直播间、UGC内容平台在中间做的就是算相关性把最匹配的内容在几十毫秒内送到用户面前。我在活动笔记里画过一张示意图把所有业务词都剥掉之后剩下的是这样一个流程原始内容经过Embedding变成向量存进向量索引用户请求经过同样的编码过程变成查询向量然后在向量空间里做近似最近邻搜索取回TopN候选再做精细排序。这套流程对电商搜索、直播推荐、社区内容分发是通用的。区别只在于Embedding的来源不同、向量的维度不同、索引的规模不同以及业务对延迟和实时性的容忍度不同。这三家愿意坐在一起聊本质上就是因为它们在这个通用框架里的可复用经验非常多。1.2 关键词匹配在真实用户表达面前的溃败活动里有一位来自YY的工程师分享过一个很典型的案例。社区里有一批关于“减压”“解压”话题的UGC内容但用户的真实表达里有大量“焦虑到失眠”“工作压力大怎么办”“求推荐放松的方法”这种完全不含目标关键词的语句。用关键词检索这类内容基本是漏掉的即使用户翻到了系统也不知道该怎么把相似内容组织起来推荐给他。电商场景中的同义词问题同样严重商品标题里的“连衣裙”和用户搜索的“one piece”“裙子”在字面上几乎没有重合。传统搜索引擎的解决方案是维护同义词表和改写规则但同义词表需要人工维护覆盖面永远跟不上用户表达的变化。向量检索直接跳过这一步通过模型把“连衣裙”和“one piece”映射到向量空间中相近的位置从机制上绕开了同义词表维护的问题。不过这里要说明白向量检索不是在所有场景下都替代关键词检索。三家分享里都提到实际线上系统是“稀疏检索稠密检索”混合架构倒排索引保证精确匹配的兜底向量索引补充语义扩展的能力。这一点我觉得特别重要也是很多团队最容易走偏的地方。1.3 向量检索解决的第一个问题把“找”变成“懂”活动上半场有一个共识性的结论向量检索真正解决的电商第一个问题是让系统从“用户输入什么就找什么”进化为“用户想表达什么就找什么”。这句话听起来像口号但在实现层面涉及一个非常实在的转变——从Query的字面匹配转向用户意图的语义空间匹配。以唯品会的商品搜索为例检索系统要做的不只是找出“输入了商品名”的用户想要的那个商品还要能处理“输入了场景词、风格词、人群词”的检索需求。比如“约会穿什么”“通勤平价”“微胖显瘦”这些query里没有具体的商品类目词但用户的意图非常清晰。这类场景下向量检索能把query映射到包含款式、风格、人群属性的语义空间再和商品的视觉特征向量、文本属性向量做匹配。这个能力是传统检索架构很难具备的但一旦接入搜索体验的提升是非常明显的。2. 向量从哪来Embedding生产和更新的完整链路活动上关于Embedding的讨论占了大半时间因为很多团队对向量检索的第一个误区就是“向量是自然而然地有的”。实际上生产一个可用、稳定、可持续更新的Embedding体系是整个向量检索落地里最费时费力的环节。三家内容方向不同Embedding的来源也各不一样但整体上都能归为三类文本向量、图像向量、用户行为序列向量。文本向量方面唯品会主要处理商品标题、属性、评价文本虎牙主要处理直播间标题、标签、弹幕文本YY主要处理UGC标题、评论、语音转写文本。图像方面唯品会对商品主图做视觉特征提取虎牙对直播封面和关键帧做图像理解YY则对短视频封面和动态配图做特征抽取。用户行为序列向量稍微特殊一点它不是对单个内容做编码而是把一个用户一段时间内的点击、浏览、互动行为序列编码成一个固定维度的向量代表这个用户的当前兴趣状态。2.1 文本、图片、用户行为三类向量的制造成本差异三类向量的生产成本和更新频率差异非常大这个直接决定了索引的构建方式。文本向量相对便宜一次批量推理可以在GPU集群上快速完成如果内容只有标题和几个属性字段单条文本的向量化成本可以控制在很低的水平。但文本embedding需要持续迭代因为用户的表达习惯会变平台的商品和内容也会变模型需要定期用最新的语料做微调。图像向量成本更高特别是商品图、直播封面这种需要处理高分辨率图的场景。视觉特征提取模型通常比文本模型更大单张图的推理耗时是毫秒级到几十毫秒级批量处理时对GPU显存的要求也更高。图像向量还有一个特殊问题图像会频繁更新商品换图、主播换封面、用户换头像每一次变化都意味着旧的向量失效需要重新编码。这个全量重算的量一起来资源消耗还是很可观的。用户行为序列向量的成本不在推理而在于数据的拼接和实时性。行为序列是动态变化的用户每产生一次点击理论上的兴趣向量都应该更新。完全实时更新不现实所以活动上三家普遍的做法是分钟级或者小时级的近线更新把用户最近一段时间的行为拼成一个序列重新过一遍模型生成新的向量。2.2 需要领域微调通用Embedding模型在垂直场景的失灵很多团队一开始会直接拿公开的通用Embedding模型来用但效果往往达不到预期。原因不复杂通用模型是在通用语料上训练的它对“连衣裙”“直播间”“解压语音”这种垂直概念的理解远不如对新闻、百科、社交文本的理解深入。唯品会的分享里提到他们早期实验阶段直接用通用模型编码商品标题和query离线评测的Recall指标看上去还行但上线后发现一个典型问题商品标题里的大量品牌词、材质词、风格词在通用模型的向量空间里区分度不够。比如“法式”“赫本风”“极简”这几类风格词通用模型能区分一些但把它们映射到商品场景里时边界就很模糊。后来他们用商品点击日志构造了“query-商品”配对数据对底座模型做进一步训练让模型学到商品域内的语义关系效果才有明显提升。这里有个容易忽略点领域微调不是拿几万条数据跑几个epoch就能解决的。数据质量、负样本构造、评测集的建立都要跟上。活动上有一位讲者提到他们为了构造负样本专门做了“难负样本”挖掘——把那些字面上很像、但用户反馈上明显不相关的配对找出来逼着模型学到更精细的边界。没有这一步模型容易偷懒靠字面重合去得分。2.3 近线Embedding队列和冷启动问题向量更新的时效性是活动上讨论比较多的一个细节。内容侧向量相对好处理商品上新、直播间开播、UGC发布都可以在内容入库时同步触发向量化进入一个近线队列由异步Worker消费并写入向量索引。难点在用户侧向量和实时内容召回用户半小时前还看得很投入的直播间可能现在已经下播了一条刚发布的UGC如果等离线全量更新完才进索引可能要等几十分钟甚至几个小时新鲜度完全跟不上。近线队列的设计实际上是在成本和实时性之间找一个平衡。活动上提到的典型方案是既有一个增量更新的通道用于处理新内容和内容变更又有一个周期性的全量合并用于处理索引内部的碎片整理和过期向量清理。冷启动问题则更麻烦一点新用户没有行为序列行为向量没法算新内容没有反馈数据向量质量也没法验证。三家给出的应对思路基本一致——先用内容侧向量做基础召回等用户积累了一定行为量之后再叠加行为向量做个性化。说白了冷启动没办法完全解决只能靠系统设计去“拖时间”等数据攒够了再上复杂模型。3. 存储与索引离线建库、增量更新与召回参数调优Embedding生产链路捋清楚之后下一步就是向量索引的构建和检索参数设计。这个部分是活动下半场的重点也是听众提问最多的环节。很多人以为向量检索就是把向量往Faiss里一扔调个HNSW的M参数就完事了。但真实业务里要考虑的东西远多于此索引放在什么介质上、增量怎么合并、过滤条件和向量检索怎么结合、召回数量怎么定每一环都影响线上效果和资源成本。3.1 向量索引选型HNSW、IVF、PQ及参数组合三家在分享里都承认目前线上最常用的索引结构还是HNSW但HNSW并不是所有场景的最优解。HNSW的优点是对召回质量友好、实现成熟、调参路径清晰缺点是内存占用偏高构建耗时也比较可观对超大规模的索引来说成本压力明显。IVF这类基于倒排分桶的思路内存占用相对友好一些但召回率会受到分桶数量的影响需要更细致的调参。PQ乘积量化则是对向量做压缩能大幅降低内存成本但量化本身是有损的压缩比越高召回精度丢失越明显。活动上有一个比较务实的建议在业务初期或者索引规模在千万级以内时直接上HNSW把M参数设置在16到32之间efConstruction设置在200到400之间召回质量有保障也不用花太多精力调优。如果索引规模到了亿级内存成本开始变得敏感再考虑IVFHNSW的组合或者引入PQ压缩。3.2 召回数量、相似度阈值和过滤条件的配合召回数量TopN是一个容易被低估的参数。取太少候选集不够影响后续排序的天花板取太多下游精排计算量和检索延迟都会上升。三家的经验都倾向于“召回多一点、精排兜底”的思路线上召回量普遍设置在几百到上千这个量级具体取决于下游精排模型的计算复杂度。相似度阈值则是一个需要结合业务调的值。过低会混入大量无关结果过高则导致召回稀疏。活动上有位讲者提到一个经验不要让阈值成为硬过滤条件最好做成软过滤——先把相似度分数作为排序信号之一观察线上指标再决定是否要用阈值截断。因为不同query的语义密度不一样统一阈值很容易误杀长尾query的合法结果。过滤条件是向量检索和传统搜索结合最紧密的地方。电商里常见的过滤是类目、品牌、价格区间直播里常见的过滤是分类、语言、开播状态。实务上过滤一定要在向量检索之前或者检索过程中完成不要在检索完再对TopN结果做过滤否则会出现候选集被过滤掉一大半、最终结果稀疏的问题。实现方式上HNSW图索引可以支持在搜索过程中带上过滤条件进行剪枝代价是搜索速度会下降也可以在检索前先用倒排索引圈定一个满足过滤条件的候选ID集合再在这个集合内做向量检索。具体选哪种取决于过滤条件的筛选率和系统瓶颈在内存还是CPU。3.3 多模态向量的存储结构与字段裁剪多模态向量带来的第一个问题是存储结构设计。一个商品可能同时有文本向量、图片向量甚至还有品牌风格相关的属性向量一个直播间可能有标题向量、封面图向量、标签向量。如果每个向量都用一个独立字段来存检索时字段数量会爆炸存储成本也扛不住。活动上分享的常见做法是做“主向量辅助向量”的区分。主向量承担主要的召回职责通常是融合了多模态信息之后输出的一个综合向量比如把文本向量和图片向量拼接后经过一个映射层压到统一维度辅助向量则服务于特定场景比如“以图搜图”时专门用纯视觉向量。检索时默认只用主向量特定场景再切换辅助向量这样既保证通用召回效果又让资源使用更可控。字段裁剪是另一个省钱细节。很多向量数据库产品支持在索引中只保留向量和少量标量字段其他详情字段放到外部存储检索命中的结果再回表查询。这个方案的逻辑很简单向量索引的主要职责是快速定位候选ID而不是承载业务展示信息。不要在向量索引里塞太多不需要参与检索和过滤的字段不然索引体积膨胀、缓存命中率下降、成本上升最终拖慢查询速度。4. 查询链路设计从用户点击到结果返回的耗时分配优化向量检索落地的另一个关键点是查询链路的整体设计。很多团队在离线评测阶段效果很好一上线就发现延迟完全压不住。原因往往不在向量检索本身而是链路中有太多地方拖慢了整体耗时。活动上三家和听众对谈时这个问题被多次抛出核心矛盾集中在“候选集怎么管”“粗排和精排怎么分工”“缓存怎么设计”。4.1 前置过滤条件是如何把候选集从亿级压到十万级的向量检索最怕的就是在亿级向量上做暴力遍历所以前置过滤的本质是把候选空间降下来。这里我记下了活动上一个非常实在的案例某家业务的热门类目占了全量内容的60%但用户query里带类目过滤的比例也很高。如果他们不先做过滤直接全量检索那么每次查询都要面对上亿的向量计算量。解决办法是在向量检索前先用倒排索引做一次粗筛把候选集压缩到十万甚至万级别然后再做向量检索。这个“先倒排粗筛、再向量精检”的顺序跟很多人的直觉正好相反。有人担心倒排查出来的候选集不完整会漏掉真正相关的内容。但事实上粗筛阶段用的过滤条件通常是用户明确表达的硬性条件比如类目、价格、上架状态漏掉这些条件之外的候选是合理的。真正需要谨慎的是那些不该前置的软条件比如风格的相似度、主题的接近度这些应该留给向量检索去判断。4.2 粗排召回精排重排的两段式架构召回到结果返回之间还有一段精排重排的流程。这三家目前线上普遍都是这种两段式架构向量检索负责从海量内容里快速捞回几百个候选下游的精排模型再在这个候选集上做精细化打分用更丰富的特征、更复杂的模型结构产出最终排序。这样设计的原因在于向量相似度本质上只是一个粗粒度的相关性信号它没有把价格、转化率、用户历史偏好、实时热度这些业务特征纳进来。活动上有人问“能不能让向量检索直接产出最终结果”现场讨论的结论是在业务简单的场景里可以但电商和直播这种复杂场景不现实。电商用户对价格敏感、直播用户对实时状态和主播风格敏感这些都不是一个纯向量相似度能表达清楚的。两段式的架构代价是多一跳的网络开销和计算开销但带来的排序质量提升是值得的。关键在于控制好粗排层的召回量和精排层的模型复杂度让整体链路延迟保持在业务可接受的范围。4.3 缓存与扩容策略对毛刺延迟的作用延迟优化里被提到最多的是缓存层设计。向量检索本身的毫秒级延迟看似不高但在高并发场景下热点内容会被大量重复查询。如果没有缓存每一次请求都会压到向量检索引擎上不仅CPU和内存压力大延迟的毛刺也会很明显。三家的做法都是分层缓存第一层缓存query级别的结果完全一样的重复查询直接命中第二层针对热门内容做embedding级别的缓存减少重复计算。缓存之外扩容策略也是一个细节。向量索引和传统倒排索引不同它无法像Redis那样简单加节点就能水平扩展因为索引构建和分片同步有较高的成本。活动上提到的经验是容量规划要按峰值QPS和索引增长率的乘积来预留而不是按平均QPS。索引数据的增长是指数级的如果容量规划只看当下的QPS半年之后性能就会开始劣化。另外向量检索集群的扩容最好提前在低峰期操作不要等线上延迟告警了才去扩容不然Build新索引的过程本身就会拖垮在线服务。5. 平台化还是自研我在活动中拿到的选型判断依据活动进行到后半段话题转向了一个非常现实的问题这些能力到底应该自研还是直接使用云上的向量检索产品。现场讨论时几家背景不同团队的同学观点差异还挺大。有的团队技术实力强、预算充足倾向自研有的团队人手有限希望尽快跑通业务倾向直接采购成熟产品。这个分歧很有意思因为两边都不是拍脑袋决定的背后各有判断依据。5.1 自研引擎适合什么规模的团队自研向量检索引擎的一个必要条件是团队有足够强的底层系统能力。向量检索不只是调Faiss或者HNSW库那么简单要解决索引构建、分片、副本同步、故障恢复、在线升级、监控告警等一系列工程问题。任何一个环节掉链子线上业务都会跟着受影响。活动上有一位从大厂出来的同学提到他们团队最早自研引擎光是把索引构建流程做到平滑无损就花了两个多月这还没算在线服务的稳定性打磨。自研的另一个条件是业务规模足够大。如果索引规模只有几千万向量QPS也就在几千的级别自研带来的成本优势其实非常有限但如果索引到了几十亿级别云产品的计费模式可能会让你觉得成本不可控这时候自研的边际成本才会真正降下来。通常来说小规模业务或者刚刚起步的业务用云上的向量检索产品做冷启动是更稳的选择。5.2 选择云上向量检索产品时的四个验收指标如果决定用云上的向量检索产品怎么评估一款产品是否适合活动上讨论出了一个相对完整的验收清单我觉得可以直接拿来做选型参考。第一个指标是召回效果的可控性。产品最好能暴露索引参数、召回数量、相似度算法这些核心配置项而不是把一个黑盒的“智能召回”丢给你。因为线上效果出了问题你至少要有办法通过调整参数来排查。第二个指标是链路延时。不仅是单次向量检索的延迟还包括索引更新生效的延迟。很多云产品离线索引构建耗时较长增量更新也不是实时的。如果你对内容新鲜度要求很高就必须仔细看这个指标否则一条刚上架的商品可能要等很久才能被检索到。第三个指标是成本模型透明度。向量索引的计费通常和向量条数、维度、副本数、存储介质的类型挂钩。同样一个业务场景在不同产品上的成本差距可以非常大。建议在选型前用自己真实的索引规模和QPS去估算成本不要只对比官网上的刊例价。第四个指标是生态工具的完整性。比如是否支持多租户隔离、是否有配套的监控面板、是否有方便的数据导入工具。这些“非核心”能力在开发阶段感觉不明显但真正运营起来会发现特别关键直接决定研发效率和排障速度。5.3 以阿里云OpenSearch向量检索版为参照的接入流程活动上因为现场有同学正在调研阿里云的OpenSearch向量检索版所以顺手把它的接入流程也过了一遍。这款产品其实是OpenSearch这个老牌搜索产品线里面向向量场景的版本核心思路是“少改代码、快速跑通”对有搜索和推荐业务基础、想快速验证向量检索效果的团队来说非常合适。它的接入流程大致是四步先在控制台上创建向量检索版实例然后在实例里定义索引结构指定向量字段、维度、距离函数还有一些常规的属性字段接着把已经生产好的向量数据通过API或者推送方式写入索引这里它支持全量推送和增量推送两种模式最后在业务代码里调用查询接口传入query向量以及过滤条件、召回数量这些参数就能拿到命中的结果。整个流程对已有的搜索架构改动不大尤其是那些已经在用OpenSearch做关键词检索的团队迁移到向量检索版基本不需要重写业务代码。选择这类云产品的核心价值本质上不是“省掉自研的麻烦”这么简单而是把向量检索本身当成一个可运维的托管服务争取了业务验证的时间。很多团队业务还没有跑通就急着自研结果发现投入了大量研发资源最后模型效果和业务指标反而不如用成熟产品快速试错来得有效。6. 活动结束后我自己消化出来的三点实战建议活动结束之后我又把当时的笔记翻了好几遍结合自己这些年做检索和推荐系统的经历想清楚了三件以前没有理顺的事情这里也一并分享出来。第一向量检索的落地顺序应该是“先业务验证后技术改造”不要一上来就做平台化。先选定一个对语义匹配需求最强烈的业务场景用最小闭环把embedding生产、索引构建、在线检索跑通看业务指标有没有正向变化。验证有效之后再考虑沉淀平台能力、做索引规模扩展、优化成本。跳过业务验证直接铺平台大概率会陷入“平台建好了没人用”的尴尬局面。第二要把“向量检索”当做一个工程系统而不是一个算法库来对待。索引更新、缓存策略、容量规划、监控告警、故障恢复这些工程问题的优先级一点不比选择什么索引算法低。我见过太多团队在HNSW的参数上调来调去线上延迟却因为索引构建阻塞或者缓存击穿而失控。检索系统是拼木桶算法只是其中一块板。第三关注向量检索和现有搜索架构的融合不要搞成“两套系统并行”。如果公司已经有倒排索引架构最优路径通常是在现有搜索架构上增加向量召回通道让倒排和向量在召回结果层面做融合而不是推倒重来。这样做的好处是团队现有技术栈可以复用排查问题时也有更多参照点。完全独立的向量检索引擎只有在业务形态本身没有搜索基础的时候才值得考虑。这场活动对我来说最大的价值不是记住了几个参数或者几个产品名而是看清楚了一个趋势向量检索在头部互联网公司里已经不是实验性的探索而是嵌入到核心业务链路的基建设施。对大部分团队来说现在正是认真评估、动手尝试的好时机。希望这篇回顾能帮你少踩一些我已经踩过的坑。