金华市网站建设_网站建设公司_UX设计_seo优化

FSAC未来超级架构师

架构师总动员
实现架构转型，再无中年危机

说在前面

Java+AI太刺激了， 最近一段时间 ， 45岁老架构师 尼恩 凭借Java+AI双栖架构，辅导了一大堆 小伙伴 进了大厂，很多还是P7、P8级技术专家。

有大量的 小伙伴 凭借尼恩改造的 Java+AI双栖架构简历 ，拿到了一线互联网企业如阿里、滴滴、极兔、有赞、希音、百度、网易、美团的面试资格。 在做面试的过程中，持续来找尼恩复盘。

前两天一个 小伙伴面 京东，遇到的一个AI 面试题：

你简历 写了 AI 项目，请问你们 的 RAG 怎么设计的？

了解过RAG语义丢失吗？ 出现过RAG 语义丢失问题吗？

你们怎么解决 RAG 语义丢失问题的？

小伙伴找尼恩复盘， 求助尼恩。

这里尼恩给大家做一下系统化、体系化的梳理，使得大家可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”。

也一并把这个题目以及参考答案，收入咱们的 《尼恩Java面试宝典PDF》V176版本，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。

最新《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请关注本公众号【技术自由圈】获取，后台回复：领电子书

RAG语义丢失面试通关指南：从翻车复盘到答题暴击模版

在AI面试中，RAG（检索增强生成）是高频考察场景，而“语义丢失”问题更是区分候选人工程能力与深度思考的核心考点。

不少候选人简历写“主导工业级RAG落地”，却在面试官的精准追问下暴露短板。

本文先复盘字节真实面试翻车案例，再拆解解决RAG语义丢失的“三板斧”（修正技术细节+补充工程落地），最后总结可直接套用的“暴击面试官”答题模版，帮你快速掌握核心竞争力。

一、 试翻车现场：绝命3问，戳破你的“伪AI项目经验”

很多简历的AI项目，都是 “伪AI项目经验”。

翻车候选人的核心问题是“只懂基础工具调用，缺乏全链路工程思维与语义保障意识”，以下是真题、错误应答、尼恩点评及问题本质的完整拆解。

【绝命1问】：如何处理PDF多栏、Excel字段关联等结构丢失问题？

错误回答：用LangChain的默认文本分割器，不分语言、不设重叠，直接切分。

尼恩点评：

这是典型的“工具化思维”，忽略了文档结构的核心价值。

• 第一，硬切割会直接斩断跨结构的完整语义（如合同中“甲方付款义务”与“乙方违约责任”的关联条款）；
• 第二，大文档全量加载+无差别序列化，极易引发线上内存溢出（OOM），完全不符合工业级高可用要求；
• 第三，未处理表格、多栏的结构信息，后续检索时会丢失关键字段关联（如Excel中“订单号”与“金额”的映射关系）。

问题本质：跳过“文档结构解析”环节，从源头破坏了信息完整性，后续所有处理都是“错上加错”。

【绝命2问】：长文档场景下，如何保证检索结果的上下文完整性？

错误回答：只构建子文本块（Chunk）的向量索引，不做父子块关联，也不用混合检索。

尼恩点评：

• 陷入“碎片化检索”误区。子块检索虽能精准匹配局部信息，但语义是割裂的；
• 缺乏上下文关联时，大模型（LLM）生成的回答会流于表面，甚至出现逻辑矛盾（如只看到“付款期限”条款，忽略前置的“付款条件”）；
• 未用混合检索，无法平衡“精准度”与“完整性”。

问题本质：未建立“分层检索”思维，忽略了长文档语义的层级关联性。

【绝命3问】：文本切分后，如何做检索优化以支撑高并发场景？

错误回答：直接调用向量数据库，不做缓存，全量搜索。

尼恩点评：

• 缺乏并发场景的工程设计能力。
• 工业级RAG常面临QPS=1W的高并发需求，全量检索会导致I/O和CPU负载暴增，检索延迟飙升至秒级；
• 无缓存设计会重复计算相同查询，浪费资源；
• 仅依赖向量检索，无法兼顾关键词精准匹配（如法律文档中的“不可抗力”条款）。

问题本质：检索策略单一，缺乏“性能优化”与“精准度平衡”的工程考量。

绝命3问 翻车的 核心短板总结

3道真题暴露了候选人的三大核心不足：

• ① 文档处理“重切割、轻结构”，源头丢失语义；
• ② 检索策略“单一化、无优化”，无法支撑工业级场景；
• ③ 长文档处理“缺分层、少关联”，上下文完整性不足。

针对这三大短板，以下“三板斧”解决方案可实现全链路语义保障。

二、解决RAG语义丢失的“三板斧”：全链路技术方案

核心逻辑：从“源头（结构解析）- 中间（语义切分）- 末端（检索增强）”全链路保障语义完整性，每个环节均兼顾“技术正确性”与“工程落地性”。

RAG第一板斧：结构还原——从源头规避语义断裂

1、核心问题

将PDF、Excel、Word等非结构化/半结构化文档直接扁平化为纯文本，会丢失表格行列关联、多栏排版顺序、标题层级等关键结构信息，导致后续切分和检索从起点就出错。

2、技术方案

在文本切分前，新增“文档结构解析与序列化”环节，核心是“保留原生结构+绑定元数据”，具体实现：

• PDF处理：用pdfplumber解析页面布局（多栏、留白）、表格（单元格合并/拆分）、图片位置，结合Unstructured提取文本时保留“多栏阅读顺序”，避免左右栏文本错乱拼接；
• Excel处理：用pandas读取时保留行列索引，对空值字段按业务规则填充（如“未填写”标记），将表格数据序列化为“行键-列键-值”的结构化格式，保留字段关联；
• Word处理：用python-docx+Unstructured提取标题层级（如一级标题/二级标题）、段落归属，生成“标题-段落”的树形结构；
• 元数据绑定：为每个结构元素（段落、表格、标题）绑定标准化元数据，包括「文档ID、页码、结构类型（标题/表格/段落）、字段关联（如Excel的“订单号-金额”映射）、语言类型」。

3、关键实施细节（避坑重点）

• 参数配置：PDF表格识别需设置“最小列词数≥2”（避免单字误判为列），Word标题用正则匹配（如“第X章”“1.XX”）确保层级精准；
• OCR降噪：若文档是扫描件（OCR识别），先用HanLP文本纠错模型清洗噪声字符（如模糊的“0”与“O”），再进行结构解析；
• 结构化存储：解析结果用JSON-LD格式序列化存储，便于后续检索时快速关联结构信息。

4、性能与容错优化（工业级必备）

• 性能优化：大文件（＞100MB）按页分片，利用多核CPU并行解析；常用文档的解析结果缓存至Redis，有效期按文档更新频率设置（如每日更新文档缓存1小时）；
• 容错机制：解析失败时降级为“基础文本提取+结构缺失标记”（如标注“该区域为表格，解析失败”），复杂表格（如合并单元格过多）触发人工复核流程。

5、绝命追问精选

绝命追问1：如何处理OCR质量差、排版混乱的PDF？

答：分三步：

• ① 用图像预处理（二值化、去噪）提升OCR识别率；
• ② 用文本纠错模型（HanLP）清洗识别结果；
• ③ 降低结构识别阈值（如表格识别最小列词数改为1），对仍无法解析的区域标注“结构未知”，后续通过人工复核补充，同时将该类文档的解析规则存入配置库，后续遇到同类文档可复用；

绝命追问2：如何高效处理十万级PDF文档？

答：采用“分布式解析架构”：

• 用HDFS存储原始文档，Spark作为计算框架按文档类型（合同/报告/表格）分片并行解析；
• 通过redis 缓存不同文档类型的解析参数（如合同类PDF的标题正则、表格识别阈值），避免重复调优；
• 解析结果存入ES，支持按元数据快速筛选。

RAG第二板斧：语义化切分——三层递进式精准分割，筑牢语义防线

1. 核心问题

传统固定长度（字符级）切分会切断完整语义单元（如中文长句、合同条款），且未适配大模型的Token上下文窗口，导致检索信息碎片化，LLM生成时逻辑断裂。本质上，文本切分并非简单的“字符串切割”，而是一场关于语义完整性保障的攻坚战，处理不当会让RAG系统沦为“高延迟的搜索引擎 + 低可信的幻觉生成器”。

2. 技术方案

采用“由浅入深、逐层加固”的三层递进式策略，构建从基础防护到智能补偿的语义防御闭环，核心是“以语义完整性为核心，适配大模型窗口限制与业务场景需求”，具体实现：

第一层：中文优化的递归分隔符切分——建立基础防线

拒绝使用默认英文分隔符进行暴力切割，采用定制化中文分隔序列，优先在自然语义边界切割：

separators=[ '\n\n', # 段落优先 '\n', # 换行其次 '。', '！', '？', '…', '……', # 中文句末标点全覆盖 '；', '，', '、', ' ', '']

默认设置chunk_size=512（Token数），chunk_overlap=64（不低于10%），确保“若…则…”等条件句式不被割裂。此层适用于新闻、日志等结构清晰的短文本场景，QPS可达5万+，内存可控，适合大规模批处理，解决硬切导致的显性语义断裂问题。

第二层：HanLP语义级切分——实现精准手术刀式切割

针对法律合同、学术论文等专业文档，上升到语言理解层面，引入HanLP进行句法分析与语义边界识别：

• 利用依存句法树识别不可切割的语义结构（如“7个工作日内”等完整时间状语、“虽然A，但是B”等复合句）；
• 通过语义停顿检测确定合理切割点，输出基于真实语义边界的句子列表，再动态合并至目标块大小；
• 关键工程实践：使用@lru_cache缓存已解析段落，提升重复文本处理效率3倍以上；设置threading.Semaphore(10)控制JVM并发，防范Full GC风暴。

此层虽单次耗时上升至~150ms，但语义保真度达工业级要求，特别适用于高准确性诉求的专业知识库场景。

第三层：父文档关联切分——构建端到端语义闭环

即便切分精准，局部匹配仍无法替代全局理解，需通过父子块关联补充上下文：

• 子块：按条款/句子切分（256 Token），用于精确命中关键词；
• 父块：保留原始片段（1024~2048 Token），存储章节主旨与上下文，存入独立DocStore；
• 绑定关联：为每个子块绑定父块ID，形成“子块精准匹配+父块上下文回填”的完整语义链路。

同时，结合目标大模型上下文窗口动态适配参数：搭建“模型参数映射表”，内置GPT-4 8k/32k、Claude 2 100k、通义千问 8k等主流模型窗口大小；通过tiktoken计算文本Token数，按模型窗口的25%确定chunk最大Token数（预留生成空间），自动匹配overlap率。

3. 关键实施细节（避坑重点）

• 场景适配策略：无最好方案，仅存最优组合，需根据文档类型匹配对应切分方案（如下表）；
• 避免过度重叠：overlap过高导致检索冗余，过低丢失跨chunk关联，按文档类型控制在10%-20%；
• 元数据补充：为每个chunk绑定“父结构ID、文档类型、语义边界标记”等元数据，便于后续检索关联与筛选。

4. 性能与容错优化（工业级必备）

• 性能优化：缓存句法分析结果与热点文档切分结果；对高并发场景采用“预切分+缓存”策略，提前处理热点文档；
• 容错机制：语义分析服务异常时，降级为“递归切分+固定Token阈值”；切分后过小的chunk（＜100 Token）自动与相邻chunk合并；JVM异常时触发熔断降级，确保pipeline不中断；
• 监控体系：通过Prometheus采集JVM内存、GC频率、请求延迟等指标，设置告警阈值，支持故障溯源。

5. 面试追问精答

问：如何避免“甲方同意乙方在收到通知后7日内付款”这类中文长句被切分？

答：用HanLP句法分析识别“时间状语（收到通知后7日内）- 谓语（付款）”的依存关系，在“后”“内”等关键介词前设置禁止切分标记，确保整个条件句作为完整chunk；同时，将这类常见法律句式存入“语义保护规则库”，提升切分效率与准确性。

问：如何为不同大模型动态调整切分参数？

答：搭建“模型参数映射表”，内置主流模型的上下文窗口大小；切分时先通过tiktoken计算文本Token数，再根据目标模型窗口的25%（预留足够空间给LLM生成）确定chunk的最大Token数，自动匹配对应overlap率；例如GPT-4（8k窗口）对应chunk Token数≤2000，通用资讯场景overlap设为10%。

RAG第三板斧：检索增强——分层关联+混合检索，兼顾精准与完整

1. 核心问题

仅建立子chunk向量索引，会导致“盲人摸象”式检索：虽能精准匹配局部信息，但缺乏长文档的层级上下文（如章节主旨），LLM生成回答缺乏深度；

单一检索策略无法兼顾“关键词精准匹配”与“语义相关性”。尤其需避免局部匹配缺失全局语境，如用户问“违约金怎么算？”仅返回“5%”却遗漏“非不可抗力”前提，引发合法性风险。

2. 技术方案

采用“父子块分层关联+BM25+向量检索混合策略+相似度过滤”，核心是“精准定位子块+补充父块上下文+平衡检索精度与完整性”，结合双store结构（vectorstore + docstore）构建语义锚点网络，具体实现：

父子块分层关联：

• ① 父块：按章节/大语义单元切分（Token数1024~2048），存储章节主旨、核心观点；
• ② 子块：按条款/句子切分（Token数256），存储具体细节；
• ③ 三级映射：通过“文档ID-父块ID-子块ID”建立关联，检索时先匹配子块，再通过父块ID从DocStore提取父块上下文，形成“细节+主旨”的完整信息；
• 10万字以上长文档新增“祖父块”层级，形成“祖父-父-子”三级关联，避免上下文遗漏；

混合检索策略：

• 结合BM25关键词检索与向量语义检索，经AB测试确定最优权重比（0.4:0.6），实现优势互补：
• ① BM25：擅长精准匹配关键词（如法律文档中的“不可抗力”“违约金”），适合刚性条款检索；
• ② 向量检索：擅长捕捉语义相关性（如“付款时间”与“履约期限”的同义关联），适合模糊查询；
• ③ 动态加权：根据业务场景调整权重（法律场景：BM25 40%+向量60%；通用资讯场景：BM25 30%+向量70%），用户输入含引号的精准关键词时，提升BM25权重至60%；
• 通过ParentDocumentRetriever自动融合子块检索结果与父块上下文；

相似度过滤与元数据筛选：

• ① 设定相似度阈值（如0.7），过滤低相关度结果，减轻LLM负担；
• ② 利用前文绑定的元数据（文档类型、页码、结构类型）进行前置筛选（如仅检索“合同类文档的表格字段”），提升检索效率；
• ③ 可度量评估：通过F1-score、hit-rate、context_coverage等指标持续追踪检索效果。

3. 关键实施细节（避坑重点）

父子块映射：

通过“文档ID-父块ID-子块ID”三级索引确保关联正确，避免跨章节映射错误；子块UUID与父块ID的映射关系写入数据库持久化，防止数据错乱；

• 权重动态调整：支持根据用户查询类型自动切换权重，精准关键词查询提升BM25权重，模糊语义查询提升向量检索权重；
• 长文档适配：10万字以上长文档（如长篇合同、研究报告），新增“祖父块”层级（按文档大类切分，如“合同主体部分”“违约责任部分”），形成“祖父-父-子”三级关联，避免上下文遗漏。

4. 性能与容错优化（工业级必备）

性能优化：

• ① 向量库分片：将向量索引按文档类型/时间分片（如100片），提升检索并行度；
• ② 热点缓存：将高频查询结果（如近30天的热门合同条款检索）缓存至Redis Cluster，目标命中率≥85%；
• ③ 索引优化：为元数据建立倒排索引，提升前置筛选效率；
• ④ 分布式架构：高并发场景采用负载均衡分发请求，实现水平扩展；

容错机制：

• 父块关联失败时，扩展子块的overlap区域（如从15%提升至30%），通过相邻子块补充上下文；
• 混合检索异常时，降级为单一检索模式（优先BM25保证可用性）；
• 极端高并发时，暂停非核心字段索引，优先保障核心检索字段可用性。

5. 面试追问精答

问：如何为10万字长合同划分父子块？

答：采用三级分层策略：

• ① 祖父块：按合同核心模块切分（如“主体信息”“付款条款”“违约责任”“争议解决”），每个祖父块Token数5000-8000；
• ② 父块：按祖父块下的章节切分（如“付款条款”下的“付款时间”“付款金额”“付款方式”），每个父块Token数1024-2048；
• ③ 子块：按具体条款切分（如“付款时间为合同签订后30日内”），每个子块Token数256；通过“三级ID映射”绑定关联关系，检索时子块精准匹配+父块/祖父块补充上下文，确保语义完整；同时将子块与父块ID映射关系持久化存储，防止数据错乱。

问：如何支撑1W QPS的高并发检索？

答：核心是“分片+缓存+降级”三级优化：

• ① 向量库分片：将1000万级向量索引分成100片，每片承载500 QPS，通过负载均衡分发请求；
• ② 热点缓存：将Top 20%高频查询结果缓存至Redis Cluster，设置10分钟过期时间，目标命中率≥85%；
• ③ 降级策略：极端高并发时，先通过元数据筛选减少检索范围，再降级混合检索为BM25检索（牺牲部分语义相关性，保证延迟＜100ms）；同时，非核心字段（如页码、文档类型）暂停索引，优先保障核心检索字段可用性；
• ④ 监控保障：通过Prometheus全链路埋点，实时监控检索延迟、命中率等指标，及时发现并处理异常。

三、尼恩暴击面试官的 模版（直接套用）

核心逻辑：面试官考察RAG语义丢失问题，本质是评估“问题定位能力+全链路方案设计+工程落地思维”。

以下模版按“6步闭环”组织语言，确保逻辑连贯、重点突出，同时体现技术深度与实战经验。

1. 破题：直击本质，点明三大核心矛盾

这不是一个简单的“字符串怎么切”的问题，而是一场关于语义完整性保障的攻坚战。在RAG系统中，文本切分一旦失控，会直接引发三个致命问题：

• 语义单元被切断：比如“7个工作日内”被拆成“7日”和“内”，LLM误读为“内心回复”，产生精准错误；
• 上下文关联丢失：关键条件状语（如“非不可抗力情形下”）与结果分离，导致模型输出看似合理实则违法的答案；
• 检索精度不足：即使关键词命中，缺乏全局语境支撑，召回内容无法用于有效推理。

这三个问题叠加起来，会让整个RAG系统沦为“高延迟的搜索引擎 + 低可信的幻觉生成器”。

所以，我们不能把文本切分当作预处理步骤来对待，而必须视为构建语义链路的第一环——它决定了大模型能否“看见全貌，理解逻辑”。

2. 基础方案：三层递进式解决方案，打造端到端防御体系

我们的策略是“由浅入深、逐层加固”，构建从基础防护到智能补偿的三层防御闭环。

第一层：中文优化的 RecursiveCharacterTextSplitter —— 建立基础防线

我们首先拒绝使用默认英文分隔符对中文文本进行暴力切割。

取而代之的是定制化分隔序列：

separators=[ '\n\n', # 段落优先 '\n', # 换行其次 '。', '！', '？', '…', '……', # 中文句末标点全覆盖 '；', '，', '、', ' ', '']

并设置 chunk_size=512, chunk_overlap=64（不低于10%），确保短句不被“若…则…”类结构割裂。

这一层解决的是硬切导致的显性断裂，适用于新闻、日志等结构清晰的短文本场景，QPS可达5万+，内存可控，适合大规模批处理。

第二层：HanLP语义级切分 —— 实现精准手术刀式切割

当面对法律合同、学术论文等专业文档时，正则已不够用。

我们必须上升到语言理解层面。

我们引入 HanLP 进行句法分析与语义边界识别：

• 利用其依存句法树判断“7个工作日内”是一个完整的时间状语；
• 通过语义停顿检测，避免将“虽然A，但是B”这类复合句错误拆分；
• 输出基于真实语义边界的句子列表，并动态合并至目标块大小。

关键工程实践包括：

• 使用 @lru_cache 缓存已解析段落，提升重复文本处理效率3倍以上；
• 配置 fallback 到正则切分机制，实现熔断降级，保障SLA。

虽然单次耗时上升至~150ms，但语义保真度达到工业级要求，特别适用于高准确性诉求的专业知识库。

第三层：父文档检索 + 混合排序 —— 构建端到端闭环

即便切得再准，局部匹配也无法替代全局理解。用户问“违约金怎么算？”，如果只返回“5%”却不带前提“非不可抗力”，那就是合法性的灾难。

为此，我们构建了三级补偿机制：

(1) 子块检索（Small Chunk）：粒度小（256 tokens），用于精确命中关键词；

(2) 父块补充（Parent Chunk）：原始片段保留（1024~2048 tokens），存储于独立DocStore，供上下文回填；

(3) 混合检索融合：结合 BM25（关键词召回强）与向量检索（语义泛化强），加权融合（经AB测试确定 0.4:0.6 最优），再通过 ParentDocumentRetriever 自动提取对应父块作为context输入LLM。

这样实现了：“查得到、看得全、信得过” 的终极目标。

3. 场景分治：没有银弹，只有适配场景的最优组合

我们坚信：没有最好的方案，只有最合适的架构。

同时，我们在所有层级都部署了工程化容错机制：

• 缓存：LRU缓存句法分析结果，减少重复计算；
• 降级：JVM异常时自动切换至正则切分，保证pipeline不断；
• 监控：Prometheus采集 JVM 内存、GC频率、请求延迟，设置告警阈值；
• 持久化映射表：子块UUID ↔ 父块ID 映射写入数据库，防止数据错乱。

这才是真正的工业级鲁棒性设计。

4. 架构跃迁：从字符串处理升维到语义基础设施

最终，我们要完成一次认知跃迁：文本切分不是NLP的起点，而是RAG系统的架构原语。

我们将 RAG 重新定义为“语义链路构建（Semantic Linking）”过程，融合三大能力：

• NLP能力：不只是分词，更是句法理解与语义边界识别；
• 存储拓扑：双store结构（vectorstore + docstore）形成语义锚点网络；
• 检索策略：多路召回 + 权重融合 + 上下文增强，构成可演进的检索智能体。

这套体系具备：

• 可度量：F1-score、hit-rate、context_coverage 等指标持续追踪；
• 可监控：全链路埋点，支持故障溯源；
• 可演进：未来可接入大模型自身做 adaptive splitting，实现动态chunking。

RAG 不再是一个工具函数，而是成为工业级AI基础设施的核心组件之一。

说在最后：有问题找45岁老架构取经

尼恩提示： 要拿到 高薪offer， 或者 要进大厂，必须来点高大上、体系化、深度化的答案， 整点技术狠活儿。

只要按照上面的 尼恩团队梳理的 方案去作答， 你的答案不是 100分，而是 120分。 面试官一定是 心满意足， 五体投地。

按照尼恩的梳理，进行 深度回答，可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”，然后实现”offer直提”。

如何学习大模型 AI ？

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

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

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

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

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

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

第一阶段（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 项目
• 内容安全
• 互联网信息服务算法备案
• …

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。

如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。

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