678 篇博文 含有标签「ai-engineering」

大多数在大语言模型（LLM）之上构建 SaaS 产品的团队都是通过惨痛的教训才发现多租户问题的：他们利用单一的共享提示词配置快速出海，然后惊恐地发现一个客户的系统提示词泄露到了另一个客户的响应中，或者某个企业级客户耗尽了所有人的速率限制，亦或是当月 AI 账单寄来时，根本无法确定是哪个客户造成了 40% 的支出。这种失败模式并非停留在理论层面——NDSS 2025 的一篇论文证明，vLLM、SGLang、LightLLM 和 DeepSpeed 中的前缀缓存（prefix caching）可以被利用，仅通过时间信号和精心构造的请求，就能以 99% 的准确率重建另一个租户的提示词。

构建多租户 AI 基础设施与传统数据库的多租户化并不相同。共享组件——推理服务器、KV 缓存、嵌入流水线、检索索引——每一个都面临独特的隔离挑战。这篇文章涵盖了你实际必须解决的四个问题：隔离、定制、成本归因以及单租户质量追踪。

大多数构建AI智能体的团队在投产三个月后都会发现同一个问题：他们精心设计的评估套件——围绕文本输入和JSON输出构建——当智能体遇到模糊的发票、扫描合同或从未见过的UI截图时，毫无参考价值。纯文本评估通过了，但用户提交了工单。

多模态输入不仅仅是另一种需要接入的模态，它们引入了一类截然不同的故障，需要不同的架构决策、不同的成本模型和不同的评估策略。将视觉能力视为对现有文本智能体的即插即用扩展的团队，无一例外地低估了所需的工作量。

大多数采用多模态AI的团队都会犯同样的错误：他们在精心策划的基准数据集上评估模型，并假设生产性能会与之相符。然而现实并非如此。视觉模型在MMMU基准上取得高分，与同一模型在生产中可靠地从发票中提取结构化数据之间，存在足以葬送产品发布的巨大差距。视觉编码器增加了基准排行榜上无法体现的延迟。空间推理在用户实际发送的图表类型上失效。在干净语音上表现良好的音频模型在真实世界的噪声下土崩瓦解。而多模态真正优于纯文本的任务类别，比供应商所暗示的要窄得多。

本文是关于这一差距的实战指南——它在哪里出现，为什么存在，以及哪些部署模式能在生产负载下保持稳定。

你的 AI 功能发布时准确率为 92%。团队举杯欢庆。三个月后，进展陷入停滞 —— 尽管投入了更多数据、更多算力和两次模型升级，错误率却不再下降。听起来很熟悉吗？

这就是 “90% 可靠性之墙”，这并非巧合。它源于三种力量的交汇：边际准确率提升的指数级成本、可消除误差与结构上不可避免误差之间的区别，以及生产环境中故障的复合放大效应 —— 而这些是基准测试永远无法捕捉到的。不了解自己正在与哪种力量对抗的团队，将会浪费数个季度的时间去试图解决那些根本无法解决的问题。

凌晨两点，你被告警叫醒。延迟上升，错误率飙升。你 SSH 进去，查看日志——什么都没有。没有指向错误部署的堆栈跟踪，没有第 247 行的空指针异常。只有一串模型输出，这些输出在细微之处、以不可预测的方式出了问题——只有当你连续读了 50 条之后，才能意识到这一点。

这就是 LLM 驱动系统中故障的样子。而传统的"告警-分类-修复"循环根本不是为此而生的。

标准值班手册有三个前提假设：故障是确定性的（相同输入，相同的错误输出）、根因是可定位的（某段代码改了，某项资源耗尽了）、回滚是直接的（还原部署，搞定）。这三点在随机 AI 系统中都不成立。同一个提示词会产生不同的输出。根因通常是一个概率分布，而不是某行代码。而且，你根本无法"回滚"一个第三方提供商昨晚悄悄更新的模型。

2024 年某个时刻，一个规律开始在 AI 团队的事后复盘中反复出现："我们去掉 LangChain 重写了，上线速度明显加快了。"这些团队在采用框架时并没有犯技术错误——犯的是时机错误。LangChain 是原型阶段的对路工具，却是第七个月的错误工具。

同样的故事发生了足够多次，现在它有了一个名字：编排框架陷阱。你采用了一个确实能加速早期工作的框架，生产力提升掩盖了不断累积的结构性债务。等到债务浮出水面，你已经深陷于那些本不该被触碰的内部实现之中。

Writer 团队在对其 RAG-MCP 基准进行插桩测试时发现，当 Agent 可以访问大量工具集时，基准工具选择准确率——在无任何特殊处理的情况下——仅为 13.62%。不是 80%，不是 60%，而是 13%。而同一个 Agent，在通过检索增强的工具选择仅暴露最相关子集后，准确率达到了 43%。工具没变，模型没变，唯一变化的是推理时可见的工具定义数量。

这就是工具过载问题，它正在悄无声息地摧毁大规模生产 AI 系统。

大多数工程师认为embedding是安全抽象的——一堆无法被逆向工程的浮点数。这个假设是错误的，而感知与现实之间的鸿沟正是用户数据泄露的地方。

最新研究仅凭文本embedding就实现了超过92%的精确token序列重建准确率——包括完整姓名、健康诊断和电子邮件地址——而无需访问原始编码器模型。这些不是理论攻击。可迁移的逆向技术在黑盒场景下同样有效：攻击者构建一个模仿你的embedding API的代理模型，就可以发动攻击。无论你使用的是专有模型还是开源模型，攻击面都存在。

本文涵盖embedding隐私风险的三个层面：逆向攻击的实际能力、检索管道中访问控制悄然失效的位置，以及能为用户提供适当控制权的架构模式——按用户命名空间、检索时权限过滤、审计日志和删除安全设计。

一位初级产品经理在产品冲刺期间编辑了一个面向客户的提示词，让它"听起来更友好"。两周后，一位后端工程师调整了同一个提示词以修复格式问题。一位机器学习工程师，对这两次更改毫不知情，在一条单独的系统消息中添加了思维链指令，这与产品经理的编辑产生了冲突。这些变更都没有工单，都没有审查人，也都没有回滚计划。

这就是大多数团队管理提示词的方式。在五个提示词时，这令人烦恼。在五十个时，这是一个隐患。

在一百万份干净文档中隐藏五份精心构造的恶意文档，就能对生产级RAG系统实现90%的攻击成功率。这不依赖零日漏洞或密码学破解——只需用纯文本指示模型以与运营者意图不同的方式运行。如果你的防御策略是"在内容到达LLM之前净化输入"，那你已经输了。

框架至关重要。将提示注入视为输入验证问题的团队会构建边界防御：正则过滤器、基于LLM的分类器、输出扫描器。这些有用但不足。真正的问题在于，现代AI系统是组件的组合——检索器、知识库、工具执行器、外部API——每个组件都是有自身攻击面的摄入点。这正是供应链漏洞的定义。

你的 AI 功能上线时，任务成功率达到了 91%。你运行了评估，迭代了提示词，并不断调优，直到达到质量标准。然后你面向全球发布了——三个月后，一名东京的用户提交了一个支持工单，称你的 AI “不太理解”他们的输入。你的日本用户一直都在默默忍受一个比英语用户体验差 15–20 个百分点的功能。你的团队中没有人注意到这一点，因为没有人去衡量它。

这就是提示词本地化债务（Prompt Localization Debt）：你为之构建 AI 的语言与用户所使用的其他每种语言之间不断累积的性能差距。它不会在仪表盘上显现，也不会导致服务中断。它只是静悄悄地制造出二等公民用户。

一家汽车经销商部署了由 ChatGPT 驱动的聊天机器人。几天内，一名用户指示它同意他们所说的任何话，然后提出以 1 美元购买一辆 2024 款 SUV。聊天机器人接受了。经销商随后将其下线。这并非复杂的攻击——只是一个想看看到底会发生什么的人写的短短三句提示词。

在面对普通消费者时，这种好奇心是你最大的安全威胁。内部 LLM 智能体在受控环境中运行，拥有精选的输入和可信的数据。而面向消费者的 LLM 功能默认在对抗性条件下运行：数百万用户中，有许多人正在积极寻找弱点，而随机模型本身并没有“这个用户似乎怀有恶意”的概念。这两个环境所需的安全策略有着本质的区别，而那些将消费者功能视为内部工具的团队终将吸取惨痛教训。