从零构建AI工程：RAG系统数据、评估与部署全流程解析

你搜到ai-engineering-from-scratch这个名字的时候大概率已经下了某个决心不满足于调 API、跑现成 Demo想搞明白 AI 应用从数据到上线的完整链路到底是怎么回事。我当初也是从同样的念头开始的。这个仓库名字直译过来就是“从零开始做 AI 工程”它标注的是一条自学路径但真正有价值的不是里面某段代码而是帮助我们建立一套判断力——知道在什么场景下该做什么决策知道哪一步省不得知道哪个环节出了问题该去查什么。这篇博客我会围绕这条路径拆开讲清楚AI 工程和 AI 研究到底差在哪、为什么必须按数据-模型-评估-部署的顺序来学、以及一个真实的 RAG 项目从零到能跑的完整过程。不管你是刚入门的新手还是已经写过不少 Python 但没碰过 AI 工程化的开发者这篇文章都适合你。1. 拆解 “AI 工程” 到底在学什么——先搞清楚边界才不会自嗨1.1 AI 工程不是“调模型”而是把模型变成可靠服务很多人在入门时最大的认知偏差是把“AI 工程”等同于“训练模型”。实际上工业界一个 AI 系统能稳定跑在生产环境里模型训练只是其中一个环节甚至不是最耗时的环节。真正决定项目成败的是数据质量、特征逻辑、评估体系、部署监控、成本控制这些“不性感”的部分。ai-engineering-from-scratch这类学习路径最核心的价值就是强制我们把视角从“模型怎么调参”拉高到“系统怎么交付”。我举个直观的例子。你想做一个文档问答机器人第一反应可能是“选一个大模型 API 接入就行了”。但实际落地时你要回答的问题是这样的用户传入的 PDF 格式五花八门扫描件怎么办表格怎么解析切分文档时该按什么粒度才不会切断语义检索回来的片段太多会稀释大模型的注意力太少又可能漏答案阈值怎么设用户问的问题超出文档范围时是硬答还是委婉拒绝每次调用 API 花多少钱要不要做缓存这些问题没有一个是“调模型”能解决的但它们恰恰是一个 AI 工程项目的日常工作。所以我把ai-engineering-from-scratch的学习目标定义为建立一套从原始需求到稳定服务的完整方法论。你不需要一开始就会训练大模型但你必须在面对一个新需求时能画出从数据到用户反馈的数据流向图能说出每一环的技术选项和取舍理由。这才是这个项目名称背后真正想传达的东西。1.2 三个被低估的基础能力数据、评估、成本意识在这个学习路径里有三个能力往往被初学者跳过但实际上是后续所有工作的基石。第一个是数据能力包括数据获取、清洗、格式转换、质量检验。很多教程喜欢给你整洁的公开数据集但现实世界的原始数据永远是脏的、不完整的、带偏见的。如果你不具备快速梳理数据的能力后面无论用多强的模型都会被糟糕的输入拖垮。我见过不止一个团队花数周微调模型最后发现效果差是因为标注数据的错误率超过 20%。第二个是评估能力也就是定义“好”的标准。这是国内很多 AI 项目最缺失的一环。大家习惯“看一眼觉得效果不错”但“看一眼”没法量化无法回归无法在系统迭代时判断到底是变好了还是变差了。工程化的做法是先定义评估集再定指标然后每次改动都跑一遍回归。这个过程不复杂但很多人没有养成习惯。from-scratch想培养的正是这种工程直觉。第三个是成本意识包括 API 调用费用、GPU 资源、存储开销、延迟成本。自己做 AI 项目很容易陷入“只要效果够好多贵都行”的状态但做得久了你会发现很多场景真正卡住上线的不是模型效果而是成本。学会估算一次请求的成本、设计缓存策略、选择合适的模型规模在评估时把“效果-成本”放在一起比这是一个 AI 工程师和业余爱好者的分水岭。2. 从零开始的学习路径设计——按周拆解不要一上来啃 Transformer2.1 第 1-3 周把 Python 和数据打交道的能力补齐如果你是零基础直接学 AI 工程我的建议是从 Python 数据处理开始而不是从“什么是 Transformer”开始。原因很简单工程是面向数据的不是面向论文的。前两三周集中做这几件事掌握pandas和polars的基本操作能完成数据的读取、过滤、聚合、合并学会用matplotlib或plotly画分布图培养对数据的直觉练习写正则表达式和简单的文本清洗函数因为后面处理文档时会反复用到同时把git和虚拟环境管理poetry或uv用熟。这些技能很琐碎但在真实项目里每天都要用到。这阶段我建议做一个具体的小任务找一个公开的数据集比如中文维基的转储文件或者某个领域的开源语料把它清洗成结构化的 DataFrame统计每条文本的长度分布画出直方图然后按长度筛选并导出。这个任务看似简单但会让你熟悉“数据从原始形态到可用形态”的完整流程也是后续做检索和训练的前提。有一点要提前说明这阶段不要追求看完所有文档不要陷入“工具恐惧”。用哪个工具不重要重要的是你理解数据处理的几个关键动作——加载loading、清洗cleaning、变换transforming、抽样sampling。每个动作用顺一个工具就够了。2.2 第 4-6 周开始接触模型但先别碰训练第四周开始可以接触模型了。我的建议是先用现成模型跑通几个典型任务彻底理解“输入输出”这个过程再考虑深入原理。你在ai-engineering-from-scratch这类路径里能找到很多对应的 hands-on 练习比如用transformers库加载一个小的中文 BERT 模型做文本分类用sentence-transformers做文本向量化算一算相似句子的余弦距离把一个大模型通过 OpenAI 兼容接口或本地推理框架接进来做一轮简单的 QA。这里的目的不是调参炼模型而是理解模型推理的基本形态输入是什么格式、输出怎么解析、超参数比如temperature、top_p对结果有什么影响、显存占用大概什么样。这阶段最容易犯的错是急着把大模型跑起来。如果你在普通笔记本上尝试加载一个 7B 参数的模型会发现内存瞬间爆掉然后陷入装驱动、调 CUDA 的泥潭。我更推荐的做法是先用 API 或者小尺寸模型1B 以下把流程跑通理解整体交互逻辑。等你真正理解了推理的流程再考虑用 GPU 做本地推理。这样学习曲线平滑很多也更容易保持动力。2.3 第 7-10 周做一个带评估闭环的完整小项目前六周的基础打完之后就该进入实战了。这阶段目标是完成一个闭环项目什么叫闭环就是有不只一次迭代每一次改动都有数据反馈。我推荐的第一个项目是“基于 RAG 的文档问答系统”原因后面会详细讲。这里先说说框架选一个主题领域收集 50-100 篇相关文档做一个检索增强生成系统然后建立一个包含 50-100 个问题的评估集写脚本自动跑测试记录准确率、延迟、成本再做两轮迭代优化。这个项目做完你基本就摸到了 AI 工程的核心流程数据准备、索引构建、检索、生成、评估、优化。更重要的是你会真正体会到“建模只占一小部分”是什么意思。我当初做第一个项目时花在数据清洗和评估集构建上的时间大约是模型调参的三倍但那三倍的时间换来的提升远大于调参。3. 实操复现一个从零开始的 RAG 问答系统的完整过程3.1 需求与架构选型为什么第一个项目选 RAG 而不是微调很多初学者一上来就想微调大模型觉得只有微调才算“真正接触 AI”。我的想法正好相反第一个 AI 项目优先做 RAG检索增强生成。原因有三点其中第一点是成本微调一个像样的大模型需要 GPU 资源和时间对新手来说环境配置就能劝退一半人而 RAG 只需要调用 API 或本地小模型即可跑通把复杂度聚焦在工程环节而不是模型训练上。第二点是迭代速度。RAG 系统的优化对象是数据切分方式、检索策略、Prompt 模板这些可快速调试的环节调整一次只需要几分钟就能看到结果。而微调的迭代周期以小时甚至天为单位对新手建立反馈回路非常不利。第三点是生产环境真实需求。目前在工业界落地最多的 AI 应用形态就是 RAG——私有知识库问答、客服辅助、文档总结都绕不开检索增强。学 RAG 是在为真实工作场景做准备而不是为了完成一个练手项目。架构上我给这个系统选的组件是这样的向量数据库用Chroma本地运行、零配置适合学习Embedding 模型用bge-small-zh-v1.5中文效果好模型小CPU 也能跑生成模型先接 OpenAI 兼容 API快捷、稳定后续再换成本地的Qwen2.5-1.5B-Instruct。这套组合的好处是每个环节都能独立替换方便做对比实验。3.2 数据准备与向量化脏数据会让你后面全白干数据准备是 RAG 项目里最枯燥但最重要的环节。很多人急于把 PDF 扔进向量库结果检索时返回一堆乱码还以为模型有问题。实际上PDF 解析这一步就有大量细节文本型 PDF 还好扫描件需要 OCRPDF 中的表格、页眉页脚会导致切分出来的 chunk 语义破碎双栏排版如果按顺序读取文字会前后颠倒。我在处理真实文档时通常会先用PyMuPDFfitz快速抽取文本观察结构和乱码比例再决定走哪条解析路线。清洗完成后进入切分环节。切分粒度是 RAG 效果好坏的关键杠杆之一。切分太短一个 chunk 可能装不下完整语义切分太长检索返回的冗余信息会干扰生成。我的经验是面向问答场景中文文档按 300-500 个字符切分重叠 50-100 个字符这样既能保留局部语义完整性又能覆盖跨边界的问题。同时要结合文档本身的章节结构做“结构化切分”先定位标题、章节、段落再在自然边界处截断而不是简单地每 500 字一刀切。这个方法虽然是基于常见实践做的补充但在我的多个项目里验证过效果比无脑切分好不少。向量化这一步有一个容易被忽略的细节bge系列模型在计算相似度之前需要给 query 加上特定的指令前缀比如为这个句子生成表示以用于检索相关文章否则检索效果会显著下降。我第一次用的时候没注意这个细节好几个 query 的 recall 率都低得离谱排查了很久才发现是少了这个前缀。这种“小细节决定成败”的情况在 AI 工程里非常典型。3.3 检索与生成的衔接参数、Prompt 与上下文管理向量化完成后系统就具备检索能力了。但“检索回来的内容”和“大模型生成的内容”之间有一层薄薄的胶水往往决定了用户体验。首先是搜索参数的调节检索时不仅要看向量相似度还要考虑多样性。如果一个问题能检索出五个片段但五个片段说的都是同一件事那对生成毫无帮助。实践中我会使用 MMRMaximum Marginal Relevance重排在相关性和多样性之间取平衡或者简单一点检索时fetch_k取 20 个候选再用重排模型比如bge-reranker-base精排后取 top 3-5 送入大模型。这里多一步重排在中文长文档场景下提升非常明显。然后是 Prompt 的写法。这个环节看着简单实际影响很大。一个可复用的模板结构是这样的先给系统设定角色告诉它“你是一个企业知识库助手只能根据提供的文档内容回答用户问题”再把检索到的片段按序号列出来并明确告知“如果文档中找不到答案请直接说明不知道不要编造”最后才是用户的问题。此外我还会把检索到的文档和回答都记录下来方便后面的评估环节做错误分析。上下文管理同样重要。如果你把 20 个检索片段全部塞给大模型模型会被无关信息干扰如果只塞一个片段又可能信息不足。我的做法是按重排分数从高到低依次拼入上下文直到达到模型上下文窗口的 70%——为什么不是 100%因为要给输出预留空间而且过长上下文会显著增加延迟和成本。这个比例是我反复测试后的经验值你可以根据自己的模型和场景调整。3.4 评估闭环没有量化指标的 AI 系统都是自嗨如果说前面的步骤是在做功能那评估就是在做质量保障。我强烈建议在做 RAG 的同时就建立一套评估脚本哪怕很粗糙。具体分三步先准备一个评估集包含 50-100 个问题和对应的标准答案。这些问题最好来自真实场景比如从用户日志里找或者自己模拟用户会问的方式——不要只写简单问题要包含跨章节综合题、表格数据题、否定式提问等难例。然后设定评估方式。最简单的做法叫命中率Recallable Answer Hit跑完系统让人工看输出判断答案是否命中标准答案中的核心信息点。更进阶一点可以做一个“AI 裁判”用 GPT-4 或 Qwen-Max 给模型输出打分。AI 裁判的可靠性没有很多人想的那么高但用来做回归测试、发现明显恶化还是够用的。注意如果用 AI 裁判要固定评分标准、固定输入格式前后保持一致否则分数不可比。评估得到的指标要落成一张趋势表。每次改动数据切分方式、Prompt、检索参数后跑一遍评估脚本记录答案准确率、平均延迟、单次平均成本。这个过程完成后你就真正体会到了“工程化”是什么意思不是在凭感觉优化而是在一个可控的闭环里量化取舍。我第一次跑完评估后发现把temperature从 0.7 降到 0.1准确率提升了 8 个百分点成本反而下降了 5%——这种发现靠“感觉”是永远得不到的。4. 上线前的工程化改造——从“能跑”到“能扛”4.1 服务化封装与并发处理写 API 不是简单地 return项目在本地跑通之后下一步就是把它封装成服务。这一步很多新手容易忽略但在实际项目中服务化才是让系统产生价值的开端。用FastAPI包一层 RESTful API把“文档导入”和“问答请求”拆成两个接口这是最基础的做法。但要注意几个细节接口不能有状态——每次请求都要独立完成检索和生成不能依赖上一次的会话信息文件上传后要异步处理解析和向量化避免用户请求一直卡在等待中大模型的响应格式要统一便于前端解析和后续扩展。并发处理是服务化过程中更实际的问题。当你把系统暴露给多个用户时会撞上很多本地跑代码时遇不到的情况多个用户同时提问导致 API 被限流个别长文档解析耗时三十秒以上把 worker 线程占死日志和上下文记录串到别的用户上。我的建议是引入队列机制比如CeleryRedis把耗时任务异步化对生成模型做连接池管理避免频繁创建和销毁连接同时给每个请求分配一个唯一的 trace id贯穿到日志里排查问题时会非常有用。4.2 可观测性日志、追踪与成本监控一个 AI 应用上线后你最大的敌人是“不知道为什么变差了”。如果没有观测手段你只会收到用户反馈“最近答案质量下降了”然后无从下手。可观测性要做三件事第一个是日志结构化把每次请求的输入输出、检索到了哪些片段、每片段得分、模型返回耗时、token 消耗全部以 JSON 格式写下来。第二个是链路追踪记录从用户请求到检索、重排、生成、返回的每个环节耗时一眼看出瓶颈在哪个阶段。第三个是质量监控定期从线上日志中抽样跑评估集跟踪效果趋势。成本监控也值得一提。AI 应用的运行成本主要是模型请求费。我在每次请求日志里都会记录prompt_tokens和completion_tokens按天汇总后除以请求次数得到平均单次成本。如果某个功能的成本异常升高往往意味着检索返回了过长片段或者发生了循环调用。这种量化监控能让你在做优化时始终心里有数而不是等到月底看账单才发现超支了。5. 这些坑我替你踩过了排查心得与避坑清单5.1 高频问题的定位思路速查做 AI 工程的过程中你一定会遇到不少“结果不对但不知道为什么”的情况。我把碰到的高频问题整理成一张速查表可以帮你在排查时快速定位方向。现象大概率原因排查动作回答完全无关检索没返回正确内容打印检索到的片段检查 embedding 模型和 query 前缀回答内容有但不够准确切分粒度不合适检查 chunk 长度分布调整切分策略回答编造文档没有的内容Prompt 没有明确约束在系统提示词里加“无法回答请说明”检索结果几乎一样MMR 参数或多样性策略失效检查检索参数、重排逻辑延迟突然变高文档切分过大或并发队列堆积看链路追踪中的耗时分布成本大幅上升检索片段过多、上下文超长分析 token 使用情况限制上下文长度如果在排查时发现检索出的片段本身是对的但最终答案不对问题通常出在 Prompt 或者生成模型的参数上不需要动检索链路。这种能精确到环节的定位习惯会大大节省你的时间。5.2 三个容易被忽视的资源陷阱除了问题本身还有一些资源层面的坑几乎每个自己搭过 AI 应用的人都会踩到。第一个是本地模型的显存计算。很多人只看参数量以为 7B 模型加载到 8GB 显存就够了实际上 7B 模型仅权重就接近 14GBFP16再加上推理时的激活值、KV Cache一张 24GB 显卡在长上下文下都可能不够用。建议用量化版GPTQ、AWQ 或 GGUF来降低显存需求或者一开始就选更小的模型。第二个是 Embedding 模型的更新问题。如果你在项目上线后新增了一批文档但没有同步更新索引里的向量这些新文档就永远不会被检索到。这个问题的隐蔽性很强用户只会觉得“明明上传了文档但系统回答不了相关内容”。解决方案是设计一个文档导入的状态跟踪机制确保每个文档都走完“解析-切分-向量化-入库”完整流程并在日志里记录状态。第三个是 API 限流和超时。开发时你一个人用感受不到限流问题上线后多人使用模型 API 会频繁返回 429 或超时。常见做法是在服务层做请求重试、指数退避以及本地缓存——高频相同问题直接返回缓存结果既省钱又能大幅降低限流概率。根据我的经验加入缓存后在重复提问较多的场景下成本能下降 30% 以上。5.3 持续迭代的正确姿势先量化再优化再量化做完整套流程后最想分享的一条心得是持续迭代的节奏比任何单次优化都重要。每当你想到一个优化点子先不要急着改而是先记录当前基准指标再动手改完立刻跑评估回归。如果指标下降果断回滚不要“感觉好像也行”。我见过太多人因为一次“感觉不错”的改动把系统带进不可控的状态最后花了更长时间排查。另一个常用技巧是保留实验记录。每次跑评估时把当时的配置切分参数、检索参数、模板版本、模型版本和结果一起记下来。时间一长你会沉淀出一张“什么配置在什么场景下表现好”的经验表。这套方法论才是ai-engineering-from-scratch真正想传给后来人的东西——不是某一套代码而是一套可复用的工程判断力。最后补充一个我在实际项目中反复用到的习惯一开始就写一个全自动的evaluate.py让它能从数据到评估一键跑完。虽然这个脚本前期写起来费时间但对后续所有迭代来说是最值得的投资。做 AI 工程这事慢就是快把地基打好后面盖楼才不至于塌。