83 篇博文 含有标签「llm」

大多数 LLM 延迟建议往往会陷入以下两种失败模式之一：要么关注错误的指标，要么推荐的优化过于依赖特定硬件，除非你运行自己的推理集群，否则难以应用。如果你是基于托管 API 或受管推理提供商进行构建，那么这类建议中的大部分都是噪音。

本文专注于真正能产生影响的因素 —— 无论你是否控制整个技术栈，这些技术都适用，且基于生产数据而非基准测试的实验室条件。

这里有一个会让团队措手不及的数学问题：如果你堆叠五个防护栏，且每个的准确率都是 90%，那么你的系统整体正确率并不是 90%——而是 59%。堆叠十个同样准确率的防护栏，正确率会降至 35% 以下。这种复合误差问题意味着，“添加更多防护栏”可能会让系统比添加更少但经过更好校准的系统变得更不可靠。大多数团队只有在搭建了庞大的内容审核流水线，并眼睁睁看着误报率攀升到用户无法忍受的程度后，才会意识到这一点。

对于生产环境的 LLM 应用来说，防护栏并非可选项。在正常条件下，现实世界中大约 31% 的 LLM 回答会出现幻觉，而在法律和医学等受监管领域，这一数字会攀升至 60%–88%。针对现代模型的越狱攻击成功率从 57% 到接近 100% 不等，具体取决于攻击技术。但是，如果将防护栏仅仅视为一种附加的合规复选框，而不是精心设计的子系统，团队最终得到的系统将不断拦截合法请求，却仍然漏掉对抗性攻击。

大多数 LLM 质量问题并非提示词（Prompt）问题。它们是上下文（Context）问题。

你花了数小时打磨完美的系统提示词。你添加了 XML 标签、思维链指令和精细的人设定义。你在一些输入上进行了测试，效果看起来很棒。然后你上线了产品。两周后，你盯着一个工单发呆：智能体一本正经地告诉用户错误的账户余额 —— 因为它检索到了前一个用户的交易记录。模型完美理解了指令，它只是拿到了错误的输入。

这就是提示词工程（Prompt Engineering）与上下文工程（Context Engineering）之间的核心区别。提示词工程问的是：“我该如何措辞？”上下文工程问的是：“模型现在需要知道什么，以及我如何确保它准确获得这些信息？”前者是文案写作，后者是系统架构。

大多数团队在发布他们的第一个 LLM 功能后，会在生产环境中因糟糕的输出而受挫，然后紧急加上护栏进行损害控制。结果是一个脆弱的系统，它会阻止合法的请求，减慢响应速度，并且在关键的边缘情况下仍然失效。护栏值得做好——但天真的方法会以你意想不到的方式伤害你。

以下是实际的权衡取舍，以及如何构建一个不会悄悄破坏你产品的护栏层。

大多数团队在微调的时机上不是太早就是太晚。过早进行微调的团队会花费数周时间在训练管道上，结果却发现一个更好的系统提示就能解决问题。而等待太久的团队则在数百万个重复任务上运行昂贵的 70B 推理，同时接受着一个微调后的 7B 模型能以十分之一的成本击败的准确性。

决策的关键不在于哪种技术“更好”。而在于根据你的具体限制条件——数据量、延迟预算、准确性要求以及任务定义的稳定性——选择合适的工具。下面将介绍如何进行思考。

大多数工程师学习提示工程都是倒着来的。他们从“发挥创意”和“一步一步思考”开始，反复迭代一个演示直到它奏效，然后在生产环境中发现模型有 15% 的时间在“幻觉”（胡编乱造），他们的 JSON 解析器每隔几小时就会抛出异常。让聊天机器人令人印象深刻的技术，往往不是让生产系统可靠的技术。

在将 LLM 功能部署到真实系统一年后，以下是真正区分有效提示和在负载下仍能保持稳定的提示的关键。

大多数在生产环境中部署的多智能体 LLM 系统，在几周内就会失败 — 失败并非源于基础设施中断或模型退化，而是因为从一开始就存在的协调问题。对七个开源框架的 1,642 条执行轨迹进行全面分析后发现，在标准基准测试中，其故障率在 41% 到 86.7% 之间。这不是模型质量问题，而是系统工程问题。

令人不安的发现是：约 79% 的故障可追溯到规范和协调问题，而非计算限制或模型能力。即使你换一个更好的模型，你的多智能体管道仍然会以同样的方式崩溃。要理解其原因，你需要仔细审视故障分类。

LLM 在生产环境中函数调用失败最令人惊讶的地方在于它们的来源。不是幻觉推理。也不是模型选错了工具。代理不稳定的首要原因在于参数构造：错误的类型、缺少必填字段、格式错误的 JSON、幻觉出的额外字段。模型本身没问题。你的 schema 才是问题所在。

这是个好消息，因为 schema 修复成本很低。

每次 AI 产品演示看起来都很棒。模型生成了一些貌似合理的内容，利益相关者频频点头，每个人都带着乐观的情绪离开会议。然后产品发布了，真实用户出现了，事情开始以没人预料到的方式走向下坡路。团队手忙脚乱地修复一个故障模式，却无意中制造了另一个，经过数周的“打地鼠”后，提示词已经变成了一个 2000 个 token 的庞然大物，没人再能完全理解它了。

根本原因几乎总是相同的：没有评估系统。那些发布可靠 AI 产品的团队很早就构建了评估系统，并将其视为基础设施，而不是事后才考虑的事情。那些停滞不前的团队则将评估视为“等产品更成熟了”才需要担心的事情。到那时，他们已经陷入困境。

大多数 AI 团队在产品发布六周后都会遇到同样的瓶颈。最初的演示令人印象深刻，原型按时交付，早期用户也褒奖有加。然而，"足以展示" 和 "足以留住用户" 之间的鸿沟变得无法避免。团队手忙脚乱——调整提示词、更换模型、添加防护措施——但产品却几乎纹丝不动。

那些真正能快速改进的团队有一个反直觉的习惯：他们花在架构上的时间较少，而花在审视数据上的时间更多。不是仪表盘。不是汇总指标。而是对话日志中那些原始的、糟糕的、单独的失败案例。

这是一份实践指南，旨在区分快速发展的 AI 团队和停滞不前的团队。

第一次一个 AI 编程代理破坏了一个团队的 CI 流水线——不是因为它编写了糟糕的代码，而是因为它生成拉取请求的速度超过了 GitHub Actions 的处理能力——这清楚地表明一些根本性的东西已经发生了转变。我们不再讨论一个更智能的自动补全工具。我们讨论的是一种完全不同的软件生产模式。

AI 辅助编程的发展轨迹迅速。自动补全工具改变了个人打字的方式。本地代理改变了单个会话能完成的任务。云代理现在正在改变团队构建软件的方式——将工作并行化到多个异步线程中，在提交 PR 之前运行测试，并且越来越多地处理长达 3 小时的任务，而开发人员则可以休息或转去解决其他问题。

大多数 AI 团队都在错误地衡量事物，使用错误的方式，并且让错误的人参与其中。典型的评估设置是这样的：一个 1 到 5 的李克特量表，少量示例，以及一个初级工程师进行数据统计。然后有人会构建一个 LLM 评判者来自动化这个过程——六个月后却想不明白为什么整个系统漏洞百出。

如果方法得当，将 LLM 用作评判者是一种强大的模式。但“方法得当”这个词在句子中承载了大量工作。本文是一个具体的指南，教你如何构建与实际质量相关联、捕获真实回归问题并经受住生产环境考验的评估器。