Review

The recent “Dawn of the East” hype around Manus.im sparked significant attention. However, its evolution over the past few days has been dramatic, with numerous open-source projects attempting to replicate it. OpenManus, one of the earliest clones, claims to have replicated it in just 3 hours, though its parent team MetaGPT has been working on agents for much longer. I believe both impressive performances and failures are normal at this early industry stage....

前几天号称“东方破晓”的Manus.im着实火了一把。但这几天的演进也充满戏剧性，已经有一大堆开源项目来复刻他们。OpenManus算是比较早的一个，号称3小时就复刻了，但其实他们背后的MetaGPT团队已经搞Agent很久了。我感觉目前的产品惊艳或者翻车都很正常，整个行业才刚开始。但OpenManus这样的项目是一个很不错的学习Agent开发的切入点，它足够简单，也覆盖了足够多的东西。这篇文章是我的一个学习笔记外加一些思考，跟大家交流。 事先说明，开源代码库变化很快，我是2025年3月7号下载的，所有内容都基于当时的版本。先来看一下整个工程的结构： . ├── LICENSE ├── README.md ├── README_zh.md ├── app │ ├── __init__.py │ ├── agent │ │ ├── __init__.py │ │ ├── base.py │ │ ├── manus.py │ │ ├── planning.py │ │ ├── react.py │ │ ├── swe.py │ │ └── toolcall.py │ ├── config.py │ ├── exceptions.py │ ├── flow │ │ ├── __init__.py │ │ ├── base.py │ │ ├── flow_factory.py │ │ └── planning.py │ ├── llm....

今天微软发布了 Phi3 模型，3.8B 的小体量做到了 Mixtral-8x7B 一样的效果，在社区引起了不小的轰动。 fuyao 老师直呼不能李姐 我前段时间曾经试过finetune Phi2 模型，效果说实话并不是很理想，默认 context 只有 2k 更是让他难以胜任很多生成式的任务。 今天发布的 Phi3 context 做到了 4k，还有长上下文的 128k 版本，至少在这块已经补上了短板。 其实 Phi 家族一直是 LLM 领域蛮有个性的一套模型，今天也趁机梳理了一下他们的发展脉络。 我们倒过去看，先总结一下今天发的最新版 Phi3。Phi-3 Technical Report: A Highly Capable Language Model Locally on Your Phone的几个重点如下： 模型尺寸有3.8B，7B，14B，3.8B 性能已经不错，量化后 1.8G 在 iPhone16 上一秒可以出 20 个 token 3.3T token 训练，更大的模型用了4.5T。这个比 llama3 的 15T 少的多 训练分两阶段。第一阶段用高质量网络数据，第二阶段用更强力过滤后的一阶段子集加 GPT 合成数据。第一阶段学语言能力和常识，第二阶段主要学逻辑推理能力。 除了语言模型还发不了 SFT+DPO 的版本 Phi3 的性能确实能打 Phi2 是23 年 12 月发布，只有一个 2.7B 的版本，没有对应的技术报告。从 Model Card 上可以看到主要是按 Phi1....

最近在学习一个奇特的技术，叫做生成式检索。生成式检索是一种利用生成式语言模型的全新信息检索方法。不同于依赖外部索引的传统方法，生成式检索利用单个强大的模型来处理查询和文档语料库。在这个注重推理能力，讲agent的年代，生成式检索却走到了让模型“死记硬背”的另一个极端。 生成式检索用简单的话来说，就是对于输入查询（query），让模型直接生成出语料库里相关文章的id，是的，你没有看错，是直接生成id！当然，这就会涉及到一个很重要的问题——id长啥样？当前的主流做法有几种： 原子id（atomic id），即每篇文章用一个独立的token来表示。这实际上是挂羊头卖狗肉，说是生成式，但因为每个文章都有独立token，所以等价于一个分类问题。 朴素id（naive id），即id是一个字符串，这个字符串没什么特别的，就是id常用的形式，可能是12345这样的数字串，也可能是apdkcr这样的hash串。然后模型在推理阶段是用自己的词表生成出这个id字符串。因为id没有明确含义，这种做法着实是挺难为模型的，相当于问一个人“为人民服务”出现在毛选的第几卷第几本第几页第几行第几个字。 语义id（semantic id）。和2一样，这里的id还是一个字符串，不同的是这个id是要包含语义信息的。这个大类有很多细分的做法，我列两种比较有代表性的。 直接生成URL。是论文Large Language Models are Built-in Autoregressive Search Engines里的做法。他们讨论的语料是维基百科，页面的url包含非常明确的页面主题信息。这种做法是比较符合大家对生成式模型的直觉的，生成目标也不局限在URL，tag、category都可以使用。 层次聚类。该领域经典论文Transformer Memory as a Differentiable Search Index的做法。是将大的语料库用embedding进行层次聚类，直到簇的大小符合要求。这样就把语料库转换成了一棵检索树，文章的id就是从根到叶子的一条路径。虽然还是数字id，但相比于一个自增或者随机的数已经结构化了很多。 层次聚类示意图 说完了id的问题，另一个重要问题是怎么让模型记住这么多id?方法也很土很暴力，就是搞一堆(query, docid) pair 让模型学就完了。如果这种数据不够，那有一些方法合成，比较典型的有： DAQ(Document as query):通常是在文章里取一截内容做query。 D2Q(Document to query):再搞一个模型根据内容生成一些可以回答的问题。 显然D2Q搞出来的数据更有可能接近使用场景的真实数据，所以效果好很多。D2Q其实不是什么新方法，四五年前就有人在IR任务里拿来增强模型。这两种方法都可以产生大量的训练数据，让模型充分死记硬背。 Doc2Query不是什么新鲜玩意儿 最后看下这种方法的效果和问题。 根据这篇论文的数据，在语料库不大（100k左右）的情况下这个方法还是表现不错的，可以超过bm25和经典的dual encoder+ann。但不得不说，这个成本可不低，100k文档的训练数据可能是4-5M条，要跑一会。 Corpus小的时候generative retrieval表现还不错 但当检索范围变大，这种方法的效果下降非常明显。这个结论也不意外，背几首古诗和背新华字典的难度肯定不同。很快就差于经典的召回方法了。 Corpus变大模型性能迅速下降 另一个明显的问题是死记硬背导致的新文档更新问题。当语料库里增加新的文档之后，模型要重新训练，速度慢不说，效果还可能有各种问题。也有不少文章专门也就这个问题。 以上就是对近期学习的一个简单总结。总的来说这个东西学术味道浓了一些，实用价值在现阶段应该还不大。但确实难说后面会不会有跟LLM结合的点。更多相关内容可以看这个Github Repo。

很多答主都提到了，从技术角度来看，声音克隆技术并不新，别的不说，去年大火一阵的 AI 孙燕姿应该大家都还有印象。 「AI 孙燕姿」火遍全网，随着技术的发展，未来 AI 歌手会成为主流吗？这一技术还可能应用到哪些场景？ 用孙燕姿的声音唱各种不同的歌曲就是声音克隆，而且难度还更好，因为要考虑音乐的节奏、音调、音色等因素。去年的效果已经很不错了，否则也不会出圈。更值得注意的是，AI 孙燕姿并不是某个大厂搞出来的，而是好多爱好者自己 DIY 出来的。可见，这个东西在技术上真的没有什么大的突破。 如果大家自己想玩玩 tts，我很推荐这个库，各种功能都有，自然也包括声音克隆。但开源的音色跟闭源确实没法比。 https://github.com/coqui-ai/TTS 但 OpenAI 做这个我觉得对他们自己还是很有意义的。毫无疑问，OpenAI 是要把自己打造成 AI 能力的首选，现在靠着 GPT 和 DALLE系列，和还未上线但已爆火的 Sora已经大概给自己树立这个形象了。但前面都是文本和视觉领域，Sora 的视频也是没有声音的。音频这块一直还没有起来，他家的 tts 功能我是用过的，我感觉体验很不错，虽然还没有老牌厂商例如微软那么精细的控制功能，但真的很简单易用，效果也好。这波声音克隆自然是比单纯 tts 更有可玩性，是更容易吸引用户的功能点。 以后，OpenAI 的 API key 应该是一个像样的应用开发者的必备之物了。

越来越多人发现Gemma 难以 finetuned的现象了。今天在 Twitter 逛就看到好几个相关帖子。 下面这个老哥是 Dolphin 和 Samantha作者，应该算有经验的开发者，直接搞了一个 200 多的 loss 出来。 add new token引发的惨剧 后面他们发现可能是新加 token 导致的问题。finetune 时如果新加 token 必须训练 embedding，对于 lora微调来说默认是不训练这组参数的。老哥把新 token 去掉之后正常了。如果是像我一样的全参微调压根不会碰到这个问题，Lora 看起来还是在社区里占据了更主流的位置。 Teknium 也是 finetune 达人，上来loss 也很高，但后面慢慢降下去了，原因也是他加了新 token。 另一个add new token引发的惨剧 回帖里有个老哥（之前是 OpenAI 员工哦）说可能是 pretrain 数据里有 Instruct 数据，顺带提了一下 Phi-2 和 Qwen 1.5。当然这都只是猜测，语料里有啥已经是大模型界最深的秘密。不过这种做法确实让人讨厌，基座就好好做通用语料训练，别搞指令数据。这么一搞下游训练容易遇到麻烦。我之前试过 Qwen 和 Baichuan，虽然他们的 benchmark 成绩都很好，但finetuned 的表现确实不如 llama2 好。Qwen 1.5最近倒是看到有不错的微调版本在 leaderboard 上排名不错。 这老哥还提供了一组超参数说值得一试。max_grad_norm 在 HF trainer 里默认就是 1，adam beta2 默认是 0.999，降低到 0.95 会让梯度的变化更敏锐一些。至于 epsilon，我一直感觉没什么可调的，1e-8 和这里的 1e-5 应该差别不大。...

昨天，也就是2024年2月22号，一早上起来就看到国内的AI公众号就热闹非凡，Google发布了他们的开源大语言模型Gemma，上Twitter也看到Jeff Dean卖力地再宣传自家的新产品：几条推文展现了好多令人兴奋的技术指标。 在上班前我先简单翻了翻技术报告，让我比较感兴趣的是256k的词表大小和6T的预训练语料。这俩改动加起来我估计应该性能确实会有一些提升。 最近Andrej Karpathy在YouTube上搞了个很火的讲Tokenizer的课程，应该也从侧面体现tokenizer和词表对现在的LLM性能之重要。我用Tokenizer Playground测试了一下LLama2和Gemma对同样文本的tokenize结果，可以发现Gemma的token数少了大概10%。当然，我测试的文本非常基础，全是ASCII字符，差距应该不那么明显，到了代码或数学场景（Gemma是做了digit分词的，数学应该强），差距应该就会显现出来。 LLama tokenizer 的结果 Gemma tokenizer结果 我最近喜欢在面试的时候问别人vocab大小对于LLM性能的影响，从序列长度讲当然是词表越大越好，因为token序列会短，不仅生成时的步数会少，每一步O(N^2)的self attention也会有不少的提速。但output layer和embedding table都会变大，所以最终的速度变化不太好说。 这个Gemma模型说是2B和7B，但其实参数量是偏大许多的，7B版本的参数加起来已经8B多了，谷歌这次为了“挽尊”特意把表格分成了embedding parameter和non-embedding parameter，确实略显诡异。 Gemma的参数量 结构的设计也比较奇怪，intermediate hidden size特别的大，和”同参数量“llama比起来层数有所降低。我特意整理了下表，大家可以更清楚地看出两者的变化。我这个表是从huggingface权重repo的config.json来的，feedforward dim竟然和tech report不一样。这次Gemma还在每一层放了两个normalization，激活函数也和llama不一样，用了GELU。 Gemma-7b Llama2-7b vocab size 256000 32000 hidden size 3072 4096 embedding params 786M 131M layers 28 32 attention heads 16 32 head dim 256 128 intermediate size 24576 11008 activation func GELU SwiGLU 技术报告里列了一大堆让人眼前一亮的指标，基本意思就是7b可以干llama-13b。但现在我感觉这些指标和实际好不好用关系并不是那么大，看看就好。当然此时的我预期Gemma7b应该还是要好过llama2 7b的。 Gemma的指标很亮眼 到了办公室赶紧就开始在我们的数据上finetune了一下。选的7b版本，huggingface已经贴心地把它整合进各种库里，transformers升级到4.38以上就行。我先试了下llama2-13b一样的超参，发现eval loss差了不少，而且新版transformers会计算grad norm，这个值在训练初期有很大的波动，一度达到上百的量级，感觉训练不是特别成功。后面我又换用了一组比较小的学习率，比之前有所提升，但eval loss还是和llama13b有差距。 我的几组实验，bf是全参微调，bl是lora 不过不同模型特别是词表量级相差如此巨大的模型间eval loss不太好比较（直观感觉是词表大的loss水平应该要高一些），只好用一些业务指标来比。我用一些测例推理了一下模型，发现学习或者推理过程应该是出了些问题。虽然eval loss在合理范围，但生成的文本基本不可用。 而且，Gemma7b的训练显存消耗比llama2-13b还大，同样的deepspeed配置我只能跑原来一半大小的batch。Gemma虽说参数约为8b，但肯定比13b小不少，出现这种情况我也比较费解，欢迎大佬点拨。 歌手大佬也发现了一些开源版的实现问题 总体感觉目前的Gemma版本有一些问题，看看过几天社区会不会发现并修复它。也希望真的能有个能超过llama2-13b的7b模型可以用。当然，我最希望的还是llama3赶紧出来吧😂

最近拿到了一台14寸的MacBook Pro，搭载了M2 Pro芯片，内存为16GB。昨天心血来潮，在上面尝试训练了一个神经网络，感触挺深的。 我训练的是一个BERT-base模型，当年也算是个”大模型“，但在现在看起来就是个小不点。训练数据不多，大概一万多条文本，平均长度应该接近模型的最大输入长度。 这个任务在我的A6000显卡上跑得飞快，不到十分钟就可以跑完三个epoch的训练。我一开始移植代码到MacBook上的时候没有注意到Huggingface Trainer有个控制是否使用M系芯片神经处理的开关，所以用的是CPU，进度条显示训练完要15个小时。 后来查阅文档，打开开关后，跑完训练的时间大幅下降到了1小时左右，提速了十几倍！(测试不严谨，但提速非常大是肯定的) 别人M1 Ultra的测试结果也有明显提速 不过遗憾的是，目前pytorch并不支持在M系列芯片上使用半精度数据类型，导致训练的显存消耗略大，batchsize上不去。但GitHub上有个帖子说M2其实只支持bf16的，估计不久的将来会有PR来支持这一特性，那又可以有一个速度的大提升。 前几天苹果发布了缝合版处理器M2 Ultra，碰巧知乎上有个付费问题，我就去了解了一下相关知识。目前苹果的统一内存架构是在CPU和GPU之间共享内存，而且内存带宽极大。4090的内存带宽是1T/s，而M2 Ultra达到了800GB/s。M2 pro的带宽也有200GB/s，而M2 max是400GB/s。 统一内存架构在大模型时代感觉有极大的优势，我查阅了一下目前NV主流的移动显卡，显存大多只有8GB，而M2 pro笔记本的起跳内存就有16GB，32GB版本再花3000块就能买到。 即使在不支持半精度的情况下，32GB的统一内存也足够塞下7B的模型，已经有很多东西可以玩了。京东上一个24GB的4090显卡也要一万多，加上七七八八配个台式机估计两万块也是要的。但是一个32GB版本的MacBook Pro也只要19000，简直太划算了！ 高考刚刚结束，有不少同学或者家长估计都在挑选新的电脑、手机等设备。在不差钱的情况下，我强烈建议搞一个MacBook，教育优惠可以打八五折，你可以尝试很多普通笔记本电脑没法带给你的东西。

今天深入体验了下Vicuna,以下是我的takeaways: 指令跟随的能力跟ChatGPT有点差距。最典型的就是下面的身份设定任务都经常失败（如下图）。模型会非常倔强地回复你他是Vicuna，是LMSYS训练的模型。 针对上面的问题我看了下代码，发现他们专门搞了好几个问身份的语料来训练模型图片，真的是把身份感刻在了骨子里。 fastchat迭代挺快的，今天试了下他们新加的API功能。整个使用体验几乎和openai的client一模一样，学习成本很低。但目前文档没怎么跟上，有时需要看看代码。例如我在异步环境里用chatCompletion.create失败，看代码才知道要用acreate。 试了下Vicuna-7b的embedding，能力非常一般，而且维度4096太大了，那算相似度可真费劲，而且在检索任务上被768维的Instructor Embedding秒杀了。 看了下lmsys的成员，好家伙，几乎全是中国人，感觉人才这块可能对于中文大模型不会是短板。 使用下来总体还可以，下面这个例子和GPT的能力确实差不多。最后一个图是我提供些knowledge给它后的回答，措辞稍微不达预期。

大江大海1949 {: .align-caption style=“text-align:center;font-size:smaller”} 就是上面的这本书，在大陆是买不到，甚至搜不到的。书商也很精明，在封面上印着“全球畅销经典作品，至今未能在中国大陆出版”来增加你对它的好奇心。其实早在多年前我就读过几页电子版，这次去台湾又在诚品书店遇见，便买了一本纸质书。 书是从讲述龙应台他们家如何辗转入台开始，通过描绘不同人物的故事和生平来展现那个特殊历史时期，更重要的可能是如书的扉页中写的 向所有被时代践踏、侮辱、伤害的人 致敬 断断续续花了一个月才读完全书，一些人和事已经记不清楚了，但有几点确实给我比较强烈的冲击。 其一是历史的残酷。不管是从台湾山区被征到东南亚成为狱卒的青年，还是从河南一路往南逃亡的少年，抑或在内战中被自己的同胞兄弟杀死的军人。身处那个时代的人们在历史的巨浪面前，真的就如蝼蚁一般，没有选择的权利，只能随波逐流。但反过来思考，历史往往又是被几个人左右。不管是日军将领，还是国共两党的高层，因为他们的诉求和命令，成千上万的平民百姓便被无故卷入到历史的漩涡中。高层虽然也是成王败寇，但在这个过程中最受伤的还是底层百姓，因为底层往往就只有你死我活的残酷争斗，生死关头，哪还管什么对错，可能连人类的尊严都可以置之不理了。 但历史又有公正的一面，我觉得龙应台的这本书对待这个问题却不够坦诚。书里有许多对解放军的描述，例如让手无寸铁的民兵打头阵与国民党军作战，有一些表述让我这个大陆人读起来不太舒服。我以前对解放战争时期我军如何能以弱胜强还不太清楚，但看了这本海峡对面的书我更加确定，胜利正是因为人民站在解放军这边，因为我党描绘的蓝图更加能打动民众的心。 与残酷的历史形成鲜明对比的当然是人的光辉，这也是龙应台一向擅长的部分。印象最深的是那五千个逃亡的少年和他们的老师，一路风餐露宿却还靠一本《古文观止》传承文化，我是真的为我们民族身上的这种韧性感动了。还有那些为了自己的理想信念甘愿付出生命的人，那些身处邪恶阵营却保有良知的人等等。我也相信不管再黑暗的时代，都会有点点温暖人心的光，而这些星星之火，终可燎原。 最后说一点稍不切题的内容。虽然身处和平年代，但中国大地上这几年涌起的浪潮其实也不小。就拿最简单的房子来做例子。多少人因为早买房、多买房甚至炒房就积累了大量的财富。而这些巨量的财富对于后来者来说就变成了沉重的负担。试想你的房子在一年之内暴涨了几百万，你又怎么还会把心思放在只能带来微薄收入的工作上呢。听说是最近北京的房价跌了，几个月的时间财富就能缩水上百万。但不管是涨价还是跌价，刺激太多，人总会变得狂躁，人生的悲欢也容易被放大，甚至扭曲。