Chip Huyen：AI 工程不是会更多模型，而是把系统更稳更能学

这期如果只记一句，我会记 Chip Huyen 那个很朴素的提醒：很多 AI 团队不是输在模型不够新，而是输在根本没把用户反馈和数据回路接起来。

对，这也是她最打动我的地方。她不是在劝大家别关注技术，而是在提醒你，技术再热闹，也不能替代系统工程。你把真实用户怎么用、哪里出错、哪些数据能回流说不清，模型再强也很难持续变好。

她说“会用户比会模型重要”，这句话一开始挺反直觉的。尤其现在大家天天都在聊新模型。

但你想想就明白了。模型能力决定的是天花板，用户场景决定的是你到底有没有机会摸到那块天花板。很多团队花很长时间比较模型排行榜，结果真正的问题是输入太脏、任务定义太模糊、用户成功标准压根没写清。

她后面聊 pre-training、post-training、fine-tuning，我觉得容易让人听成“研究话题”。对 builder 来说，最有用的翻译是什么？

最简单的翻译就是：别把自己想成在跟大模型公司抢饭碗。底座训练不是大多数团队的主战场。你更可能真正拉开差距的地方，是后训练阶段的数据组织、任务定义、反馈设计，还有你怎么把这些东西接进产品里。

也就是说，很多创业团队真正要做的，不是“训练更大的模型”，而是让现有模型在自己的任务上不乱来。

就是这个意思。比如你做客服、做代码助手、做文档问答，真正难的通常不是第一次跑出一个 demo，而是你怎么让它在第二百次、第二千次调用里依然稳定。稳定不是玄学，是一套数据、规则、监控和回放机制。

我注意到她对 evals 的态度也很成熟，不是那种“评测万能”，也不是“评测没用”。

对，她讲得很像工程师在过日子。你当然需要评测，不然根本不知道系统在退步还是进步；但你也不能为了追评测覆盖率，把团队全部拖进一个没有尽头的工作坑里。关键是找对最贵、最容易出事的那些场景，先把它们盯住。

她提到 pairwise 比较，也就是让人比较两个回答哪个更好。这听起来很朴素，但她好像觉得特别实用。

因为这真的比打绝对分靠谱得多。你让人说“这个答案是 7.2 分还是 8.1 分”，大家会漂；但如果你给两版结果，让人选哪版更可靠、更完整、更像样，判断通常会稳定很多。这类比较一旦积累起来，就能变成后面迭代模型和流程的真实依据。

她讲 RAG 和数据准备那段，我也很认同。很多人一上来就先争数据库、框架、检索方案。

对，但她的判断是，很多 RAG 系统表现差，不是向量库选错了，而是原始数据根本没整理好。文档怎么切、有没有上下文、是不是问答格式、是不是把对人类友好的文档改成了对模型也友好的形态，这些往往比框架名字更重要。

这其实挺反潮流的。因为讨论技术栈最容易显得自己懂行。

是，但 builder 真要对结果负责的时候，最后还是得回到那个很土的问题：用户到底问了什么，我们到底喂了什么，系统为什么会给出这个答案。技术选型当然重要，可它更像地基材料，不是你家为什么总漏雨的第一原因。

她还有个提醒，我觉得挺适合你现在这个项目：不要太早把自己绑定在单一技术栈上。

非常适合。尤其你还在快速试错阶段。这个时候如果某个模型、框架、服务一换就全身抽筋，说明你的系统耦合得太死了。你应该尽量把“任务定义”“评测标准”“数据资产”握在自己手里，把可以替换的那层做薄。

那如果是一个小团队，今天就想把这期内容落地，第一步应该做什么？

先别做一整套宏伟蓝图。挑一个最重要的任务，先写清楚三件事：用户成功长什么样、最常见的失败长什么样、你今天能收集到哪些反馈。哪怕只是人工标几个例子，也比继续空谈“以后我们做个超级智能系统”更有效。

听下来我会觉得，AI 工程这件事最容易被骗的地方，就是太容易把注意力放在炫的部分。

没错。真正拉开差距的，通常不是某个 demo 看起来多惊艳，而是系统在难看、无聊、重复的场景里能不能持续工作。数据整理、评测、反馈闭环，这些听着不酷，但它们才是你能不能长期交付的原因。

如果我只能把这期压成一句团队内部提醒，你会怎么说？

我会说：别把 AI 工程理解成“学会更多模型名词”，把它理解成“把用户、数据、评测和迭代接成一条能持续变好的线”。线没接起来，再强的模型也只是偶尔表现好。