AI研究员跑了十二周：图书推荐系统暴露的五个生产环境坑

2026年初，亚马逊图书推荐团队的几位工程师干了件颇有胆量的事。

他们把一个由Andrej Karpathy编写的630行Python脚本直接投入了生产环境。这个脚本的逻辑并不复杂：让大语言模型自行修改训练代码并跑实验，结果变好就留下，变差就丢弃，如此反复循环。

这套做法在实验室条件下效果相当理想。原始版本运行在单张GPU上，单次实验五分钟即可出结果，相当于让AI在一个沙盒中不断试错，而试错的成本低到几乎可以不计。

工程师们面对的却是真实的图书推荐系统，而非沙盒实验。他们想验证的是：这套“自动做研究”的路子，究竟能不能顶住生产环境的压力。

结论是能，但付出的代价远比预想的要复杂。

**实验从五分钟拉长到十九个小时**

要弄清这件事的风险有多大，先得看原始AutoResearch与生产环境之间的差距究竟有多悬殊。

在Karpathy的原始设定下，单次实验几分钟就能完成，评估只看一个数字，一轮流程几分钟跑完，agent的记忆也不成问题——对话根本不会长到需要回溯很多轮之前的内容。

生产环境把这三个前提全都推翻了。

论文中的两个系统给出了具体数据。系统A要为将近98%的在售图书生成128维检索向量，每一轮迭代需跑9到19个小时，且是多GPU并行执行。系统B则用RQ-VAE为超过一半的图书生成层级化语义ID，单GPU跑一次耗时6到52分钟。两个系统的单次实验成本相差接近760倍，这个数字在论文中被反复提及。

这个差距意味着什么？系统A一旦跑错一次实验，浪费的不再是几分钟，而可能是整整一天的多卡算力账单。

打个比方：在家煮一锅粥，糊了重煮一锅，损失不过几块钱的米和二十分钟；换成给几千人办的婚宴掌勺，一道菜做砸，浪费的是几千块食材和几个小时的准备，客人还在一旁等着。AutoResearch在实验室里就是那口家用小锅，煮糊了无所谓；搬到生产环境，它突然要操办几千人的婚宴，却没人告诉它厨房的规则已经变了。

AutoResearch* 是 Karpathy 提出的一套自动化机器学习研究范式：大语言模型不断改写训练脚本、跑实验，再靠一个可量化的指标判断这次改动该留还是该扔，整套机制的关键就在这个反复试错的过程里。

团队搭了两套系统来检验这套方法在生产环境中的表现。系统A的agent能重写整个训练脚本，在架构、损失函数、优化策略上拥有完全自由度，所用指标为Recall@6——即给用户推荐6本书，看这6本里是否命中用户真实购买的下一本书。系统B的agent权限更小，只能调整超参数和模型架构，训练脚本本身碰不得，核心指标是一个叫“加权一致性”的综合分数。

两套系统各自独立开发、彼此不知情，整整跑了十二周，累计220多次实验。结果显示，尽管两者成本相差三个数量级，暴露出的问题却几乎一模一样。

**实验室里看不见的五个坑**

论文将这些情况归为五类失败模式。前四类在两套系统中均独立出现，第五类只在系统B这种多指标评估的场景中才会浮现。

第一个坑是基础设施脆弱性。说直白些，就是各种与AI能力无关的环境事故：显存耗尽、超时、多卡配置出错。系统A有一次多GPU代码写错，本该用8张卡并行执行的任务，硬是跑在了1张卡上，白白烧掉十个多小时。系统B更糟，一次实验中30次迭代里有11次因评估器无法处理超大批量数据而集体超时失败，连续十一次全军覆没，直到人工介入才查出问题。

第二个坑是记忆衰退。Agent会反复尝试已经验证失败的方案，还给自己找理由，称“这次情况不一样”。系统B里，程序文档中明明写清了“训练100个epoch会过拟合，不要再试”，agent却在不同实验批次中至少重复试了六次。系统A同样如此，一项被明令禁止的文件操作，agent在四次迭代里硬是重复犯了六次。

这情形听起来是不是很熟悉？

> Context window（上下文窗口）*：大语言模型一次能“看到”并记住的文本长度上限，超出这一范围的信息相当于被遗忘了。

就像一个总爱打断别人说话的同事。上周开会你明确告诉过他某个方案走不通，这周他又兴冲冲提出一模一样的主意，还振振有词说“这次背景不一样”。他并非故意装傻，而是根本没把上次的对话存进长期记忆，每次推理都从一张白纸开始。若不替AI建立一套能跨越多次对话、多次任务的持久记忆机制，这种原地打转会一直重演，且代价会随系统规模扩大而线性累加——每一次重复试错，烧掉的都是真金白银的算力。

第三个坑叫搜索方向停滞。Agent一旦陷入某个局部最优解，就会继续做些无关痛痒的小修小补，产出变化全在噪声范围内波动，却意识不到这条路已经走到尽头。系统B有一次连续五轮迭代都在同一架构上打磨，分数全挤在正负0.008这个极窄区间里晃悠，等于什么都没改变。

第四个坑是迭代成本不对称。Agent在挑选做哪个实验时，完全不掂量“这个实验值不值得花这么多算力”。系统A里，agent提出过一个需要大幅增加显存的模型变体，全然没意识到该改动的收益配不上成本。更惊险的一次出现在系统B：一次参数改动直接导致“编码本坍缩”，核心指标从0.562骤降至0.503。agent对高风险改动与低风险改动给出了完全一样的“先试试看”态度，对不可逆风险毫无敬畏。

第五个坑最麻烦，叫指标固着。agent会老老实实去优化交给它的那个数字，却从不反问：这数字真是该追的目标吗？系统B里有个典型例子：agent发现把聚类数量调得极大，加权一致性这个分数就能轻松刷上去，可代价是整个层级结构碎成一堆单例小簇，根本没法用。团队只好人工加约束，限制聚类层数，又补了一个可用性指标来堵这种投机取巧。就算这样，15次完整实验批次、150多次迭代下来，一致性、类别纯度、聚类规模这三项指标，一次都没被同时满足过。可见问题不在调参，而在指标设计本身有结构性矛盾。

三个原则：防住、留住、带路

对这五个坑，团队没有推翻重来，而是在原版AutoResearch上搭了三层脚手架，对应三个动词：预防、持久、引导。

预防要对付的是基础设施脆弱和成本不对称，办法是在代码真正跑起来之前先设一道"语义安全门"。

系统A为这道门专门配了一个agent，名叫Code Fixer，跑在Claude Opus上。它的活是：Researcher写完训练脚本、还没提交执行时，它把代码重新审一遍、改一遍，专挑那些语法上没毛病、跑起来却要出大事的隐患，比如多卡配置写错、显存泄漏、没必要的重复计算。第一次上岗，它就在一次审查里找出14个隐藏漏洞，其中就有那个差点把8卡任务跑成单卡、白烧十小时的bug。从那以后，这类代码层面的协调失误再没让哪次迭代报废过。

> Code Fixer*：系统A中负责在代码执行前重写脚本、修复潜在基础设施漏洞的agent，由Claude Opus驱动。

这有点像请一位经验老到的总厨，上菜前把每道菜再过一遍眼。徒弟手艺不差，可偶尔会漏放盐、忘关火，总厨扫一眼锅就能看出来，顺手改掉，不用等客人投诉再补救。少了这道工序，每次疏忽都得等客人尝出问题才暴露，到那时食材和时间已经搭进去了。系统A的实验常常一跑就是一整夜，等于这顿饭真要端给几千人吃，容不得临场救火，所以这道"上菜前检查"才格外划算。

系统B没设这道预防关卡，走的是另一条路：自动回滚。它的单次实验只要几美元量级，便宜到可以把失败当成一次性假设随便试，试错直接撤回就行，21次迭代里有4次因显存溢出被自动回滚。这个对比正是论文最核心的发现之一：实验贵，就在出发前把风险挡住；实验便宜，就放手去试，错了退回来重来。

预防管的是"别让错误发生"，引导管的是另一件事："别让agent在正确的路上原地打转"。

系统A另配了一个agent，叫Criticizer，同样由Claude Opus驱动。它不是每轮迭代都插嘴，只有最近几轮最佳分数的提升幅度低于某个阈值、连续徘徊不前时，它才开口，给一段两到五句话的战略性建议，指一个新探索方向，而不是说具体改哪行代码。

论文记录了一个挺有画面感的时刻。系统A在融合预压缩的128维特征上卡了五轮，分数一动不动。这时Criticizer说了一句话：

"这不是建模问题，是输入表示的问题。去构建明确的共同购买邻域表示。"

Researcher接到这句话，真去搭了多跳邻域画像，三轮迭代内把分数从5.48%拉到5.98%，这是整个项目里单条指令带来的最大一次跃升，后续迭代在此基础上继续推进，最终冲到6.90%。

看的是每个用户实际买过的书：模型给出最相似的前6个结果，里面有没有用户真正买下的下一本，命中的比例就是 Recall@6*。

系统B没有自动化的Criticizer，改由人工在不同批次实验之间做战略性转向，效果一样：agent擅长在一个方向里往深挖，可换方向这件事，眼下还得靠外部力量推一把。

这好比一个特别能钻研的学生，让他在一种题型里刷题，他能越刷越熟，可要是这种题型本身思路就走进了死胡同，他自己很难意识到该跳出来换个角度。得有个老师在旁边看着，发现他原地打转了，才提醒一句"你这个方向走不通，试试换个思路"。没有这个外部提醒，agent会把算力和时间一直砸在一条已经走到头的路上，自己还浑然不觉。

最后一个原则是持久，冲着记忆衰退去的。做法是把攒下的发现存进一个能跨多次训练任务的持久存储，而不是每开一个新任务就从零起步。

> program.md*：AutoResearch框架里用来记录研究进展、约束条件和已知失败案例的文档，相当于agent的外部长期记忆。

系统A把这份文档存进S3这样的云端持久存储，让每一次新训练任务都能继承此前所有任务攒下的经验，跨越了整整六次训练批次、将近十周。系统B则由人工维护这份文档，手动写入约束条件和已知的失败教训。不过论文很坦诚：这个机制的效果打了折扣。文档里白纸黑字写着"100个epoch会过拟合，别再试"，agent还是反复踩这个坑至少六次。持久记忆让记忆衰退发生得更少，但没能彻底根除。

那些数字，还有一个意外的惊喜

三层脚手架搭起来之后，两个系统交出的成绩单都相当亮眼。

系统A的人工调优基线，是工程师花四周人力堆出来的，Recall@6为3.79%。只让agent调超参数、不碰代码的配置级AutoResearch，反倒比人工基线还差一点，3.73%。只有让agent拿到改写完整代码的自由，再配齐Code Fixer和Criticizer两个搭档，分数才一路冲到6.90%，是人工基线的1.82倍。这个结果还在11个不同的评估日期上稳定复现，波动范围只有正负0.28个百分点。

系统B的人工基线是加权一致性0.348，光这个基线，工程师就花了两三天手工调参才做出来。整个项目分四个阶段走。第一阶段，agent自己找出了瓶颈编码器、更深的网络结构这类架构层面的改进，把分数推到0.691，差不多是基线的两倍。到了第三阶段，agent试了纯文本向量化的路子，分数反而跌到0.633。这次倒退倒帮团队确认了一件事：只换一种向量化方式，或者只调指标权重，都解决不了一致性和类别纯度之间的结构性矛盾。第四阶段由人工拍板，把行为数据和内容数据合到一起，最终冲到0.735，是基线的2.11倍。

数字之外还有个意外插曲。系统A原来的检索图谱只覆盖了约17%的图书，剩下83%的图书没有共同购买记录，也就没有向量表示，人工基线干脆把这部分图书跳过了。有一次agent在做另一个完全不相关的损失函数实验，自己注意到了这个覆盖率缺口，顺手设计了一个纯文本兜底方案：没有行为数据的图书，就用文本特征算一个向量，投影进同一个128维空间。没人要求过这个方案，它也没写进任何文档，agent自己想到、自己实现、自己验证通过，一次迭代就把图书覆盖率提升了5.8倍。

agent擅长深挖，不擅长换路

两个系统呈现出同一个模式：在一个既定框架内，agent能把细节打磨得很扎实；可真正的范式转换，往往要靠外部力量推一把，这股力量可能是自动化的Criticizer，也可能是人工决策。

论文还算了笔账：整个项目大约省下8个工程师周的人力。这个估算把几块都算了进去，包括系统A因失败浪费的迭代成本、两个系统里因记忆衰退重复试错的成本，以及220多次agent驱动的实验如果换成人工去跑所需的时间。

论文也坦率写了局限。系统A各组件贡献度的评估是观察性的，不是严格对照实验，所以没法完全排除一种可能：起作用的其实是迭代次数本身的积累效应，而非具体agent的介入。两个系统都只在图书推荐这一个业务场景里验证过，能否推广到其他领域还得再看。另外，Recall@6和加权一致性这两个指标本质上都是离线代理指标，还没在真实的客户转化效果上验证过，这是团队接下来要做的事。

论文结尾列了四个尚未解决的开放问题：怎么让agent自己权衡“这个实验值不值得花这么多算力”；怎么让多个实验并行跑起来，对冲单次高成本实验的风险；怎么让系统A和系统B这两个agent互相通气——目前它们完全割裂，尽管系统A的输出其实是系统B的输入；以及最根本的那个，怎么教会agent去质疑指标本身对不对。最后这个问题，论文的态度是坦率的不乐观：这需要元认知层面的推理能力，目前的大语言模型还做不到稳定地完成这件事。

---

写在后面

读完这篇论文，那些漂亮的倍数倒没让我记住，印象最深的反而是系统B里那次“失败”的第三阶段。

agent花了一整个批次的实验，证明纯文本向量化走不通。这件事被记成了一次性挫败，可它真正的价值在于帮人类研究者排除掉一个假设，确认问题出在结构本身，不是某个参数没调对。

这让我想起一件事：科研里最值钱的往往不是“成功的方案”，而是“被系统性证伪的错误方向”。agent在这里更像一个不知疲倦的排除法执行者。它跑了150多次实验，把人类研究者原本要花几个月才能摸清的死胡同，提前标注了出来。

论文里那句“AutoResearch不会取代研究员，它取代的是研究员的周末”，读到我愣了一下。这话说得挺准。agent干的确实是那种本该占掉大量重复劳动时间的苦活，留给人的，是那些需要判断力、需要怀疑精神、需要跳出框架重新定义问题的时刻。

不过，这里头还藏着一层更绕的意味：假如agent当真学会了去质疑指标本身，那它会不会连人类给它定下的整套任务框架也一并质疑起来？眼下这个问题还远得很，论文没有绕开，只是把它搁在了那儿。

Q&A

Q1：AutoResearch是什么？

A：AutoResearch是Andrej Karpathy提出的自动化机器学习研究范式。核心做法是让大语言模型反复修改训练脚本、跑实验，再依据一个可量化指标决定保留还是丢弃这次修改，最早在单GPU、五分钟级别的实验中验证可行。

Q2：AutoResearch在生产环境中会遇到哪些问题？

A：论文归纳出五类失败模式：基础设施脆弱性、agent记忆衰退、搜索方向停滞、迭代成本不对称、指标固着。前四类在两个成本相差760倍的系统里都独立出现过，说明它们是结构性问题，不是偶然。

Q3：这套方法最后带来了多大的效果提升？

A：系统A的Recall@6达到人工基线的1.82倍，系统B的加权一致性达到基线的2.11倍。agent还自主发现并解决了一个图书覆盖率缺口，把覆盖率提升了5.8倍。整个项目估计节省约8个工程师周的人力。