简介这份资料面向希望系统掌握AI大模型的开发者、产品经理与AI应用爱好者围绕大模型原理、提示词技巧与业务接入经验展开帮助读者解决“会用但用不好”的实际困惑。资源为1个PDF文档压缩包约2.51MB内容涵盖大模型分类与发展脉络、提示词撰写原则与公式、多轮对话与数据安全等常见问题并给出可复用的优化思路。目前已有1546人学习下载适合作为入门到进阶的参考手册。读者可从中获得提示词标准与技巧、复杂任务拆解方法、模型接入中的排错经验以及国内外主流模型的能力差异对比便于在实际工作与学习中快速上手并规避常见误区。1. 从一堆散装笔记到能跑通的 RAG这份 AI 大模型学习资料到底怎么用很多人手里攒了几十 G 的 AI 学习资料从 Transformer 图解到微调脚本一应俱全真到要动手做一个能回答公司内部文档的问答机器人时却连 embedding 该选哪个维度、chunk 切多大都拿不准。这份「AI大模型学习资料与知识点」就是冲着这个断层来的——它不是又一本从感知机讲起的教科书而是把大模型学习路径拆成「原理够用、代码能跑、参数可调」三段覆盖 Transformer 架构、Prompt 工程、RAG 检索增强、LoRA 微调、模型量化部署这几块从业者真正会碰到的内容。适合刚转方向、需要一套能照着敲的参考路线的开发者也适合已经会调 API、但想把底层链路补扎实的熟手。下面按我实际拆包的顺序把这份资料怎么用、哪里容易翻车讲清楚。2. 先搞清楚资料里的技术栈分层别从注意力公式硬啃2.1 三层结构概念层、代码层、调参层这份资料的组织方式不是按论文时间线排的而是按「你当前要解决什么问题」分了三层。概念层放的是 Transformer、注意力机制、位置编码这些必须懂但不必手推的模块配的是图解和最小可运行示例代码层是 RAG 管道、LoRA 微调脚本、量化推理这几套能直接跑的工程代码调参层则是把 temperature、top_p、chunk_size、rank 这些参数单独拎出来讲什么场景该动哪个。我一般建议先翻代码层的目录看哪个脚本跟你手头任务最像跑通之后再回头补概念层里对应的那几节。反过来先啃注意力矩阵推导大概率第三天就放弃了。资料里概念层和代码层是有交叉引用的比如 RAG 那节会回指位置编码告诉你为什么长文档切分后检索效果会掉——这种「用到再学」的路径比线性阅读效率高得多。2.2 环境依赖与版本对齐代码层跑不起来九成是版本问题。这份资料里的示例对 transformers、torch、langchain 这几个库的版本比较敏感尤其是 langchain 近几个大版本 API 改动频繁直接pip install最新版大概率报 import 错误。常见做法是先建独立虚拟环境再按资料里 requirements 的版本装。# 建独立环境别在系统 Python 里折腾 python -m venv llm_env source llm_env/bin/activate # Windows 用 llm_env\Scripts\activate # 按资料给的版本装不要盲目升级 pip install torch2.1.0 transformers4.36.0 langchain0.1.0 pip install sentence-transformers faiss-cpu逻辑说明虚拟环境隔离是为了避免和你机器上已有的其他项目冲突torch 和 transformers 版本必须对齐否则加载模型时会出现权重 key 不匹配。faiss-cpu 是给 RAG 做向量检索用的如果你机器有 CUDA 可以换 faiss-gpu但资料里的示例默认走 CPU 路径先跑通再换。参数说明torch2.1.0对应的是 CUDA 11.8 和 12.1 两个轮子装之前用nvidia-smi看下驱动支持的 CUDA 版本langchain0.1.0是资料里 RAG 脚本验证过的版本0.2 之后RetrievalQA的导入路径变了会直接报错。提示如果你只是想先体验 RAG 效果不想装 torch资料里有一份纯 API 版本的脚本用在线 embedding 接口替代本地模型依赖只有 requests 和 numpy适合快速验证思路。3. RAG 管道实操从文档切分到检索召回3.1 文档切分的三个参数怎么定RAG 效果好不好一半看切分。资料里给的默认是chunk_size500、chunk_overlap50但这两个数不是万能药。chunk_size 指的是每段文本的字符数overlap 是相邻段的重叠部分目的是防止一句话被从中间切断导致语义丢失。我一般会按文档类型调技术文档、API 手册这种句子短、信息密度高的chunk_size 可以压到 300 左右会议纪要、长篇报告这种上下文依赖强的放到 800 到 1000overlap 相应提到 100。切太碎会导致检索出来的片段缺上下文模型答非所问切太大又会让检索精度下降因为一个 chunk 里混了多个主题。from langchain.text_splitter import RecursiveCharacterTextSplitter # 按文档类型调整这两个参数 splitter RecursiveCharacterTextSplitter( chunk_size500, # 每段字符数技术文档可降到 300 chunk_overlap50, # 相邻段重叠长文档可提到 100 separators[\n\n, \n, 。, , , , ] # 中文优先按句号切 ) docs splitter.split_text(open(your_doc.txt, encodingutf-8).read()) print(f切出 {len(docs)} 段第一段长度 {len(docs[0])})逻辑说明RecursiveCharacterTextSplitter会按 separators 列表的顺序依次尝试切分先按段落切段落还太长就按句子切保证不会把一句话拦腰截断。中文场景一定要把「。」「」「」加进 separators默认的英文分隔符对中文不友好。参数说明chunk_overlap不要超过chunk_size的一半否则会出现大量重复内容检索时同一段被反复召回浪费上下文窗口。切完之后打印段数和首段长度是快速验证切分是否合理的习惯动作。3.2 向量化与检索embedding 模型选型切分完就是向量化。资料里默认用的是text2vec-base-chinese这类中文 embedding 模型原因是它对中文语义的捕捉比直接用多语言模型更准而且体积小CPU 也能跑。如果你做的是中英混合文档可以换成bge-m3这类多语言模型代价是推理慢一些。from sentence_transformers import SentenceTransformer import faiss import numpy as np # 加载中文 embedding 模型 model SentenceTransformer(shibing624/text2vec-base-chinese) embeddings model.encode(docs, normalize_embeddingsTrue) # 建 FAISS 索引用内积做相似度 dim embeddings.shape[1] index faiss.IndexFlatIP(dim) index.add(np.array(embeddings).astype(float32)) # 检索把问题也向量化取 top 3 query 这份资料里 RAG 的切分参数怎么调 q_vec model.encode([query], normalize_embeddingsTrue) scores, ids index.search(np.array(q_vec).astype(float32), k3) for i, sid in enumerate(ids[0]): print(f召回 {i1} 得分 {scores[0][i]:.3f}: {docs[sid][:80]}...)逻辑说明normalize_embeddingsTrue把向量归一化后内积等价于余弦相似度所以索引用IndexFlatIP。如果忘了归一化还用内积得分会被向量长度带偏召回结果不可信。参数说明k3是召回条数太小可能漏掉关键信息太大又会把无关内容塞进 prompt 干扰模型。我一般从 3 开始试看回答质量再调到 5。得分低于 0.5 的召回基本可以忽略说明问题和文档语义差距大这时候要考虑是不是切分粒度不对或者 embedding 模型不匹配。3.3 拼 prompt 与生成上下文窗口的取舍召回之后要把片段拼进 prompt 送给大模型。这里有个容易忽略的点不是召回越多越好而是要控制总 token 数不超过模型的上下文窗口同时给生成留出空间。资料里的做法是按得分排序从高到低累加直到接近预算上限就停。def build_prompt(query, docs, scores, ids, max_chars2000): context for score, sid in zip(scores[0], ids[0]): if score 0.5: # 低分召回直接丢 continue if len(context) len(docs[sid]) max_chars: break context docs[sid] \n---\n return f根据以下资料回答问题资料没有的内容不要编造。\n\n资料\n{context}\n问题{query}\n回答 prompt build_prompt(query, docs, scores, ids) print(prompt[:300])逻辑说明prompt 里明确写了「资料没有的内容不要编造」这是抑制幻觉最直接的手段。max_chars2000是给上下文留的字符预算实际项目里要按模型 tokenizer 换算成 token 数中文大致 1 字 1 token 多一点。参数说明得分阈值 0.5 是经验值不同 embedding 模型的分数分布不一样换模型后要重新标定。max_chars要根据你用的模型上下文窗口来定8k 窗口的模型留 2k 给上下文、2k 给回答比较稳妥。4. LoRA 微调避坑显存、rank 与过拟合4.1 为什么选 LoRA 而不是全量微调全量微调一个 7B 模型光优化器状态就要吃掉几十 G 显存普通单卡根本扛不住。LoRA 的思路是冻结原模型权重只在注意力层的部分矩阵旁边挂两个小矩阵做低秩分解训练参数量能降到原来的千分之一级别。资料里给的 LoRA 脚本在 24G 显存的卡上能跑 7B 模型的微调这是它最实用的地方。但 LoRA 不是没有代价。它改变的是模型对特定任务的输出风格和知识偏向对模型本身的通用能力提升有限。如果你的任务是让模型学会一个全新领域的知识LoRA 配合 RAG 一起用效果更好——RAG 负责灌知识LoRA 负责调格式。4.2 rank 和 alpha 怎么配LoRA 里最常调的两个参数是 rankr和 alpha。rank 决定低秩矩阵的维度越大能拟合的能力越强但参数量和过拟合风险也越高。alpha 是缩放系数一般设成 rank 的两倍。from peft import LoraConfig, get_peft_model lora_config LoraConfig( r8, # rank任务简单用 4-8复杂用 16-32 lora_alpha16, # 一般设成 r 的 2 倍 target_modules[q_proj, v_proj], # 只挂注意力层的 Q、V 矩阵 lora_dropout0.05, # 防过拟合 biasnone, task_typeCAUSAL_LM ) model get_peft_model(base_model, lora_config) model.print_trainable_parameters() # 看可训练参数占比逻辑说明target_modules选 q_proj 和 v_proj 是最常见的做法因为注意力里 Q 和 V 对任务适配最敏感。想效果更好可以加上 k_proj 和 o_proj但参数量会上去。print_trainable_parameters()打印出来的占比一般在 0.1% 到 1% 之间如果超过 5% 说明 rank 设太大了。参数说明r8 是起点数据量少于 1000 条时用 4 就够多了容易过拟合数据量大、任务复杂再往 16、32 加。lora_dropout 在数据量小的时候可以提到 0.1数据量大可以降到 0。4.3 训练中的显存与过拟合信号微调过程中最常翻车的两个点显存溢出和过拟合。显存溢出一般出现在 batch size 设太大或者序列长度太长的时候解决办法是开梯度累积用时间换空间。过拟合的信号是训练 loss 一直降但验证 loss 开始回升这时候要么加数据要么降 rank要么早停。training_args TrainingArguments( per_device_train_batch_size2, # 单卡放不下就降到 1 gradient_accumulation_steps8, # 累积 8 步等效 batch 16 num_train_epochs3, learning_rate2e-4, # LoRA 常用 1e-4 到 3e-4 fp16True, # 混合精度省显存 logging_steps10, eval_strategysteps, eval_steps50, save_strategysteps, save_steps100, load_best_model_at_endTrue # 按验证指标存最优 )逻辑说明gradient_accumulation_steps8配合 batch size 2等效于一次更新看 16 条样本显存占用却只有 batch 2 的水平。load_best_model_at_endTrue是防过拟合的后悔药训练结束自动回滚到验证集表现最好的那个 checkpoint。参数说明学习率 2e-4 是 LoRA 的常用值比全量微调高一个数量级因为可训练参数少需要更大的步长。fp16True在支持混合精度的卡上能省近一半显存但老卡可能不支持报错就换成bf16或关掉。5. 常见问题排查这几个坑我替你踩过了5.1 检索召回全是无关内容现象问一个问题召回的片段跟问题八竿子打不着得分还都在 0.6 以上。原因通常是 embedding 模型和文档语言不匹配比如用英文模型编码中文文档向量空间对不上。解决方法是换成中文或多语言 embedding 模型重新建索引。另一个可能是切分太碎单段信息量不足以表达完整语义把 chunk_size 调大再试。5.2 微调后模型开始胡言乱语现象LoRA 微调完模型在训练集上的任务表现很好但一问别的问题就开始输出乱码或重复。原因是 rank 设太大加上数据量少模型把训练数据的模式硬背下来了通用能力被覆盖。解决办法是降 rank 到 4、加 lora_dropout、减少训练轮数或者混入一部分通用指令数据一起训。5.3 显存溢出但 batch size 已经降到 1现象batch size 降到 1 还是 OOM。原因往往是序列长度太长或者模型加载时用了 fp32 而不是 fp16。解决方法是先确认torch_dtypetorch.float16加载模型再把 max_seq_length 从 2048 降到 1024 甚至 512同时开 gradient checkpointing 用计算换显存。5.4 推理速度慢到没法用现象本地部署的模型生成一句话要等十几秒。原因是没做量化fp16 的 7B 模型推理就是慢。解决办法是用 GPTQ 或 AWQ 做 4bit 量化显存占用降到四分之一速度提升明显。资料里量化那节有现成脚本但要注意量化后的模型在复杂推理任务上会有一定精度损失简单问答影响不大。5.5 换了 embedding 模型后检索结果全乱现象把 text2vec 换成 bge 之后之前调好的得分阈值失效召回质量反而下降。原因是不同模型的向量分布和相似度尺度不一样0.5 这个阈值只对原模型有效。解决办法是换模型后重新跑一批测试问题观察得分分布重新标定阈值同时确认新模型的向量维度跟 FAISS 索引对得上维度不匹配会直接报错。6. 量化部署与效果验证把模型塞进有限显存6.1 4bit 量化的实操与精度取舍模型训好了要部署绕不开量化。资料里给的 GPTQ 量化流程大致是准备一批校准数据跑一遍量化脚本导出量化后的权重。校准数据的质量直接影响量化精度最好用跟你任务分布接近的文本别随便拿一段新闻凑数。# 用 GPTQ 做 4bit 量化校准数据用你自己的领域文本 python quantize.py \ --model_path ./merged_model \ --output_path ./model_4bit \ --bits 4 \ --group_size 128 \ --calib_data ./calib.jsonl \ --calib_samples 128逻辑说明group_size128是量化分组大小越小精度越高但压缩率越低128 是精度和体积的平衡点。calib_samples128是校准样本数太少会导致量化误差大太多则耗时128 到 256 之间比较合适。参数说明bits4是主流选择3bit 体积更小但精度掉得明显8bit 精度好但省不了多少显存。量化完一定要用同一批测试问题对比量化前后的回答质量别只看体积。6.2 用固定测试集验证 RAG 效果RAG 和微调都做完怎么知道有没有变好靠感觉不行得有一批固定问题。我一般会准备 20 到 30 条覆盖不同难度的问题每条标注期望答案的关键点每次改动后跑一遍看命中率。验证维度怎么测合格线检索命中率期望片段是否出现在 top 3 召回里80% 以上回答准确率关键点是否被正确回答70% 以上幻觉率是否编造资料里没有的内容10% 以下平均响应时间从提问到出完整回答5 秒以内这张表是我自己用的数值不是绝对标准但能帮你判断改动是正向还是负向。比如你把 chunk_size 从 500 调到 1000检索命中率涨了但响应时间翻倍那就得权衡。6.3 一个容易被忽略的技巧查询改写最后说个提升 RAG 召回的小技巧。用户提问往往很口语跟文档里的书面表达差距大直接拿原始问题去检索效果一般。可以在检索前加一步查询改写让模型把口语问题转成几个关键词或书面问法再分别检索合并结果。def rewrite_query(query, llm): prompt f把下面的问题改写成三个适合检索的关键词短语用换行分隔\n{query} result llm.invoke(prompt) return [q.strip() for q in result.split(\n) if q.strip()] # 多路检索后合并去重 all_ids set() for q in rewrite_query(query, llm): q_vec model.encode([q], normalize_embeddingsTrue) _, ids index.search(np.array(q_vec).astype(float32), k3) all_ids.update(ids[0].tolist())逻辑说明查询改写相当于把用户的口语映射到文档的语义空间多路检索再合并能提高召回覆盖面。代价是多一次模型调用延迟会增加适合对准确率要求高、对延迟不敏感的场景。参数说明改写出的关键词数量控制在 3 到 5 个太多会引入噪声。合并去重后如果召回片段超过预算还是按相似度排序截断。从那以后我每次动 RAG 参数之前都会先把那 20 条测试问题跑一遍留个基线改完再跑一遍对比不然根本不知道是改好了还是碰巧。这套习惯帮我省了不少来回折腾的时间希望帮到你。本文还有配套的精品资源点击获取
