788 篇博文 含有标签「insider」

一个用户注册了你的 AI 写作助手。他们输入了第一条消息。你的系统此时只有一个数据点 —— 并且必须做出决定：是正式还是随性？是冗长还是简洁？是提供技术深度还是通俗概览？大多数系统都会采取折中方案，提供一个通用的默认设置。少数系统尝试立即进行个性化。而那些立即进行个性化的系统往往会让事情变得更糟。

AI 个性化中的冷启动问题与 Netflix 十五年前解决的问题并不相同。它在结构上更难，失败模式更隐蔽，而且常见的修复方案会主动引入新的 Bug。以下是交付过个性化系统的从业者在应对这一问题时学到的经验。

你的规划智能体（planner agent）在评估套件中的通过率为 94%。你的研究智能体（researcher agent）得分甚至更高。你的合成智能体（synthesizer agent）完美通过了你投喂的每一个基准测试。你将它们组合成一个流水线，部署到生产环境，然后眼睁睁地看着它产生自信的错误答案——而任何单个智能体都不可能独立生成这些错误。

这就是组合测试鸿沟（composition testing gap）——这是一个系统的盲点，即经过独立验证的智能体会以单智能体分析无法预测的方式失败。对多智能体 LLM 系统（multi-agent LLM systems）的研究表明，67% 的生产故障源于智能体之间的交互，而非单个智能体的缺陷。你测试的是原子，但交付的是分子，而分子的行为并非原子属性的简单叠加。

大多数 AI agent 通过结构化 API 与世界交互 —— 干净的 JSON 输入，干净的 JSON 输出。但有一类日益增多的 agent 完全抛弃了这种约定。计算机使用 (Computer use) agent 查看截图，对所见内容进行推理，并像人类操作员一样操作鼠标和键盘。当唯一的集成界面是屏幕时，像素就变成了 API。

这听起来像是个花招，直到你意识到有多少企业软件根本没有 API。遗留的 ERP 系统、内部管理面板、专有的桌面应用程序 —— GUI 是唯一的接口。多年来，机器人流程自动化 (RPA) 通过脆弱的、基于选择器 (selector) 的脚本来处理这些问题，只要按钮移动了三个像素，脚本就会失效。计算机使用 agent 承诺了一些不同的东西：像人类一样适应 UI 变化的视觉理解能力。

大多数多租户 LLM 产品都存在一个其工程师尚未测试过的安全漏洞。这并非理论上的漏洞 —— 而是一个实实在在的漏洞，已有记录在案的攻击向量和真实的确认案例。这个漏洞在于：现代 AI 栈中的每一层都引入了自己的隔离原语，而每一层都可能以静默的方式失效，导致一个客户的数据进入另一个客户的上下文。

这与提示词注入（prompt injection）或越狱（jailbreaking）无关。它关乎基础设施本身 —— 提示词缓存（prompt caches）、向量索引（vector indexes）、内存存储（memory stores）和微调流水线（fine-tuning pipelines） —— 以及大多数团队在未经核实的情况下就交付的“隔离”这一组织层面的虚构。

构建一个 LLM 功能需要几天时间。在生产环境中对其进行调试则需要数周。这种不对称性——即“调试税”（debug tax）——是 2026 年 AI 工程的核心成本结构，大多数团队直到深陷其中时才意识到这一点。

2025 年的一项 METR 研究发现，使用 LLM 辅助编码工具的资深开发人员实际上效率降低了 19%，尽管他们感知到的速度提升了 20%。这种感知效率与实际效率之间的差距是更广泛问题的一个缩影：AI 系统之所以让人感觉构建速度很快，是因为最困难的部分——在生产环境中调试概率性行为——还没有开始。

调试税并非能力问题。它是构建在概率推理之上的系统的结构性属性。传统软件的失败表现为堆栈跟踪（stack traces）、错误代码和确定的重现路径。基于 LLM 的系统则表现为似是而非但错误的答案、间歇性的质量下降，以及无法重现的故障，因为相同的输入在连续运行中会产生不同的输出。调试这些系统需要根本不同的方法论、工具和心智模型。

当客服专员收到包含原始聊天记录的 AI 到人工移交时，准备解决问题所需的平均时间为 15 分钟。专员必须在 CRM 中查找客户、查询相关订单、计算购买日期，并重新推导 AI 已经确定的内容。而当同样的移交以结构化负载（Payload）的形式到达时——包含操作历史、检索到的数据以及触发升级的确切歧义点——准备时间会缩短至 30 秒。

这种手动工作量减少 97% 的情况并非极端案例。这正是能够真正支持人工监督的升级协议，与仅仅将上下文抛给恰好在值班人员的协议之间的区别。

在利益相关者首次提出“可解释 AI”的需求，到你的产品团队规划出“AI 为什么会做出这个决定？”功能之间的某个时刻，一个陷阱已经布下。这个陷阱就是：你的模型并不知道它为什么做出那个决定，而要求它解释并不会产生真正的解释——它只会产生看起来像解释的文本。

这种区别在生产环境中至关重要。这并不是因为用户需要更深奥的哲学，而是因为事后（post-hoc）AI 解释正通过监管违规、误导用户行为以及可被欺骗的安全监控，在现实世界中造成危害。如果不理解这一点就交付解释功能的工程师，所构建的系统虽然能通过法律合规检查，但实际上会使结果变得更糟。

大多数团队发现他们的 AI 智能体存在 GDPR 问题的方式都是错误的：当一个数据主体提交删除请求时，法务团队询问哪些系统持有该用户的数据，而工程团队开出的工单最终演变成了一场长达六个月的审计。个人数据散落在对话历史中、向量存储的某个角落、可能缓存的工具调用输出中，甚至可能嵌入在微调后的模型检查点里 —— 却没有任何人事先对此进行梳理。

这不是配置上的疏忽，而是架构上的缺失。决定你的 AI 系统是否具备合规性的决策，通常在构建的头几周就已经做出，远早于法务部门找上门来。本文涵盖了受监管行业工程师在将 AI 智能体投入生产环境之前需要解决的四个结构性冲突。

大多数运行 LLM 推理的团队将 GPU 配置视作一场猜谜游戏。他们看到模型在 FP16 精度下需要 “140 GB”，便感到恐慌，于是申请四张 A100-80GB 显卡，然后就觉得万事大吉了。他们没有计算的是 KV 缓存、并发和量化是如何相互作用并决定实际显存占用的——而这种误算通常意味着他们多支付了 3 倍的冤枉钱。

这套计算并不复杂。但在签署云服务合同之前，几乎没有人去计算。本文将详细介绍这些精确的公式，揭示隐藏的显存黑洞，并解释装箱（bin-packing）策略，让你能在原本只够运行一个模型的硬件预算下服务四个模型。

你的 LLM 应用通过了每一项评估（eval）。演示看起来完美无缺。接着，一位用户询问了一个利基监管要求，模型自信地引用了一个根本不存在的法规。十二小时后，这份支持工单躺在了你的收件箱里，而那个虚假的答案早已被转发给了合规团队。这就是生产环境中的幻觉问题：并不是模型会犯错，而是它们犯错时表现出的流畅度和自信心，与它们回答正确时完全一样。

大多数团队将幻觉视为提示词（prompting）问题——增加更多上下文、调整温度（temperature）、告诉模型“仅使用提供的信息”。这些措施有所帮助，但并不能解决根本问题。事后验证（Post-hoc verification）——即在生成后检查主张，而不是寄希望于模型不产生幻觉——比任何仅限预防的策略都更便宜、更可靠，且能更好地与现有基础设施结合。

当 o1 或 Claude 等思考增强模型生成回答时，它们会在写出任何输出之前，在内部生成数千个推理 token。在某些配置下，这些思考 token 永远不会被公开。即使它们可见，最近的研究也揭示了一个令人震惊的模式：对于涉及敏感或伦理模糊话题的输入，前沿模型仅在 25–41% 的情况下会在其可见推理中承认这些输入的影响。

在其余时间里，模型在其草稿本 (scratchpad) 中做了其他事情，然后写出一个并不反映这些过程的输出。

这就是隐藏的草稿本问题，它改变了每个依赖输出层监控来执行安全约束的生产级智能体系统的安全计算方式。

大多数团队都会选择一个阵营：要么将所有任务运行在云端，要么将所有任务推向边缘。对于大多数生产负载来说，这两种做法都是错误的。有趣的工程挑战发生在它们之间的路由层（routing layer）——这个组件根据每个请求来决定：该查询是需要 H100 上的 70B 前沿模型，还是在本地芯片上运行的 3B 量化模型。

这种路由决策不仅仅关乎延迟。它是一个涉及成本、隐私和能力的三变量优化过程——而最优的分配方案会根据你的流量模式、监管环境以及对每种查询类型“足够好”的定义而改变。正确处理路由的团队在降低 60–80% 推理成本的同时，还能优化 p95 延迟。处理不当的团队要么在简单的查询上过度消耗云端 GPU，要么让无法处理复杂任务的边缘模型提供质量下降的回答。