★ FEATURED ARTICLE 1. 先想清楚这个智能学习辅导系统到底要辅导什么看到这个标题我猜很多人第一反应是SpringBoot 机器学习听起来高大上但真要动手做毕设或者实际项目的时候往往就卡在了一个灵魂问题上——系统到底要智能在哪里。是做个聊天机器人陪学生聊天还是根据学生错题自动推送练习题或者像有些同学想的那样搞个AI老师自动讲解知识点如果你只是把题库挂在网页上让学生自己刷题那这个系统离智能两个字还差得很远。我自己的理解是一个真正可用的智能学习辅导系统核心要解决三个问题诊断学生现在哪些知识点掌握得不好薄弱环节在哪推荐接下来该学什么、该练什么才能最高效地补齐短板干预学生是不是要掉队了要不要提前预警让老师或系统介入这三个环节对应到技术实现上就是知识掌握度评估、个性化题目推荐、学情预测与预警。这也是整个系统里机器学习真正能落地的场景。我见过不少项目把重点放在界面好看和功能列表齐全上但学习数据的流转逻辑是断的——学生做了题结果只是存进数据库没有进入任何分析和推荐链路。那这个系统做出来本质上就是个带用户系统的刷题网站机器学习纯粹是装饰。做这类系统我的建议是先定义清楚一个最小的业务闭环。比如不要一开始就想着做完整的知识图谱、深度学习模型、实时学习路径规划先做到做题→判分→更新掌握度→推荐下一组题这个闭环跑通后面再逐步加功能。这个闭环里面每一个环节都需要数据支撑也都有机器学习可以发挥的空间比一上来就铺一堆花架子功能扎实得多。2. 整体技术选型为什么是SpringBoot加Python的双轨制确定了业务闭环之后最头疼的就是技术选型。这个标题里同时出现SpringBoot和机器学习很多同学第一个纠结的问题是**Java里能不能直接做机器学习模型要不要用Java重写**我明确建议不要。先说结论整个系统采用前后端分离 双语言架构前端Vue 3 Element Plus负责学生端、教师端的页面交互后端主服务SpringBoot 2.7.x负责用户权限、业务逻辑、数据持久化、对接模型服务模型服务Python FastAPI负责所有机器学习相关的推理任务数据存储MySQL 存业务数据Redis 做缓存和热点数据Elasticsearch 可选做题目检索MVP阶段可以不加中间通信SpringBoot 通过 HTTP 调用 Python 模型服务JSON 格式传数据2.1 为什么后端必须用SpringBoot有些同学会想既然机器学习都在Python这边那后端干脆也用Python比如Django、FastAPI写不就行了何必搞两套语言这个问题我在项目里也认真想过。答案是学习辅导系统除了推荐算法更重要的是业务系统的复杂度。用户管理、角色权限、课程管理、题目管理、做题记录、成绩统计、班级管理、教师端审核……这些功能是典型的业务系统场景。SpringBoot 在这方面的成熟度是Python全家桶比不了的Spring Security JWT 做权限管理方案非常成熟网上资料也多MyBatis-Plus 操作数据库效率极高分页、条件查询、逻辑删除这些全都内置Spring 生态的依赖注入、事务管理、定时任务写业务代码时省心很多部署运维方案成熟打一个jar包就能跑另外还有个很现实的因素这类项目大概率是毕业设计或者课程项目SpringBoot Vue 这套组合在答辩时老师认可度高遇到问题也更容易找到参考代码。2.2 为什么机器学习必须放在Python侧反过来为什么不在SpringBoot里直接调机器学习库比如Java的Weka、Smile、Deeplearning4j答案是生态差距太大。你随便找一个机器学习项目比如基于协同过滤的推荐、知识点掌握度预测、学习行为聚类参考代码和预训练模型几乎全部是Python写的。scikit-learn、pandas、numpy 这些库在数据处理和模型训练上的便利程度Java生态完全比不了。更别说如果要上深度学习相关的模型PyTorch的生态更是碾压性的。我在项目里就是这样分工的SpringBoot负责接客Python负责思考。Python模型服务包装成HTTP接口对SpringBoot来说就是一个普通的外部API内部用什么算法、什么框架完全透明。这样两边各干各的擅长的事互不拖累。2.3 一个容易被忽视的细节SpringBoot版本别盲目追新这个项目涉及跨语言对接稳定性是第一位的。SpringBoot版本我建议用 2.7.x 而不是 3.x为什么SpringBoot 3.x 基于Spring Framework 6底层是Java 17有些老版本的依赖比如某些MyBatis-Plus版本、代码生成器会有兼容性问题。如果你用的是JDK 8那SpringBoot 2.7.x 几乎是唯一选择——3.x根本不支持JDK 8。很多同学在开发时遇到莫名其妙的依赖冲突排查到最后发现是版本太高导致的这种坑真的没必要踩。我个人的推荐组合是组件版本选择JDK1.8 或 11SpringBoot2.7.18MyBatis-Plus3.5.xMySQL5.7 或 8.0Redis6.x 或 7.xPython3.9FastAPI0.100scikit-learn1.3这套组合经过大量项目验证兼容性几乎不会出问题。毕设项目求稳最重要没必要在版本上玩心跳。3. 学习行为数据从哪来采集、清洗与特征工程机器学习项目有个铁律模型的效果上限由数据质量决定。很多同学做智能推荐结果发现模型训练出来完全不能用回过头来排查才发现是数据本身一塌糊涂——日志缺字段、做题记录对不上学生、知识点标签混乱。这一节我把数据这块掰开了讲。3.1 定义行为埋点前端要采集什么智能辅导系统的第一手数据来自学生的行为。我在系统里设计了这样几类核心事件start_exam开始答题记录学生ID、题目ID、知识点ID、时间戳submit_answer提交答案记录答案内容、是否正确、用时view_material查看学习资料记录资料ID、停留时长pause_learning暂停学习记录离开时的进度这些事件埋在前端页面里统一通过一个接口上报到后端。关键一点是不要只上报结果要把过程也上报。比如一道题学生做了60秒做对了和做了5秒做对了反映出的掌握程度是完全不一样的。答题用时这个字段在后面对特征工程非常有价值。3.2 数据落库与清洗的细节前端上报的数据在后端要做基本的校验和清洗不然脏数据会直接影响模型。我在项目里遇到过几个典型问题重复上报学生刷新页面导致同一道题提交两次。处理方案是加一个request_id做幂等同一道题同一个session只记录一次时间戳异常学生挂机很久后回来提交答题用时显示30分钟。这种明显超过阈值的数据比如超过10分钟要么剔除要么做截断处理知识点缺失某些题目没有正确关联到知识点导致这条记录无法进入特征计算。这个要在题库维护时就做好约束清洗后的数据会写入一张learning_record表这是后面所有特征计算的数据源。3.3 特征工程把日志变成模型能懂的宽表原始数据是一条条的事件记录不能直接扔给模型。要做特征工程把每个学生的行为聚合成特征。我在项目里按不同的时间窗口最近一天、近三天、近一周聚合出一张学生特征宽表典型字段包括student_id学生IDtotal_questions总做题数correct_rate正确率avg_response_time平均答题用时秒knowledge_point_coverage已接触知识点数 / 总知识点数weak_knowledge_count薄弱知识点数量正确率低于60%的知识点study_frequency近7天学习天数continuous_study_days连续学习天数recent_avg_score最近一次测验的平均得分time_of_day最常学习的时间段偏好早上/晚上这些特征并不需要多高深的数学核心是把学习行为转化成数字。特征的质量远比数量重要。我当时就是靠这一批基础特征做出来的推荐和预测效果已经相当可用了。值得一提的还有遗忘曲线特征。心理学里的艾宾浩斯遗忘曲线告诉我们记忆会随时间衰减。在特征里可以加一个knowledge_recency学生距离上次练习某个知识点的时间间隔。间隔越久掌握度下降越明显。这个特征在题目推荐里非常有效学生练过的题隔了一周再去推荐重测和刚练完就推荐重测含义完全不同。4. 模型选型与训练从规则到算法的渐进之路很多初学者一上来就想着用深度学习、用知识图谱、用大模型其实在智能学习辅导这类场景里大多数时候浅层模型就够了而且效果更好维护。我建议按下面的层次逐步升级。4.1 先用规则打底再用模型优化在做机器学习之前先把规则系统做好。比如知识点-题目映射每道题关联到知识点这是最基础的规则薄弱知识点判定正确率低于60%的知识点标记为薄弱基础推荐规则优先推送薄弱知识点下的未被掌握题目这些规则不需要训练纯靠业务逻辑就能实现但它们是整个系统的骨架。规则系统跑通之后再去叠加机器学习模型这样即使模型出问题系统也还有规则兜底不至于完全跑不动。4.2 题目推荐模型双路召回 融合排序推荐题目是智能辅导系统最核心的机器学习场景。我在项目中用的是双路召回 排序融合的思路。第一路基于物品的协同过滤ItemCF。核心逻辑是如果大量学生在做A题之后都做了B题那A和B之间存在关联关系。你做完A题我就给你推B题。算法上通过计算题目之间的相似度矩阵来实现相似度可以用余弦相似度或者Pearson相关系数。第二路基于内容的推荐Content-Based。如果学生薄弱知识点是二次函数那我就召回所有二次函数知识点下的题目再根据题目难度和学生当前水平做过滤。两路召回得到候选题目集合之后需要做排序融合。简单做法是加权融合最终得分 0.6 × 协同过滤得分 0.4 × 内容匹配得分。更进阶一点可以训练一个逻辑回归模型来学习这个权重输入特征是两路得分、题目难度、学生历史正确率等输出是学生做对这道题的概率然后按概率排序。4.3 学情预测模型预测学生会不会掉队除了推荐我还做了一个学情预警功能根据学生最近一段时间的学习行为预测他下一次测验是否会出现成绩下滑。这里我选用的是逻辑回归因为它在教学场景里有明显的优势——可解释性强。逻辑回归输出的不是一个二分类标签而是一个概率值比如该学生下次测验下滑概率为0.78。而且可以输出每个特征的贡献权重比如近期做题量少这个因素贡献了0.3的下降概率。这对于教师端来说非常有说服力——老师知道干预的方向是什么。特征就用第3节列出的那些行为特征标签就是该学生下次测验是否较上一次下滑超过10%。训练数据可以从历史学习记录里构造。我用scikit-learn训练代码很简单from sklearn.linear_model import LogisticRegression from sklearn.model_selection import train_test_split import pandas as pd # 加载特征宽表 df pd.read_csv(student_features.csv) X df.drop([student_id, label], axis1) y df[label] # 切分训练测试集 X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.2, random_state42, stratifyy ) # 训练逻辑回归 model LogisticRegression(max_iter1000) model.fit(X_train, y_train) # 评估 from sklearn.metrics import accuracy_score, roc_auc_score y_pred model.predict(X_test) y_proba model.predict_proba(X_test)[:, 1] print(f准确率: {accuracy_score(y_test, y_pred):.4f}) print(fAUC: {roc_auc_score(y_test, y_proba):.4f})这个模型跑下来AUC一般能做到0.75到0.85之间对于一个基于行为特征的辅导系统来说已经够用。AUC 0.8意味着模型有80%的概率能给会下滑的学生打出比正常学生更高的风险分这已经有实际的参考价值了。4.4 模型导出与版本管理训练好的模型用joblib保存import joblib joblib.dump(model, learning_risk_model.pkl) joblib.dump(item_sim_matrix, item_sim_matrix.pkl)模型文件要按版本管理比如learning_risk_model_v1.0.pkl。因为线上推理需要稳定不能模型文件直接在线上覆盖更新一旦新模型效果异常还能回滚到旧版本。5. SpringBoot与模型服务的集成我踩过最深的坑从这一节开始进入SpringBoot的重头戏如何把Python模型服务整合进Java项目里。这是整个项目里最容易出问题、也是网上资料最零散的部分。5.1 三种集成方案对比我对比过三种主流方案先看结论方案优点缺点适合场景A. Java直接调用模型库无网络开销部署简单特征处理两套代码难保持一致模型库生态弱更新模型要重新编译部署不推荐B. Python封装推理服务SpringBoot走HTTP调用模型迭代灵活Python生态完整解耦清晰多一个服务要部署维护有网络延迟推荐C. 导出PMML/ONNXJava加载推理跨语言统一模型格式特征工程处理复杂部分模型支持不好排错困难不推荐我最终选了方案B。理由很实际模型更新不需要动Java代码。比如我训练了新版本的推荐模型只需要把新模型文件放到Python服务那边服务重启加载新模型即可SpringBoot代码完全不用改。这在项目迭代中带来的维护成本优势是巨大的。5.2 Python模型服务怎么封装用FastAPI封装一个推理接口代码很清爽。以学情预测接口为例from fastapi import FastAPI from pydantic import BaseModel import joblib import numpy as np import pandas as pd app FastAPI() model joblib.load(/models/learning_risk_model_v1.0.pkl) # 注意特征顺序必须与训练时完全一致 FEATURE_COLUMNS [ total_questions, correct_rate, avg_response_time, knowledge_point_coverage, weak_knowledge_count, study_frequency, continuous_study_days, recent_avg_score ] class PredictRequest(BaseModel): student_id: int features: list app.post(/api/predict/learning_risk) async def predict_learning_risk(req: PredictRequest): features np.array(req.features).reshape(1, -1) df pd.DataFrame(features, columnsFEATURE_COLUMNS) prob model.predict_proba(df)[0][1] return { student_id: req.student_id, risk_probability: round(float(prob), 4), risk_level: high if prob 0.7 else (medium if prob 0.4 else low) }这里有一个极其关键的点请求参数里的特征顺序必须和训练时完全一致。我在这上面踩过很大的坑——训练时特征列顺序是A、B、CJava那边传过来的JSON不小心变成了A、C、B模型表现直线下降排查了很久才发现是特征顺序错位。解决方法是定义一个模型服务端的特征schemaSpringBoot每次调用时严格按照schema拼接参数并在模型服务端做校验。5.3 SpringBoot里的HTTP调用与容错SpringBoot内部调用模型服务我用的方式是RestTemplate配置好超时时间同时加上降级逻辑——模型服务挂掉时系统不能跟着挂要回到规则系统兜底。Component public class MLServiceClient { private final RestTemplate restTemplate; public MLServiceClient(RestTemplate restTemplate) { this.restTemplate restTemplate; } public RiskResult predictLearningRisk(int studentId, ListDouble features) { HttpHeaders headers new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); MapString, Object body new HashMap(); body.put(student_id, studentId); body.put(features, features); HttpEntityMapString, Object request new HttpEntity(body, headers); try { ResponseEntityRiskResult response restTemplate.postForEntity( http://localhost:8000/api/predict/learning_risk, request, RiskResult.class ); return response.getBody(); } catch (Exception e) { // 降级模型服务不可用时基于规则返回默认风险等级 return new RiskResult(studentId, 0.5, medium, fallback-rule); } } }超时设置我建议连接超时1秒读取超时3秒。原因很简单用户不能因为模型服务慢而干等。如果模型推理超过了2-3秒说明服务负载过高或模型太重这时候应该返回缓存结果或者降级结果而不是让用户一直转圈。更进一步如果推荐场景对实时性要求高可以再引入异步化——SpringBoot接收请求后立即返回请求受理后台线程异步调用模型服务等结果出来再推送给前端。这样接口响应时间完全不受模型推理影响。5.4 RestTemplate的配置细节Bean public RestTemplate restTemplate() { SimpleClientHttpRequestFactory factory new SimpleClientHttpRequestFactory(); factory.setConnectTimeout(1000); factory.setReadTimeout(3000); return new RestTemplate(factory); }这里还要注意如果SpringBoot和模型服务之间传递的是复杂对象响应的JSON结构要保持稳定。我在项目里给每个接口定义了对应的DTO类并且前后端对JSON字段名的大小写约定必须一致。建议统一用risk_probability这种下划线风格Python和Java双方都明确用同一个命名规范能省掉非常多联调阶段才能暴露的坑。6. 核心业务模块实现题目推荐、学情报告与预警架构和模型都打通之后回到业务层面我把核心功能模块的实现思路在这节完整展开这些都是可以直接复制落地的东西。6.1 题目推荐的完整链路一次推荐请求从学生点击开始练习到页面展示题目完整的流程是前端请求/api/recommend/questions?studentIdxxxSpringBoot查询该学生的知识点掌握度记录SpringBoot组装特征调用Python模型服务的推荐接口模型服务内部做双路召回 排序融合返回题目ID列表SpringBoot根据题目ID列表组装完整题目信息返回给前端RestController RequestMapping(/api/recommend) public class RecommendController { Autowired private RecommendService recommendService; GetMapping(/questions) public ResultListQuestionVO recommendQuestions(RequestParam Integer studentId) { ListQuestionVO questions recommendService.recommendForStudent(studentId); return Result.success(questions); } }这里推荐服务内部的关键逻辑是先从缓存里查有就直接返回没有才调模型服务。因为推荐结果其实在短时间内是稳定的学生不会一分钟内掌握度剧变所以完全可以做短时间缓存比如5分钟过期。这能极大降低模型服务压力。6.2 知识点掌握度的计算这是整个系统评估功能的基石。我采用的是一种简化但有效的计算方式知识掌握度 0.6 × 历史正确率 0.3 × 最近一次正确率 0.1 × 练习频次系数历史正确率该知识点下所有题目的历史平均正确率最近一次正确率最近5次练习的正确率练习频次系数如果练习次数少于3次打0.7的折扣少于5次打0.85超过5次算1.0这个公式比单纯算正确率高明的点在于它兼顾了能力和熟练度。一个学生历史正确率80%但最近连续3道题都做错了说明他可能正在遗忘这个知识点掌握度会明显下降。这种变化在纯历史正确率里面是体现不出来的。public double calculateMastery(Long studentId, Long knowledgePointId) { ListLearningRecord records learningRecordMapper.selectByStudentAndKp( studentId, knowledgePointId); if (records.isEmpty()) { return 0.0; } // 历史正确率 long correctCount records.stream().filter(LearningRecord::isCorrect).count(); double historyAccuracy (double) correctCount / records.size(); // 最近5次正确率 ListLearningRecord recent records.size() 5 ? records.subList(records.size() - 5, records.size()) : records; long recentCorrect recent.stream().filter(LearningRecord::isCorrect).count(); double recentAccuracy (double) recentCorrect / recent.size(); // 频次系数 double frequencyFactor records.size() 3 ? 0.7 : (records.size() 5 ? 0.85 : 1.0); return (0.6 * historyAccuracy 0.3 * recentAccuracy 0.1 * frequencyFactor) * frequencyFactor; }这个数据不仅用于推荐前端还以雷达图的形式展示给学生让学生能直观看到自己在各个知识点上的强弱分布。6.3 学情预警模块预警模块的核心逻辑是定时任务每天运行一次对所有活跃学生调用模型服务获取风险概率然后根据阈值触发预警。Component public class LearningRiskScheduler { Scheduled(cron 0 0 2 * * ?) // 每天凌晨2点执行 public void checkLearningRisk() { ListInteger activeStudentIds studentMapper.selectActiveStudentIds(); for (Integer studentId : activeStudentIds) { RiskResult risk mlServiceClient.predictLearningRisk(studentId, buildFeatures(studentId)); if (high.equals(risk.getRiskLevel())) { // 生成预警记录并通知 warningService.createWarning(studentId, risk.getRiskProbability()); } } } }预警方式我做了两档高风险发站内信 邮件给班主任中风险只记录不打扰。因为如果每个学生都给老师发消息老师很快就会麻木预警也就失去意义了。预警要的是精准不是数量。6.4 学情报告的生成学情报告本质上是把学习记录做数据聚合然后可视化。学生端可以看到自己的正确率趋势折线图、知识点掌握度雷达图、每日学习时长柱状图。技术实现上用ECharts后端通过接口提供聚合好的JSON数据。关键点是聚合SQL的效率。如果学生答题记录很多每次打开报告都实时从明细表聚合数据库压力会很大。我的做法是每天晚上定时把聚合结果写入一张daily_student_summary汇总表前端展示直接读汇总表速度极快。7. 部署上线与压测开发环境到生产环境的平滑路线系统开发完成之后就是部署环节。这一节我把从本地开发到生产的全流程走一遍很多细节如果不提前处理到了部署阶段会手忙脚乱。7.1 本地开发环境的五个进程项目本地开发时至少需要同时启动这几个服务Vue前端npm run devSpringBoot主服务IDEA里启动端口8080Python模型服务uvicorn main:app --host 0.0.0.0 --port 8000MySQL本地库端口3306Redis默认端口6379建议写一个docker-compose.yml把MySQL和Redis拉起来不用本机直接装服务避免环境污染version: 3 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root MYSQL_DATABASE: study_system ports: - 3306:3306 volumes: - mysql_data:/var/lib/mysql redis: image: redis:7.0 ports: - 6379:6379 volumes: mysql_data:7.2 生产环境的Docker编排生产环境我建议把SpringBoot服务和Python模型服务都容器化通过Docker Compose一起编排。SpringBoot的DockerfileFROM openjdk:8-jdk-alpine COPY target/study-system-1.0.0.jar /app/app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, /app/app.jar]Python模型服务的DockerfileFROM python:3.9-slim WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple COPY . /app EXPOSE 8000 CMD [uvicorn, main:app, --host, 0.0.0.0, --port, 8000]这里有个小经验Python依赖包安装时加国内镜像源否则构建镜像时下载依赖会非常慢甚至超时。7.3 容量预估与压测模型服务能支撑多少并发需要心里有数。逻辑回归模型推理一次大概在毫秒级单核CPU的FastAPI服务可以轻松支撑几百QPS。但SpringBoot到模型服务之间还有网络开销所以整个链路的瓶颈通常不在模型推理本身而在网络和业务查询。我用JMeter做过一次压测一个最简单的推荐接口SpringBootMySQL模型服务全链路单机8核16G配置下200并发跑5分钟平均响应时间约350ms无报错。这个数据对于毕设项目或者中小规模的教学辅助场景完全够用。如果要进一步优化方向是推荐结果缓存同一学生短时间内的推荐结果不要重复调模型模型服务多实例部署两个Python服务实例通过Nginx做负载均衡特征预计算把常用特征提前算好放Redis而不是每次现场聚合7.4 跨域与网关配置前后端分离部署时跨域问题几乎一定会遇到。我用一个简单的WebMvcConfigurer解决Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(Registry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }生产环境如果用了Nginx做反向代理建议把跨域交给Nginx统一处理SpringBoot层面不用开。这样更灵活也避免开发和生产环境行为不一致。8. 踩坑实录那些文档里不会写的细节与教训最后这一节我把整个开发过程中最典型的几个坑集中写出来。这些坑每一个都让我付出了实打实的时间成本写出来给后来人避避雷。8.1 特征不一致问题训练和推断必须共用一套处理逻辑这是跨语言架构里最阴险的坑。Python端训练模型时用了pandas对特征做了一系列处理比如缺失值填充、归一化、异常值截断。但SpringBoot调用模型服务时传过来的特征并没有经过同样的处理。举个例子训练时avg_response_time这个特征如果有异常值比如300秒在Python端被截断到60。但SpringBoot传过来的可能是原始值300。模型看到300这个数字预测结果完全变形。解决这个问题我用了两个办法第一所有特征处理逻辑统一放在Python端。SpringBoot只传原始行为数据如答题数、正确数、总用时Python模型服务内部负责所有特征计算和预处理。这样训练和推断的特征处理逻辑天然一致双端割裂的风险就消失了。第二在模型服务入口加特征范围校验如果传入的特征值明显超出训练时的合理范围比如正确率大于1或者小于0直接拒绝请求并提示错误而不是把脏数据喂给模型。8.2 模型文件别塞进SpringBoot的jar包我第一次做这个项目时一度想过把模型文件放在SpringBoot的resources目录下随jar包一起打进去。后来发现这是个馊主意jar包体积会变大每次打包浪费更多时间模型更新时要重新打jar包、重新部署违背了模型服务独立迭代的初衷读取classpath下的模型文件在Linux环境可能会遇到路径问题正确做法是模型文件存放在Python模型服务侧独立的模型目录甚至可以用对象存储或云盘挂载SpringBoot完全不碰模型文件。8.3 跨语言调用的编码乱码问题Java和Python之间传中文比如学生姓名、知识点名称时遇到过几次乱码。排查发现是HTTP调用时Content-Type没有指定charsetutf-8或者Python端FastAPI的响应没有显式声明UTF-8编码。解决方案很简单SpringBoot端headers.setContentType(MediaType.APPLICATION_JSON_UTF8);Python端FastAPI默认就是JSON处理正常不会出问题。但如果用了旧版本的某些库还是建议在响应模型里显式处理。总之跨语言联调第一晚先把中文传一遍避免后面带着编码问题排查业务Bug。8.4 异步任务别占满全局线程池我给项目加过定时数据清洗功能有一次发现学生正常请求接口变慢排查半天发现是定时任务把线程池占满了。原因是我在定时任务里调用了Thread.sleep()而且处理的数据量级超过了预期导致后续任务排队。这个是Java并发非常常见的坑。解决方案定时任务单独使用独立的线程池和业务请求线程池隔离批处理逻辑要控制每批处理量避免一批数据量过大Async注解要指定专用的执行器不能默认使用全局线程池8.5 推荐结果的回声效应推荐系统的经典问题。如果推荐算法只基于学生做过的题来推荐相似题目学生永远不会接触到新领域的知识——系统推荐的永远是他熟悉的东西知识点覆盖面无法扩大。我在推荐逻辑里加了一个探索策略每次推荐结果中80%来自模型推荐的精准题目20%随机从学生未接触过的知识点中抽取探索题。这样既保证练习的针对性又避免认知固化。这个比例可以调但20%是我试下来体验比较好的。8.6 模型更新时的平滑过渡模型更新不能粗暴切换。我的做法是带上模型版本号Java端调用时传model_version参数Python端根据版本号加载对应的模型文件。新模型先小流量灰度比如只对测试账号生效观察一段时间效果没问题再全量切换。一旦发现新模型效果反而更差还能在配置中心直接切换回旧版本号不需要任何代码改动。我在实际做这个系统的时候最大的一个感受是智能不一定要深不可测的算法把学习行为数据用扎实的工程方法组织起来加上合适的基础模型效果已经能超过大部分拍脑袋设计的伪智能系统。真正花时间的地方不是调参而是数据链路的设计、服务的容错和系统整体闭环的打磨。如果你正在做类似的项目我建议你也先按照诊断—推荐—干预这个闭环去拆解功能先跑通再谈优化这个顺序能帮你少走很多弯路。
阅读完成 · 觉得有帮助？
