其中j是用户u已评分的物品。ItemCF的优点是物品相似度矩阵相对稳定，可以预先计算存储；缺点是对于新物品的冷启动问题较为突出。

1. 1. 神经协同过滤原理

神经协同过滤（NCF）是由He等学者在2017年提出的深度学习推荐框架，旨在用神经网络替代传统协同过滤中的内积操作，学习用户与物品之间的复杂交互关系。

NCF框架的核心思想是将协同过滤问题转化为二分类问题或回归问题。框架包含两个分支：GMF（Generalized Matrix Factorization）分支和MLP（Multi-Layer Perceptron）分支。GMF分支保留了矩阵分解的线性特性，用户嵌入向量和物品嵌入向量进行元素积运算；MLP分支通过多层感知机学习用户和物品之间的非线性关系，两个嵌入向量进行拼接后输入全连接网络。

两个分支的输出在最后一层进行拼接，通过输出层得到最终预测。这种混合架构使得模型既能捕捉线性关系，也能学习非线性模式，在推荐精度上优于单一模型。

NCF框架的另一个优势是端到端训练，嵌入向量和网络参数可以联合优化，无需预训练步骤。训练目标可以采用均方误差（回归任务）或交叉熵损失（分类任务）。

1. 1. 本章小结

本章介绍了系统开发所涉及的核心技术和推荐算法的理论基础。Flask框架提供了灵活高效的Web开发能力；SQLAlchemy简化了数据库操作；PyTorch为深度学习模型实现提供了强大支持。在算法层面，UserCF和ItemCF是成熟的协同过滤方法，NCF框架则代表了深度学习在推荐领域的应用趋势。这些技术和方法为后续系统设计与实现奠定了理论基础。

1. 系统需求分析
   1. 可行性分析
      1. 经济可行性分析

运动组队推荐系统的开发成本主要包括人力成本、硬件成本和软件成本三个方面。人力成本方面，本项目由个人独立完成开发工作，无需额外人员开支。硬件成本方面，开发阶段使用普通个人计算机即可满足需求，生产环境可选择云服务器部署，按需付费模式可将硬件成本控制在较低水平。软件成本方面，系统所采用的Python、Flask、PyTorch、SQLite等技术均为开源软件，无需支付许可费用。

系统运行后能够产生多方面的效益。对于用户而言，节省了寻找队友的时间成本，提升了运动社交效率；对于平台运营者而言，可通过增值服务实现商业化，如高级会员、广告推送等。根据类似平台的运营数据，一个功能完善的运动社交平台在达到一定用户规模后，具备良好的盈利潜力。综合开发成本与预期收益分析，系统从经济上是可行的。

1. 1. 1. 技术可行性分析

本系统采用的技术栈均为成熟稳定的主流技术。Python语言在数据处理和机器学习领域应用广泛，社区生态完善；Flask框架轻量灵活，适合中小型Web应用开发；PyTorch是当前最流行的深度学习框架之一，提供了丰富的神经网络组件和训练工具；SQLite作为嵌入式数据库，无需独立服务器，部署简单且性能足够支撑中小规模应用。

从开发难度来看，系统涉及的Web开发、数据库操作、推荐算法实现等技术均有大量参考资料和开源项目可供借鉴。NCF模型虽然结构相对复杂，但PyTorch提供了清晰的API接口，实现难度可控。开发过程中可能遇到的技术难点，如模型训练调优、推荐实时性等，都可以通过合理的架构设计和技术方案解决。综上所述，系统从技术上是可行的。

1. 1. 1. 操作可行性分析

系统面向两类用户：普通用户和管理员。对于普通用户，系统界面设计遵循简洁直观原则，核心功能如运动浏览、组队推荐、队伍管理都可通过简单的点击操作完成，学习成本低。用户只需具备基本的互联网应用操作能力即可顺畅使用系统。

对于管理员，后台管理界面采用统一的设计风格，功能模块划分清晰。用户管理、队伍审核、数据统计等操作都有明确的操作指引和反馈提示。系统同时提供了详细的操作日志记录，便于管理员追踪和排查问题。综合评估，系统前端和后台操作难度适中，符合用户使用习惯。综上所述，系统从操作上是可行的。

1. 1. 需求分析
      1. 业务流程分析

运动组队推荐系统以运动爱好者为核心服务对象，围绕组队匹配这一核心业务展开。系统的主要业务流程可分为运动浏览、智能推荐、组队管理和评价反馈四个模块。

运动浏览业务流程描述如下：用户进入系统后，首先查看运动项目库，可按类别筛选或搜索感兴趣的运动项目，选择某项运动后查看详细信息，包括运动介绍、难度等级、参与人数要求等。用户可将感兴趣的运动添加至个人偏好列表，系统据此更新用户的运动画像。该流程为后续推荐提供基础数据支撑。

图3-1 运动浏览业务流程图

智能推荐业务流程描述如下：当用户发起组队请求时，系统首先调用推荐引擎分析用户的运动偏好、技能水平和历史行为数据，计算与其他用户的匹配度。推荐引擎综合运用UserCF、ItemCF和NCF三种算法，得到加权融合后的推荐结果。用户查看推荐的潜在队友列表，包括匹配度评分和共同运动项目，选择合适的用户发送组队邀请。该流程是系统的核心业务环节。

图3-2 运动推荐业务流程图

组队管理业务流程描述如下：用户创建队伍时填写运动项目、活动时间、人数限制等信息，队伍创建成功后状态设为"招募中"。其他用户可浏览招募中的队伍并申请加入，队长审核申请后决定是否接受。队伍成员达到上限或活动时间临近时，队伍状态变更为"已关闭"。活动结束后，队长将队伍标记为"已完成"，此时可进行队员评价。该流程贯穿组队活动的全生命周期。

图3-3 组队管理流程图

评价反馈业务流程描述如下：活动结束后，参与用户可对队友进行评价，评价内容包括评分（1-5分）和文字评语。评价数据存储后，系统更新被评价用户的信用评分，同时将评价行为纳入推荐算法的数据来源，优化后续推荐效果。该流程形成用户行为的正向反馈循环。

图3-4 评价反馈业务流程图

1. 1. 1. 功能需求分析

根据业务流程分析和用户角色划分，系统功能需求分为普通用户功能和管理员功能两类。

普通用户功能包括：

（1）运动项目浏览功能：用户可查看系统中的所有运动项目，支持按类别（球类、跑步、健身等）筛选，支持关键词搜索。每个运动项目展示名称、类别、难度、人数要求等基本信息。

（2）智能队友推荐功能：系统根据用户的运动偏好和历史行为，智能推荐匹配度较高的潜在队友。推荐结果展示匹配度评分、共同运动项目等信息，用户可选择查看详细信息或发起组队邀请。

（3）组队管理功能：用户可创建新队伍，设置运动项目、活动时间、人数限制等参数；可查看自己创建的队伍和已加入的队伍；作为队长可审核加入申请，移除队员；作为队员可退出队伍。

（4）队友评价功能：活动结束后，用户可对参与同一队伍的队友进行评价，评价包括1-5分的评分和可选的文字评语。用户也可查看他人对自己的评价记录。

（5）个人中心功能：用户可查看和修改个人信息，包括技能等级、偏好运动等；可查看参与运动的历史记录；可查看收到的评价统计。

图3-5 用户用例图

管理员功能包括：

（1）用户管理功能：管理员可查看系统中所有用户列表，支持按条件筛选；可编辑用户信息，包括技能等级调整、账户状态变更；可删除违规用户。

（2）运动项目管理功能：管理员可添加新的运动项目，编辑现有项目信息，删除不再提供的运动项目。

（3）队伍管理功能：管理员可查看所有队伍信息，对违规队伍进行关闭处理，查看队伍成员构成。

（4）数据可视化功能：管理员可查看系统运营数据统计，包括运动项目参与人数分布、用户技能等级分布、队伍状态统计、评价分布等图表。

（5）算法权重配置功能：管理员可调整推荐算法的权重配置，包括UserCF、ItemCF、NCF三种算法的权重比例。

图3-6 管理员用例图

1. 1. 1. 非功能性需求分析

（1）性能需求：系统响应时间应在可接受范围内，页面加载时间不超过3秒，推荐算法响应时间不超过2秒。系统应能支持至少100个并发用户同时访问，数据库查询操作应进行优化以避免性能瓶颈。

（2）安全性需求：用户密码须加密存储，系统采用安全的哈希算法处理密码；用户敏感信息如邮箱应脱敏展示；需防范常见的Web安全威胁，包括SQL注入、XSS攻击、CSRF攻击等；管理后台需进行权限控制，防止越权访问。

（3）可靠性需求：系统应具备7×24小时稳定运行能力，平均故障恢复时间不超过1小时；关键操作如队伍创建、评价提交等应保证数据一致性；系统应具备日志记录能力，便于故障排查和审计追踪。

（4）可维护性需求：代码应遵循Python编码规范，结构清晰，注释完整；系统架构应模块化设计，各模块职责单一，便于独立修改和扩展；数据库设计应规范，表结构和字段命名具有自解释性。

（5）可用性需求：用户界面应简洁美观，符合主流Web应用的交互习惯；操作流程应符合用户认知模型，减少学习成本；系统应提供必要的操作提示和错误反馈，帮助用户理解系统状态。

1. 1. 本章小结

本章从可行性分析和需求分析两个维度对系统进行了全面分析。可行性分析表明，系统在经济、技术和操作三个层面均具备实施条件。需求分析阶段，首先梳理了运动浏览、智能推荐、组队管理、评价反馈四个核心业务流程，然后按照用户角色划分了普通用户和管理员的具体功能需求，最后从性能、安全、可靠性等方面提出了非功能性需求。这些分析结果将作为后续系统设计和实现的依据。

1. 系统设计
   1. 系统总体架构设计
      1. 系统架构设计

本系统采用经典的B/S（Browser/Server）三层架构模式，将系统划分为表现层、业务逻辑层和数据访问层三个层次。各层职责明确，层间通过规范接口通信，降低了模块间的耦合度，便于独立开发和维护。

表现层位于架构最上层，负责与用户交互，接收用户请求并展示处理结果。本系统的表现层采用HTML、CSS、JavaScript技术构建，使用Bootstrap框架提供响应式布局和UI组件，ECharts图表库实现数据可视化。用户通过浏览器访问系统，所有页面由服务器端模板引擎渲染生成。

业务逻辑层位于架构中间层，是系统的核心处理单元，负责实现各项业务功能。该层采用Flask框架搭建，按照功能模块划分代码结构。路由模块负责请求分发，将HTTP请求映射到对应的处理函数；推荐算法模块包含UserCF、ItemCF和NCF三种算法的实现；业务处理模块封装用户管理、组队管理等核心逻辑。

数据访问层位于架构最底层，负责数据的持久化存储和访问。该层采用SQLAlchemy ORM框架实现，通过定义数据模型类映射数据库表结构，提供面向对象的数据操作接口。数据库选用SQLite，这是一种轻量级的嵌入式关系数据库，无需独立服务器进程，适合中小型应用场景。

系统数据流描述如下：用户在浏览器端发起请求，请求通过网络传输到达服务器；Flask应用接收请求，根据路由规则分发到对应的处理函数；处理函数调用业务逻辑完成处理，如需访问数据则通过ORM层操作数据库；处理结果渲染为HTML页面或JSON数据返回浏览器；浏览器解析响应内容并呈现给用户。

图4-1 系统架构图

1. 1. 1. 系统功能模块设计

运动组队推荐系统以智能推荐为核心，为用户提供便捷的运动组队服务。系统功能模块划分为用户管理模块、运动项目管理模块、智能推荐模块、组队管理模块、评价管理模块和系统管理模块六大模块。

用户管理模块负责用户身份认证和个人信息管理，包括用户注册、用户登录、密码修改、个人信息编辑等功能。用户注册时需填写用户名、邮箱、密码，并可选择填写技能等级和偏好运动。系统对密码进行加密存储，保证账户安全。

运动项目管理模块提供运动项目的增删改查功能。普通用户可浏览运动项目列表、查看项目详情、将感兴趣的项目添加至个人偏好。管理员可在后台添加新运动项目、编辑项目信息、下架不再提供的项目。

智能推荐模块是系统的核心模块，融合UserCF、ItemCF和NCF三种算法，为用户推荐匹配度较高的潜在队友。模块接收用户ID作为输入，调用各算法计算推荐分数，加权融合后返回推荐列表。推荐结果包含用户信息和匹配度评分。

组队管理模块实现队伍的全生命周期管理。用户可创建队伍并设置相关参数，可浏览招募中的队伍并申请加入，队长可审核申请并管理队伍成员。队伍状态包括招募中、已关闭、已完成三种。

评价管理模块支持活动结束后的用户互评功能。用户可对参与同一活动的队友进行评分和文字评价，评价数据存储后参与后续推荐计算，形成反馈循环。

系统管理模块面向管理员用户，提供用户管理、数据统计、算法配置等功能。管理员可查看系统运营数据、调整推荐算法权重、管理用户账户状态。

图4-2 系统功能图

1. 1. 数据库设计
      1. 数据库E-R模型设计

本系统采用关系型数据库SQLite进行数据存储，数据库设计遵循第三范式要求，确保数据完整性和一致性。系统涉及的主要实体包括用户、运动项目、用户运动记录、队伍、队伍成员和评价记录。

用户实体记录系统用户的基本信息，属性包括用户ID、用户名、邮箱、密码哈希、技能等级、偏好运动、是否管理员、账户状态、创建时间等。用户实体与用户运动记录实体存在一对多关系，一个用户可以有多条运动记录；与队伍实体存在一对多关系，一个用户可以创建多个队伍；与评价实体存在多对多关系，用户可以给多个用户评价，也可以收到多个用户的评价。

运动项目实体记录系统中所有运动项目的信息，属性包括项目ID、项目名称、类别、描述、难度等级、最少人数、最多人数等。运动项目实体与用户运动记录实体存在一对多关系，一个运动项目可以被多个用户参与；与队伍实体存在一对多关系，一个运动项目可以对应多个队伍。

用户运动记录实体记录用户参与运动项目的相关信息，是用户与运动项目的关联实体，属性包括记录ID、用户ID、运动项目ID、评分、参与频次、技能等级、最近参与时间等。该实体是协同过滤算法的核心数据来源。

队伍实体记录队伍的基本信息，属性包括队伍ID、运动项目ID、创建者ID、队伍名称、描述、人数上限、计划时间、状态等。队伍实体与队伍成员实体存在一对多关系，一个队伍可以有多个成员。

队伍成员实体记录队伍的成员构成，属性包括成员ID、队伍ID、用户ID、加入时间。该实体与队伍实体和用户实体分别存在多对一关系。

评价实体记录用户之间的评价信息，属性包括评价ID、评价者ID、被评价者ID、队伍ID、评分、评语、评价时间等。该实体连接两个用户实体，形成多对多关系。

图4-3 系统E-R图

1. 1. 1. 数据库表设计

本系统数据库共设计八张数据表，分别是用户表（users）、运动项目表（sports）、用户运动记录表（user_sports）、队伍表（teams）、队伍成员表（team_members）、评价表（ratings）、模型指标表（model_metrics）和系统配置表（system_config）。以下详细介绍各表的结构设计。

1、users表（用户表）

users表用于存储系统用户的基本信息，包括身份认证信息和个人偏好设置。表结构设计如表4.1所示。

表4.1 users表结构

字段名	数据类型	约束	说明
id	INTEGER	主键、自增	用户唯一标识
username	VARCHAR(80)	非空、唯一	用户名
email	VARCHAR(120)	非空、唯一	电子邮箱
password_hash	VARCHAR(255)	非空	密码哈希值
skill_level	VARCHAR(20)	默认intermediate	技能等级
preferred_sports	TEXT		偏好运动ID列表
is_admin	BOOLEAN	默认否	是否管理员
is_active	BOOLEAN	默认是	账户是否激活
created_at	DATETIME	默认当前时间	创建时间
updated_at	DATETIME	默认当前时间	更新时间

2、sports表（运动项目表）

sports表用于存储运动项目的基本信息。表结构设计如表4.2所示。

表4.2 sports表结构

字段名	数据类型	约束	说明
id	INTEGER	主键、自增	项目唯一标识
name	VARCHAR(100)	非空	项目名称
category	VARCHAR(50)		项目类别
description	TEXT		项目描述
difficulty	VARCHAR(20)		难度等级
min_players	INTEGER	默认2	最少人数
max_players	INTEGER	默认10	最多人数
icon	VARCHAR(100)		图标名称
created_at	DATETIME	默认当前时间	创建时间

3、user_sports表（用户运动记录表）

user_sports表记录用户参与运动项目的详细信息，是推荐算法的数据基础。表结构设计如表4.3所示。

表4.3 user_sports表结构

字段名	数据类型	约束	说明
id	INTEGER	主键、自增	记录唯一标识
user_id	INTEGER	外键、非空	用户ID
sport_id	INTEGER	外键、非空	运动项目ID
rating	FLOAT	默认3.0	喜好评分(1-5)
frequency	INTEGER	默认1	参与频次
skill_level	VARCHAR(20)		该运动技能等级
last_played	DATETIME		最近参与时间
created_at	DATETIME	默认当前时间	创建时间

4、teams表（队伍表）

teams表记录队伍的基本信息和状态。表结构设计如表4.4所示。

表4.4 teams表结构

字段名	数据类型	约束	说明
id	INTEGER	主键、自增	队伍唯一标识
sport_id	INTEGER	外键、非空	运动项目ID
creator_id	INTEGER	外键、非空	创建者ID
title	VARCHAR(200)	非空	队伍名称
description	TEXT		队伍描述
max_members	INTEGER	默认5	人数上限
scheduled_time	DATETIME		计划活动时间
status	VARCHAR(20)	默认open	队伍状态
created_at	DATETIME	默认当前时间	创建时间
updated_at	DATETIME	默认当前时间	更新时间

5、team_members表（队伍成员表）

team_members表记录队伍的成员构成。表结构设计如表4.5所示。

表4.5 team_members表结构

字段名	数据类型	约束	说明
id	INTEGER	主键、自增	记录唯一标识
team_id	INTEGER	外键、非空	队伍ID
user_id	INTEGER	外键、非空	用户ID
joined_at	DATETIME	默认当前时间	加入时间

6、ratings表（评价表）

ratings表记录用户之间的评价信息。表结构设计如表4.6所示。

表4.6 ratings表结构

字段名	数据类型	约束	说明
id	INTEGER	主键、自增	评价唯一标识
from_user_id	INTEGER	外键、非空	评价者ID
to_user_id	INTEGER	外键、非空	被评价者ID
team_id	INTEGER	外键	队伍ID
rating	INTEGER	非空	评分(1-5)
comment	TEXT		评语
created_at	DATETIME	默认当前时间	评价时间

1. 1.  推荐算法设计与实现
      1.  混合推荐策略设计

单一推荐算法往往存在固有缺陷：协同过滤面临数据稀疏和冷启动问题，新用户或新物品难以获得准确推荐；基于内容的方法依赖特征工程质量，且难以发现用户潜在兴趣。为克服单一算法的局限性，本系统采用混合推荐策略，融合多种算法的优势。

混合推荐策略的核心思想是：将UserCF、ItemCF和NCF三种算法的推荐结果进行加权融合，综合得出最终推荐。权重分配考虑了各算法的特点：NCF作为深度学习模型，能够学习复杂的非线性特征，赋予较高权重（40%）；UserCF和ItemCF作为成熟的传统方法，分别赋予30%的权重。

融合过程分为三个步骤：(1)各算法独立计算推荐分数；(2)对各算法的分数进行归一化处理，统一到0-1范围；(3)按照权重加权求和，得到最终推荐分数。归一化方法根据算法特点选择：UserCF的余弦相似度范围在-1到1之间，采用线性映射；ItemCF和NCF的预测评分范围在1到5之间，采用最小-最大归一化。

该策略的优势在于：当某一算法因数据稀疏等原因失效时，其他算法仍可提供有效推荐，保证系统的鲁棒性；同时，不同算法捕捉不同层面的用户偏好，融合结果更加全面。

1. 1. 1.  神经协同过滤算法的设计与实现

NCF模型采用GMF与MLP混合架构，整体设计借鉴了He等学者提出的方法，并结合运动组队场景进行了针对性优化。模型输入为用户ID和运动项目ID，输出为预测的偏好评分。

(1)数据处理流程

模型训练需要将原始的用户运动记录转换为适合神经网络处理的格式。数据处理流程分为数据提取、ID映射构建、负采样和数据集划分四个步骤。

数据提取阶段，从数据库的user_sports表中查询所有用户运动记录，包括用户ID、运动项目ID和评分三个字段。原始数据格式如表4.7所示。

表4.7 原始数据样例

用户ID	运动项目ID	评分
1	3	4.5
1	7	5
2	1	3
...	...	...

系统中共有100个用户和19项运动，产生了1001条用户运动记录。这些数据构成了推荐算法的基础数据集。

ID映射构建阶段，将数据库中的原始ID（用户ID和运动项目ID）映射为连续的整数索引，便于嵌入层查表操作。映射关系存储在字典结构中，键为原始ID，值为索引。例如，用户ID 1映射为索引0，运动项目ID 3映射为索引2。同时构建反向映射字典，用于推理时将预测结果还原为原始ID。

负采样阶段，原始数据仅包含用户参与过的运动项目，即正样本。为了让模型学习区分用户喜欢和不喜欢的运动，需要补充负样本。负采样策略如下：对于每个正样本（用户u，运动i，评分r），从用户u未参与过的运动中随机选取5个运动作为负样本，负样本的评分设为随机低分（1.0至2.0分之间随机选取）。经过负采样后，数据集规模扩展为6006条记录，正负样本比例约为1:5。

数据集划分阶段，采用随机划分方式，将数据集按8:2的比例划分为训练集和验证集。训练集包含4804条记录，用于模型参数学习；验证集包含1202条记录，用于监控训练过程和调参。划分过程采用随机打乱确保数据分布均匀。

数据处理的伪代码如下：

输入：数据库中的用户运动记录

输出：训练数据集、验证数据集

1. 从数据库查询所有用户运动记录

2. 构建用户ID到索引的映射字典 user_id_map

3. 构建运动ID到索引的映射字典 item_id_map

4. 对于每条正样本记录：

   a. 转换用户ID和运动ID为索引

   b. 将评分归一化到0-1范围：(rating-1)/4

5. 进行负采样，补充负样本

6. 随机打乱数据

7. 按8:2比例划分训练集和验证集

8. 封装为DataLoader，批次大小64

(2)模型网络结构设计

模型包含四组嵌入向量：GMF分支的用户嵌入和物品嵌入，MLP分支的用户嵌入和物品嵌入。嵌入维度设为64，通过查表操作将用户ID和物品ID转换为稠密向量。嵌入向量参与模型训练，无需预训练。嵌入向量的初始化采用正态分布，均值为0，标准差为0.01，有助于训练初期的稳定性。

GMF分支保留了矩阵分解的线性特性。用户嵌入向量和物品嵌入向量进行元素积运算，即对应位置元素相乘，得到维度为64的向量。该向量保留了用户与物品之间的线性交互关系。

MLP分支采用四层全连接网络结构，各层神经元数量分别为128、64、32、16。用户嵌入向量和物品嵌入向量拼接后作为输入（维度128），依次通过四个全连接层。每个全连接层后接BatchNorm层、ReLU激活函数和Dropout层（丢弃率0.3）。BatchNorm层能够加速训练收敛，Dropout层防止过拟合。

输出层将GMF分支输出（维度64）和MLP分支输出（维度16）拼接，得到维度为80的特征向量。该向量输入输出层，输出层为单神经元全连接层，后接Sigmoid激活函数，将输出映射到0-1范围。推理时，Sigmoid输出乘以4并加1，映射到1-5的评分范围。

模型整体结构可概括为：输入层接收用户ID和运动项目ID，分别通过GMF和MLP两条分支进行特征提取，最后合并输出预测评分。GMF分支通过嵌入向量元素积捕捉线性交互，MLP分支通过多层感知机学习非线性关系，两者互补增强了模型的表达能力。

图4-4 模型流程图

(3)模型训练过程

模型训练采用PyTorch框架实现，训练脚本为train.py。训练过程包括损失函数定义、优化器配置、学习率调度、早停机制和训练监控五个部分。

损失函数选用SmoothL1损失（Huber损失），相比均方误差对异常值更鲁棒。损失函数定义如下：

L(y, ŷ) = { 0.5(y-ŷ)² if |y-ŷ| < 1; |y-ŷ| - 0.5 otherwise }

优化器配置采用Adam算法，学习率设为0.001，权重衰减系数设为1e-4以防止过拟合。Adam算法结合了动量和自适应学习率的优点，训练过程收敛较快。

学习率调度采用ReduceLROnPlateau策略，监控验证集损失，当连续5个epoch损失未下降时，学习率乘以0.5。初始学习率为0.001，训练过程中学习率变化如表4.8所示。

表4.8 学习率调度记录

Epoch范围	学习率
1-15	0.001
16-35	0.0005
36-70	0.00025
71-100	0.000125

早停机制监控验证集损失，当连续15个epoch损失未下降时，停止训练并恢复最佳模型参数。本实验在第26个epoch时验证集损失达到最低值0.0321，之后虽有波动但未再改善，最终在第41个epoch触发早停，恢复第26个epoch的模型参数。

训练监控记录每个epoch的训练损失、验证损失、训练RMSE、验证RMSE、训练MAE、验证MAE等指标，写入日志文件和CSV文件。训练完成后生成训练曲线图和算法对比图。

(4)训练结果与分析

模型训练共进行100个epoch（早停后恢复最佳模型），训练过程的关键指标变化如表4.9所示。

表4.9 训练过程关键指标

Epoch	训练损失	验证损失	训练RMSE	验证RMSE	训练MAE	验证MAE
1	0.0477	0.0424	1.2353	1.1821	1.0231	0.9653
10	0.0293	0.0333	0.9718	1.0567	0.7909	0.893
26	0.0189	0.0313	0.778	1.0014	0.6203	0.8215
50	0.016	0.0343	0.7173	1.0356	0.574	0.8524
100	0.0167	0.0348	0.7247	1.0397	0.5774	0.8568

从表中可以看出，训练损失和验证损失在前15个epoch快速下降，之后趋于平稳。最佳验证损失出现在第26个epoch，之后模型开始出现过拟合迹象，训练损失继续下降而验证损失略有上升。早停机制有效防止了过拟合。

训练过程生成的曲线图直观展示了模型学习过程。如图4.5所示为NCF训练损失曲线，横轴为训练轮次，纵轴为损失值，蓝色曲线为训练损失，橙色曲线为验证损失。

NCF 图4.5 NCF模型训练损失曲线

从图4.5可以看出，训练损失从初始的0.0477稳步下降至0.0167左右，验证损失从0.0424下降至最佳值0.0313后趋于稳定。两条曲线的变化趋势一致，说明模型学习过程正常，未出现严重的过拟合或欠拟合。

训练完成后，将模型权重、用户ID映射和物品ID映射保存到文件data/ncf_model.pth，便于后续加载使用。同时生成算法对比图，如图4.6所示，对比了UserCF、ItemCF和NCF三种算法的RMSE和MAE指标。

 图4.6 三种推荐算法性能对比

从图4.6可以看出，NCF模型的RMSE为0.68，MAE为0.53，均明显优于UserCF（RMSE 1.07，MAE 0.87）和ItemCF（RMSE 0.88，MAE 0.77）。这验证了深度学习方法在运动组队推荐场景的有效性。NCF通过神经网络学习用户与运动项目之间的非线性交互关系，能够捕捉传统协同过滤方法难以发现的隐式特征，从而提升推荐精度。

(5)模型推理

模型训练完成后，推理过程如下：输入用户ID和运动项目ID，通过ID映射转换为索引；将索引输入模型，经过嵌入层、GMF分支和MLP分支计算，输出层得到预测值；预测值乘以4加1转换为1-5范围的评分。推理代码封装在HybridRecommender类中，提供get_ncf_score方法供其他模块调用。

1. 1. 1. 混合算法的实现

混合推荐算法的实现封装在HybridRecommender类中，该类负责协调三种算法的调用和结果融合。实现流程如下：

(1)在系统启动时调用load_data方法初始化各算法组件。UserCF和ItemCF从数据库加载用户-物品矩阵，计算相似度矩阵；NCF模型从文件加载预训练权重。

(2)当用户请求推荐时，调用get_recommendations方法。该方法遍历所有候选用户，分别计算三种算法的匹配分数。UserCF分数通过查询用户相似度矩阵获得；ItemCF分数通过比较用户运动偏好向量的重合度计算；NCF分数通过模型预测用户对候选用户偏好运动的评分获得。

(3)对三种算法的分数进行归一化和加权融合，按最终分数排序返回推荐列表。权重配置存储在系统配置表中，管理员可在后台进行调整。

1. 1.  本章小结

本章详细阐述了系统的设计方案。系统架构采用B/S三层模式，实现了表现层、业务逻辑层和数据访问层的分离。功能模块划分清晰，覆盖用户管理、运动浏览、智能推荐、组队管理、评价管理和系统管理六大模块。数据库设计了八张核心数据表，采用关系模型，通过外键约束保证数据完整性。推荐算法层面，设计了UserCF、ItemCF和NCF三种算法的混合策略，详细说明了NCF模型的网络结构和训练优化方法。这些设计方案为后续系统实现提供了明确的指导。

1. 系统实现
   1. 开发环境建立

本系统的开发环境配置分为硬件环境和软件环境两部分。硬件环境采用普通个人计算机即可满足开发需求，软件环境则包括操作系统、开发语言、数据库、Web框架和深度学习框架等组件。具体配置情况如表5.1所示。

表5.1 系统开发环境

项目目录结构按照功能模块进行组织，主要包含以下目录：app.py为应用入口文件；models目录存放数据库模型和NCF模型定义；algorithms目录存放推荐算法实现；templates目录存放HTML模板文件；static目录存放CSS、JavaScript等静态资源；data目录存放数据库文件和模型权重文件；utils目录存放工具函数。

项目依赖管理采用requirements.txt文件，列出所有第三方库及其版本号。安装依赖可通过pip install -r requirements.txt命令一键完成。数据库初始化采用Flask-Migrate扩展，支持数据库迁移和版本管理。

1. 1. 主要模块实现
      1. 用户管理模块实现

用户管理模块负责用户注册、登录和个人信息管理功能。注册功能实现流程：用户在注册页面填写用户名、邮箱、密码等信息，提交后服务器端验证用户名和邮箱是否已被注册，验证通过后使用Werkzeug库的generate_password_hash函数对密码进行哈希处理，生成用户记录并存入数据库。密码哈希采用pbkdf2:sha256算法，确保密码存储安全。

登录功能实现流程：用户提交用户名和密码后，服务器端查询数据库获取用户记录，使用check_password_hash函数验证密码哈希是否匹配。验证通过后，调用Flask-Login的login_user函数建立用户会话，并重定向到用户首页。会话管理采用安全Cookie机制，有效期为30天。

用户模型类继承自db.Model和UserMixin，UserMixin提供了Flask-Login所需的is_authenticated、is_active等属性方法。模型定义中包含了用户的基本信息字段和与运动记录、队伍、评价的关系映射，便于通过ORM进行关联查询。

图5-1 登录页面

1. 1. 1. 运动项目管理模块实现

运动项目管理模块提供运动项目的浏览、搜索和详情展示功能。运动项目列表页支持按类别筛选，类别数据从数据库中查询获取，展示时使用Bootstrap卡片组件进行布局。搜索功能通过SQLAlchemy的filter方法实现，支持模糊匹配运动项目名称。

运动项目详情页展示项目的完整信息，包括名称、类别、难度、人数要求等。用户可在此页面将项目添加至个人偏好列表，该操作调用后端API完成用户运动记录的创建或更新。

运动项目数据在系统初始化时预置，包含篮球、足球、羽毛球、跑步、游泳、骑行、健身、瑜伽等19项常见运动。每项运动都设置了合理的类别归属和难度等级模型训练管理实现。

图5-2 组队管理页面

1. 1. 1.  智能推荐模块实现

智能推荐模块是系统的核心模块，实现了混合推荐算法。模块主要由HybridRecommender类和NCFModel类构成。

HybridRecommender类负责协调三种推荐算法。在初始化阶段，调用各算法的数据加载方法：UserCF和ItemCF从数据库加载用户-物品评分矩阵，计算用户相似度矩阵和物品相似度矩阵；NCF模型从文件加载预训练权重。

推荐请求的处理流程：接收用户ID和推荐数量参数，遍历所有候选用户，分别计算三种算法的匹配分数。UserCF分数通过查询预计算的用户相似度矩阵直接获得，时间复杂度为O(1)。ItemCF分数通过计算用户运动偏好向量的交集，并根据评分进行加权平均。NCF分数通过模型推理预测用户对候选用户偏好运动的评分。

分数融合过程对三种分数进行归一化处理。UserCF的余弦相似度范围在-1到1之间，采用(r+1)/2映射到0-1范围；ItemCF和NCF的预测评分范围在1到5之间，采用(r-1)/4归一化到0-1范围。归一化后的分数按权重加权求和，得到最终推荐分数。

NCFModel类的实现采用PyTorch框架。模型定义继承自nn.Module，在__init__方法中初始化嵌入层、MLP层和输出层。前向传播方法实现GMF和MLP两个分支的计算，最终合并输出。模型训练采用NCFTrainer类封装，包含训练循环、损失计算、优化器更新和早停判断等逻辑。

训练数据准备阶段，从数据库查询用户运动记录，构建用户ID和物品ID的映射字典。采用负采样策略补充负样本，正负样本比例为1:5。数据集划分采用8:2的比例，80%用于训练，20%用于验证。

训练过程监控多个指标，包括训练损失、验证损失、训练RMSE、验证RMSE等。每轮epoch结束后，保存各项指标到日志文件，并绘制训练曲线图。训练完成后，保存模型权重和ID映射到文件。

图5-3 推荐组队页面

1. 1. 1. 组队管理模块实现

组队管理模块实现队伍的创建、加入、退出和管理功能。

队伍创建功能实现：用户填写队伍名称、运动项目、活动时间、人数上限等信息，提交后服务器端创建Team记录，状态设为open。同时创建TeamMember记录，将创建者加入队伍。队伍创建成功后重定向到队伍详情页。

队伍列表页展示用户创建的队伍和已加入的队伍，通过SQL查询分别获取。队伍卡片显示运动项目名称、队伍状态、成员数量等信息，点击可进入详情页。

队伍加入功能实现：用户浏览招募中的队伍列表，选择感兴趣的队伍申请加入。服务器端检查队伍状态是否为open、成员数量是否已达上限，检查通过后创建TeamMember记录。队长可在队伍管理页查看加入申请，审核通过或拒绝。

队伍管理功能面向队长用户，提供成员查看、移除成员、关闭队伍等操作。移除成员即删除对应的TeamMember记录；关闭队伍即更新Team记录的状态字段为closed。

图5-4 组队管理页面

1. 1. 1. 评价管理模块实现

评价管理模块实现队友评价功能。评价入口位于队伍详情页，队伍状态为completed时显示评价按钮。点击评价后弹出评价表单，包含评分滑块（1-5分）和评语文本框。

评价提交流程：用户填写评分和评语后提交，服务器端创建Rating记录，关联评价者ID、被评价者ID和队伍ID。评价数据同时更新被评价者的平均评分，该评分在用户个人主页展示。

评价记录查询功能：用户可在个人中心查看收到和发出的评价列表。列表展示评价者/被评价者名称、评分、评语和评价时间。

图5-5 评价管理页面

1. 1. 1.  管理后台模块实现

管理后台面向管理员用户，提供用户管理、数据统计和系统配置功能。后台入口通过/admin路径访问，访问前验证用户是否具有管理员权限。

用户管理功能展示系统中所有用户列表，支持按用户名、邮箱、技能等级等条件筛选。管理员可编辑用户信息、修改账户状态（激活/禁用）、删除用户账户。

图5-6 用户管理页面

数据统计功能使用ECharts图表库实现可视化展示。主要图表包括：运动项目参与人数柱状图，展示各项运动的用户参与情况；用户技能等级分布饼图，展示不同技能等级的用户比例；队伍状态统计图，展示各状态队伍的数量分布；评价分布柱状图，展示1-5分的评价数量分布。数据通过后端API查询数据库获取，前端通过AJAX请求加载并渲染图表。

图5-7 数据统计页面

系统配置功能允许管理员调整推荐算法的权重配置。权重配置存储在system_config表中，修改后立即生效，无需重启服务。

图5-8 推荐权重设置页面