《AI工程:大模型应用开发实战》:大模型时代AI工程方法论

《AI工程:大模型应用开发实战》提供了一套大模型时代 AI 工程方法论,覆盖模型选型、工程实践和闭环优化,助你构建可落地的 AI 应用。

原文标题:前英伟达工程师 Chip Huyen 的 AI 工程方法论!

原文作者:图灵编辑部

冷月清谈:

《AI工程:大模型应用开发实战》一书旨在帮助开发者构建真正可落地的 AI 应用。本书以系统视角解构 AI 应用,覆盖模型层、工程层和闭环层等关键环节,强调长期有效的工程方法论,例如模型选择、服务部署、推理优化、提示词工程、RAG、数据集构建、评估体系、微调和用户反馈循环等。本书区分了 AI 工程与传统 ML 的不同,尤其是在评估方面,生成式 AI 系统更为复杂。本书适合作为长期参考的入门与进阶读物,帮助读者理解在快速变化的时代中相对稳定的工程原则,并为开发者构建优质应用打下基础。

怜星夜思:

1、书中提到了应该优先投入 RAG 还是做微调,大家在实际应用中是怎么选择的?有哪些因素会影响这个决策?
2、书中强调了评估体系的重要性,大家在构建 AI 应用时,都关注哪些评估指标?有没有遇到过难以量化的评估维度?
3、书中提到了 AI 工程与传统 ML 工程的区分,大家觉得最大的区别是什么?这种区别对工程师的技能栈提出了哪些新的要求?

原文内容

很多人调侃,大模型时代的程序员已经变成了提示词工程师。但真正动过手的人都知道,调用一个 API 只是写了一行代码,而要把模型打磨成一个稳定的产品,中间隔着一整个工程世界的鸿沟:评估怎么做?RAG 效果差怎么办?成本和时延如何权衡?

在会调模型,但做不出好应用的普遍焦虑中,Chip Huyen 的这本《AI工程:大模型应用开发实战》显得尤为及时。它讨论的并不只是怎么调用一个模型,而是更完整的问题:在 Foundation Models 迅速成为软件基础设施的今天,我们究竟该怎样构建真正可落地的 AI 应用。

无论是邮件助手、内容编辑工具,还是更复杂的 AI Agent 系统,传统软件正在被重新定义,而这本书恰好提供了一张相对完整的工程知识地图。


01 )

以系统视角解构 AI 应用

这本书的优点首先在于全。它几乎覆盖了当前大模型应用开发中的所有关键环节:

  • 模型层: 模型选择、服务与部署、推理优化。

  • 工程层:提示词工程、RAG(检索增强生成)、数据集构建。

  • 闭环层:评估体系、微调、用户反馈的循环利用。

相比很多只讲 Prompt、只讲 Agent,或者只讲某个特定框架的书,它明显更有体系感

作者没有把 AI 应用理解成几个流行技巧的拼接,而是把它看成一个需要权衡、评估、迭代和扩展的工程系统。这种视角是这本书最有价值的地方。

02 )

授人以渔:更关注长期决策方法论

作者没有把重点押在那些很快会过时的工具和框架上,而是更强调长期有效的方法论这点还是很难得的。书里不断在帮助读者思考一些真正重要的架构决策,比如:

  • 究竟应该调用外部模型 API,还是自建推理服务?

  • 应该优先投入 RAG,还是做微调?

  • 评估体系要怎样建立,才能支撑持续迭代?

这些问题没有标准答案,但作者给出了比较清晰判断框架也正因为如此,这本书更像一本“AI 工程决策指南”,而不只是一本操作手册。

03 )

认知升级:区分 AI 工程与传统 ML

从写作上看,Chip Huyen 依然延续了她一贯的优点:擅长把复杂概念拆开讲清楚,层层推进。书中对 AI Engineering 与传统 ML Engineering 的区分尤其重要。

很多人在谈大模型应用时,容易把模型能力、产品体验和工程实现混成一团。而这本书恰恰提醒我们:围绕 Foundation Models 构建应用,是一个与传统机器学习系统不同的问题领域。尤其在评估这件事上,生成式系统天然更复杂,更难依赖单一指标解决问题。作者对这一点的展开,很能帮助读者建立正确的心理预期。


04 )

阅读建议:它是底层知识的骨架

如果你已经长期关注这一领域,并且看过大量论文解读和技术博客,这本书未必会带来那种颠覆认知的新鲜感。

它更像是把分散在各处的碎片化知识进行了系统化沉淀,帮助你建立结构,而不是不断抛出惊艳的新观点。

对于不同背景的读者:

  • 软件工程师: 非常友好。它不需要你一开始就有深厚的算法背景,对 Finetuning、RAG 等概念都有清晰的铺垫,能帮你建立第一层稳定的知识骨架。

  • 实战派:如果你期待的是一本拿来即用的代码案例集,它可能不完全是那种风格。它更偏向工程思维训练,而非案例驱动教程。

05 )

快速变化的时代,相对稳定的工程原则

总的来说,《AI工程》对我来说是一本非常扎实、适合作为长期参考的入门与进阶读物。它最突出的优点,不是教你追踪热点,而是帮助你理解在快速变化的时代,什么才是相对稳定的工程原则。

这仅仅是一个开始。读完本书后,想要真正构建出优质的应用,开发者依然需要去啃那些硬核知识、深入理解大模型底层机制,并在真实的业务泥潭中去摸爬滚打。它是一道丰盛的开胃菜,但真正的主菜,还需要读者自己在工程实践中去烹饪

入门之后,要进阶成为高手,我觉得得啃啃这些硬骨头:首先是得搞懂Transformer的原理,别光会调API,还得知道模型内部是怎么运作的。然后是得学学怎么优化模型,让它跑得更快、更省钱。最后也是最重要的,得深入理解业务,知道AI能解决什么问题,不能解决什么问题。毕竟,AI只是工具,真正的价值在于解决实际问题。

这本书就像是给了你一张藏宝图,告诉你宝藏大概在哪儿。但要真正挖到宝藏,还得靠自己努力。我觉得需要补的硬核知识包括:1. 线性代数和概率论,这是理解很多模型算法的基础。2. 熟悉至少一种深度学习框架,比如 PyTorch 或 TensorFlow,并且能熟练地使用它们。3. 学习模型压缩和加速技术,毕竟大模型部署成本很高。更重要的是,要保持学习的热情,多看论文、多做实验,不断提升自己的工程能力。

评估生成式AI,那简直是玄学!以前搞传统ML,准确率、召回率一摆,大家心里都有数。现在大模型一张嘴,胡说八道你都不知道。更麻烦的是,同样一句话,有人觉得妙语连珠,有人觉得驴唇不对马嘴。所以啊,评估生成式AI,得引入更多维度。除了靠谱程度,还得看它是不是有趣、是不是有创意,甚至还得考虑伦理问题,不能让它教坏小朋友。应对方法嘛,我觉得人肉评估是少不了的,还得设计一些巧妙的测试用例,专门去刁难它,看看它能不能hold住。

掌握本书内容后,要更好地将 AI 工程化落地,我认为还需要深入学习以下几个方面: 1. 大模型底层机制: Transformer 架构、注意力机制、预训练方法等。理解这些机制有助于更好地进行模型选择、微调和优化。 2. 分布式训练与推理: 掌握分布式训练框架(如 PyTorch DDP、TensorFlow MirroredStrategy)和推理加速技术(如 TensorRT、ONNX Runtime),以应对大模型带来的计算挑战。 3. 数据工程: 深入理解数据清洗、数据增强、数据标注等数据工程环节,保证训练数据的质量。 4. 领域知识: 结合具体应用场景,深入学习相关领域的知识,才能更好地利用 AI 解决实际问题。

关于RAG和微调的选择,我的看法是:如果你的应用场景需要引入大量外部知识或者领域知识,并且希望模型能够快速适应这些知识,那么RAG可能是更合适的选择。因为它可以在不改变模型本身的情况下,通过检索外部信息来增强生成效果。但如果你的场景对模型生成内容的风格、特定指令的遵循或者一些细微的知识点有较高要求,那么微调可能更有效。在实际项目中,我会先评估数据准备的难易程度。如果能容易地获取到高质量的相关数据进行微调,并且对性能有极致要求,我会选择微调。否则,RAG的性价比会更高。

生成式 AI 系统的评估确实比传统 ML 系统复杂得多。主要体现在以下几个方面:1. 主观性:生成内容的质量很大程度上取决于人的主观判断,难以用单一指标量化。2. 多样性:生成结果可能有很多种正确答案,需要考虑模型的创造性和泛化能力。3. 安全性:生成内容可能存在偏见、歧视等问题,需要进行安全评估。 为了应对这些挑战,我认为可以采取以下措施:1. 多指标评估:综合考虑准确性、流畅性、相关性、安全性等多个指标。2. 人工评估:引入人工评估环节,对生成结果进行主观评价。3. 对抗性测试:通过构造对抗性样本,测试模型的鲁棒性和安全性。

说到评估,传统ML就像考试,有标准答案,改卷子也简单。生成式AI就像艺术品鉴赏,你说它好,我说它不行,很难有统一标准。我觉得最难的是怎么量化“创造性”和“趣味性”。现在很多评估方法还是依赖人工,成本很高,而且容易受主观影响。未来的方向可能是开发更智能的自动化评估工具,让AI来评估AI,但想想就觉得有点科幻。目前,我觉得可以尝试众包的方式,让更多人参与评估,减少bias。

简单来说,我站 RAG!微调感觉像玄学,调不好就overfit,而且费钱。RAG 好歹能看到检索结果,心里有底。而且现在各种向量数据库、Embedding 模型都挺成熟了,用起来也方便。当然,如果你的数据量不大,或者想让模型学会你特有的“黑话”,那可能微调更适合。但是说实话,直接用 RAG + 优质 Prompt 应该能解决大部分问题了。

对于『模型 API vs 自建推理』这个选择,我个人觉得可以从『控制权』和『成本』两个维度来考量。

API 就像是 SaaS 服务,用起来方便,不用管底层,但魔改起来就比较困难。自建的话,所有东西都在自己手里,想怎么改就怎么改,但同时也意味着要承担所有的风险和运维成本。

具体到选择,我会看以下几点:

1. 业务的独特性: 业务场景是不是特别特殊,需要定制很多模型没有的功能?如果是,那自建可能更合适。
2. 数据安全性: 数据是不是非常敏感,绝对不能出问题?如果是,那自建可以更好地控制数据流向。
3. 长期成本: 长远来看,API 的调用量会不会很大,导致成本超过自建的成本?如果是,那自建可能更划算。

当然,如果团队没有 AI 相关的技术积累,还是建议先用 API 试水,等业务跑起来了,再考虑自建也不迟。

RAG确实是个好东西,但坑也不少。我之前遇到过一个问题,就是检索到的信息不够准确,导致生成的内容也驴唇不对马嘴。后来发现是向量数据库的索引建得不好,导致检索结果偏差很大。所以,在使用RAG时,一定要重视数据预处理和索引构建,选择合适的向量化方法和相似度计算方式。

同意楼上,prompt engineering很重要! 除了GPT-4,还可以试试其他开源的评估模型,比如DebertaV3之类的。 另外,评估的指标也要多样化,不能只看BLEU、ROUGE这些。 可以考虑引入一些更全面的指标,比如信息检索领域的NDCG、MAP,或者对话系统领域的Turn-level Accuracy、Success Rate等等。 总之,评估是个持续迭代的过程,需要不断尝试、不断改进。

我个人觉得这得看具体情况,RAG上手快,见效也快,但效果上限可能不如tuning。如果时间紧,或者说需求是快速验证一个想法,那RAG肯定优先。但如果是核心业务,需要极致的性能,那还是得耐心搞微调。当然,也可以先用RAG快速上线,然后慢慢迭代到微调。

对Prompt的理解和运用绝对是新的要求!以前搞ML,调参是重点。现在搞AI,Prompt写不好,再NB的模型也白搭。还有就是对各种agent框架的理解,也得提上日程。

评估指标这块确实头疼。之前做过一个内容生成的应用,一开始只关注了BLEU值,但发现BLEU值高的内容,用户并不喜欢。后来增加了人工评估,包括内容是否符合主题、是否有趣、是否有逻辑错误等等。但人工评估成本太高,还在想办法自动化。

RAG 和微调的选择主要取决于你的应用场景和数据情况。RAG 适合需要利用外部知识的场景,比如问答系统,信息检索等,而微调则更适合优化模型在特定任务上的表现。如果外部知识更新频繁,数据量大,RAG 可能是更好的选择。如果你的数据量较小,但希望模型在特定领域有更好的表现,可以考虑微调。

我觉得最大的区别是『不确定性』。传统的ML,输入和输出相对固定,Error也容易定位。但AI工程,尤其是大模型应用,输出有很多『可能性』,debug起来简直是噩梦。所以,AI工程师不仅要懂模型,还得懂人性,要理解用户的意图,才能更好地优化模型。

格局要大!成年人不做选择,我选择全部都要!:dog_face:
其实可以结合使用,先用 RAG 快速引入外部知识,然后针对 RAG 的效果进行分析,提取效果不好的 case,然后使用这些 case 进行微调,效果应该会更好。

除了传统的准确率、召回率等指标,对于生成式 AI 应用,我们更关注生成内容的相关性、流畅性和一致性。难以量化的维度包括用户体验、创造性和趣味性等,这些可能需要通过用户调研或者 A/B 测试来评估。

我觉得评估不能只看技术指标,更要关注业务指标。比如,你的AI客服解决了多少问题?用户的满意度提升了多少?最终还是要看AI应用给业务带来了多少价值。