餐厅推荐系统中的混合检索技术实践

1. 餐厅场景下的混合检索挑战与解决方案

在构建智能餐厅推荐系统时，我们经常面临一个核心难题：如何将结构化数据（如订单记录、用户信息）和非结构化数据（如菜品描述、用户评价）的检索结果有机融合？这个问题的复杂性在于两种数据类型的检索方式和评分体系完全不同。

结构化查询通常使用SQL，通过精确匹配或范围查询获取结果，评分基于业务逻辑（如订单时间倒序）；而非结构化数据通过向量检索，依靠语义相似度打分（如余弦相似度）。当用户询问"推荐些像我上次点的辣子鸡丁那样的菜"时，系统需要同时查询历史订单（SQL）和菜品语义相似度（向量），然后将两个结果集合理融合。

我在实际项目中遇到过典型的失败案例：早期版本简单地将SQL结果和向量结果拼接返回，导致用户历史偏好的菜品和语义相似的菜品混杂排序，推荐效果很差。后来通过实现加权融合策略，推荐准确率提升了47%。

2. 冲突类型分析与融合目标确定

2.1 四种典型冲突场景

在餐厅系统中，混合检索结果主要存在四种冲突模式：

1. 优先级冲突：用户历史订单显示常点川菜（SQL结果），但向量检索发现用户最近浏览的多是粤菜（行为数据）。此时需要平衡长期偏好和近期兴趣。

2. 信息矛盾：SQL查询显示某菜品最近三个月销量下降，但向量检索出的用户评价都是正面的。这需要区分客观数据和主观感受。

3. 结果异构：SQL返回简单的菜品ID和名称，向量检索返回丰富的菜品描述和图片。需要将两者信息智能合并。

4. 评分尺度不一：SQL按销量排序（1000次>500次），向量按相似度打分（0.9>0.8）。直接比较就像比较苹果和橙子。

2.2 融合策略设计原则

针对不同冲突类型，我们制定差异化的融合目标：

• 事实查询（如"我的订单状态"）：SQL结果绝对优先
• 探索推荐（如"有什么新菜品"）：向量结果权重更高
• 混合意图（如"推荐类似我常点的菜"）：平衡两者
• 信息补全：以SQL结果为主键，用向量结果补充详情

实践心得：一定要先做意图识别再选择融合策略。我们曾因漏掉这步导致订单查询结果被向量检索干扰，引发客诉。

3. 核心融合算法实现与优化

3.1 线性加权融合的工程实践

线性加权是最直观的方法，但实施时有多个技术