别让PDF里的饼图和PPT里的折线成为你RAG系统的"智障盲区"——一文打通多模态文档理解的任督二脉，让大模型真正"睁眼看世界"

文字目录：

1. 多模态RAG的"视觉盲区"：纯文本RAG在图表处理上的致命伤
2. 图表检测与区域提取：从"截图运气流"到"精准定位"
3. PDF图表解析实战：穿透版式迷雾的"分层拆解术"
4. PPT图表解析实战：原生图表的"后门读取"与降级方案
5. 图表语义编码与向量化：让大模型读懂"海拔高度"
6. 多模态检索链路设计：召回、重排与生成的全链路闭环

嗨，大家好呀，我是你的老朋友精通代码大仙。接下来我们一起学习 《大模型RAG生成式AI开发实战》37.[第4章 多模态RAG] 文档理解增强：PDF、PPT中的图表提取与分析

“饭要一口一口吃，代码要一行一行敲，但PDF里的图表你要是还当纯文本处理，那这口饭能噎死你。”

这句话扎心不？很多刚入坑RAG的小伙伴，好不容易搭了个向量数据库，接了个大模型，觉得万事大吉。结果老板扔过来一份五十页的季度财报PDF，或者一份产品规划的PPT，问了一句："这个增长趋势和竞品对比怎么看？“你的RAG系统当场表演一个"已读乱回”。

为啥？因为系统根本没"看见"那些饼图、柱状图、折线图。它眼里只有从PDF里抠出来的干巴巴文字，图表区域对它来说要么是空白，要么是一团乱码。这就是新手在多模态RAG路上遇到的第一个大坑——视觉盲区。今天这篇，咱们就把PDF和PPT里的图表提取与分析掰开揉碎了聊。我不跟你讲虚的，就聊实打实的技术方案和踩坑实录。坐稳了，发车。

---

1. 多模态RAG的"视觉盲区"：纯文本RAG在图表处理上的致命伤

咱们先摆正一个认知。传统的RAG系统，说白了是个"书呆子"，只会啃文字。它把PDF、PPT转成文本，切成chunk，塞进向量库。这套打法在纯文字文档里确实溜，但一旦遇到带图表的文档，立马从学霸变学渣。

新手最容易犯的错，就是认为"文档解析=文本提取"。你拿PyPDF2、pdfminer或者随便找个开源库，把PDF读成字符串，感觉挺顺利的，对吧？但你想过没有，页面中间那个占了一半版面的柱状图，这些库是怎么处理的？

大部分情况下，它们直接忽略。或者更惨，把图表内部的零散文字（比如坐标轴数字、图例）东一块西一块地抠出来，混在正文里，上下文全乱了。

我给你举个真实到血泪的案例。假设你有一份销售报告PDF，里面有个饼图写着"Q1占比35%，Q2占比40%"。你用PyPDF2提取文本，可能得到的是：

Sales Report
Q1
35
Q2
40

看到这些文本chunk的时候，你的RAG系统一脸懵逼："35"是啥？“40"又是啥？是人数？金额？还是页码？当用户问"第二季度销售占比多少"的时候，系统要么检索不到，要么更可怕——它开始瞎编，说"第二季度占比是40%，环比增长5个百分点”。听起来挺像回事？但那个饼图里Q2明明是30%，它把坐标轴和饼图数据搞混了。

这就是纯文本RAG的致命伤：图表承载的结构性信息、空间关系和视觉语义，全部被销毁了。

那正确做法是什么？咱们得建立多模态文档理解的认知。一份PDF或PPT，它的信息密度是分层级的：

• 文本层：段落、标题、列表
• 图表层：柱状图、饼图、折线图、散点图
• 版式层：栏位、对齐、颜色语义
• 元数据层：页码、章节、作者

你的RAG系统必须戴上"眼镜"，把这几层信息同时纳入处理流程。具体落地时，别再只用单一文本解析器了。引入专门的多模态文档解析工具，比如MinerU、Marker、Unstructured，或者自研的版面分析流水线。

以MinerU为例，它的核心思路是先把页面渲染成图像，用布局分析模型识别出"这里是文字块"、“那里是图表区域”，然后对文字块走OCR和文本提取，对图表区域走专门的视觉解析链路。Marker则更侧重于学术PDF，能把LaTeX排版的公式、表格、图表都结构化地抽出来。这些工具的共同点是：图表被识别出来后，会走专门的图表理解链路，而不是和正文文字搅在一起。

文本检索归文本检索，图表检索归图表检索，最后在生成阶段再做融合。这样，你的系统才算真正"睁开了眼"。图表不是文档的装饰品，而是高密度的信息载体。把图表当空气，你的RAG就会在某些问题上变成"人工智障"。

---

2. 图表检测与区域提取：从"截图运气流"到"精准定位"

既然知道图表很重要，那下一个问题来了：怎么在密密麻麻的文档页面里，把图表区域自动找出来？这一步叫图表检测（Chart Detection）或版面分析（Layout Analysis），是整个多模态RAG的前置关卡。

我见过太多新手在这一步"八仙过海，各显神通"，但姿势都不太对。

第一类选手，我称之为"截图运气流"。他们写死坐标，比如"第3页左上角(100,200)到右下角(500,600)一定是那个柱状图"。好家伙，你这代码要是只处理一份固定版式的文件，那确实能跑。但老板明天换了个模板，或者换了个部门发来的PPT，坐标全变，你的代码当场罢工。维护这种硬编码，就跟在屎山上雕花一样，越雕越崩溃。

第二类选手稍微聪明点，用正则匹配。看见页面上有"Figure 1"、"图2"这种字样，就把前后区域的图片抠出来。但问题是，很多商业PDF里的图表根本没有标题，或者标题在千里之外。你匹配个寂寞。

第三类选手走向了另一个极端：反正现在多模态大模型强，我把每一页PDF都转成高清图片，一股脑扔给GPT-4V或Qwen-VL，让它自己看。这思路方向没错，但成本呢？一页PDF如果按1024x1024的图送进去，token消耗直接起飞。一份100页的文档，光是过一遍页面视觉理解，账单就能让你肉疼。而且检索阶段你怎么做？把100张图都编码成向量存进去？检索效率低得令人发指。

正确的姿势，是引入专门的版面分析模型做"精准定位"。现在的目标检测和文档理解模型已经非常成熟了。比如YOLOv8、DETR、LayoutLMv3，在文档版面分析任务上表现相当稳健。它们的训练数据里通常包含了"figure"、“table”、"chart"这些区域标签。你可以直接拿开源权重用，也可以用少量业务数据做个微调。

整个流程是这样的：

先让轻量级的检测模型过滤一遍，只把确认包含图表的区域裁剪出来（ROI, Region of Interest）。这样既避免了硬编码的脆弱性，又避免了全量送图的高成本。

实际操作上，你可以用PaddleOCR里的PP-Structure，它内置了版面分析能力，能直接输出文字、标题、图片、图表、表格的坐标框。或者上Hugging Face拉一个现成的LayoutLMv3微调模型，输入页面图像，输出若干个bounding box和类别标签。你只需要过滤出label为"chart"或"figure"的框，把它从原页面裁切下来，保存为独立图片。

裁切的时候注意分辨率。PDF是矢量格式，渲染成图片时最好用较高的DPI（比如200以上），保证图表细节清晰，不然后续OCR或者视觉模型容易把"8"看成"3"。

这一步还有一个隐藏技巧：多尺度检测。有些图表占满整页，有些只是边角的一个小趋势图。你的检测模型如果在单一尺度上训练，可能会漏掉小图。可以在预处理时做个图像金字塔，或者直接用支持多尺度特征的检测器。

别靠运气截图，也别盲目全图扫描。用版面分析模型做"雷达定位"，只把图表区域精确送检，是成本和效果的最佳平衡点。

---

3. PDF图表解析实战：穿透版式迷雾的"分层拆解术"

图表区域已经抠出来了，现在面对的是一个棘手的对手——PDF。PDF这玩意儿天生就不是给人读的，它是给打印机看的。同样的一个柱状图，在PDF内部可能是图片、可能是矢量路径、可能是内嵌的字体glyph，甚至可能是多层叠加的。

新手在这里最容易踩的坑，就是"一刀切"——不管什么PDF，统一转成图片然后OCR。

我给你说个血泪案例。有份研报PDF，里面的柱状图是用矢量路径画的（就是PDF内部存了一堆line to、curve to指令）。你拿工具转成了PNG，然后用PaddleOCR去识别上面的数字。结果柱状图顶部的数字"85"和坐标轴的"60"在图像上挨得近，OCR直接读成了"8560"或者漏掉了其中一个。更惨的是，有些矢量图表转图片时抗锯齿没做好，数字边缘发虚，"3"和"8"傻傻分不清楚。

还有一种情况，PDF里的图表其实是图片嵌进去的（比如从截图粘贴过来的）。这种你OCR还能抢救一下。但如果是矢量图，你明明可以直接提取绘制指令，还原出原始数据，却非要走"渲染->截图->OCR"这条弯路，属于典型的放着正门不走偏要翻窗户。

另外，很多新手不知道PDF里的图表可能带有隐藏数据。有些学术图表会把完整数据表藏在PDF的附件里，或者作为图表的替代文本（Alt Text）。你一通OCR操作，精度损失不说，还漏掉了更结构化的数据源。

PDF图表解析必须做分层拆解，先看"出身"，再对症下药。

第一层：图片型图表。如果检测到的区域本质是位图（可以用pdfimages或者PyMuPDF检查XObject类型），那就走图像链路。高DPI渲染出来，送专门的图表理解模型，比如微软的DePlot、Google的Chart-to-Text，或者直接用多模态大模型做视觉问答（VQA）。DePlot这类模型被专门训练来理解图表结构，能把柱状图转成数据表格，比通用OCR靠谱得多。它会把图表先解析成代码表示（类似matplotlib的代码），再从中提取数据。

第二层：矢量型图表。如果图表是由路径指令构成的（这在用LaTeX、Matplotlib、R生成的学术PDF里特别常见），你要换个思路。工具比如pdf2svg可以把页面转成SVG，然后解析SVG路径，提取矩形条的坐标和高度，反推出原始数值比例。更简单粗暴的，用pdfplumber读取页面上的线条和文字位置，通过空间对齐关系重建数据结构。pdfplumber的好处是能拿到每个字符的精确坐标，你可以写规则把y轴刻度和柱子顶部的数值对应起来。

# 伪代码示例：分层处理逻辑
import fitz  # PyMuPDF

doc = fitz.open("report.pdf")
page = doc[0]

# 检查区域里的对象类型
for img in page.get_images():
    # 处理图片型图表
    process_image_chart(img)
    
for drawing in page.get_drawings():
    # 处理矢量路径，提取线条和矩形
    process_vector_drawing(drawing)
    
# 结合文字位置做数据对齐
words = page.get_text("dict")["blocks"]

第三层：表格型图表。有些图表本质上就是美化过的表格，比如带颜色背景的甘特图。这时候别硬用视觉模型，先用camelot或tabula提取表格，拿到结构化DataFrame，再判断是否需要补充视觉描述。

还有一个绝招：多模态融合校验。如果你既有OCR结果，又提取到了矢量路径的相对数值，两者可以互相校验。OCR读出的绝对数字可以用来标定矢量路径的比例尺，这样即使坐标轴被截断了，你也能推算出真实数值。

PDF是文档界的"千层饼"，图表解析不能一刀砍。图片型走视觉理解，矢量型走路径解析，表格型直接结构化提取，分层拆解才能穿透版式迷雾。

---

4. PPT图表解析实战：原生图表的"后门读取"与降级方案

聊完PDF，咱们来说说PPT。如果说PDF是"铁桶阵"，难啃但套路固定；那PPT就是"变形怪"，尤其是.pptx格式，它里面藏着的秘密比你想的多得多。

新手处理PPT图表，最常见的操作是什么？转成PDF，然后走上一章的路子。

停！你这属于主动放弃治疗。PPT里的图表，特别是Office原生创建的图表（就是你在Excel里填了数据，然后复制到PPT里的那种），它是带有底层数据缓存的！你转成PDF，这些数据就直接丢了，只剩下一张渲染后的图。你从PDF里再怎么OCR，都是二手信息，精度打折不说，数据完整性也没保障。

我见过最离谱的案例：一个产品经理把竞品分析PPT转成PDF上传RAG系统。PPT里本来有个动态柱状图，带了12个月的数据。转PDF后，因为版式压缩，只显示了前6个月的柱子，后6个月被截掉了。结果用户问"下半年趋势如何"，RAG系统基于PDF里残缺不全的图，一本正经地胡说八道。

还有一种情况，PPT里的图表是用形状拼出来的（比如用矩形手工堆了一个柱状图）。这种"伪图表"没有底层数据，但也不是标准图片，走常规解析很容易漏掉。

正确的PPT图表解析，必须分两种情况，走两条路。

情况一：原生Office图表（有后门）

如果你的输入是.pptx文件，直接上python-pptx库。这个库可以读取PPT的XML结构，直接访问图表对象。

from pptx import Presentation
from pptx.chart.data import ChartData

prs = Presentation("report.pptx")
for slide in prs.slides:
    for shape in slide.shapes:
        if shape.has_chart:
            chart = shape.chart
            # 直接读取系列和类别数据
            for series in chart.series:
                print(f"系列名: {series.name}")
                print(f"数据点: {series.values}")
                # 拿到干净的数据，直接生成JSON或CSV

看到没？根本不需要OCR，不需要视觉模型，直接从XML里把数据捞出来。拿到这个数据后，你可以做两件事：

1. 生成高质量的自然语言描述（比如"2024年用户增长在Q2达到峰值85万，随后Q3回落至72万"）。
2. 保留结构化数据，在RAG生成阶段供大模型做精确计算和推理。

情况二：图片型或形状拼装的图表（硬骨头）

如果PPT里的图表是从外部粘贴的图片，或者是用PPT形状工具手绘的，那确实没有后门可走。这时候需要做降级处理：

第一步，用python-pptx提取高清图片。PPT里的图片通常是原分辨率嵌入的，比转PDF再截图清晰得多。

第二步，送图表专用VQA模型。比如用Qwen-VL、LLaVA-1.5，或者专门的ChartQA模型。给模型设计好prompt，要求它输出结构化JSON：

请分析这张图表，输出以下JSON格式：
{
  "chart_type": "柱状图",
  "title": "2024年季度销售额",
  "x_axis": ["Q1", "Q2", "Q3", "Q4"],
  "y_axis": "销售额（万元）",
  "data": [{"category": "Q1", "value": 120}, ...],
  "trend": "整体呈上升趋势，Q4达到峰值"
}

第三步，PPT还有一个特殊资源：演讲者备注（Notes）。很多商务PPT的图表旁边，演讲者备注里已经写好了对这张图的解读。用python-pptx读取slide.notes_text_frame，往往能得到比OCR更准确的图表语义。

PPT解析要记住一个原则：能走后门绝不翻窗。原生图表直接读XML，图片型才上视觉模型，别忘了演讲者备注这个隐藏的彩蛋。

---

5. 图表语义编码与向量化：让大模型读懂"海拔高度"

图表提取出来了，数据也有了，下一步是把它变成向量，让检索系统能根据用户问题把相关图表找回来。这一步叫语义编码，是多模态RAG的"灵魂翻译官"。

新手在图表向量化上，通常有两个极端。

第一个极端是文本简化主义。把图表随手拍个脑袋，生成一句简单的描述，比如"2023年销售柱状图"，然后把这个句子用text-embedding模型转成向量。这有啥问题？用户问"去年哪个季度增长最快"，这句话里根本没有"柱状图"三个字，语义匹配度很低。而且"2023年销售柱状图"这句话丢失了所有数值信息，检索召回基本靠运气。

第二个极端是像素原教旨主义。直接把图表图片送进CLIP，拿到视觉向量。CLIP这类模型确实能把图像和文本映射到同一空间，但它在细粒度的图表理解上表现很弱。你问"增长率超过20%的有哪些"，CLIP向量根本捕捉不到这种数值条件，因为它训练时主要学的是"图里有只猫"这种粗粒度对齐。

更隐蔽的坑是结构化数据孤岛。有些同学好不容易用DePlot把图表转成了CSV表格，结果把这张表原封不动地当字符串存进向量库。CSV字符串的语义是极其稀疏的，text-embedding模型很难理解"150, 230, 89"这组数字的业务含义。

图表语义编码必须走**“三路并发”**的策略，三条腿走路才稳。

第一路：结构化数据通道

把图表解析成干净的结构化格式，比如JSON或Markdown表格。但别直接存原始字符串，而是生成语义化的键值对：

{
  "chart_title": "2024年各产品线季度营收",
  "x_categories": ["Q1", "Q2", "Q3", "Q4"],
  "series": [
    {"name": "云服务", "values": [120, 150, 180, 210], "trend": "持续上升"},
    {"name": "硬件", "values": [200, 180, 160, 140], "trend": "逐渐下滑"}
  ],
  "key_insights": ["云业务Q4达到全年峰值210万", "硬件业务连续三季度下滑"]
}

这个JSON不仅保留了精确数值，还通过"key_insights"注入了高层语义，让检索时能匹配到"增长"、“下滑”、"峰值"这类关键词。

第二路：自然语言描述通道

用图表captioning模型或精心设计的prompt，生成一段详细的自然语言摘要。注意，这不是简单的一句话，而是包含数据、趋势、极值、对比的段落：

“该折线图展示了2023年1月至12月的月活用户变化。MAU从1月的45万增长至8月的峰值92万，增幅达104%。随后在Q4出现小幅回落，12月收于85万。整体呈先 rapid growth 后 stable adjustment 的态势。”

这段描述要存成文本chunk，走标准的text-embedding流程（比如BGE-M3、OpenAI text-embedding-3-large）。用户问"月活什么时候最高"、“Q4表现如何”，都能召回这段文本。

第三路：视觉embedding通道

对于视觉相关性要求高的问题（比如"找那张蓝底红线的趋势图"），保留图表的视觉向量。可以用专门的多模态embedding模型，如Jina-CLIP、BGE-VL，或者把图片和描述拼接后编码。在索引时，可以存多模态向量；在检索时，根据query类型决定走文本向量还是视觉向量。

最终的索引结构应该是这样的：

另外，一个进阶技巧是生成伪问题（Pseudo-Queries）。针对每个图表，让大模型生成10个可能的用户问题，比如"哪个产品线营收最高"、“云服务和硬件的反差在哪”。把这些伪问题也向量化存入索引。检索时，用户问题更容易和伪问题命中，召回率能提升一大截。

图表向量化不能只靠"一张图"或"一句话"。结构化数据保精度，自然语言描述保召回，视觉向量保相关性，三路并发才能建好图表的语义高速公路。

---

6. 多模态检索链路设计：召回、重排与生成的全链路闭环

前面的工作都是铺垫，最终要让图表在RAG的全流程里发挥价值。从用户提问，到检索召回，再到重排序，最后到大模型生成，图表必须深度参与每一个关节。

很多新手做多模态RAG，检索链路设计得非常"瘸腿"。

最常见的瘸腿情况是检索端歧视。向量库里既有文本chunk也有图表chunk，但检索时只召回文本。为啥？因为文本chunk的数量通常占绝对优势（比如一份报告100个文本块只有5张图），向量相似度打分的时候，图表的描述文本往往打不过长篇大论的段落。结果用户明明问的是图表内容，召回的全是文字段落，图表被埋在海量文本里永不见天日。

还有一种情况是重排端失明。即使图表被召回来了，过了个朴素的交叉编码器（Cross-Encoder），这个编码器只懂文本，不懂图像。它看到图表chunk附带的那点文字描述，觉得"这玩意跟用户问题关系不大"，直接给排到后面去了。

最致命的是生成端近视。好不容易把图表chunk送到了大模型面前，结果你传的是文字描述，而原始图片没给大模型看。现在的大模型（尤其是GPT-4V、Qwen-VL、Yi-VL）都是"视觉动物"，你给它看原始图表图片，它能自己发现趋势、对比、异常点；你只给它看转述的文字，信息经过了一层损耗，模型再厉害也补不回那些视觉细节。

要治好这条瘸腿，必须从检索、重排、生成三个环节同时动手术。

检索环节：多路召回与索引分离

不要把图表和文本混在一个大池子里裸奔。建议做分离索引：

• 文本索引：标准text-embedding，负责背景知识、段落细节。
• 图表索引：每个图表存三条记录（描述文本、结构化JSON、图片路径/视觉向量）。

用户提问时，先做个查询意图识别。用个轻量级分类器或LLM判断这个问题是在问数据、问趋势，还是问概念。如果是数据/趋势类问题，优先检索图表索引；如果是概念解释类，优先文本索引。这就是路由检索（Routed Retrieval）。

也可以做多路召回：一路走文本向量，一路走图表的视觉向量，一路走图表描述文本向量，最后做RRF（Reciprocal Rank Fusion）合并结果。RRF公式简单有效，能把不同来源的排序融合成统一的优先级。

重排环节：多模态重排器

别再只用纯文本的Cross-Encoder了。引入多模态重排模型，比如ColPali、magic-bge-multimodal，或者把图表图片和问题文本一起送进一个小参数的多模态模型打分。

如果暂时没有多模态重排器，也可以做规则后处理：强制保证召回结果里至少包含N个图表chunk（如果查询意图是数据类）。这叫多样性截断（Diversity Truncation），简单粗暴但有效。

生成环节：多模态上下文拼接

这是最关键的一步。当你的RAG系统决定了要用某个图表来回答问题时，上下文里不仅要包含图表的文字描述和结构化数据，还要把原始图片传给多模态大模型。

设计prompt时可以这样组织：

基于以下信息回答用户问题：

[相关文本上下文]
...
[图表结构化数据]
图表标题：2024年营收趋势
关键数据：Q1 120万, Q2 150万, Q3 180万, Q4 210万
...
[图表图片]
<image>
...
用户问题：去年哪个季度增长最快？请结合图表详细说明。

多模态大模型看到原始图片，能验证结构化数据有没有被解析错；看到结构化数据，能做精确计算；看到文本上下文，能补充业务背景。这三者互为备份，能极大降低幻觉概率。

如果图表数量多，上下文装不下，可以用分层生成：先用LLM根据问题选出最相关的1-2张图，再只把这几张图送进最终生成环节，避免视觉token超限。

多模态RAG的检索链路，必须让图表参与从召回、重排到生成的全生命周期。检索时别让它被文本淹没，重排时别让它被视觉忽视，生成时别让它只活在文字转述里。

---

写在最后

聊到这儿，咱们把这章关于PDF和PPT图表提取与分析的核心要点串了一遍。你看，多模态RAG这件事，难吗？其实思路理顺了并不难，但它确实比纯文本RAG多了好几个维度需要考量。

从最开始建立"图表也是信息主角"的认知，到用版面分析模型做精准定位，再到PDF的分层拆解和PPT的后门读取，然后是图表的语义编码与三路向量化，最后落地到检索链路的闭环设计——每一步都是在给你的RAG系统安装一副更高级的眼镜。

我知道，很多新手看到这些工具链、模型、格式，头都大了。可能你现在的项目里连基础的文本RAG都还没跑稳，就要面对多模态这个"大魔王"。但我想跟你说，别慌。技术演进就是这样，先建立正确的认知框架，再逐个击破工程细节。你今天搞懂了图表在RAG里的位置，明天遇到视频、音频的多模态需求，底层逻辑也是相通的。

编程之路不易，每一步成长都算数。你的RAG系统现在看不懂图表没关系，只要按照今天聊的这些步骤，一点一点把能力补上去，它迟早能从"文盲"进化成"看图说话"的高手。

保持好奇，持续学习，多动手实验。那些PDF里的饼图、PPT里的折线，终将成为你系统里最可靠的论据，而不是最扎心的盲区。加油，咱们下篇见！

关注私信备注：“资料代找获取”，全网计算机学习资料代找：例如:
《课程：2026 年多模态大模型实战训练营》
《课程：AI 大模型工程师系统课程 (22 章完整版 持续更新)》
《课程：AI 大模型系统实战课第四期 (2026 年开课 持续更新)》
《课程：2026 年 AGI 大模型系统课 23 期》
《课程：2026 年 AGI 大模型系统课 21 期》
《课程：AI 大模型实战课 8 期 (2026 年 2 月最新完结版)》
《课程：AI 大模型系统实战课三期》
《课程：AI 大模型系统课程 (2026 年 2 月开课 持续更新)》
《课程：AI 大模型全阶课程 (2025 年 12 月开课 2026 年 6 月结课)》
《课程：AI 大模型工程师全阶课程 (2025 年 10 月开课 2026 年 4 月结课)》
《课程：2026 年最新大模型 Agent 开发系统课 (持续更新)》
《课程：LLM 多模态视觉大模型系统课》
《课程：大模型 AI 应用开发企业级项目实战课 (2026 年 1 月开课)》
《课程：大模型智能体线上速成班 V2.0》
《课程：Java+AI 大模型智能应用开发全阶课》
《课程：Python+AI 大模型实战视频教程》
《书籍：软件工程 3.0: 大模型驱动的研发新范式.pdf》
《课程：人工智能大模型系统课 (2026 年 1 月底完结版)》
《课程：AI 大模型零基础到商业实战全栈课第五期》
《课程：Vue3.5+Electron + 大模型跨平台 AI 桌面聊天应用实战 (2025)》
《课程：AI 大模型实战训练营 从入门到实战轻松上手》
《课程：2026 年 AI 大模型 RAG 与 Agent 智能体项目实战开发课》
《课程：大模型训练营配套补充资料》