1. 项目概述当搜索不再“猜谜”在电商平台工作过的同学尤其是负责搜索、推荐或者算法相关业务的肯定都经历过一个让人头疼的“玄学”时刻用户明明输入了“白色连衣裙 夏季 雪纺”为什么系统返回的第一页里会混进几条“白色T恤”甚至“白色沙发套”你拉出后台的搜索日志和商品数据发现商品标题、属性、详情页里确实有这些关键词从传统的文本匹配角度看似乎“没毛病”。但用户不买账他们会直接划走或者更糟——直接离开你的平台。这就是经典的“搜索相关性”问题。它早已超越了简单的关键词匹配变成了一个复杂的系统工程。传统的解决方案无论是基于统计的BM25还是基于深度学习的双塔模型、BERT都在试图从不同角度逼近“用户真实意图”这个模糊的目标。但现实是单一模型、单一视角往往力不从心。用户的一次搜索背后可能隐藏着品类意图、属性偏好、场景需求、甚至是微妙的语义泛化比如“老爹鞋”和“复古运动鞋”。最近我和团队基于实际业务中的一系列棘手案例设计并落地了一套“案例驱动的多智能体电商搜索相关性框架”。这个名字听起来有点学术但核心理念很朴素与其让一个“全能”但可能“平庸”的模型去解决所有问题不如组建一个各有所长的“专家团队”让它们针对不同类型的“疑难杂症”进行会诊共同做出更精准的判断。这个框架不是纸上谈兵而是我们从大量bad case负面案例中抽象出模式再针对性设计解决方案的产物。它特别适合那些搜索流量巨大、商品库复杂、长尾查询多的中大型电商平台能有效提升头部流量的转化效率和用户体验。2. 框架核心设计思路从“单兵作战”到“团队协作”传统的搜索相关性模型就像一个全科医生什么病都看但遇到专科疑难杂症就可能误诊。我们的多智能体框架则像是建立了一家“专科医院”里面有负责看X光片文本匹配的放射科医生有擅长分析病理报告用户行为的化验科医生还有综合会诊的主任医师。2.1 为什么选择“案例驱动”“案例驱动”是我们框架的基石。很多技术方案是从技术趋势出发比如“现在BERT很火我们上个BERT模型吧”。但这样容易脱离业务实际。我们的做法是Bad Case挖掘与归类定期如每周从搜索满意度调查、人工标注样本、高跳出率查询中收集bad case。这不是随机抽样而是定向抓取“让人困惑”的案例。模式抽象将收集到的案例进行归类。例如我们发现了以下几类高频问题类目错配型查询“苹果”结果出现水果和手机混排且比例失调。属性缺失/冲突型查询“不锈钢保温杯 500ml”结果出现很多非不锈钢材质或容量不符的商品。语义泛化型查询“七夕礼物”结果全是“玫瑰花”而用户可能想要首饰、巧克力、香水等。场景混淆型查询“办公椅”在下午时段出现很多“电竞椅”而在上午时段则更偏向传统人体工学椅。定义问题边界每一类问题都对应着相关性判断的一个子维度。这为我们设计“专科医生”智能体提供了明确的需求清单。2.2 多智能体架构设计基于上述问题分类我们设计了四个核心智能体它们各司其职并行工作Query理解智能体 (Query Understanding Agent)这是“门诊分诊台”。它的核心任务是解析用户查询的深层意图。它不直接判断商品是否相关而是为后续判断提供“诊断依据”。输入原始查询词。核心工作类目预测判断查询最可能指向的1-3个叶子类目。这里我们融合了基于点击数据的统计模型和基于BERT的语义模型并对“苹果手机”vs“苹果水果”这类歧义查询做了专门处理。属性抽取识别查询中的关键属性值对如“颜色:白色”、“材质:雪纺”、“容量:500ml”。我们采用序列标注模型并结合商品库的属性枚举值进行归一化。意图分类判断是“精准购买”、“探索浏览”还是“比价”意图。这会影响后续智能体的权重分配。输出一个结构化的意图对象包含{预测类目列表 属性约束集合 意图类型}。文本匹配智能体 (Text Matching Agent)这是“放射科医生”专注看“片子”文本。它衡量商品文本信息标题、属性、详情片段与查询的匹配程度。输入用户查询 vs 商品文本信息。核心工作我们并未完全抛弃传统的BM25因为它对精确词匹配如型号、品牌依然稳健。我们构建了一个混合文本匹配器精确匹配层处理品牌、型号等关键实体。稀疏向量层BM25保证基础相关性。稠密向量层基于Sentence-BERT或SimCSE训练的双塔模型捕捉语义相似性如“手机壳”和“iPhone保护套”。输出一个0-1之间的分数表示文本层面的相关性。行为感知智能体 (Behavior-Aware Agent)这是“化验科医生”分析“病理报告”用户行为。它认为群众的眼睛是雪亮的群体的行为能反映隐性的相关性。输入查询、候选商品、以及历史行为数据如针对该查询用户的点击、购买、停留时长序列。核心工作点击模型基于全局和Session内的点击数据计算商品对于该查询的点击率预期值。购买转化模型更进一步计算点击后的购买转化率。协同过滤信号对于新查询或新品引入“相似查询”或“相似商品”的行为数据进行平滑。输出一个基于行为信号的相关性置信度分数。注意这个智能体要谨慎使用因为它容易强化“马太效应”需要与文本匹配智能体相互制衡。属性约束智能体 (Attribute Constraint Agent)这是“专科医生”专门处理“属性缺失/冲突”这类硬伤。它执行的是硬性规则或强逻辑判断。输入Query理解智能体提取出的属性约束集合vs 商品的属性字段。核心工作进行属性符合度校验。必须满足如查询指定“不锈钢”商品材质必须是“不锈钢”或其同义词若为“玻璃”则一票否决。应该满足如查询指定“500ml”商品容量是“550ml”可以接受但会扣分若是“1000ml”则扣更多分。数值范围处理对价格、尺寸等数值型属性进行区间匹配。输出一个二值结果是否通过或一个符合度分数0-1。2.3 智能体协同与决策机制各个智能体出具自己的“诊断意见”后需要一个“主任医师”决策层来综合会诊给出最终结论。我们设计了一个两阶段决策流程第一阶段粗排与过滤首先属性约束智能体作为守门员对召回的海量商品进行快速过滤直接剔除严重违反硬性约束的商品如非不锈钢材质的“不锈钢杯”。然后文本匹配智能体和行为感知智能体对剩余商品进行快速打分选出Top-N例如500个候选商品进入精排。第二阶段精排与融合对于精排阶段的候选商品所有智能体都给出自己的分数。最终的融合分数不是简单的加权平均而是一个基于注意力机制的动态加权网络。Query理解智能体输出的意图类型会决定权重分配。例如对于“精准购买”意图如“iPhone 14 Pro Max 256GB 暗紫色”文本匹配智能体和属性约束智能体的权重会非常高行为感知智能体权重降低。对于“探索浏览”意图如“七夕礼物”行为感知智能体和语义泛化能力强的文本匹配智能体稠密向量部分权重会提高。这个动态加权网络本身是一个轻量级神经网络以各智能体的输出分数和查询意图特征为输入通过离线训练训练数据来自人工标注的相关性标签学习最优的融合方式。实操心得权重不是静态的初期我们尝试了静态权重效果很不稳定。动态加权的关键在于让系统自己学会“看菜下碟”。训练这个融合模型时正样本要包含各种意图的case负样本尤其要多收集那些单一智能体判断失误的case如文本匹配高但属性不符这样模型才能学会在什么情况下该听谁的。3. 核心模块实现细节与避坑指南3.1 Query理解智能体的实战要点这个模块是源头源头错了后面全错。我们踩过最大的坑就是“类目预测的准确性”。细节1处理类目歧义。“苹果”的例子是经典。我们的策略是上下文感知利用用户实时Session信息。如果用户之前刚搜索过“MacBook”那么接下来的“苹果”大概率是手机/电脑。我们在架构上增加了短期兴趣画像的输入。用户画像辅助对于新用户或无Session用户参考其历史偏好如长期购买数码产品 vs 购买生鲜。流量导向如果“苹果手机”的日常搜索流量是“苹果水果”的100倍那么在无任何其他信号时优先指向手机类目但要在结果页的类目导航栏中明确提示“您是不是在找水果-苹果”给予用户纠正的机会。细节2属性抽取的归一化。用户输入“500毫升”、“0.5L”、“一斤装”都需要映射到标准属性值“500ml”。我们建立了一个庞大的“同义词-标准值”映射库并利用商品后台类目体系中的属性值枚举来约束和修正模型的抽取结果避免出现“粉色可爱风”这种无法匹配的非标准值。避坑指南不要过度依赖NLP模型初期我们用一个端到端的NLP模型同时做类目预测和属性抽取发现它在标准查询上表现尚可但在大量口语化、带错别字、简写的电商查询上效果波动很大。后来我们拆解了任务类目预测用“统计模型快且稳语义模型处理新品新词”融合属性抽取用“序列标注模型知识库属性枚举校验”的管道模式鲁棒性大大提升。记住在工程系统里“简单、可解释、稳定”的模块组合往往比一个复杂黑箱模型更可靠。3.2 文本匹配智能体的混合策略如何让BM25和深度模型和谐共处细节1分而治之。我们不是将BM25分数和向量相似度分数简单相加。而是设计了一个规则如果查询中包含明确的品牌、型号、精确商品词通过NER识别则BM25分数的权重急剧升高。因为用户此时需要的是精确匹配语义泛化反而可能是干扰。如果查询是场景化、需求化描述如“办公室午睡毯”、“小学生书包轻便”则稠密向量相似度的权重占主导。实现上我们训练了一个轻量级分类器先对查询类型进行判断再选择不同的分数混合公式。细节2负样本构造。训练语义匹配模型时负样本的质量至关重要。除了随机采样的负样本我们特意加入了“困难负样本”同类别不相关商品同是“连衣裙”但用户要“雪纺”你给“牛仔”。文本匹配高分但实际不相关通过BM25或早期模型找出的错误匹配case。加入这些困难样本后模型学会了区分更细微的差异而不是简单地学会区分“连衣裙”和“手机”这种简单差异。3.3 行为感知智能体的冷启动与偏差处理行为数据是双刃剑用得好效果显著用不好就会陷入“强者恒强”的循环。细节1冷启动问题。对于新上架商品或长尾查询行为数据稀疏甚至为零。我们的解决方案是文本相似性平滑对于新商品用其文本信息标题、属性找到最相似的Top-K个老商品用这些老商品的行为数据经衰减处理作为新商品的初始值。类目基线如果连相似商品都找不到则回落至该商品所在类目的平均行为水平作为先验。细节2破解流行度偏差。热门商品可能因为曝光多而点击多但这不意味着它与某个特定查询最相关。我们采用了反事实推理的思路进行纠偏在计算行为分数时不仅看商品对于该查询的绝对点击率更看它的相对点击率即该查询下的点击率/该商品在全平台所有场景下的平均点击率。如果一个商品本身就很热门那么它在某个查询下的高点击率“含金量”可能没那么高反之一个不那么热门的商品在特定查询下点击率飙升则是一个很强的相关性信号。在模型特征中显式加入商品的全局曝光点击率作为特征让融合模型自己去学习如何“打折”。4. 系统落地与迭代闭环框架设计得再好不能稳定落地也是空谈。我们采用微服务架构将每个智能体封装为独立的服务通过高可用消息队列进行通信。4.1 线上服务架构异步并行调用当搜索请求到来时Query理解服务首先被调用。得到结构化意图后将其与查询词一起广播给文本匹配、行为感知、属性约束服务。这三个服务是并行调用的极大降低了整体延迟。结果缓存对于Query理解的结果和行为感知中基于全局统计的数据如商品历史CTR进行多级缓存本地缓存分布式缓存热查询的响应时间可以控制在10毫秒内。降级与熔断任何一个智能体服务出现故障或高延迟决策层都有降级策略。例如行为感知服务超时则自动将其权重设为0完全依赖文本和属性判断。确保搜索功能永远可用即使相关性有所下降。4.2 数据闭环与持续迭代多智能体框架的强大之处在于它的可迭代性。我们建立了一个完整的数据闭环在线日志收集记录每一次搜索请求的输入查询、各智能体的中间输出、最终融合分数及排序结果、用户的后续行为点击、购买、翻页、跳出。Bad Case自动挖掘定期运行离线作业从日志中自动识别潜在bad case。规则例如排名靠前但无点击的商品。有点击但快速退出的商品可能不相关。同一Session内用户修改查询词后点击了之前出现但未点击的商品说明原排序不准。人工标注与反馈将自动挖掘的疑似bad case和随机抽样case送入标注平台由专业标注员判断相关性。这些新产生的标注数据成为迭代模型的新燃料。定向迭代根据bad case的类型我们可以有针对性地迭代某个智能体而不必动全身。如果是类目预测错了就优化Query理解智能体。如果是属性没识别出来就补充属性抽取的同义词库或调整模型。如果是语义泛化不够就给文本匹配的稠密向量模型补充更多困难负样本。这个闭环让整个系统具备了“自我进化”的能力。每一次bad case的修复都让系统在某个细分问题上变得更聪明。5. 效果评估与常见问题排查上线不是终点如何科学地评估效果和快速定位问题是保证系统长期健康运行的关键。5.1 多维度评估体系不要只看一个整体的CTR或GMV提升要拆开看评估维度评估指标说明整体效果NDCG5/10, MRR衡量排序质量的金标准需依赖人工标注的测试集。用户体验首次点击位置、翻页率、搜索退出率更靠前的点击、更少的翻页和退出说明用户更快找到了所需。业务价值搜索引导GMV占比、搜索转化率核心业务指标但受多重因素影响需做AB实验隔离变量。分场景效果各类意图查询精准/探索下的CTR检查框架是否真的做到了“动态适配”而不是牺牲某一类查询的效果。智能体健康度各智能体分数分布、覆盖率、调用延迟监控每个“专家”的工作状态确保其输出稳定、可用。我们通过A/B实验将新框架与旧版基线模型对比。在一个月的实验期内核心指标提升如下NDCG5提升了8.2%搜索退出率降低了5.7%尤其是“探索浏览”类查询的转化率提升了12.1%证明多智能体在理解模糊意图上的优势。5.2 线上问题排查清单当监控报警或业务方反馈搜索效果波动时可以按以下清单快速排查问题现象某一类商品如“手机”的搜索排名突然全部下降。排查步骤检查Query理解智能体的类目预测服务该类目的预测准确率是否骤降模型是否刚刚更新特征数据源是否异常检查行为感知智能体该类目商品的历史行为数据流是否中断或延迟导致分数异常检查属性约束智能体是否新上线了某个严格的属性过滤规则误伤了该类目问题现象整体搜索转化率下降但CTR变化不大。排查步骤分析行为感知智能体的分数权重是否在动态融合中权重过高导致系统过于“保守”只推热门爆款虽然有人点但购买意图不匹配检查用户行为数据流购买行为的数据是否正常上报和处理如果购买信号缺失行为感知智能体的判断就会失准。查看Bad Case新出现的bad case是否集中在“有点击无购买”的类型这可能是商品详情页与搜索列表页信息不一致或者价格突然变动。问题现象特定长尾查询的效果变差。排查步骤检查文本匹配智能体的语义模型是否在处理某些新网络词汇或特定表述时失效需要检查该查询下稠密向量相似度的分数是否异常低。检查缓存是否为该长尾查询建立了错误的缓存例如缓存了一个旧版本的、效果差的结果查看数据闭环是否有针对这类长尾查询的标注数据如果没有它就是系统的盲区需要主动补充样本进行训练。这套框架从构思到全量上线我们花了近半年时间。最大的体会是解决搜索相关性这种复杂问题没有银弹。与其追求一个“终极模型”不如建立一个灵活的、可解释的、可持续迭代的“系统生态”。多智能体的思想让我们能够将复杂问题模块化针对性地攻坚并且可以随着业务发展随时引入新的“专家”例如未来可以增加一个“图像理解智能体”来处理以图搜图的场景。技术最终要服务于业务场景而案例驱动确保了我们的每一步迭代都踩在业务的痛点上。