万字图文盘点RAG常见的100个核心概念：前 30 个
很多同学看了十几篇 RAG 教程，Embedding、Chunk、向量数据库、BM25 单独都认识，连起来却分不清谁先谁后。
因为 RAG 不只是接个向量数据库。前面要处理文档，后面要排序结果、控制上下文，任何一环出问题，答案都会偏。
下面老王把 30 个核心概念按链路顺序串起来。看完之后，你应该能自己画出一条完整的 RAG 流程了。
整条链路只有三个动作：检索、增强、生成。
01
FOUNDATION
基础原理
01 · RAG
让一个只学过通识课的学生回答专业问题，他大概率答不好。
如果先给他几篇相关资料，再让他回答，结果会好很多。RAG 做的就是这件事：回答之前，先查资料。
系统从知识库里找出相关片段，把片段和用户问题一起交给大模型。模型再基于这些资料生成答案。
整条链路只有三个动作：检索、增强、生成。
真正难的通常不是生成，而是能不能把正确资料找准、找全。
大模型训练完成后，知识基本被冻结。公司内部制度、刚更新的产品文档、训练截止日期之后的信息，它本来就不知道。
不加外部资料，模型只能说不知道，或者根据旧知识硬猜。RAG 的价值，就是让答案不再只依赖模型记忆。
但 RAG 不是万能知识外挂。知识库里没有、没有权限访问，或者检索没有命中的内容，模型仍然拿不到。
— 检索增强生成工作机制
02 · 知识库
知识库是提前整理好的资料集合，RAG 主要从这里检索，不是每次都去互联网现搜。
产品手册、制度文件、客服话术和技术文档，只有先放进知识库，模型回答时才有依据。
知识库里没有的内容，模型无法凭空补出来。
知识库也不是越大越好。过期制度、重复记录和互相矛盾的文档混在一起，只会降低检索精度。
核心指标是内容是否有效、一致，并且能覆盖真实问题。
文档本身写得含糊，模型检索回来也看不懂。同一个问题存在多个冲突版本，模型也不知道该信谁。
所以知识库需要持续治理：旧版本要归档，重复内容要合并，冲突规则要明确生效时间和优先级。
知识库的天花板不是文档数量，而是有效内容覆盖率。放进去一万份低质量资料，不如维护好一百份高频核心文档。
— 知识库如何支撑回答
03 · 语料库
语料库是你能拿到的全部原始内容，还没经过筛选和处理。
比如过去三年的客服聊天记录，都属于语料库。但其中的模板回复、重复问题、表情包和过期信息，不应该直接进入知识库。
语料库像原料仓，知识库像精品货架。
做 RAG 的第一步不是调参数，而是先看原始资料质量到底怎么样。
以客服聊天记录为例，可以保留最近半年的真实问答，去掉机器人模板、纯表情消息和高度重复的问题。
筛选后的内容才适合进入知识库。原始资料覆盖不全，后面再怎么调检索也补不回来。
语料库质量决定知识库上限。缺少真实用户问题、关键制度或异常案例，系统上线后就会出现明显盲区。
— 语料库与知识库
04 · 索引
一本 500 页的产品手册，没有目录，只能逐页找「退货流程」。有目录，十秒就能定位。
索引就是知识库的快速目录。它把文档内容组织成可搜索的数据结构，先找到候选位置，再读取对应文本。
没有索引，每次都要扫描全库。数据量一大，检索就会慢到无法使用。
知识库新增、修改或删除文档后，索引也要同步更新。否则新内容搜不到，旧内容还可能继续被返回。
用户提问时，系统会先提取查询里的关键词或语义特征，再到索引里找候选位置，最后根据位置取回完整文本。
索引存的是快速定位能力，不等于文档正文。它更像目录和路标，真正回答问题的仍然是原始内容。
不同检索方式会建立不同索引。关键词检索依赖倒排索引，向量检索依赖高维向量索引，两者解决的问题并不相同。
— 索引为什么能加速检索
05 · 查询
用户在对话框里输入的话，不一定能直接拿去检索。
比如「上次那封邮件里说的报销怎么办」，其中的时间、邮件和具体诉求都不清楚。
系统要先补全指代、结合对话历史，再拆成「报销流程是什么」「需要哪些材料」这类明确问题。
处理后真正送给检索系统的内容，才叫查询。
很多 RAG 效果差，不是算法不行，而是查询本身就没说清楚。
多轮对话里，这一步更重要。用户先问「退货要几天」，下一句只说「那换货呢」，系统要把上一轮的售后场景补回查询。
一句话里包含多个问题时，也可以拆成多个子查询分别检索，再合并结果。
查询改写不能改变用户原意。补全得太激进，会把模糊问题改成另一个问题，后面的检索再准也没有意义。
— 查询不是用户原话
06 · 检索上下文
检索系统找到很多候选片段后，真正塞进大模型提示词里的那些文字，叫检索上下文。
这是模型生成答案时能看到的外部依据。漏掉关键说明，模型再聪明也答不出来。
文档解析、清洗、分块、嵌入、索引、混合检索和重排序，最终都服务于同一个目标：让检索上下文又准又全。
片段也不能直接乱拼。顺序、衔接和冲突关系都会影响模型理解。
两段资料互相矛盾时，要带上来源、时间和版本信息。否则模型看到两种说法，只能自己猜。
评估 RAG 时，不要只盯着召回率。更应该直接检查：最终塞给模型的那几段资料，到底对不对、全不全。
检索上下文还要控制重复。十段内容如果八段都在重复同一句制度，只会浪费窗口，并不会让答案更可靠。
— 检索上下文如何形成
02
DOCUMENT
文档处理
07 · 数据摄取
把外部数据持续接入知识库，叫数据摄取。
数据可能来自 PDF、网页、工单、聊天记录和业务数据库。每个来源的格式、权限和更新频率都不一样。
一次性导入并不难，难的是长期同步。原文更新、页面归档或字段变化后，知识库也要跟着变。
不同数据源还要选择全量覆盖还是增量追加。策略搞错，要么产生重复数据，要么旧内容永远清不掉。
比如每天导出的完整产品表，适合全量覆盖；持续新增的工单记录，更适合增量追加。
实际项目里还会遇到 API 限流、权限认证、字段变化和编码异常。数据摄取没做稳，后面的知识库只会越来越旧。
一条成熟的数据摄取链路还要能记录来源、更新时间和处理状态，方便失败后重试，也方便追查某段内容从哪里来。
— 数据摄取持续把资料接进来
08 · 文档解析
人看 PDF，能直接分清标题、正文、表格和图片。
计算机看到的却是一串字节。文档解析要把它还原成结构化内容：标题保持层级，表格保留行列，图片文字通过 OCR 提取。
解析错了，后面的检索都会受影响。
双栏 PDF 容易读乱顺序，扫描件不做 OCR 就几乎没有可检索文本。纯文本和 Markdown 最简单，PDF 通常最难。
表格也是高风险区域。把三行四列的数据读成连续文字后，数值还在，但行列关系已经丢了。
解析阶段的目标不是把字提出来就结束，而是尽可能保住文档原来的结构和阅读顺序。
解析完成后最好做抽样检查，重点看复杂表格、跨页内容、双栏页面和扫描件，而不是只验证文件有没有成功导入。
— 文档解析把页面还原成结构
09 · 文本清洗
解析出来的原始文本里，通常混着导航栏、广告、重复页眉、模板回复、乱码和错误换行。
文本清洗就是把这些噪声去掉。
不清洗，噪声也会被编码成向量，甚至因为碰巧出现公司名而被错误召回，白白占用上下文。
但清洗不能一刀切。表格结构、金额、日期和版本号都可能是关键信息，删过头同样会破坏检索。
不同文档需要不同规则。网页重点去导航和广告，PDF 重点去重复页眉页脚，聊天记录重点去系统消息和模板话术。
清洗后的判断标准很简单：留下来的内容能不能独立表达业务含义。
清洗规则也要可追溯。否则发现检索缺少金额或日期时，很难判断是原文没有、解析失败，还是清洗阶段误删了。
— 文本清洗去掉无效噪声
10 · 元数据
元数据就像文档封面上的信息，不属于正文，却能帮助筛选。
常见字段包括标题、时间、部门、文档类型、来源和权限级别。
用户问「今年的报销标准」，系统可以先保留今年、制度类、当前用户有权限查看的文档，再做语义检索。
这样既能缩小范围，也能避免把机密内容返回给无权限用户。
元数据最好在文档入库时就写好，而不是等到检索阶段临时猜。
时间、部门、状态和权限这类高频字段越规范，后面的过滤越快，也越可靠。
元数据字段不是越多越好。只有确实用于筛选、权限、排序或追踪来源的字段，才值得长期维护。
— 元数据是文档的筛选标签
11 · 分块
一份 200 页的手册，不能整本拿去编码，也不该全部塞进大模型上下文。
分块就是把长文档切成多个可独立检索的小段。每个块单独编码、存储和召回。
用户问「退款需要几个工作日」，系统只需要返回包含退款时效的那几块。
块太碎，完整步骤会被拆开；块太大，又会混入无关内容。
标题、列表和表格都是自然结构，切分时尽量不要从中间截断。
比如「退款需要提交以下材料」和后面的材料清单，本来是一个完整语义单元。切开后只召回清单，模型就不知道这些材料用于什么。
分块不只是控制长度，更是在决定系统能检索到什么粒度的信息。
同一份文档也可以采用分层分块：小块用于精准命中，命中后再取它所属的大章节补足上下文。
— 分块把长文档切成可检索单元
12 · 文本块
分块后的每一小段，就是文本块，也叫 Chunk。
它同时承担三个角色：作为嵌入模型的编码输入，作为向量数据库的存储记录，作为大模型最终看到的上下文。
块太长会被截断，太短又缺少语义。块的粒度还会影响检索精度和上下文占用。
所以设计文本块，本质上是在编码、检索和模型理解之间找平衡。
标题、列表和表格标记可以适当保留，它们能帮助模型理解文档结构。
一个好的文本块应该尽量自包含。即使离开前后文，读者也能知道它在讲什么。
必要时可以把上级标题补进块里，让「申请条件」变成「退款申请条件」，减少脱离上下文后的歧义。
文本块通常还会绑定文档 ID、页码、章节和权限等元数据，方便返回来源，也方便从块追溯到原文。
— 文本块同时承担三个角色
13 · 分块大小
单个文本块能装多少内容，叫分块大小，也叫 Chunk Size。
块太小，一段完整操作会被切碎。检索只返回其中一块时，模型看到的步骤就不完整。
块太大，又会把安装、配置和故障排查混在一起，既浪费上下文，也增加噪声。
没有万能数值。FAQ、技术手册和制度文件应该分别调参，最后用真实查询做检索评估。
FAQ 往往一问一答就是一个块，可以切得短一些。技术手册的操作流程需要保留完整步骤，通常要更长。
判断分块大小是否合适，不能只看平均字数，要看真实问题能否召回完整答案。
同一个知识库里可以按文档类型使用不同配置，不必强迫 FAQ、合同和技术手册共享一个分块大小。
— 分块大小太小太大都不行
14 · 分块重叠
相邻文本块之间故意保留一段重复内容，叫分块重叠，也叫 Chunk Overlap。
它解决的是边界断裂问题。退款条件如果刚好跨越两个块，重叠能让前后两块都保留关键内容。
重叠像安全冗余区，但不是越大越好。
10% 到 20% 是常见范围。过大会增加存储和编码成本，过小又起不到保护作用。
语义分块的边界更自然，对重叠的依赖通常比固定长度分块低。
比如一个 500 字的块，可以把末尾 50 到 100 字复制到下一块开头。这样命中任意一块，都不容易漏掉交界处的信息。
重叠内容也会被重复编码和存储，所以它是一种有成本的保险。
如果召回结果里出现大量相邻块的重复内容，可以在拼接上下文前去重，而不是简单把所有命中块全部塞进去。
— 分块重叠给边界留安全区
15 · 语义分块
固定长度分块只看字数，每 500 字切一刀，章节、步骤和列表都可能被拦腰截断。
语义分块看的是内容边界。话题在哪里结束，就在哪里切。
最简单的做法是按标题层级切。更复杂的做法，是用向量相似度识别话题变化，或者让大模型判断段落是否完整。
它的成本更高，但得到的文本块更自包含，检索命中后不需要再拼凑残缺信息。
按标题切最便宜，也最容易解释。用向量相似度识别话题转折更灵活，但需要额外计算。
让大模型判断边界最精细，成本也最高。实际项目通常先从文档结构切分开始，再根据评估结果升级。
语义分块也要设置长度上下限。完全只按语义切，有时会得到特别短或特别长的块，仍然需要二次合并或拆分。
— 语义分块按意思切不按字数硬切
03
VECTOR & INDEX
向量化与索引
16 · 嵌入
嵌入，英文叫 Embedding，就是把文字转换成一串固定长度的数字。
这串数字不是字面编码，而是文字在语义空间里的位置。
「苹果很好吃」和「这个苹果真甜」意思接近，生成的向量也会靠得很近。「今天天气不错」则会离得更远。
RAG 先把查询和文本块都转换成向量，再找距离最近的内容。
这就是语义检索的基础。
不管输入是一句话还是一页文字，同一个嵌入模型输出的向量维度都是固定的。
因此短查询和较长的文档块可以放进同一个空间比较，不会因为字数不同就无法匹配。
嵌入本身不会生成答案。它只负责把语言变成可计算的表示，让后面的相似度搜索能够运行。
— 嵌入把文字变成语义坐标
17 · 嵌入模型
专门把文本转换成向量的模型，叫嵌入模型。
它不会写文章或回答问题，只负责让相似文本靠近、不相似文本远离。
选型主要看三个指标：向量维度、最大输入长度和多语言能力。
维度越高，表达能力通常越强，但存储和计算成本也越高。文本块长度还不能超过模型的输入上限。
最重要的约束是：同一个知识库必须使用同一个嵌入模型。中途换模型，就要把全部文档重新编码。
不同模型形成的语义空间并不兼容。即使输入完全相同，得到的向量位置也可能完全不同。
中英文混合知识库还要特别测试跨语言检索，不能只看模型宣传页上的多语言标签。
选型时应使用自己的业务查询和文档做对照测试，因为公开排行榜的高分不一定能代表你的术语和场景。
— 嵌入模型怎么选
18 · 向量
文本经过嵌入模型后得到的数字数组，就是向量。
它可以理解成一段文字的语义指纹。
在高维空间里，关于「退货」的文本会聚在一片区域，关于「招聘」的文本会聚在另一片区域。
用户查询「退货需要多少天」，系统就去退货区域附近找最近的文档块。
维度太低，语义区分能力不足；维度太高，存储和检索成本会上升。选型仍然是效果和成本的平衡。
向量里的单个数字通常没有直观含义，真正有价值的是整组数字共同形成的位置和方向。
所以向量不是关键词表，也不能靠肉眼解释。它更像机器用来比较语义的坐标。
向量必须和原文本、来源及元数据一起保存。只留数字不留原文，即使检索命中，也无法把可读内容交给模型。
— 向量是文本的语义指纹
19 · 余弦相似度
有了向量，还需要一个方法衡量它们有多相似，这就是余弦相似度。
它把两个向量看成从同一原点出发的两条线。
夹角越小，余弦值越接近 1，语义越相似。方向差异越大，相关性越低。
它主要比较方向，不比较文本长短。因此短查询也能匹配较长的文档块。
系统会把查询向量与候选文档逐一比较，优先返回相似度最高的内容。
例如查询「怎么报销差旅费」，与差旅报销流程对应的文档方向更接近，相似度就会排在前面。
余弦相似度只是相关性信号，不代表内容一定正确。过期文档也可能与查询高度相似。
因此相似度通常要配合时间、权限、文档状态等条件使用，不能把一个高分直接当成最终正确答案。
— 余弦相似度看方向是否接近
20 · 向量数据库
关系型数据库擅长找「订单号等于 123456」的记录，却不擅长找「意思最接近」的内容。
向量数据库就是为相似度检索设计的。
它能从百万甚至亿级高维向量中，快速找到与查询最接近的前几十条，而不是逐条暴力计算。
工程选型还要看元数据过滤、多租户隔离、权限控制、横向扩展和运维成本。
检索性能只是其中一个指标。
不同租户的数据还要隔离，当前用户无权查看的文档必须在检索阶段被过滤。
有些关系型数据库也支持向量扩展。数据量不大时，不一定非要单独引入一套向量数据库。
如果业务还需要复杂事务和结构化查询，保留原数据库并增加向量能力，往往比拆成两套系统更简单。
— 向量数据库专门做相似度搜索
21 · 向量索引
高维向量没有天然顺序，普通数据库的 B+ 树不适合直接拿来做相似度搜索。
向量索引的作用，是先把搜索范围缩小，再在小范围内精确比较。
HNSW 用多层图搜索，精度高、速度快，但内存占用大。
IVF 先把向量聚类，只搜索最近的几个簇，速度快，但可能漏掉簇边界附近的结果。
PQ 通过量化压缩节省内存，代价是更明显的精度损失。
这些方案没有绝对优劣。数据规模、内存预算、响应时间和召回要求不同，选择也会不同。
索引建得越复杂，查询可能越快，但写入、更新和维护成本也会增加。
新增大量文档后，部分索引需要重建或优化。只关注查询速度、忽略更新成本，系统很容易在运营阶段出问题。
— 向量索引的三种常见取舍
22 · 近似最近邻搜索
在 100 万条高维向量里逐条计算相似度，实时体验很难接受。
近似最近邻搜索，简称 ANN，用少量精度换取巨大速度。
它的核心是剪枝：先跳过绝大多数明显无关的向量，只对少量候选做精确比较。
找到的结果不一定是数学上绝对最近的前十条，但通常足够接近，而且能在毫秒级返回。
选择 ANN 方案，本质上还是在精度、速度和内存之间取舍。
HNSW 通过图结构跳转来剪枝，IVF 通过聚类缩小范围。方法不同，目标都是先排除绝大多数无关向量。
线上系统通常用真实查询集测召回率和延迟，再决定能接受多少近似误差。
对于客服问答，前几名轻微换位通常可以接受；对于法律条款或安全规则，漏掉真正最近的结果可能就不能接受。
— 近似最近邻搜索用少量精度换速度
04
RETRIEVAL
检索与排序
23 · BM25
BM25 是经典的关键词匹配算法，只看字面，不理解语义。
它主要考虑三个因素：查询词出现多少次、这个词在全库里有多稀有、文档长度是否会造成偏差。
「退订」这种少见词，比「公司」「这个」更能代表主题，因此权重更高。
BM25 简单、快速、可解释，特别适合产品编号、合同号和法律条款号。
短板也很明显：用户搜「退订服务」，标题是「取消订阅的方法」，一个词都对不上，就可能完全漏掉。
文档长度也会参与打分。同样出现两次目标词，短文里的密度更高，通常比长文更相关。
因此 BM25 特别适合作为精确检索通道，而不是单独承担所有语义问题。
它不需要训练模型，也不需要 GPU。对文档规模不大的场景，BM25 往往是成本最低、最容易建立基线的方法。
— 关键词检索只看字面匹配
24 · 稠密检索
稠密检索把查询和文档都编码成向量，再比较语义距离。
它不只看命中的几个词，而是把整段文字的含义压缩进高维向量。
用户搜「提高客户留存率」，它能找到「降低用户流失的策略」，因为两句话表达的是同一类问题。
这种方式很适合口语化、多种表达和同义词场景。
但产品编号、日期、条款号等精确内容，向量检索可能不如 BM25。
原因是这些稀有符号在嵌入模型里未必有稳定语义。两个只差一位的产品编号，向量距离可能无法反映业务差异。
所以稠密检索解决的是「意思相近」，不是「字符必须完全一致」。
嵌入模型一旦选择错误，稠密检索的上限也会被锁死。尤其是行业术语和中英混合内容，必须单独测试。
— 稠密检索看语义不只看字面
25 · 混合检索
混合检索就是让 BM25 和稠密检索同时工作。
一条路负责产品编号、条款号、日期等精确匹配；另一条路负责口语、同义词和不同句式的语义匹配。
两路各自返回候选，再做合并排序。
融合前通常要先归一化分数，因为 BM25 分数和向量相似度不在同一个量级。
它已经成为 RAG 的常见做法：关键词保精确，向量检索补召回。
两条检索可以并行执行，整体延迟通常不会简单翻倍。
真正需要调的是两路权重：编号类查询可以提高关键词权重，口语化问题则可以提高语义检索权重。
更进一步，还可以先判断查询类型，再动态选择检索策略，而不是让所有问题都使用固定权重。
— 混合检索两条路一起找
26 · 元数据过滤
元数据过滤分为检索前过滤和检索后过滤。
检索前过滤更高效。先按区域、部门、文档类型和权限，把 10 万份文档缩到 2000 份，再做语义检索。
检索后过滤则是先全库搜索，再把无权限或不相关的结果删掉。算力已经花了，返回数量还可能不够。
常见过滤字段包括时间、类型、部门、状态、语言和权限。
高频过滤字段最好设计成枚举值，不要全部使用自由文本。
字符串包含匹配通常比枚举匹配更慢，也更容易出现写法不一致。
权限过滤尤其应该前置。不能先把机密文档召回，再指望后面的模型自行忽略。
检索前过滤过严也会误伤召回。字段缺失或标注错误的文档可能直接被排除，因此元数据质量同样需要监控。
— 元数据过滤先缩小候选范围
27 · Top-K
检索系统返回多少个候选结果，这个数量就是 K。
K 太小，关键内容可能刚好排在下一条，模型永远看不到。
K 太大，又会引入大量弱相关片段，浪费上下文并干扰判断。
简单事实查询可能只需要 3 到 5 条，复杂分析可能需要 10 到 20 条。
Top-K 没有万能默认值，最好根据查询复杂度动态调整。
关键不是把更多资料交给模型，而是让有限的上下文覆盖完整答案。
调参时要同时看召回率、噪声比例和最终回答质量，不能只看返回数量。
有些系统会先多召回一些，再经过重排序只保留前几条。此时检索阶段的 K 和最终进入上下文的 K 不是同一个值。
— 返回条数太少太多都不行
28 · 重排序
混合检索先返回一批候选，但初始排序通常不够精细。
重排序会用更强的模型，重新判断查询和每条候选文档的匹配程度。
它把查询和文档放在一起理解，判断更准，但计算成本也更高。
所以重排序不能跑全库。正确做法是先快速筛出 20 到 50 条候选，再对这几十条精排。
第一阶段负责找全，第二阶段负责排准。
重排序后，原本排在第八名但真正相关的文档，可能被提升到第一名。
最终只把精排后的前几条放进上下文，既控制长度，也提高模型看到关键信息的概率。
重排序模型也要与业务语言匹配。通用模型对专业术语判断不准时，需要更合适的模型或业务数据微调。
— 重排序把真正相关的放到前面
05
GENERATION
生成与效果
29 · 上下文窗口
大模型一次最多能处理的文字总量，叫上下文窗口，通常用 Token 计算。
这个窗口不只装检索片段。系统提示词、对话历史、用户问题和最终输出都要占空间。
留给检索上下文的容量，是总窗口减掉这些固定开销后的剩余部分。
窗口大，也不代表应该塞满。片段太多会稀释注意力，增加延迟和调用成本。
设计时要按实际可用空间计算，不能只看模型标称值。
比如标称 128K 的窗口，扣掉系统提示词、历史对话和输出预留后，真正留给检索片段的空间会少一截。
即使还能放更多块，也要考虑信息密度。几十段资料同时出现时，中间的关键信息反而可能被忽略。
多轮对话还会不断吃掉窗口。常见做法是压缩历史消息、只保留关键轮次，或者在必要时重新检索。
— 上下文窗口总容量要分着用
30 · 忠实性
忠实性衡量的是：答案里的每一句话，能不能在检索上下文中找到依据。
资料只写了三种支付方式，模型却回答五种，多出来的两种就是编造。
忠实性和准确性不是一回事。
资料本身错了，模型照着复述，忠实性可以很高，但答案并不准确。资料是对的，模型自己添加内容，则是忠实性问题。
常见评估方法是把答案拆成句子，逐句检查是否有对应来源。可以人工抽查，也可以用另一个模型自动评估。
还有一种情况也要注意：资料写的是「退款需要 5 个工作日」，模型回答成「一般 3 到 5 天」，虽然听起来合理，却已经偏离了明确依据。
忠实性关注的是有没有根据，不负责判断资料本身是否正确。资料质量和生成忠实性要分开评估。
产品侧还可以要求答案附带引用来源。用户能看到文档名称、章节或链接，既方便核验，也能提高使用信任。
— 忠实性要求每句话都能找到依据
RAG 说到底就是三步：准备好文档，找到相关内容，基于资料生成答案。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～