简介这是一份AI工程领域的系统学习资源对应Chip Huyen所著《AI EngineeringBuilding Applications with Foundation Models》适合希望将生成式AI落地到实际产品中的工程师与技术决策者。全书围绕构建AI应用的全流程展开涵盖提示工程、RAG检索增强生成、代理系统、模型微调与数据工程等核心技术并结合延迟、成本、幻觉治理与评估基准等生产环境中的关键问题提供从原型到部署的实践框架。资源包为1个pdf文件大小64.7MB共1个文件内容完整、版式清晰便于电脑端或平板深度阅读。目前已有2498人学习下载是入门AI应用开发并掌握生产级构建方法的实用参考资料。1. AI 工程实战指南RAG 与 Finetuning 是把模型变可用的两条主线把大模型接进真实业务绝大多数团队最终都会走到同一道岔口知识问答用 RAG还是直接 Finetuning我在一线做 AI 工程实践这两年见过太多项目死在选型阶段——不是模型不行是没把这两件事的边界想清楚。这份指南围绕 RAG 和 Finetuning 两条主线把选型、管道搭建、LoRA 微调、部署评测的完整链路拆开讲参数和步骤都能直接复现。适合手里已经有大模型 API 或开源模型、但还没形成完整工程 pipeline 的算法工程师和全栈开发也适合刚接手 AI agent 项目的同学用它对照自己团队的方案。看完你会发现大部分坑不是算法问题是工程习惯问题。2. 选型攻防RAG 与 Finetuning 的边界、代价与决策清单2.1 RAG 的原理检索、增强、生成三段式RAG 的全称是 Retrieval-Augmented Generation核心思路是把模型的知识来源从参数内部外挂到外部知识库。系统由离线建索引、在线召回、增强生成三段组成离线阶段把业务文档切块、向量化、写入向量库在线阶段把用户问题转成向量到库里做相似度检索拿回 top_k 个片段最后把这些片段拼进 prompt让 LLM 基于给定内容生成答案。整个流程里模型权重完全不动知识更新等价于重建一次索引这是它适合业务资料频繁变化的根本原因。为什么检索质量决定 RAG 上限因为 LLM 的幻觉多半来自硬答——模型不知道的知识它也会强行编。RAG 把证据前置到 prompt 里把生成变成摘编但这有个前提证据本身得正确且完整。所以工程上真正要调的是 chunk_size、embedding 模型、top_k、重排序这些检索侧参数它们的组合直接决定回答质量。我一般把优化顺序定成先保证召得回再谈生成好召不回正确答案prompt 写得再精细也是无米之炊。RAG 也有明确的失效场景纯逻辑推理、需要跨多个段落拼接才能得出结论的问题、以及答案根本不在知识库里的开放问题。识别这些场景很关键因为它们是 Finetuning 或模型原生能力该负责的部分。很多团队把 RAG 当万能药知识库里什么都没有也硬接结果评测集上看着还行因为题目都是库里出的线上真实问题一多就露馅。选型的第一步不是比技术是先承认问题的边界。2.2 Finetuning 的原理LoRA 改变了什么Finetuning 走的是直接改权重的路线。全量微调对 7B 模型来说优化器状态加梯度就要吃掉数倍于模型尺寸的显存小团队基本扛不住。LoRALow-Rank Adaptation把权重更新 ΔW 分解成两个低秩矩阵 A 和 B 的乘积训练时原权重冻结只更新这两个小矩阵。一个 4096×4096 的线性层用 rank16 的 LoRA可训练参数量从 1600 万压到 13 万出头显存占用掉到可以接受的量级。LoRA 微调适合解决三类问题输出格式约束稳定输出 JSON、风格迁移客服话术、报告语气、工具调用与指令遵循AI agent 的函数调用格式。它改变的是模型的行为习惯不是注入事实知识。如果你想用微调让模型记住一批业务数据效果远不如 RAG而且每次数据更新都要重新付一遍训练成本。这是最常见的选型翻车把 RAG 该干的活硬塞给微调训练完发现模型要么过拟合在样本上要么换个问法依旧胡说。训练侧还可以用 QLoRA 进一步压显存先把基座模型 4bit 量化再挂 LoRA一张 24G 卡就能跑 7B 模型。代价是训练速度略慢、精度略有损耗但收益大于代价。需要警惕的是 adapter 与基座版本的强耦合LoRA 权重只对训练时的基座版本有效换了基座模型文件必须重新训练或至少做一轮完整验证否则推理结果不可信。2.3 决策清单一张表判断该走哪条路把业务诉求抽象成几种典型场景选型时先对号入座。业务诉求首选方案原因私有文档问答、知识库检索RAG知识可增量更新能给出引用来源无需重训输出格式固定、工具调用Finetuning行为模式需要模型内化prompt 约束不稳定答案需要分钟级实时性RAG微调无法覆盖高频数据变化大规模风格迁移Finetuning每轮推理都带风格 prompt 成本高且易漂移既要知识又要行为规范RAG Finetuning 混合微调定行为RAG 供知识表格之外还有一个现实判断标准更新频率与成本。RAG 的主成本是一次性索引加上持续的向量库存储和检索服务Finetuning 的成本是 GPU 机时而且每次行为标准推翻都要重新付。我习惯写一小段脚本把两边成本算成可比数字而不是凭感觉拍板。def estimate_rag_index_cost(doc_chars: int, embed_batch: int 64, embed_api_price: float 0.0007): # 估算 RAG 一次性建索引成本中文约 1.8 字符折算一个 token tokens doc_chars / 1.8 batches -(-tokens // embed_batch) # 向上取整 return batches * embed_batch * embed_api_price def estimate_lora_train_cost(hours: float 10, gpu_price_per_hour: float 8): # 7B 模型 LoRA 训练 3 epoch 单卡 A100 约 6-10 小时 return hours * gpu_price_per_hour print(estimate_rag_index_cost(2_000_000)) # 200 万字文档 print(estimate_lora_train_cost())这段代码的价值在于把决策从感觉变成可算。RAG 在文档量不大时非常便宜而且知识更新是常态时边际成本趋近于零微调则相反每次改动都全额付费。混合方案也越来越多见先用 LoRA 把模型的输出格式、工具调用能力焊死再让 RAG 负责实时知识。建议刚起步的团队先把 RAG 做通只有 prompt 压不住格式时才引入微调——少一条技术线就少一堆要守的坑。3. 把 RAG 管道跑通切分、向量化、检索重排的步骤与参数3.1 文档切分chunk_size 与 overlap 不是拍脑袋定的切分是 RAG 管道里最被低估的环节也最容易出现看着合理、用着拉胯的结果。chunk 太小一段话被拦腰切断召回回来全是没语境的碎片chunk 太大整段向量在 embedding 空间里被拉平检索精度下降。中文业务文档的经验区间是 chunk_size 300-500 字符、overlap 50-80 字符并且优先在段落和句子边界切而不是按固定长度硬切。from langchain_text_splitters import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size400, # 中文按 400 字符切 chunk_overlap60, # 相邻块重叠 60 字符保住跨块语义 separators[\n\n, \n, 。, , , , , ], keep_separatorTrue, # 保留分隔符避免句子被从中间掐断 ) docs splitter.split_text(origin_text) print(f切出 {len(docs)} 块平均块长 {sum(len(d) for d in docs) // len(docs)})逻辑说明RecursiveCharacterTextSplitter 按优先级从上到下尝试分隔符先用段落空行分块块仍超长时再按句号、逗号逐级下探直到满足 chunk_size 约束keep_separatorTrue 保证切分后句子仍是完整语法单元这是防止句子从中间断掉的关键。参数上chunk_size 调小了召回精度上升但上下文碎片化调大了语义完整但向量被稀释overlap 是给跨块语义买的后悔药但不宜超过 chunk_size 的 20%否则索引体积和重复内容会明显膨胀。结构化内容要单独处理。表格、XML、日志这类数据如果走文本切分语义会被彻底打散。常见做法是写独立的解析器按行、按单元格、按字段层级切块再在向量库里用 payload 字段存原始位置方便召回后回溯原文。这一步工程量不小但它是 RAG 引用来源可信度的根基——没有位置信息的召回等于黑匣子输出用户问这段结论是哪份文档里的你答不上来。3.2 Embedding 模型与向量库选型Embedding 模型决定了语义相似这件事怎么度量。中文场景常用的有 bge-m3、text2vec-large-chinese、m3e 系列。bge-m3 支持最长 8192 token 输入多语言混合场景表现稳是目前新建项目的优先选择。要特别留心输出维度bge-m3 是 1024 维text2vec 是 768 维。维度一旦确定向量库的索引结构和距离度量随之确定中途换模型意味着全量重建索引这个坑后面还会细说。向量库方案定位优势注意FAISS单机库部署简单毫秒级响应无分布式无完整 CRUD 运维Milvus分布式服务支持过滤、多副本、水平扩展组件多运维成本高Qdrant轻量服务开箱即用支持 payload 过滤集群模式需单独部署距离度量的选择也要说明向量库常用的有内积IP、欧氏距离L2、余弦相似度。向量做 L2 归一化之后IP 和余弦是等价的所以很多向量库默认用 IP 以追求计算速度。建议在建索引前统一把向量归一化这样相似度阈值解释起来更直观也方便未来在不同向量库之间迁移而不改业务代码。选型建议按数据量走十万级以内、单机部署FAISS 完全够用pip 装完就能跑要上云、要多副本和复杂过滤再迁 Milvus 或 Qdrant。别一上来就上重组件运维负担会把项目拖死。我见过一个团队只有两万条文档就上了三节点 Milvus 集群最后排查问题的时间比写业务代码还多。3.3 检索与重排序top_k 召回、cross-encoder 精排的工程实现检索侧的标准打法是粗召回 精排两段式先用双塔 embedding 做 ANN 检索快速拿几十条候选再用 cross-encoder 对候选做细粒度精排最后只取三五条进 prompt。from flag_embedding import FlagModel from sentence_transformers import CrossEncoder embedder FlagModel(BAAI/bge-m3, use_fp16True) reranker CrossEncoder(BAAI/bge-reranker-v2-m3) def retrieve(query: str, top_k: int 50, rerank_n: int 5): q_vec embedder.encode_queries([query]) # 在向量库内做 ANN 粗召回先拿 50 条候选 hits vector_db.search(q_vec, top_ktop_k) # cross-encoder 对 query-文档对逐一打分 pairs [(query, hit[text]) for hit in hits] scores reranker.predict(pairs) ranked sorted(zip(hits, scores), keylambda x: x[1], reverseTrue) return [h[text] for h, _ in ranked[:rerank_n]]逻辑说明第一段用的是双塔结构query 和文档各自独立编码成向量交给 ANN 索引做近似最近邻检索速度快但精度有限第二段 cross-encoder 把 query 和每条候选文档拼接后过同一个编码器直接输出相关性分精度高但每对都要过一次模型所以只能用在粗召回之后。参数上top_k 建议 40-80太小容易漏掉正确答案太大 reranker 延迟明显升高rerank_n 决定最终进 prompt 的块数普通问答 3-6 块足够多了反而稀释模型注意力。还有两个常被忽视的检索调参点。第一是 query 扩写用户问题很短、指代不清时先用一个小模型把问题扩写或改写再向量化召回质量的提升肉眼可见。第二是混合检索把 BM25 稀疏检索和稠密向量检索的分数做融合处理专有名词、订单号、型号这类精确匹配问题特别有效因为 embedding 对生僻词的处理远不如字面匹配。这两招加起来能覆盖八成以上的召回失败。4. 把 LoRA 微调落地数据、超参与合并部署的完整链路4.1 训练数据格式化对话模板决定模型学会什么微调效果的权重七成在数据三成在参数。数据格式必须按模型要求的对话模板组织每条样本是一个完整的 messages 数组system 放全局约束user 放指令assistant 放期望输出。训练时 tokenizer 会自动把模板拼进去你只需要保证 JSONL 里角色完整、顺序正确。常见错误是样本只有 user 和 assistant 两轮、system 约束残缺模型上线后对拒答规则毫无概念。import json def build_training_sample(system: str, user: str, assistant: str): # 一条样本 一组完整多轮对话assistant 的角色必须存在 return json.dumps({ messages: [ {role: system, content: system}, {role: user, content: user}, {role: assistant, content: assistant}, ] }, ensure_asciiFalse) samples [ build_training_sample( 你是订单客服只根据订单信息回答不知道就说不知道。, 我的订单 8341 什么时候发货, 订单 8341 显示已出库预计 3 天内送达物流单号 SF124…, ), ] with open(train.jsonl, w, encodingutf-8) as f: for s in samples: f.write(s \n)逻辑说明训练样本以对话数组形式存储ChatML 之类的模板会在加载时由 tokenizer 自动包裹。训练时只对 assistant 的最后一条回复计算 loss前面的 system 和 user 轮次作为上下文参与前向计算但不回传梯度。注意 system 里千万别漏不知道就说不知道这类拒答约束它是后续防幻觉的第一道防线。数据质量三件事必须做同一意图至少写 5 种问法否则模型对表达方式过拟合换个说法就不灵assistant 回复不要带解释性噪音格式严格统一让模型学的是结构不是废话再掺 10% 的负样本明确要求模型回答不知道或转人工。这套做法对 AI agent 的工具调用微调同样适用——把函数定义和调用序列写进 assistant 输出模型很快能学会先选函数、再填参数、最后触发调用的动作序列。4.2 LoRA 超参lora_r、lora_alpha、target_modules 怎么设LoRA 的核心超参其实很好理解。r 是低秩分解的维度决定可训练参数的容量alpha 是缩放系数实际学习步长按 alpha/r 计算target_modules 决定哪些层挂 adapter。注意力四件套 q/k/v/o 是默认挂载点把 MLP 层的 gate/up/down 加进去能提升容量但显存和过拟合风险也随之上升。from peft import LoraConfig lora_config LoraConfig( r16, # 低秩维度决定可训练参数容量 lora_alpha32, # 缩放系数实际步长 alpha / r target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, biasnone, )常用起点是 r8-16、alpha16-32、lora_dropout0.05。r 不是越大越好超过 64 后收益递减只增加显存和过拟合风险alpha 与 r 的比值稳定在 2 附近效果比较稳。learning_rate 对 LoRA 来说可以比全量微调更激进1e-4 到 2e-4 是常见区间QLoRA 可以 2e-4 起步。from transformers import TrainingArguments training_args TrainingArguments( output_dir./lora_out, per_device_train_batch_size2, gradient_accumulation_steps8, # 等效 batch size 2 * 8 16 learning_rate1e-4, warmup_ratio0.03, num_train_epochs3, logging_steps10, save_steps200, fp16True, # 半精度训练7B 模型 24G 显存可跑 remove_unused_columnsFalse, # 保留 messages 列别让 Trainer 丢掉 )逐个说参数per_device_train_batch_size 受显存限制7B LoRA 在 24G 卡上取 2 比较稳gradient_accumulation_steps 把等效 batch 撑到 16 左右batch 太小梯度过噪、太大收敛变慢warmup_ratio 0.03 让前几百步学习率从零爬升避免开局震荡num_train_epochs 取 2-3 即可LoRA 因为更新参数少训练轮数再多容易在训练集上过拟合。显存还吃紧就换 QLoRA加载时把基座 4bit 量化LoRA 仍以全精度更新7B 模型 24G 卡 batch_size 能到 4。4.3 合并与部署从 adapter 到 vLLM 推理服务训练完拿到的是 adapter 权重一堆零散小文件不能直接上生产。我习惯先把 adapter 合并回基座再统一管理模型版本。from peft import PeftModel from transformers import AutoModelForCausalLM base AutoModelForCausalLM.from_pretrained(base_model_path) model PeftModel.from_pretrained(base, ./lora_out/checkpoint-last) merged model.merge_and_unload() # 把低秩矩阵合回原权重 merged.save_pretrained(./merged_model)合并后建议做一次合并前后一致性抽查用同一批 prompt 分别跑 adapter 模式和合并模式对比输出分布。这一步能拦截版本不匹配、混精度导致的隐性偏差属于上线前的后悔药。合并后上推理服务vLLM 是目前的主流选择吞吐和显存控制远好于裸 transformers 推理命令行启动即可python -m vllm.entrypoints.openai.api_server \ --model ./merged_model \ --quantization awq \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85几个参数解释tensor-parallel-size 单卡就填 1多卡按 GPU 数量填max-model-len 按训练时的 max_length 设不要贪大它直接决定 KV cache 预分配的大小gpu-memory-utilization 控制 KV cache 可用的显存比例0.85 是稳的起点要给模型权重和激活值留余量。量化方案选 AWQ 还是 GPTQAWQ 对激活值敏感在 7B 这个量级精度损失通常更小GPTQ 生态更老、算子兼容性好。没有特殊依赖直接上 AWQ。5. 部署与评测避坑五个真实翻车记录和排查方法5.1 召回侧翻车切分过碎与 embedding 版本不一致坑 1切分过碎导致上下文碎片化。现象是检索回来的 top_k 全是单句碎片答案翻半天找不到完整背景模型只能基于残句生成答得前言不搭后语。原因基本都出在 chunk_size 设到 200 以内且没有按段落边界切句子被拦腰截断。解决chunk_size 提到 400-500强制优先用段落空行、句号做分隔符overlap 控制在 15% 左右切完随机抽 20 块人工读一遍确认没有断句。坑 2重建向量库后检索结果全是乱码。现象是换了一个 embedding 模型重建索引后召回分数普遍偏低返回的内容和 query 牛头不对马嘴。原因往往是新旧向量混在了同一个库里新模型输出维度可能不同即便维度相同向量空间的分布也变了距离计算完全失去意义。解决从建库第一天就把 embedding 模型名和版本写进 collection 的元数据重建时整体替换而不是追加上线前抽样算一遍同义 query 对的相似度分布确认分布合理再切换。5.2 生成侧翻车检索到了模型却没引用坑 3检索命中没问题模型却编了一段不相干的话。现象是最相关的 chunk 已经被召回且排在第一但生成的答案完全没用到它甚至和检索内容矛盾。原因大概率是 system prompt 里没强制约束只依据检索内容回答模型的自由发挥习惯没有压住。解决在 system prompt 里写死引用规则把检索块编号后要求答案必须标注编号格式类似依据 [3][5] 回答同时把检索块原文完整放进上下文而不是只放摘要。坑 4同一套代码、同一份知识库评测分数忽高忽低。现象是连续跑三次评测准确率能差二十个百分点找原因找半天。原因多半是 generation 参数没固定temperature 设成 0.7同样的检索结果每轮生成的路径都不一样评测自然抖动。解决评测和线上稳定场景把 temperature 固定为 0top_p 固定为 1需要多样性的场景单独开一条高温度链路两条链路参数互不影响。这个坑在 RAG 问答里最隐蔽因为你会下意识怀疑检索或 prompt 变了其实模型压根没做确定性解码。5.3 部署侧翻车显存 OOM 与并发排队坑 5vLLM 刚启动正常压测到 20 并发直接 CUDA OOM。现象是服务单请求时延正常并发一上去就报显存不足进程直接崩溃。原因是 max-model-len 设得过大——比如明明业务平均输入才 2000 token你却设了 32768KV cache 的预分配把显存全占了。解决先统计线上请求的 p99 长度再按 p99 加 20% 冗余来设 max-model-len同时配合 vLLM 的 --max-num-seqs 限制并发序列数给模型权重和激活值留出安全余量。记住一个朴素原则并发上不去的系统绝大多数不是引擎不行是显存被未来可能用到的长度吃光了。避坑实录里我最后想多提一句上面五个坑全是看起来合理、用起来出事的典型。它们共同的特点是——没有在改动后立刻做回归验证。如果你只在项目上线那天测一次后面换参数、换模型、调 prompt 全靠感觉那这些坑你迟早会逐一踩一遍。6. 进阶收尾回归评测集把模型改动锁进工程习惯6.1 回归评测集怎么搭两百条覆盖五个维度线上出问题不可怕可怕的是改完系统你根本不知道是变好了还是变坏了。我现在的做法是维护一个固定评测集任何检索参数、prompt、微调权重的改动上线前都要跑一遍跟基线对比。数量不用多两百条足够关键在维度覆盖。题型类型数量覆盖点基本问答60知识库内可直答的事实题验证基础召回多跳问答40需要跨两到三个 chunk 拼接得出结论拒答与边界40库外问题、模糊问题验证该拒就拒格式与引用30JSON 结构正确性、引用编号可溯源工具调用30AI agent 场景下函数名、参数、调用序列多跳问答是最容易暴露切分问题的题目类型如果 chunk 边界切得不对模型怎么都拼不出完整答案拒答与边界则考验 system prompt 里的约束有没有被模型内化。这两类题各放三四十条基本就能把 RAG 管道的七寸捏住。6.2 把评测跑成回归门禁脚本、阈值与记录评测集搭好之后关键是让它成为门禁而不是摆设。我写了一个简单的回归脚本每次改动后跑一遍和基线比对负向超过阈值就拦截上线。import json def run_regression(testset_path: str, endpoint_url: str, baseline: dict): cases json.load(open(testset_path, encodingutf-8)) current, failures {}, [] for case in cases: # call_model 统一走线上推理接口保证评测环境和线上一致 answer call_model(endpoint_url, case[question], case.get(context)) score, detail score_case(case, answer) # 规则评分或 LLM judge current[case[id]] score if score baseline[case[id]] - 0.05: # 下浮超过 5 分记为失败 failures.append(case[id]) if len(failures) 3: # 负向超过 3 条则拦截 raise RuntimeError(f回归未通过{len(failures)} 条低于基线) return current逻辑说明score_case 可以用规则评分是否包含关键词、JSON 能否解析、引用编号是否存在也可以用独立的 judge 模型打分两条路可以混用重点是把每次评测结果单独记成一行 CSV包含日期、改动描述、各维度分数、失败样例。三个月下来你就有一份属于自己项目的改动-效果对照表哪些调整是负收益一目了然不用再靠记忆猜。从那以后我每次动检索参数、换 prompt 或者更新微调权重都会强制跑一遍这个回归集把结果和基线逐条比对负向超过三条就拦下来查原因。这套习惯帮我挡掉的线上事故远比我预期多希望帮到你。本文还有配套的精品资源点击获取