这是一个新的系列,如果坚持下去我会将它单独列为一个 category。这是受到 叶弈宁 启发的一个系列,他在自己的博客里面每日更新 LLM 相关的论文 insights。他说他写 insights 的启发来自于谭院士的 博客,但谭院士的风格太过简练,我不太想效仿。
对于我来说,论文不是我现在生活最重要的一部分。所以我的 insights 更多的是面对生活,了解自己这些方向的。
之前在 xlog 写博客期间我有过公开每周总结的一个系列,随后我的每周总结变成了 self monologue,也就是每日给前一天和后一天的自己写信。这样的内容不适合公布,但这个习惯我断断续续已经坚持了有半年,算是一个很不错的 practice。
这样的对话我会记录很多细碎的细节,因为跟自己的对话没有压力,不会让我提炼最想说的。内容的冗长也就降低了日后回顾的频率,有悖我记录生活的初衷 — 为了丰富我的生活,而不是为了记录本身。
因此我现在将自己的总结重新搬回到公开空间,将适合分享的部分总结出来,每日关于我读到有趣的东西和自己的感悟整理成一天的内容,希望借助公开的压力让将每日值得记住的一些内容提炼出来。
最近最核心的工作在重新折腾 thesis 的 新实验了。有的时候真的会遇到那些表面上完全没有思路的 bug,比如模型和 tensor 都在 cuda:0 上但是报 not on the same device 的错。
Eugenio 之前提到过一个深度学习的 心得总结,其中一个就是 be with the data,从 data 的角度,流过你的 pipeline ,从参与者的角度看到问题。
最近很多的 debug 我都是依靠着这样的思路,很多时候当我真的觉得前面完全没有思路了, de 无可 de 的时候,最后的解法永远只有跟着你的数据在往前一步,再 step in 一个 function,然后再继续往前走。从数据的角度一步一步走到报错出现的地方。
前段时间看 v-jepa 的 repo,在库内使用东西的时候一切都好,但是想要在外面调用的时候就遇到问题了。匪夷所思的是,虽然已经确认安装了这个库,按照 setup.py 里面定义的库名 jepa 却怎么都调用不了它。
最后发现作者在 implement 的时候没有注意清楚 repo 的格式。对于一个 python 的项目,一般有两种目录方式,一种以库名作为源文件的文件夹名,一种则是 src/库名 的形式。
# 方式一
example_python_project
├── example_python_project
│ ├── __init__.py
│ └── something.py
└── setup.py
# 方式二
example_python_project
├── setup.py
└── src
└── example_python_project
├── __init__.py
└── something.py
这两种方式都可以被正常的识别,其中的源码也会 register 到 example_python_project 中去。但搞笑的是这个 meta 出品的库选择了两者中间 — 他使用了 src 但没有项目同名的子文件夹。这就导致他的所有源文件都 regieter 到 src 里面。
而作者将错就错,在整个 repo 里面都一直用的是 from src.xxx.xxx import xxx
这样的形式,这其实估计是他误解为一种 relative import,即从项目的根目录开始的 import。但因为大部分的命令都是在根目录下运行,所以他也没有发现问题。
但这其实是一个非常不合理的操作,我在看源码的时候也一直没意识到这个问题,直到发现在任意地方都可以以 src.xxx.xxx 的方式引用 jepa 内的库的时候,我才意识到原来在 FAIR 上班的人,也能在自己的项目里面犯如此低级的错误。
罗磊的文章《我的老婆确诊肺癌,希望能得到你的帮助》,详细记录了自己妻子确诊肺癌的过程。看着我非常的心酸,感同身受,又非常害怕类似的事情发生在我的家人身上。
因为上面的文章发现他的博客,看到了他描述自己这两年渐渐从国内互联网上脱钩的 文章,我觉得和我的心态也非常相似。除了一些无关隐私的社交媒体,以及某些完全没办法摆脱的流氓全民社交软件,我已经几乎完全从国内的互联网消失了。通过 self-host (主要方式) 和国外的替代服务,我能确保我的隐私是真的属于我的,而不是任何人可以牟利的工具,更不能成为宵小们可以随意取阅的东西。我非常感谢 oss movement 的存在,让我有这样的选择。