LLM

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。