关于故事生成微调：

由于完全没有接触过大语言模型，微调这些东西，所以上半学期做的非常难受，在网上各种调研看教学视频，最终选择了北理开发的llama-factory微调平台，以及在HuggingFace上下载的deepseek-r1-7B-distrill蒸馏版本作为模型本体。我在autoDL上租了3090服务器用来放模型本体，微调平台并利用显卡来进行微调训练。我们的故事微调功能的目的是结合包含大量故事的数据集，每日自动生成一个由当日推荐单词串联而成的趣味故事，通过故事化的记忆方式增强单词的语境关联性，用寓教于乐的形式帮助用户更高效地掌握词汇。因此我们选择开源的ROC_Story数据集，它包含10 万个英文日常的故事，都是经过作者团队挑选的包含了日常事件之间常见的因果和时序关系的故事，我们的任务是故事生成，我们尝试了使用三种方式用于数据清洗构造微调数据集：1.从每个故事中随机挑选关键词，2.基于词性（名词、动词、形容词）和去重规则挑选关键词，3.在完整的故事中随机删除一句话，引导模型推测缺失的情节。对于三种方式我们都保留了词性，复数，时态等等，以保持数据的多样性，但是这三种方式都会出现过拟合，deepseek的深度思考没了，并且返回的故事格式总跟我们的故事格式完全一致，并且经常出现无意义的单词重复，最终我们取2000条故事进行训练，并且混合我们上面的后两种数据集，分阶段训练：第一阶段是给故事情节，让模型预测故事结局，让模型学习故事的连贯性和情感；第二阶段是引导模型根据关键词生成完整故事，教会模型怎么在生成故事的时候自然的使用单词，最终的效果还可以。

关于多分支互动性故事优化：

但是这样生成故事实在是太无聊了，我希望能增加一些新意，有时候我会刷一些短视频，经常刷到一些解谜小游戏，根据用户的选择，会走向不同结局，受这种模式的启发，我将每日故事生成优化成了一种多分支互动性故事，这样的设计能够让用户觉得结局的走向和自己的选择是有关系的，进一步提升代入感，我们选择使用prompt工程来实现这种多分支故事：设计三种prompt分别是开头，分支，结局，其中开头和分支要结合给定的关键词，根据用户登录时选择的词汇书自动匹配难度（四级对应简单，六级对应中等，雅思对应困难），对于开头和分支还要生成供用户选择的选项，每次选择后会将用户选择和之前已生成的故事内容加入prompt中为模型提供语境信息，如果用户选择次数达到阈值并且故事中已经包含全部关键词时，就生成结局。

关于故事场景图像生成（微调扩散模型）：

但这样可能一个页面上会显示一个很长的故事，因此为了优化用户体验我设置成分页生成，控制一次性生成的长度；这样设计之后，就非常适合给每个故事页面添加一个场景图片，我又去调研图像生成模型微调，这里微调是因为扩散模型它生成的图像质量不稳定，并且风格不一致，我们还是希望这个故事的每个页面能生成风格差不多的图片，最终选择了开源的扩散模型Stable-Diffusion，并且由于llama-factory这个微调平台限制很多，比如它的损失函数固定，很多东西不透明，所以这一次我们选择用代码进行微调，我们选择用信噪比加权的均方误差损失（早期时间步（高噪声）：权重较小，避免过度关注噪声；后期时间步（低噪声）：权重较大，更关注细节重建），我们使用开源的宝可梦数据集，用CLIP模型生成图像对应的文字描述，构造了一个包含833张图片和对应文字描述的数据集，用于微调训练。这个过程也是比较耗时，最终选择1500轮的权重，因为我发现2000轮可能有点过拟合，生成的图像就有点不成样子了。我其实还尝试了分开生产场景和人物图像，因为有时特定的故事情节会导致扩散模型生成非常混乱的图像，场景和人物的风格不一致，并且有时还有对话框，乱码等等，最后还是选了一个比较稳定的。

场景图片通过扩散模型生成后，以base64编码形式存储在数据库。

关于AutoDL端口映射：

另外autoDL不允许本地直接访问它的云服务器端口，所以需要将本地端口映射到云服务器才能实现前后端交互，我们这里现在本机配置了端口映射，然后在main.py用fastAPI设置了交互方法。

因为这个大模型他比较大，我又用了微调平台，模型本体，CLIP这些模型，所以经常出现内存不足，就需要清理系统盘或者租一个新的服务器，期中的时候nips截稿那段时间前autoDL基本就是天天GPU不足，我还得复制到一个新显卡上才能启动,加上我这个微调过程比较多，它3090是1.66一小时，我一共花了130多。

关于前端界面设计和多功能实现：

然后是前后端开发，在故事页面，翻页，用户选择这些的基础上，我给前端又加了英文语音播放，显示中文翻译这些功能，并设置了逐词显示英文内容（打字机效果，按空格可以直接显示全部内容），关键词高亮，关键词超链接跳转单词详情页等功能。

关于故事预生成功能，前后端开发和数据库建表：

然而故事生成功能有点太慢了，这一方面是由于本地和云服务器的连接和Deepseek的深度思考功能，一方面是扩散模型生成高质量图像需要较长时间，用户在等待故事生成时需要等待很长时间，严重影响用户体验。因此我们在原有故事生成基础上增加了故事预生成功能，用户登录时自动触发，使用递归算法一次性生成所有可能的故事分支，我在数据库里建了三个表格来记录故事模板，故事页面，用户故事进度。这样实现：
1.能让用户无需等待直接查看已在数据库中保存的故事模板，并且能记录用户在每个故事的阅读进度；
2.将故事按页存储，每页由扩散模型生成一个场景图片，能更加充分利用扩散模型，并且图片的情景不会太复杂，方便用户阅读，也更加符合逻辑；
3.有充分的时间能够对数据库中的故事文本和图片做进一步优化和改进。
并且增加了故事模板列表界面的前后端，用来保存用户生成过的所有故事模板，可以随时查看和回忆。

关于公众号功能前后端开发：

最后为优化用户体验，我们将通过微信公众号提供多项学习辅助功能，帮助用户更便捷地查看学习进度并提升学习效率。在开发过程中由于个人公众号功能不全，目前对于学生来说难以进行企业认证，于是便使用接口测试号进行开发与调试。四个核心功能：
1.今日学习查询: 用户可以快速查看他们当天学习的单词。
2.学习进度查询: 提供用户整体学习进度的全面概览，包括可视化进度条和复习提醒。
3.用户信息管理: 允许用户查看他们的设置，并且管理员可以查询特定用户的详细信息。
4.帮助系统: 用户可以通过简单的方式发现所有可用的命令。
集成微信 SDK，创建 WeixinController通过签名检查（GET 请求）验证来自微信的请求，以确保其真实性；接收用户消息（POST 请求）。 当消息传入时，它是 XML 格式的。我们解析它来理解用户发送了什么——特别是消息内容及其类型，例如‘文本’消息。”所有功能中都使用buildMessageTextEntity将准备好的内容字符串包装成微信期望的文本消息的正确 XML 结构。