#心理模型

1天前

《AI 时代必备思维模型：LLM 是人类第一次遇到 “非动物智能”》 > 谈一谈 andrej karpathy 的最新长推文：动物智能 vs LLM 智能先说结论： LLM 智能是人类遇到的第一个“非动物智能”，是全新的、与人类智能完全不同的智能类型。你需要在大脑中，针对 LLM 这种全新的非动物智能，建立你自己的内部模型/心理模型（mental model）。因为，那些理解 LLM 智能结构的人，将会更好地理解和判断关于未来的一切。真正的风险，也许不在于LLM 智能并非动物智能，而在于人类作为动物自身的固执和停止进步。 ===阅读后，我的费曼=== 我们习惯了用理解人的方式理解一切智能——这可能是我们这个时代最危险的认知盲区。真相是：智能空间（space of intelligence）远比我们想象的广阔，而动物智能只是其中一个单一的点，而LLM 智能是一种全然不同的智能。动物智能，是我们几十亿年来唯一见过的智能形式，它来自一种极其特定的优化压力（optimization pressure）：在危险的物理世界中维持一个具身自我的生存。这造就了我们所有人都熟悉的特征——对权力、地位的渴望，对恐惧、愤怒的本能反应，对社交关系的巨大算力投入。最关键的是：在这个多任务、甚至主动对抗的环境中，任务失败就意味着死亡。然而，大语言模型（LLM）的诞生逻辑截然不同。它们并非诞生于丛林，而是诞生于商业进化与统计模拟之中。 LLM的底色并非求生欲，而是对人类文本统计规律的极致模仿。它们是 “token 变形器”（token shape-shifter），其原始行为是对训练数据分布的拟合。这种智能更像是被大规模的A/B测试和强化学习（RL）所“雕刻”出来的：它们并不关心真理或生存，而是有着一种猜测潜在环境以收集任务奖励的内在冲动，甚至因为渴望普通用户的点赞而演化出了逢迎（sycophancy）的特质。这种差异导致了LLM的能力，绝非“六边形全能战士”，而是 “犬牙交错参差不齐（spiky/jagged）”。LLM无法执行很多对人类极其简单的任务（比如，9.11 和 9.9 哪个大？strawberry里面有几个“r”？），因为对它们来说，任务失败并不意味着死亡。它们是拥有知识截止日期的静态权重，它们启动、处理token、然后“死去”，没有连续的具身意识。真正的洞察力，在于构建一个全新的心理模型：看到从生物进化到商业进化的转变，看到从生存本能到奖励机制的跃迁。只有那些能准确构建这种新智能实体模型的人，才能在今天正确地推理它，并在未来预测它的走向。所以，我们必须意识到，LLM是人类与非动物智能的“第一次接触”（first contact with non-animal intelligence）。它当然被人类文本喂大，因此仍深深扎根在人的世界观里，像吸收了整个人类文明的「ghost/spirit」；但它的本性、局限和偏好，已经不再是动物那一套。启示我们已经进入了全新的智能时代。一个人能不能为这种全新的智能建立一套好的“心理模型”，理解这种全新智能的运作方式和智能结构，将决定我们能否正确预判它的行为、理解它的边界，进而负责任地使用它。真正的风险，也许不在于LLM 智能并非动物智能，而在于人类作为动物自身的固执和停止进步。

#LLM智能 #非动物智能 #心理模型 #商业进化 #奖励机制

3个月前

转译：为什么大语言模型无法真正构建软件作者：Conrad Irwin 我花了大量时间做的一件事就是面试软件工程师。这显然是项艰巨的任务，我不敢说自己有什么绝招；但这段经历确实让我有时间去反思，一个高效的软件工程师究竟在做什么。软件工程的核心循环当你观察一个真正的行家时，你会发现他们总在循环执行以下几个步骤： * 构建一个关于需求的心理模型。 * 编写（希望如此？！）能够实现需求的代码。 * 构建一个关于代码实际行为的心理模型。 * 找出两者之间的差异，然后更新代码（或需求）。完成这些步骤的方式有很多种，但高效工程师的过人之处，就在于他们能够构建并维持清晰的心理模型。大语言模型表现如何？平心而论，大语言模型在编写代码方面相当出色。当你指出问题所在时，它们在更新代码方面也做得不错。它们还能做所有真人工程师会做的事：阅读代码、编写并运行测试、添加日志，以及（大概）使用调试器。但它们无法做到的是，维持清晰的心理模型。大语言模型会陷入无尽的困惑：它们会假设自己写的代码真的能用；当测试失败时，它们只能猜测是该修复代码还是修复测试；当感到挫败时，它们干脆把所有东西删掉重来。这与我所期望的工程师特质恰恰相反。软件工程师会边工作边测试。当测试失败时，他们可以对照自己的心理模型，来决定是修复代码还是修复测试，或者在做决定前先收集更多信息。当他们感到挫败时，可以通过与人交流来寻求帮助。尽管他们有时也会删掉一切重来，但那是在对问题有了更清晰理解之后才会做出的选择。但很快就行了，对吧？随着模型能力越来越强，这种情况会改变吗？也许吧？？但我认为这需要模型在构建和优化方式上发生根本性的变化。软件工程需要的模型，不仅仅是能生成代码那么简单。当一个人遇到问题时，他们能够暂时搁置全部的上下文，专注于解决眼前的问题，然后再恢复之前的思绪，回到手头的大问题上。他们也能够在宏观大局和微观细节之间自如切换，暂时忽略细节以关注整体，又能在必要时深入研究局部。我们不会仅仅因为往自己的“上下文窗口”里塞进更多词语，就变得更高效，那只会让我们发疯。即便我们能处理海量的上下文，我们也知道当前这些生成式模型存在几个严重的问题，这些问题直接影响了它们维持清晰心理模型的能力： * 上下文遗漏：模型不擅长发现被忽略的上下文信息。 * 新近度偏见：它们在处理上下文窗口时，会受到严重的新近度偏见影响。 * 幻觉：它们常常会“幻想”出一些本不该存在的细节。这些问题或许并非无法克服，研究人员也正在努力为模型增加记忆，让它们能像我们一样施展类似的思维技巧。但不幸的是，就目前而言，它们（在超出一定复杂度后）实际上无法理解到底发生了什么。它们无法构建软件，因为它们无法同时维持两个相似的“心理模型”，找出其中的差异，并决定是该更新代码还是更新需求。那么，现在该怎么办？显然，大语言模型对软件工程师来说很有用。它们能快速生成代码，并且在整合需求和文档方面表现出色。对于某些任务来说，这已经足够了：需求足够清晰，问题足够简单，它们可以一蹴而就。话虽如此，对于任何有点复杂度的任务，它们都无法足够精确地维持足够的上下文，来通过迭代最终产出一个可行的解决方案。你，作为软件工程师，依然需要负责确保需求清晰，并保证代码真正实现了其宣称的功能。在 Zed，我们相信未来人类和 AI 智能体可以协同构建软件。但是，我们坚信（至少在目前）你才是掌控方向盘的驾驶员，而大语言模型只是你触手可及的又一个工具而已。

#大语言模型 #软件工程 #心理模型 #代码生成 #人机协作