跳到主要内容

702 篇博文 含有标签「llm」

查看所有标签

“展示过程”的 UX 陷阱:当推理链只是披着产品外壳的调试输出

· 阅读需 11 分钟
Tian Pan
Software Engineer

推理模型会输出思维链(chain-of-thought)轨迹,因为这是它的计算方式。产品团队在 UI 中渲染该轨迹,是因为隐藏它感觉像是丢掉了用户付费购买的 token。这是两个不同的决定,而产品端几乎没有人意识到他们做了第二个决定。于是,轨迹变成了面板,面板变成了功能,功能有了文档页面。六个月后,有人在季度回顾中问,为什么支持队列里全是用户在反驳推理过程,而不是针对答案本身。

推理轨迹本质上是调试输出。它的存在是为了让工程师了解模型为什么选择某个工具、在日期上含糊其辞,或者在段落中间悄悄切换了角色。在没有经过设计审查的情况下将其推给终端用户,等同于在生产环境中留下 console.log 调用并称之为“透明度”。它看起来像个功能,渲染成本几乎为零,但它会以团队构建的任何仪表盘都无法显示的方式悄悄削弱信任。

小模型,大账单:为什么单 Token 成本更低反而更贵

· 阅读需 10 分钟
Tian Pan
Software Engineer

由财务主导的“切换到更小模型”的指令,是让你的 LLM 账单季度环比增长最可靠的方式之一。采购团队盯着的仪表盘——单次调用成本、每次请求的平均 token 数——一直在下降。与此同时,发票金额却在不断攀升。当有人终于把这两者对上账时,团队已经花了六个月的时间进行提示词(prompt)迭代,以补偿那个在任务处理上表现更差的模型,而且团队已经陷得太深,如果不承认最初的切换是个错误,就无法走回头路。

错误不在于定价,而在于计量单位。当推理深度、重试次数和提示词大小都随模型而异时,单 token 价格是一个具有误导性的维度。正确的指标是“单次成功完成所需的 token 数”,在这个维度上,更便宜的模型往往会输。

停止序列的“自毁”陷阱:当用户输入与分隔符发生冲突

· 阅读需 12 分钟
Tian Pan
Software Engineer

一位用户将一段 Markdown 粘贴到你的支持代理中。他们粘贴内容中的第一个标题是 ### Steps I tried。你的提示词模板(prompt template)使用 ### 作为停止序列(stop sequence)。模型尽职地读取了用户的输入,开始回答,并生成了 ### 作为其结构化响应的一部分——结果 API 返回了两句自信的回复,随后便是沉默。工单以“模型质量退化”的名义进入你的队列。其实不然。修复方法只是网关中的一行代码。

停止序列是生产级 LLM 技术栈中极其关键却又常被忽视的调节开关。它们通常是在最初编写提示词的那一周选定的,那时输入还是整洁的工程示例,还没有人粘贴过 JIRA 工单的堆栈信息。十二个月后,用户内容的分布已经远远超出了提示词作者的想象,曾经整洁的分隔符现在变成了潜伏在每三百个用户粘贴中就有一个的隐患。没有任何告警。评估套件(eval suite)依然能够通过。受影响部分的 CSAT 指标下降了 0.5 分并维持在那里。

这不是模型的问题。这是一个伪装成模型问题的输入契约(input-contract)问题,它的形态类似于典型的分布式系统 Bug:为一方的内容分布选择的分隔符被强制应用于另一方的内容分布,且在边界处没有任何监控。

流式结构化输出:为什么你的解析器会在第 47 个 Token 处卡住

· 阅读需 12 分钟
Tian Pan
Software Engineer

团队第一次构建带有结构化输出的流式 AI 功能时,遇到的 bug 总是如出一辙。模型生成正常,数据块(chunks)接收正常。但在第 47 个 token 左右,解析器挂掉了,UI 冻结了,或者更糟——一个半成型的枚举(enum)值被路由到了下游工具,导致其悄无声息地执行了错误操作。团队在 JSON.parse 周围加了一个 try/catch,觉得自己搞定了,然后发布。两周后,兄弟团队抱怨响应变长后流式 UI 感觉很卡。一个季度后,事故审查询问为什么在一个模型仍在描述为 "DeleteIfEmpty" 的记录上触发了 "Delete" 工具调用。

Bug 不在任何单个 token 中。Bug 在于 token 流式传输和结构化输出在架构上是冲突的,而大多数框架只是用“祈祷”来掩盖这种冲突。Schema 说“这是一个完整的对象”。Token 流说“这是一次一个字节的数据”。从定义上讲,这两个端点之间的每一个中间状态对于 Schema 来说都是无效的。团队的工作是决定在这些中间状态期间该做什么——而大多数团队并没有明确做出这个决定。

总结税:当压缩消耗的 Token 超过了它节省的量

· 阅读需 12 分钟
Tian Pan
Software Engineer

一个长时间运行的 Agent 每 12 轮就会达到其压缩阈值。每一次压缩的成本都相当于一次规模等同于当前运行窗口的 LLM 调用——首先是 8K tokens,然后是 14K,接着是 22K——因为被总结的内容跨度随着每次触发而增长。到了第 60 轮,用户在观察 Agent 自我总结上花费的 token,已经超过了在实际推理上花费的 token。成本仪表盘将“用户推理成本”显示为一个单一数字,完全没有意识到其中一半是为用户永远不会再看的上下文压缩而付费的。

这就是“总结税”:一类随着对话长度增加而增长的开销,在用户回合之间悄然触发,并作为一个单一项目出现,将用户付费的工作与系统为自我管理而进行的内务处理混为一谈。这是现代 Agent 架构中最接近“垃圾回收停顿时间(garbage-collection pause time)”的东西——而大多数团队在生产环境中运行时都关闭了 -verbose:gc

每个开放 RAG 系统自带的攻击向量

· 阅读需 11 分钟
Tian Pan
Software Engineer

五份精心设计的文档。260 万条记录的语料库。操纵特定 AI 响应的成功率高达 97%。这是来自 PoisonedRAG 的基准测试结果,该研究发表于 USENIX Security 2025 —— 而且这种攻击不需要模型访问权限,不需要在推理阶段进行提示词注入,甚至不需要与系统进行任何直接交互。攻击者只需向知识库贡献内容即可。

如果你的 RAG 系统允许用户添加内容 —— 服务台工单、Wiki 编辑、客户反馈、共享笔记 —— 那么你已经发布了攻击载体。问题在于你是否也同步发布了防御机制。

孤儿微调:基础模型废弃后如何恢复领域专业知识

· 阅读需 10 分钟
Tian Pan
Software Engineer

2024年1月4日,OpenAI 下线了 /fine-tunes 接口。每一个基于 Ada、Babbage、Curie 和 Davinci 微调的模型都停止了响应。那些花费数月在这些模型上构建生产系统的团队——精心设计的提示、标注的数据集、标签流水线——一觉醒来发现收到的是 HTTP 404。微调模型没有迁移,学到的行为没有迁移,领域专业知识就此消失。

这不是小概率事件。2024年8月,Google 彻底关闭了 PaLM API,没有任何向后兼容的宽限期。与 OpenAI 至少允许现有 GPT-3.5 微调模型继续运行(只是禁止新的训练任务)不同,Google 的关闭意味着生产推理在同一天停止。如果你的微调 PaLM 模型处于关键路径上,你就遭遇了服务中断。

LLM 输出的统计水印:Token Logit 偏置如何创建可检测的签名

· 阅读需 10 分钟
Tian Pan
Software Engineer

自 2024 年 10 月起,Google 已对所有 Gemini 用户的输出进行水印处理 —— 覆盖 2000 万用户,无可感知的质量损失,且可通过算法检测。OpenAI 已有可工作的原型,仅需数百个 token 即可产生可靠的信号。Anthropic 表示已列入路线图。欧盟《AI 法案》第 50 条要求涵盖范围内的提供商以机器可读格式标记 AI 生成的内容。然而:一种每百万 token 成本仅 0.88 美元的攻击,能同时对七种最新水印方案实现约 100% 的规避成功率。

这就是 LLM 文本水印的真实现状。已部署的方案、论文的声明与攻击者的实际能力之间的差距,远比大多数团队意识到的要大 —— 而你对水印的工程决策,很大程度上取决于你站在这个差距的哪一边。

撒谎的 AI A/B 测试:LLM 实验中的新奇效应、结转偏差与锚定偏差

· 阅读需 12 分钟
Tian Pan
Software Engineer

你的 AI 功能在信心满满中上线了。A/B 测试显示用户参与度有了 12% 的统计学显著提升。置信区间没有重叠。样本量大小合适。p 值远低于 0.05。六周后,指标回落到了基准线。三个月后,它实际上已经低于基准线。实验告诉你该功能有效,但实验撒了谎。

这并不是你统计工具的 bug。这是标准 A/B 测试所测量的指标,与人类随着时间的推移与概率性 AI 系统互动之间存在的根本性错配。三种特定的偏差——新奇效应膨胀、锚定偏差和结转偏差——共同导致了每个 AI 功能实验的虚高,而增加留置组(holdout group)的常规补救措施并不能解决其中的任何一个问题。

AI 效率悖论:当你的核心功能扼杀了营收

· 阅读需 10 分钟
Tian Pan
Software Engineer

2026 年初,Atlassian 报告了一件公司历史上从未发生过的事情:企业席位数量下降。对于一家增长模式完全依赖于扩张收入(随着客户组织增长而销售更多席位)的公司来说,这是一个结构性警报,而非偶然波动。直接原因并非客户流失或产品失败。而是 Atlassian 自身的 AI 功能大幅提高了团队效率,以至于完成同样的工作量所需的席位更少了。

这就是 AI 效率悖论:构建一个真正为用户节省时间的功能,你可能正在训练他们减少对你产品的使用。你的 AI 越有用,你的定价模型崩溃得就越快。

故事点在与 LLM 的第一次接触中就会失效

· 阅读需 9 分钟
Tian Pan
Software Engineer

在每一家拥有成熟敏捷实践并决定增加 LLM 功能的公司,都悄然发生着这样一种失败模式:团队用故事点评估工作,将其分配到为期两周的冲刺(sprint)中,然后连续三个冲刺都报告“完成了 70%”,而工程经理则盯着那张拒绝下降的燃尽图发愁。没人撒谎。功能确实很难完成 —— 因为让故事点成为有用规划工具的条件,在 AI 功能中并不存在,而大家直到投入其中才察觉到这一点。

问题不在于工程师不擅长估算。问题在于故事点编码了关于软件工作本质的假设 —— 而 LLM 功能在结构上(而非偶然地)违反了这些假设。

AI 功能依赖图:当多个服务共用同一个模型时的韧性工程

· 阅读需 12 分钟
Tian Pan
Software Engineer

你的 embedding 模型在周二下午 3 点宕机了。不到 30 秒,你的支持聊天机器人停止回答问题,个性化推荐引擎开始返回空结果,文档搜索一无所获,入职助手也停止工作了。你的值班工程师打开事件频道,看到来自 15 个彼此看不出联系的功能同时发出的告警。没有堆栈跟踪指向根本原因。这看起来像是分布式系统故障 —— 但其实不是。这是一个单一的共享依赖项失效了,而你之前并不知道有 15 个功能共享它。

这就是 AI 功能依赖问题:你的产品功能底层的基础设施层是深度互连的,但你的架构图却将每个功能显示为孤立的方框。当耦合是不可见的,故障传播也是不可见的 —— 直到问题爆发。