578 篇博文 含有标签「insider」

几乎每一个全球部署的 AI 产品中都潜伏着一种隐蔽的失败模式。工程师本地化了 UI 字符串，通过翻译 API 运行模型输出，让母语者抽查几个回复，然后就发布了。该产品在技术上是多语言的，但在文化上并不称职。东京、利雅得和成都的用户收到的输出在语法上是正确的，但在文化上是错误的——这些回复表现出的不尊重、困惑或不信任，是团队在汇总指标中永远无法看到的。

研究结果是明确的：测试的每一个主要大语言模型（LLM）都反映了讲英语的新教欧洲社会的价值观。针对来自 107 个国家的代表性数据进行模型测试的研究发现，没有任何一个模型与非洲、拉丁美洲或中东地区人们建立信任、表达尊重或解决冲突的方式相契合。翻译修补了表面，但底层的校准仍然是西方化的。

你的 AI 功能上线了。在预发环境中，响应时间看起来还不错。一周后，生产环境开始出现神秘的 p99 尖峰——在中等负载下，延迟从 800ms 飙升至 8 秒，而 GPU 压力正常，模型没有报错，也找不到明显原因。你扩容了更多副本，没有改善。你对模型服务做了性能剖析，没有问题。你加了缓存，还是没用。

最终，有人查了数据库连接池的等待时间。从第三天起，它的利用率就已经高达 95%。

这是 AI 生产事故中最常见的一类，却鲜有人谈及——因为连接池耗尽的表现很像模型变慢。症状出现在错误的层级：你看到的是 LLM 调用延迟高，而不是数据库查询慢，所以定位问题往往需要数天，而用户一直在忍受降级的响应。

大多数构建多步 agent 管道的工程师会在第一次生产故障后约两周发现同一个问题：他们在 API 网关设置了 5 秒超时，但 agent 管道有四跳，而整个系统的行为就好像根本没有超时一样。第三跳的 agent 不知道上游调用方三秒前就已放弃等待，它继续运行、继续调用工具、继续生成 token——而用户早已离开。

这不是配置错误，而是结构性问题。延迟约束默认不会跨 agent 边界传播，主流编排框架也没有任何一个让截止时间传播变得容易。结果是一类看起来像延迟问题、实则是上下文传播问题的故障。

30%的生成式AI项目在概念验证后被放弃。95%的企业试点没有产生任何可衡量的业务影响。Gartner预测，到2027年底，40%的智能体AI项目将被取消。这些并非底层技术的失败——而是演示与生产之间差距导致的失败。

演示到生产的失败模式是可预测、可重复的，也几乎完全可以预防的。它的发生是因为让演示看起来很棒的条件与让生产正常运行的条件系统性地不同。团队优化前者，却被后者打个措手不及。

你的 Datadog 仪表盘一片绿色。Jaeger 链路看起来干净整洁。P99 延迟符合 SLA。而你的 Agent 流水线正在悄无声息地因重试死循环每天烧掉 4000 美元，却没有触发任何一条报错。

传统 APM 工具是为微服务设计的——确定性路径、有界载荷、可预测的扇出。Agent 流水线打破了所有这些假设。执行路径在运行时才能确定。工具调用深度变化剧烈。一次"请求"可能跨数分钟产生数十次 LLM 调用。而当出了问题，失败模式通常不是异常——而是一个悄然膨胀成本和延迟、却返回看似正常输出的静默重试级联。

结果是一代工程师在盲目飞行，信任着那些衡量错误事物的仪表盘。

一个合规承包商构建了一个 RAG 系统，旨在回答有关 400 页政策文档的问题。系统通过了内部 QA，针对单主题查询的检索表现正确。然而系统上线后，在处理涉及例外条款的任何问题时，它开始返回语气自信、结构严谨但错误百出的答案。

调试过程似曾相识：更换嵌入模型、调整相似度阈值、试验分块大小、添加重排序器。几周过去了，改进微乎其微。真正的症结在于，一个关键的例外条款在段落边界处被分割到了两个分块（chunks）中 —— 这并非由于分块策略，而是因为 PDF 提取器在误读排版时，悄无声息地将该段落一分为二。孤立来看，这两个分块都无法检索或解析。系统无法通过幻觉得到正确答案，因为正确的信息从未完整地进入索引。

这就是“提取天花板”：即当下游优化再多也无法弥补受损或缺失的输入数据时，系统所面临的瓶颈。

大多数团队将 AI 自主性视为一个二进制开关：智能体要么受监督，要么不受监督。这种思维模式正是为什么 80% 的组织报告了智能体的意外操作，以及为什么 Gartner 预测到 2027 年底，超过 40% 的代理型 AI 项目将因风险控制不足而被放弃。问题不在于 AI 智能体天生不可信，而在于团队在赢得独立性之前就将其提升到了独立地位。

自主性应该是智能体通过展示其可靠性而逐步积累的东西，而不是你在部署时分配的一个属性。就像一名新工程师在获得生产环境访问权限之前，先从审查 PRs 开始一样，AI 智能体在建立业绩记录的过程中，其操作范围也应逐步扩大。这不仅是哲学层面的思考——它会改变你所做的具体架构决策、你追踪的指标以及你设计回滚机制的方式。

大多数团队在做“云端 vs. 边缘”的决策时往往凭直觉：因为云端更简单，所以他们默认选择云端。直到 HIPAA 审计来袭，或者延迟 SLO 下降了 400 ms，亦或是收到了当月的账单。只有到那时，他们才会反思是否某些推理本来就应该在本地完成。

答案几乎永远不会是“全云端”或“全边缘”。大规模运行生产级 AI 的团队已经达成共识，采用了分层架构：由设备端或本地模型处理大部分请求，而云端前沿模型则负责处理小模型无法应对的情况。正确处理这种路由是一个工程决策，而不是一种直觉。

这就是进行严谨决策的决策框架。

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

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

你的发票解析器可能运行得不错。给它一个来自世界 500 强供应商的清晰、数字化的 PDF —— 结构化的行、一致的列宽、机器生成的文本 —— 它就能以近乎完美的准确度提取行项目。但当有人上传一份来自区域供应商的多页合同、一份带有手写修改的扫描表格，或者一份表格标题在第 3 页而数据行延续到第 6 页的财务报表时，提取器就会悄无声息地失败，返回部分数据，或者自信地生成结构化输出，而这些输出的错误方式是任何下游校验都无法捕捉到的。

这是企业级文档智能的核心问题：使你的系统崩溃的文档并不是边缘案例。它们往往是具有最高业务价值的文档。

40% 到 60% 的企业 RAG 部署无法进入生产环境。罪魁祸首几乎从来不是检索算法——HNSW 索引运行正常，嵌入质量也不错，向量相似度搜索已是成熟技术。问题发生在上下游：没有文档所有权、查询时未执行访问控制、PII 裸露在向量索引中，以及检索语料库在上线数周内就与现实脱节。这些都是治理失败，而大多数工程团队将其视为别人的问题，直到合规团队、安全审计，或某个收到了其他租户数据的用户把这变成自己的问题为止。

本文是受控 RAG 知识库的组织与技术解剖——写给拥有管道的工程师，而不是批准预算的高管。

团队调度循环 AI Agent 任务最常见的方式，也是最危险的方式：一个每隔 N 分钟触发一次 REST 调用的 Cron 条目，它启动一个 LLM 工作流，任务要么完成，要么悄无声息地失败。这个模式在预发布环境看起来没什么问题，但在生产环境中，它会制造出一类极难发现、难以恢复、难以推理的故障。

Cron 诞生于 1975 年，最初是为运维脚本设计的。它所内建的假设——运行时间短、无状态执行、触发即忘——在每一个维度上都与 LLM 工作负载的现实相悖。循环 AI Agent 任务是长时运行的、有状态的、成本高昂的，其失败方式会在多次重试中不断叠加。用 Cron 来调度它们，不只是可靠性风险，更是可见性风险：出问题时，你往往浑然不知。