大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



 
  
    
     
本文以“空气小猪”AI客服案例，深入浅出地介绍了AI客服的落地过程。文章涵盖了技术选型、流程设计、知识整理、知识库构建、意图识别、问题泛化、上下文管理、检索方案、生成阶段等关键步骤，并详细阐述了数据飞轮机制如何持续优化AI客服效果。
 

这个AI客服案例来源于我们去年AI 2C的创业项目：空气小猪。他是一款基于社交的语言学习App，从上线之后一直是我们自己在做客服工作，，这种状态已经持续了半年多了，占用了大量时间。

这期间，我们也尝试找过兼职客服做过一段时间，发现效果很差。一方面，兼职人员不太上心；

另一方面，由于对产品理念和定位理解不够深入，往往无法准确、有效地回应用户问题，整体服务质量难以保障。

其实用户的问题基本都是重复的，高频问题就那些，每天去人工重复回答这些问题确实挺费时间的，既低效也不具备可持续性。：

简单场景照着做就行（虽然最后证明其他同学会在其他地方掉坑里）；复杂场景的话又有另外一套方法论，由此我们也几乎可以得出一个结论：

客服工作，无论简单复杂，在未来大概率会被AI替换

在线客服工作本身具有较强的重复性，因此“降本增效”始终是客服系统演进的核心目标。基于大模型的AI客服，可同时显著提升产品能力和用户体验，还能大幅降低运维成本。

随着 AI Agent 的成熟应用，AI客服系统在成本、效率和可扩展性方面进一步优化，逐渐会成为最优解。

那么这里又有同学会有疑问：

答案很简单：我们也需要积累原始数据啊…

在这半年多的时间里，创始人与用户之间沉淀了大量。在基础问题开始不断重复的时候：就是构建一套 AI 客服系统的时机了。

这里目标就简单了：把我们从每天2小时的人工客服时间释放出来！这也是整体项目背景了，下面我们将详细的介绍空气小猪AI客服从0到1 的整个实践过程，以及落地的关键步骤。

在实现环节我们面临一个选择：是采用智能体低代码开发平台，还是直接进行工程化代码开发？

从技术角度来看，这两种方式都可以实现目标，但真的要做肯定是直接选择工程化代码方案啊，好处很多，最重要的是对这块有更深入的技术实践，所有这一切都会体现在自主可控性这点，但也可以将选型过程简单说下，各位可以考虑看看：

在智能体开发平台的选型中，主要考虑的是Dify，前面我们介绍过coze、dify、fastgpt、n8n的技术选型。

整体来看，Dify的能力算是这些平台中最均衡的，没有明显的短板，尤其适合企业场景下的智能体开发、工作流的编排以及知识库驱动型应用。

但是最终没有选择Dify，主要是基于下面几个方面考虑：

1. 我们对知识库检索能力有较高要求，希望在召回策略、排序逻辑、上下文拼接等环节进行深度优化。这部分是 AI 客服的核心能力，我们更希望逻辑完全自主可控。
2. 私有化部署也需要额外的服务器的成本和运维成本，对我们当前阶段而言是没有必要的（真实使用你们才知道开源版本会少了什么）。
3. 在实际测试中，我们发现 Dify 的执行链路相对较长，尤其在知识检索节点，整体响应时间偏长，不完全符合我们对实时性的要求。
4. 即使使用Dify，实际落地过程中依然会涉及系统对接、数据适配和定制开发等工作，并非零成本集成。

综合这些因素，我们最终决定自己写代码，从底层能力开始搭建，虽然前期投入更高，但在可控性、性能优化空间以及长期演进能力方面更有优势。

并且自己写代码，事实上成本也并不高…

解决了第一个问题，很多同学第二个问题也就出现了：那么我们的AI客服要不要直接用Agent模式呢？

Workflow还是Agent？

项目开始阶段，除了要决定使用Dify还是工程化代码，开发模式也需要在Workflow和Agent中做出选择。

Agent是具有高度自主性的智能体，但是结果的确定性、性能等都不占优势，通常客服场景会选择比较保守的做法：先按照Workflow的方式，搭建稳定的流程，来追求确定的、能控制的结果。

从工作流程入手，逐步引入并解决每一个遇到的问题，同时兼顾效果、成本和可控制程度。

至于后期要不要“升级”Agent版本，完全看业务需要，业务上几乎不追求这些时髦的东西。

基础流程设计

在确定基础技术选型后，就可以进行流程设计了，在第一个版本中，我们把意图分为产品咨询和闲聊，大致的流程如下：

但是很快我们发现，用户除了咨询常见的产品功能问题，还会反馈一些产品建议以及程序故障等问题。

而这一部分内容的处理逻辑与单纯的产品咨询其实是不太一样的，用户反馈的问题是需要存入数据库，并且根据问题的严重程度划分等级，方便我们及时跟进修复处理。

在初版的基础上面我们增加了优化建议、故障反馈的意图处理流程。具体流程如下：

这也就是我们方法论中所述的整理大表了，在基础意图整理差不多后就可以进入最重要的知识梳理环节了：

要做AI知识库的同学一定要注意：数据才是灵魂！如果有人说做AI项目不深度聊数据，那么他大概率是没做过的…

产品知识是AI客服的基础（这也是为什么我们非要等半年才做客服的原因），只有提供优质的知识才能让AI输出优质的回答，否则就是垃圾进垃圾出。

在数据不全的情况下，不管做再多的工程化优化都是无用功，所以说RAG的本质是个数据工程，大家一定要去理解这到底是在说撒。

具体在做AI客服知识梳理时，理论上来说要求是很高的，，但是知识的完备性需要持续的迭代更新才能覆盖完全。

真实情况是：所有知识库应用初始阶段都存在类似的情况，所以允许知识覆盖不全，在迭代中逐步补齐知识，并且后面用数据飞轮的策略来自动化的完善知识不足的问题变成了主流。

具体到这个项目，我们的知识来源于两部分内容：一部分内容是人工整理的，另外一部分是历史客服数据。

在进行知识整理时，就需要考虑如何组织知识才能有更好的检索效果，而检索的效果很大程度是取决于数据处理是否正确，比如每个分块的语义是否完整独立。

因此输出的知识一定要能够单独成块，可以利用Markdown格式进行结构的化层级进行整理，在分块时，可以根据标题进行分割，知识内容大致形式如下：

另一方面，我们导出了，这里主要根据会话维度进行分析，因为数据较多，不太可能人工整理，可借助AI分析提取每个会话中有效的问答记录。

当然这里也不能一次性把所有的数据给到大模型整理，有两个原因：

1. 一是数据太多会超出大模型上下文限制；
2. 二是数据太多，幻觉增加，准确率会降低；

处理的策略是拆分为多个批次进行整理，比如每10个会话为一个批次，我们借助Coze搭建了一个自动化处理工作流，流程如下：

PS：这里也可以看出来，我们其实也使用Coze，但一般是来做一些自动化小操作，用完就走

从数据库导出会话记录时，每10个会话导出为一个会话记录文件，最终会导出若干个会话记录文件，然后把这些文件上传到coze工作流上进行批量处理，生成的问答对内容都会被写入飞书多维表格中。

最终表格中的内容必定会存在重复的内容，再把表格中整个内容给到大模型进行分析，把内容去重处理，形成最终的问答对。

通过这两种方式，我们就得到了最终的产品知识数据，

可以认为：这一步没做好，那么AI客服的效果一定会差！

在数据整理结束后，就进入了知识库构建环节：

这里技术实现：Python + FAISS + MYSQL + qwen(text-embedding-v4)

向量库选择Meta公司开源的FAISS，非常轻量，嵌入模型使用千问的text-embedding-v4（1024维度），它在中文场景下表现更好。

数据存储的结构

整个知识库由库、集合和数据 3 部分组成。

集合可以简单理解为一个文件，一个库中可以包含多个集合，一个集合中可以包含多组数据；

最小的搜索单位是库，也就是说，知识库搜索时，是对整个库进行搜索，而集合仅是为了对数据进行分类管理，与搜索效果无关。

向量存储的结构

使用 Faiss 作为向量检索引擎，使用 MySQL 作为业务数据存储数据库，实现知识入库与向量召回的分离式架构设计。

这里Faiss只负责向量存储与相似度检索，MySQL负责原始知识数据与业务字段存储，向量检索引擎可独立替换为其它向量数据库（比如Milvus、Weaviate等），不影响业务数据库结构。

而这两者间的关系通过向量ID进行关联，在MySQL的dataset.datas表中，会存储向量原数据的信息，同时有一个vectorId字段，会记录其对应的向量ID。

知识入库是一个离线过程，大致流程如下：

1. 先加载知识文档，对文档进行分块
2. 然后把分块存入到mysql业务数据库中，此时向量化状态为待向量化，向量ID字段为null
3. 然后通过异步事件驱动把每一个分块chunk使用向量模型进行向量化，得到向量坐标之后，存入Faiss向量库中
4. 存入向量库完成后，会生成向量ID，然后在把这个向量ID存入到mysql对应的chunk中的vectorId字段，并且将向量化状态更新为已向量化

知识检索流程，如下：

1. 使用向量模型对用户的问题进行向量化，得到向量
2. 然后使用 Faiss 执行相似度搜索，召回TopK个向量ID，同时得到相似度得分
3. 拿到召回结果后，根据向量ID去MySQL数据库中查询该向量ID对应的原始文档chunk数据

知识入库

在知识整理完之后，使用代码对markdown格式的知识，按照结构层级进行分块，得到结构化的JSON数据，然后存入业务数据库和向量库中。

把一级标题设置为category字段，把最后一级标题设置为questions，段落内容设置为answer字段，如果存在三级以上的层级，把1到n级标题通过“-”链接设置为category字段，n级标题设置为questions字段。我们得到的分块内容如下结构，这里只列举核心字段：

GPT plus 代充 只需 145

得到若干上述分块结构之后，按照前面的流程把每个分块存入mysql数据库，并存入向量库中。

需要注意的是，向量化的文档内容并不是直接把这个JSON进行向量化，这里JSON结构主要是为了拿到文档分块的结构化信息，方便元信息获取及存储。

向量化的真正文本内容为category+quesions+answer的拼接内容。

在这一步我们最初犯了一个错误，我们把生成的原始chunk使用大模型针对问题进行了泛化处理，泛化后的结构为：

也就是把一个问题泛化为多个可能的问题，以提升召回命中率，并且在存储时按照一问一答的结构进行储存，也就是把问题1 + 答案、问题2 + 答案、问题3 + 答案 分别进行存储。

最后在知识召回时就出现问题了，同一个问题很大概率会召回相同的文档信息，并且这部分的得分还比较高，于是取Top-K时，召回的数据都是一样的，只是问题不一样，这就导致其它可能更相关的内容被挤掉。

接下来是检索流程：

RAG系统在检索这里，比较重要的是意图识别。

所以，前置的意图分类这一步就至关重要，真实用户的问题是非常发散的，第一步就需要对用户的意图进行收敛，收敛的目的是为了匹配后续的流程以及更好的匹配到我们知识库中的知识。

我们在把第一级大类意图拆分为 产品咨询、故障反馈、闲聊，然后通过代码进行路由分发，分别走不同的处理流程；

但是这里要让大模型准确判断是哪一个意图，需要继续细化用户的二级意图，比如什么情况下应该匹配到产品咨询上，什么情况匹配到故障反馈上；

你需要给大模型一个明确的评价标准，这个二级意图就是用来辅助大模型判断一级意图的标准。否则在意图识别这一步很可能就直接出错，后续的回答肯定就不准确了。

这里整理的思路也跟大家分享一下：

• 一是从产品本身梳理（我们提供了什么、主要解决什么问题）；
• 二是从用户的角度进行梳理（我能得到什么、对我英语有没有提升，怎么用），然后对两者进行融合；

通过客服历史问答数据，我们提炼了用户的高频问题，这里给了非常大的参考价值。下面是我们梳理的一些高频问题类别：

这里再摘抄的提示词：

GPT plus 代充 只需 145

从提示词的设计可以看出，我们不仅对用户的提问进行了意图识别，还在这之前增加了指代消解的处理步骤。也就是说，在完成指代消解之后，才进入意图识别阶段。

PS：事实上也可以将这个提示词再拆分，以符合提示词原子性的要求，我们这里因为是做案例讲解就不麻烦了

至于之所以需要进行指代消解，是因为在实际使用过程中，我们发现用户往往会将一个完整的问题拆分成两句话，或者在后续提问中使用上下文中的指代词；

例如，用户先问“空气小猪是干什么的？”，接着又问“它怎么用？”如果将第二句话直接用于检索，很可能无法获得有效结果；而真正符合用户意图的检索语句应该是“空气小猪怎么使用？”。

因此，我们借助大模型结合上下文语境，对用户最新的问题进行指代消解，将其中的指代词还原为具体对象。这样可以提高意图识别、以及检索的准确性，使整体流程更加连贯和高效。

在意图识别这个环节中，模型经历了从GPT-4.1到Qwen-plus-latest、Qwen-max-latest，再到Qwen3-max、Qwen-plus的选择过程。

GPT-4.1作为效果标杆，Qwen系列则需要通过提示词优化或节点拆分来提升表现。值得一提的是，Qwen-plus在未修改提示词的情况下即有提升，整体效果还可以。

我们这里场景不算复杂，为了均衡，我们模型最终选择了Qwen-plus, 如果需要更好的效果可以考虑Qwen3-max或GPT4.x等模型。

模型的选择可以根据项目阶段来确定，项目初期选择参数较大的模型进行验证并快速上线；后期则在保证意图识别准确率不下降的前提下，逐步替换为成本更低的模型，以实现效果与成本的平衡。

总之，我们每个项目做的时候都会用最好的模型，后续实际上线，都是各种成本考虑…

问题泛化

在正式进入检索阶段之前，需要先对用户问题进行一系列语义预处理，最大程度提升后续检索的召回率与覆盖面。

首先，通过指代消解技术，对问题中的代词、模糊指称和上下文依赖表达进行还原。

例如，将“他”“这个”“那个”等模糊表达，结合上下文明确为具体的名称，从而避免检索阶段因语义歧义而遗漏关键信息。

其次，我们基于原始问题进行多问题生成（Query Expansion & Multi-Query Generation）。利用大模型的语义理解和重写能力，从不同角度、不同表达方式对同一问题进行改写扩展。

比如：同义词替换与表达重构、从不同维度拆解子问题、将抽象问题转化为更具体、可检索的表达语句。

通过这种方式，可以将一个单一问题扩展为多个语义相关但表达不同的查询语句。

这种多路查询策略能够覆盖更多潜在的匹配结果，以提升召回率，同时减少因表达方式单一或者口语化而导致的信息遗漏。

上下文管理

每次让大模型进行意图识别、问题泛化、回答问题时，除了把用户最新的消息传进去之外，还需要把历史会话消息传递进去，这样才能确保大模型理解对话语境。

但是这里存在一个问题：太少的话大概率会丢失上下文信息，大模型回答会偏；携带太多，速度会慢、token消耗会变大，干扰信息太多会产生幻觉。

如果简单固定携带10条-20条历史消息，在大多数情况下是可以的，但仍然存在明显的缺陷，更早的关键对话信息就丢失了。因此，单纯使用“固定条数”的策略没法在上下文完整性和资源成本之间取得比较好的平衡。

为此，这里也做了一个优化策略，

短期记忆比较好理解，就是每次携带N条最新的会话消息，这部分信息保持原始表达，不做信息压缩，尽量保证对话语境的连续性和即时性。

除此之外，还会携带历史消息的摘要信息，历史摘要信息的生成规则是每满N条消息就会进行一轮异步压缩，并把摘要信息存入业务数据库中，持久化保存。

需要注意的是，这里的历史摘要信息携带数量，并不是全量的，也完全没有必要全量携带；

举例说明：比如我们每30条消息进行一轮压缩，如果携带10条摘要信息，那这里就是300条历史消息的摘要信息了，用户最新的聊天可能早已跳出之前的对话语境。

下面是历史消息摘要生成的示例提示词：

GPT plus 代充 只需 145

我们在让大模型意图识别、问题泛化以及回答问题时，我们携带的消息上下文构成如下：

当然除了上面这种按照固定条数进行压缩之外，我们也可以根据达到一定的token数量才进行压缩。这里根据具体场景进行选择。

检索方案

前面我们针对用的问题进行了泛化处理，把一个问题改写为多种不同的表达方式，利用多路查询提升知识召回率，然后对于每个问题，我们又使用了混合检索策略进行搜索。

这里的混合检索就是语义检索和全文检索的组合使用，之所以采用这种方式，是因为这两者在能力上具有互补性：语义检索擅长理解语义层面的相似性，而全文检索则擅长精确关键词匹配，从而弥补单一检索策略各自的局限。

语义检索是通过向量距离，计算用户问题与知识库内容的距离，从而得出“相似度”。需要注意的是，这并不是语言学上的相似，而是数学空间中的距离相近。它的优势就是能够找到语义相近的知识，但是它的精度较低，会受到关键词和句子完整度影响。

而全文检索我们采用BM25算法，BM25主要基于词频和逆文档频率（TF-IDF）的加权搜索模型来对文档进行排序和检索。它特别适用于处理较为简单的匹配任务，尤其是当查询和文档中的关键词有直接匹配。

为此通过“多问题查询 + 混合检索”，我们会获得一批候选知识。但此时的结果集合规模较大、质量参差不齐，因此还需要进一步筛选，才能得到真正符合需求的内容。

那我们应该如何处理呢？

首先对相同检索方式的结果使用RRF进行合并，得到两类候选结果，分别为向量检索结果、BM25检索结果，由于混合检索后的查找范围很大，单纯依赖原始相似度分数难以直接过滤结果，因此需要引入重排模型进行精细排序。

重排模型（reranker）对候选结果重新评分，并根据相关度重新排序，绝大多数情况下，可以有效提高搜索结果的准确率。重排后可以得到一个0-1得分，代表着搜索内容与问题的相关度，该分数通常比向量的得分更加精确，可以根据得分进行过滤。

最后我们会使用 RRF 对重排结果、向量搜索结果、全文检索结果进行合并，得到最终的搜索结果。

单个问题的向量检索流程与前面讲解的流程一致，这里多问题并行向量检索的流程如下：

我们使用的Faiss向量库以及MySQL并不直接支持BM25检索，我们采用的策略是：先拿到所有的知识分块片段，并结合用户的问题，利用LangChain提供的BM25Retrieve进行计算，核心代码逻辑如下：

至此，其实AI客服的核心流程都被覆盖了，剩下的也就是最后的生成环节，反而简单了：

我们把大的意图分为了三个，分别是产品咨询、故障反馈、闲聊，进入每个意图后，处理的逻辑是存在差异的，因此大模型生成回答的提示词是不同的。

提示词的重点是构造上下文信息，拼装召回的知识、最新的N条对话历史消息、更旧的历史摘要消息以及用户最新的问题。下面是具体的提示词：

需要注意的是，知识召回后，在大模型真正生成回答时，会让他再次判断召回的知识是否可以回答用户问题，如果没用则拒绝回答，并且把useful字段设置为false；否则，设置为true。

这个字段的用处在于，我们会对大模型回答的问题进行标记，不能回答的问题，会进入低置信度问题池列表，便于后续知识补足和复盘，是为后面的数据飞轮做准备的：

GPT plus 代充 只需 145

当用户意图匹配为“故障反馈”或“功能建议”时，需先确认用户反馈的问题内容，并检查相关功能是否已存在：

• 如果功能已存在，引导用户正确使用或提供解决方案。
• 如果功能不存在，需要评估用户需求是否符合产品原则，以及是否属于明确“不做”范围：

• 如果属于“不做”范围，明确说明并予以拒绝；
• 如果不属于，则继续收集信息。 在信息不足的情况下，需要引导用户补充详细描述；随后对用户的反馈进行数据清洗，并判断反馈类型（故障或优化建议），再分类存入业务数据库，便于后续跟进与处理。

对于严肃型产品服务场景（如电商、医疗、金融等），通常不建议提供闲聊功能，应优先保证回答的准确性和可靠性；在无法确认答案时，宁可不回答，也不应提供可能误导用户的信息。

但在语言学习类应用中，我们有意引入“闲聊意图”，目标是让 AI 客服具有更自然、有温度的互动体验，而不是仅提供机械式回复。

通过适度的闲聊能力，可以增强用户参与感与陪伴感，从而提升整体使用体验与产品黏性：

GPT plus 代充 只需 145

前面的内容，整个客服的流程就已经拉通了，从知识整理、知识入库到问答流程。

现在我们需要进一步调优，就要观察关键的环节是否符合我们的预期，比如，我们需要对每个环节的耗时进行观测。

为此，我们在流程关键节点对核心信息进行了结构化存储，包括：

• 指代消解、用户问题改写
• 意图识别结果
• 向量召回的候选结果列表及置信度
• 最终命中的知识内容及回复结果
• 大模型调用日志

在后台管理系统中，可以看到全流程关键节点的输入和输出信息，可以直观地观测整个 AI 客服的运行状态。

比如：…

通过对这些核心节点的持续监测、分析，可以将原本不可见的系统运行过程由“黑盒”转变为“透明”，从而实现问题可定位、效果可评估、策略可优化，支撑整体能力的持续迭代与提升。

这里必须说清楚，我们搭建的客服系统，，除了人工补齐的方案，我们也增加数据飞轮系统功能。

数据飞轮本质上是一种持续反馈的闭环机制：

通过从用户交互中不断收集数据 → 处理 → 优化 → 再反哺系统 让 AI 在真实业务中越用越准

当然这里并不是把所有的问题都放进知识库，而是：

1. 识别哪些问题值得沉淀；
2. 持续补全真正有价值的知识缺口；

下面结合实际系统设计，介绍在 AI 客服中，如何对低置信度问题进行收集，并持续优化知识库。

置信度

在前文我们提到过，AI 客服的第一步是 意图识别。当用户提问后：

1. 系统会先给问题打标签（例如：产品咨询）；
2. 在对应标签下，进行向量召回；
3. 每条召回结果，都会有一个 置信度（score）；

这个置信度，代表的是：

1. 用户问题 与 知识库内容 的语义匹配程度；
2. 分值越高，说明命中越精准；
3. 分值越低，往往意味着知识库存在缺失或覆盖不足；

在系统中，我将置信度阈值设置为 0.5。当召回置信度 ≥ 0.5时，直接走正常回答流程；当召回置信度 < 0.5时，认为当前知识库匹配度较低，此时，系统会异步处理这条问题数据，进入数据飞轮流程。

问题标准化

模型会基于下面的提示词，完成两件关键事情：

1. 将用户的原始提问进行标准化处理
2. 生成一个示例答案，作为后续处理与参考依据

这一步在信息检索领域中，通常被称为 Question Canonicalization（问题规范化），因为用户的表达通常是口语化、上下文依赖很强，并不适合用于直接存储或检索；

在进入数据飞轮流程前，需要先将问题转化为结构清晰、语义稳定的标准形式，以提升后续召回、匹配与分析效果。

GPT plus 代充 只需 145

数据入库与前后台分工

处理完成后的数据，会进入入库流程，用户端：

1. 负责数据采集；
2. 低置信度问题自动进入待处理队列；

后台管理端：

1. 人工审核；
2. 决定是否写入知识库；

问题审核

不是所有问题都值得沉淀，在后台中，人工需要先对问题进行审核：

当看到某条问题的召回置信度低于 0.5 时，需要判断：

1. 是否为正常业务问题；
2. 是否存在垃圾信息、无意义输入或不当言论；
3. …

同时，也并不是所有问题都适合入库：

1. 低频问题不值得沉淀；
2. 强时效性问题会自然过期；
3. 模型误判为“低置信度”的情况一定存在；

只有审核通过的问题，才会进入向量化流程。这里系统也设置了相似问题出现的次数，可以根据问题出现次数，判断重要性：

效果验证

完成向量化后，知识库中会新增一条元数据：

当下次出现语义相近的问题时，向量检索会命中这条新数据，AI 客服能够给出更贴合的回答。通过数据飞轮的设计，能够让AI客服越用越准。

通过空气小猪 AI 客服项目的实践，相信各位对于什么是简单AI知识库，以及AI知识库如何落地会有更深的理解了。

对于正在迷茫择业、想转行提升，或是刚入门的程序员、编程小白来说，有一个问题几乎人人都在问：未来10年，什么领域的职业发展潜力最大？

答案只有一个：人工智能（尤其是大模型方向）

当下，人工智能行业正处于爆发式增长期，其中大模型相关岗位更是供不应求，薪资待遇直接拉满——字节跳动作为AI领域的头部玩家，给硕士毕业的优质AI人才（含大模型相关方向）开出的月基础工资高达5万—6万元；即便是非“人才计划”的普通应聘者，月基础工资也能稳定在4万元左右。

再看阿里、腾讯两大互联网大厂，非“人才计划”的AI相关岗位应聘者，月基础工资也约有3万元，远超其他行业同资历岗位的薪资水平，对于程序员、小白来说，无疑是绝佳的转型和提升赛道。


对于想入局大模型、抢占未来10年行业红利的程序员和小白来说，现在正是最好的学习时机：行业缺口大、大厂需求旺、薪资天花板高，只要找准学习方向，稳步提升技能，就能轻松摆脱“低薪困境”，抓住AI时代的职业机遇。

如果你还不知道从何开始，我自己整理一套全网最全最细的大模型零基础教程，我也是一路自学走过来的，很清楚小白前期学习的痛楚，你要是没有方向还没有好的资源，根本学不到东西！

下面是我整理的大模型学习资源，希望能帮到你。

扫码免费领取全部内容

从入门到进阶这里都有，跟着老师学习事半功倍。

2026最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

【大厂 AI 岗位面经分享（107 道）】

【AI 大模型面试真题（102 道）】

【LLMs 面试真题（97 道）】

适用人群

四阶段学习规划（共90天，可落地执行）

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型
• 带你了解全球大模型
• 使用国产大模型服务
• 搭建 OpenAI 代理
• 热身：基于阿里云 PAI 部署 Stable Diffusion
• 在本地计算机运行大模型
• 大模型的私有化部署
• 基于 vLLM 部署大模型
• 案例：如何优雅地在阿里云私有部署开源大模型
• 部署一套开源 LLM 项目
• 内容安全
• 互联网信息服务算法备案
• …

  👇👇扫码免费领取全部内容👇👇

  

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【】