1. 毕设选题的逻辑为什么推荐系统是性价比极高的方向每年毕业季计算机专业的同学都要面对同一个灵魂拷问做什么题目做得太简单怕答辩时被导师几句问倒做得太复杂又怕时间不够、能力不足最后草草收场。如果你正在这个十字路口徘徊又恰好掌握了一点Python基础、接触过Django或Flask框架那我强烈建议你看看基于双算法的商品推荐系统这个题目方向。这个题目的性价比体现在三个方面。第一业务流程足够完整从前端商品展示、用户登录注册到后端的推荐算法计算、行为日志收集再到管理后台的订单和商品管理覆盖了一个电商系统的主要功能闭环这在毕设答辩时就是工作量充足的直接证据。第二技术栈非常有层次感Django负责Web框架和ORM数据操作协同过滤算法承担核心推荐逻辑ECharts或原生JavaScript做数据可视化再加上可选的大模型接口做商品标签增强——从传统机器学习到最新的大模型应用都有涉及每一个技术点都能撑起一个答辩提问。第三推荐算法本身自带话题性评委老师几乎都会围绕推荐效果怎么评估冷启动怎么解决这类问题追问只要提前准备了相关素材答起来就会很有底气。我在指导某位学弟做类似项目时他一开始想做图书管理系统被我劝退了。原因很简单纯CRUD的管理系统在毕设里太常见了答辩时很难拿出有区分度的亮点。后来换成了推荐系统方向工作量相同但技术含金量和展示效果完全是两个量级。这就是选题阶段最关键的一点优先选择自带机器学习或算法标签的方向哪怕算法部分只是最经典的协同过滤也天然比纯增删改查高一个段位。2. 项目全景拆解从数据流看整站架构很多同学拿到这类项目后第一反应是代码好多从哪里看起。我的建议是不要先看代码先看数据。搞清楚了数据从哪来、存到哪里、被谁消费整个系统的骨架就清晰了。2.1 系统分层与数据流向这个推荐系统从架构上可以分为四个层次数据源层、业务逻辑层、推荐算法层、展示层。数据源层负责采集和存储原始数据。用户注册时写入用户信息浏览商品时记录浏览日志购买商品时生成订单记录收藏和加入购物车也会留下行为痕迹。这些数据在MySQL里通常表现为四张核心表用户表、商品表、订单表、行为日志表。如果还想做更精细的推荐可以单独用一张评分表来存储用户对商品的隐式反馈点击、收藏、加购、购买分别计不同的分值这样协同过滤算法的输入数据就非常干净了。业务逻辑层是Django的主场负责处理HTTP请求、调用ORM读写数据、校验用户权限、完成订单流程。这一层对应Django的views.py和urls.py是串联前端页面和后端数据的桥梁。推荐算法层是系统的灵魂。用户的商品列表页、商品详情页的猜你喜欢模块、个人中心的为你推荐区域这些位置的推荐结果都来自这一层。两种算法在这里协同工作一种基于协同过滤Collaborative Filtering利用用户与物品的历史交互行为计算相似度另一种基于商品内容特征如标题关键词、分类、价格区间、大模型生成的标签做内容推荐。两种算法的结果最终通过加权融合或加权切换的方式输出这就是标题里双算法的由来。展示层负责把推荐结果以友好的方式呈现给用户同时提供数据可视化的管理面板。Django的模板系统渲染HTML页面配合ECharts折线图、柱状图、饼图展示商品销量分布、用户活跃时段、分类热度等统计数据让系统不只是能用而是看得见效果。2.2 关键数据表设计设计数据表时有一个很重要的原则表结构要为算法服务而不是为页面服务。很多同学做管理系统时习惯先设计页面再倒推数据表但在推荐系统里算法的数据输入决定了表结构能不能用。核心的几张表大致如下用户表除了常规的username、password、email之外我在实际项目中还会加一个preference_category字段用来记录用户注册时选择的感兴趣分类。这是解决推荐冷启动问题的一个简单有效的手段——新用户没有行为数据时可以直接按偏好分类推送热门商品。商品表除了名称、价格、库存、分类、描述这些常规字段还可以设计一个tags字段存储算法生成的标签比如办公学生高性价比。这个字段可以由大模型接口根据商品标题和描述自动生成写入后供内容推荐算法使用。行为日志表是整个推荐系统的数据命脉。字段包括user_id、item_id、behavior_type浏览/收藏/加购/购买、create_time。这里切记不要用Boolean类型来标记行为而要使用带权重的枚举值因为不同行为对用户兴趣的指示强度完全不同购买行为权重最高加购和收藏次之浏览最弱。这个权重直接影响协同过滤算法中评分的计算。评分表则是数据预处理后的产物。我在项目里用Django的management command自定义管理命令周期性执行一段评分计算脚本把行为日志表中的原始行为数据转换为评分矩阵写入评分表供算法读取。这样设计的好处是算法层和数据采集层解耦什么时候跑算法、用哪一批数据都可以灵活控制。3. 双算法的第一层协同过滤从原理到代码落地协同过滤是推荐系统里最经典、最耐用的一类算法其核心思想用一句话概括就是物以类聚人以群分。在毕设项目里实现协同过滤不需要去啃复杂的矩阵分解公式直接从两种最直观的变体入手就足够了。3.1 基于用户的协同过滤找到和你相似的人基于用户的协同过滤UserCF的逻辑是找出和当前用户兴趣最相似的一批用户再看这批用户最近喜欢了什么商品把这些商品推荐给当前用户。举例来说用户A和用户B都买过《算法导论》和《深度学习》这两本书那么系统会判定A和B兴趣高度相似。这时如果B又购买了《机器学习实战》而A没有买过系统就优先把这本书推荐给A。在实际代码实现中核心是三步构建评分向量、计算相似度、生成推荐列表。下面是一个纯Python实现的用户相似度计算片段import math from collections import defaultdict def build_user_item_matrix(ratings): 将评分数据转换为用户-物品矩阵 matrix defaultdict(dict) for record in ratings: user_id record[user_id] item_id record[item_id] score record[score] matrix[user_id][item_id] score return matrix def user_similarity(user_matrix): 计算用户之间的余弦相似度 sim_matrix defaultdict(dict) users list(user_matrix.keys()) for i in range(len(users)): for j in range(i 1, len(users)): user_i, user_j users[i], users[j] items_i set(user_matrix[user_i].keys()) items_j set(user_matrix[user_j].keys()) common items_i items_j if not common: continue # 余弦相似度公式 dot sum(user_matrix[user_i][item] * user_matrix[user_j][item] for item in common) norm_i math.sqrt(sum([s ** 2 for s in user_matrix[user_i].values()])) norm_j math.sqrt(sum([s ** 2 for s in user_matrix[user_j].values()])) if norm_i 0 or norm_j 0: continue sim_matrix[user_i][user_j] dot / (norm_i * norm_j) sim_matrix[user_j][user_i] sim_matrix[user_i][user_j] return sim_matrix这段代码的关键点是余弦相似度的计算。之所以选择余弦相似度而不是Jaccard相似度是因为余弦相似度考虑了评分的高低而Jaccard只考虑是否共同出现过。在电商场景下两个用户都浏览了同一个商品但一个人给了高评分、另一个人只随手点开过这两者的兴趣强度是不同的余弦相似度能把这种差异区分开来。获得用户相似度矩阵后推荐生成就很简单了找到与目标用户相似度最高的K个用户K通常取10到20把这些人评分较高且目标用户未交互过的商品按加权评分排序后输出。3.2 基于物品的协同过滤推荐和你喜欢的东西相似的基于物品的协同过滤ItemCF是电商平台使用最广泛的方案也是这个项目里我更推荐优先落地的一种。它的逻辑是统计喜欢物品A的用户还喜欢哪些物品如果两个物品经常被同一批用户消费就认为它们相似。ItemCF的优势在于计算量可以离线完成。商品数量远小于用户数量物品相似度矩阵可以提前算好存入缓存用户请求推荐时只需要查询和该用户最近交互物品最相似的TopN商品即可响应速度很快。在Django项目中可以把物品相似度矩阵序列化后存储在Redis或者直接使用内存计算每次启动项目时重新加载。物品相似度的代码实现逻辑如下def item_similarity(user_matrix): 基于用户行为计算物品相似度 # 先统计每个物品被哪些用户评分过 item_users defaultdict(set) for user, items in user_matrix.items(): for item, score in items.items(): item_users[item].add(user) # 计算物品间的共现矩阵 item_sim defaultdict(dict) for item, users in item_users.items(): for user in users: for other_item in user_matrix[user]: if other_item item: continue # 累加共现次数 item_sim[item][other_item] item_sim[item].get(other_item, 0) 1 # 归一化处理 for item in item_sim: max_count max(item_sim[item].values()) if max_count: for other_item in item_sim[item]: item_sim[item][other_item] item_sim[item][other_item] / max_count return item_sim这里我做了个小小的改进在得到共现次数后用每个商品的最大共现次数做了归一化处理把相似度压缩到0到1的区间。这个处理能让不同热度商品之间的相似度可比避免热门商品每次都赢者通吃。原始代码里也可以改用共现次数 / sqrt(物品A被交互次数 * 物品B被交互次数)的改进型公式效果更接近标准做法但计算开销会大一些毕设阶段用归一化处理就足够了。3.3 两种协同过滤的选型对比下面这张表是我在实际项目中选择算法变体时的参考对比维度基于用户的协同过滤基于物品的协同过滤适用场景用户数量少、内容更新快如新闻资讯物品数量少、用户量大如电商网站实时性用户行为变化后需重新计算用户相似度物品相似度可离线预计算实时性好冷启动表现新用户无行为数据时完全失效同样失效但可通过热门商品兜底算力消耗依赖用户间相似度用户多时开销大物品相似度可提前算好请求时开销小推荐解释和你相似的人也买了因为你买过某商品所以推荐在毕设的项目文档和答辩PPT里这张表是非常好的展示材料它能让评委看到你不仅会调代码还理解算法在不同场景下的取舍。我在实际项目中做了个折中方案用户如果没有足够行为数据就调用UserCF行为数据充足则切换为ItemCF这个按条件切换的策略在答辩讲双算法协同时也成了一个不错的亮点。4. 双算法的第二层内容画像与大模型标签的融合策略协同过滤算法有一个天生缺陷就是冷启动问题——当系统里没有足够多的用户行为数据时评分矩阵非常稀疏相似度计算结果几乎无意义。解决办法是引入第二种算法基于内容的推荐Content-based Recommendation。这种算法不依赖用户行为而是分析商品本身的内容特征根据用户历史偏好的特征进行匹配推荐。4.1 基于内容的推荐从商品特征找兴趣基于内容的推荐核心是把每个商品表示为一个特征向量然后计算用户特征向量和商品特征向量之间的相似度。特征从哪里来最简单的方式是使用商品的分类、标题关键词、价格区间等结构化字段通过TF-IDF文本向量化或者直接构建特征标签来进行匹配。我在项目里采用的方法是先把商品的标题和描述分词去除停用词后提取关键词用TF-IDF计算每个词的权重再把分类和价格区间作为附加特征拼入向量。然后用余弦相似度计算用户偏好向量与商品向量的距离得分高的商品进入推荐列表。Django端的实现示例如下# recommend/content_based.py from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity import joblib def train_content_model(items): 基于商品描述训练内容推荐模型 descriptions [f{item.title} {item.category} {item.tags} for item in items] vectorizer TfidfVectorizer(max_features500, stop_wordsenglish) item_vectors vectorizer.fit_transform(descriptions) # 保存模型避免重复训练 joblib.dump(vectorizer, models/content_vectorizer.pkl) joblib.dump(item_vectors, models/item_vectors.pkl) return vectorizer, item_vectors def recommend_by_content(user_profile_vector, item_vectors, top_n10): 基于内容相似度生成推荐 sims cosine_similarity(user_profile_vector, item_vectors) top_indices sims.argsort()[0][-top_n:][::-1] return top_indices.tolist()这里用了scikit-learn的TF-IDF向量化和余弦相似度函数比自己手写更稳定、效率更高。需要注意的一点是训练好的向量化器和物品向量要保存下来避免每次请求都重新训练一遍。在Django中可以通过joblib或pickle直接序列化保存到项目目录下服务启动时加载一次即可。4.2 大模型辅助给商品打上人能读懂的标签内容推荐的效果很大程度上取决于商品特征的表达能力。仅靠标题和分类提取的关键词往往丢掉了商品隐含的消费场景信息比如一款便携榨汁杯标题里可能只有品牌和容量但用户购买它的核心动机是办公室使用或者健身代餐。这种场景化信息传统的分词和TF-IDF很难捕捉到这时候大模型就能派上用场。我在项目里调用了大模型的文本生成接口对每个商品生成3到5个标签写入商品的tags字段。比如输入商品标题苏泊尔便携榨汁机家用小型榨汁杯无线充电果汁机大模型返回的标签可能是[办公室便携, 健身代餐, 充电便携, 家用小型]。这些标签后续会被加入内容推荐的TF-IDF语料中显著提升了特征表达的丰富度。调用大模型的代码逻辑大致如下# services/llm_tagging.py import requests import json def generate_tags(title, description): 调用大模型接口生成商品标签 prompt f 请根据以下商品标题和描述生成3-5个消费场景标签。 要求标签要体现使用场景、目标人群或产品特性每个标签不超过6个汉字。 商品标题{title} 商品描述{description} 输出格式直接输出标签用英文逗号分隔不要多余文字。 response requests.post( https://api.example.com/v1/chat/completions, headers{Authorization: Bearer YOUR_API_KEY}, json{ model: deepseek-chat, messages: [{role: user, content: prompt}], temperature: 0.3 }, timeout10 ) data response.json() content data[choices][0][message][content] tags [tag.strip() for tag in content.split() if tag.strip()] return tags大模型接入的关键是控制好调用频率。毕设项目的数据量通常在几百到几千条商品如果每件商品都实时调用接口不仅慢还可能触发接口配额限制。我的做法是写一个Django管理命令启动后批量遍历商品表对tags为空的商品生成标签然后存入数据库已经生成过标签的商品直接跳过。这样整个系统运行时不会有大模型调用的延迟标签生成是一次性的离线任务。4.3 双算法融合不是平均分而是加权综合排序有了协同过滤的结果和内容推荐的结果最后一步是把两者融合成最终的推荐列表。这一部拿捏得好整个推荐系统的智能感就出来了。我采用的融合策略是基于用户行为丰富度动态调整权重。对于行为数据丰富的用户协同过滤的结果可信度更高权重占60%到70%对于新用户或者行为稀疏的用户内容推荐占主导。具体实现时可以用一个分数融合函数# recommend/fusion.py def fuse_recommendations(cf_items, content_items, cf_weight0.6): 加权融合两种推荐结果 merged {} # 协同过滤结果 for item_id, score in cf_items: merged[item_id] merged.get(item_id, 0) score * cf_weight # 内容推荐结果 for item_id, score in content_items: merged[item_id] merged.get(item_id, 0) score * (1 - cf_weight) # 按融合分数排序取TopN sorted_items sorted(merged.items(), keylambda x: x[1], reverseTrue) return [item_id for item_id, _ in sorted_items[:20]]这里需要注意一个问题协同过滤和内容推荐的分数量纲不一样直接加权没有意义。所以我在融合前对每个算法的原始得分做了一次归一化把得分映射到0-1区间然后再加权求和。实践中可以把这个归一化做得更精细比如采用Z-score归一化或者Min-Max归一化不同数据分布下的表现会有些差异但毕设阶段Min-Max归一化够用了。5. 前端展示与可视化不是只要表格而是讲故事的仪表盘推荐系统的后台管理界面很容易被做成一堆表格堆叠的风格——商品列表一个表格、用户列表一个表格、订单列表又一个表格。这种界面能交差但视觉效果平平。在毕设答辩时一个包含数据可视化图表的管理面板往往会带来这个工作量扎实的直接观感。5.1 Django模板渲染与推荐位逻辑前端页面我采用Django默认的模板系统配合Bootstrap和原生JavaScript没有额外引入复杂的前端框架。这样做的考虑是Django模板语法可以直接在HTML中嵌入动态数据对于毕设项目来说完全够用且容易调试省去前后端分离带来的跨域、接口联调等额外工作量。推荐位的展示逻辑主要集中在三个位置。首页是热门推荐这个列表默认按商品销量或综合评分排序用户未登录时展示的就是这个登录后首页会变为猜你喜欢此时后端会调用推荐算法生成个性化列表商品详情页下方设置相关推荐这个位置主要用ItemCF逻辑推荐与当前商品相似度最高的几个商品。商品推荐位的view函数大致长这样# store/views.py from django.shortcuts import render from .models import Product, Rating from recommend.fusion import fuse_recommendations from recommend.collaborative import get_cf_recommendations from recommend.content_based import get_content_recommendations def index(request): user request.user if user.is_authenticated: # 登录用户个性化推荐 cf_items get_cf_recommendations(user.id, top_n20) content_items get_content_recommendations(user.id, top_n20) cf_weight get_cf_weight(user.id) # 根据行为丰富度计算权重 recommend_ids fuse_recommendations(cf_items, content_items, cf_weight) recommended_products Product.objects.filter(id__inrecommend_ids).order_by( # 此处可按推荐得分自定义排序 ) else: # 未登录用户热门兜底 recommended_products Product.objects.order_by(-sales_count)[:12] return render(request, store/index.html, {products: recommended_products})页面渲染时Django模板里用{% for product in products %}循环输出商品卡片每个卡片展示主图、名称、价格、销量和加入购物车按钮。为了让页面不显得呆板我还给每个推荐位加上了推荐理由的展示比如因为你浏览过无线蓝牙耳机、和你相似的用户也买了智能手环。这个细节在答辩演示时非常加分它让推荐结果不再是冷冰冰的商品罗列而是有了算法在思考的可感知效果。5.2 ECharts可视化把算法效果画出来数据可视化部分我选择ECharts开源图表库它的中文文档齐全、图表类型丰富、渲染性能好非常适合快速搭建仪表盘。在Django的模板中引入ECharts的方式很简单在HTML头部加载CDN的JS文件后用JavaScript初始化一个图表实例即可。关键是把Django后端查询到的统计数据以JSON格式传递到JavaScript变量中供图表使用。以下是一个每日销售量趋势图的实现思路!-- templates/admin/dashboard.html -- div idsales-trend stylewidth: 100%; height: 400px;/div script srchttps://cdn.jsdelivr.net/npm/echarts5/dist/echarts.min.js/script script var salesTrend echarts.init(document.getElementById(sales-trend)); var dates {{ dates | safe }}; // [2025-05-01, 2025-05-02, ...] var sales {{ sales | safe }}; // [15, 22, 18, ...] salesTrend.setOption({ title: { text: 近7日销售量趋势 }, tooltip: { trigger: axis }, xAxis: { type: category, data: dates }, yAxis: { type: value }, series: [{ name: 销量, type: line, data: sales, smooth: true, areaStyle: { opacity: 0.2 } }] }); /script类似地分类销售占比可以用饼图展示用户活跃时段分布可以用柱状图展示推荐算法覆盖率可以用仪表盘组件展示。一套数据可视化面板做下来整个项目在使用观感上会有一个明显提升。这里有一个经验性的提醒ECharts图表如果数据为空或者数据格式不对会导致图表区域渲染失败甚至JS报错。在Django的view中要确保传给模板的JSON数据是合法的列表或字典如果数据库为空最好给个默认值比如dates []时页面显示暂无数据占位图这比一个空白报错区域专业得多。6. 跑通项目的环境配置与避坑清单毕设项目拿到手能不能顺顺利利地在本地跑起来往往决定了你接下来一周的心情。这部分我专门整理了环境配置的完整流程和我在实际部署中踩过的几个坑照着走能省很多时间。6.1 环境准备与依赖安装项目的基础环境要求如下表依赖项推荐版本说明Python3.8 - 3.11版本过高或过低都可能在依赖安装时出现问题Django3.2 LTS 或 4.x选择长期支持版本稳定性和示例代码兼容性好MySQL5.7 或 8.0也可以用SQLite替代但MySQL更贴近生产环境pandas1.5.x数据处理与评分矩阵构建numpy1.24.x向量计算和矩阵操作scikit-learn1.2.xTF-IDF向量化和相似度计算joblib1.2.x模型持久化保存requests2.31.x调用大模型接口安装依赖时推荐使用virtualenv或conda创建独立虚拟环境避免和系统Python环境互相污染。然后在项目根目录执行pip install -r requirements.txt python manage.py migrate python manage.py createsuperuser python manage.py runserver如果项目里有用到MySQL不要忘记先在MySQL中创建好数据库并根据settings.py中的配置调整用户名和密码。6.2 高频踩坑点与解决方案第一个坑是中文乱码。很多基于Django的电商项目在展示商品信息时会出现中文乱码原因往往是MySQL数据库的字符集不是utf8mb4。解决办法是在创建数据库时指定编码CREATE DATABASE ecommerce CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;同时在Django的settings.py的DATABASES配置中添加OPTIONS: {charset: utf8mb4}。如果从旧库导入了数据还需要确认SHOW CREATE TABLE里的默认字符集也是utf8mb4。第二个坑是协同过滤评分矩阵的稀疏问题。刚开始用真实行为数据测试时用户和商品的交互记录很少评分矩阵的稀疏度可能超过95%导致相似度计算几乎找不到共同项。应对思路有两种一是使用填充值策略对用户未交互的商品填0分同时计算相似度时鼓励使用皮尔逊相关系数而不是余弦相似度二是干脆只对最近30天有行为记录的用户和商品做计算缩小矩阵规模。实践中第二种方法的效果更好我基本都用这种方式。第三个坑是物品相似度计算消耗过大。如果商品数量到了几千件两两计算相似度的复杂度是O(n²)在低配电脑上可能要跑很久。解决方法是限制候选集只对同一分类下的商品计算相似度不同分类的商品之间不计算。电商场景下用户买了一本书推荐同类别的书比推荐一个完全不同品类的商品要合理得多这个限制不仅不影响推荐质量反而让推荐结果更精准。第四个坑是大模型接口调用的超时和重试。调用外部接口如果遇到网络波动可能导致接口挂起几十秒。所以我用了requests库的timeout参数设置了10秒超时并且加了异常处理和日志记录。失败时不阻断主流程给商品打上默认标签比如用分类名直接当标签保证推荐系统整体可用。6.3 数据集的准备自己造还是用公开数据很多同学纠结推荐系统项目应该用什么数据集。公开数据集如某电商平台的公开商品数据、某电影评分数据集数据量大、格式规整适合跑算法实验但毕设答辩演示时数据里的商品名称和品类和你的页面设计可能不搭看起来很违和。我的做法是用公开数据做算法调优和性能验证同时自己造了200到300条贴近页面风格的商品数据用于系统演示。商品名称、图片、分类、价格都是可以手动构造的行为日志则写一个脚本模拟一批虚拟用户的点击、收藏、购买记录这样推荐算法就有足够的行为数据可跑演示效果非常自然。模拟数据的脚本也不复杂核心就是随机生成用户与商品的交互# manage.py generate_fake_data import random from store.models import User, Product, BehaviorLog def generate_behavior_logs(num_users50): products list(Product.objects.all()) for user_id in range(1, num_users 1): interacted random.sample(products, krandom.randint(5, 30)) for product in interacted: behavior random.choices( [view, cart, collect, purchase], weights[6, 2, 1, 1], k1 )[0] BehaviorLog.objects.create( user_iduser_id, item_idproduct.id, behavior_typebehavior )7. 答辩准备与后续扩展思路一个能跑的项目只是完成了60%剩下的40%在于让评委快速理解你的工作量和亮点。这一节我分享一些答辩时的准备技巧和这个项目的扩展方向。7.1 答辩演示脚本与高频问题答辩时不要漫无目的地打开浏览器随便点提前准备好一条演示路径从首页推荐位开始登录一个行为数据丰富的测试账号展示推荐结果是如何随行为变化的再切到一个新注册的空白账号展示冷启动阶段的内容推荐策略最后进入管理后台用数据可视化面板展示整体运营数据。这条演示路径能自然地把两种算法都讲清楚。评委的高频问题基本集中在四个方面一是推荐算法的准确率如何衡量。你可以回答在小规模测试中使用了精确率Precision和召回率Recall指标通过把行为日志按时间切分用前70%的数据训练、后30%的数据验证计算推荐命中率。毕设阶段不追求绝对数值高更看重评估流程的完整性。二是冷启动问题怎么解决。这是必问的回答思路就按照内容推荐和大模型标签辅助的路子来讲新用户没有行为时通过注册时选择的偏好分类推荐热门商品新商品没有销量时通过商品标签匹配用户偏好。三是双算法为什么这样搭配。这个问题就是要讲清楚协同过滤捕捉用户行为规律内容推荐捕捉商品特征语义两者互补协同过滤在新用户场景失效时内容推荐能兜底。四是系统如果部署到线上会遇到什么问题。可以如实回答数据量增大后需要引入Redis做缓存、分布式计算框架做离线推荐任务数据库要加索引和读写分离。这一问更多是考察你有没有工程化的思维。7.2 从毕设到完整项目的扩展方向如果你的时间和精力允许这个项目在毕设之后还可以继续发酵成更有分量的作品。方向一引入实时推荐流基于用户实时点击事件调整推荐结果这部分可以接入WebSocket或消息队列把推荐延迟控制到秒级。方向二引入深度学习模型用神经协同过滤NCF或者Wide Deep模型替代传统的相似度计算Django后端只需要替换算法层整体架构几乎不用动。方向三把推荐系统包装成一个小型SaaS服务做成可配置的推荐API给其他中小电商网站调用这样作品就从课程设计变成了产品原型含金量大不一样。我在实际参与多个毕设项目的辅导过程中发现推荐系统方向之所以值得推荐核心在于它有非常清晰的问题边界和解决方案层次既不会难到让人从入门到放弃又有足够深的技术细节让愿意钻研的同学发挥。无论你是准备用它应付毕业答辩还是真的想探索推荐算法的工程实践这个题目的价值都经得起推敲。最后多提一句选题和实现过程中如果出现算法效果不好或者页面和数据对不上这类问题几乎都能从数据层的准确性找到根源所以动手前先把表结构和数据流理顺后面你会感谢自己当时多花的那半小时。
