AI 工程:当模型不再稀缺,工程能力成为关键

《AI工程》强调,在基础模型时代,工程能力比模型本身更重要,AI 工程是一门系统工程。

原文标题:前英伟达工程师 Chip Huyen :当模型不再稀缺,工程能力才是真正的分水岭

原文作者:图灵编辑部

冷月清谈:

《AI工程》一书指出,随着基础模型的普及,AI 工程的核心已从训练模型转向适配、组合、评估和部署现有模型。这标志着 AI 工程从传统的机器学习工程延伸为一门质变的新学科。该书强调 AI 应用的失败往往源于系统设计不成熟,而非模型本身。书中探讨了 Prompt Engineering、RAG、Finetuning 等关键技术,以及如何评估生成模型和控制推理成本。本书适合已经或准备使用大模型的工程师、技术团队以及需要理解 AI 系统整体逻辑的产品与技术负责人阅读,旨在帮助读者了解如何在基础模型时代负责任、稳定、可持续地应用 AI。

怜星夜思:

1、文章提到“AI 应用失败,往往不是因为模型不够好,而是因为系统设计不成熟”,你认为在 AI 项目中,除了模型本身,还有哪些因素容易导致项目失败?
2、文章提到 Prompt Engineering 和 RAG 技术,你认为 Prompt Engineering 在实际应用中最大的挑战是什么?RAG 如何弥补大型语言模型的不足?
3、文章提到评估生成式 AI 的挑战,你认为目前有哪些可行的评估方法?如何构建更贴近真实使用场景的评估体系?

原文内容

在生成式 AI 成为行业基础设施的今天,关于如何把 AI 真正用起来的问题,已经比如何训练一个更大的模型更为迫切。

前英伟达工程师 Chip Huyen 的《AI工程》,正是在这样背景下出现的一本书。与其说它是一本讲 AI 技术的书,不如说它是在为一个正在成形的新工程范式正名——AI Engineering

从机器学习工程到 AI 工程

在很长一段时间里,AI 工程几乎等同于机器学习工程:数据收集、特征工程、模型训练、评估、部署,一套流程高度依赖专业团队和重型基础设施。

而 Huyen 明确指出,这套逻辑正在被打破。

基础模型(foundation models)普及之后,AI 应用的核心工作不再是训练模型,而是如何适配、组合、评估并部署已经存在的强大模型。工程师面对的,不是一个需要从零开始学习的函数逼近问题,而是一个需要被精细调教的复杂系统。

这正是《AI工程》的立场所在:“AI 工程不是传统机器学习工程的延伸,而是一门在实践层面已经发生质变的新学科。”

基础模型改变了什么?

基础模型的意义,并不只在于它们更大、更强,而在于它们具备跨任务泛化能力。一个模型,可以同时用于问答、总结、代码生成、信息抽取,甚至跨模态任务。

更重要的是,这些模型通常以 API 形式存在。

这意味着,AI 能力第一次从研究机构与大型公司专属,变成了任何开发者都可以调用的公共能力。AI 工程的门槛由此被显著降低,小团队甚至个人,也能构建具备相当复杂度的 AI 应用。

Huyen 清醒地意识到:“当模型不再稀缺,工程能力才是真正的分水岭。”

不是调模型而是做系统

AI工程》一书中反复强调的一点是:“AI 应用失败,往往不是因为模型不够好,而是因为系统设计不成熟。”

因此,书中大量篇幅并不集中在模型结构或训练细节上,而是讨论以下问题:

  • 如何通过 Prompt Engineering 精确引导模型行为

  • 如何用 RAG(检索增强生成) 弥补模型知识边界

  • 在什么情况下才值得进行 Finetuning

  • 如何评估生成模型,而不仅仅是计算准确率

  • 如何控制推理延迟与成本,使系统可持续运行

这些内容共同指向一个事实——AI 工程是一门系统工程,而不是算法竞赛。

评估是生成式 AI 的硬骨头

在评估问题上,Huyen 的态度尤为务实。

她明确指出,传统机器学习中常用的指标,在生成式模型面前往往失效。一个回答可能语法完美、逻辑顺畅,却完全是幻觉。

因此,AI 工程必须建立更贴近真实使用场景的评估体系,包括功能正确性、相似度、人类反馈以及成本与延迟等现实约束。

这部分内容,或许不是最炫技的,但却是整本书中最具工程价值的部分之一。

谁适合读?

《AI工程》的目标读者非常明确:

  • 已经在使用或准备使用大模型的工程师

  • 希望将生成式 AI 投入生产环境的技术团队

  • 需要理解 AI 系统整体逻辑的产品与技术负责人

对于完全没有机器学习背景的读者来说,书中部分章节(如微调与数据工程)仍然存在一定门槛。但对于知道模型是什么,却不知道如何把它变成产品的人而言,这本书提供的,正是长期缺失的那块拼图。

如果说过去十年的 AI 书籍,主要在回答模型如何变得更聪明,那么《AI工程》关注的,是另一个更现实的问题:“当模型已经足够聪明,我们该如何负责任、稳定、可持续地使用它?”

在基础模型成为默认选项的时代,这本书不仅是一本技术读物,更是一份关于 AI 工程思维方式的宣言。

我作为一个后端工程师,认为是可观测性。AI系统很多时候像一个黑盒,出了问题很难排查。如果没有完善的日志、监控和告警机制,根本不知道哪里出了问题,更别提优化了。

尤其是对于生成式AI应用,评估模型的输出质量本身就是一个挑战。没有可观测性,就无法有效地进行模型评估和改进。

所以,在系统设计初期就要充分考虑可观测性,埋好各种监控探针,以便及时发现和解决问题。

可以从更宏观的角度来看这个问题。一个AI项目的失败,除了技术层面,往往还涉及到组织结构、人才储备、以及对风险的评估。如果公司高层对AI的理解不够深入,或者缺乏相应的配套资源和人才,即使技术方案再完美,也难以成功落地。

构建更贴近真实使用场景的评估体系,关键在于模拟真实的用户行为和反馈。可以考虑建立一个用户反馈循环,让用户对模型生成的答案进行评价,并利用这些评价来优化模型。此外,还可以使用模拟用户来自动测试模型在不同场景下的表现。

评估生成式 AI 确实是个难题。光看准确率肯定不行,得结合实际应用场景。我觉得可以考虑 A/B 测试,让用户来投票哪个结果更好。另外,还可以引入人工评估,比如请专家对生成的内容进行打分。当然,成本也是个问题。

Prompt Engineering最大的挑战在于如何设计出既能激发模型潜力,又能避免其产生有害或不正确信息的 prompt。这需要对模型的内部机制有深入的了解,并且不断进行实验和迭代。RAG 通过检索外部知识库,为大型语言模型提供更全面的信息,有效缓解了模型幻觉问题,并使其能够回答超出其训练范围的问题。

Prompt Engineering的挑战在于平衡通用性和特异性。太通用的prompt效果可能很一般,太特异的prompt泛化能力又差。RAG相当于给大模型外挂了一个“搜索引擎”,让它在回答问题前先查阅相关资料,避免瞎编乱造。相当于给它开了个作弊器,考前抱佛脚,但确实有效。

除了传统的指标外,我认为可以从以下几个方面入手:1. 评估生成内容的多样性,避免模型生成过于保守或重复的答案;2. 考察模型是否能够处理不同的输入风格和领域;3. 评估模型在处理对抗性输入时的鲁棒性;4. 建立一个包含各种使用场景的数据集,并定期对模型进行评估。

文章说的很有道理!模型再牛,系统拉胯也白搭。我觉得还有几个坑:一是数据质量,脏数据会直接毁掉整个流程;二是需求理解偏差,做的东西根本不是用户想要的;三是团队协作,各自为战效率低下;四是成本控制,烧钱太快项目直接GG。

Prompt Engineering最大的挑战我觉得是“玄学”。同样的 Prompt,换个模型,结果可能天差地别。而且Prompt的编写很大程度上依赖经验和直觉,缺乏一套通用的、可解释的指导原则。这导致了Prompt Engineering的成本很高,而且难以复用。

从我的经验来看,除了模型和系统架构,还有以下几点值得注意:1. 缺乏清晰的业务目标和 KPI,导致项目方向跑偏;2. 过度追求技术而忽略用户体验,最终产品无人问津;3. 低估了数据安全和隐私保护的重要性,容易引发法律风险;4. 没有建立有效的监控和反馈机制,无法及时发现和解决问题。