大模型应用案例（非常详细）零基础入门到精通，收藏这一篇就够了

最新推荐文章于 2025-03-14 07:30:00 发布

Python_chichi

最新推荐文章于 2025-03-14 07:30:00 发布

阅读量1.3k

点赞数 29

分类专栏：科技程序员大模型文章标签：大模型人工智能

本文链接：https://blog.csdn.net/Javachichi/article/details/143848339

版权

程序员同时被 3 个专栏收录

1390 篇文章

订阅专栏

科技

425 篇文章

订阅专栏

大模型

358 篇文章

订阅专栏

百度最近举办了一场以「应用来了」为主题的市场活动。其创始人李彦宏演讲提到，利用RAG，即检索增强生成，基本消除了大模型的幻觉。AI应用将在智能体和产业应用两个方向演进，智能体是AI应用的主流形态，即将迎来快速爆发。

企业的市场活动，多少有营销意味，大模型应用是否如百度所预测的演进，需要我们拭目以待。不过，百度对于大模型的真正价值在于应用，尤其面向产业的观点，笔者倒是很认同。经常听到行业大模型，或者垂类大模型，就是面向政府和企业的大模型应用系统。

本篇文章，将围绕大模型应用，从应用形式，模型适配方式，应用开发和部署架构，对大模型应用的相关知识的系统梳理。

大模型应用形式

聊天机器人(Chatbot)

这是最常见的大模型应用形式，尤其是面向互联网用户，以聊天对话形式和大模型交互。智能客服场景主要采用的应用形式。

AI助手(AI Assistant)

AI助手，以一种辅助方式和用户协作。最为知名的是微软的各种Copilot。腾讯文档，主要功能是在线文档编辑能力，AI文档助手，可帮助我们续写当前文档，也可以根据当前的文档，生成ppt等等。

智能体(Agent)

智能体是指具备感知、思考、记忆、自主学习和决策能力的人工智能系统。Agent能够通过感知环境，自主进行所处情景、既定目标的推理预测，继而规划行动，最终自动执行工作任务。这是大模型应用领域最热的领域，有单个Agent和多个Agent的形式。自动驾驶汽车可以认为是一种智能体。具身智能也归类到智能体。24年初，AI教母李飞飞参与的一篇论文，讨论的就是Agent AI。

有两点需要说明一下。第一，这里所谓应用形式，更多是从用户的角度来看，不是开发者的设计模式。第二，应用形式与应用场景Use-Case相区别，举两个例子。

代码生成，是一个应用场景，其应用形式可以归类到AI助手。比如，Cursor的主界面和VS code类似，程序员可以在上下文或者右侧的Chat，利用大模型生成代码，修复bug，提高编程效率。另外一个AI编程工具，Github Copilot，应用名字包含着Copilot这个单词。

AI搜索引擎。美国的Perplexity ，国内的秘塔AI搜索。OpenAI刚刚发布了Chatgpt Search，向Google发起挑战。这种应用形式，和聊天机器人的形式类似，只是查询的目的和输出的结果，不会如Chatbot那么多轮。

模型适配方式

如何让通用大模型和企业的专有知识发生联系，生成的内容与企业相关，减少幻觉，这是大模型走向B端要解决的难题，也是学术界和产业界一直持续探索并尝试各种方式来解决。

提示工程(Prompt Engineering)

提示工程，实质是怎么能更好的向大模型提问，使得模型的回答更准确。研究者关注提示词对模型输出的影响，例如给大模型一个角色，鼓励他，给他个示例等，CoT(Chain of Thought)，一步一步思考，更进一步，ToT(Tree of Thought)，以决策树的方式思考。

给大模型做示范，根据投喂给大模型例子的多少，形成了几个概念。零样本学习(Zero-Shot Learning)，这是不给大模型示例，直接下指令。单样本学习(One-Shot Learning)，提供一个示例。少量样本学习(Few-Shot Learning)，提供几个样本。显然，示例多几个，模型回答会更好，也会按照给定例子的格式来响应。

不过直觉上，我们期望大模型就应该尽最大努力去思考和回应，缺省就设置成一步一步去思考，拆解用户的问题。OpenAI最新发布的o1模型，就带了CoT的能力。我们习惯于直接给大模型下指令，简单粗暴，不过有时候给他示例，可以得到更好的结果。

检索增强生成(RAG)

本文开头提到RAG就是对大模型增强的一种方式，主要目的就是消除大模型幻觉，以相对经济的方式，让模型和企业知识相关联。RAG是企业大模型落地的主要形式。

在大模型应用开发阶段，企业准备和相关的数据，经过嵌入模型（如OpenAI的text-embedding-3-large）处理后，导入向量数据库中。应用部署上线后，用户输入查询，检索向量数据库，返回相关的上下文信息，和原始的查询一起构造新提示词，再送给大模型，返回和企业相关的结果。

RAG架构图

RAG是学术界的热门，有很多论文发表。卡内基梅隆大学最近有一篇综述，介绍了15个典型的RAG框架，可以一览全貌。有兴趣的读者，可以在文末找到链接。

模型训练完之后，知识就不再更新，这是模型自身机制所决定的，除非二次增量训练模型。考虑成本问题，鲜有企业会这么做。但是，企业可以更新向量数据库，这个成本和难度，远小于前者。即便如此，有些随时间变化的信息，比如今天的天气情况，或者企业外部的信息，大模型还是无能为力。需要其他工具来赋能，例如通过Web工具，访问互联网来获取外部信息，或者及时的信息。这相当于模型的外挂，也是一种检索增强形式，一般称之为工具/插件集成。

微调(Fine-Tunning)

有针对性的训练模型，学习相关知识，从RAG的外挂，转变为微调的内化。此外，有些合规的要求，比如价值观对齐的内容，也可以通过微调让大模型掌握。微调说的是小规模的调整模型的参数，需要少量的数据或者问答对（可以认为是标准答案），对模型的调整比较轻微。想要深入了解微调的分类和方法，可以参考文末链接。

增量预训练

在基础模型或者微调过模型基础上，二次增量训练，学习行业知识，是打造行业大模型的常用方式。行业大模型，具备专业领域的问答和生成能力。

提示词功能和RAG，都是从提示词上做文章，没有对模型进行优化。微调和增量预训练，这对企业的算力和人才提出很高要求，最基本的，让模型运行起来需要GPU集群。

从难度和成本角度看，提示工程、RAG、微调、增量预训练，是依次升高的，从消除幻觉和更懂企业来看，也是依次提高的。这就需要企业在成本和效果上做权衡，假如RAG足够好，就不用花很高成本做微调了呢？这是个问题。

大模型应用开发流程

大模型应用开发和传统应用开发，并没有本质区别。在流程上，可以分为设计、开发和运行三个阶段，每个环节之内，有一些细化的任务。最重要的，大模型应用最先需要考虑的是需求和目标，这是后续所有相关工作的关键。

微软LLM应用生命周期

大模型应用特别之处在于大模型的引入，应用和大模型的适配是重点。在设计阶段，需要根据应用场景，自身条件（比如有没有算力和数据）来决定最终应用形式和模型适配方式。

应用需要考虑的问题：

全新应用 vs 现有应用LLM改造升级
聊天机器人（智能客服类）vs AI助手 vs Agent
单Agent vs 多Agent

模型需要考虑的问题：

开源 vs 闭源
购买公有云MaaS服务 vs 部署在私有云
大模型 vs 小模型 vs 多个模型
提示工程 vs RAG vs 微调

大模型应用架构

讨论企业大模型应用的架构之前，先来探索下Kimi，推测一下大模型应用应该有哪些组件。

PC浏览器登录Kimi的首页

Kimi提供PC浏览器和手机App，基于网页的BS架应用；
打开Kimi后，首先会提示登录或者注册，这跟传统应用没有区别，需要用户管理系统，后台会存储用户相关的数据；
登录成功后，可以直接输入提示词，也可以看到历史会话。如果是pc版，在对话框下面有系统提供的范例，或者说当用户没有特定目的的浏览，只是随便浏览体验，可以直接点系统提供提示词。可以推断，系统会有用户的会话历史库，这个只和当前用户有关，还有个提示词库，跟所有用户相关；
Kimi能够访问互联网，可以调用Web访问的插件。所以会有插件集成的组件，包括插件本身；
用户可以上传最多50个100M以下的文件，文件格式可以是pdf，doc，xlsx等。这样相当于用户给Kimi一些跟用户相关的领域知识，在这些文档里面查询和回复，比如总结要点，改写扩写等操作。这些文件存在哪里呢？推测系统会有嵌入模型，把这些文档向量化，存储到向量数据库里。

回到企业大模型应用，开发测试完成，上线部署，对外提供服务。假设以AI助手的应用模式，采用RAG方式的模型适配，并且大模型可以调用工具，访问互联网来查询信息。这种应用形式和模式适配方式，看看大模型应用的架构。

Nvida认为比较现实的LLM应用架构

借用英伟达的一个架构图。左侧是用户和设备，边缘的API端点；右侧是大模型工具和插件所访问的外部资源，比如向量数据库或者网站，中间是应用系统，中间的位置有两个模型，嵌入模型和推理大模型，是整个应用系统的核心。模型前面，有Guardrails，对用户的输入和模型的输出，提供安全过滤的能力，然后是提示词编排，上面关联着提示词库。模型后面，主要是模型插件和工具的分配和调度。

需要强调一点，这里讨论的只是比较有代表性的大模型应用架构，实际会有出入。比如，很多大模型应用实践，会用到多个大模型，根据用户的输入来判断，传递给哪一个模型来处理，比如一个专门处理图片OCR的小模型，再根据用户的意图，传递给大模型，输出给用户。