搓了个基于本地本子库的多模态RAG Agent（已上Dockerhub，欢迎体验）
本帖最后由 王牛子 于 2026-3-3 11:50 编辑发完这贴之后lz感觉还是不满足，感觉架构还是太草台了，比如强依赖n8n外部编排、webui是用streamlit写的，响应太慢功能也少、推荐算法太简陋。
但最重要的是，我发现其实bot完全就是个伪需求：
既然我都把推荐算法做出来了，为啥要把自己框在telegram bot这个极不方便的交互里呢？比如我想要推荐还得在telegram打字给agent，LLM没了系统就用不了，而实际上推荐算法，搜索算法是完全不需要LLM参与的，直接刷推荐瀑布流他不香吗？还能顺便进一步降低对硬件的要求。
这成为了我重构架构的主要原因。
在那之后我又踩了很多坑，把前端从streamlit重构成了Vue3, 尽量贴合最佳实践。现在的版本代码量已经膨胀到了数万行，包含 18+ 个微服务，彻底变成了一个带 WebUI、带硬核推荐算法、带独立大模型 Agent 中枢的“企业级 SaaS”应用。目前镜像已经打包推上了 DockerHub，支持 0 配置冷启动。
以下是重构后系统的核心特性
1. 抛弃现成方案，手写三场势能“物理学”推荐引擎 以前的推荐只是简单拿向量算个距离，现在我把它做成了真正的推荐流。系统会实时计算一个基于三场势能的打分器：
标签偏好场 (U_tag)：对你的历史阅读标签做频率平滑处理。
视觉聚类场 (U_vis)：用 Scikit-learn 对你最近看过的本子封面跑 KMeans 聚类，提取几个“核心审美质心”，新本子计算 L2 距离。
实时反馈动态场 (U_profile)：上面两个主要是基于半静态的阅读记录，为了实现更动态的推荐系统，我在库里维护了一个 1024 维的基础向量，你的每次操作（点击、曝光、阅读、点踩）都有不同的学习率（Alpha，比如踩是 -0.15，看是 0.05），你的 XP 向量是在实时进化的。
最后，三个场合并为总势能，套用物理学里的玻尔兹曼分布 (exp(-U_total / T)) 计算最终推荐概率。使用公式里的温度T，我添加了一个温度（探索度）的设置，调高温度 T，给你塞点新奇的私货；降低温度，就死死锁住好球区。
2. 可插拔的大模型 Agent 与“三级记忆”系统 我把 n8n 的核心编排逻辑抽回了后端，重写了一个 hunterAgent 中枢，并为它设计了三级记忆机制来防止 LLM 上下文溢出：
短期记忆：最近的高频 Tag 和点踩屏蔽 Tag。
长期记忆：大模型根据你的阅读历史总结的宏观偏好。
语义记忆 (Semantic Facts)：使用 PgVector 向量检索，只把和当前对话相关的记忆事实动态注入进 System Prompt。 你现在直接和系统内置的战术副官对话，她完全记得你的癖好，还能根据混合检索（RRF）找出来的结果，给你写包含“邀功请赏”的推荐简报。
3. “SaaS级” Vue3 仪表盘与 XP 3D地形图 没有 UI 实在太痛苦了。用 Vue3 + Vuetify 写了个完整的前端：
自带 Setup Wizard (安装向导)，支持0配置冷启动，界面甚至做了鼠标互动的动态特效（类似Apple Watch那种中间大两边小的效果）
之前 V1 做的 XP 散点图，现在不仅保留了 PCA 降维，我还上了 scipy.stats.gaussian_kde，直接把 2D 坐标算成了高斯核密度估计，在前端渲染出一个你专属的 XP 3D 潜在地形图 (Potential Surface)，你的 XP 到底是个什么形状一目了然。
为了能让我自己在移动端上用着舒服点我还加了PWA支持，启动需要经过HTTPS协议不然浏览器不会触发安装。
4. 尽力确保最高安全性与国内网络容灾 因为是要对外发布的项目，而且毕竟这要处理的数据大家懂得都懂，我在这方面下了血本，目标是就算被脱裤核心鉴权信息也不会泄露（被迫学习防御性编程）：
安全防御：拒绝脆弱的鉴权，上了 PBKDF2 + 动态 Salt + 环境变量 Pepper。前端危险设置区域必须输入密码解锁（Sudo提权机制）。生成 10 个用后即焚的恢复密钥（类2FA）单向哈希存入配置，防数据库填错导致锁死，顺便做了只有 15 分钟寿命的无状态 HMAC 签名 Token 来进应急恢复模式。
网络容灾 (针对 EH 缩略图加载)：国内看 EH 大家都懂，网络波动极大。我重写了代理层，上了幽灵加载、带互斥锁的长连接 HTTP Client。请求失败不仅会自动多级退避重试，还能动态切换 CDN（表站里站动态重试），最后把图片落入本地 Cache 缓存。
以下是系统的新架构：
目前整个应用基本已经打磨完成自用中，我自己也上传了dockerhub镜像，不再需要本地编译了，欢迎大家体验，更多技术细节，源码审阅，部署指南请参考GitHub仓库：
https://github.com/jdiosajiof/AutoEhHunter
---------------------------------------------------重构前的版本--------------------------------------------------------
lz 本来一直在寻找安卓端更好的漫画阅读器方案，最后跌跌撞撞选定了 LANraragi (后端) + Mihon (前端插件) 的组合。这套方案管理本地库确实稳而且方便使用，但当我把上千本元数据刮削完之后，发现搜索体验依然很蛋疼：
除非我把每个 Tag 都背下来，否则搜 "黑丝" 搜不出 "pantyhose"，搜 "老师" 漏掉 "tutor"，或者我我想找“那种画风很实用，剧情偏纯爱但带点重口”的本子，传统关键词搜索根本无能为力。最让我蛋疼的是Mihon 的lrr插件居然连阅读状态都不会回传给服务器，所有历史只存在手机本地，跟服务器端完全解耦，换个设备进度全丢。
正好最近在研究 n8n 和 RAG，突然想到既然现在 LLM 和多模态向量模型这么强，为什么不能给我的本子库做一个“图书管理员 Agent”？
于是花了两个礼拜，借着Opencode的辅助，也是为了测测现在的Coding Agent到底能做多复杂的项目整个压力测试，手搓了一套支持多模态检索、XP聚类分析、自动推荐的 Agent 工作流。现在发出来分享下架构细节和踩的坑。
【架构设计】
因为我本身就不咋会写代码，为了不把系统写成一坨没办法debug的垃圾，我参考了控制面/数据面的设计思路，统一IO，让AI做了很多防御性编程，这样出了问题我至少能问出来为什么，进而用自然语言进行debug，整个项目基于 Docker Compose 编排，分为三个平面，包含 5 个核心容器（LANraragi, n8n, pgvector, compute, data）：
1. 控制面 (Control Plane) - n8n
角色：大脑/指挥官。
功能：负责接收 Telegram Bot 的自然语言指令，进行意图路由（是搜图？还是看历史？还是推荐？），然后编排底层的 API 调用。
如果要改的话把业务逻辑从代码里剥离出来，改流程拖拽一下就行，不用重写后端。最近还看到个astrbot，感觉那个也可以接入，因为我项目主要是后端，电报只是层皮而已。
2. 算力面 (Compute Plane) - Python/FastAPI
角色：视觉与语言中枢。
核心模型：
SigLIP (Vision)：当时选型的时候问AI啥视觉模型比较好推荐了这个，搜了下看起来比 CLIP 强在多语言理解和细节捕捉，专门用来做“以图搜图”和“视觉特征提取”。
BGE-M3 (Text)：用来做文本 Embedding，支持多语言长文本，平时用openwebui也是必备，所以选了。
功能：提供向量化服务、XP 聚类算法（KMeans）、RRF（倒数排名融合）重排序。这里我特意把计算节点做成了无状态的，方便以后把这部分丢到显卡性能更好的机器上，实现存算分离。
粗测了一下Top10召回率，纯搜图的话封面彩页大概有个7-80%，但是非常依赖作者画风的一致性，因为我感觉SigLIP更侧重页面整体的配色和姿势而不是具体的画风。这点在搜黑白内页的时候有体现，即便我感觉画师的风格非常特别，SigLIP有时候还是会失败，Top10召回率估计在6-70%，整体来说更随机。
3. 数据面 (Data Plane) - Postgres (pgvector) + LANraragi
角色：记忆体。
功能：LANraragi 负责文件管理；Postgres 17 配合 pgvector 插件存储几十万维度的向量索引（HNSW）。放弃了 ES，直接用 PG 做向量库，运维成本低很多。正好nextcloud也用postgres，比较熟。整个库专门为EH标签做了优化，并且支持动态抓取EHTagCN标签翻译把翻译后的中文标签入库用于中文检索。
【技术干货与踩坑记录】
1. 真正的“语义搜索”：RRF 混合检索
单纯用向量搜容易搜出“意思对但字不对”的，单纯用关键词又太死板。
我上了一套 RRF (倒数排名融合)，把 SigLIP 的视觉向量结果、BGE 的文本向量结果、以及传统数据库的 Tag 匹配结果进行加权融合。
效果：即使本子没有打 "stockings" 的标，只要封面或内页里画了黑丝，SigLIP 也能把它捞出来。实际跑的时候还能定制Agent的性格，整点角色扮演，目前我给的词比较素，但qwen感觉在放飞自我方面比较在行。
2. XP年报？：KMeans + PCA
这是我觉得最好玩，也是我非常想做的功能，因为我非常好奇自己既然下了这么多本子，没个什么“年终报告”或者“XP分析”感觉没那味。我把库里所有本子的向量扔进 KMeans 聚类，然后用 PCA 降维到 2D 平面画了个散点图。
结果非常直观：
左边一坨是“同人志/剧情向”，右边一坨是“单行本/实用向”。
中间红色的聚类精准命中了我的核心 XP（比如捆绑/特定服装），连接了剧情和视觉。
听了相关专业朋友的建议还整了个“XP 进化树”，把层次聚类也加进去了，看自己是怎么从纯爱战神一步步堕落的（x
3. 解决并发竞争：Postgres 的黑科技
在写爬虫队列（eh_crawler）时，遇到了多 worker 同时抢任务的问题，具体是爬虫会写URL到文件，但EH入库那边又会读URL，入库完了会把URL删掉，那删的时候很可能就会把这之间新加入的URL给一起删掉，导致漏抓或者竞态。
本来想用 Redis 锁，后来发现 Postgres 有个神技：SELECT ... FOR UPDATE SKIP LOCKED。
直接把数据库当队列用，原子性操作，既省了 Redis 组件，又解决了并发冲突。
4. 完成数据闭环：修改 Mihon 源码
为了解决历史记录不同步的问题，我硬着头皮去改了 Mihon (Kotlin) 的LANraragi扩展的源码。现在阅读器每翻一页，都会静默上报进度到我的后端。这样 Agent 不仅知道我“存”了什么，还知道我“真正爱看”什么（而不是存了不看）。
【总结】
这项目本质上是用企业级的架构（RAG、向量数据库、微服务编排）去解决我自己的一个非常原始的需求（看本子）。
虽然代码大半是 AI 辅助写的，但架构设计、数据流转、竞态处理这些坑还是得自己一个一个填，感觉学到了不少实战经验（必可活用于下一次）。
目前这套系统已经跑通了 Telegram 对话 -> 意图识别 -> 多模态召回 -> 结果推送的完整闭环。
讲真的就tg发图，文本搜索或者是要EH推荐的时候，Agent 立刻把库里和库外画风相似或者是对我XP的本子甩我脸上的时候，那种成就感真的比改 Tag 强太多了。
不过这套系统还没有经过我的长期验证，我也不确定推荐得准不准，也欢迎大家试用之后给点反馈。
如果大家对本地向量库部署或者 n8n 工作流编排感兴趣，可以在楼里交流，以下是代码仓库：
这种项目能在面试的时候秀出来吗 勿徊哉 发表于 2026-2-19 12:06
这种项目能在面试的时候秀出来吗
当然可以。男人变态有什么错.jpg 本帖最后由 Sza 于 2026-2-19 13:58 编辑
非常有趣的项目！
我在想e站有很多版权本被删了，还有一些月刊漫画在杂志合集中没有单独上架，可能会导致仅通过标签搜不到之前看过的本。或许得在本地手工/自动补标签。
对了，是否需要加个阅读权限？ Sza 发表于 2026-2-19 14:56
非常有趣的项目！
我在想e站有很多版权本被删了，还有一些月刊漫画在杂志合集中没有单独上架，可能会导致 ...
我当年开始下本子其实就是因为我发现E站本子消失的概率还挺高的，为了回看我就养成了手动下载的习惯，不过最近感觉越来越多整个库变得不好管理了所以顺手整了个活。不过还好eh本子消失应该只是设了个标签，元数据还是能正常抓到所以问题不大 王牛子 发表于 2026-2-19 14:07
我当年开始下本子其实就是因为我发现E站本子消失的概率还挺高的，为了回看我就养成了手动下载的习惯，不 ...
长知识了 视觉特征采集的主要是封面么？
我感觉看本子tag确实不是很实用 我挑本子一半看剧情脑洞 一半看画风。前者我感觉无法用tag概括，后者则一般不会体现在tag上。
用向量数据库的话，文本应该是能做到较好的索引（不过本子的文字顺序不知道有没有成熟的方案识别?）
画风涉及多模态向量化的效果，不知道效果如何？ 我想高喊一声 lz 丝国一
—— 来自 vivo V2238A, Android 15, 鹅球 v3.5.99 刮削是什么意思 紧那罗 发表于 2026-2-19 23:46
视觉特征采集的主要是封面么？
我感觉看本子tag确实不是很实用 我挑本子一半看剧情脑洞 一半看画风。前者我 ...
剧情我目前是用VL模型随机抽内页描述剧情和场景，但质量未知，光看文本应该主要是在描述单页的场景，需要修改提示词让模型把整个剧情连贯起来。我接下来准备不随机抽取，直接按前中后固定的页码比例抽几页让模型脑补整个剧情，这样应该多少能提高点命中率，现在的文本向量更像是视觉的辅助，剧情识别不出来。 王牛子 发表于 2026-2-20 09:29
剧情我目前是用VL模型随机抽内页描述剧情和场景，但质量未知，光看文本应该主要是在描述单页的场景，需要 ...
哦 我看图上的意思就是VL模型负责生成描述文本 再用bge做文本的向量化吧，如果算力足够的话（或者换别的开销更小的OCR方案）我感觉不做抽样基于全量内容总结剧情应该效果会好很多，视觉向量也是受算力限制所以只拿了封面？ 紧那罗 发表于 2026-2-20 15:57
哦 我看图上的意思就是VL模型负责生成描述文本 再用bge做文本的向量化吧，如果算力足够的话（或者换别的 ...
是的，其实我怕的主要是上下文爆炸和截断，全量总结当然最理想，但是一次能喂给模型的图肯定是有限的，比如那些几百页的差分全喂进去不现实（倒是可以做个分流，页多的就用OCR这样，先记下了），我感觉现在抽3页内页可能是有点少，加上VL模型给的描述还是孤立的所以可能没起效。视觉向量也是个我感觉有改的地方，因为现在我本地是封面彩页+随机3页内页然后做L2平均之后写进去的，所以视觉向量实际上是全彩黑白混在一起的，可能需要写个逻辑把表改一下封面和内页分开存。 本帖最后由 魔法师lain 于 2026-2-24 08:51 编辑
本子库的话，以前下载时代感觉最困惑的是重复度高，每次cm下载都要自己整理半天，往期的又下载不了，就此轮空了很多。后来到eh时代，问题到看的东西经常被删，重复问题还是有。后来更多在dmm买了。话说没用过tg，这telegrambot究竟有什么用，直接让再下一层收自然语言不行吗？现在也在试用ai修改github上的gal启动器，在想有没更好的tag管理方法。
—— 来自 HUAWEI ALT-AL10, Android 12, 鹅球 v3.5.99 王牛子 发表于 2026-2-20 16:23
是的，其实我怕的主要是上下文爆炸和截断，全量总结当然最理想，但是一次能喂给模型的图肯定是有限的，比 ...
没必要一本本子一次全喂进去,一次几页这样我觉得就可以了,本身纸张的分页属性我觉得天然就适合做上下文拆分. 多页的问题我建议也是不要合并, 可以设计一下数据结构, 一本本子的视觉向量归集到一起, 检索的时候也按本子的粒度去重就好了(代码层面定制实现就行了, 交给AI做很简单的) 这样只记得其中一页的细节也可以搜到.
phD大佬这是真无敌了，想请教你这检索重排体系具体怎么搭建的，pg加插件实现了向量数据库，用多个查找方式提供查询结果然后再重排？可以进一步展开说说不
—— 来自 vivo V2324A, Android 15, 鹅球 v3.5.99-alpha okok123 发表于 2026-2-26 09:14
phD大佬这是真无敌了，想请教你这检索重排体系具体怎么搭建的，pg加插件实现了向量数据库，用多个查找方式 ...
底层确实是pgvector数据库，但里面的逻辑基本上是我自己的直觉加上AI辅助写出来的。主要分混合搜索和智能推荐两个场景。
搜索（特别是自然语言搜索）我做了5路并发召回：
1. 传统文本路 (Text & EH_Text)：标题模糊匹配（ILIKE）+ 标签匹配（使用 LLM 提取意图标签并模糊映射到本地热门标签）。
2. 语义向量路 (Desc)：通过 LLM 生成查询词的 Embedding，使用 pgvector 的 <=> 操作符对图库简介/文本进行余弦相似度检索。
3. 视觉跨模态路 (Visual & EH_Visual)：借助本地的 SigLIP 模型，直接把用户的搜索词（如“黑发 双马尾”）转成图像向量，去跨模态比对数据库里的本子封面（cover_embedding）。
拿到 5 路结果后，我没有依赖现成的框架，而是手写了一个带权重的RRF算法。系统会根据用户当前的搜索场景（看重画风 visual、看重剧情 plot 还是 mixed）动态调整这 5 路的权重，最后倒数相加计算出最终得分进行截断。不过目前这些权重主要还是基于经验设置，将来可以研究一下动态权重。
推荐体系这边可能要更复杂一点，我写了一个基于三场势能的打分器。
首先，系统会拉取你过去一段时间的阅读历史和库存，动态生成你的“XP 画像”：
视觉审美偏好 (U_vis)：用 scikit-learn 对你最近看过的本子封面向量跑 KMeans 聚类，提取出你的几个“核心审美质心 (Centroids)”。候选本子计算离最近质心的 L2 距离。
标签偏好 (U_tag)：对历史标签进行频率统计和平滑处理，算出一个匹配得分。
实时反馈动态场 (U_profile)：这是个很关键的机制。系统会在库里为你维护一个 1024 维的 base_vector。你的每次操作（点击、曝光、阅读、点踩 dislike）都会带有不同的学习率（Alpha，比如 dislike 是 -0.15，click 是 0.05）。系统会实时把封面向量按权重更新到你的基础向量上（类似动量更新）。候选本子再跟这个基础向量算余弦相似度。
这三项会被合并成一个总势能 (U_total)。我引入了物理学里的玻尔兹曼分布 (exp(-U_total / T)) 来计算最终概率。 这里的 T 就是温度参数 (Temperature)。这个温度很好的平衡了探索和精准锁定的问题，如果调高温度降低能量截断阈值，那系统可能推荐一些平时你可能不怎么看、但沾点边的本子；如果降低温度，那系统就会死死锁住你的好球区，但实际上因为XP建模不是那么精确，所以一般来说不推荐把温度调得太低，一样会失准。
总结一下就是PGVector 解决底层的距离计算，业务层用 RRF 解决多模态搜索融合，用 KMeans + 实时反馈向量 + 玻尔兹曼温度机制 解决千人千面的推荐 哇塞
—— 来自 Xiaomi 24129PN74C, Android 16, 鹅球 v3.5.99 只会撸管的我弱爆了
我愿尊你为JBKing!
回家部署看看
—— 来自 鹅球 v3.3.96-alpha 瑟瑟是第一生产力 JBKing！ 很不错的项目，关于元数据是存储在lanraragi吗，有没有考虑过直接写入压缩包里，感觉这样会更加适合分享一些 PalmTiger 发表于 2026-2-28 11:42
很不错的项目，关于元数据是存储在lanraragi吗，有没有考虑过直接写入压缩包里，感觉这样会更加适合分享一 ...
元数据是从LANraragi，借用那边的刮削工具先写入他那边的数据库，然后我再调他的API，打印成jsonl，再入我这边的库，不考虑写压缩包，太分散了。将来准备慢慢移除对外部图库的依赖，做成一个独立的阅读器。特别是我感觉LANraragi架构确实比较老了，并且CBZ也有性能问题，边看边解压不光CPU占用高，流式阅读的体验还很差，我准备换一个更先进的格式（https://github.com/ef1500/libbbf)，同时做一个旧的CBZ和ZIP兼容模式来彻底解决这个问题 元数据直接写入库的问题是如果本子结构或者格式变了是不是又要再刮削一遍？我之前普通的漫画库从kavita迁到komga就很麻烦，直接写个comicinfo.xml丢cbz里就会好些。不过如果元数据不够完善需要维护也是一个麻烦的地方 谁说大头不能控制小头
给学术牛子star了，研究一下让龙虾给我搞个每周推荐
PalmTiger 发表于 2026-2-28 11:52
元数据直接写入库的问题是如果本子结构或者格式变了是不是又要再刮削一遍？我之前普通的漫画库从kavita迁到 ...
对，这是LANraragi那边的限制，所以这就是为啥我想着慢慢收拢到我这个主容器，更方便管理。因为我这个容器里面为了从EH获取信息，也有调用API，用里站token的逻辑，所以动态更新不是不能做。不过你提的很有道理，我应该会加一个迁移时统一写入标准化comicinfo.xml的逻辑，方便搞到其他平台 王牛子 发表于 2026-2-20 16:23
是的，其实我怕的主要是上下文爆炸和截断，全量总结当然最理想，但是一次能喂给模型的图肯定是有限的，比 ...
respect
封面和内页权重可能还需要根据页码的大小统计一下得出个优选值，随机的话那些200页+的出版类很可能采样失真了，毕竟是多章节的
另外VL这部分abliterated模型推荐使用哪个作本地部署？手头只有一块4090 漫画就是压缩包，比如zip的扔LANraragi 目录然后让工程自己去扫压缩包里的头几页确认大概的内容类型以及去抓e站的数据? 流缨 发表于 2026-2-28 12:12
respect
封面和内页权重可能还需要根据页码的大小统计一下得出个优选值，随机的话那些200页+的出版类很 ...
这就是为什么我现在在做阅读器，如果有了阅读器，那这个容器就能收集你的每页阅读时间方差，然后VL入库就可以挑你阅读的时候停留时间长的页面，直接把用户当成数据飞轮（反正这套系统纯本地，也没所谓数据收集的范围，我准备all in了，能搜集多少就多少）。VL完全看你心情，我用的huihuiai的qwen3-8B-VL，你要是想详细一点可以换更大的
完整版大概会长下面这样：
total_dwell_s (INT): 总阅读停留秒数。
completion_rate (FLOAT): 完成率（阅读页数 / 总页数）。
bounce_page_idx (INT): 跳出页码。如果用户在第 5 页关掉，和在第 30 页关掉，代表的排斥力（斥力源）是完全不同的。
session_type (VARCHAR): 阅读类型。是通过推荐点进来的（recommend），还是主动搜索的（search），这决定了该行为权重的可信度。
2. 微观浏览行为
这是未来我做“帧级别视觉 RAG”的核心，因为看本子最大的特点是非线性阅阅读，用户会在某些页面一扫而过（过场剧情），而在某些页面长久停留（核心 XP 场景）。
page_dwell_map (JSONB): 页面停留热力映射，每页停多久。
pace_variance (FLOAT): 阅读节奏方差。
计算每页停留时长的统计方差。方差极小，说明是平铺直叙地看剧情；方差极大，说明是在“精准空降”找施法材料。这可以直接作为聚类分析（KDE）的一个重要维度。
jump_paths (JSONB): 跳跃路径记录。
专门记录用户拖动进度条的行为。大跨度的跳跃通常意味着对当前剧情的不耐烦（强斥力）。
3. 物理交互与拓扑级
这部分数据暂时属于预留，但如果未来接入更高级的视觉模型（如目标检测 YOLO 或更精细的 VL大模型），就有用了。
zoom_events (JSONB): 局部放大事件。
如果在特定画面的某个坐标（比如特写镜头、特定部位）发生了高频缩放，这不仅是对该页面的喜欢，更是对该画面局部特征的极度关注。
device_orientation (VARCHAR): portrait 或 landscape。
横屏往往是双页阅读，竖屏是单页。这影响计算翻页速度时的标准化折算。
read_direction (VARCHAR): LTR, RTL, Vertical（条漫）。 zerona 发表于 2026-2-28 11:29
漫画就是压缩包，比如zip的扔LANraragi 目录然后让工程自己去扫压缩包里的头几页确认大概的内容类型以及去 ...
不用前几页，用其中一页做sha1去ex就能直接搜出来对应的gallery
—— 来自 鹅球 v3.5.99 王牛子 发表于 2026-2-28 11:59
这就是为什么我现在在做阅读器，如果有了阅读器，那这个容器就能收集你的每页阅读时间方差，然后VL入库就 ...
果然天下推荐算法殊途同归，听起来就是现在购物类和内容类产品的推荐逻辑迫真小H书
此外似乎没有看到作品年代和作者标签的处理逻辑，这种较大层面上的分类和标签是否更难量化到目前的推荐算法中？
—— 来自 vivo V2309A, Android 16, 鹅球 v3.5.99
页:
[1]