案例驱动的多智能体框架：破解电商搜索相关性难题

1. 项目概述：当搜索不再“猜谜”

在电商平台工作过的同学，尤其是负责搜索、推荐或者算法相关业务的，肯定都经历过一个让人头疼的“玄学”时刻：用户明明输入了“白色连衣裙 夏季 雪纺”，为什么系统返回的第一页里，会混进几条“白色T恤”甚至“白色沙发套”？你拉出后台的搜索日志和商品数据，发现商品标题、属性、详情页里确实有这些关键词，从传统的文本匹配角度看，似乎“没毛病”。但用户不买账，他们会直接划走，或者更糟——直接离开你的平台。

这就是经典的“搜索相关性”问题。它早已超越了简单的关键词匹配，变成了一个复杂的系统工程。传统的解决方案，无论是基于统计的BM25，还是基于深度学习的双塔模型、BERT，都在试图从不同角度逼近“用户真实意图”这个模糊的目标。但现实是，单一模型、单一视角往往力不从心。用户的一次搜索，背后可能隐藏着品类意图、属性偏好、场景需求、甚至是微妙的语义泛化（比如“老爹鞋”和“复古运动鞋”）。

最近，我和团队基于实际业务中的一系列棘手案例，设计并落地了一套“案例驱动的多智能体电商搜索相关性框架”。这个名字听起来有点学术，但核心理念很朴素：与其让一个“全能”但可能“平庸”的模型去解决所有问题，不如组建一个各有所长的“专家团队”，让它们针对不同类型的“疑难杂症”进行会诊，共同做出更精准的判断。这个框架不是纸上谈兵，而是我们从大量bad case（负面案例）中抽象出模式，再针对性设计解决方案的产物。它特别适合那些搜索流量巨大、商品库复杂、长尾查询多的中大型电商平台，能有效提升头部流量的转化效率和用户体验。

2. 框架核心设计思路：从“单兵作战”到“团队协作”

传统的搜索相关性模型，就像一个全科医生，什么病都看，但遇到专科疑难杂症就可能误诊。我们的多智能体框架，则像是建立了一家“专科医院”，里面有负责看X光片（文本匹配）的放射科医生，有擅长分析病理报告（用户行为）的化验科医生，还有综合会诊的主任医师。

2.1 为什么选择“案例驱动”？

“案例驱动”是我们框架的基石。很多技术方案是从技术趋势出发，比如“现在BERT很火，我们上个BERT模型吧”。但这样容易脱离业务实际。我们的做法是：

1. Bad Case挖掘与归类：定期（如每周）从搜索满意度调查、人工标注样本、高跳出率查询中收集bad case。这不是随机抽样，而是定向抓取“让人困惑”的案例。
2. 模式抽象：将收集到的案例进行归类。例如，我们发现了以下几类高频问题：
   • 类目错配型：查询“苹果”，结果出现水果和手机混排，且比例失调。
   • 属性缺失/冲突型：查询“不锈钢保温杯 500ml”，结果出现很多非不锈钢材质或容量不符的商品。
   • 语义泛化型：查询“七夕礼物”，结果全是“玫瑰花”，而用户可能想要首饰、巧克力、香水等。
   • 场景混淆型：查询“办公椅”，在下午时段出现很多“电竞椅”，而在上午时段则更偏向传统人体工学椅。
3. 定义问题边界：每一类问题，都对应着相关性判断的一个子维度。这为我们设计“专科医生”（智能体）提供了明确的需求清单。

2.2 多智能体架构设计

基于上述问题分类，我们设计了四个核心智能体，它们各司其职，并行工作：

1. Query理解智能体 (Query Understanding Agent)：这是“门诊分诊台”。它的核心任务是解析用户查询的深层意图。它不直接判断商品是否相关，而是为后续判断提供“诊断依据”。

   • 输入：原始查询词。
   • 核心工作：
     • 类目预测：判断查询最可能指向的1-3个叶子类目。这里我们融合了基于点击数据的统计模型和基于BERT的语义模型，并对“苹果手机”vs“苹果水果”这类歧义查询做了专门处理。
     • 属性抽取：识别查询中的关键属性值对，如“颜色:白色”、“材质:雪纺”、“容量:500ml”。我们采用序列标注模型，并结合商品库的属性枚举值进行归一化。
     • 意图分类：判断是“精准购买”、“探索浏览”还是“比价”意图。这会影响后续智能体的权重分配。
   • 输出：一个结构化的意图对象，包含{预测类目列表， 属性约束集合， 意图类型}。

2. 文本匹配智能体 (Text Matching Agent)：这是“放射科医生”，专注看“片子”（文本）。它衡量商品文本信息（标题、属性、详情片段）与查询的匹配程度。

   • 输入：用户查询 vs 商品文本信息。
   • 核心工作：我们并未完全抛弃传统的BM25，因为它对精确词匹配（如型号、品牌）依然稳健。我们构建了一个混合文本匹配器：
     • 精确匹配层：处理品牌、型号等关键实体。
     • 稀疏向量层：BM25，保证基础相关性。
     • 稠密向量层：基于Sentence-BERT或SimCSE训练的双塔模型，捕捉语义相似性（如“手机壳”和“iPhone保护套”）。
   • 输出：一个0-1之间的分数，表示文本层面的相关性。

3. 行为感知智能体 (Behavior-Aware Agent)：这是“化验科医生”，分析“病理报告”（用户行为）。它认为，群众的眼睛是雪亮的，群体的行为能反映隐性的相关性。

   • 输入：查询、候选商品、以及历史行为数据（如针对该查询，用户的点击、购买、停留时长序列）。
   • 核心工作：
     • 点击模型：基于全局和Session内的点击数据，计算商品对于该查询的点击率预期值。
     • 购买转化模型：更进一步，计算点击后的购买转化率。
     • 协同过滤信号：对于新查询或新品，引入“相似查询”或“相似商品”的行为数据进行平滑。
   • 输出：一个基于行为信号的相关性置信度分数。注意：这个智能体要谨慎使用，因为它容易强化“马太效应”，需要与文本匹配智能体相互制衡。

4. 属性约束智能体 (Attribute Constraint Agent)：这是“专科医生”，专门处理“属性缺失/冲突”这类硬伤。它执行的是硬性规则或强逻辑判断。

   • 输入：Query理解智能体提取出的属性约束集合vs 商品的属性字段。
   • 核心工作：进行属性符合度校验。
     • 必须满足：如查询指定“不锈钢”，商品材质必须是“不锈钢”或其同义词，若为“玻璃”则一票否决。
     • 应该满足：如查询指定“500ml”，商品容量是“550ml”，可以接受但会扣分；若是“1000ml”，则扣更多分。
     • 数值范围处理：对价格、尺寸等数值型属性进行区间匹配。
   • 输出：一个二值结果（是否通过）或一个符合度分数（0-1）。

2.3 智能体协同与决策机制

各个智能体出具自己的“诊断意见”后，需要一个“主任医师”（决策层）来综合会诊，给出最终结论。我们设计了一个两阶段决策流程：

第一阶段：粗排与过滤

1. 首先，属性约束智能体作为守门员，对召回的海量商品进行快速过滤，直接剔除严重违反硬性约束的商品（如非不锈钢材质的“不锈钢杯”）。
2. 然后，文本匹配智能体和行为感知智能体对剩余商品进行快速打分，选出Top-N（例如500个）候选商品进入精排。

第二阶段：精排与融合对于精排阶段的候选商品，所有智能体都给出自己的分数。最终的融合分数不是简单的加权平均，而是一个基于注意力机制的动态加权网络。

• Query理解智能体输出的意图类型，会决定权重分配。例如：
  • 对于“精准购买”意图（如“iPhone 14 Pro Max 256GB 暗紫色”），文本匹配智能体和属性约束智能体的权重会非常高，行为感知智能体权重降低。
  • 对于“探索浏览”意图（如“七夕礼物”），行为感知智能体和语义泛化能力强的文本匹配智能体（稠密向量部分）权重会提高。
• 这个动态加权网络本身是一个轻量级神经网络，以各智能体的输出分数和查询意图特征为输入，通过离线训练（训练数据来自人工标注的相关性标签）学习最优的融合方式。

实操心得：权重不是静态的初期我们尝试了静态权重，效果很不稳定。动态加权的关键在于，让系统自己学会“看菜下碟”。训练这个融合模型时，正样本要包含各种意图的case，负样本尤其要多收集那些单一智能体判断失误的case（如文本匹配高但属性不符），这样模型才能学会在什么情况下该听谁的。

3. 核心模块实现细节与避坑指南

3.1 Query理解智能体的实战要点

这个模块是源头，源头错了，后面全错。我们踩过最大的坑就是“类目预测的准确性”。

• 细节1：处理类目歧义。“苹果”的例子是经典。我们的策略是：
  1. 上下文感知：利用用户实时Session信息。如果用户之前刚搜索过“MacBook”，那么接下来的“苹果”大概率是手机/电脑。我们在架构上增加了短期兴趣画像的输入。
  2. 用户画像辅助：对于新用户或无Session用户，参考其历史偏好（如长期购买数码产品 vs 购买生鲜）。
  3. 流量导向：如果“苹果手机”的日常搜索流量是“苹果水果”的100倍，那么在无任何其他信号时，优先指向手机类目，但要在结果页的类目导航栏中明确提示“您是不是在找：水果-苹果”，给予用户纠正的机会。
• 细节2：属性抽取的归一化。用户输入“500毫升”、“0.5L”、“一斤装”，都需要映射到标准属性值“500ml”。我们建立了一个庞大的“同义词-标准值”映射库，并利用商品后台类目体系中的属性值枚举来约束和修正模型的抽取结果，避免出现“粉色（可爱风）”这种无法匹配的非标准值。

避坑指南：不要过度依赖NLP模型初期我们用一个端到端的NLP模型同时做类目预测和属性抽取，发现它在标准查询上表现尚可，但在大量口语化、带错别字、简写的电商查询上，效果波动很大。后来我们拆解了任务：类目预测用“统计模型（快且稳）+语义模型（处理新品新词）”融合，属性抽取用“序列标注模型+知识库（属性枚举）校验”的管道模式，鲁棒性大大提升。记住，在工程系统里，“简单、可解释、稳定”的模块组合，往往比一个复杂黑箱模型更可靠。

3.2 文本匹配智能体的混合策略

如何让BM25和深度模型和谐共处？

• 细节1：分而治之。我们不是将BM25分数和向量相似度分数简单相加。而是设计了一个规则：
  • 如果查询中包含明确的品牌、型号、精确商品词（通过NER识别），则BM25分数的权重急剧升高。因为用户此时需要的是精确匹配，语义泛化反而可能是干扰。
  • 如果查询是场景化、需求化描述（如“办公室午睡毯”、“小学生书包轻便”），则稠密向量相似度的权重占主导。
  • 实现上，我们训练了一个轻量级分类器，先对查询类型进行判断，再选择不同的分数混合公式。
• 细节2：负样本构造。训练语义匹配模型时，负样本的质量至关重要。除了随机采样的负样本，我们特意加入了“困难负样本”：
  • 同类别不相关商品：同是“连衣裙”，但用户要“雪纺”，你给“牛仔”。
  • 文本匹配高分但实际不相关：通过BM25或早期模型找出的错误匹配case。
  • 加入这些困难样本后，模型学会了区分更细微的差异，而不是简单地学会区分“连衣裙”和“手机”这种简单差异。

3.3 行为感知智能体的冷启动与偏差处理

行为数据是双刃剑，用得好效果显著，用不好就会陷入“强者恒强”的循环。

• 细节1：冷启动问题。对于新上架商品或长尾查询，行为数据稀疏甚至为零。我们的解决方案是：
  1. 文本相似性平滑：对于新商品，用其文本信息（标题、属性）找到最相似的Top-K个老商品，用这些老商品的行为数据（经衰减处理）作为新商品的初始值。
  2. 类目基线：如果连相似商品都找不到，则回落至该商品所在类目的平均行为水平作为先验。
• 细节2：破解流行度偏差。热门商品可能因为曝光多而点击多，但这不意味着它与某个特定查询最相关。我们采用了反事实推理的思路进行纠偏：
  • 在计算行为分数时，不仅看商品对于该查询的绝对点击率，更看它的相对点击率：即（该查询下的点击率）/（该商品在全平台所有场景下的平均点击率）。如果一个商品本身就很热门，那么它在某个查询下的高点击率“含金量”可能没那么高；反之，一个不那么热门的商品在特定查询下点击率飙升，则是一个很强的相关性信号。
  • 在模型特征中，显式加入商品的全局曝光点击率作为特征，让融合模型自己去学习如何“打折”。

4. 系统落地与迭代闭环

框架设计得再好，不能稳定落地也是空谈。我们采用微服务架构，将每个智能体封装为独立的服务，通过高可用消息队列进行通信。

4.1 线上服务架构

1. 异步并行调用：当搜索请求到来时，Query理解服务首先被调用。得到结构化意图后，将其与查询词一起广播给文本匹配、行为感知、属性约束服务。这三个服务是并行调用的，极大降低了整体延迟。
2. 结果缓存：对于Query理解的结果和行为感知中基于全局统计的数据（如商品历史CTR），进行多级缓存（本地缓存+分布式缓存），热查询的响应时间可以控制在10毫秒内。
3. 降级与熔断：任何一个智能体服务出现故障或高延迟，决策层都有降级策略。例如，行为感知服务超时，则自动将其权重设为0，完全依赖文本和属性判断。确保搜索功能永远可用，即使相关性有所下降。

4.2 数据闭环与持续迭代

多智能体框架的强大之处在于它的可迭代性。我们建立了一个完整的数据闭环：

1. 在线日志收集：记录每一次搜索请求的输入（查询）、各智能体的中间输出、最终融合分数及排序结果、用户的后续行为（点击、购买、翻页、跳出）。
2. Bad Case自动挖掘：定期运行离线作业，从日志中自动识别潜在bad case。规则例如：
   • 排名靠前但无点击的商品。
   • 有点击但快速退出的商品（可能不相关）。
   • 同一Session内，用户修改查询词后点击了之前出现但未点击的商品（说明原排序不准）。
3. 人工标注与反馈：将自动挖掘的疑似bad case和随机抽样case，送入标注平台，由专业标注员判断相关性。这些新产生的标注数据，成为迭代模型的新燃料。
4. 定向迭代：根据bad case的类型，我们可以有针对性地迭代某个智能体，而不必动全身。
   • 如果是类目预测错了，就优化Query理解智能体。
   • 如果是属性没识别出来，就补充属性抽取的同义词库或调整模型。
   • 如果是语义泛化不够，就给文本匹配的稠密向量模型补充更多困难负样本。

这个闭环让整个系统具备了“自我进化”的能力。每一次bad case的修复，都让系统在某个细分问题上变得更聪明。

5. 效果评估与常见问题排查

上线不是终点，如何科学地评估效果和快速定位问题，是保证系统长期健康运行的关键。

5.1 多维度评估体系

不要只看一个整体的CTR或GMV提升，要拆开看：

我们通过A/B实验，将新框架与旧版基线模型对比。在一个月的实验期内，核心指标提升如下：NDCG@5提升了8.2%，搜索退出率降低了5.7%，尤其是“探索浏览”类查询的转化率提升了12.1%，证明多智能体在理解模糊意图上的优势。

5.2 线上问题排查清单

当监控报警或业务方反馈搜索效果波动时，可以按以下清单快速排查：

1. 问题现象：某一类商品（如“手机”）的搜索排名突然全部下降。

   • 排查步骤：
     • 检查Query理解智能体的类目预测服务：该类目的预测准确率是否骤降？模型是否刚刚更新？特征数据源是否异常？
     • 检查行为感知智能体：该类目商品的历史行为数据流是否中断或延迟，导致分数异常？
     • 检查属性约束智能体：是否新上线了某个严格的属性过滤规则，误伤了该类目？

2. 问题现象：整体搜索转化率下降，但CTR变化不大。

   • 排查步骤：
     • 分析行为感知智能体的分数权重：是否在动态融合中权重过高，导致系统过于“保守”，只推热门爆款，虽然有人点，但购买意图不匹配？
     • 检查用户行为数据流：购买行为的数据是否正常上报和处理？如果购买信号缺失，行为感知智能体的判断就会失准。
     • 查看Bad Case：新出现的bad case是否集中在“有点击无购买”的类型？这可能是商品详情页与搜索列表页信息不一致，或者价格突然变动。

3. 问题现象：特定长尾查询的效果变差。

   • 排查步骤：
     • 检查文本匹配智能体的语义模型：是否在处理某些新网络词汇或特定表述时失效？需要检查该查询下，稠密向量相似度的分数是否异常低。
     • 检查缓存：是否为该长尾查询建立了错误的缓存（例如缓存了一个旧版本的、效果差的结果）？
     • 查看数据闭环：是否有针对这类长尾查询的标注数据？如果没有，它就是系统的盲区，需要主动补充样本进行训练。

这套框架从构思到全量上线，我们花了近半年时间。最大的体会是，解决搜索相关性这种复杂问题，没有银弹。与其追求一个“终极模型”，不如建立一个灵活的、可解释的、可持续迭代的“系统生态”。多智能体的思想，让我们能够将复杂问题模块化，针对性地攻坚，并且可以随着业务发展，随时引入新的“专家”（例如，未来可以增加一个“图像理解智能体”来处理以图搜图的场景）。技术最终要服务于业务场景，而案例驱动，确保了我们的每一步迭代都踩在业务的痛点上。