Seeing the Big Picture Through a Narrow Lens: Understanding Agent Products Through OpenManus
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....
管中窥豹:从OpenManus看到底什么是Agent产品
前几天号称“东方破晓”的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....
Deepseek公开利润率带来的影响
2025年2月28号,DeepSeek开源周的第六天,官方发布了一个很特别的东西,是V3/R1模型的推理系统介绍。和前面几天的代码库不同,这次是一篇博客文章。文章我没有细看,看可能也看不太懂,但单纯是tweeter上的帖子,已经带来相当大的震撼。 DeepSeek这个公司和早两年的OpenAI有一点像,让人眼前一亮。不管你喜欢还是不喜欢,OpenAI在这几年的AI浪潮就是先行者,旗手,领路人的角色,前期的几个工作ChatGPT、GPT4、Sora、O1都是开创性的。DeepSeek在几个月前其实在国内甚至都不被包含在所谓的六小龙里面,R1出来之后迅速出圈爆火。上个月研究了一下他们之前的一系列工作,连贯性特别强,除了坚持MOE道路,从一开始就把效率摆在了非常重要的位置。之前大家都说OpenAI力大飞砖,暴力美学,苦于国内算力难求,就感觉低人一档,但DeepSeek是一直在想怎么用更小的力把砖也飞起来,感觉有一种工程的精致美感。 开源周开源的几个东西,其实和一般开发者都没什么关系,但今天的这个推文,我感觉会很深刻地影响后面的产业走向,进而影响到广大普通人。 首先是把AI的价格打下来,你看他现在卖这么便宜,还有500%的利润率,简直是在印钞,可见降价空间之大。目前DS API的价格是8块钱人民币1M input,16块1M output,如果是没有RAG的问答,我感觉1M input/output够中高端用户用半年(红楼梦大概120万字,中文跟token大概率1比1换算,所以就是1.2Mtoken,你想一想一本红楼梦你要看多久)。未来一年,这个成本还会继续下降,我感觉降到十分之一并不困难,那么估计一个用户一年产生的推理成本可能就是几块钱人民币,基本可以忽略不计。当然这个估计可能不够准,毕竟推理模型大行其道之后模型的输出长度可能会成倍增加。但不会影响成本的数量级。 接下来是AI应用的爆发,如果上面的成本计算正确,那所有的应用都会毫不犹豫地加上AI功能,只要AI能提升一丁点产品体验,且不会伤害现有的商业模式(被普遍接受的观点是动作缓慢的谷歌就是怕影响广告)。我之前听到AI应用爆发,第一反应是像物种大爆炸一样出来很多“新”的东西,但是成本的快速下降可能更有利于原有产品利用AI进行体验提升。另一个角度是感觉直接把模型卖给消费者不是个好生意,这里有好多理由,比如:1)零星应用产生的交易金额很小,按照上面的计算一个普通人可能一年就花几块钱;2)模型间切换成本很低,一旦有更好或者更便宜的模型,用户会毫不犹豫地切换,这就特别需要加一个产品层来让用户产生粘性;3)对普通应用,目前的模型可能已经足够好了,比较难做出差异。在不严谨的语境下,AI在今年达到“90%领域超过90%的人”我认为是板上钉钉的。结合两方面原因,除了有AGI理想,卷应用是个更合理的选择。 然后就是对很多职业的影响,当ai真的在90%领域超过90%的人,那大规模失业的概率感觉在上升。离技术近的码农行业已经开始了,北美这边应届生找计算机相关工作真的挺困难。随着AI能力提升,影响面会逐渐从Junior岗位往Senior蔓延,也会从技术行业往其他行业蔓延,尤其是高时薪的知识密集型岗位,比如医生、律师等等。要么在行业里达到前10%,否则就比较危险,而且现在是10%,两三年之后可能就是5%,甚至1%。当然这个过程明面上不会很快,因为人会给机器使绊子。你端我饭碗,我跟你拼命。 “太阳底下没有新鲜事”这句话是很恐怖的,如果不是新鲜事,就意味着有被压缩到几百Billion模型参数里的可能性。所以在最后,祝大家能活出新鲜感吧。
Impact of Deepseek's Public Profit Rate Disclosure
On March 1st, 2025, the sixth day of DeepSeek’s open-source week, they released something quite special - an introduction to the V3/R1 model’s inference system. Unlike the code repositories from previous days, this time it was a blog post. I haven’t read the article in detail, and I might not fully understand it anyway, but the Twitter post alone has already caused quite a stir. DeepSeek resembles the OpenAI of two years ago, catching everyone’s attention....
小模型 Phi 的发展之路
今天微软发布了 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。
OpenAI 公布声音克隆新技术,仅需 15 秒音频样本即可模仿任何说话者,将带来哪些影响?
很多答主都提到了,从技术角度来看,声音克隆技术并不新,别的不说,去年大火一阵的 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微调踩坑记录
越来越多人发现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 应该差别不大。...
地表最强7b模型?我的Gemma体验报告
昨天,也就是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赶紧出来吧😂
接近参数化的世界
每个人的世界无非是ta看到的,听到的,闻到的,尝到的,摸到的加上想到的。 今天Sora的问世让我感觉到离计算机能够模拟这个感官世界已经不远了。虽然不是精确的,但肯定可以是精彩的,令人满意的。在享受面前,谁又会在意精不精确呢。 2022年ChatGPT出来的时候有模糊的感觉:预测下一个token的任务竟然能在效果上模拟推理、逻辑、甚至扮演角色,这不就说明文字世界的一切其实是被一个概率刻画的规律主宰的吗。放在玄学语境里,就是所谓的因果,它真的存在。 这次OpenAI更近一步,“世界模型”的概念已经再清楚不过地表达他们已经接近找到用概率模型刻画世界的方法了。 Sora is able to generate complex scenes with multiple characters, specific types of motion, and accurate details of the subject and background. The model understands not only what the user has asked for in the prompt, but also how those things exist in the physical world. 时至今日,文本、图像、音频、视频都已经可以被基于概率的AI以不错的质量产生出来。这些模型几十上百GB的权重里就是一个参数化的世界。 当一切都打磨地更加完善,那下一步就可以做一个造物主,用概率的方法造一个跟现实世界很像的世界。元宇宙可能处在大爆炸前夜?