fragments
提出一个好问题的比解决它更难
提出一个好问题的比解决它更难
之前有各种各样的针对AI的使用观察。比如使用AI提出的idea大部分都很蠢。比如使用AI会让强者更强。还有在解决coding问题上所谓的文科生+AI < 理科生+AI论调。
今天我尝试分析这些问题的核心原因:ask the right questions 。一个物理学教授可能不再会问“什么是麦克斯韦方程”的问题,一个受过良好训练的计算机学生也应该不会再问“为什么别人打不开我的localhost网站”,做研究时有经验的研究者能比刚入门的研究者提出一些更重要的问题。我们站在一个更高的高度,才能提出一个好问题。在AI时代,提出一个好的问题,已经比解决它变得更难也更重要。
当然有人可能问,为什么LLM不能提出一个好问题?我目前还没有理解。如果说把提出问题建模为一个搜索,一个好问题的搜索可能类似于muon,从rare directions里找到一些藏在噪声里的信号(噪声可能是相对于提出问题,比如包含已知的结果、推导)。我目前的一个感受/观察/猜想是,人在提出问题上更可能找出这些tail信号。
最近我从完全GPU科研重新回到了CPU-GPU协同科研状态。CPU/人脑适合进行这种复杂搜索,GPU/AI用来做代码实现/实验。这个人-AI协作的研发状态最大的challenge在两点:
-
- CPU/GPU的任务边界;哪些任务放GPU,哪些是CPU。
-
- CPU/GPU如何交互;两者在做不同任务时如何减少性能干扰问题。
我们尝试阐明challenge 1的边界:哪些知识和任务是有利于提出问题的,这一类job会从GPU调度到CPU,以及何时成熟的时候回到GPU。LLM在提出问题上目前不算太好,但我们可以让LLM加速人理解知识和问题,比如把很多的paper变成总结性的md。但这里的问题是,总结性的md像是对文章的主要部分进行采样,对长尾部分(比如实验内容的观察)不是很多。而很多有趣的问题其实是从这些长尾部分观察出来的。因此这部分内容需要人和agent持续的交互和人亲自看原文,去做BFS-DFS类的探索。
challenge2 的核心观察是,如果你每5-10分钟就去关注agent在实验等不重要任务运行的结果,CPU的深度思考总是会被打断。更可能合理的方案是根据重要性和思考频率打成cuda graph/megakernel,在一次交互里下达更长的指令。这可能会导致你的agent有时完成了任务,但是你还在CPU运行,产生GPU bubble。但是没问题,永远记得最重要的任务是在CPU端ask questions,消除CPU端的bubble更重要。
之前也有人尝试量化AI加速research的效率,经验数据大概是提升了两倍多。我们用CPU/GPU模型和阿姆达尔定律验证就知道了,想要速度变为原来的33%,其实真实的workload加速情况是20%的不可加速任务和原本80%任务被AI优化到了13%,其提升比一定是远超3倍的。如何让加速比更快?答案也是刚刚我们的challenge:用更强的model,把CPU任务抢到GPU;用更快更多的model,让GPU任务更快。什么时候不可加速部分变成0%,或者只有开头需要人类剩下完全agent,AGI或许就到了。
If you need to cite this post
Haibin Lai. (November 8, 2026). “提出一个好问题的比解决它更难” [Blog post]. Retrieved from https://www.haibinlaiblog.top/posts/%E6%8F%90%E5%87%BA%E4%B8%80%E4%B8%AA%E5%A5%BD%E9%97%AE%E9%A2%98%E7%9A%84%E6%AF%94%E8%A7%A3%E5%86%B3%E5%AE%83%E6%9B%B4%E9%9A%BE/
@online{lai--,
title={提出一个好问题的比解决它更难},
author={Haibin Lai},
year={2026},
url={https://www.haibinlaiblog.top/posts/%E6%8F%90%E5%87%BA%E4%B8%80%E4%B8%AA%E5%A5%BD%E9%97%AE%E9%A2%98%E7%9A%84%E6%AF%94%E8%A7%A3%E5%86%B3%E5%AE%83%E6%9B%B4%E9%9A%BE/},
}
Haibin's blog
DISCUSSION
Comments
No imported comments yet. Start the conversation below.
Leave a comment with GitHub