基于Python的得物鞋类数据分析可视化与推荐系统

每年到了毕业季,总有一堆学弟学妹跑来找我看计算机毕业设计的题目,其中被问得最多的就是“电商类推荐系统怎么做”。说实话,这种题目网上一抓一大把,但真正能落地、能答辩、能演示出效果的项目反而不多。今天分享的这套——基于Python的得物鞋类数据分析可视化与推荐系统,是我觉得性价比很高的一版方案。它不光是跑通一个Django网站那么简单,而是把数据分析、可视化、协同过滤、大模型Agent这些热点全串了起来,既有技术深度又有演示效果,答辩的时候也有的聊。

这套系统面向的是一类很典型的毕设需求:数据量不能太小、功能要可视化、算法要能讲出原理、最好再蹭一点“大模型”的热度。关键词里带“得物鞋类”的好处是场景垂直,数据语义清晰——用户对鞋的品牌、价格、风格、尺码偏好都非常明确,做出来的推荐结果容易解释,不像泛电商那样特征太散。如果你是计算机相关专业、想选一个“数据分析+推荐系统”方向的题目,或者手里已经拿到类似题目但不知道从哪下手,这篇文章基本可以当一份实施手册来用。

我只能基于标题和常见项目实践来拆解整条技术链路,默认的技术栈是Python 3.8+、Django 3.2/4.0、Pandas、Pyecharts以及Surprise或自写的协同过滤算法。下面从设计思路开始,一步步带你把这个项目从零到一搭出来。

1. 项目整体设计与思路拆解

1.1 这个毕设到底做了什么

一句话概括:采集或构造得物平台上鞋类商品的数据,完成数据清洗和特征工程,然后用Django搭建一个Web应用,把数据可视化看板、商品列表、用户推荐模块整合在一起,核心推荐能力由协同过滤算法提供,再叠加一点大模型Agent的智能化交互。

从业务视角看,它模拟的是一个垂直电商的推荐后台。用户登录后,系统能根据其历史行为(浏览、收藏、加购、评分)推荐可能喜欢的球鞋;管理员或普通用户打开数据看板,能看到价格分布、品牌销量占比、热门鞋款排行、用户活跃时段等图表;如果再加入大模型对话入口,用户可以直接用自然语言问“给我推荐一双一千块以内的实战篮球鞋”,系统返回结构化推荐结果。这一套下来,数据、算法、Web开发、交互设计四个层面全都有了,覆盖面非常广。

我见过很多毕设只做一个简单CRUD,或者只跑一个离线算法脚本,答辩时老师一问“系统在哪里”就露馅了。这个项目的精髓在于:算法离线算好、效果在线展示,数据和模型都有可视化出口,每个环节都能截图放进论文,这也是它适合当毕设的核心原因。

1.2 技术选型:为什么是Django而不是Flask

技术栈第一坑就是框架选择。很多同学觉得Flask轻量、上手快,但真正做毕设我强烈建议Django,原因有三个:

第一个原因是Django自带Admin后台。得物鞋类商品需要管理品牌、分类、商品信息、用户行为记录,如果全手写一套管理界面,工作量至少多出两周。Django的Admin只需要注册模型就能得到增删改查页面,导师看到后台管理面板也会觉得系统完整。

第二个原因是Django的ORM对复杂查询非常友好。推荐系统需要反复join用户表、商品表、评分表,比如统计“某个品牌下用户评分最高的Top10鞋款”,这种查询用Django ORM写起来清晰,而且切到MySQL或PostgreSQL时不用改代码。Flask要用SQLAlchemy也不是不行,但整体模板、表单、认证都要自己拼,Django全家桶确实省心。

第三个原因是答辩演示的稳定性。用Django启动一个项目,

python manage.py runserver

就能在局域网内跑起来,笔记本连上手机热点,老师用手机扫码也能打开演示页面。Flask虽然也可以,但Django在静态文件处理、CSRF、Session管理上是默认配置好的,现场出Bug的概率更低。

当然,如果你的题目明确要求“前后端分离”,那就用Django REST Framework写API,配合Vue3或Uniapp客户端,这也是现在很流行的组合。本文仍然以传统Django模板渲染为主,因为毕设团队里只有一个人的情况,后端渲染能少写很多接口代码。

1.3 功能模块划分

根据标题里的关键词,我建议把系统拆成六个模块:

• 用户模块:登录、注册、个人信息、行为记录(浏览、收藏、评分)。
• 商品模块:鞋类商品信息管理,包括品牌、型号、价格、发售日期、图片、分类。
• 数据管理模块:导入鞋类数据集、增量更新、数据清洗接口。
• 推荐模块:协同过滤算法离线计算,给每个用户生成TopN推荐列表。
• 数据分析与可视化模块:价格分布、品牌销量、用户画像、时间趋势等图表看板。
• 大模型Agent模块:接收自然语言查询,解析意图,调用推荐结果返回给用户。

这些模块不是拍脑袋定的,而是对应评分表里的得分点。功能模块越清晰,论文目录越好写,答辩时讲“系统由六大模块组成”也比“我写了一个网站”要专业得多。

2. 数据获取与预处理:推荐系统的基础

2.1 得物鞋类数据从哪来

数据是所有推荐算法和可视化的根基。得物平台本身没有开放公开API,所以毕设项目的数据来源通常有两种方式:第一种是使用公开数据集,比如Kaggle上的电商用户行为数据集、淘宝用户购物数据集,只需要把字段映射成“鞋类”语义即可;第二种是自行编写爬虫,获取得物商品页的公开信息。

我个人的建议是:优先使用公开数据集,把精力放在算法和系统上。因为得物的反爬措施较严,而且用爬虫采集到的数据如果涉及个人敏感信息,在论文里不好交代。公开数据集可以选择用户行为日志CSV,字段包括

user_id,item_id,behavior_type,price,brand,category,timestamp

。如果数据集不是鞋类的,可以按商品标题或分类字段筛选出包含“篮球鞋”“跑步鞋”“板鞋”“运动鞋”等关键词的商品,构成一个鞋类子集。

另外,要生成“像得物”的商品数据,可以写一个简单的数据合成脚本:预设球鞋品牌(如Nike、Adidas、李宁、安踏、New Balance),每个品牌下生成若干型号,价格按品牌定位加上随机浮动,销量和评分按正态分布采样。这样既绕开了敏感问题,又能模拟出真实电商数据的分布特征,对算法验证完全够用。

2.2 数据清洗的坑

数据拿到手,第一个要处理的就是缺值和异常值。拿典型的CSV行为数据来说,最容易出现的坑有三个:

• user_id

  或

  item_id

  为空:这类记录直接删除,因为推荐算法依赖交互关系。

• 价格字段类型混乱:数据里可能有“1299元”“1299.00”“1,299”等多种格式,统一用正则提取数字再转float。
• 重复交互记录:同一用户短时间内多次浏览同一商品,这算一次行为还是多次?我的经验是,浏览行为按天去重,收藏、加购、评分行为不去重,因为它们有明确的操作含义。

处理缺失值时,分类字段(品牌、鞋类)用众数填充,数值字段(价格、销量)用中位数填充,不要用均值。因为价格数据往往右偏,少数高价限量款会把均值拉高,用中位数更稳健。清洗完的数据最好输出一份

data_clean.csv

,后续数据分析、模型训练、论文实验部分都要反复用到这份数据,保留中间产物的习惯非常值得培养。

2.3 特征工程:如何把“鞋”变成向量

协同过滤算法本身不直接需要商品特征,但如果你加入了大模型Agent或者想要给冷启动用户做推荐,特征工程就很重要了。这里用到的是比较常规的三类特征:

• 数值特征:价格、发售年份、销量、收藏数、评分均值,直接做MinMax归一化。
• 类别特征:品牌、鞋类分类(篮球鞋/跑步鞋/休闲鞋/板鞋)、颜色,做One-Hot编码或者更省空间的Label Encoding。
• 文本特征:商品标题和描述文本,用Jieba分词后获得词向量。可以用TF-IDF,也可以直接用预训练的Sentence-BERT做Embedding。不过考虑到毕设环境不一定有GPU,推荐用TF-IDF加上一个简单的词向量平均,效果足够支撑论文内容。

把这些特征拼接成一个商品向量,有三个用途:一是给基于物品的协同过滤计算相似度时做辅助;二是给冷启动用户做“按属性匹配”的初始推荐;三是用来给大模型Agent提供结构化的“商品知识”。所以特征工程这一层做得是否规范,直接决定了后面模块能不能顺利衔接。

3. 协同过滤推荐算法:从公式到落地

3.1 基于用户的协同过滤 vs 基于物品的协同过滤

协同过滤在毕设里是核心考点,答辩时老师最喜欢问的就是“两种协同过滤分别适合什么场景”。这里必须讲清楚。

基于用户的协同过滤(UserCF)的思路是:找到和你历史喜好相似的其他用户,把那些用户喜欢的商品推荐给你。它的优势是能发掘潜在兴趣,适合用户量相对少、UEBA行为日志丰富的场景。缺点是用户数量大时,用户相似度矩阵的规模会膨胀,而且新用户没有历史行为就完全失效。

基于物品的协同过滤(ItemCF)的思路是:计算商品之间的相似度,推荐与你历史喜欢的物品相似的物品。这是电商平台用得最多的,因为商品数量相对稳定,相似度矩阵可以离线定期更新,实时计算的压力小。得物鞋类这种场景非常契合ItemCF——你收藏了一双AJ1,系统给你推AJ1的其他配色或其他Air Jordan系列,解释性非常好。

我的建议是主推ItemCF,同时把UserCF作为一个对照实验写进论文。这样既能展示你对两种算法的理解,又能通过实验说明为什么ItemCF更适合鞋类电商。

3.2 相似度计算实战

鞋类商品相似度的计算,常见的有余弦相似度、皮尔逊相关系数、Jaccard相似度。在ItemCF里,最常用的是余弦相似度。

假如商品A被用户集合U_A评分或购买过,商品B被用户集合U_B交互过,那A和B的相似度可以这样算:

similarity(A, B) = |U_A ∩ U_B| / sqrt(|U_A| * |U_B|)

这个公式其实是在算“同时跟A和B发生过交互的用户占的比例”,比值越大,说明这两个商品在用户眼里越可替换,相似度越高。用Python实现的时候,不必用pandas的

corr()

硬算,因为稀疏矩阵下很多计算是浪费的。更工程化的做法是用

scikit-learn

的

cosine_similarity

或者自建一个稀疏矩阵。

我实际写的时候,是先把交互数据转成

user-item

稀疏矩阵,然后用

csr_matrix

存储,再一次性算商品相似度矩阵。数据集规模在几千个用户、几千个商品时,这个计算量在普通笔记本上几秒钟就跑完了,完全不用上升到大数据框架。

3.3 冷启动问题怎么解决

协同过滤最大的软肋是冷启动,这也是毕业论文里“创新性”最集中的切入点。新用户没有行为数据,怎么给他推荐?我的做法是三层兜底策略:

第一层:如果用户没有任何行为,用“热门商品推荐”。统计最近30天销量最高的20款鞋,直接展示。这叫流行度推荐,简单有效。

第二层:如果用户有少量行为(比如只浏览过一双鞋),根据行为记录的物品类别和品牌,做属性匹配推荐。比如看的是“李宁-篮球鞋”,就推荐同类目下价格接近的鞋。

第三层:用户行为数据足够多以后,才用协同过滤计算个性化推荐。

这三层策略写进论文,就是一套完整的分级推荐逻辑。答辩时老师一定会问“冷启动怎么处理”,你可以非常自信地给出这三个层级。很多毕设只写了协同过滤一个算法,冷启动这里一问就卡壳,你能答上来就是加分项。

4. 数据可视化:让答辩PPT自己会说话

4.1 技术选型:Pyecharts还是ECharts

可视化模块是视觉冲击力最强的部分,也是导师第一眼就看的地方。技术选型上有两条路:后端用Pyecharts生成图表,或者前端直接用ECharts。

我的偏好是Pyecharts,原因很简单:可以直接在Python里通过DataFrame统计数据,然后调用

add_js_funcs

或

render_embed()

生成HTML片段,嵌入Django模板即可。整个过程不需要写一行JavaScript,非常适合不熟悉前端的同学。

ECharts的优势是交互性更强、图表更炫,但需要自己写JS回调、维护前端依赖。如果时间充足、前端基础也不错,可以在后期把几个核心图表换成ECharts版本。我建议初期统一用Pyecharts,保证系统能在三天内跑通,后期再考虑视觉升级。

4.2 可视化看板怎么设计

看板不是图表越多越好,而是每张图都要对应一个分析结论。以得物鞋类数据为例,我给出六个高频图表,后文会一一实现:

• 价格分布直方图:看主流价位区间,一眼看出球鞋定价重心在500到1200元。
• 品牌销量Top10条形图:看品牌集中度,Nike、Adidas是不是垄断级存在。
• 鞋类分类占比饼图:篮球鞋、跑步鞋、板鞋各占多少,用于分析品类结构。
• 用户购买时间热力图:看用户活跃时段,比如晚上8到10点是高峰,对应“得物”这类潮流电商的真实用户习惯。
• 价格与销量散点图:验证“价格越高销量越低”还是“高价限量款反而抢手”。
• 用户评分分布图:看整体满意度,判断平台商品口碑。

每个图表下方配一段文字结论,比如“价格集中在500~1000元区间,超过2000元的高价鞋销量明显下滑,说明主流消费者对价格敏感”。这些结论不仅能演示,还能直接复制进论文的“数据分析”章节。

4.3 Django怎么和前端图表对接

Pyecharts生成的图表本质是一个HTML片段。在Django里的做法是:在视图函数中准备好统计数据,生成图表实例,然后通过模板上下文传到前端。

一个典型的视图逻辑:

from pyecharts.options.global_options import InitOpts
from pyecharts import options as opts
from pyecharts.charts import Bar

def brand_sales_view(request):
# 从数据库读取品牌销量数据
brand_qs = (Product.objects
.values('brand')
.annotate(total_sales=Sum('sales'))
.order_by('-total_sales')[:10])
brands = [item['brand'] for item in brand_qs]
sales = [item['total_sales'] for item in brand_qs]

bar = (
Bar(init_opts=InitOpts(width="800px", height="400px"))
.add_xaxis(brands)
.add_yaxis("销量", sales)
.set_global_opts(title_opts=opts.TitleOpts(title="品牌销量Top10"))
)
chart_html = bar.render_embed()
return render(request, 'analysis/dashboard.html', {'chart_html': chart_html})

模板中直接用

{{ chart_html|safe }}

渲染即可。要注意的是,

render_embed()

默认会引入Pyecharts的JS依赖,如果离线环境没有CDN,需要把Pyecharts的静态资源下载到本地

static

目录,并修改模板里的script引用。这个问题在答辩现场很常见,提前处理好离线资源能避免当场翻车。

5. 大模型与Agent:毕设的加分项

5.1 大模型在推荐系统里能干什么

标题里出现了“大模型”和“agent”,这是当前毕设的热点词。但很多同学对大模型在推荐里的定位非常模糊,要么只挂一个API聊天窗口,要么声称用了大模型却没有任何实际改动。我的理解是,大模型在推荐系统里至少有三个落点:

第一个落点是理解用户自然语言查询。比如用户输入“推荐适合学生党的性价比跑鞋”,传统协同过滤完全无法处理,因为无法解析这个query。用大模型做意图识别和关键词抽取,可以得到“价格<800、品类=跑鞋、适用人群=学生”的结构化条件,再把这些条件放到推荐模块里做筛选,这就是一个完整的推荐链路。

第二个落点是生成推荐理由。协同过滤算出“推给你Nike Air Force 1”,但如果是普通列表页,用户不知道为什么被推荐。借用大模型的文本生成能力,针对每个推荐商品生成一句个性化理由——“因为你收藏过Air Jordan系列,而这双空军一号在同类休闲板鞋里评价最高”。

第三个落点是构建商品知识问答。用户问“AJ1和Dunk有什么区别”,系统把商品描述文本交给大模型,生成答案。这更像是商品百科,但对答辩来说非常出彩,因为它能直观地展示大模型的“推理+记忆”能力。

5.2 Agent设计思路

Agent本质上是一个“会调用工具的对话系统”。在这个毕设里,我不建议你从零搭建Agent框架,而是用最朴素的方式实现一个“意图-行为”路由:

def agent_handle(user_message):
# 第一步:意图识别（可调用大模型API或者本地规则）
intent = detect_intent(user_message) # recommend / query / chat

if intent == "recommend":
conditions = extract_conditions(user_message)
products = recommend_by_conditions(conditions)
explain = generate_explanation(products, user_message)
return build_response(products, explain)
elif intent == "query":
answer = knowledge_qa(user_message)
return answer
else:
return default_chat(user_message)

这里有一个关键点:意图识别不一定要调用大模型。用正则加关键词字典就能识别大部分推荐请求,比如出现“推荐”“给我推”“想买”“有没有”就是推荐意图,出现“区别”“是什么”“怎么样”就是问答意图。先用规则兜底,解释不通再调用大模型,这样系统在离线演示环境也能稳定运行,不会被API的不稳定性连累。

如果你真要接入大模型API,建议用OpenAI兼容的接口协议,很多国产模型也都支持同样的格式,方便随时切换。把API Key放到配置文件,不要在代码里硬编码,免得答辩时翻到源码尴尬。

5.3 离线模型接口与在线API的取舍

大模型这部分,我特别想提醒一点:不要让你的整个系统强依赖外部大模型API。因为答辩现场网络环境往往很差,API超时或失败会让演示变成事故。

我的做法是做一个“降级开关”:优先走本地规则和协同过滤,大模型只是一个增强层。配置文件里加一个

USE_LLM = True / False

开关,如果现场网络状态良好就开启对话增强,网络不稳定就关闭,让系统回归纯规则版。这样既能在论文里写明“系统集成大模型Agent”,又能保证现场演示万无一失。

6. 核心代码实现与实操过程

6.1 项目目录结构

一个规范的Django项目结构应该是这样的:

shoes_recommend/
├── manage.py
├── requirements.txt
├── config/ # 项目配置
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
├── apps/
│ ├── users/ # 用户模块
│ ├── products/ # 商品模块
│ ├── behavior/ # 行为记录模块
│ ├── recommendation/ # 推荐算法模块
│ ├── analysis/ # 数据分析与可视化
│ └── agent/ # 大模型Agent模块
├── static/ # 静态资源
├── templates/
│ ├── base.html
│ ├── index.html
│ ├── dashboard.html
│ └── recommend.html
└── data/
├── raw_data.csv
├── clean_data.csv
└── model/
└── item_sim_matrix.npy

`

我自己习惯把应用按业务拆分成独立的app,而不是全部塞进一个

app

里。这样做的直接好处是,每次迁移数据库、写测试、排查Bug时定位非常快。你想象一下,如果users、products、recommendation的所有model都写在同一个models.py里,文件几百行往上走,改一个字段都要Ctrl+F半天,心态很容易崩。

6.2 推荐算法核心代码解析

协同过滤这块,我建议用Pandas自己写,不要一上来就上Surprise库。自己写能让你对公式了如指掌,答辩时讲原理更有底气。一个基于物品的协同过滤核心代码参考如下:

import pandas as pd
import numpy as np

def build_item_similarity(interactions: pd.DataFrame):
"""
interactions: [user_id, item_id, rating]
"""
# 构造稀疏矩阵的雏形
user_item = interactions.pivot_table(
index='user_id',
columns='item_id',
values='rating',
fill_value=0
)
# 目标：计算 item-item 余弦相似度
# 先对列做归一化，然后用矩阵乘法计算相似度
item_matrix = user_item.values.T # shape: [item_count, user_count]

# 计算余弦相似度: A dot B.T / (||A|| * ||B||)
norm = np.linalg.norm(item_matrix, axis=1, keepdims=True)
norm[norm == 0] = 1e-6 # 防止除零
normalized = item_matrix / norm

sim_matrix = np.dot(normalized, normalized.T)
# sim_matrix[i][j] 表示 item_i 与 item_j 的相似度

item_ids = user_item.columns.tolist()
sim_df = pd.DataFrame(sim_matrix, index=item_ids, columns=item_ids)
return sim_df

def recommend_by_item_cf(sim_df: pd.DataFrame,
user_hist: dict,
top_n: int = 10):
"""
user_hist: {item_id: rating}
"""
scores = {}
for item_id, rating in user_hist.items():
if item_id not in sim_df.index:
continue
sim_scores = sim_df[item_id]
for candidate, sim in sim_scores.items():
if candidate in user_hist:
continue
scores[candidate] = scores.get(candidate, 0) + sim * rating
# 按权重总分排序
ranked = sorted(scores.items(), key=lambda x: x[1], reverse=True)
return [item_id for item_id, score in ranked[:top_n]]

这里有一个我在实战中总结的小技巧:计算相似度时,建议先过滤掉交互量极少的商品(比如只有1到2个用户购买),否则这些“冷门商品”会因为共现次数少而产生虚假的相似度配对,推荐结果会很飘。一般保留交互次数大于等于5的商品再建矩阵,效果会稳定很多。

6.3 数据可视化接口实现

可视化这块,除了前面已经给出品牌Top10条形图,我再补一个热力图的实现示例,用Pyecharts自带的

HeatMap

:

import random
from pyecharts import options as opts
from pyecharts.charts import HeatMap

def get_user_activity_heatmap():
# 横轴：小时（0-23），纵轴：星期一到星期日
data = []
for day in range(7):
for hour in range(24):
count = random.randint(20, 500) # 实际上应从数据库聚合
data.append([hour, day, count])

heatmap = (
HeatMap()
.add_xaxis([str(i) for i in range(24)])
.add_yaxis(
"活跃度",
["周一", "周二", "周三", "周四", "周五", "周六", "周日"],
data,
label_opts=opts.LabelOpts(is_show=False),
)
.set_global_opts(
title_opts=opts.TitleOpts(title="用户活跃时段热力图"),
visualmap_opts=opts.VisualMapOpts(max_=500),
)
)
return heatmap.render_embed()

实际项目里不要用

random

,应该用

BehaviorRecord

表里按

hour

和

weekday

分组统计真实次数。用peewee或Django ORM:

from django.db.models.functions import ExtractHour, ExtractWeekDay
result = (BehaviorRecord.objects
.annotate(hour=ExtractHour('create_time'),
weekday=ExtractWeekDay('create_time'))
.values('hour', 'weekday')
.annotate(count=Count('id')))

热力图在答辩演示时视觉效果非常好,用颜色深浅直观展示“晚上才是逛鞋的高峰期”,一下就能抓住老师的注意力。

7. 常见问题与排查技巧实录

7.1 必踩的坑

这些问题是我在调试类似项目时真实遇到过的,整理成速查表,你碰到的时候直接对照排查。

原因

解决方法

另外一个很容易翻车的点:不要在Windows下用

python manage.py runserver

直接读取大型CSV。Django开发服务器是单进程的,如果数据加载逻辑写在视图里,每次打开页面都要重新读一遍大文件,页面会卡到怀疑人生。正确做法是把数据清洗和相似度计算做成离线脚本,服务启动时只加载

item_sim_matrix.npy

这种已经算好的矩阵文件,内存占用和响应时间都能接受。

7.2 性能优化建议

毕设虽然不需要高并发,但演示流畅度直接关系到老师的主观印象。我自己常用的性能三板斧,你可以直接抄:

一是离线预计算。协同过滤的相似度矩阵、聚合统计指标,全部放到

views.py

之外的脚本中定时或手动触发。线上只做查询,不做计算。

二是给数据库加索引。对

BehaviorRecord

表的

user_id

、

item_id

、

create_time

添加联合索引,这样查询一个用户的历史记录从全表扫描变成索引扫描,速度能差十倍以上。

三是缓存常用结果。Django自带的

cache

框架配合LocMemCache就能用,把品牌Top10、首页热门推荐这些低频变化的接口缓存5到10分钟,页面加载速度肉眼可见地提升。

7.3 答辩前必须准备的两个演示预案

第一个预案是数据集演示。提前准备好一份1万条以上的行为数据,在答辩时现场跑一次清洗和相似度计算脚本,然后展示结果。这能让老师相信你的算法不是写死的,而是真的能处理数据。

第二个预案是断网演示。提前把Pyecharts的JS库下载到本地,Agent开关关闭,让整个系统在完全断网的环境下也能正常浏览和推荐。我见过太多人因为现场WiFi连不上而手足无措,这种细节准备到位,就已经赢了一半。

最后分享一点我的个人体会

做毕设,最怕的不是技术难,而是方向散。今天这套系统的好处在于,每个模块都有清晰交付物:数据清洗有干净数据集,算法有推荐列表,可视化有图表看板,大模型Agent有对话界面,甚至还可以加一个后台导出用户行为报表的功能。你在写论文的时候,每一章都能对应到实际代码和运行截图,不会出现凑字数的情况。

有时间的话,可以再给系统加一个“相似鞋款对比”功能:用户看到一双鞋,点击“找相似”,系统同时展示协同过滤结果和特征相似度结果,两个结果可以对比展示。这样一来,“传统推荐算法”和“特征向量检索”两个方法的优劣就能用实验数据说明,论文的创新点又多了一个。希望这篇文章能让你少走一些弯路,按这个架构一步步把系统搭起来,毕业答辩的时候,你就能底气很足地说:这个系统里的每一张图、每一个推荐结果,都是我亲手算出来的。