对 AI Safety / AI open source 以及 large scale AI deployment 的看法
Q: 大家觉得， 人类接下来五年能实现的 super intelligence 到底能有多强，以及它到底是有多大程度的 safety concern?
研究员1：保守估计从去年这个时候到现在一年时间已经intelligence提升是2倍，那么2的5次方就是32倍
研究员2：目前认为safety是一种幻觉，当AI智力突破临界值后，是不存在可靠的手段产生“safety”的
研究员3：AI 对于人类的影线也不一定是完全的，可能是局部的，比如说，如果模型在某些特定疾病上 halluscinate 但在其他疾病上极为精准，那么人类可能会因为模型在其他疾病上都很精准所以对模型有足够的信任，但是刚好就是有那一种病的人遭殃；然后，AI 对人类的影响也不一定是在时间维度是上局部的，它也可能是代际的。比如说，如果 2010 年生下来这一代人精神上只想跟 character 谈恋爱，肉体上过几年各种娃娃也造得很真；然后再来个 Sam 给你发 UBI，国内发低保，那可能他们这一代人就比我们这一代更不想繁衍了。刘慈欣在一次 talk 上也讲了这个观点；再然后，当 AI 的能力到了一定程度之后，它就有自我进化的可能，如果 AI 可以自我演化那就没人类什么事了。
研究员4：OAI 做过演化的研究 https://openai.com/research/evolution-through-large-models。
是否有一种轻量方法可以动态压缩序列，在不考虑工程的情况下，可以大幅降低计算复杂度
研究员1： https://arxiv.org/abs/2305.11170 之前做过一个压缩prompt的，不过不是压缩hidden state
研究员2： 如果指的是prompt compression, LLMLingua 做的是类似的事，如果考虑在hidden上做，确实somehow和稀疏attention，LongNet这种很像，不过如果考虑到 lost in the middle, 目前认为是觉得非常有必要做某种denoise，（如果把context windows 比如RAM，那一定有L1, L2）
研究员3： 目前认为把 retrieval 也直接接上，like 原先的 retrieval 都是用小模型产生 embedding，可以直接用大模型本身把 memory encode 成 embedding
论文分享
1.《Transformer升级之路：15、Key归一化助力长度外推》https://kexue.fm/archives/9859
本文介绍了笔者意外发现的一种长度外推方案“KeyNorm”——对Attention的Key序列进行L2归一化，在训练长度上取得了更好的效果，并在长度外推方面表现出显著的提升。它属于“事前修改”方案，跟其他事前修改方案如ALIBI、KERPLE等相比，它没有Local约束，因此更有希望能够Scale Up；相比于NTK-RoPE、YaRN等“事后修改”方案，它在外推的时候则不会损失训练长度内的性能。 https://mp.weixin.qq.com/s/qSJCNCH433EbF7Khr0FYrg
2. Improving Stability of Fine-Tuning Pretrained Language Models via component-Wise Gradient Norm Clipping
如果supervised finetuning多次跑结果不稳定，EMNLP提到过一个优化解决方法(虽然只是做在bert上，但大的model这个问题并不会解决，因为这是optimization的问题): https://arxiv.org/pdf/2210.10325
简单结论: 想要更好的稳定性，又不想损失performance，最简单的建议试试适当加一点gradient norm。
3. https://github.com/shuyhere/about-super-alignment 整理了关于superalignment时间线和reading list
4. Detecting Pretraining Data from Large Language Models
https://swj0419.github.io/detect-pretrain.github.io/
讨论&杂谈
D(Discussion): deepmind的这篇工作发表时，被发现召回向量长度太短了，无法捕捉全局内容，因此目前研究员们想找一种方法对隐状态压缩，提升RAG效果 Improving language models by retrieving from trillions of tokens https://arxiv.org/abs/2112.04426
F(Follow): 目前认为这是 retrieval 的一个问题，就是现在的模型都是把一个句子，几十个词，match 到一个段落，几百个词那种；但是有时候想要的是 8k 和 8k 的 match; 但现在的 embedding model 不大能 encode 8k 这么长的 doc ，之前试过 Jina，虽然号称 8k，但是效果堪忧。
D: Claude 2.1 (200K Tokens) 上下文信息提取能力表现测试 https://x.com/GregKamradt/status/1727018183608193393?s=20 * 在 200K Tokens（近 470 页）下，Claude 2.1 能从召回事实。* 在上下文最顶部和最底部的信息以几乎 100% 的准确率被召回。* 位于上下文最顶部的信息，相较于下面，召回难度偏高，这点类似 GPT-4。* 从 ~90K Tokens 开始，上下文底部的召回性能开始变得越来越差。* 在上下文不多的时候，模型的性能不像 GPT-4 那样稳定。
D: Medusa 这个框架比 lookahead decoding 更早出来也非常值得一看 https://github.com/FasterDecoding/Medusa
F: https://www.together.ai/blog/together-inference-engine-v1 这里还有个商业版 里面提到没有用量化，但是有一个table能看出来精度有波动，合理推测应该是加了Medusa
F1: https://inflection.ai/inflection-2
D: 一个观点：好的长上下文语言模型应该能模拟一个数据库，给一个表，以及若干增删改查的操作，让语言模型输出此时数据库的状态以及进行其他sql查询，其结果应该尽可能等同于sqlite里建表并执行增删改查的结果。这个模拟能考察模型跟踪状态以及进行大量简单推理的能力
F: 这个只需要大模型有处理局域信息的能力，相对来说可能还是太简单了。long context用户需求主要还是需要模型处理非局域信息，例如整体摘要，差异还是比较大
F1: 直接丢一个表的数据，求某一列的均值，妥妥非局域信息啊。这个观点的精妙之处目前的理解在于构造sft数据和测试长窗口性能都可以自动化，不用人参与太多过程。
F2: 这个最大的优势就是可以自动化评估，说明不少可能存在的问题。但目前认为的是这个评估指标（衡量长上下文模型的局域能力）和模型满足用户需求的能力的相关性不是特别大
F3: https://arxiv.org/abs/2310.16135 这篇emnlp其实就在做非常简单的random I/O测试，只有read和write，多点查询直接崩，而且就算是看上去对的responsemodel也可能follow了非常诡异的update过程(right for the wrong reason)，这个倾向性会随着update变多/context变长而更加明显
简短问答
Q: 想问现在transformer在设计hiddensize, number heads, 其他超参的时候除了考虑infrastructure还有没有别的考虑?
A: 还有位置嵌入的超参，比如考虑上下文调整rope的参数
Q: 目前用 trl.SFTTrainer finetune Vicuna，用相同的数据相同的参数 finetune，发现设置了：torch.manual_seed(42) random.seed(42) 之后，这个 finetune 得到的 ckpt evaluate 仍旧不稳定。每次重新用相同的 dataset 去 finetune，差距非常大。该如何确保自己的 finetune 稳定呢？
A: 如果gpu上有randomness的操作要一个 torch.cuda.manual_seed(42).
Q: 有没有什么比较好的文章研究模型的 memorization ，背数据到底能背多厉害? 感觉现在 scale up 的性能提升蛮多就是因为模型背答案。
A: (1) https://arxiv.org/abs/2310.16789 Detecting Pretraining Data from Large Language Models & https://arxiv.org/abs/2202.07646 (2) http://arxiv.org/abs/2311.04850 这篇也不错
Q: 怀疑phi model有pretrain on benchmark-like data的嫌疑？
A: 感觉deepseek 1B instruct比phi的结果还离谱很多
A1: deepseek肯定没有刻意pretrain on benchmark-like data的嫌疑，但至于是否存在一些test集合天然分布在train里面，没有刻意处理（比如有一些GitHub上有一些leetcode的题解等），目前觉得这其实也是一部分知识，不应该因为潜在的benchmark包含就排除在pretrain data之外。真正要做的应该是用更新的泛化更好的benchmark测，比如用leetcode的定期新出的周赛题
F: 谢谢解答！目前通过一些example里试过deepseek coder然后确实效果很好所以会很好奇2B instruction data的insight 因为-instruct version对比base model的提升再各个benchmark上也很明显
Q: 有哪篇论文讲对LLM输入一些negative word但取得好效果的吗?
A: https://arxiv.org/pdf/2307.11760.pdf & https://arxiv.org/pdf/2311.07590.pdf
Q: 请问大家有了解模型hidden state序列动态压缩的技术吗？比如对于10个token的句子，如果其信息量很大，则隐状态序列长度仍然保持为10，但是如果其信息量很低，则通过一些算法把隐状态序列长度压缩（例如压缩到3）
A: https://arxiv.org/abs/2305.14788 不过这个不是选择性压缩 压缩后的大小是超参数确定的
Q: 能从原理去解释下 VLLM 的表现呢？使用 4 卡 80G A800 满血做 sft 后 的 vicuna 的 inference，10000 条耗时 24 分钟。然而同样的 dataset，用 2 卡 80G A800 满血做没有 finetune 的 vicuna 的 inference，耗时 15 分钟。反而更快了?
A: 可以nvtop看一下 有时候utilization是100%但是卡的功率上不去 比如90/350W这种可能就是卡在了通信上
A2: nsys profile看看, a800只有400g, 多卡拆分，通信带宽消耗更大, io导致的放空时间更长
A3: 如果消耗的算力不大，卡少可减少通信开耗, 一般会平均分配算力，相当于大家都吃不饱还来回交换数据，自然更慢, 多卡如果能并行算，最后合并，估计能快。现在的大模型是拆分，因为显存不够，多卡效率挺低的.
A4: PCIe 是所有卡抢占 64 GB/s CPU/GPU 传输输入数据也是一起抢占的。通信瓶颈的话，卡越多越慢。 NVLink 是可以 8卡两两同时打满 160GB/s 的。
A5: PCIE版，搭满三个桥才能work
Q: 请问大家是否知道如何在某张指定的 cuda 上面启动 vllm 么? 不是通过设置环境变量, 就是传参数。
A: 可以自己写个参数 传进去用os.environ
Q: 想请教下大家SFT训练相关的问题，如果用了learning rate decay（最后一个step变成0），然后evaluation的时候发现多训一些step可能还有提升，这时候一般怎么操作，是只能从头训嘛？
A: 减少学习率，继续train,可以采用1/10，1/20这种初始学习率设定, 这种情况下，loss曲线一般会开始时略微上升，但很快就降下去了
Q: Sky work放出了一些中文验证集数据但是没有放英文的，想问下英文也是按照中文这种方式得到不同领域验证集的吗？只通过验证集loss就能判断出在下游任务的好坏吗？
A: 英文找了多个 domain 的一些最新数据作为 Validation set，比如 23年9月之后的 arxiv 文章之类的。Validation loss 肯定还不能完全反应下游任务的好坏，但在不少场景中都有相关性。 而且 Validation loss 是一个比 downstream task 更鲁棒的评估方式，因为其变化是连续的。
Q: 可以解释下silent data corruption么？
A: 简单来说就是cpu/gpu偶尔把“1+1算成了3”，单个芯片的sdc概率很低，但在成千上万张卡scale的训练下就几乎不可避免，从而影响收敛（比如出现spike）
A1: Google有一篇关于CPU的很有名：https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s01-hochschild.pdf 所有芯片包括GPU/TPU也都有这种问题 不可避免
A2: https://arxiv.org/abs/2102.11245
A3: 传统的sdc主要是data store/transfer的bit flip可以通过一些coding方法解决 但现在面临的challenge是计算单元也有sdc 这些目前几乎还是无解 大都是通过一些resilience/detection的方法缓着
Q: planning应该是一个inference-time (search) algorithm，还是应该是train的时候就加入?
A: 像人类的慢思维和快思维一样, search靠计算，train靠感觉, 目前认为更好还是借助外部的tool
A1: 目前认为就是retro那个idea, memory和reasoning分开