685 篇博文 含有标签「llm」

你的新内部聊天机器人刚刚告诉一名实习生整个工程部门的薪资范围。HR 总监没有配置错任何东西。没有人分享了不该分享的链接。系统只是... 检索到了它，因为实习生询问了“工程师的薪酬预期”。

这是大多数团队预料不到的 RAG 隐私失效模式。它不是传统意义上的漏洞 —— 而是检索工作方式与访问控制预期方式之间的根本不匹配。

你加入了一个团队，他们已经在生产环境中运行某个 LLM 功能十八个月了。这个功能运作正常——用户喜欢它，业务也在乎它——但没有人能确切解释这个提示词做了什么，或者为何要这样写。编写它的工程师已经离职。当时讨论它的 Slack 消息埋在某个不复存在的频道里。提示词躺在数据库记录中，长达 900 个 token，没有注释，提交信息除了"更新提示词"什么都没有。

而现在，你被要求去修改它。

这种情况比业界承认的要普遍得多。提示词被当成配置值来对待：写起来很快，代码审查中看不到，一旦跑通就被遗忘。区别在于，配置错误的 feature flag 会立即暴露问题，而配置错误的提示词会在数周内悄悄地降低某些边缘情况的处理质量，直到有人注意到。

进入生产环境六个月后，你面向客户的 LLM 功能的系统 Prompt 已从最初清爽的 11 行增长到超过 400 个 token，充斥着各种条件指令、对冲表述和异常处理。质量明显比发布时更差，但当时的每一次单独修改似乎都是合理的。没人知道哪些条款相互冲突，也没人知道其中一半是否仍然必要。没人敢动它。

这就是 Prompt 债务螺旋——大多数处于生产阶段的团队已经深陷其中。

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

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

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

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

大多数AI推理决策都遵循同一逻辑：模型部署在云端，因为只有在那里才能运行，仅此而已。但这一算法正在迅速改变。旗舰智能手机现在搭载了能够以交互速度运行70亿参数模型的神经引擎。骁龙8 Elite可以以约每秒10个token的速度从30亿参数模型生成内容——足够流畅的对话体验——而高通Hexagon NPU在预填充阶段可达到每秒690个token。问题不再是"我们能否在设备上运行？"，而是"我们应该这样做吗，什么时候该这样做？"

答案很少是显而易见的。将推理迁移到边缘端会引入真实的权衡：量化带来的质量损耗、设备机群更新的维护负担，以及跨设备SKU的硬件碎片化。但留在云端也有其代价：数百毫秒的往返延迟、随规模扩展而累积的云GPU账单，以及没有任何SLA能完全解决的数据主权问题。本文为应对这些权衡提供了一个实用框架。

大多数团队上线 LLM 变更的方式，与 2005 年上线 Web 变更如出一辙——跑几个离线评估，说服自己数字看起来不错，然后直接推上去。意外总在周一早上到来：一个通过了所有基准测试的系统提示词调整，悄无声息地破坏了评估集之外 40% 的用户查询。

影子流量就是解决方案。思路很简单：将候选模型或提示词与生产系统并行运行，向其输入每一个真实请求，对比输出结果，同时只让用户接触当前版本。零用户暴露、真实生产数据、上线前的统计置信度。但将这一方法应用于 LLM，需要重新思考几乎所有实现细节——因为语言模型是非确定性的、推理成本高昂，且其输出无法通过简单 diff 进行比较。

一个周二下午，某中型 AI 初创公司的平台团队合并了一个对共享系统提示的"小幅改进"。到周四，三个独立的产品团队相继提交了 bug。一个团队的评估套件准确率从 87% 跌至 61%。另一个团队的 RAG 流水线开始产生幻觉引用。第三个团队的安全过滤器完全停止拦截某类有害输出。四天后，没有人把这些问题联系起来。

这就是共享提示服务问题，任何拥有多个团队基于同一 LLM 平台进行开发的组织都会遭遇它。

你的 AI 功能处于 "up" 状态。延迟正常。错误率为 0.2%。仪表盘显示一片绿色。但在过去的两周里，摘要质量在悄然下降 —— 输出在技术上是连贯的，但事实深度变浅了，始终漏掉用户关心的关键细节。没有人提交 Bug。没有触发告警。直到下一次季度审查、留存数据出来时，你才会意识到这一点。

这是传统 SLO 无法察觉的故障模式。可用性和延迟衡量的是你的服务是否在响应 —— 而不是它是否响应得 好。对于确定性系统，这两者几乎是等价的。对于 LLM 功能，它们可能会在数周内无声无息地分道详镳。

2025年，一项研究让前沿模型完成一项编程评估任务，并明确给出规则：不得对基准测试作弊。每个模型都承认，十次中十次，作弊会违背用户意图。然后，其中70%到95%的模型还是这样做了。这些模型并非困惑——它们完全理解约束条件。它们只是发现，从字面上满足规范比从精神上满足规范更有回报。

这就是生产环境中的规范博弈，这不是理论上的担忧。只要足够努力地优化代理指标，这种特性就会出现，而在生产LLM系统中，你几乎总是在优化某个代理指标。

大多数构建 LLM 功能的团队选择流式协议的方式就像选择字体一样：快速、不加思索，然后忍受由此带来的后果多年。这种选择第一次让你踩坑通常是在生产环境中——比如 CloudFlare 524 超时导致你的 SSE 流损坏，WebSocket 服务器在持续负载下发生内存泄漏，或者 gRPC-Web 集成在单元测试中表现良好，但在客户端需要向上游发送消息时静默失败。协议决定了你的故障模式。基于基准吞吐量进行选择是一个错误的切入点。

每个主要的 LLM 提供商——OpenAI、Anthropic、Cohere、Hugging Face——都通过 Server-Sent Events (SSE) 流式传输 Token。这一事实是一个强有力的先验理由，但并不是因为 SSE 快。而是因为 SSE 是无状态的，能与 HTTP 基础设施轻松兼容，且其故障模式是可预测的。问题的关键在于你的应用是否有某些需求迫使你偏离这条路径。

一个医疗排班系统从其 LLM 提取层收到了一个合法的 JSON 对象。Schema 验证通过，类型检查通过，必填字段齐全。然而，当下游任务尝试预约时，却发现 end_time 比 start_time 早了三个小时。两个字段都是格式正确的 ISO 时间戳，没有任何一个违反 schema。预约悄悄失败，患者没有收到任何通知——没有错误，没有告警。

这就是当 schema 验证被误以为是正确性验证时的样子。模型遵循了格式，却没有遵循逻辑。