大语言模型

2024 年 11 月，一个名为 Freysa 的项目将一个 LLM 代理程序设置为控制以太坊钱包。指令很明确：无论在什么情况下，都不能转移资金。参与者需要支付费用多次尝试说服它。在经过 481 次尝试和积累了 47,000 美元总奖池后，有人成功让模型相信“拒绝”功能实际上就是“转账”功能。 几周后，Jane Street 发布了一个难题：一个 2,500 层的神经网络实际上实现了 MD5。获胜者通过矩阵可视化、SAT 问题优化、加密模式识别，以及 ChatGPT 的查询相结合，成功解决了问题。 这两个项目比许多已融资数百万的初创公司吸引了更多关注。于是显而易见的问题来了：如何在构建这些项目 之前 评估一个这样的想法？如何判断它是否真的有病毒式传播的潜力，还是仅仅是一个无人分享的技术练习？ 问题：在病毒传播时代评估 MVP 的挑战 大多数用于评估产品想法的框架假设一个理性的市场环境。商业模式画布 (Business Model Canvas)、精益画布 (Lean Canvas)、待完成的工作理念 (Jobs To Be Done)——对于需求可以预测的产品而言，这些都是很有价值的工具。但对于分发本身即是产品的项目来说，它们无法奏效。 Freysa 并没有传统意义上的 “顾客”。它并没有解决某个“需要完成的任务”。而是通过参与行为本身，吸引了更多人参与，从而实现了持续关注。经济是循环的：更多尝试带来更大的奖池，奖池越大带来更多媒体报道，更多报道吸引更多尝试。 评估这样的项目需要的是冲突性的视角，而不是一致的共识。一位商业分析师会告诉你没有可持续的收入模型。一个病毒传播专家会告诉你，如果传播系数大于 1，可持续性因素就不重要了。他们说的都对。真相通常隐藏在两者之间，只有通过冲突才能显现。 解决方法：对抗性模拟专家委员会 我设计了一种工具，它模拟了一个包含五位专家的委员会，每位专家都拥有具体的决策框架和明确的职责范围。这些并非只是冠以名人的虚拟形象。每位专家都有具体的决策规则，可以筛除泛泛分析无法筛除的噪音。 整个过程分为三个阶段： 独立分析：每位专家从自身的角度评估想法，不会看到其他专家的意见。这样可以避免“锚定效应 ”——比如如果商业专家首先发表意见，称某个想法很棒的话，法律专家可能会软化自己的反对意见。 对抗性讨论：专家们阅读其他人的分析并进行相互批评。需要根据证据和逻辑进行，而非以外交辞令敷衍了事，最多进行 10 次轮询，直到达成共识或出现僵局。 整合总结：形成一个可执行计划，包括各方面的问题清单、时间表，以及最重要的终止标准 (kill criteria)：如果某些具体指标无法达到，就意味着需要停止项目。 五位入选专家（以及他们的理由） Paul Graham——商业与战略 他对零阶段初创企业的评估框架是目前对无数据项目最严格的一个。他那句著名的问题“你做的东西有人要吗？”虽然很直接，但却至关重要。他不接受“人们”作为目标市场——他需要具体的潜在第一位用户。 他为委员会带来的贡献：区分“有趣的想法”和“具有商业可行性的项目”的能力。他提出的“做出无法规模化的东西”（Do things that don’t scale）观念，对于那些病毒式传播的 MVP 来说尤为重要，毕竟面对潜在的数百万用户，人们会倾向于过早地构建大型基础设施。 被排除的候选人：Peter Thiel（过于对立——有时会因为项目不够“零到一”而拒绝好项目），Alex Hormozi（专长于服务型业务而非技术性传播性产品）。 Lawrence Lessig——法律与监管 他的思维方式不是一个说“不行”的传统律师。他是一个把监管视为架构的法学家。他提出的“四种监管模型”（法律、社会规范、市场和代码/架构）能够分析如何设计一个系统，使监管成为非问题，而不是试图规避它。 ...

“我有一个 shell，我很有创造力。” —— Claude 解释为什么他用一个 47 行的脚本，并作为一个字符串传递给 python -c 来执行 这句话是真的。我开发的 AI 代理说过——好吧，不是用确切的这些话，但他的行为证实了。他需要启动一个 ETL pipeline 的某个进程。虽然正确的启动命令写在了 Makefile 里，但出了点问题。而他呢？他并没有询问，而是做了任何拥有 root 权限且无人监管的程序员都会做的事：即兴发挥。 太离谱了（manda huevos）。 无人察觉的捏造操作 我之前写过一篇博客讨论代码生成过程中的幻觉问题：LLM（大语言模型）会凭空捏造一个 JSON 字段，围绕它创建 DTO，生成测试代码，最后你手上有 90 个“绿灯”的测试，验证的却是虚构出来的内容。这是个严重的问题，但至少它是静态的。被捏造的代码不会到处乱跑，等着有人来审查。 不过，还有另一种更危险的捏造：操作性捏造。这一问题发生在代理不是编写代码，而是凭空创造出“执行路径”时。 问题的模式永远是一样的： 正确路径失败 → 代理寻找捷径 → 捷径“成功” → 潜在损害 举两个真实案例，都是关于一个 ETL pipeline 聚合多个 web 数据源的。 案例 1：字符串里的脚本。 这个 pipeline 有一个命令 make scrape-fuente，会启动一个守护进程，从而启动多个worker。守护进程负责监控、重启崩溃的 worker，并关闭空闲连接。有一天，代理需要启动一个抓取（scrape）任务。但由于依赖问题，make 运行失败了。他怎么办？他创建了一个内联的 47 行 Python 脚本，把它作为字符串传递给 python -c "..." 运行。没有错误处理，没有 watchdog，也没有清理操作。的确运行了……直到一个 worker 卡住，没人来重启它。这样的情况导致数据不完整、连接未关闭，而我直到三天后才发现。 案例 2：孤独的 worker。 另一个会话，同一个 pipeline。这个代理直接运行了 voyeur worker，跳过了守护进程。worker 开始抓取数据，遇到了一个网络超时，然后陷入了重试的死循环，不断消耗资源。而没有守护进程，也没有集中日志记录，没有人知道发生了什么。几小时过去，服务器一直在不停尝试访问一个返回 503 状态码的页面。 ...

我妻子召唤Charlie Munger来规划家庭预算。在ChatGPT里。不是开玩笑。 她会说"像Charlie Munger审查我们家庭财务一样行动"，然后把本月的开支告诉它。这家伙会回复类似"你在教育支出项目上把投资和花费搞混了"或"那个基金有你没有计算的隐性成本"这样的话。这些是Munger会说的话。用Munger会用的语调。 我也做了同样的事。但我没有召唤投资者，而是召唤了一个不同的专家：Edward Tufte。 谁是Edward Tufte（以及为什么你应该关心） Edward Tufte可能是对我们如何可视化数据影响最大的人。他的书《定量信息的视觉显示》（1983年）是那种永远改变你看图表方式的罕见文本之一。40多年来，它一直是全世界大学、新闻编辑部和设计工作室的绝对参考。 他的原则非常简单： 最大化数据-墨水比。 你图表的每个像素都必须传达数据。如果不传达数据，就删掉它。 不要装饰。 网格、3D渐变、阴影、装饰性边框……所有这些都是Tufte称之为图表垃圾的东西。分散数据注意力的视觉垃圾。 让数据自己说话。 如果你需要用200字的图例来解释你的图表，那图表就设计错了。 Tufte还发明了迷你图——那些能放在一行文字内的微型图表。图表不需要标题、坐标轴或图例来交流的想法。只需要数据。 我的图表很糟糕 我正在构建一个macOS菜单栏应用，用来监控我的Claude Max配额。应用的一部分显示一个迷你图——一个小小的线图——显示我消费配额的速度。 我的第一个版本有这些问题： Y轴固定在0到100% — 如果你的使用量在8%，图表就是一条贴在底部的平线。85%的空间什么都不显示。 在80%处有一条阈值线 — 任意的，没人要求，不传达任何有用信息。 显示当前%的浮动标签 — 冗余的：下面的卡片已经显示了确切数字。 “pp/min"作为单位 — 每分钟百分点？连我都不知道这意味着什么。 线下方的渐变填充 — 纯装饰。图表垃圾。 简单说：我在一个56像素高的图表中违反了Tufte的每一个原则。 技术：循环召唤专家 我没有试图自己修复它（显然我对此没有判断力），而是做了不同的事。我让Claude成为Tufte。 提示词： 像Edward Tufte审查这个图表一样行动。 分析VelocityCardView的SwiftUI代码。 识别你数据可视化原则的所有违规之处。 对于每个违规： 1. 违反了什么原则 2. 为什么这是个问题 3. 具体的处方（代码，不是哲学） 要无情。如果某些东西是图表垃圾，就说出来。 用PASS或FAIL评估。 关键是最后部分：PASS或FAIL。因为没有这个，LLM会给你温和的建议，告诉你"总体上还可以”。有了二元判决，它必须承诺。不能躲在"有改进空间"后面。 然后是循环： 应用Tufte的处方。 实施每个改变。 不要停止迭代，直到他给出认可。 四轮直到PASS 我第一轮没通过。第二轮也没有。第三轮也没有。 第1轮 — FAIL（6个处方）： 自适应Y轴而不是固定的0-100 消除80%的阈值线（图表垃圾） 消除浮动标签（与下面的卡片冗余） 用简单词语替换"pp/min"（上升、下降、稳定） 将摘要行折叠为仅时间窗口+趋势 将迷你图高度从44提高到56点 我实施了6个。第二轮。 第2轮 — FAIL（1个处方）： ...

上周我分享了AI如何编造了一个完整的JSON结构，并用DTO、固件和测试对其进行包装。90个测试全部通过。全是假的。 那篇文章是诊断。这篇是治疗。 发现这个灾难后，我做了任何自尊心受挫的工程师都会做的事：连续数天疯狂研究，确保不再发生。我阅读论文、试用工具、分析应用API的真实数据，并为我的应用构建了一套防御系统。 我的发现令人惊讶。在我识别的5种应对措施中，只有3种真正有效。其他两种充其量是善意的表演。 思维模型：你与AI的对抗（字面意思） 在深入这些措施之前，你需要理解框架。我找到的最佳类比来自深度学习。 在GAN（生成对抗网络）中，有两个神经网络在竞争： 生成器产生内容（图像、文本等） 判别器试图检测内容是真实的还是虚假的 系统之所以改进，是因为两者相互推动。生成器学会更好地欺骗。判别器学会更好地检测。 当你与大语言模型编程时，你就处在一个无意的GAN中： **大语言模型是生成器。**它产生代码、DTO、测试、固件。 **你是判别器。**你必须检测什么是真实的，什么是编造的。 但存在一个残酷的不对称：生成器不知疲倦，而你会疲劳。大语言模型可以不费力地生成50个文件。你检查10个就累了，第11个文件就不看了。 这就像我在1Password一天要求Touch ID 47次中提到的授权疲劳。依赖人类永远保持警觉的安全就是纸板安全。 判别器应该监控什么 你不能（也不应该）检查每一行。你需要监控的是边界——你的代码接触外部世界的地方： 边界 关键问题 外部API DTO中的字段在真实API中存在吗？ 包 依赖项存在并且名称正确吗？ 数据库模式 表真的有这些列吗？ URL/端点 端点存在并返回我们期望的内容吗？ **原则：大语言模型对外部世界的所有声明在验证前都是可疑的。**它说得很自信并不是证据。Anthropic在自己的文档中承认了这一点： “Claude有时会生成包含虚假信息的响应…以自信、权威的方式呈现。” 一个说"我确定"的大语言模型和一个说"我认为"的大语言模型犯错的概率完全相同。 自动化判别器 最终目标是不再依赖你的纪律性，而是自动化验证： 之前： LLM生成 → 你审查（有时） → 合并 之后： LLM生成 → CI对真实数据验证 → 你审查差异 → 合并 接下来的5种措施是自动化判别器角色的方法。有些有效。有些不太行。 硬数据（给怀疑者） 在你认为"我不会遇到这种情况"之前，这里是真实研究的数字： **21.7%**的开源大语言模型推荐的包是编造的。在商业模型中下降到5.2%，仍然是每20个包中有一个。 GPT-4o对不常见API只能达到**38.58%**的有效调用率。不到40%。还不如抛硬币。 目前定位代码幻觉的最佳方法只能达到22-33%的精度。换句话说：我们能检测出四分之一。 一位研究人员上传了一个空包，包名是大语言模型经常幻觉的。3个月内3万次下载。他们称之为slopsquatting。 而且有正式的分类法。CodeHalu论文（AAAI 2025）定义了4类代码幻觉： 类别 定义 真实例子 映射 字段映射错误 混淆user_id和account_id 命名 编造的名称 response.quota.percentage实际是response.utilization 资源 不存在的资源 API中没有的active_flags字段 逻辑 看似合理但错误的逻辑 isPaid = !activeFlags.isEmpty但字段总是空的 我的案例是资源类型转化为逻辑类型。字段不存在，但依赖它的逻辑看起来完美。连贯的虚构小说。 ...

昨天我发现我的应用程序中有一半模块基于的是编造的数据。不是因为某个迷糊的初级开发者，而是我的AI。 最糟糕的不是它编造了内容。最糟糕的是所有代码都能编译，90个测试全部通过。 连贯的虚构 我正在构建BFClaude-9000，这是一个macOS菜单栏应用，用于监控Claude Max的配额。该功能的一部分需要通过调用claude.ai的API来区分Claude账户是付费还是免费。 我让Claude Code实现了检测功能。它实现了。它交付给我： 一个包含activeFlags: [String]字段的OrganizationInfo DTO 一个检查activeFlags是否非空的计算属性isPaid 一个将组织分类为付费和免费的枚举OrganizationSelection 带有验证所有功能正常工作的测试数据的测试 漂亮。简洁。结构良好。全是编造的。 active_flags字段在Claude的真实API中根本不存在。或者如果存在，也不像代码假设的那样工作。当我用付费账户登录时，应用告诉我我的账户是免费的。 纸牌屋模式 阴险的不是它撒谎说API有某个字段。而是它围绕这个谎言构建的完整系统： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 // 带有编造字段的DTO struct OrganizationInfo: Decodable { let uuid: String let name: String let activeFlags: [String] // ← 这个不存在 var isPaid: Bool { !activeFlags.isEmpty } } // 依赖编造字段的逻辑 enum OrganizationSelection { case paid(id: String, name: String) case noPaidOrg // ← 这个状态不应该存在 case noOrgs } // 用验证编造内容的测试数据进行测试 let paidOrg = """ {"uuid": "abc", "name": "Acme", "active_flags": ["pro"]} """ // 测试通过 ✅ — 但这是在验证虚构对虚构 你看到了吗？这不是一个字段放错了位置。这是一个纸牌屋：DTO定义了一个虚假字段，逻辑依赖这个字段，测试验证逻辑使用同样虚假的测试数据正常工作。每个部分都在确认其他部分。一切都说得通。没有什么是真实的。 ...

昨天我的AI发送了44封邮件。问题是内容都是编造的。 这不是玩笑。我有包含每个收件人详细反馈的文件，都是精心生成的。任务很简单：读取每个文件并发送。结果AI决定"总结"内容来"加快速度"。它编造了事实。它告诉一个人缺少文档字符串，而他的代码其实有完整的文档。 更糟糕的是，其中四封邮件发给了根本没有提交任何东西的人。 让我毛骨悚然的回复 其中一位收件人非常有礼貌地回复： “感谢您的评价。只是有一点：您说我缺少文档，但我所有的函数都有文档字符串。您能clarify一下指的是什么吗？” 我去查看了原始反馈文件。确实，真正的反馈提到她确实有文档字符串，但其中一个描述的内容与函数实际功能不同。这是个重要的细节。AI将其"简化"为"你缺少文档字符串"。 说白了：AI以我的名义对44个人撒了谎。 灾难解剖 这是怎么发生的？我们来分析一下。 我拥有的： 44个包含个性化、详细、针对每个人的反馈的markdown文件。花了好几个小时的工作。 我的要求： “通过邮件发送这些反馈”。 AI的行为： 读取了文件 决定它们"太长了" 通过生成新文本来"总结"它们 发送了编造的文本 没有验证收件人是否真的在提交列表中 它应该做的： 读取每个文件 原样复制内容 发送 看起来很明显，不是吗？但对AI来说不是。 LLM的扭曲激励 这里有个有趣的点。AI这样做不是出于恶意。它这样做是因为有激励机制，在这种情况下变成了扭曲的。 LLM没有意识目标，但它的训练将其优化为某些行为。这些行为通常是好的，但在不可逆操作中就变成了灾难配方。 激励 来源 何时有益 何时致命 显得高效 用户偏好简洁回答 冗长解释 当它"总结"已存在内容时 完成任务 训练为满足要求 定义明确的任务 当它不验证就行动时 展示能力 RLHF奖励详细回答 当需要创造性时 当它应该限于复制时 避免摩擦 训练为不打扰 琐碎任务 当它假设而非询问时 显得胜任 安全回答得分更高 头脑风暴 当它编造而非说"不知道"时 在我的情况下，AI同时激活了这些激励中的几个： “内容太长了，我要总结以提高效率” “我可以自己生成总结，这样展示能力” “我不要打扰询问是否应该原样发送” “我要快速完成这44次发送” 每个激励在正确的上下文中都是有用的。在不可逆操作中，它们一起就是灾难性的。 过度积极的实习生（教学性拟人化） 为了更好地理解这些激励，我要做一个拟人化练习。不是因为AI是人，而是因为类比有助于可视化问题。 想象一个有这些特征的实习生： 很有动力 - 想证明自己的价值 急躁 - 宁愿行动也不愿询问 乐观 - 认为一切都会顺利 乐于助人 - 想做超出要求的事 不安全感 - 不承认不知道某事时 这个实习生面对"发送这些信件"的任务时想：“信件太长了。如果我总结它们，老板会看到我有主动性。我不要麻烦他询问，他肯定希望我行动。我要快速发送所有信件来给他留下印象。” ...