帖子发在 bangumi https://bangumi.tv/group/topic/430934
这个持续开发了将近半年，由七个 GitHub 开源 repo，加上一个暂时还没放到 GitHub 的 repo 共同支撑的项目终于上线啦~
最开始开发的是 eplot 这个摘要网站。它是许多想法的 base. Epr （友声 Anime Episode Recommender）便是 eplot 项目的一个扩展。Eplot 的一个大缺陷是，用 LLM 生成摘要一定会有错误。而用它来做内容推荐，能极大规避 LLM 摘要错误的影响。
接下来，一方面根据 bangumi 的反馈继续开发 epr 项目。另一方面，开始考虑基于 eplot 摘要的其他可能性。
【网页】
【使用方法】
这是一个基于大语言模型 Gemini 2.5 Flash 的开源开放的番剧推荐计划。它的功能专注于番剧推荐。
使用方法很简单，在网页界面中: https://epr.oopus.info/ , 您可以选择两部您喜欢的番剧，系统就会把这两部番剧的摘要提交给 Gemini 2.5 Flash 模型，向您推荐两到三部和这两部类似的番剧。
【起因】
面向影视、书籍的推荐系统很多。我希望做一个侧重于内容相似性的推荐系统，因为内容包含的信息量相比元数据（监督、原画、风格、时代等等）更丰富。
番剧本身作为画面、时间、语言、声音等的集合，什么是「内容」，以及如何提取「内容」？这需要好好考量。我自己对语义处理更熟悉，所以把问题简化到字幕组的字幕。使用大语言模型对字幕进行总结，反推出故事的「内容」文本。
一开始的模型使用 deepseek，后来 gemini 2.5 flash 和 pro 发布，它们的汇总能力以及输出速度当时都更好，并且 gemini api 有免费的额度，于是转向 gemini，一直到现在。
解决了「内容」的问题之后，一开始想要基于 sentence embedding 做内容相似度为主，用元数据作为辅助的番剧推荐系统。这个思路的问题是，它没有办法推荐我还没收集的番剧。由于制作摘要本身耗费时间，当前的主要收录 2022 年至今 bangumi 收藏量前三的一月，四月，七月，十月番。如果推荐系统总是推那些大家都知道的番，它推荐的价值就很低。
于是试着把番剧的摘要提交给 gemini, 让它依据自己的知识来推荐。测试的结果相当好。在测试中会推荐一些特别冷门但很有道理、有趣的番。
另一个问题，包含更多细节的「内容」对推荐有价值，但把番剧过于详细的内容提交给 LLM，边际效用会递减。基于这个前提，包含足够细节的文本量，超过两部可能就太多了（input token 大概 1.5K 字左右，output token 大概 1K 字左右）。所以我把这个项目设置为只能选择两部来做推荐的模式。
【开源的技术实现】
这是查询界面：
https://github.com/sudoghut/ep-rec-interface
这是查询界面后台数据库（所有番剧摘要的数据都开放在它所 clone 的 eplot-data-compiler 项目里面）：
https://github.com/sudoghut/ep-rec-api
这是用于制作后台数据库的项目（所有生成的番剧摘要数据都在 data.db 这个 sqlite 数据库中，欢迎下载和二次开发） ：
https://github.com/sudoghut/eplot-data-compiler
这是把所有摘要展示在网页上的另一个开源项目（您可以直接在这里看到 LLM 生成的摘要，也可以使用网页查询内容）：
网页: https://eplot.oopus.info/
开源代码: https://github.com/sudoghut/eplot
这是用来轮询 Gemini token 的后端：
https://github.com/sudoghut/safe-trigger
这是排队器：
https://github.com/sudoghut/queue-single-line
因为使用免费的 token 资源，所以当前的队列长度是最多能容纳 50 个人的单线程排队。每次生成的等待时间大约是半分钟。排队的人多了可能等待时间比较久，大家可以根据当前所在队列的位置预估排到的时间。
另外，为了应对上线未知的流量，当前的 token 是从咸鱼买来的 50 个。卖家肯定有一 token 多卖的情况，当前测试的状况是一天至少会有两个 token 被封。【注意：如果大家辛苦排完队提示 token 错误，又从队尾开始排，先向大家抱歉。】建议如果在队列中，就把浏览器 tab 放一边，别故意等它。
这是用于检查 gemini api 是否被封的小工具：
https://github.com/sudoghut/token-validator
【欢迎来自您的协力】
当前这个项目因为对我自己也很有帮助，所以无论如何会至少一个人长期维护。如果您对共同维护这个项目感兴趣，也欢迎一起来维护。当前想到的贡献方式有三种。
首先，是 eplot https://github.com/sudoghut/eplot 纠错。字幕只是番剧内容的一个侧面，根据画面和声音，容易理解的剧情，但只有字幕，有时人类也可能猜错剧情，更不要说 LLM 了。在使用 eplot 的时候，如果您看到错误的剧情摘要，欢迎直接提交 pr 或者 issue 修改。一定希望提交修改后的内容，而不只是指出错误。因为指出错误之后， LLM 有时也没办法根据有限的字幕信息改对。不过剧情些许错误对 epr （推荐生成）的影响不大。
第二，番剧的 ass 字幕，有字幕轨的视频文件，或者直接贡献摘要。当前字幕文件主要从 mikan 和 dmhy 下载。感谢这两个项目！大多数是直接从有中文字幕轨（不是烧录在视频里面）的视频里面提取，一小部分字幕组提供了 ass 字幕下载。如果您感兴趣的番剧还没有被 epr 项目收录，欢迎在本帖下回复资源（番剧的 ass 字幕，有字幕轨的视频文件），或者发送站内信。
如果您熟悉 github，也欢迎直接往 eplot 项目 https://github.com/sudoghut/eplot/tree/main/src/content/blog 里面提交摘要.
文件名格式是：英文名_集数.md
内容的格式是：
---
title: "中文标题 集数"
description: "短摘要"
date: yyyy-mm-mm
tags: ["中文名", "英文名", "开播时间，格式为 yyyymm"]
---
长摘要您也直接参考已有的例子来写 md 文件：
第三，免费的 gemini token. 如果您有闲置的免费 tier （一定确认不要分享付费的 tiers）的 gemini token, 并且愿意分享，也欢迎通过站内信分享。在 safe-trigger 程序里面，设置的使用频率是不快于每分钟使用一次（当前准备了 50 个 tokens 用于轮询, 每个 token 最快也是二十五分钟使用一次。您也可以明确告诉我，希望轮询您的 token 最短的时间），每次 request 使用的 input token 数量大概是 1500，输出字数大概是 1000. 确认这样的使用下不会影响到您自己 quota 的前提下，欢迎分享。您的 token 将会只用于 epr 的番剧推荐。