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

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 线性加权融合的工程实践

线性加权是最直观的方法，但实施时有多个技术细节需要注意：

python复制def linear_fusion(sql_items, vector_items, sql_weight=0.4):
    """
    参数说明：
    sql_items: [{'id':1, 'norm_score':0.8, 'data':{...}},...] 
    vector_items: [{'id':1, 'norm_score':0.9, 'data':{...}},...]
    sql_weight: SQL结果的权重（向量权重自动为1-sql_weight）
    
    返回按融合分数排序的结果列表
    """
    # 使用字典合并相同ID的结果
    fused = {}
    
    # 处理SQL结果
    for item in sql_items:
        fused[item['id']] = {
            'final_score': item['norm_score'] * sql_weight,
            'sources': ['sql'],
            'data': item['data']
        }
    
    # 处理向量结果
    for item in vector_items:
        if item['id'] in fused:
            fused[item['id']]['final_score'] += item['norm_score'] * (1 - sql_weight)
            fused[item['id']]['sources'].append('vector')
            # 合并数据字段
            fused[item['id']]['data'].update(item['data'])
        else:
            fused[item['id']] = {
                'final_score': item['norm_score'] * (1 - sql_weight),
                'sources': ['vector'],
                'data': item['data']
            }
    
    # 按分数降序排序
    return sorted(fused.values(), key=lambda x: x['final_score'], reverse=True)

关键实现细节：

1. 分数归一化：必须将不同来源的分数映射到相同区间。我们测试发现，对于销量这类长尾数据，Z-Score归一化比Min-Max更稳定。

2. 数据合并：当同一ID出现在两个结果集时，需要深度合并data字段。我们使用递归合并算法处理嵌套字典。

3. 权重设定：通过A/B测试确定最佳权重。数据显示，对于推荐场景，sql_weight=0.4时用户点击率最高。

3.2 RRF融合的实战应用

当结果只有排名没有分数时，Reciprocal Rank Fusion（RRF）表现出色。我们在新菜品冷启动阶段大量使用该方法：

python复制def rrf_fusion(ranked_lists, k=60):
    """
    ranked_lists: [
        [{'id':1}, {'id':2}, {'id':3}],  # SQL结果
        [{'id':2}, {'id':1}, {'id':4}]   # 向量结果
    ]
    k: 平滑参数，通常取60
    """
    scores = defaultdict(float)
    
    for rlist in ranked_lists:
        for rank, item in enumerate(rlist, 1):
            scores[item['id']] += 1 / (k + rank)
    
    # 返回按RRF分数排序的结果
    return sorted([{'id':id, 'score':score} for id,score in scores.items()],
                 key=lambda x: x['score'], reverse=True)

参数调优经验：

• k值越小，排名靠前的结果优势越大。我们通过实验确定k=60时，能在头部准确性和尾部多样性间取得平衡。
• 对于需要强调头部结果的场景（如热门推荐），可以减小k到30-40。
• 添加权重后演变成Weighted RRF，成为我们的主力融合算法。

4. 餐厅业务场景的特殊处理

4.1 分层决策架构

我们设计了三级决策流程来处理餐厅查询：

1. 意图识别层：使用轻量级模型快速分类

   • 明确事实查询：直接走SQL通路
   • 明确探索查询：向量检索优先
   • 混合意图：进入融合流程

2. 并行检索层：同时发起SQL和向量查询

   • SQL查询优化：添加缓存，95%的订单查询在5ms内返回
   • 向量查询优化：使用FAISS索引，支持每秒千级QPS

3. 智能融合层：根据查询类型选择融合算法

   • 订单状态类：SQL结果优先
   • 菜品推荐类：加权RRF融合
   • 知识问答类：向量结果优先

4.2 动态权重调整策略

固定权重难以应对复杂场景，我们实现了动态权重机制：

python复制def dynamic_weight(query):
    """根据查询特征计算SQL权重"""
    # 查询包含订单号等精确信息
    if has_exact_keywords(query):
        return 0.9  
    
    # 查询长度短，倾向探索
    if len(query) < 5:
        return 0.2
    
    # 包含"推荐""类似"等词
    if has_recommend_words(query):
        return 0.3
    
    # 默认值
    return 0.5

同时考虑结果集质量：

• 当SQL结果为空时，自动降低其权重
• 当向量结果置信度低时，提高SQL权重
• 对于高价值用户，适当提高历史偏好权重

5. 性能优化与效果评估

5.1 工程优化措施

1. 异步并行查询：SQL和向量检索同时发起，通过协程控制超时
2. 结果预处理：在数据库和向量库层面预先完成简单的归一化
3. 缓存融合结果：对热门查询的融合结果缓存5-10秒
4. 批量处理：对列表页请求批量执行融合操作

5.2 评估指标体系

我们建立了多维度的评估方案：

经过3个月的迭代，关键指标提升如下：

• 推荐菜品点击率：+47%
• 订单转化率：+12%
• 融合延迟：从120ms降至35ms

6. 典型问题排查与解决

在实际部署中我们遇到了几个关键问题：

问题1：融合结果不稳定

• 现象：相同查询返回的排序结果波动大
• 原因：未对空结果做特殊处理
• 修复：添加结果质量检查，对空结果集自动降权

问题2：长尾菜品永远排不到前面

• 现象：新菜品或小众菜品难以进入推荐前列
• 原因：仅考虑相似度，缺乏多样性机制
• 解决：在RRF中引入多样性因子，对小众菜品适当加权

问题3：高并发时延迟飙升

• 现象：用餐高峰期响应变慢
• 原因：向量检索未做限流
• 解决：实现基于令牌桶的流量控制，并添加降级策略

7. 实施路线图建议

对于想要实施类似系统的团队，我建议分阶段推进：

1. 基础建设阶段（2-4周）

   • 搭建向量检索基础设施（如ES+Faiss）
   • 实现基本的线性融合算法
   • 构建评估框架

2. 算法优化阶段（4-6周）

   • 引入RRF等高级融合算法
   • 实现动态权重机制
   • 进行大规模A/B测试

3. 系统工程化阶段（持续）

   • 优化查询性能
   • 完善监控告警
   • 建立自动化调参机制

在实际项目中，我们发现先从小流量开始验证（比如先对10%的查询使用融合策略），然后逐步扩大范围是最稳妥的方式。同时要建立完善的回滚机制，当发现关键指标下跌时能快速切换回旧版。