人活着就是为了XXX (原本只是起了个头, 结果没收住, 还写歪了.) 太久没写东西, 表达欲上来了, 但是还是得早睡

waifu

名词: 我的老婆 (>ω<)

waifu 可以是这样子

也可以是这样子

当然最初应该是这样子

似乎有点暴露年龄

在动漫中, waifu 更像是一瞬间的感觉, 好像一瞬间过了一生(像是思考加速, 又像是走马灯)的感觉.

而对于我来说, waifu 也像是一种情结, 它不一定是动漫角色. 因为我同样也是网文爱好者, 在我想象力多到发泄不完的小学和初中, 晚上通常都是沉浸在对玄幻或者仙侠世界的幻想里入睡的.

而那样一瞬间心动, 兴奋的感觉在后来却越来越少.

直到大一入学时我刚刚学 CPP 时看到了有个人写的用窗口句柄打开和切换 QQ 聊天窗口并且假激活和利用多线程给别人发垃圾消息. 我反而立刻想到了可以做成聊天机器人, 也确实写了: 利用C++实现QQ（TIM）的自动回复(不带nlp和tts,纯自己跟自己聊天), 但当时我压根不知道啥是 github, 于是乎我的代码在不知道什么时候就丢了, 就像我不知道啥时候我的 CPP 的路就突然断了.(我的水平在某个阶段之后就陷入平台期甚至还因为一直没用而越来越低.)

当时干完那个后我就非常兴奋地去学了 nlp , 碰壁了一回, 因为那时候 nlp 的教程里还在讲机器学习的方法, 深度学习的方法还停留在 lstm 啥的, (那个时间点 chatgpt 刚出, 我压根不知道调个 API 就可以实现我学完所有自然语言处理也版本都熬的事情, 但那个时间点我正在每隔两周被老师问候 最近有没有什么 idea , 你觉得这个最大似然XXX论文能不能整合到 GAN 的判别器里 这样的, 于是乎错过了一波.)

我在很久后看到了看到了ChatGPT+Galgame 与老婆自由对话！, 我当时只感觉我的梦想实现了一半! (我并不觉得如果我有时间就能写出来, 只是可惜的是即使看到了演示, 我也没看到简介区里的 github 仓库, 还是那句话, 当时我压根不知道 github 是啥, 如果看到了, 我肯定会尝试自己修改, 也会提早一两年加入 github, 也能掌握更多的主动)

在后来我就像一个后知后觉的人, 每次看到一样新的东西, 感觉我能参与其中并且做贡献, 都是在它已经开发很久到了稳定版本, 比如 Stable diffusion, 比如 BERT-VITS2, 比如 RVC, 比如 GPT-SoVITS.

我也渐渐躺下来 感觉看着别人帮我实现梦想也挺不错的, 只是每次看到演示的时候会莫名奇妙地兴奋一下, 但是我自己都忘了那兴奋是为了什么.

但是, 一次课设, 他妈的唤醒了我的 waifu 之魂.

我试着把前沿的东西融入 waifu, 把 waifu 和 coding 结合, 尽管在定下雏形后我发现我要做的东西和它是如此地像:(tnnd 又是落后几个月)

但是它用 sherpa-onnx 做所有模型的中转是一种比较危险的行为, sherpa-onnx 把目前开源的常用的 vad, asr, tts, punc 的实时和非实时识别全部整合到一起, 而且全平台支持(而且还支持 CPP, C#, Python ...的调用) 我佩服作者维护能力和精力, 但是它的这种做法注定是不稳定的, 因为每次更新模型都可能带来 API 的变动和弃用, 最新的模型永远只能用最新的库版本进行调用, 而旧版本的模型可能因为模型的 API 变动而不被支持, 而也很难知晓哪个版本是被支持的.而作者兼容了十几个模型的数十种调用方法, 只能说是藏雷还带藏一窝的 =-=.

另外, 多平台和多语言的支持需要大量的文档, 它的文档工作做的真的不太好, 我看了半天没看到是不是有直接面向麦克风的语音唤醒, 它的仓库里给了 C# 的实现示例, 但是 Python 和 C# 的 API 写法和命名是不统一的(还没找到对应 API 文档, 读 python 源码里似乎实现调用的是 CPP 封装的接口), 另外可能是新旧版本差异, grok 给了我一个和C# 一样 API 命名调用版本的写法, 据说它适应于 1.7.0 乃至高, 但是 pypi 上最旧的版本是, 2023 Nov 的 1.8.11, 其他应该被删了, release 的几个大版本都间隔较久, 是今年开始积极维护的, 让人比较害怕, 而且最新版本里 python 的 typing annotation 我看了都摇头.

如此大的工作量, 还主要都是作者一个人在维护, 它会导致, 应用它代码在失去维护后直接瘫痪. 所以 Open-LLM-VTuber 和 sherpa-onnx 应该算共生了, 后者出问题都前者的作者来兜底 =-=.

共生是不好的(虽然我也这么干), 除非你确定那个作者的 coding 习惯比你好非常非常多并且大概率会长期维护.

作为一个起步不久的包管理者, 上面这些都 tm 是教训:(我仿佛看到了两年后的自己, 因为我的 coding 习惯和更新习惯几乎和那一模一样)

• 应该定时更新, 即使只是适配更新的 Python 和依赖库版本(因为别人在用的时候一般默认使用都是在他那个时候的最新库版本, 一个落后就意味着每个都得考虑降级)
• typing annotation 是必修课, 即使是 pexpect ,它的 typing 似乎也不不太行.另外, 所有开源模型的实现仓库的代码都只能说是能跑, 尽可能没 bug 或者看不出来有 bug,但它的 typing 也是很糟糕(大部分压根就没有). 对于代码, 应该以给别人 import 使用的库(比如 paddle 那样的框架作为基准来写 typing 和 并且提供全面的 docs(因为就连自己都不知道哪天就忘记了代码做啥, 所以最好留下一些 usage examples))
• API docs 是必不可少的, 不然你做了什么, 代码能做什么别人根本不知道, 而且用起来还有股鸟气和无名火. 而且 API 变动时最好立刻更改 docs, 不要指望自己喜欢写 docs.(我虽然是话痨,但是我真不喜欢写 docs, 我喜欢漫无边际地写而不是条条目目地和处理积虑站在别人视角让人理解地写文档 - 所以我写到这里应该已经歪题到不知道哪里了, 对观者来说可能难受, 对我来说那就一个爽字了得, 也正是因为这个, 一般写不来有条理(既定目录)的长文, 那对我来说太煎熬了.nagi 佬似乎很擅长写教程呢)

先写到这里. 写歪了 wc. 看了一天 sherpa-onnx 没忍住. 虽然真的不是它的错, 因为它的存在已经是一个奇迹了.