82 篇博文 含有标签「ai」

在 2024 年底，OpenAI 的 o3 系统在 ARC-AGI 基准测试中获得了 75.7% 的分数——这是一个专门为抵抗优化而设计的测试。AI 研究界欢欣鼓舞。但从业者仔细观察后发现：o3 使用了该基准测试 75% 的公开训练集进行训练，且最高算力配置使用的资源是基准线的 172 倍。这并不是伪装成分数的能力突破，而是伪装成能力突破的分数。

这就是评估悖论（Evaluation Paradox）。一旦某个基准测试成为团队优化的目标，它就不再能衡量其最初设计的目的。古德哈特定律（Goodhart's Law）——“当一个衡量指标变成目标时，它就不再是一个好的指标了”——虽然是在 20 世纪 70 年代的经济政策中提出的，但它却极其精准地描述了 AI 基准测试的现状。

大多数个性化系统是围绕一个飞轮构建的：用户进行互动，你学习他们的偏好，你展示更好的推荐，他们从而进行更多互动。随着数据的积累，飞轮转得越来越快。问题在于，飞轮需要速度才能产生升力——而新用户完全没有速度。

这就是冷启动问题。而且它比大多数团队在首次发布个性化功能时所认识到的更为危险。一个新用户在到达时没有任何历史记录，没有信号，通常还带着怀疑的先验预期：“AI 并不了解我。”你大约有 5 到 15 分钟的时间来证明并非如此，否则他们就会形成一种定论，决定他们是否会留得足够久，以产生那些能让你真正帮助到他们的数据。如果这个窗口期表现糟糕，高达 75% 的新用户会在第一周弃用产品。

冷启动问题不是数据问题，而是初始化问题。工程上的问题是：在缺乏历史记录的情况下，你应该注入什么？

你发布了一个 AI 功能。模型在你的留出集（holdout set）上达到了 92% 的准确率。你把这个结果展示给产品 VP、法务团队和客户成功主管。每个人都点头表示认可。功能上线了。

三个月后，一个你没有专门测试过的客户群体正面临 40% 的错误率。法务部门在提问。客户成功团队正在处理升级投诉。产品 VP 想知道为什么没有人预警。

92% 这个数字在技术上是正确的。但在作为决策输入时，它几乎是毫无用处的 —— 因为整体准确率恰恰掩盖了那些最重要的信息。

大多数工程师将 LLM 质量回归视为提示词工程问题或模型能力问题。他们会重写系统提示词、尝试更新的模型，或添加少样本示例。他们很少检查每次 API 调用顶部静静躺着的三个数字：temperature、top-p 和 top-k。但这些默认值正在悄然改变模型产出的每一个响应，错误的调参会导致输出方差——团队往往数月内都把锅甩给模型，直到意识到罪魁祸首不过是一个从未动过的配置值。

这不是入门教程。如果你在生产环境中运行 LLM——用于信息抽取管道、代码生成、摘要，或任何输出流入真实系统的任务——以下是你在智能调参之前必须理解的机制与权衡。

大多数 AI 团队都会对其落地页进行无障碍审计。但几乎没有人对聊天界面本身进行审计。这种差距并非源于懒惰 —— 而是因为工具根本不存在。WCAG 2.2 没有针对流式内容的成功标准，没有针对非确定性输出的标准，也没有针对逐个 token 传输的指南。这意味着目前每个将响应流式传输到 <div> 中的 AI 产品都处于合规灰色地带，同时破坏了很大一部分用户的体验。

这并不是一个微不足道的边缘情况。盲人和低视力用户报告称，寻求信息是他们使用 AI 的首要场景。患有诵读障碍、ADHD 和认知障碍的用户正积极尝试使用 AI 工具来减轻阅读负担 —— 而默认的实现模式却实际上让情况变得更糟。

大多数采用 AI 代码审查器的团队都会经历同样的阶段：最初的兴奋，伴随着大量看似有用的标注问题，然后逐渐演变成完全忽视该机器人。几个月内，工程师们已经形成了一种在不阅读 AI 评论的情况下直接将其关闭的肌肉记忆。工具仍在运行，评论仍在出现，但没有人再根据它们采取行动了。

这不是工具问题，而是衡量标准的问题。团队在部署 AI 代码审查时，从未定义过什么是“净收益”——如果没有这个基准线，告警疲劳最终会胜出。

这种规律在 2023 年和 2024 年采用编程智能体的团队中几乎普遍存在。第一个月，效率翻倍。第三个月，管理层把生产力指标拿出来，作为 AI 投资回报的证据。到了第十二个月，工程团队有一半的代码库已无法向新员工解释清楚，重构成本高得令人望而却步，工程师花在调试 AI 生成代码上的时间，比他们手写这些代码所需的时间还要多。

这不是一个关于 AI 代码暗中存在缺陷的故事。这是一个关于 AI 生成代码的质量特征如何系统性地瓦解团队已有的组织实践的故事——以及这些实践在技术债务复利失控之前需要如何改变。

一个由十二名工程师组成的团队热情地采用了 AI 编程工具。六个月后，每位工程师合并的 Pull Request (PR) 数量几乎翻了一番。工程经理为此欢欣鼓舞。随后，值班轮换开始频繁报警。调试过程的持续时间延长了一倍。没有人能解释为什么某个特定模块要采用那样的结构。编写它的工程师诚实地回答道：“我不知道 —— 这大部分是 AI 生成的，看起来没问题。”

这种情景正在各地的公司上演。个人生产力的故事是真实的：开发人员更快地完成任务，编写更多的测试，更高效地清理积压工作。但团队层面的情况则更为复杂，大多数组织尚未为此做好准备。

在43%的测试提示中，GPT-4会在被要求续写给定段落时逐字复现书中原文。2025年的一项研究中，研究人员仅通过持续的前缀喂入循环——无需任何越狱操作——就从一个生产级LLM中近乎完整地提取了一本书的内容。如果你的产品使用语言模型生成内容，版权风险已不是未来的隐患，而是正在你的用户会话中实时发生，而你可能完全没有监测手段。

这不是一篇法律文章，而是一篇关于法律问题的工程文章——工程决策要么制造这个问题，要么遏制它。律师会告诉你什么构成侵权；这套框架告诉你系统在哪里泄漏、如何度量，以及哪些措施真正能降低风险，而不只是看起来有效。

一份干净的 PDF、一个强大的 LLM、三十行代码。演示成功了。你提取出了发票总额、合同日期、患者诊断。利益相关方印象深刻。然后你推向生产，不到一周，流水线就在 15% 的文档上静默地返回错误数据——而没有人知道。

这就是文档 AI 的陷阱。失败模式不是崩溃或异常，而是一条在生成垃圾数据的同时仍然报告"成功"的流水线。构建生产级文档提取，与构建一个演示，是完全不同的问题——而大多数团队直到已经上线才意识到这一点。

你发布了 AI 功能。你将其内置于产品中。你编写了帮助文档。然而，六个月后，你最资深的企业用户仍然在将文本复制粘贴到 ChatGPT 中，以完成你的功能原本就能原生实现的事情。这不是培训问题。这是一个可发现性（discoverability）问题，也是当今企业软件中 AI 投资浪费最普遍的来源之一。

这种模式已有详尽的记录：49% 的员工表示他们在工作中从不使用 AI，74% 的公司难以从 AI 部署中扩大价值。但有趣的失败模式并不是那些明确抵制的后期采用者，而是那些每天打开你的产品、却从未意识到原本值得他们付费的 AI 功能就潜伏在光标一键之遥处的活跃用户。

大多数企业安全团队都有一套相当成熟的内部威胁模型：心怀不满的员工将文件下载到 USB 驱动器，将电子表格发送到个人邮箱，或者带着凭据离职。检测策略是已知的 —— DLP 规则、出口监控、UEBA 基准。这些策略没有考虑到的是这样一种场景：你给每位员工都提供了一个能够以机器速度规划、执行并掩盖多阶段操作的工具。这正是部署 AI 编程助手和基于 RAG 的文档代理的实际效果。

问题并不在于这些工具在隔离状态下是不安全的。而在于它们极大地放大了一个受攻击或怀有恶意的内部人员在单次会话中能完成的任务。内部人员事件的平均成本每年已达到每家机构 1740 万美元，83% 的机构在过去一年中至少经历过一次内部攻击。AI 工具并没有引入新的威胁类别 —— 它们只是成倍地增强了每一个现有威胁类别的能力。