我一直跟身边想转 AI 的人说同一句话别急着上大模型。很多人听到ai-engineering-from-scratch第一反应就是啃论文、刷公式、调参数好像不追到最前沿就做不了事。但真正做过几个项目之后你会明白AI 工程更像是“把软件工程的方法论移植到模型驱动的系统里”。它要处理的不只是模型本身还有数据、接口、并发、评估、监控、成本以及最容易被忽视的“需求到底该怎么翻译成模型任务”。这篇文章不堆名词挑几个我踩过的坑、总结出来的套路从零开始把 AI 工程这件事讲透。如果你还没入行或者刚接手一个 AI 项目但不知道从哪里下手这篇文章能帮你建立一张完整的地图如果你已经做过一两个 demo正准备往生产环境推这里也有不少可供直接参考的工程细节。我尽量用做事的口吻来讲不绕弯子。1. 先别急着写代码AI 工程到底在解决什么问题1.1 从“模型能用”到“系统能用”的最后一公里我见过太多团队把大模型 API 一接跑通了一个对话窗口就认为项目已经完成了 80%。实际上这通常只完成了 2%。模型能用和系统能用中间隔着一条很宽的河。河里漂着的是数据处理流程、服务质量保障、安全性设计、成本控制、迭代机制还有一整套评估体系。ai-engineering的核心就是翻过“模型 demo 很惊艳落地系统很骨感”这座山。举个例子。一个企业内部的文档问答系统demo 阶段只需要上传几份 PDF问几个问题模型答得对老板就点头了。可真要上线你会发现不同的文件格式怎么统一解析表格和扫描件怎么办文档更新后向量库怎么同步用户并发高的时候 GPU 扛不扛得住模型给出错误答案的时候系统能不能用引用来源去兜底这些都是工程问题不是模型问题。从零开始做 AI 工程就是要从一开始就知道“最后 20% 的稳定性决定了项目能不能活过第一个月”。1.2 别把 AI 工程当成算法工程师的专属很多团队有个误区觉得 AI 工程是算法团队的事业务方只要提需求就行。实际上最成功的 AI 项目通常有一个特别“土”的特点需求方深度参与了评估标准的设计。业务人员不懂 embedding、不懂注意力机制但他们知道什么答案能卖给客户、什么答案会砸了招牌。AI 工程本质上是“算法、工程、业务三条线的交集”。我从项目里学到的经验是交付一份 AI 系统技术上再漂亮如果业务方说不出“什么场景必须答、什么场景必须说不知道”这个系统上线之后还是会被吐槽。所以从零开始做 AI 工程第一步不是选模型是把干系人拉在一起把场景边界、接受标准、失败兜底都写下来。这一步可能不性感但价值极高。1.3 从零开始的真正含义建立工程感“from scratch”这个说法很容易让人误解为要从训练一个基座模型开始。我建议普通人别这么干。除非你是大厂研究团队、有上万张卡否则从头预训练一个模型既烧钱又没有必要。更现实的“从零开始”是指从零搭建一套完整可运行的 AI 应用系统。你能独立完成数据准备、模型选型、服务封装、评价闭环甚至能说清楚每个环节为什么这么做。这种能力才是 AI 工程的核心门槛。换句话说ai-engineering不是要你成为模型发明者而是要你成为模型的使用者和集成者。你要懂模型的能力边界但不必会写反向传播你要会调参但更重要的是会设计实验。工程感来自你亲手把一个模块一个模块串起来再看着它被真实用户使用的全过程。2. 把 AI 工程拆成一张可执行的地图2.1 需求锁定先回答“不做 AI 行不行”这是最难但最容易被跳过的环节。很多 AI 项目启动时需求描述都是“做一个智能客服”“做一个 AI 陪练”“自动生成周报”。这些描述听上去很酷但工程化之前必须翻译成可验证的问题。我会用一套问题清单来问需求方这个系统的使用者是谁他们现在的痛苦是什么输入是什么是文本、图像、语音还是混合输出是什么要的是精确的结果还是生成式的建议答错了会带来多大成本可不可以接受“不知道”作为答案数据从哪里来有没有隐私和权限要求如果需求方回答不清楚就先做最小验证。我自己的习惯是先用一周时间准备几十条典型问题拿一个现成模型跑一遍看效果。效果明显不行趁早换个思路效果有戏再谈系统架构。这个验证阶段花的时间往往能省下后面几个月返工的时间。2.2 数据工程如果你觉得模型差八成是数据先出了问题数据工程是 AI 工程里最不性感但最见功力的一块。刚开始做文档问答那阵我花了两周清洗公司里的制度文档。文档里既有 Word、PDF、PPT又有扫描件和表格。真正处理下来才发现很多所谓“模型效果不好”的 case根本是源头数据烂掉了。比如同一个政策在不同文档里说法不一致比如表格被解析成了乱序文本比如扫描件有大量 OCR 错字。这块我的建议是先把数据处理 pipeline搭起来而不是手动修文件。用 Python 写一个自动解析脚本把文档统一转成纯文本或 Markdown再按章节切分保留标题层级。处理完之后要做两件事一是人工抽检 10% 的数据看解析正确率二是建一个“脏数据案例库”把后期发现的解析问题不断回流到脚本里。数据工程不是一次性的它是系统的一部分。2.3 模型选型别一上来就搬最大的模型模型选型是另一个特别容易犯迷糊的点。我记得第一次做问答系统直接用了当时最大的开源模型效果确实好但部署之后发现推理延迟高、显存占用大、并发一上来就卡死。后来换成同系列的小尺寸模型配了量化、加了缓存和检索用户体验反而更稳。模型不是越大越好适合场景、能控制成本、能在延迟阈值内跑完才是好模型。选型之前我会先列几个硬指标首 Token 延迟、生成速度、显存要求、开源协议、中文能力、工具调用能力。然后做一个小规模评测集大概 30~50 条专门覆盖典型场景和边界 case。模型之间差距并没有想象中那么大但部署难度和成本差距可能非常悬殊。选型不是学术评审而是带着约束条件的取舍。2.4 评估体系没有指标的 AI 项目早晚失控AI 系统的效果评估不能靠“感觉变好了”。我见过一个团队每次换模型都说效果提升结果实际上是把提示词里的例子改得更长导致某几个特定题目答得好了其他题反而退步。没有科学的评估集你根本无法判断一次改动到底是正向还是负向。我会在项目第一天就建立两个东西一个评测集包含几百条标准问题每条都标好参考答案和评分标准另一个是评估脚本离线自动跑算准确率、召回率、拒答率、幻觉率。上线之后还要加一层在线指标也就是用户真实反馈和日志分析。离线评测管“模型有没有进步”在线指标管“用户体验有没有变好”两者不能互相替代。3. 实操案例从零搭一个可上线的文档问答系统3.1 场景设定与技术选型讲完理论看一个具体案例。假设要给企业内部搭一个“制度问答机器人”输入是几十份员工手册、报销制度、考勤规则输出要求是“基于文档内容回答问题并附上引用来源”。这是一个很典型的 RAG 场景适合从零开始练手。我的技术栈选择如下模块选择原因应用框架Python FastAPI生态成熟异步支持好写接口快LLMQwen2.5-7B-Instruct中文效果好显存可控适合企业私有化部署Embeddingbge-m3中文和英文检索效果均衡支持 8192 长度向量库PostgreSQL pgvector复用已有数据库能力减少一个运维组件推理引擎vLLM高并发下吞吐更好支持连续批处理任务编排自研 pipeline避免引入过重框架便于调试这些工具不是唯一解但算是一个比较稳妥的组合。如果你只是想快速验证可以先用 FAISS 当向量库后面再迁移到 pgvector。我选 pgvector 的核心原因是运维简单很多公司本来就有一套 PostgreSQL不用再额外维护一个 Milvus 集群。3.2 数据处理与向量化流程数据准备是管道的第一段。我会把文档放进一个./docs目录然后写脚本统一处理大致步骤如下按扩展名分发解析器PDF 用 pypdf 或 pdfplumberWord 用 python-docxPPT 用 python-pptx。清洗噪声去掉页眉页脚、多余空格、图片占位符表格尽量转成 Markdown 表格。按章节切块优先按文档原有标题切如果某个章节太长再按段落切每块控制在 512 个 token 左右设置 50 token 重叠避免语义被切断。向量化用 bge-m3 把每个 chunk 编码成向量同时保留原始文本和文档元信息标题、页码、来源文件名。写入向量库以文档 ID 作为逻辑主键方便后续增量更新。这套流程里最容易出问题的是切块策略。切得太碎检索到的上下文不完整切得太大喂给模型的内容太杂影响注意力。我通常会先用“章节优先、超长再切”的策略跑一遍评测集再根据召回率微调。数据管道没有必要一上来做得很花哨稳定、可复现、可重跑是最重要的。3.3 检索增强生成链路搭建用户提问后系统要做的不只是从向量库“捞几段文本”。我搭的 pipeline 分这样几步对用户问题进行改写比如“报销要几步”这种口语问题先扩展成“报销流程需要哪些步骤”。向量检索用 bge-m3 把问题编码在 pgvector 里用余弦相似度找 Top 20 候选块。重排序用一个轻量级 reranker如 bge-reranker对候选块精排取 Top 5。拼装上下文把排名前几的文本块按原文顺序拼接附上来源标记。调模型生成提示词里明确“只根据给定文档回答如果找不到答案直接说不知道”。这里的关键是重排序。只用向量相似度经常会把“语义相近但无关”的段落捞上来加上 reranker 之后召回质量有明显提升。RAG 的效果瓶颈往往不在生成模型而在检索质量。检索不对模型再强也答不对。提示词模板我一般写成类似这样你是一个企业制度问答助手。请严格根据以下文档片段回答问题。 如果片段中没有相关信息请回答“文档中未找到相关内容”不要自行臆测。 文档片段 {context} 问题{question}这个模板看起来很简单但“不要臆测”这几个字能显著降低幻觉率。3.4 本地部署与性能调优本地部署首先要解决模型推理效率。我用 vLLM 加载 Qwen2.5-7B-Instruct 的 AWQ 量化版本显存占用大概 9~12GB单张 24GB 显卡就能跑得挺稳。如果只有 16GB 显存就再考虑 3B 或 4B 模型。量化不是坏词在工程里AWQ 或 GPTQ 可以把显存降低 30%~50%同时把延迟压下来。接口部分我建议不要直接用流式输出当同步接口用。真实场景里用户等待回答往往超过 3 秒就会焦虑最好用 WebSocket 或 SSE 做流式输出。另外应用层要做超时控制和并发限制。一个很常见的坑是模型推理服务自己扛得住但数据库连接池不够或者 FastAPI 的 worker 数量开太低导致整体并发上不去。部署时必须对每层做压测。性能优化方面有几个立竿见影的手段给重复问题加缓存用问题文本的哈希做 key命中后直接返回。给生成结果加最大 token 限制问答场景根本不需要写长文默认 512 就够。打开 vLLM 的 continuous batching并发请求多了之后吞吐提升非常明显。把 embedding 模型单独部署不要和 LLM 抢显存。3.5 上线后的监控与迭代闭环很多人以为上线就是结束其实上线才是迭代的开始。我在生产环境里最少要监控四类数据接口延迟重点关注 P95、token 消耗、检索命中率、用户反馈。还要把所有问答日志落库包括问题、检索到的文档片段、模型输出、用户是否点了“有帮助”。这堆日志是后续改进模型和提示词的原材料。迭代闭环我习惯按周走。每周抽一批回答质量差的 case分类统计是检索漏了是上下文拼错了还是模型总结错了然后针对占比最高的三类问题做优化。比如发现很多问题都出在“文档更新不及时”上那就要建立增量更新任务发现“表格数据识别错误”那就回到数据解析环节去修。4. 常见问题与排查技巧实录4.1 上线前后一定会遇到的五个坑我在多个项目里反复踩过同样的坑整理成一张速查表希望对你有用。现象根本原因排查思路解决方向模型回答“答非所问”检索到的上下文与问题相关性低查看日志里召回 Top5 的片段是否合理调 chunk 大小换 reranker调整相似度阈值模型一本正经地编造提示词没有限制“不知道”检查 prompt 是否有指令边界在提示词中强制“不知道”声明首次响应特别慢模型未做预热或推理引擎配置不对看首 Token 延迟指标用 vLLM 启动预载打开流式输出并发一高就报错数据库连接池或推理服务队列过小做并发压测看错误日志调连接池加队列必要时扩容副本文档更新后答案不更新向量库没有增量更新机制检查数据入库时间戳建文档变更监听做定时增量同步4.2 排查工具和方法论在 AI 工程里日志比模型本身更重要。我会要求所有核心环节都打印结构化日志包括耗时、token 数、检索结果 ID、分数、模型返回码。这样出了问题不用靠猜直接看日志就能定位。如果日志里看不到关键环节就补日志不要急着调模型。另一个特别有用的工具是“最小复现集”。我每次从线上找一个出问题的问题加入评测集然后离线复现看是检索问题还是生成问题。通常的做法是先把检索结果打印出来人工判断这些片段能不能答出正确结果。如果能问题就在生成阶段如果不能问题就在检索阶段。这种二分定位法比盯着模型瞎调参数有效得多。还有个常见误区一上线就追求准确率 100%。AI 系统不可能做到完美目标应该是“把高频且简单的问题全部解决把低俗边缘问题通过兜底方式提高体验”。给系统设一个“拒答率”指标允许它合理地承认自己不知道反而比硬撑着乱答更让用户信任。4.3 成本控制心得让项目活得更久AI 项目最容易被老板挑战的不是效果而是成本。我见过不少项目一上线就烧了很多钱最后被叫停。其实成本控制可以从一开始就设计进去。第一模型分级。简单问题走小模型复杂问题才走大模型。比如“今天考勤怎么打卡”这种指令式问题用 1.5B 模型就够了只有“跨部门的报销流程差异”这类复杂推理才需要 7B 或更大模型。第二结果缓存非常有效。企业内部问答很多问题其实是重复的缓存命中率能做到 30% 以上。第三控制生成长度。模型输出多一个 token 都是钱强制让答案简洁用户阅读体验还更好。第四批量推理。有些场景不需要实时响应比如夜间离线分析文档可以攒一批请求在低峰期集中处理。5. 我的路线建议带团队和新人的几点大实话5.1 学习顺序用项目倒逼学习很多人列出学习清单先学 Python再学机器学习再学深度学习最后学 Docker。等学完发现技术又过时了。我更推荐“项目倒逼式”学习。直接定一个目标做一个小型 RAG 系统。做完这个你会被迫把 Python、数据解析、向量检索、模型 API、后端接口、容器化都摸一遍。这个过程里你不需要先把数学学完但你会因为遇到具体问题而补数学。同样道理不要一开始就啃完整本 Transformer 论文。先去调用一个现成模型观察它的输入输出理解它“在哪里表现好、在哪里表现差”再回头去看论文里的注意力机制你会更容易看懂。工程能力本来就应该是“先知道怎么做再理解为什么这么做”。这个顺序非常适合 AI 工程。5.2 项目落地的最小工程清单如果在公司内部要推动一个小型 AI 项目我建议你至少保证下面这些“零件”齐全一个可离线运行的模型推理服务私有化部署避免数据出域。一套可重复执行的数据处理脚本。一个带版本管理的评测集和评估指标。一套完整的日志与监控面板。一份包含常见问题的用户手册和系统文档。这五样东西看起来不起眼但它们就是“demo”和“产品”之间的边界。只要少了其中任何一样系统维护者迟早会陷入“每次改动都很危险”的境地。我在实际项目中吃过这样的亏模型升级后没有评估集兜底结果把一个会导致严重后果的错误悄悄上线了。从那以后我宁可先不做新功能也一定要把评测体系补上。5.3 最后说点掏心窝的话AI 工程这个方向表面看是代码和模型内核其实是判断力和责任感。你设计的每一个兜底逻辑、每一处超时设置、每一条“不知道”的限制都会影响真实用户在真实场景里的体验。从零开始做最难的不是学会某个框架而是建立“先把系统想明白再动手写代码”的习惯。如果你现在还没有项目练手我建议就从你自己最熟悉的一个场景开始。哪怕是把你自己电脑里的几百封邮件做成一个“问答小助手”也是一个极好的起点。做完之后你再去看生产环境里的复杂架构心里就有了底。技术会变模型会升级但“先锁需求、再管数据、重评估、可观测、持续迭代”这套做事的框架大概率能陪你走很远。