先前我们聊到了《从零开始构建大模型(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产品经理如何学习
求大家的点赞和收藏,我花2万买的大模型学习资料免费共享给你们,来看看有哪些东西。
1.学习路线图
第一阶段: 从大模型系统设计入手,讲解大模型的主要方法;
第二阶段: 在通过大模型提示词工程从Prompts角度入手更好发挥模型的作用;
第三阶段: 大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统;
第四阶段: 大模型知识库应用开发以LangChain框架为例,构建物流行业咨询智能问答系统;
第五阶段: 大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型;
第六阶段: 以SD多模态大模型为主,搭建了文生图小程序案例;
第七阶段: 以大模型平台应用与开发为主,通过星火大模型,文心大模型等成熟大模型构建大模型行业应用。
2.视频教程
网上虽然也有很多的学习资源,但基本上都残缺不全的,这是我自己整理的大模型视频教程,上面路线图的每一个知识点,我都有配套的视频讲解。
(都打包成一块的了,不能一一展开,总共300多集)
因篇幅有限,仅展示部分资料,需要点击下方图片前往获取
3.技术文档和电子书
这里主要整理了大模型相关PDF书籍、行业报告、文档,有几百本,都是目前行业最新的。
4.LLM面试题和面经合集
这里主要整理了行业目前最新的大模型面试题和各种大厂offer面经合集。
👉学会后的收获:👈
• 基于大模型全栈工程实现(前端、后端、产品经理、设计、数据分析等),通过这门课可获得不同能力;
• 能够利用大模型解决相关实际项目需求: 大数据时代,越来越多的企业和机构需要处理海量数据,利用大模型技术可以更好地处理这些数据,提高数据分析和决策的准确性。因此,掌握大模型应用开发技能,可以让程序员更好地应对实际项目需求;
• 基于大模型和企业数据AI应用开发,实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能, 学会Fine-tuning垂直训练大模型(数据准备、数据蒸馏、大模型部署)一站式掌握;
• 能够完成时下热门大模型垂直领域模型训练能力,提高程序员的编码能力: 大模型应用开发需要掌握机器学习算法、深度学习框架等技术,这些技术的掌握可以提高程序员的编码能力和分析能力,让程序员更加熟练地编写高质量的代码。
1.AI大模型学习路线图
2.100套AI大模型商业化落地方案
3.100集大模型视频教程
4.200本大模型PDF书籍
5.LLM面试题合集
6.AI产品经理资源合集
👉获取方式:
😝有需要的小伙伴,可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓