-
我的帖子已经打上 开源推广 标签： 是
-
我的开源项目完整开源，无未开源部分： 是
-
我的开源项目已链接认可 LINUX DO 社区： 是
-
我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
-
以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
最近用ai辅助写了一个小项目，目前还是半成品，遇到了一些问题，不知道该如何解决，故发帖请教一下
项目地址：GitHub - divisioncassini05-lab/BiliClimb: 把个人 B 站视频库整理成渐进式学习路径的 AI 辅助项目 · GitHub
项目的目标很简单，在刷b站的时候，为了避免首页的很多娱乐视频的干扰。
所以我一般喜欢手动保存一些从封面，时长，作者，播放量，标题等方面来看，有一定价值的视频。这个时候一般会用到b站自带的稍后再看的功能。
本来最初的想法只是实现可以分类的稍后再看的功能，视频大致分五个难度。也很容易实现，但后面随着想法越来越多，整个项目的复杂度也越来越高，现在对我来说已经完全是个黑箱了，我看不懂他写的代码，很难确定底层架构是不是合理，只能不断给他提要求改进这个项目。
不过有几个问题我询问ai获取解决方法，但始终无法让我满意，所以打算发此帖请教佬们的思路。
最终版的简单介绍
我的大致想法是先在b站标记一部分视频，然后导入视频库，然后调用AI来通过视频库的所有视频，用户的长期画像以及用户想成为什么样的人，每次视频的观看情况和反馈等数据，为我推荐下一个合适的视频，并给出理由。
更详细的介绍
首先是先做了一个小脚本，作用是可以直接在b站标记视频，然后可以将记录导出为JSON，然后可以导入到本地工具的视频库中。
我最初的设想是让一个模型负责所有工作，但后面发现根本不现实。然后我尝试将整个项目分为了几个独立的任务模块。
大致分为：
1. A0
前台入口，负责正常对话，可以通过它直接调用另外几个模型。体验上就与普通的聊天模型差不多，主要功能是用来记录你看完视频后的反馈，如果你在闲聊过程中有关于当前状态与长期状态的信息，它也会提取出来，然后告诉另外几个模型。
当前状态就是用户现在的状态，比如说你马上要考试了，今天很累之类的信息。
长期状态可能是你的喜好，比如说你闲聊中无意提到你很喜欢天文类的视频，你很喜欢xx博主的视频。
A0也细分为了两个模型，一个是前端的聊天模型，另一个是用于提取状态信息的模型，目的是为了节约成本，聊天模型用个差一点的，提取用户状态信息的后端模型用个稍微强一点的。
2. A1
这个模型的任务只有一个，就是总结用户的长期画像，我目前的想法是每天整理一次，每天根据当天A0整理的部分有用信息，用户观看视频后的反馈等信息来分析出用户的长期画像。
同时，A1总结的长期画像也不应该让其他模型全部都读取。
简单分为几类：
-
第一种是原始画像
-
第二种是给其他模型读取的短画像
-
第三种是证据池
这部分是我最不确定的，长期画像到底该怎么设计。
3. A2
将导入视频库的视频分类，加标签，提取视频简介的摘要生成一份videocard。
还有就是保存用户的观看记录。
4. A3
根据A2整理后的视频库，A0的现在的状态信息，A1的长期画像等信息推荐一个最合适的视频。
A3每次推荐视频也不能每次都读取完整的视频库，应该先选出初步的方向（推荐哪类的视频），然后再在筛选后的视频库里进行推荐。
5. A4
没什么好说的，根据当天状态、观看记录、推荐记录和反馈生成一份今天的复盘，单独分一个的原因是为了能和A0使用不同的模型。
工作流
先手动在b站用脚本标记一些视频，然后导出json文件，再将文件导入本地工具的视频库。
其他的操作基本都可以直接通过与A0交流完成，聊天中A0提取可能有用的信息，整理下来，当明确告诉A0，帮我推荐一个视频时则会调用A3，然后A0读取并转述给用户A3的答案。
当用户看完后有什么感想直接告诉A0后，系统会更新当前的状态，观看记录和反馈等。
不过这整个过程有非常多不成熟的地方和问题，而且很多使用上的优化我也没做完，比如说插件的视频库无法翻页，还有插件的视频库和本地工具的视频库我最初是希望能实现自动同步的，不过目前这个问题暂时被搁置了。
不过这个帖子也不是为了向佬友们展示项目的，而是想请教佬友们对整体架构设计方面的的思路。
关于这个项目更多详细的信息可以看GitHub上的介绍，GitHub上有更完整的项目说明和代码介绍，不过是codex写项目时自动写的，我就不发上来了。我并不清楚codex是否与我的原始设想完全一致，而且在这个帖子里的内容也只是我按照自己的理解做的一个概况，具体以代码为准。
首先第一个问题：有没有更成熟的个人画像 / 长期记忆架构的思路可以参考？
长期画像该如何区分稳定状态，临时状态等信息，如果每次都让A1分析所有的数据，那积累到后面输入上下文会直接爆炸，成本也会直接爆炸，那该如何精炼信息。
然后是第二个问题：这种多AI协作的工作流该如何节省token？
目前这个工作流走下来实测，token消耗会直接爆炸。我的初步设想是通过程序来完成部分本来让ai做的工作，比如说格式。
不过都只是初步设想，还有就是不同难度的问题用不同的模型，比如说A2就可以用弱一点的模型。
1 个帖子 - 1 位参与者