AI 工程的认知误区——2 年里被纠正的 5 个判断

老张2026/4/30大约 9 分钟

AI 工程的认知误区——2 年里被纠正的 5 个判断

适读人群：正在做或准备做 AI 工程的开发者 | 阅读时长：约13分钟 | 核心价值：用真实的错误判断和纠正过程，帮你少走弯路

我不太喜欢写"我学到了什么"这种总结，因为这种文章通常是拿现在的认知去重新包装过去，失去了当时的真实感。

今天这篇我想换个角度：我不只说我现在认为什么是对的，我想说我当时为什么会形成那个错误的判断，以及什么让我改变了想法。

这样才有价值，因为你很可能正处在我当时的那个判断里，而且你有同样充足的理由觉得自己是对的。

误区一："越大的模型越好"

当时的判断和理由

这个判断在刚开始做 AI 工程的时候几乎是公理。GPT-4 比 GPT-3.5 好，这是明摆着的。那就用最好的模型，别犹豫。

我的理由是：模型能力是上限，用最强的能力，出问题的概率最低，后续迭代的空间最大。用弱模型要是效果差，还要换，成本更高。

什么让我改变了想法

第一个触发点是成本。一个生产系统，用 GPT-4 处理所有请求，一个月的 API 费用让 business case 根本成立不了。

但成本问题还可以用"高质量值得高成本"来辩护。让我真正改变想法的是一次对比测试。

我们有一个从用户问题里提取"订单号"的任务，这是一个结构化提取，任务很明确，输入输出格式固定。我对比了 GPT-4o 和 GPT-4o-mini 在这个任务上的效果：

GPT-4o 准确率 97.8%，GPT-4o-mini 准确率 96.9%。

差别只有 0.9%，但成本差了将近十倍。

这让我意识到：模型的能力大小是对任务难度的响应，而不是独立于任务的绝对优势。简单任务上，小模型和大模型能达到几乎相同的效果。大模型的优势只在复杂推理、多步骤任务、需要丰富背景知识的任务上才真正体现。

修正后的判断

任务难度和模型能力要匹配。过度配置（用大模型做简单任务）是成本浪费，不是保险。

实际工程里，我现在的默认做法是：先用最简单够用的模型，测量效果，只有在效果不达标的情况下才升级到更强的模型。

这个做法和软件工程里"过早优化是万恶之源"是一回事，只不过在 AI 工程里，"过早选择大模型"是一种常见的过早优化。

误区二："RAG 能解决所有知识问题"

当时的判断和理由

RAG 是我在 AI 工程里学到的第一个真正重要的技术，我对它的第一印象非常好。大语言模型有知识截止日期？RAG 解决。私有数据无法训练进模型？RAG 解决。需要可追溯的回答来源？RAG 解决。

我当时的判断是：有了 RAG，LLM 的知识局限基本不再是问题。

什么让我改变了想法

第一个破绽是一个看起来简单但 RAG 反复处理不好的查询："我们产品最近有什么更新？"

这个问题对人来说很直觉，但对 RAG 来说是灾难。"最近"是个相对时间概念，向量检索不理解时间关系。知识库里的更新日志按时间分布，RAG 会检索到一堆时间跨度各异的片段，模型不知道哪个算"最近"。

另一个破绽是多跳问题：" A 产品支持的最大文件大小是 B 功能里的多少倍？"这类问题需要从不同文档里找到两个数值，然后做计算。RAG 在检索阶段可能只找到了其中一个，或者找到了两个但没有把它们关联起来。

还有一个更根本的限制：RAG 假设知识是可以被显式文档化的。但很多隐性知识（这个系统为什么这样设计、某个参数调过但没记录的原因）根本不在任何文档里。这类知识，RAG 永远检索不到。

修正后的判断

RAG 是一个非常有价值的工具，但它解决的是"知识库里有明确答案、可以通过语义检索找到"这个子集。以下几类问题 RAG 处理得不好：

时间相关查询（需要理解时间关系）
多跳推理（需要跨文档关联多个信息片段）
计算和比较（需要在检索后做运算）
隐性知识（没有被文档化的经验和规则）
负面查询（"有没有不支持 XX 的情况"，检索通常找不到负面证据）

对这些类型的问题，RAG 需要配合其他技术（如 query rewriting、structured retrieval、knowledge graph），或者承认当前能力边界。

误区三："Agent 会很快成熟"

当时的判断和理由

2023 年初 AutoGPT 爆火的时候，我花了大量时间研究 Agent，认为这是下一个重大的工程方向。Agent 能自主规划、调用工具、完成复杂任务，这在演示里看起来令人震撼。

我当时判断：6-12 个月内，Agent 框架会成熟到可以用于生产环境的程度。

什么让我改变了想法

实际用 Agent 做项目的经历。

Agent 的两个根本问题，两年后仍然没有被工程化地解决：

可靠性问题：Agent 在多步骤任务里的错误累积非常严重。如果每一步有 95% 的正确率，五步之后的总体正确率就下降到 77%（0.95^5），十步之后是 60%，二十步之后是 36%。对于生产系统，这种可靠性是不可接受的。

可控性问题：当 Agent 出了问题，排查非常困难。因为 Agent 的决策过程涉及多次 LLM 调用、多次工具使用，中间的推理过程不完全透明，复现困难。这使得 Agent 系统的维护成本极高。

我参与过一个 Agent 项目，花了两个月上线，然后花了接下来三个月不断修复 Agent 走偏的问题，最终被迫回退到规则式的工作流。

修正后的判断

Agent 技术本身很有价值，但"成熟到可以安心用于高风险生产场景"这件事，比我预期的时间要长得多，甚至可能需要架构层面的新突破。

目前的合理用法是：在有人工监督的场景、低风险任务、或者错误成本低且可恢复的场景里使用 Agent。对于高风险、高准确率要求的任务，仍然应该用可预测的工作流而非 Agent。

误区四："Prompt 工程不是真的工程"

当时的判断和理由

作为一个 Java 工程师，我最开始看 Prompt Engineering 这个词是有点嗤之以鼻的——这不就是写字吗？和真正的工程有什么关系？

我当时的判断：Prompt 工程是个过渡技能，等到 AI 模型更强了，这些工作就没意义了。

什么让我改变了想法

做了几个认真的 Prompt 迭代项目之后。

写一个在生产环境里真正有效的 Prompt，需要的能力包括：

理解任务的边界条件和异常情况
设计鲁棒的输入输出格式
版本控制和 A/B 测试
效果评估和指标设计
对模型行为的深度理解

这每一项，都是真实的工程能力，不比写一个稳定的 API 容易。

让我真正改变想法的是一次 Prompt 迭代经历。我在优化一个代码解释的 Prompt，花了三周时间，跑了 47 个版本，最终版本在测试集上的准确率从 71% 提升到 89%。这个过程里涉及的系统性测试方法、版本追踪、指标设计，完全是工程方法论，不是"调调字眼"。

如何在 LLM 调用失败时降级？（fallback strategy）
如何控制 API 成本在预算内？（cost management）
如何设计评估管道，持续监控模型效果？（eval pipeline）
如何处理 Prompt 注入攻击？（security）
如何设计 context window 的使用策略？（token management）
如何处理长会话的记忆管理？（memory management）
如何保证生产系统的延迟在可接受范围内？（latency optimization）

每一个问题都是独立的工程挑战，需要认真的设计和实现。

修正后的判断

AI 应用的工程复杂度主要在后端，而且是新的、教科书里没有的复杂度。前端体验确实重要，但工程护城河在后端。

写这篇文章的过程里，我想到了一件事：这五个误区，每一个在当时都有看起来合理的理由。形成这些误区不是因为我不用心，而是因为当时的信息不完整，或者当时的状态还没有给出反驳这些判断的证据。

所以对你在读这篇文章时的认知，我也是同样态度——你现在的判断，可能有一部分是对的，有一部分是明天会被证伪的。保持这种不确定感，是 AI 工程里最有价值的心态。