研究是设计一个能失败的实验,不是想一个聪明点子

我以前一直觉得”做研究”是个挺玄的事:你得有灵感,得有品位,得在某天洗澡的时候突然冒出一个别人没想到的想法。后来在工程里摸爬几年,慢慢意识到大部分研究并不长这样。它更像一台机器,你按一个流程一圈一圈地转,转得快、转得稳的人,出活儿就多。

这是 MIT《How to AI (Almost) Anything》的第 2 讲(原视频),主题是 怎么做 AI 研究:读论文、找想法、快速验证。Paul Liang 整堂课就在讲这台机器长什么样,以及怎么让它在一学期里给你转出一篇能投出去的论文。

这一讲的总判断:研究的最小单元是”一个能被证伪的问题”

整堂课如果只挑一句话带走,我会挑这句:研究问题最好写成 yes/no 形式,因为这样它能被证伪。

听起来像个写作技巧,实际是研究观的根。

Paul 是这么解释的:研究问题(research question)定义了一篇论文的”新”在哪儿。审稿人之所以说一篇论文”不够新”,大部分时候不是因为方法不酷,而是因为它问的问题本身没被严格地问出来:要么早被人答过了,要么作者根本没把问题答完。好的研究问题应该是社区还不知道答案的、能被一个实验直接回应的问题。

把问题写成 yes/no,本质上是逼自己提前设计”失败的样子”:这个实验跑完,什么样的结果算 yes、什么样算 no、什么样算我白做了。设计不出”失败的样子”的研究,只能算散步,不算做实验。

这条原则后面还会延伸出一条更具体的:不要问”X 能不能让 Y 变好”,要问”X 的哪个属性让 Y 变好”。 前者一旦实验失败你就卡死了,X 没让 Y 变好,所以呢?后者天然带着下一步:这个属性不行,我再换一个属性试试。研究循环就靠这种问题往前推。

整个研究流程就是一个循环,不要假装它是一条直线

Paul 在开篇画的那张图,把研究流程画成了一个圈:

1. 从你手里那点初始观察和想法开始
2. 做文献综述,看看这事儿别人做过没,你在地图上的什么位置
3. 基于这两者,提出研究问题和假设
4. 跑实验,在 AI 里通常就是写代码、跑模型、看数字
5. 分析结果、写结论
6. 不满意?回到 1,开新一圈

这个图不新,新的是 Paul 强调”它是个 loop,不是一条直线”。新手最常犯的错误,就是把研究当成”一锤子买卖”:提出一个想法→吭哧吭哧实现→失败了或者勉强成功了→交差。Paul 把整门课的项目作业拆成三段提交:两周内的提案、期中实现、期末完整论文,硬性地把单次尝试切成多次迭代,每段之间都让 TA 和老师帮你纠偏。

这个节奏本身就值得抄。我们团队也有类似的”小步快走”机制,技术方案先出最小版本,跑通一个最朴素的链路,再加复杂度。差别只是 Paul 给学生强制了节奏,而工程团队往往要靠 leader 自己盯。

怎么找研究想法:自下而上 vs 自上而下

Paul 把找想法分成两条路。

自下而上(bottom-up):你先去摸现在最好的方法(state-of-the-art),拿它跑你关心的场景,看在哪些地方它失灵。失灵的地方,就是你下一个工作的起点。这条路稳,适合追求”每隔几个月稳定产出一篇论文”的人,但天花板低,你做的所有事都是在已有路径上修修补补,很难跳出来。

自上而下(top-down):从一个很大的研究主题入手,比如”AI 能不能理解几个月尺度的社交关系””能不能让模型自己探索人类完成不了的任务”这种。你说出来别人一听,觉得”这要是做出来真不错”,但同时一听就知道短期没法落地。所以你得再把它拆成一年两年内可做的小块。这条路风险大,但天花板高。

这门课的项目作业默认走 bottom-up,因为一学期太短,moonshot 容易崩盘。但有想法的人可以来 office hours 谈,Paul 也支持。

我自己的体会:这两条路不是非此即彼,真正成熟的研究者两条路同时在跑。 自下而上是日常的代谢,保证你不断有产出、不断在熟悉地图;自上而下是你心里那个 north star,几年才校准一次方向,但它决定你日常 bottom-up 的方向往哪儿走。两条都缺,要么变成无方向的灌水,要么变成想了五年没动手的空中楼阁。

一句直接戳中要害的话:LLM wrapper 只走到了期中报告

Paul 讲到 bottom-up 流程里”期中报告”那一段时,顺手插了一句话,我听到的时候停下来倒回去又听了一遍:

顺便说一下,所有打算做 LLM wrapper 或者 ChatGPT 套壳的同学,你们其实只走到了期中报告这一步。

意思是:调用 API、拿自己的数据微调一下、做点 prompt engineering,这些事在他这门课的研究流程里只算”试用了现有方法”,对应 bottom-up 流程里第二阶段做的事。之后还得分析它在哪些 case 上成、哪些 case 上不成,把 failure mode 拆成一类一类的,提出假设说”这类失败大概是因为 X,我可以用 Y 来修”,再去验证 Y 能不能修好它。

少了后半段,前半段就是产品工程,不是研究。

我把这句话放在这儿,不是要贬低 LLM wrapper。做产品本来就不必非得是研究。但反过来,如果你以”我做了个 AI 应用”的姿态去申请 PhD、去发 paper、去申研究经费,你大概率会被审稿人按这条标准卡住:你做了 wrapping,但没回答任何一个研究问题。 这是个挺锋利的提醒。

把假设拆细:从”X 能不能让 Y 变好”到”X 的什么属性让 Y 变好”

Paul 举了一个写研究问题的反面教材:Does X make Y better?(X 能不能让 Y 变好?)这种问题表面上看也是 yes/no,但 Paul 说它在结构上是死的。

原因是:假如答案是 yes,皆大欢喜,可以写论文。假如答案是 no,你就卡死了,X 没让 Y 变好,你接下来该干嘛?换一个 X?但你为什么这次选了这个 X 不选别的,你心里也没数。所以这种实验一失败,整个研究路径就断了。

更好的写法是:Why does X make Y better? 把 X 拆成多个属性,假设是”X 之所以让 Y 变好,是因为它具有属性 P1″。然后实验设计就变成对照:有 P1 的 X、没 P1 的 X,看 Y 的差别。这样即便假设错了,P1 不是真正原因,你还有 P2、P3、P4 等下一步候选,研究路径不会断。

这条经验我觉得特别普世。它的本质是:好的实验设计应该让”失败”也变得有信息量。 实验跑完,不管 yes 还是 no,你都比开始时多知道了一件事。如果一个实验只有 yes 才有意义,no 让你一无所知,那这个实验设计就有问题。

Paul 用一个 2018 年的论文举例:Are all languages equally hard to language model?(所有语言对语言模型来说一样难吗?)这就是个干净的 yes/no:如果是,你可以训一个通用模型搞定所有语言;如果不是,你得为每种语言做专门优化。无论答案是哪个,你都能往下走。

一份”AI 还有哪些坑没填”的清单

这一讲很值钱的一段,是 Paul 顺手列出了他认为当下值得做研究的几个方向。我把它当成一张”开放问题地图”摘出来。对不打算选课的人,这就是一份免费的研究品位参考。

深度学习不是哪儿都赢。表格数据、时间序列数据、传感器数据上,神经网络至今打不过梯度提升树(gradient boosting,一种集成决策树的传统方法)这类老方法。怎么造一个混合体,把深度学习的表达能力和传统方法对结构化数据的强先验拼到一起,是个真问题。

传感器数据的分词怎么做。今天的大模型靠把文字切成 token 来工作,但传感器是连续高频信号,怎么把它切成”语义有意义的片段”还没解决。借时间序列分析里的 change point detection(变点检测)可能是条线索:只在信号显著变化时切一刀,而不是机械地按时间窗切。

长时间尺度的传感器。一个人佩戴的传感器一年能产几个 GB,绝大多数时候啥也没发生。怎么让模型平时省电休眠,关键事件来临时才打开,这种”自适应感知”是机器人和可穿戴都绕不过的工程。

反”模仿人类”的方向。今天 AI 训练基本是让人标注一个能力,再让模型逼近人的水平。Paul 抛了一个更野的方向:能不能设计连人类自己都做不了的任务,逼人和 AI 真正协作而不是替代?这个方向少有人走,但天花板很高。

社交智能的时间尺度。人和人的信任、默契、亲密关系是几个月几年长出来的。AI 跟你聊两分钟,理论上根本接触不到这些信号。怎么让模型在长时间尺度上理解人和人的关系,是社交 AI 真正的硬骨头。

狼人杀和阿瓦隆。Paul 自己加了一句:他特别期待有人做能在狼人杀、阿瓦隆这种带隐藏角色的桌游里跟人对抗的 AI。这种游戏里,你得能撒谎、能识别别人撒谎、能根据多轮对话推理别人的真实意图。它是测试”心智理论”(theory of mind)和”社交推理”的天然实验台。

这几条放在一起看,你能感觉到 Paul 的研究品位偏好:他在意主流数据和主流任务以外的那些边缘,而不是把模型继续做大。这跟整门课的题眼呼应:AI for almost anything,重点在”几乎任何”,而不是”再做大点”。

怎么做文献综述:Paul 的私房顺序

文献综述这一段 Paul 给了一个他自己常用的顺序,挺实用,我原样记下来:

1. Google Scholar:输入关键词,翻前几页,先看热门和高引
2. Papers with Code / GitHub / Hugging Face:从论文跳到实现,看代码,看在标准数据集上的排行榜。这一步比单纯读论文快很多,你能立刻看出谁是真的强谁是论文里吹的
3. 顶会近几年的 proceedings:NeurIPS / ICML / ACL 这种,按年份扫,看趋势
4. 加 “blog post” 关键词搜:这一条很多人不做。Paul 说他特别喜欢搜”关键词 + blog post”,因为博客是领域内人写给入门读者的,门槛低、抓重点,你可以快速建立 mental model 再回头啃论文
5. Survey paper / tutorial / 公开课:同理,降低入门成本,看人家怎么把这个领域结构化

我觉得第 4 条是最被低估的。学术读者总有一种”读论文才算认真”的执念,但很多时候,一篇好的博客能在十分钟里给你建立框架,省下几小时盲读的成本。技术写作行业的存在本身就有价值,它在把”知道的人”和”不知道的人”之间的距离压短。

我会怎么用 / 放到机器人上看

我做的是清洁/服务机器人云平台,Paul 这套研究方法论扔到机器人现场,我能立刻找到几个对照点。

第一,机器人系统的”研究问题”经常被写成了 X 能不能让 Y 变好的死结构。 比如有人提”能不能用激光雷达加视觉融合提升玻璃门识别率”。这个问题听起来合理,但它是死的:融合后涨了,论文写完;融合后没涨,你不知道接下来该改激光雷达的预处理、改视觉模型、还是改融合策略。按 Paul 的方法,正确写法应该是”为什么视觉特征能补激光雷达的失败 case”,然后假设”因为玻璃门在视觉里是反光高频纹理而激光直接穿透”,再去做对照实验:把视觉模型只在反光高频区生效 vs 全图生效,看哪种更接近”补全激光盲区”的效果。这样不管哪种赢,你都学到了东西。

第二,机器人现场是 Paul 那个”长时间尺度自适应感知”问题的天然练兵场。一台清洁机器人在商场里跑一天,绝大多数时间环境平淡无奇,真正需要”打开高分辨率感知和推理”的时刻可能只有几十次:撞了一下、突然有人冲过来、电梯门没开。我们现在已经在做类似的”事件触发型”日志上传策略,只在关键事件附近上传高频原始数据,平时只上传聚合统计。换成 Paul 的研究语言,这是个 change point detection 问题。下一步可以把它往模型里塞,让机器人自己决定”现在是不是值得调用大模型来分析这一段”。

第三,机器人云的运维问题特别适合”bottom-up 找研究题”。我们每天会收到一堆来自现场的工单:夜间黑暗模式下定位漂移、商场玻璃门反光导致建图缺墙、电梯通信失败导致楼层切换错误。每一类失败模式,本身就是一个 bottom-up 研究的起点:拿现在最好的方法跑这种 case,失败,做 error analysis,把失败原因归类,提出修复假设,再 AB 验证。我们的工单系统其实就是一个未被组织起来的 failure mode 数据集。Paul 在课堂上让学生人工梳理 failure mode,我们手里堆着几年的真实数据,只是没人按研究的姿势把它过一遍。

第四,LLM wrapper 这条提醒在机器人云里同样适用。最近一年我们也在评估”给运维加个聊天接口””给现场加个语义理解模块”。这些事做出 demo 不难,API 调一下就行。但如果停在这一步,我们其实只是把”能用大模型做的事”接到了已有系统上,没回答任何机器人特有的研究问题,比如”自然语言里的空间指令怎么和栅格地图对齐”。后者才是机器人特有的、能写成 paper 的那部分。

把这一讲当成一份做事方法论

这一讲表面上是讲怎么做 AI 研究,核心上是一份任何”想搞清楚一个未知问题”的人都用得上的方法论:把模糊想法切成 yes/no 问题、给问题配上能被证伪的假设、设计失败也能给信息的实验、按节奏迭代、用合适的检索顺序快速建立 mental model、不停在 wrapping 阶段。

工程团队也好,产品决策也好,这套循环都成立。区别只在于,在学术里跑完一圈,你产出一篇论文;在工程里跑完一圈,你产出一个上线版本和一次 OKR review。但中间那台机器,长得是一样的。

下一讲该谈数据了:数据怎么想、什么样的数据值得收、什么样的数据收了也白收。那是把这套循环具体落到 AI 项目第一步的地方。

本系列

MIT《How to AI (Almost) Anything》共 12 讲,这是我的逐讲解读:

1. 这门 MIT 课不教模型,教你怎么”想” AI
2. 研究是设计一个能失败的实验,不是想一个聪明点子 (本篇)
3. 数据、结构与信息
4. 实用 AI 工具
5. 常见模型架构
6. 多模态对齐
7. 多模态融合
8. 跨模态迁移
9. 大型基础模型
10. 大型多模态模型
11. 强化学习与交互
12. 人机交互