30 秒看懂
斯坦福计算机科学教授 Tengyu Ma 目前休假,担任 Voyage AI 联合创始人兼 CEO。他在 No Priors 播客上与 Sarah Guo 对谈,解释为什么检索增强生成在企业内部越来越占上风。一个 1 亿个 Token 的企业知识库,如果整体塞进长上下文(long context)模型,成本会高得惊人;同样的工作改用检索增强生成,成本只有 10 万美元上下,远低于 1000 万美元。他讲述了把自己引向这一结论的研究经历,其中包括 Sophia 优化器,以及为什么对智能体(Agent)来说,长期记忆应当交给向量嵌入(embedding),而更大的上下文窗口则不然。
- 1他的实验室有两条主线:训练效率和推理。第一条主线是被形势逼出来的:数据和算力(compute)都快用完了,两者都必须用得更好。推理是风险更大的押注,因为没人知道难题能以多快的速度被解开。
- 2一位 Meta 的朋友把 Sophia 用在超过 1000 亿参数的多模态训练中,效率提升了 1.6 倍。一笔 1600 万美元的预训练,换一个优化器就能降到 1000 万美元。
- 3七年前,应用机器学习要走七个痛苦的步骤。现在,别人来训练基础模型,你写一个提示词(prompt),再在上面叠一层检索增强生成。把 AI 用进企业的门槛降低了一个数量级,这就是他休假去创办 Voyage 的原因。
- 4随着 GPU 和网络越来越便宜、越来越小,长上下文和检索增强生成都会变便宜。两者的相对成本结构不会反转,因为检索增强生成底层的技术同样是神经网络。
- 5智能体串联与嵌入并不对立,它本质上是迭代式、多步骤的检索增强生成。知识应当交给小模型来管理,嵌入可能正是串联中合适的长期记忆。把大模型用在生成上,否则你刚省下来的效率又会花掉。
- 6嵌入模型的规模大约止步于 100 亿参数,因为延迟预算只有 1 秒、200 毫秒,甚至 50 毫秒。参数就这么少,就得花在最关键的领域上,然后再针对企业自己的数据做定制。
按章节阅读整理后的全文
从矩阵补全到 Sophia,论文里都带着理论思考的习惯
Sarah Guo 介绍 Tengyu Ma 时说,他是斯坦福大学计算机科学助理教授,同时是 Voyage AI 的联合创始人兼 CEO,该公司为检索系统训练向量嵌入模型和重排序器(reranker)。Guo 提到,他的研究范围格外广,涵盖理论、强化学习、嵌入、Transformer 和优化器。Ma 说,他的大多数论文里都带着一些理论思考,这是贯穿其中的一条线。他的工作从深度学习系统的数学证明,一路做到实用的语言模型,近来则集中在两个重点方向上。
第一个是训练效率。他认为,数据和算力都快用完了,所以必须把两者用得好得多。第二个是推理,他把它看得很重,某种意义上也很有风险:目前还没人知道,那些困难的推理问题能以多快的速度被解决。早年他研究矩阵补全中的优化问题。之后他转向句子和向量嵌入,其中有一篇论文早于 Transformer,它的做法很简单,只是把词嵌入取平均,再做了几次 PCA 变换,结果质量大幅提升。接着是对比学习,先用在图像上,后来成了训练嵌入模型的方法,他也试图解释它为什么有效。
Adam 已经十年了,Sophia 经历多次失败项目才撼动了默认选项
去年那篇优化器论文是 Sophia。Ma 的团队找到一种新优化器,把预训练效率提高了 2 倍。Sarah 的反应是,Adam 到现在已经很老了,Ma 表示同意:它大约有十年历史了。这十年里,无数论文宣称在各种场景下超过了它,但 Adam 依然是训练大语言模型的默认选择。正是这种顽固,让他大约在 2018 或 2019 年就安排学生去研究这个问题。经过好几年、好几次失败的项目和想法,才有了这篇论文。
代价更高的证据来自产业界。Meta 的一位朋友在大规模多模态训练中用了 Sophia。Ma 不清楚具体规模,但估计超过 1000 亿参数。在这个规模下,训练效率提升了 1.6 倍。Ma 把它换算成预算:一次 1600 万美元的训练,对比一次 1000 万美元的训练。换句话说,优化器层面的一个改动,就能省下真金白银。
把 AI 用进企业的难度降低了一个数量级,他因此休假创业
Ma 去年离开斯坦福休假,创办了 Voyage。他选择斯坦福,部分原因是这里的产业联系比许多大学都更紧密,他说创业一直在他的职业规划里。真正的问题是时机:技术已经足够成熟,商业化终于有了意义。他翻出了七年前刚开始教书时的课件,其中有一节与 Chris Ré 有关的应用机器学习课。当时的流程有七步,包括定义问题、收集数据、选择损失函数、训练和迭代。过程相当费劲。
在基础模型时代,有人负责训练基础模型。你给它一个提示词,再加上检索增强生成,基本就是整套技术栈了。他说,在产业界应用 AI 比七年前容易得多,这正是他觉得该商业化的原因。Guo 在自己的基金里也看到了同样的前提:大部分工作由别人以更通用的方式完成,所以应用层的成本大大降低。你只需要做最后几步。
检索增强生成分两步,质量瓶颈几乎全在检索
Voyage 做两个组件:嵌入模型和重排序器,目标都是提高检索质量。原因是客户一直在说的事。实现检索增强生成并不难:把各个部件连起来,系统很快就能跑起来。瓶颈在于答案的质量,而这一质量几乎完全受制于检索。如果语言模型看到的是高度相关的文档,它就能综合出一个好答案。即使是 Llama 70B,也能做得很好。
把语言模型当作黑盒来用时,它对公司的私有信息一无所知。检索增强生成会先从公司内部检索知识,再把这些知识交给模型,让它在生成时不那么随意地产生幻觉。模型看到相关段落后,会把它们当作锚点来完善答案,幻觉率会大幅下降。具体做法是:把知识库向量化,文档、视频、代码,什么都包括,把这些向量作为索引存进向量数据库,再用查询的向量去搜索。
客户覆盖面很广。Voyage 有一家化学公司,在自家文档和产品描述上使用检索增强生成,此外还有金融、法律、代码检索和代码生成等客户。Ma 认为,它几乎适用于所有场景,包括个人场景:比如手机上的检索增强生成系统,让你能调出自己的历史记录;或者笔记本上的搜索,不要求你记得准确的文件名。在这种场景下,语义搜索意味着你描述文件的内容,系统就能把文件找出来。Guo 提到,一年前,大多数企业技术负责人几乎没听说过这个词。这套架构还很年轻,争议却已经出现了。
长上下文是短期记忆,检索增强生成则是不必装在脑子里的图书馆
去年的争论是检索增强生成对微调(fine-tuning),Ma 认为这场争论基本已经有了结论。检索增强生成容易得多;微调往往需要大量数据,才能看到结果,而且微调之后幻觉可能依然存在。现在的争论是检索增强生成对智能体串联,或者对长上下文:把所有私有文档塞进一串带指令的模型,或者放进一个窗口里,而不做任何向量化。他想先谈长上下文,并讨论它的未来版本,因为眼下长上下文还不实用。
按今天的价格,把 10 亿个 Token 的私有数据直接塞进 Transformer,“根本不可能”,成本大约高出五到十个数量级,具体取决于语料。把这些文档在模型内部运算中的激活值缓存下来,能大幅降低费用,但整个上下文的中间计算仍然要放在 GPU 或 CPU 内存里,与检索增强生成之间的理论差距依然存在。有人会说,一切都会变便宜。嵌入本身也是神经网络:GPU 变便宜,网络变小,检索增强生成也会同步变便宜。他预测,检索增强生成仍会比长上下文便宜得多。两者的相对成本结构不会翻转。
Guo 给上下文窗口算了笔账:Gemini 1.5 Pro 的 100 万个 Token 大约相当于五本书,或者 2.5 万到 3 万行代码,视频和音频则没多少。Ma 说,许多公司手里有 1 亿个 Token,相差 100 倍。这就是“10 万美元”和“1000 万美元”两种账单的差别。1000 万美元不可接受,10 万美元还能接受。从第一性原理出发,他把长上下文看作短期记忆,把检索增强生成看作长期记忆。为什么要为了回答一个问题,把整座图书馆都搬进工作记忆?更高效的做法,是每次只检索其中一部分。计算机体系结构早就学会了这一点:硬盘、内存和 CPU 缓存之所以构成一个层级,正是因为这样效率最高。
用他的话说,嵌入模型和重排序器是管理语言模型长期记忆的模型。技术还会继续演进:两年之内,Voyage 或其他公司可能会推出一种新的记忆设计,它扩展嵌入模型,而非取代它们。至于智能体串联,它“定义得没那么清楚”,基本上与前者相互独立。串联中你仍然要用嵌入,仍然要做迭代检索,仍然要调用大模型。他会把智能体串联重新表述为一种迭代式、多步骤的检索增强系统。Guo 提到,最初采用串联的动机,和检索增强生成一样,都是为了效率。Ma 同意,但提醒说,如果让一个非常大的模型去管理知识系统,就等于把效率又还了回去。知识应当交给小模型,这时嵌入可能就是合适的工具。迭代检索现在有用,是因为嵌入模型还有提升空间,也还不够聪明;等它们变得更聪明,一两轮检索应该就够了,额外的跳转步骤也就没那么重要了。
把 100 亿参数花在领域上,再花在企业上
假设对于必须可靠的大规模私有数据,检索增强生成是主流架构。那怎么改进它?一种办法是调整提示词:告诉模型,如果检索到的文档里没有相关内容,就拒绝作答。现在的模型很听指令,几乎用不着这个技巧了。在 Ma 看来,用户反映的也是同一个问题:瓶颈在检索。你可以用软件工程的办法去攻克:分块、元数据、迭代检索、启发式规则。也可以直接改进网络本身,也就是嵌入模型和重排序器。Voyage 选择了后者。这类工作很依赖数据,要用数万亿个 Token 训练,再做专门化,这种重活应当由供应商来做,不必让每个终端用户都自己动手。
他更长远的押注是:更聪明的网络会让上层的软件层变薄。分块已经没那么必要:上下文长度在 1 万到 1.6 万个 Token 之间的长上下文嵌入模型,可以整份吃下一份 50 页的 PDF,因此把文档切成 5K 或 12K 个 Token 的片段,也就没那么重要了。同样的模式应该也会冲击其他“胶水”环节。今天,人们会把图片转成文字描述,再对文字做嵌入。等嵌入模型变成多模态、变得更聪明,这一转换步骤就该消失了。
领域模型,是 Voyage 使用稀缺参数预算的方式。他们先从头训练一个通用嵌入模型,再用领域数据继续训练:代码嵌入模型用了 2 万亿个代码 Token,法律嵌入模型用了 1 万亿个法律 Token。客户的私有数据不进入这些模型,所以任何人都可以使用它们。它们在一个领域里表现出色,在其他领域里提升很有限。延迟是硬约束。查询时要在推理(inference)阶段生成嵌入,再到向量数据库里做比对,而应用的延迟预算大约是 1 秒,常见的是 200 毫秒,有时只有 50 毫秒。这意味着超过大约 100 亿参数就不现实了。权重有限,定制就是把它们用到正确任务上的方法。领域微调已经显示出 5% 到 20% 的提升:代码上提升 15% 到 20%,那里数据更多,任务也需要算法理解;法律上提升 5% 到 15%,因为基线已经更强。再用某家公司的私有数据做进一步微调,还能再加 10% 到 20%。绝对的提升空间依然重要:起点是 50% 的准确率,就还有 50 个点可以提升;起点是 90%,就只剩 10 个点。
向量维度是一个被低估的延迟旋钮。在 100 维的嵌入上搜索,比在 1000 维的嵌入上快得多。Voyage 的嵌入维度比一些竞争对手小约 3 到 4 倍,这也是他们能承诺低延迟的原因之一。开发者应该什么时候开始在这上面投入?Ma 的默认答案是:原型做出来之后,第一天就开始。要分析延迟和质量。单独评估检索本身,也就是返回的文档到底有多少真正相关(业界有标准方法),同时评估端到端的答案。把两者对比,找出瓶颈,然后替换组件:换更强的嵌入模型,加一个重排序器,甚至换一个语言模型。不要一上来就堆提示词技巧。
最终形态是三四个网络加一层薄薄的软件
被问到技术栈会怎么演变时,Ma 预测系统会变得更简单,理由是 GPT 类模型、Claude、Mixtral 和 Llama 都在持续进步。他承认这种看法有偏向,也正是 Voyage 在朝着的方向。理想的架构是三个组件,或许四个:一个大模型、一个向量数据库、一个嵌入模型,也许再加一个重排序器来精炼返回的结果。把它们连起来就行。不必担心分块、模态转换或格式清理,因为网络会吸收其中的大部分工作。七年前,你得把非常干净的格式交给语言模型。今天和 GPT-4 打交道,可以带着错别字、奇怪的排版,甚至直接丢一个 JSON 文件过去。他认为,嵌入也会走同样的路。照这种说法,AI 的未来,是在几个强大的神经网络组件之上,覆盖一层非常简单的软件工程层。
他发现,创办公司和在大公司做研究很不一样,和管理大学实验室只差一点点:在实验室里他已经同时是 CEO、CTO、CFO 和 HR,只是规模小一些。最有用的建议来自一位天使投资人:去读书,哪怕是有经验的创始人都觉得基础的那些书。他只读了 Elad Gil 那本讲如何从十个人扩展到一千人的书的几章,因为 Voyage 现在大约只有十个人。和天使投资人,以及包括 Guo 在内的领投人交流,是他减少无谓失误的办法。对他来说,关键是减少犯错的次数,并且尽快纠正。一个错误在一周后修正,还是一个月后修正,效率相差 4 倍。Guo 指出,就连创业的经验教训,他也习惯用倍数来表达,这和他做研究的风格是一致的。
谈到规模化时代的学术界角色,Ma 愿意说一些不那么时髦的话。如果唯一的问题是如何把系统做大,那么激励机制不对,资金也不在那里。他引用了 Sam Altman 的观点:非营利机构筹不到足够的钱来做大规模扩展。他基本同意这一点,这也是大学实验室难以做大规模研究的原因。大学应该研究不同的问题,规模更小,眼光放在三到五年之后,别再沿着现在的路线去帮 OpenAI 把 GPT-5 做得更好。这也是他的实验室仍在研究优化器的原因:Adam 已经十年了,如果五年内能实现 5 到 10 倍的效率提升,整个格局就会改变,一笔 1 亿美元的 GPT-5 训练,可能降到 1000 万美元。推理是另一条主线,因为目前还不清楚,规模定律(scaling law)能否带人走到黎曼猜想,或者任何困难的猜想。他说,如果训练数据只有 Common Crawl,超人类水平的数学能力就很难让人相信。“如果只用网上的 Common Crawl 数据训练,能成为一个好的数学家吗?这真的很难让人相信。”Guo 说,这是一个开放式的收尾:还有待弄清的问题。
同频道的其他文章
39:23EN → 简体中文
1:09:44EN → 简体中文
35:39EN → 简体中文
42:44EN → 简体中文
38:14EN → 简体中文
45:10EN → 简体中文