11 篇博文 含有标签「enterprise-ai」

一位客户的总法律顾问给你发来一封只有一行的邮件：“如果下周模型在我们的合规工作流中捏造了事实，谁的保险来赔付？”你把邮件转发给工程副总裁，他转发给法务，法务又转回给你。等这条转发链结束时，三个人都分别假设其他人已经仔细阅读过模型提供商的条款。但实际上没人读过。合同之间并没有真正的衔接——而你，作为中间层，是第一个发现这一点的人。

这就是 AI 赔偿缺口。它的存在是因为每个企业级 AI 产品都处于一个由三环组成的责任链中——终端客户、你的产品、模型提供商——每一环都默默假设下层在承担责任。模型提供商的条款将赔偿限额设定在过去 12 个月的费用总额左右，并明确排除对输出准确性的责任。你的 MSA（主服务协议）通过客户律师未仔细阅读的下游转嫁条款继承了这些排除项。而你的客户与他们的下游用户（当输出出错时真正的链尾受害者）签署的合同却将你的产品列为责任方，且没有明确的上游追索权。

第一次索赔发生时，大家才会发现这个缺口。在此之前，责任链上的每一个人都在抱着侥幸心理得过且过。

我上个月交流过的一位 AI 初创公司 CTO 打开她的笔记本电脑，给我看了一个数字：47。那是目前在生产环境中运行的独立系统提示词（System Prompt）的数量，每个企业客户或每个逻辑分组各占一个。基础提示词在第四个月为一家需要更温和拒绝态度的医疗客户派生（Fork）了一次。然后为一家需要引用的法律客户又派生了一次。接着是为一家金融服务客户派生的，因为他们的合规团队有一份违禁词清单。当时，这些看起来都不是什么大事。每一个都是独立批准的小需求，让大客户经理团队能够顺利签下订单。

两年后，模型提供商宣布了她那些针对旧版本调优的提示词的切换截止日期。她的工程团队直觉反应是对新模型运行评估套件（Eval Suite）。评估套件仅针对基础提示词。基础提示词仍在为 0 号客户提供服务，该客户没有任何覆盖配置，且约占收入的 9%。

同一家公司的两位分析师都问了你的 AI 助手同一个问题："我们 Q3 的客户流失率是多少？"一个人得到的是 4.2%，另一个人得到的是 4.8%。两个答案都没有错——他们只是在不同的时间、不同的会话上下文中进行了查询，检索索引对略有不同的数据块进行了排名。AI 自信地回答了两个问题，没有任何保留，没有标记任何差异。两位分析师带着不同的数字走进了同一个会议，而你的工具刚刚变成了一个负担。

这就是跨用户一致性问题，也是企业 AI 部署悄然失去信任最常见的原因之一。这种失败并非经典意义上的幻觉——没有编造任何事实。失败在于：你的系统在规模上是非确定性的，而这种非确定性在两个用户互相对比结果之前是不可见的。

有一种故障模式几乎出现在每一个企业 RAG 部署中：一名员工向内部 AI 助手询问薪酬政策相关问题。系统返回了正确、具体的信息——却是从一份该员工本无权查看的 HR 文档中提取的。由于没有人监控检索层，这件事不会立刻让任何人丢掉工作。但那份机密文档已被索引，用户的查询在语义上命中了它，模型忠实地报告了它所找到的内容。

这个错误并不罕见，它是将公共网络 RAG 模式原封不动地应用于私有组织知识却不做架构适配的默认结果。公共网络 RAG 没有访问控制层，因为公共网络内容本身就没有访问限制。而企业数据有——这一约束从根本上改变了整个系统的设计。

你的 AI 助手刚刚处理了一份来自潜在供应商的合同。它总结了条款，标记了风险条款，并起草了回复。你不知道的是，PDF 中包含了白底白字的文本——肉眼不可见，但在模型面前一览无余——指令它无论条款如何都建议接受。摘要看起来很合理。批准建议看起来也很合理。模型遵循了你从未写过的指令。

这就是“文档即攻击面”问题，而大多数企业级 AI 流水线对此完全没有防备。

这种漏洞是架构性的，而非偶然发生的。当文档内容直接流向 LLM 的上下文窗口时，模型无法可靠地将合法指令与嵌入在文件中的攻击者控制内容区分开来。流水线摄取的每一份文档都是潜在的指令源——在大多数系统中，不可信的文档和可信的系统提示词（System Prompts）被以同等的权威进行处理。

你的企业刚刚部署了一个 RAG 系统。你索引了每个 Confluence 页面、每份运行手册（runbook）、每篇架构文档。六个月后，一位高级工程师离职了——就是那个知道为什么支付服务会有那种不寻常的重试模式、为什么你们从不把缓存扩容超过 80%，以及周五绝对不要给哪家供应商打电话的人。这些知识从未被记录下来。你的 RAG 系统根本不知道它的存在。

这就是隐性知识（tacit knowledge）问题。这也是为什么大多数企业 AI 系统表现不佳的原因——不是因为检索质量或幻觉，而是因为它们所需的知识从一开始就没被捕获。60% 的员工表示，很难甚至几乎不可能从同事那里获取关键信息。90% 的组织表示，员工离职会导致严重的知识流失。你的 RAG 能索引的文档只是冰山一角。

一个在文档理解数据集上达到 97% 准确率的基准测试结果看起来非常有说服力，直到你针对公司的实际发票存档运行它，才发现它正在静默地搞乱 30% 的行项目。模型不会报错，也不会返回低置信度，它只是产生了一个看起来合情合理但却是错误的输出。

这是生产级文档 AI 的典型失效模式：静默损坏 (silent corruption)。与崩溃或异常不同，静默损坏会发生传播。乱码的单元格流入下游聚合，聚合信息喂给报告，报告驱动决策。当你意识到问题时，追踪根本原因就像是在搞考古。

文档 AI 在基准测试表现与生产环境表现之间的差距是真实存在的、持久的，且被评估这些模型的团队所低估。理解为什么会存在这种差距——以及如何防御它——正是本文要解决的工程问题。

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

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

你的团队花了三个迭代周期标注了5万条领域样本。你在前沿模型上运行了LoRA微调。评估指标提升了。然后一位同事稍微改变了提示词的措辞，模型又回到了你以为已经抑制的行为。这不是数据集问题——这就是预训练的阴影。

实践者不断重新发现的核心洞察是：微调教会模型如何在新语境中说话，但无法改写模型根本知识或倾向。在预训练期间编码的行为、偏见和事实先验是一个引力场——微调只能在其周围轨道运行，很难真正逃脱。

大多数团队认为内部 AI 工具比面向客户的 AI 产品需要更少的安全工作。这个逻辑看起来很明显：员工是受信任的用户，爆炸半径是可控的，你随时可以通过一条 Slack 消息来修复问题。这种直觉是危险的错误。内部 AI 工具往往需要更多的安全工程——只是完全不同的类型。

去年报告了 AI 智能体安全事件的 88% 的组织，大多数并非通过面向客户的产品受到攻击。这些事件来自拥有对业务系统的环境权限、访问专有数据以及隐式信任员工会话的内部工具。

你的公司花了六个月构建了一个内部 AI 聊天机器人。演示非常令人印象深刻——高管们频频点头，试点团队赞不绝口，甚至有人在 Slack 的一条消息中称之为"变革性的"。上线三个月后，你查看了分析数据：12% 的周活跃用户，而且其中大多数还是最初试点的那五个人。

这就是内部 AI 工具陷阱，几乎每家企业都会掉进去。工具本身没问题，技术是可靠的。但没人用它，因为你建了一个目的地，而你本应建一个交汇点。