从零开始做AI工程：工程思维、数据管线与文档问答实战

说句实话干了这些年工程我发现一个挺有意思的现象网上关于“AI 工程”的教程多到看不完但真正能把“从零开始”这四个字落到实处的掰着手指头数得过来。这个标题“ai-engineering-from-scratch”之所以能戳中不少人是因为它背后藏着一个非常现实的诉求——不是追着新框架跑而是想搞明白 AI 应用到底是怎么从一块空地变成一栋能住人的房子的。这篇文章我就从自己的实际踩坑经历出发聊聊我理解的“从零开始做 AI 工程”到底意味着什么适合那些刚入门、以及在 AI 应用层做了一阵子但总觉得根基不牢的朋友参考。很多人以为“从零开始”就是把 Transformer 的源码啃一遍或者把反向传播的数学推导手写出来。我不否认这些有用但 AI 工程的核心从来不是“复现一篇论文”而是“稳定地交付一个能用的系统”。这篇文章里我不会给你画一张包治百病的学习路线图而是把我自己实践下来觉得最值钱的几个环节拆开讲清楚工程化思维怎么建立、基础能力到底该补什么、一个完整项目是怎么从数据一路走到部署的以及最容易让人翻车的那些坑。希望能给正准备认真入行或者想体系化梳理一遍的你一点真正能落地的参考。1. AI 工程到底“工程”在哪里1.1 别把“写模型代码”当成 AI 工程的全部我见过不少朋友一开始就把大量时间花在刷模型架构、调参上面觉得把准确率从 90% 提到 91% 就是工程能力的体现。但放到真实的业务场景里模型本身的精度只是整个链条上的一环。数据怎么来、怎么保证质量、特征怎么对齐、线上和线下的分布怎么保持一致、推理延迟能不能压到百毫秒以内、出错了怎么回滚、监控指标怎么设——这些问题才是决定一个 AI 项目能不能活下去的关键。打个比方模型训练就像练驾驶技术但 AI 工程是造一辆能上路的车。练好驾驶只解决了“怎么开”的问题可一辆车要能交付需要发动机、底盘、刹车、车灯、安全气囊、售后服务这套完整的东西才叫“工程”。只盯着模型代码本质上是在反复练同一个科目车还是没法量产。所以我对“AI 工程”的理解是用软件工程的纪律来约束整个 AI 系统的生命周期。数据、实验、模型、部署、监控、迭代每一个环节都要有版本、有记录、有验证出了问题能快速定位。这种思维和“跑通一个 notebook”是完全不同的维度。1.2 工程思维和算法思维最本质的差异算法思维关心的是“能不能”工程思维关心的是“能不能稳定地重复”。同样是训练一个模型算法同学可能会在 Jupyter Notebook 里反复试参数直到在测试集上拿到一个理想结果但工程同学会想这批数据的处理脚本有没有固化随机种子有没有固定训练配置是不是写进了配置文件评估指标是不是和线上口径一致这些东西不解决就算你这次跑出了好结果下次可能就复现不出来了。工程思维还意味着要敢于做减法。很多时候“从零开始”并不是要你从头造所有轮子而是让你清楚每个轮子是怎么转的知道什么时候该用现成的轮子什么时候必须自己造。我在实际项目里最常用的原则是核心业务逻辑必须可控非核心环节尽量用成熟方案。比如对话系统的对话管理逻辑我会自己维护但底层的向量检索直接用开源的向量数据库就好没必要自己写个倒排索引再来个 HNSW。1.3 从零开始学的不是工具是“最小可靠系统”如果只盯着工具看你会发现 AI 领域的工具更新速度快到让人焦虑今天学的框架可能明天就被新的替代了。但工具的底层逻辑往往是相通的。比如不管是 LangChain 还是 LlamaIndex它们解决的核心问题都是怎么把大模型跟外部工具、数据源、业务逻辑串起来。你今天把一个框架理清楚了明天换一个新框架会发现很多东西只是换了个写法底层的设计思想是一样的。所以我建议“从零开始”的人不要一上来就跟着某个框架的教程走而是先想想自己要搭的那个“最小可靠系统”长什么样。一个最简单的 AI 应用至少得有输入解析、模型调用、结果校验、错误处理这几块。你先用自己的代码把这几个模块串一遍哪怕用的是最原始的 HTTP 调用也能理解每一步在干什么。这时候再去学框架你会发现框架只是帮你把重复劳动封装了起来而不是什么黑魔法。2. 地基要打多深才算够2.1 数学和算法基础到底需要学到什么程度很多初学者一提“从零开始”就头大觉得数学不好就没法学 AI。我的看法是如果走工程方向数学够用就行重点是逻辑清晰而不是技巧堆砌。线性代数里面你至少要理解矩阵乘法、向量空间、特征分解这些概念因为神经网络的本质就是矩阵运算。概率统计里面条件概率、贝叶斯思想、常见分布、均值方差这些在评估模型、理解不确定性时经常用到。微积分里面链式法则和梯度下降的逻辑必须吃透因为整个深度学习优化过程就是围绕它转的。但我不建议一上来就啃《深度学习》那本大黑书然后死磕里面的公式推导。更好的做法是边做边补。比如你训练一个分类模型发现 loss 不降了这时候再回头去研究梯度消失、学习率的关系你会记得特别牢。我自己的经验是数学啃不下去的时候就把它放到一个具体问题里去学效率至少高三倍。至于算法基础Transformer 的架构确实值得认真看一遍尤其是注意力机制的实现。但看的时候要带着问题看为什么要有位置编码为什么用多头注意力KV Cache 是怎么让推理加速的这几个问题搞懂了你对大模型推理的认知会和只会调 API 的人完全不一样。2.2 Python 工程能力的三个关键短板绝大多数 AI 初学者 Python 基础都不差但到了工程场景有三个短板特别容易暴露。第一个是调试能力。Notebook 里写代码报错了就往上翻但工程代码是在模块化、异步化、多进程的环境里跑问题不总是那么好定位。我建议系统性学一下 pdb 和 IDE 断点调试学会看调用栈学会在异常发生时先想“输入数据长什么样”而不是盯着报错信息猜。第二个是数据处理能力。AI 项目里最耗时间的往往不是调参而是处理脏数据。你面对的是 CSV、JSON、数据库、日志文件、API 返回的各种乱七八糟的数据格式要能熟练用 pandas、json、pathlib、logging 这些库把数据清洗成模型能吃的结构。很多人写模型代码很快一碰到数据就卡壳这就是工程能力不足的典型表现。第三个是工程规范。代码要有模块意识一个文件只干一件事函数要有明确的输入输出项目里要有 README、requirements.txt、配置文件日志要分级输出方便线上排查问题。这些看起来没什么技术含量但决定了别人能不能接手你的代码也决定了你自己三个月后还能不能看懂自己的代码。2.3 上来就学大模型框架可能是个坑市面上的大模型应用框架比如 LangChain、LlamaIndex、Flowise 这些确实能让你很快搭出个原型。但如果你完全不懂底层原理一旦遇到问题就会非常被动。比如说你可能照着文档写了个 RAG 的检索增强生成结果发现回答质量不行这时候你得自己排查是检索的问题、还是切分的问题、还是提示词的问题。底层原理不清楚你连问题出在哪一环都不知道。我的建议是分两步走。第一步先用最原始的方式实现一遍同样的功能。比如 RAG你就自己用 embedding 模型把文档向量化用向量数据库存起来查询的时候自己拼 prompt再调用大模型生成答案。每一步都是自己控制的出了问题能精准定位。第二步再去用框架重写一遍你会发现框架的抽象层到底帮你干了什么哪些地方可以直接用默认配置哪些地方需要自定义。这个顺序反过来你就会变成框架的“奴隶”。3. 完整的实操从零搭一个文档问答系统3.1 项目选型为什么选文档问答而不是图像分类我建议所有想认真入门 AI 工程的读者都从“文档问答”或者“知识库问答”这类项目入手。原因有几个第一它的效果直观你问一个问题系统能给出带出处的回答这种成就感是图像分类那种“准确率 93%”没法比的。第二它覆盖了 AI 工程全链路的关键环节包括文档加载、格式解析、文本切分、向量化、存储、检索、Prompt 编排、模型调用、结果校验几乎每一步都有值得研究的细节。第三它对算力要求低跑 embedding 模型用自己的电脑就行大模型可以用 API不会因为硬件门槛劝退初学者。我自己第一次正经做 AI 工程项目就是文档问答。当时拿到一批 PDF 格式的内部资料要求做一个问答机器人。过程谈不上顺利但就是这个项目让我把“从零开始”的各个环节真正串起来了后面做别的应用也基本是这套路。3.2 数据管线的设计与实现项目第一步不是写模型代码而是把数据管线搭好。就拿 PDF 文档来说事情远没有“读进来”那么简单PDF 有扫描版、有表格、有分栏、有页眉页脚直接抽文本出来经常是一团乱麻。我当时花了整整两天去调研处理方案最后选了 OCR 识别加后处理的组合光是文本清洗规则就写了几十条。数据管线设计的时候要特别注意两点。第一每一步都要有缓存。文档解析非常耗时如果每次调试都重新解析一遍你会发现时间全耗在等待上了。我当时把解析结果直接序列化成本地文件调试后面的步骤就不用再碰原始 PDF。第二切分策略非常关键。切分不是简单按字符数砍要结合文档的语义结构按标题、段落、列表来切还要保证每个切片的大小适中太长会稀释检索精度太短会丢失上下文。我后来专门写了一个基于 Markdown 标题层级来切分的函数实测效果比固定窗口切分好很多。3.3 检索与生成从向量数据库到 Prompt 编排数据准备好之后下一步是把切分好的文本块用 embedding 模型转成向量存进向量数据库。这里有一个很多人容易忽略的点embedding 模型的选择直接决定检索质量。我当时先用了通用模型后来换了一个针对中文优化的模型检索的相关性有明显提升。所以我的建议是不要盲目跟风而是要拿你自己的数据去做小规模评测选一个适合你数据分布的 embedding 模型。向量检索这块不需要一开始就研究各种距离算法。你把向量存进去之后关键是设置一个合理的相似度阈值。阈值太高检索结果太少生成环节没上下文可用阈值太低检索结果都是无关内容反而会干扰模型回答。我当时的做法是抽样了几十条真实问题人工判断哪些检索结果算“相关”然后反推阈值应该设多少。Prompt 编排同样是一个反复调优的过程。我的经验是 Prompt 里不仅要给大模型相关的上下文片段还要明确告诉它“如果检索内容不能回答用户问题请直接说明”这样可以有效减少模型的胡编乱造。同时要把对话历史合理截断只保留跟当前问题最相关的几轮否则多轮对话时上下文一长既费 token又容易让模型跑偏。3.4 评估不是上线之后才做的事很多人做完检索、生成之后觉得“看起来效果还行”就算完成了。但“看起来还行”和“系统真能稳定工作”之间差着一个东西评估集。我当时做的时候专门整理了大概八十条问答对覆盖了常见的几种问题类型包括直接事实型、对比型、推理型、以及文档里找不到答案的问题。然后写了一个评估脚本每次修改完提示词或者检索参数就跑一遍全部问题记录下回答质量和检索命中率。没有这套评估你根本不知道你的修改到底是在变好还是变坏。很多优化的方向对不对都得靠评估结果说话。这个评估集本身就是很有价值的资产。后面模型升级了或者换了 embedding 模型这张评估集还能继续用来回归测试确保新方案不会让旧场景变差。我发现不少团队把这个环节省掉了结果每次改动都像在赌这是大忌。3.5 部署与可观测性让系统能被“看见”部署这一步我强烈建议从最简单的方案开始。先把服务代码写成 FastAPI 应用暴露一个接收“用户问题、返回答案和出处”的接口再用 Docker 打包。如果你还不熟悉 Docker一定要找一个项目练练手因为它是现代 AI 工程交付的基本载体它可以保证你本地环境和服务器环境一致不会出现“在我机器上能跑”的问题。部署过程中有一件容易被忽视但极其重要的事可观测性。线上系统出问题的时候你必须知道问题出在哪里。日志要包含请求参数、耗时、模型返回内容、错误信息每一条都要带唯一请求 ID。检索出的文档片段最好也记录下来这样用户反馈回答不对时你可以快速看出到底是没有检索到正确内容还是模型理解偏了。没有这套可观测性的设计你排查线上问题就像在黑暗里摸东西效率极低。4. 常见问题与排查技巧实录4.1 检索不到相关内容这类问题太常见了。我遇到过的情况包括文档切太碎导致语义不完整、embedding 模型处理长文本能力有限、向量库里存入了大量无意义的页眉页脚文本、查询问法跟文档表述风格差异太大。排查的时候不要瞎猜我建议按顺序检查先看看原始文档内容解析得对不对再看切分后的文本块是不是保持了语义完整性然后抽样打印出检索结果人工判断到底是哪一步出了问题。有一个我自己试过很好用的技巧把查询问题和检索到的文本块一起打印出来用肉眼看看两者的语义匹配度。如果文本块内容明显相关但向量检索分数很低说明 embedding 模型可能不太理解你这个领域的表达方式这时候就该考虑换模型或者给文本块加一些领域关键词帮助模型对齐语义。4.2 模型总是“一本正经地胡说八道”大模型的幻觉问题没法完全消除但可以从工程上抑制。我总结了几条有效的手段第一在 Prompt 里明确限制模型只能基于给定上下文回答不能使用自己的外部知识第二当检索结果的相关性分数低于阈值时干脆告诉用户“当前知识库没有相关内容”也不要硬让模型生成第三让模型在回答时引用文档片段编号这样用户能看到答案出处也方便你后续的质检。这里有个容易被忽略的小细节检索结果不要一股脑全塞进 Prompt把最相关的三到五段放进去就够了片段多了反而容易引入噪声。我实测过塞进去的片段超过一定数量后模型开始把不相关的信息也揉进回答里答非所问的概率增加。所以精挑细选而不是多多益善。4.3 本地调试正常部署后行为不一致碰到这种问题先检查是不是依赖环境不一致造成的。我踩过的坑包括Docker 容器里缺了中文字体导致 PDF 渲染异常、系统时区不同导致日志时间错乱、不同机器上的 Python 版本差异导致一段正则表达式行为不同。解决办法是尽量把环境和依赖固定下来Docker 文件里明确基础镜像版本Python 依赖用 lock 文件锁版本不去使用裸的 latest 标签。这样至少能保证同一个镜像在不同机器上表现一致。另一个很容易忽略的坑是文件路径。本地开发用的是相对路径部署之后工作目录变了相对路径就找不到文件了。这个问题的排查成本很低但要提前预防代码里所有文件路径都基于项目的根目录动态计算别直接写死在字符串里。4.4 Token 成本失控做 AI 应用token 就是钱。很多初学者没有成本概念把检索到的所有文本块全塞给模型结果一次调用消耗几千 token用户问几句话账户余额就肉眼可见地没了。要控制成本第一限制单次请求的最大输入长度第二对长文档要做好摘要而不是直接全量送进去第三多轮对话时不要让历史无限膨胀及时裁剪或总结早期对话第四不同的模型用途分开简单的分类任务用便宜的小模型复杂生成才用大模型。我记得自己在第一个项目里就吃过瘪上线测试一周成本比预期高出好几倍。后来加了上面这些限制成本立刻降了差不多一半而且回答质量没有明显下降。成本优化不是一个锦上添花的事它是 AI 工程能否长期运营的基础条件。5. 把“从零开始”的路走扎实一些心里话做 AI 工程这几年我最大的感受是这个领域里的“捷径”大多都是弯路。今天有个新框架出来你学一下觉得省事明天有个新模型发布你换一下觉得效果更好。但如果底层的工程能力没有建立起来你会一直处于“跟着别人跑”的状态永远在用别人的方案而不是自己掌控方案。什么是底层的工程能力就是你能把一个模糊的业务问题拆解成数据、模型、评估、部署、监控这些具体的模块并且清楚每个模块的输入输出是什么、可能出现什么问题、出了问题怎么排查。这种能力不是看几篇博客就能建立的必须通过完整项目去反复打磨。我建议你给自己定一个周期比如三个月就做一个真正的端到端项目。不要用现成的模板不要只看教程就从读取原始数据开始一步步实现、调试、部署、评估。遇到不懂的去查资料、去问人、去试错但不要停下来。第一个项目大概率做得很粗糙这很正常。我自己的第一个项目也是文档问答现在看来代码丑得不行但就是那个过程让我把 AI 工程的全链路刻在了脑子里。这个领域变化快但如果你地基打得牢新东西出来你适应得也快。最后分享一个我自己一直保留的习惯每隔一段时间就关掉所有框架和高层封装的 API用一个周末从头实现一个小项目比如写个简单的检索系统或者手动搭一个模型推理服务。这种“回到基本功”的练习能让你在纷繁复杂的技术浪潮里始终清楚地知道自己在做什么。