61 篇博文 含有标签「ai」

你的团队在六个月前发布了一项由 AI 驱动的摘要功能。采用率停滞在 8% 的用户。模型调用每月耗资 4,000 美元。构建该功能的工程师已经调到了另一个团队。现在，模型提供商正在涨价。

所有的直觉都在告诉你：砍掉它。但事实证明，停掉一个 AI 功能要比停掉任何其他类型的功能都难得多——大多数团队都是在退役过程中，当合规问题开始出现、核心用户开始反抗时，才以惨痛的方式意识到这一点的。

这是一份在发布功能之前就应该存在的指南，但在你盯着那些明显指向退出的使用率图表时，它最为有用。

大多数 AI 产品团队都会遇到这样一种场景：某位领导层成员询问新的文案生成模型是否比旧的好。团队运行了评估套件，准确率数据看起来不错，于是发布了模型。三周后，营销团队悄悄换回了旧模型，因为新模型“听起来不对劲”。准确率指标是真实的，只是他们衡量错了对象。

这就是 AI 品味问题。只要你的输出是主观的——文案创作、设计建议、创意内容、语气调整、风格推荐——它就会出现。当没有客观的基准事实（Ground Truth）时，传统的机器学习评估框架会给你一种虚假的自信。而大多数团队对于该如何应对并没有系统性的方案。

一家大型保险公司的 AI 系统正在拒绝理赔申请。人工审核这些决定后，发现其中 90% 是错误的。这家保险公司的工程团队构建了性能出色的模型，MLOps 团队有完善的部署流水线，数据科学家有严格的评估指标。但这一切都无济于事，因为在董事会层面，从来没有人回答过这个问题：对于影响病人能否获得治疗的 AI 决策，我们可接受的失败率是多少？

这个缺口——功能正常的技术系统与缺失的高管决策之间的鸿沟——正是 AI 治理在实践中最常出现问题的地方。结果是：组织同时在生产环境中运行 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中近乎完整地提取了一本书的内容。如果你的产品使用语言模型生成内容，版权风险已不是未来的隐患，而是正在你的用户会话中实时发生，而你可能完全没有监测手段。

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