基于协同过滤算法的家居选购系统设计与实现-北京尧图网络

1. 选题背景为什么用协同过滤算法做家居选购1.1 家居选购的决策特点做毕设选题时很多人第一反应是做一个常规的电商系统商品管理、购物车、订单结算一套流程走完但这样的系统技术含量有限答辩时很难讲出亮点。我最后定的是“基于协同过滤算法的家居选购系统”核心思路不是再做一个电商Demo而是把重点放在推荐算法上用户进入系统后不再靠自己去分类列表里翻找而是由系统根据历史行为数据主动推算出“这个用户可能喜欢什么家居商品”。家居选购这个场景很有意思。它和买书、买零食完全不同——低频、高客单价、决策周期长。用户不会像买日用品那样隔三差五下单可能一年就买一两次每次都要货比三家。这个特点直接影响推荐算法的设计如果用基于用户的协同过滤会遇到用户行为数据稀疏的问题如果单纯用基于物品的协同过滤又需要更精细地刻画物品之间的搭配关联。系统做得怎么样很大程度上取决于你针对这些痛点做了哪些处理这就是项目真正的价值所在。1.2 协同过滤算法为什么契合这个场景协同过滤算法在推荐系统里属于经典中的经典核心假设是如果用户A和用户B在历史行为上相似那么A喜欢的物品B大概率也喜欢反过来如果物品X和物品Y经常被同一批用户购买或收藏那么当用户买了X时系统就应该把Y也推给用户。家居选购恰好有很强的内容关联性。举个很直白的例子一个用户买了北欧风原木色餐桌大概率也需要同风格的餐椅、桌布或者吊灯。这种关联不是商品分类层面能解决的因为分类只是一种标签而协同过滤挖掘的是用户行为背后真实的共同出现规律。相比规则推荐比如“买了餐桌的人也可能买桌布”这种人工设定的关联协同过滤的优势是规律自己从数据里长出来不需要人工一条条维护规则。对于一个毕设项目来说算法原理清楚、实现路径明确、效果可量化这个选题的完成度和展示空间都很高。1.3 毕设的系统定位与技术选型背景这个项目定位是一个带Web前端、后端服务、数据库和推荐引擎的完整系统。基础功能包括用户注册登录、商品浏览、收藏、加入购物车、模拟下单核心亮点是独立的推荐模块用户登录后首页展示“猜你喜欢”商品详情页展示“相关搭配推荐”用户个人中心展示“历史浏览相似推荐”。技术栈的选择上我倾向于Python做推荐算法部分因为NumPy和Pandas处理相似度矩阵非常方便代码量比Java少一截。Web端可以用Flask或者Django做后端前端用普通HTML/CSS/JavaScript或者Vue按需选择。数据库用MySQL存用户表、商品表、行为表、推荐结果表。推荐引擎单独抽成一个模块加载用户行为数据后离线计算相似度矩阵再通过接口返回推荐列表。这套结构清晰、演示方便也符合毕设评审老师对“系统完整性”的期待。2. 算法设计家居场景下协同过滤的两种核心路线2.1 基于用户的协同过滤UserCF基于用户的协同过滤思路很直观先找到和你兴趣最像的一批人然后把这些人喜欢的、但你没见过的家居物品推荐给你。实现上分三步。第一步构建用户-物品评分矩阵行是用户列是物品值可以是显式评分也可以用收藏、点击、加购等隐式行为量化。第二步用余弦相似度或皮尔逊相关系数计算用户之间的相似度找到当前用户的TopK相似邻居。第三步汇总邻居们对候选物品的评分加权计算出当前用户对物品的预测评分取TopN生成推荐列表。在毕设里我用的评分量化方式是这样浏览计1分收藏计3分加购计5分下单计8分。这种人工量化的好处是简单直接不需要做复杂的隐式反馈建模演示时效果也比较直观。但UserCF有个明显问题家居选购低频新用户几乎没有历史行为用户相似度根本算不准。而且在线用户量不够大时相似用户的计算结果波动很明显这是我在实验阶段真实碰到过的现象。2.2 基于物品的协同过滤ItemCF基于物品的协同过滤解决的是另外一类问题不用找相似用户而是找相似物品。核心逻辑是——计算物品i和物品j之间的相似度依据是“有多少用户同时喜欢这两件物品”。当用户喜欢过某个物品时系统就把和它最相似的物品推荐出去。家居选购场景下单品的关联购买行为非常常见一个用户同时下单了床和床头柜同时收藏了沙发和茶几这些行为天然地构建了物品之间的关联。ItemCF的计算公式在学术上常用余弦相似度sim(i, j) |N(i) ∩ N(j)| / sqrt(|N(i)| * |N(j)|)N(i) 是对物品i产生过行为的用户集合分子是两个物品共同被行为的用户数分母是两个物品各自行为用户数的几何平均。这个公式的直观理解是两件物品被同一批用户喜欢的程度越高它们就越相似。实现时我直接用Pandas的透视表把评分矩阵转换成物品-用户矩阵然后用矩阵乘法一步算出所有物品对的相似度效率非常高。实际测试下来ItemCF在家居场景中的推荐效果明显好于UserCF。原因也好理解物品的共现规律比用户的相似性更容易在稀疏数据下被捕捉到。一个用户可能只有3条行为记录但每一条都能贡献给物品关联UserCF却可能需要十几个行为记录才能跟别人对上号。2.3 家居场景下的算法选择与混合策略我的最终方案不是二选一而是组合使用。首页的“猜你喜欢”用基于物品的协同过滤做主推荐因为它稳定、可解释性强。商品详情页的“相关搭配推荐”用基于物品的协同过滤计算相似商品但会加上过滤条件同一品牌或同类风格的商品权重适当提高。“相似用户还买了什么”则用UserCF计算展示的是社交性的推荐结果这部分虽然命中率不如ItemCF但演示价值高能让评审老师直观看到两种算法的区别。混合策略上我用的是加权融合最终得分 0.7 × ItemCF得分 0.3 × UserCF得分。权重是在实验基础上调的这个比例在我的测试数据上综合表现最好——ItemCF保证了推荐的相关性UserCF带来了意外发现的多样性。调权重的过程是真实做项目最花时间的地方但这个参数没有标准答案数据不同最优值就不同建议拿到自己的数据后跑几组对比而不是直接抄网上参数。3. 从评分矩阵到推荐列表核心模块实现细节3.1 数据来源与评分矩阵构造毕设项目的数据是很多人头疼的地方。真实电商数据不公开自己造数据又怕不真实。我的做法是两条腿走路基础商品库用爬虫采集的公开家居电商数据只保留商品名、图片、分类、价格这些公开字段外链一律去掉用户行为数据用脚本模拟生成。行为数据生成要符合真实规律不能均匀随机乱来。我设定了几种用户画像偏好北欧风的用户会更倾向于浏览和收藏原木色、简约款商品偏好中式风的用户对深色实木家具兴趣更高。生成时按照“用户画像 - 候选商品池 - 行为类型加权”的流程构造记录这样数据里自带规律协同过滤算法才能学出有价值的模式。我用这个方式生成了50个用户、近2000条行为记录对毕设演示来说足够。评分矩阵最终用Pandas来做行为用户ID列为商品ID值为行为量化得分空缺填0。这里有一个细节矩阵千万不要用稠密矩阵存20个用户800个商品就是16000格数据量小还能接受但毕设演示如果数据扩到上万条记录稠密矩阵的内存和计算开销会直接爆炸。用稀疏矩阵SciPy的CSR格式是正确做法矩阵乘法的速度也会快很多。3.2 相似度计算的选取与实现相似度算法我对比过余弦相似度、皮尔逊相关系数和Jaccard相似度。余弦相似度适合处理评分向量因为评分向量天然是数字可以把用户或物品看作向量计算向量夹角。皮尔逊相关系数在评分标准化后有优势能降低用户打分习惯差异的影响——但家居选购的评分大多是我自己量化的行为得分不存在“某个用户习惯打高分”的问题所以皮尔逊的优势体现不明显。Jaccard相似度只看有没有行为不看行为多少更适合二值化的场景。最终我主力用余弦相似度核心代码很少经常用的写法是用矩阵乘法实现。假设行为矩阵是user_items物品相似度矩阵可以这样算import numpy as np from scipy.sparse import csr_matrix def calc_item_similarity(user_item_matrix): # user_item_matrix: 用户-物品稀疏矩阵行是用户列是物品 user_item_csr csr_matrix(user_item_matrix) # 物品-物品同现矩阵矩阵转置乘以矩阵 item_sim user_item_csr.T user_item_csr # 计算每个物品被行为的用户数用于归一化 item_count np.array(user_item_csr.sum(axis0)).flatten() # 分母sqrt(N(i)) * sqrt(N(j)) denominator np.sqrt(item_count[:, None] item_count[None, :]) # 处理分母为0的情况 denominator[denominator 0] 1e-10 return item_sim.toarray() / denominator这里用稀疏矩阵转置乘自己一步得到同现矩阵再逐项除以几何平均做归一化就是标准的物品余弦相似度。跑上千件商品只需要秒级时间不管是离线预计算还是答辩现场演示效率都没压力。3.3 Top-N推荐生成与过滤策略相似度矩阵算完推荐生成就从矩阵运算变成了取数和排序的问题。对当前用户把他产生过行为的物品ID取出来遍历每个物品的相似商品列表累加得到候选物品的得分再排序取前N个。这个过程的伪代码思路是获取用户行为过的物品列表及其得分对每个行为物品取相似度矩阵中相似度最高的K个物品候选物品综合得分物品相似度 × 用户行为原始得分然后按物品汇总过滤掉用户已经购买过的商品避免推荐已购物品按综合得分排序取TopN作为推荐列表。这里有一个很关键的过滤已经产生过行为的物品必须挡在推荐结果之外否则系统会把你刚收藏过的沙发继续推给你演示效果非常尴尬。另一个细节是候选物品的得分要排除两个来源不同的物品对同一候选物品的简单叠加——统一在汇总阶段按用户ID加总否则重复计算会让结果发生偏斜。举个例子用户行为物品A得分5和物品B得分8A和B都相似于候选物品C相似度分别为0.5和0.2那么C的得分应该是5×0.58×0.24.1而不是分别算完再加总时出现浮点误差累积导致的异常值。4. 系统架构与代码工程结构4.1 整体架构与数据流整个系统我按经典的三层结构拆表现层、业务逻辑层、数据层。表现层是Web页面负责向用户展示推荐结果业务逻辑层管理用户操作和推荐调用数据层存商品、用户、行为、推荐快照。推荐引擎独立存在于业务逻辑层下面不跟具体业务耦合这样换数据集或换算法时不用动Web部分的代码。数据流向是这样的用户在前端浏览或点击商品前端把行为事件异步提交到后端接口后端把行为写入MySQL推荐引擎定时或按需从MySQL里拉取行为数据重新计算相似度矩阵生成推荐列表存回数据库用户打开首页时Web后端直接从推荐结果表中查出推荐商品拼接商品信息后返回前端展示。这个设计有一个好处答辩演示的时候即使网络不稳定推荐结果也不会丢——因为推荐结果已经缓存到数据库了画面上依然能正常展示不需要现场临时跑算法。4.2 数据库设计要点数据库表我设计了五张用户表、商品表、行为表、相似度结果表、推荐结果表。用户表用户ID、用户名、密码哈希、注册时间。商品表商品ID、标题、图片URL、分类、价格、风格标签、品牌。行为表行为ID、用户ID、商品ID、行为类型浏览/收藏/加购/下单、行为得分、时间戳。相似度结果表物品A、物品B、相似度值。这张表是核心离线算完直接写入查询TopK相似物品时一条SQL搞定。推荐结果表用户ID、推荐物品ID、推荐得分、排序位置、推荐类型猜你喜欢/相关搭配/相似用户。商品表里的风格标签对推荐有辅助作用——算法算相似度做主判断风格标签用于推荐后的二次排序。比如在相似度得分接近的情况下风格匹配的商品排前面。这个细节在实际测试中很有用因为物品相似度只考虑了行为共现而家居商品天然有风格属性辅助排序能让推荐结果更“像人挑的”。4.3 推荐引擎与Web端的衔接后端我用Flask写REST接口推荐引擎单独封装成一个Python类。初始化时加载相似度矩阵对外暴露三个方法recommend_for_user(user_id, top_n)、similar_items(item_id, top_n)、user_cf_recommend(user_id, top_n)。Web接口只管接收请求、调方法、返回JSON不关心算法内部怎么算。一个实操建议推荐引擎不要做成每次请求都实时计算相似度矩阵。哪怕Python矩阵运算很快连续多次请求时重复计算也是浪费而且在线计算会拖慢页面响应。我的做法是写了一个定时任务每5分钟增量拉取一次新行为数据重新计算相似度后更新数据库里的相似度结果表。Web接口只查表不碰矩阵。这个方案在答辩演示时特别稳页面秒开。5. 毕设附带的源码如何运行与二次开发5.1 环境准备与工程导入源码工程我会打包成一个完整目录包含后端Python代码、前端静态文件、SQL初始化脚本、预处理好的CSV数据和README说明文档。拿到后的第一步是准备环境依赖项我用requirements.txt管理核心依赖包括Flask、Flask-CORS、NumPy、Pandas、SciPy、PyMySQL、scikit-learn用于数据划分和评估指标计算。执行安装pip install -r requirements.txt然后是初始化数据库我提供了init.sql里面包含建表和预置商品数据。在MySQL里执行如下命令即可mysql -u root -p init.sql接下来启动推荐预计算脚本脚本会读取行为数据算相似度矩阵把推荐结果写入数据库python recompute.py最后启动Web服务python app.py浏览器访问http://127.0.0.1:5000用README里预置的测试账号登录就能看到首页的“猜你喜欢”推荐。整个流程做成了一键式操作保证不在项目调试上浪费答辩准备时间。5.2 数据集测试与效果观察代码库里附带了一份演示数据集60个用户、800多件家居商品、约5000条行为记录。数据不是纯随机生成的而是按照用户画像和行为规律构造所以跑完算法后你能看到比较明显的推荐效果。我建议拿到后先做三个直观验证。第一注册一个新账号不做任何操作首页推荐是默认的热门商品浏览收藏几件北欧风商品后刷新推荐结果会快速向北欧风偏移——这是基于物品的协同过滤在起作用。第二打开一个商品详情页看“相关搭配推荐”应该能看到和当前商品风格接近或常被一起购买的商品比如看沙发时推荐茶几、边几。第三找一个有较多历史行为的老账号对比首页推荐的Top5和普通热门榜单看差异有多大——推荐应该明显带个人偏好色彩。这三个验证都是在代码层面能真实跑通的如果测试时发现结果不理想优先排查行为表里是否有足够多的共现数据这是推荐效果的最大变量。5.3 二次开发替换成自己的家居数据很多同学拿到源码后第一件事是想换自己的数据集。替换方式并不复杂关键是格式要对。商品表里每行要包含商品ID唯一、标题、图片URL、分类、价格、风格标签。风格标签这里强烈建议认真填写一个商品可以有多标签比如“现代简约、原木、北欧”因为辅助排序阶段会用到。行为表里需要的是用户ID、商品ID、行为类型、时间戳。行为类型可以是任何你自定义的字符串但要在配置文件里把行为类型到行为得分的映射关系同步修改不然浏览、收藏、加购、下单的权重还是默认值。我遇到过有人直接把自己爬的数据导进去但用户ID对不上行为记录里有大量“同一个用户反复操作同一商品”的记录导致相似度矩阵出现严重的偏差。处理方法是导入前对行为数据做去重和清洗同一用户同一商品只保留一次最高行为类型避免重复数据干扰共现计算。6. 踩坑记录与优化方向6.1 冷启动问题的触底与缓解冷启动是这个项目里我踩得最深的一个坑。新用户没有任何历史行为协同过滤矩阵里他对应的向量全是0算相似度时Cosine会得到一个无效值分母为0推荐结果直接变成空列表。第一版我直接用了一个笨办法新用户返回热门商品Top10。后来发现这个策略过于粗糙改进版是这样处理的当用户产生至少1条行为后先用ItemCF针对这个行为商品找到相似商品立刻就能给出个性化推荐只有完全没有行为的用户才返回热门榜。这个改进只用了很少的代码量但推荐从“完全无用”变成了“跟用户行为直接相关”效果提升非常明显。6.2 评分稀疏导致相似度失真家居选购的低频特性导致行为矩阵稀疏度极高我的演示数据里矩阵稀疏度超过95%。在稀疏矩阵下物品相似度的分母两个集合交叉很小会出现“只被同一个人买过的两件家具相似度1”的假象因为分子是1分母也是1。解决办法是加频率惩罚推荐结果里对共现用户数小于阈值的相似物品对做降权或过滤。我在代码里给相似度结果加上一个字段common_count只有共同行为用户数不低于3的相似关系才参与推荐候选。这个阈值可以根据数据量调整数据量大的时候可以考虑提高到5。这个细节在论文里也值得写一笔——它是展示你对算法有过深入思考的重要证据。6.3 推荐结果的多样性不足做实验时发现纯用ItemCF会出现“推荐结果过于集中在某个风格”的问题。一个用户浏览了一件北欧风沙发后首页推荐全是北欧风的家具椅子、桌子、灯具无一例外。这在真实使用体验中不好——用户确实偏好北欧风但也不代表完全不想看其他风格。我的改进方案是引入多样性重排从推荐候选中取Top50然后按风格分类保证最终Top10里最多3件同风格商品其余的风格尽量错开。重排的条件是推荐得分和风格多样性之间的权衡我用了简单贪心策略先取得分最高的商品后续商品在保持同一风格不超过3件的前提下优先取得分次高的。这个策略在代码上只有十几行但推荐结果的可接受度提高了非常多。6.4 在线与离线推荐的取舍最后说一个关于系统设计层面的问题。很多推荐系统课程会强调实时性但家居选购这个场景真的不需要实时推荐。用户一天内产生的新行为量很小而且决策周期长30分钟级别乃至小时级别的更新频率完全足够。项目里我做的是离线计算、在线查询的架构定期把相似度计算和推荐结果生成完缓存到数据库。这样的好处是系统在线部分极其简单稳定性高并发请求几乎没有压力代价是实时性差但在这个场景下这个代价可以接受。如果你后续想加实时性升级路线也很清晰加上一层Redis缓存行为产生时增量更新物品相似度再配合消息队列异步计算就能把更新延迟降到秒级。整个项目从选题、到算法实现、再到系统开发和数据构造完整走下来我的体会是推荐系统项目最容易出彩的地方不一定是最复杂的模型而是你对场景特点的理解和针对性的处理。毕设代码本身不复杂复杂的是让推荐结果在一个具体场景里真正“像个懂行的导购”这些经验在数据分析和推荐相关的岗位上都是实打实的加分项。

基于协同过滤算法的家居选购系统设计与实现

相关推荐

企业级AI中台搭建实战：基于坤擎智能体的架构设计与容错控制

增长停滞诊断框架：5步定位用户流失与激活问题

纯Servlet+JDBC实现图书销售系统事务控制

更多资讯

JSP+MySQL体育赛事管理系统毕设实战指南

ZYNQ+Vitis初学者入门指南：板卡选型与软硬件协同开发全流程

RK3588交叉编译实战：嵌入式AI部署的系统级建模

C++编译器扩展与兼容性：GCC、Clang与MSVC的方言世界

整数拆分问题全解：动态规划、数学优化与三语言实现

HuggingFace英译中模型迁移ONNX：CPU推理加速与INT8量化实战

今日更新

PHP htmlentities()函数用法讲解

AI Agent工程实战：从七要素到七个决策点的系统设计指南

AI入局芯片设计验证：验证收敛50倍加速的真相与应对

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？