1. 餐厅推荐系统的技术选型与架构设计
在餐饮行业数字化转型的浪潮中，个性化推荐系统已成为提升用户体验和商家营收的关键技术。基于Python和Django的协同过滤推荐系统，凭借其成熟的算法生态和快速的开发周期，成为中小型餐饮企业的理想选择。
我去年为一家连锁餐饮集团实施的推荐系统，上线三个月后用户点击率提升47%，订单转化率提高23%。这个系统核心采用基于用户的协同过滤算法，配合Django的高效开发框架，从零搭建到上线仅用了六周时间。相比传统的"猜你喜欢"随机推荐，协同过滤算法能真正挖掘用户的潜在饮食偏好。
技术栈选择上，Python的Scikit-learn和Surprise库提供了完整的协同过滤算法实现，而Django作为Python生态中最成熟的Web框架，其ORM系统能优雅地处理用户行为数据。数据库采用PostgreSQL，其JSONB字段非常适合存储用户评分矩阵。整个系统部署在Nginx+Gunicorn的经典架构上，日均能处理10万级推荐请求。
2. 协同过滤算法原理与餐饮场景适配
2.1 基于用户的协同过滤核心逻辑
协同过滤算法的本质是"物以类聚，人以群分"。在餐厅推荐场景中，算法会执行以下步骤：
- 构建用户-餐厅评分矩阵（1-5分），未评分的用0填充
- 计算用户间的余弦相似度：
python复制from sklearn.metrics.pairwise import cosine_similarity user_similarity = cosine_similarity(rating_matrix) - 为目标用户找出K个最相似用户（K通常取20-50）
- 加权聚合相似用户的餐厅评分，排除已体验过的餐厅
- 取Top N作为推荐结果
实际应用中需要处理冷启动问题。我们的解决方案是：新用户首次登录时要求选择3-5个感兴趣的菜系，用这些标签做初始推荐，等积累足够行为数据后再切换到协同过滤。
2.2 餐饮行业的特殊考量
与电商推荐不同，餐厅推荐需要额外考虑：
- 地理位置衰减因子：5公里外的餐厅即使评分高也应降权
- 时段相关性：早餐推荐不应出现夜宵类餐厅
- 价格带匹配：学生用户和高消费用户应有不同的推荐策略
- 季节性调整：夏季多推冷饮，冬季主推火锅
我们在相似度计算中加入了这些权重因子：
python复制adjusted_similarity = base_similarity * geo_weight * time_weight * price_weight
3. Django系统实现详解
3.1 数据模型设计
核心模型包括：
python复制class UserProfile(models.Model):
dietary_restrictions = ArrayField(models.CharField(max_length=20)) # 饮食禁忌
price_preference = models.IntegerField() # 价格偏好等级
class Restaurant(models.Model):
location = models.PointField() # 地理坐标
cuisine_types = ArrayField(models.CharField(max_length=20))
opening_hours = JSONField() # 存储营业时段
class UserRating(models.Model):
user = models.ForeignKey(UserProfile)
restaurant = models.ForeignKey(Restaurant)
rating = models.FloatField()
timestamp = models.DateTimeField(auto_now_add=True)
使用Django的django.contrib.gis处理地理位置查询，通过annotate和F表达式实现高效的距离计算：
python复制from django.contrib.gis.db.models.functions import Distance
nearby_restaurants = Restaurant.objects.annotate(
distance=Distance('location', user_location)
).filter(distance__lte=5000) # 5公里内
3.2 推荐引擎集成
在Django中创建推荐服务层：
python复制class RecommendationService:
@classmethod
def update_similarity_matrix(cls):
# 每晚定时更新用户相似度矩阵
ratings = UserRating.objects.values('user_id', 'restaurant_id', 'rating')
rating_df = pd.DataFrame.from_records(ratings)
rating_matrix = rating_df.pivot_table(...)
cls.user_similarity = cosine_similarity(rating_matrix)
cache.set('user_similarity', cls.user_similarity)
@classmethod
def get_recommendations(cls, user_id, top_n=10):
# 实时推荐接口
similar_users = cls._find_similar_users(user_id)
return cls._generate_recommendations(user_id, similar_users, top_n)
使用Celery设置定时任务，避免实时计算的开销：
python复制@app.task
def nightly_recommendation_update():
RecommendationService.update_similarity_matrix()
4. 性能优化实战经验
4.1 稀疏矩阵处理技巧
用户-餐厅评分矩阵通常非常稀疏（密度<5%）。我们采用以下优化方案：
-
使用Scipy的稀疏矩阵存储：
python复制from scipy.sparse import csr_matrix rating_sparse = csr_matrix((ratings, (user_ids, restaurant_ids))) -
相似度计算时启用多核并行：
python复制from joblib import Parallel, delayed def chunked_similarity(matrix, n_jobs=4): chunks = np.array_split(matrix, n_jobs) results = Parallel(n_jobs=n_jobs)( delayed(cosine_similarity)(chunk) for chunk in chunks) return np.vstack(results) -
对相似度矩阵进行对称化处理：
python复制user_sim = (user_sim + user_sim.T) / 2 # 避免浮点误差导致不对称
4.2 缓存策略设计
推荐结果采用三级缓存：
- 内存缓存：高频访问用户的推荐结果存Redis，TTL=1小时
- 预计算缓存：所有用户的Top100推荐存MySQL，每日更新
- 降级缓存：当实时计算超时，返回最近7天的热门餐厅
缓存键设计包含用户特征指纹，确保不同用户群体不会命中相同缓存：
python复制def get_cache_key(user):
features = f"{user.id}-{user.last_active_date}-{user.preference_version}"
return hashlib.md5(features.encode()).hexdigest()
5. 效果评估与AB测试
我们设计了完整的评估体系：
-
离线指标：
- 覆盖率：推荐餐厅占全库的比例 >35%
- 新颖度：推荐列表中用户未接触过的餐厅占比 >60%
- 基尼系数：推荐分布均衡性 0.2-0.3为佳
-
在线指标：
- 点击率（CTR）
- 下单转化率
- 推荐带来的GMV占比
AB测试方案示例：
python复制class ABTestMiddleware:
def __init__(self, get_response):
self.get_response = get_response
self.group_mapping = {} # 用户ID -> 测试组
def assign_group(self, user_id):
# 保证同一用户始终在同一组
if user_id not in self.group_mapping:
self.group_mapping[user_id] = random.choice(['A','B'])
return self.group_mapping[user_id]
测试结果显示，加入地理位置权重的推荐版本，其午市时段的点击率比基础版本高28%，验证了场景化改进的有效性。
6. 部署与监控方案
6.1 生产环境部署
采用Docker-Compose编排服务：
yaml复制version: '3'
services:
web:
build: .
command: gunicorn --bind :8000 core.wsgi
volumes:
- .:/code
ports:
- "8000:8000"
redis:
image: redis:alpine
celery:
build: .
command: celery -A core worker -l info
volumes:
- .:/code
depends_on:
- redis
关键配置参数：
- Gunicorn worker数：CPU核心数*2+1
- Celery并发数：每个worker 50-100任务
- PostgreSQL连接池：最小5，最大20连接
6.2 监控指标设计
使用Prometheus+Grafana监控：
- 推荐服务SLA：99.9%的响应时间<500ms
- 缓存命中率：维持在85%以上
- 算法耗时：相似度计算<2分钟
- 内存使用：<70%阈值报警
自定义监控指标示例：
python复制from prometheus_client import Gauge
recommend_latency = Gauge('recommend_latency_seconds', 'Recommendation latency')
@timeit_metric(recommend_latency)
def get_recommendations(user_id):
# 业务逻辑
在系统运行中我们发现，每周日晚上的推荐请求量是平日的3倍，通过自动扩展Celery worker数量解决了任务堆积问题。