702 篇博文 含有标签「llm」

一个周二下午，某中型 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 验证被误以为是正确性验证时的样子。模型遵循了格式，却没有遵循逻辑。

大多数团队采用结构化输出，是因为厌倦了用脆弱的正则表达式从模型响应中抽取数据。这个动机合情合理。但他们没料到的是，几个月后当他们真正度量任务准确率时，会发现那次"可靠性提升"同时让推理密集型任务的内容质量下降了 10 到 15 个百分点。语法问题解决了，语义问题却悄然而生。

本文的目的是精确理解这一权衡——约束解码的实际代价是什么、什么时候值得支付这笔税，以及如何在上线前构建评测来判断它是否正在拖累你的系统。

有数据时，微调模型很容易。残酷之处在于产品诞生之前的那个时刻：你需要个性化来吸引用户，但又需要用户才能积累个性化数据。大多数团队要么完全跳过微调（"以后再加"），要么花数周手工收集标注样本。两种方式都行不通。前者产出一个用户一眼就能看穿的通用模型，后者慢到等你有了数据，任务早已演变。

合成种子数据能解决这个问题——但前提是你必须清楚它在哪里会失效。

大多数工程团队在第一次收到账单暴涨时都会发现同一件事：他们的系统提示词已经悄悄增长到4,000个token的精心指令，而模型也悄悄开始忽略其中一半。解决方法很少是添加更多指令，几乎总是删除它们。

追求面面俱到的本能是可以理解的。更多约束感觉像是更多控制。但随着系统提示词膨胀，存在一种可量化的质量下降——而且它与成本的复合方式在造成损害之前并不明显。研究一致发现，在大约3,000个输入token处准确率开始下降，远在达到任何名义上的上下文限制之前。模型不会拒绝遵守；它只是开始以难以查明的方式表现不佳。

本文的目的是使这种退化变得可见，理解其发生原因，并建立一套不需要寄希望于"不会出问题"的精简规范。

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

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

每当一个新的 LLM 功能上线，总会有人问："我们该用多少 temperature？"答案几乎千篇一律："不知道，留着 0.7 吧。"然后对话结束，没有人再碰这个值。

这是一个用默认值做出的产品决策。Temperature 不只是控制模型听起来有多"随机"——它决定了用户是否信任输出、是否会重新运行查询、是否感到被帮助或被淹没。把它调好比大多数团队意识到的更重要；调错了也很难诊断，因为失败的表现看起来像是模型行为差，而不是配置差。

Text-to-SQL 演示看起来出奇地简单：把 schema 粘贴到提示词里，向 GPT-4 提个问题，拿到一条整洁的 SELECT 语句，然后 Slack 里就开始涌现"要不要把这个集成进数据平台？"的消息。等到你真正打算上线时，麻烦来了。基准测试显示 85% 的准确率，但内部数据团队反映大约一半的答案是错的，而安全团队则在追问：生成的查询在执行前有没有经过审查？没人能给出一个像样的答案。

这正是 text-to-SQL 作为研究问题与作为工程问题之间的鸿沟。研究问题关注的是让模型生成语法正确的 SQL；工程问题面对的是 schema 歧义、访问控制、查询验证，以及你的企业数据库根本不像 Spider 或 BIRD 数据集这一现实。

你的ASR系统返回了"the patient takes metaformin twice daily"。正确的词应该是metformin。转录看起来很干净——没有[INAUDIBLE]标记，没有错误标志。那个词的置信度是0.73。你的管道丢弃了这个数字，将干净的文本传给了LLM。LLM将其视为真实情况，围绕一种不存在的药物进行推理。

这就是转录层的谎言：一种隐性假设，认为中间文本表示——无论是由语音识别、OCR还是解析文档的视觉模型产生的——都足够可靠，可以不加保留地向下游传递。事实并非如此。但几乎每个生产管道都将其视为可信来源。