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

大多数团队在保护 RAG 应用时，把精力放错了地方。他们验证用户输入、清洗查询语句、实施访问频率限制、添加输出过滤器。这些措施固然必要——但没有一项能阻止 RAG 系统中最关键的那类攻击。

大多数团队在调优 RAG 系统时关注两个杠杆：分块策略和嵌入模型选择。当检索质量下降时，他们重新分块；当召回率数据不好看时，他们升级嵌入模型。这两步都合理——但它们在优化流水线的中间环节，却让最高杠杆点一直没有触及。

用户的查询几乎从来不是向量检索的理想形式。它简短、口语化、模糊，或者假设了索引中并不存在的上下文。无论你的嵌入有多好，如果你用一个表述糟糕的查询来搜索，检索结果就会很差。解决方法不在下游——而是在查询命中向量索引之前对其进行变换。

大多数团队引入护栏的方式，和引入日志一样随意：直接挂上去，以为代价很小，然后继续往下走。但代价并不小。一次内容审核检查要花 10–50ms，再加上 PII 检测，又是 20–80ms；再叠上输出 schema 校验和毒性分类器，在第一个 token 到达用户之前，串行开销就已累积到 200–400ms。加上 500ms 的模型响应，你那个"快速"的 AI 功能现在给人的感觉就是迟钝。

把锅甩给 LLM 是错的。护栏才是瓶颈。解决方案不是去掉安全措施，而是停止把安全检查当成一堆无差别的任务，改用架构思维来对待它。

Spider 基准测试看起来很棒。GPT-4 在数百个测试查询中的 text-to-SQL 转换得分超过 85%。团队看到这些数字，配置好 LangChain 的 SQLDatabaseChain，然后上线“询问你的数据”功能。两周后，一位分析师关于按地区划分收入的无心提问触发了全表扫描，导致报表系统宕机 30 分钟。

基准测试数字是真实的。问题在于，基准测试不使用你的模式 (schema)。

Spider 1.0 在包含 5–30 个表和 50–100 个列的数据库上测试模型。而你的生产数据仓库有 200 个表、700 多个列，根据你查询的系统有三种 SQL 方言，以及在四年前编写代码的工程师看来有意义，但对其他任何人来说都毫无意义的列名。当研究人员推出 Spider 2.0——一个具有企业级规模 schema 和现实复杂性的基准测试时——GPT-4o 的成功率从 86.6% 下降到 10.1%。这种断崖式下跌才是生产环境的真实写照。

大多数工程师在生产中而非设计评审时发现他们的会话架构是错误的。演示运行良好：你用五条消息进行了测试，对话历史可以放入内存，LLM 也能连贯地响应。然后你上线了，在第一批千个并发会话与第一次部署滚动之间，用户开始遇到上下文遗忘、部分响应或会话无故重置的问题。让聊天功能原型设计变得简单的内存模式，正是使其在运营中变得脆弱的根源。

这并不是一个微妙的架构错误。对话状态与请求状态有着本质区别。请求状态只存活数毫秒；对话状态必须能够在 Pod 重启、水平扩展、部署周期和移动网络中断中存活——持续数分钟、数小时或数天。建立在错误抽象上的系统会产生可靠性债务，随着对话长度增长和用户负载增加而累积。

大多数 AI 产品将上下文限制视为一个对用户隐藏的实现细节。这种决定在演示中看起来很简洁，但在生产环境中却是灾难性的。当用户在执行任务中途达到上限时，通常会发生以下三件事之一：请求抛出硬错误；模型因为丢失了关键的早期上下文而悄悄开始产生幻觉；或者产品重置会话并销毁所有积累的状态。对于一个你要求人们在实际工作中信任的产品来说，这些结果都是不可接受的。

Token 预算并不是一个可以敷衍了事的怪癖。它是一个核心产品约束，应该像内存限制在系统编程中那样，被纳入你的设计流程。交付可靠 AI 功能的团队已经不再假装这个天花板不存在了。

当今大多数招聘 AI 工程师的团队，都在运行一套为一个根本不存在的岗位所优化的面试流程。他们筛查的是 LeetCode 刷题能力，考察候选人对 Transformer 内部机制的了解程度，并给那些能够自信地在白板上画出分布式系统的人加分。然而，这些候选人加入团队后，却在调试幻觉频发的检索流水线时束手无策，并且交付了一个在测试环境中表现完美、在生产中悄然退化的模型集成。

这不是人才问题，而是测量问题。预示 AI 工程成功的技能在传统面试循环中几乎是不可见的——而面试实际测量到的技能，与工作的真实需求相关性极低。

大多数工程团队默认将 AI 功能构建为聊天界面。用户输入内容，模型做出响应。这种模式感觉很自然，因为它映射了人类的对话，而且工具链也让实现变得简单。但当你观察生产环境中的这些基于聊天的 AI 功能时，你经常会看到同样的功能失效：用户界面处于闲置状态，等待着那些太忙、太分心或根本不知道该问什么的用户。

聊天是一种“拉取”（pull）模式。由用户发起，AI 做出反应。对于任何产品中具有价值的 AI 工作的一个重要子集——监控、异常检测、工作流自动化、主动通知——“拉取”模式都是错误的形态。无论用户是否记得打开聊天窗口，这些工作都需要进行。

在峰值流量期间，部分 LLM 提供商的失败率超过 20%。当系统撞上这堵墙，并通过加倍等待时间和重试来应对时，你解决的是一个错误的问题。指数退避处理的是单次调用的韧性，对整个系统毫无作用——无法减少浪费的 token，无法解决连接池耗尽，也无法照顾到排在刚收到 429 响应那个请求后面的 50 个请求。

冲击 LLM API 的流量模式也发生了根本性变化。2023 年到 2025 年间，100 token 以下的简单查询从占流量的 80% 骤降至约 20%，而超过 500 token 的请求则成为持续的多数。Agentic 工作流在短时间内串联 10-20 个顺序调用，产生的流量模式在传统的每分钟请求数（RPM）限速下，与 DDoS 攻击别无二致。为负载可预测的 REST API 构建的基础设施，并不是 LLM 流水线所需要的基础设施。

大多数在 QA 阶段夭折的 AI 项目，死因并非模型不好，而是没有人在构建之前就"好"的定义达成共识。工单里的验收标准往往写着"摘要功能应生成准确、相关的摘要"——当工程师问"准确"是什么意思时，得到的答案是"看到就知道"。这不是行为需求，这是一种期许。

问题在于团队把原本用于确定性软件的需求流程照搬到了本质上具有随机性的系统上。当你为数据库查询写 assertTrue(output.equals("Paris")) 时，测试的通过与否是完全确定的。但把同样形式的断言用在 LLM 上，得到的是一个对所有有效的同义表达都失败、对所有自信的幻觉都通过的测试。单元测试在骗你，而它所依据的规格从来就不是为"生成输出分布而非单一值"的系统设计的。

你构建了一个个性化功能，将其接入应用，然后发布上线。第一周到了。系统尽职尽责地为每个新用户推送同样的几个全局热门内容——你的 AI 号称智能，却连按字母排序的列表都不如。参与度指标几乎没有变化。团队得出结论：模型需要更多调优。其实不然。模型完全按设计运行。问题在于，你要求它在没有任何可学习内容之前就开始学习。

这就是冷启动问题，它摧毁的 AI 功能比糟糕的模型多得多。

核心矛盾是循环的：行为机器学习系统需要用户交互才能产生有用的预测，但它需要产生有用的预测才能获得用户交互。某大型电商平台记录显示，冷启动影响了超过 60% 的新用户——这些用户收到了明显失准的推荐，可测量地损害了转化率。在整体指标中，这一信号几乎不可见，因为活跃用户掩盖了损失。

一家金融科技初创公司在他们的系统提示词中添加了一个逗号。第二天，他们的发票生成机器人开始输出乱码，在有人追踪到原因之前，他们已经损失了 8,500 美元。没有抛出任何错误。没有触发任何报警。应用程序继续运行，虽然错了但很自信。

这就是在生产环境中调试 LLM 的真实样子。没有指向行号的堆栈追踪。没有你可以检查的核心转储（core dump）。系统不会崩溃——它在继续运行的同时，悄无声息地产生降级的输出。传统的调试直觉不再适用。大多数工程师的反应是随机调整提示词，直到看起来好一点，然后基于三个示例进行部署，并称其已修复。结果两周后，问题又以另一种形式浮出水面。

有一种更好的方法。LLM 的故障遵循系统性的模式，而这些模式对结构化的调查有反应。这就是这套方法论。