简单易懂的LLM三角原则，让你轻松开发大模型应用

雪碧没气阿

于 2024-08-20 10:28:41 发布

阅读量430

点赞数 4

文章标签：人工智能大语言模型 ai大模型 Agent LLM 大模型应用计算机技术

本文链接：https://blog.csdn.net/xxue345678/article/details/141351391

版权

先前我们聊到了《从零开始构建大模型(LLM)应用》，不少朋友偷偷问我：“什么是LLM的三角原则？”今天就给大家仔细讲讲构建LLM应用的三角原则。这套原则其实不复杂，由“3+1”(一范式三原则)个基础组成，适合任何团队来实践。

说到以LLM为核心的应用，有不少人以为是高大上的模型占主导，但其实情况是这样的：10%是那些复杂的模型，而有足足90%是实验性的、以数据为驱动的工程作业。

当我们把LLM应用到实际产品中时，需要的不仅是代码功底，更多的是工程上的精磨细打。如果用户不能直接和LLM打交道，那我们就必须搭建完善的构造prompt ，确保涵盖所有必要的细节，否则用户的反馈可能就没法收集完整，将会影响到后续的迭代升级！

1、LLM三角原则概念

提到LLM三角原则，你可能会觉得这是个很复杂的概念，但实际上，它就是我们构建高效LLM本地应用的一套基本指南。这套原则为开发者们提供了清晰的框架和方向，一步一步地打造出既健壮又可靠的LLM应用。有了这个原则作为指南，开发的过程将会变得更有条不紊，有效率。

在这里插入图片描述

1.1关键点

在我们打造LLM本地应用的过程中，LLM三角原则介绍了一个范式三大实用原则。

我们来看看范式：标准操作程序（SOP）。这个原则帮助我们把握好三个重要原则：模型、工程集成和上下文数据。

简单地说，把这三部分通过SOP进行精细调整，就是打造一个高效强大LLM本地应用的秘诀。这就像是确保我们的应用在正确的轨道上高速前进，既稳定又快速。

2. 标准操作程序（SOP）

**标准操作程序（SOP）**是一个常见的概念。其实就是一本操作手册，里面详细记录了每一步怎么做，确保每个员工做同一个工作时，效果都差不多，质量都很高。就像是给没有经验的员工一个详细的指导书，让他们也能像正常工作。

在我们构建LLM应用时，我们也用了这个原则。把模型想象成一个刚入行的新手，通过SOP这样的标准操作指南来“教”它怎么像专家那样完成任务。这样一来，我们的应用不仅运行得更流畅，出来的成果也能保证是高质量的。

在这里插入图片描述

“没有SOP，再厉害的LLM也难以保持一贯的高质量。”

在弄清楚SOP指导范式的时候，我们需要思考哪些技术工具可以帮助我们最有效地实行三大原则。

2.1 认知建模

要制定SOP，我们得先观察那些干得最好的员工——也就是我们的业务专家。我们需要模仿他们的思考和工作方式，确保能够达到他们同样的成果，并且要把他们的每一步操作都记录下来。

当我们编辑和正式化这些记录后，就会形成一套详尽的操作指南。这套指南能帮助经验不够或技术不足的员工也能够顺利完成工作。

我们自己在工作时，如果任务太复杂，就会感到头脑负担重。所以，把复杂的任务简化或者分解成小步骤，可以帮助我们更轻松地完成任务。遵循这样简单明了的分步指导，比起那些长长的、复杂的操作流程要容易得多。

在这个过程中，我们还会注意到一些专家在不经意间采取的小小习惯，这些习惯可能看起来微不足道，但实际上对最终结果有很大的影响。

在这里插入图片描述

比如说，我们想要模拟一个数据分析(通常是使用SQL或者表格)的工作方式。我们可以先从访谈开始，问他们一些具体的问题，了解他们的日常工作流程：

当需要你分析一个业务问题时，你通常会怎么做？
你是如何确保你的解决方案完全符合需求的？
接下来，我们会把我们理解的过程反馈给受访者看看，比如说：“所以你是这样分析的吗？”
然后询问：“这个流程可以覆盖你的工作过程吗？”这样可以让他们纠正我们可能理解错误的地方。
诸如此类的问题。

在这里插入图片描述

隐性认知过程有很多种，它们的形式和表现各不相同。比如说，“业务特定定义”就是一个典型例子。拿“畅销书”这个词来说，对于我们的业务专家来讲，这是一个非常重要的术语，他们对这个词有着明确的理解和定义。但如果你问一般人，他们可能就不那么清楚这个词具体是什么意思了。

在这里插入图片描述

到最后，我们就能拥有一套完整的SOP流程，这让我们可以模仿我们最优秀分析师的工作方法。当我们试图绘制这些复杂的流程时，将它们用图表形式展示出来会非常有帮助。特别是当这些流程包括许多小步骤、条件选择和不同分支时，图表的方式可以让我们更清晰地看到每一个环节，理解和执行起来也会更加直观。这样的方法能帮助我们更好地掌握流程，确保像那些优秀的分析师一样执行每一步操作。

在这里插入图片描述

我们的最终解决方案应该严格按照SOP中定义的步骤来模仿执行。在设计初期，不必过多关注实现的具体细节——这部分我们可以在后续阶段，针对解决方案的具体步骤或环节中逐步实施。

与其他原则不同，认知建模（即编写SOP）是一个独立的过程。我强烈推荐，在动手编写代码之前，先对整个流程进行模拟。当然，在实际实施过程中，随着对问题的理解不断深入，你可能需要根据新的认识对模型进行调整。

既然我们已经了解到创建一个SOP的重要性，这个SOP将指导我们更好地理解产品的问题及定位，并探讨如何有效利用各种工程技术来实施这一过程。这种方法确保我们的方案既符合需求又具有执行效率。

3. 工程集成

工程集成是实施SOP并最大化模型效用的关键。在考虑工程集成原则时，我们需要思考：使用的“工具”里有哪些技术可以帮助我们执行和完善SOP？这些技术又如何确保模型能有效执行并满足我们的需求？

在这里插入图片描述

在我们的工程技术中，有些技术仅在提示层面实施，而更多技术则需要在软件层面才能有效运作，还有一些技术是结合了这两个层面。

在这里插入图片描述

虽然每天我们都能遇到很多小调整，但在这里主要介绍两种重要的技术：工作流/链路和Agents。这两种技术对于我们的系统来说至关重要，它们帮助我们更高效地管理和执行复杂的任务。

3.1. LLM应用架构设计（工作流或链路）

LLM应用架构设计其实是在描述我们的LLM应用要完成任务的各个流程。

在我们的设计中，每一个步骤都是不可或缺的，各自独立地完成特定任务。有些步骤可能只需要靠一些固定的代码来执行；而对于其他步骤，我们可能会用到LLM（Agents）。

为了更好地构建这个架构，我们需要重新审视之前制定的标准操作程序（SOP），并思考以下几个问题：

哪些SOP步骤应该合并到同一个流程中？哪些步骤需要分开处理？
哪些步骤应该独立执行（虽然它们可能依赖前一个步骤的信息）？
哪些步骤可以通过固定步骤来实现？
等等。

在这里插入图片描述

在我们继续深入架构或流程图的具体步骤之前，我们应该明确一些关键属性：

输入和输出 —— 每一步需要什么输入？我们在行动前需要准备什么？（这同样适用于Agents的输出格式）。
质量保证 —— 什么样的响应才算是“足够好”？有没有需要人工介入的情况？我们可以设置哪些检查来确保质量？
自主级别 —— 我们希望对结果的质量控制到什么程度？这个阶段能处理哪些问题的范围？换句话说，我们对模型在这个阶段独立工作的能力有多大的信任？
触发器 —— 下一步我们要做什么？什么决定了下一步的行动？
非功能性要求 —— 我们需要的响应时间是多少？是否需要特别的业务监控？
故障转移控制 —— 可能会出现哪些类型的故障（包括系统性和代理性）？我们准备了哪些应对措施？
状态管理 —— 我们需要特殊的状态管理机制吗？我们如何检索或保存状态（确定索引键）？是否需要持久化存储？这种状态有哪些不同的应用（例如，用于缓存、记录日志等）？

3.2. 代理(Agents)是什么?

在LLM本地架构中，LLM Agents是一个独立的组件，它的工作就是调用一个LLM。

每个Agents都是LLM的一个实例，其中的prompt 包含了相应的上下文。但是，并不是所有的Agents都一样——有些Agents会使用“工具”，而有些则不会；有些可能在流程中只被使用一次，而其他的可以被递归调用或多次调用，它们会携带前一个输入和输出。这种设计让每个Agents都能根据需要灵活地执行任务，从而有效地支持整个LLM应用的运行。

3.2.1. Agents 与工具集

一些LLM Agents可以利用“工具”——这些工具是预先定义好的功能，可以用来执行数学计算或网络搜索等操作。当Agents需要使用某个工具时，它会明确指出所需的工具及其输入参数，随后应用程序依照这些指令执行任务，并将结果反馈给Agents。

为了帮助大家更好地理解这个概念，我通过一个简单的例子来看看如何实现工具调用。这个示例可以在没有专门训练用于调用工具的模型中工作：

你扮演的是一个助手，可以使用以下工具：

- calculate(expression: str) -> str - 用于计算数学表达式
- search(query: str) -> str - 用于在库存中搜索项目

接到一个输入后，你需要以YAML格式回应，其中包括以下键：`func`(字符串类型) 和 `arguments`(映射类型) 或 `message`(字符串类型)。

给定输入

我们需要区分两种代理：一种是带有工具的代理（即自主Agent），另一种是其输出可以直接导致执行动作的代理。

“自主Agent是具备独立完成任务方法的代理。”

自主Agent拥有决定是否采取行动及其具体行动的权力。相比之下，非自主代理只是简单地“处理”我们的请求（例如，进行分类），处理完成后，由我们的确定性代码来执行具体动作，模型本身对这一过程没有控制权。

在这里插入图片描述

随着我们增加Agent在规划和执行任务中的自主性，我们确实增强了决策能力。这看似一个非常好的解决方案，可以让Agent显得更“智能”。但是，这样做的一个潜在风险是可能会降低我们对最终输出质量的控制。

在这里插入图片描述

不要过分依赖全自主代理。虽然这类Agent的设计看起来简单且很有吸引力，但如果在所有情况下或作为初步概念验证使用，可能会在实际应用中产生误导。自主Agent难以调试且其响应质量不稳定，因此通常不适合在生产环境中使用。

以经验来看，在没有详细指导的情况下，Agent在规划复杂过程时往往表现不佳，可能会忽略一些关键步骤。例如，在我们的“百科编辑者”示例中，Agent可能会直接开始写作，而忽视了必要的准备工作。这说明Agent的性能很大程度上依赖于它们训练的数据——简单来说，Agent只能做得和它们训练的数据一样好。

与其让一个或一组Agent自由地完成所有环节的任务，不如在流程或标准操作程序（SOP）中的特定区域限定它们的任务，特别是那些需要创造力和灵活性的环节。这种做法可以提高成果的质量，因为它既利用了流程的规范性，又保留了创新的空间。

以AlphaCodium(一个代码生成任务增强流程很火的开源项目)为例：通过将固定的流程与不同功能的Agent相结合（包括一个专门负责重复编写和测试代码的新型代理），他们成功地将GPT-4在CodeContests上的准确率（pass@5）从19%提高到了44%。这个例子很好地说明结合流程控制和Agent创造力的重要性，以及这种结合如何有效提升任务执行的效果。

在这里插入图片描述

在我们利用工程集成来实施标准操作程序（SOP）和优化LLM本地应用的同时，我们也不能忽视LLM三角原则中的另一个核心要素：模型本身。

4. 模型

我们选用的模型是项目成功的关键因素。例如，像GPT-4或Claude Opus这样的大模型虽然能够提供更优质的结果，但在大规模应用时成本也相当高。相比之下，较小的模型虽然可能不那么“强大”，但有助于我们控制预算，而且在某些特定领域能达到我们想要的效果。因此，在考虑选择模型时，我们必须清楚自己的约束条件和目标，才能确定哪种类型的模型最适合帮助我们达成这些目标。

在这里插入图片描述

并非所有的LLM都是相同的。要使模型与任务相匹配。

事实是，我们并不总是需要最大的模型；这取决于具体任务。为了找到合适的匹配，我们必须进行实验过程，并尝试我们解决方案的多种变体。

考虑到我们的“无经验工人”类比——一个拥有众多学术资质的非常“聪明”的工人可能会轻松完成一些任务，但他们可能对某些工作来说过于高资，雇用一个“更便宜”的候选人会更加具有成本效益。

在选择模型时，我们需要根据可以接受的各种权衡来定义和评估不同的解决方案：

任务复杂度 — 对于简单的任务，如生成摘要，一个小型模型就足够了，但处理更复杂的推理任务通常需要较大的模型。
推理基础设施 — 我们选择在云端还是在端侧上运行模型？模型的大小可能会限制设备配置的性能，但在云服务中这通常不是问题。
定价 — 我们能接受的最高价格是多少？结合业务影响和预期的使用频率，这个投入是否划算？
延迟 — 模型越大，其处理速度可能越慢。
标注数据 — 我们是否拥有足够的标注数据来丰富模型，尤其是那些模型未曾学习过的信息？

在许多情况下，在我们积累足够的“专业知识”之前，为了获得经验丰富的效果而支付额外成本是非常需要的——这对于LLMs也是适用的。这可以在初期阶段帮助我们实现更好的性能和效果。

如果手头没有标注数据，一个好的策略是先使用一个更强大（也就是更大）的模型开始工作，通过这个模型来收集数据，但这个需要注意合规风险。然后，利用收集到的这些数据，我们可以通过少样本学习或者对模型进行微调，从而进一步提升模型的性能。

4.1. 模型微调

在对模型进行微调之前，您必须考虑以下几个方面：

隐私：如果您的数据中包含敏感或个人信息，必须对这些信息进行匿名化处理，以避免可能的法律责任。
法律、合规性和数据权利：训练模型时可能涉及法律问题。例如，OpenAI的使用条款禁止未经许可使用其生成的内容来训练模型。另外，根据欧盟的GDPR法规，用户有权要求企业删除其个人数据，这可能会引起关于模型是否需要重新训练的法律问题。
更新延迟：与直接在上下文中嵌入新信息相比，重新训练模型通常需要更多时间，因此更新的频率可能较低。
开发和操作：建立一个可重复、可扩展并可监控的微调流程是至关重要的，同时需要持续评估性能。这一过程复杂且需要持续的维护。
成本：由于训练过程的复杂性以及高密集的资源需求（如GPU），重新训练模型通常代价高昂。

LLMs作为“上下文学习者”的功能，以及新模型支持更宽广上下文窗口的能力，已经大大简化了我们的应用实现。这意味着即使不进行模型微调，我们也能获得很好的效果。因此，考虑到微调的复杂性，我们建议只在必要时才采用，或者尽可能避免使用微调。

另一方面，对于特定任务（例如生成结构化的JSON输出）或特定领域的应用进行微调，可能会更有效。一个专为特定任务设计的小模型在处理这些任务时既高效又成本低，比大型LLMs要经济得多。因此，在决定是否升级到更大规模的LLM训练之前，评估所有相关因素是非常必要的。

请注意，即使是最先进的模型，也需要依赖相关而且结构合理的上下文数据，才能充分发挥其潜力。

5. 上下文数据

LLMs 是上下文学习的高手。只要我们提供相关任务的具体信息，LLM Agent就能够在不经过特殊训练或微调的情况下帮助我们完成这些任务。这让我们可以很轻松地向它们“传授”新的知识或技能。

当涉及到上下文数据的处理时，我们应该要向如何组织和建模手头上的数据，并考虑如何在我们的prompt 中有效地整合这些数据。这样一来，LLM就能更好地理解和执行任务，从而提高效率和效果。

在这里插入图片描述

要构建有效的上下文，我们需要在发送给LLM的提示（prompt）中包含相关的信息。通常，我们可以采用两种类型的上下文：

嵌入上下文：这种上下文直接嵌入到prompt的文本中，作为信息的一部分提供。

你是<name>的得力助手，<name>在<company>担任<role>。

附件上下文：这种上下文通过在prompt的开头或结尾附加信息片段来提供。

在保持友好语气的同时总结所提供的电子邮件。
---
<email_0>
<email_1>

我们通常使用“prompt模板”来实现这些上下文，比如使用jinja2、mustache或简单的原生格式化字符串。通过这种方式，我们可以优雅地构建提示内容，同时保持其核心本质清晰：

# 带有附件上下文的嵌入上下文
prompt = f"""
你是{name}的得力助手，{name}在{company}担任{role}。

帮助我用{tone}语气回复附加的电子邮件。
始终以以下签名结尾：
{signature}

---

{email}
"""

5.1. 少样本学习

少样本学习是一个不需要大量调整模型就能教会LLMs新技能的方法。我们只需在prompt中加入一些准备好的示例，模型就能学会我们需要的格式、风格或怎样完成任务。

比如，如果我们想让LLM帮忙回复电子邮件，我们可以在prompt中加入几个认为写的好的回复示例。这样，模型就能学到我们希望的回复结构和语气。

通过提供多种不同的示例，模型可以更好地理解各种复杂的情况和细微的差异。因此，确保你的示例全面，能覆盖所有可能的情况是非常重要的。

随着应用程序的进步，你可以采取“动态少样本学习”的策略，根据每个特定的输入选择最相关的示例。这种方式虽然更复杂，但能让模型针对不同的情况得到最好的指导，从而在处理多种任务时提高性能，同时避免了成本高的大规模调整。

5.2. RAG

检索增强生成（Retrieval Augmented Generation，简称RAG）是一种特别的技术，它会在LLM生成回答之前先查找相关的文档，以此来提供更多的上下文信息。可以想象成，在LLM回答问题之前，它会先快速查阅相关的资料，这样做可以帮助它给出更准确和更新的信息。

例如，在聊天机器人的应用中，RAG能够自动查找并提取相关的帮助台维基页面，这些信息将直接用来支持LLM的回答。

这种方法让LLM能够依据最新获取的信息来生成回答，这不仅确保了信息的及时更新，还减少了生成不准确或虚假信息的风险。对于那些需要最新数据或专门知识的任务，使用RAG特别有效，而且这样做不需要重新训练整个模型，既节约了时间也节省了资源。

例如，假设我们正在为产品开发一个在线支持聊天功能。在这种情况下，我们可以利用RAG技术从知识库中检索出相关的文档，然后把这些信息提供给LLM Agent。接着，让它根据提供的问题和文档内容撰写出合适的答案。

在部署RAG技术时，我们需要特别关注以下几个关键点：

检索机制：通常的做法是通过搜索相似的内容来找到相关文档，有时候采用更简单的搜索方法（例如，基于关键词的BM-25搜索）可能更有效或成本更低。
索引数据结构：如果我们直接索引整篇文档而不做预处理，可能会影响搜索结果的质量。因此，我们可能需要先进行一些数据准备，例如根据文档内容制作一份问答对列表。
元数据：保留与查询相关的元数据可以帮助我们更有效地筛选和引用信息（比如，只关注与用户查询直接相关的知识页面）。这一额外的数据层可以使检索过程更简单。

5.3. 提供相关上下文

在提供信息给Agent时，关键是要把握一个度。提供很多信息似乎看起来非常有用，但是如果信息太多、太杂，反而可能会让模型感到不堪重负，难以区分哪些信息是真正相关的。过多的无关信息可能会让模型学到错误的东西，造成混淆甚至错误的判断。

例如，当Gemini 1.5发布时，它能处理高达10M标记的数据，一些专家开始质疑这样庞大的数据处理能力是否真的有效。尽管这种能力对某些特定场景（比如处理PDF文件的对话）很有帮助，但在需要对多种文档进行综合推理的情况下，它的效果还是非常有限。

因此，我们在提供信息时，应该尽量保证信息的相关性。这样做不仅能减少模型处理无关数据时的计算负担，还能提高任务的执行质量和效率，同时也能降低成本。选择什么样的信息提供给模型，直接影响到模型的表现和效果。

要提高我们提供给LLM的上下文信息的相关性，有很多有效的方法，这些方法主要涉及如何更好地存储和管理数据。特别是在使用检索增强生成（RAG）技术的应用中，加入一个准备数据的步骤会非常有帮助。例如，我们可以先从文档中提取出问题和答案，然后只向LLM代理提供这些答案。这样，Agent接收到的上下文就会更加简洁明了。同时，使用一些算法对检索到的文档进行重新排序，也能优化最终的输出结果。

“数据是LLM应用的核心驱动力。好的上下文数据能最大限度地发挥出它的潜力。”

6、总结

LLM三角原则提供了一个基础框架，帮助我们在开发产品时发挥LLMs的功能。这个框架基于三个主要的元素：模型、工程集成、上下文数据，以及一套详细的操作步骤（SOP）。

在这里插入图片描述

6.1关键要点

从明确的操作步骤开始：先模拟专家如何思考和操作，然后根据这些信息为你的LLM应用制定一份详细的操作指南。这个指南将成为你实施其他步骤的基础。
选择合适的模型：在选择模型时要考虑到性能和成本之间的平衡。你可以先从一个大模型开始，如果需要，以后再改用一个经过微调的小模型。
利用工程技术：建立一个LLM本地架构，并巧妙地利用代理来提升性能，同时确保能控制整个过程。试验不同的提示技术，找到最适合你需求的方法。
提供相关上下文：合理利用上下文信息来增强学习，比如使用检索增强生成（RAG），但要注意避免给模型提供太多无关的信息。
不断迭代和实验：通常，找到最好的解决方案需要不断的测试和调整。推荐阅读《从零开始构建大模型(LLM)应用》来获得更多关于LLM开发过程的详细指导。

通过这些方法，组织不仅能超越基本的概念验证阶段，还能开发出强大、准备好上线的LLM应用，最大限度地发挥这项技术的潜力。

6.2干货推荐

在项目中，构建大模型应用时，以下几款工具是非常实用且常用的：


框架	使用场景	优点	缺点
LangChain	1、适合需要快速开发和部署大型模型应用的场景。 2、适合有编程基础和对大模型有了解的开发者。	1、易用性：LangChain简直是为程序员量身打造的工具集，简化了开发工作量。 2、模块化设计：各种模块（如Retrievers、Memory、Chain、Agent、Tools）可以随意组合，开发效率杠杠的。 3、快速迭代：几乎每天都有新版本，成熟度不断提升。 4、社区支持：在GitHub上人气很高，社区非常活跃，获取帮助很方便。	1、学习成本：虽然设计简单，但还是需要点代码能力和对大模型的理解。 2、部分模块成熟度不一：有些第三方功能还不太成熟，不建议直接用。
LlamaIndex	1、适合需要结合大型语言模型和私有数据或特定领域数据的应用场景。 2、适合有技术背景的开发者使用。	1、数据连接能力：LlamaIndex的数据连接器简直无敌，能读多种外部数据源。 2、索引构建：支持多种索引方式，用户可以根据需求自由构建索引。 3、查询接口：提供大模型对话接口，让大模型理解和回应外部数据查询。 4、扩展性和灵活性：用户可以自定义索引和查询逻辑，满足不同需求。	1、技术门槛：构建和管理索引需要一定技术背景，对初学者有些难度。 2、资源消耗：索引和查询会消耗较多计算资源，特别是处理大量数据时。
RAGFlow	1、适合处理复杂格式非结构化数据并构建知识类应用的企业和个人。 2、适合对文档理解和问答质量要求高的场景。	1、深度文档理解能力：RAGFlow从复杂格式的非结构化数据中提取真知灼见，支持无限上下文场景。 2、可控可解释的文本切片：多种文本模板，结果可控可解释，降低幻觉风险。 3、兼容异构数据源：支持Word、PPT、Excel、PDF等多种文件类型，方便集成。 4、自动化RAG工作流：全面优化的RAG工作流，支持各种规模的生态系统。	目前具体缺点信息较少，可能包括某些特定功能的限制或性能瓶颈。
DB-GPT	1、适合围绕数据库构建大模型应用的企业和个人。 2、适合对模型管理、数据处理和问答体验要求高的场景。	1、多模型管理：DB-GPT支持多种开源和API代理的大语言模型，管理功能强大。 2、Text2SQL效果优化：优化了Text2SQL任务，提高应用智能化水平。 3、RAG框架：基于RAG能力构建知识类应用。 4、数据驱动的Multi-Agents框架：支持自定义插件执行任务，智能体协作高效。 5、数据隐私和安全：注重数据隐私，通过私有化大模型、代理脱敏等技术保障数据安全。	相比其他框架，DB-GPT更侧重数据应用和模型管理，对某些特定场景支持不如其他框架全面。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述