AI工程从零入门：技术栈搭建到生产落地的完整指南

我们团队之前内部折腾过好几个 AI 项目，踩了一圈坑之后发现一个很扎心的现实：真正缺的不是会调模型、会写 prompt 的人，而是能把模型稳定跑进业务里的人。所以当朋友问我“AI 工程师应该怎么从零开始学”的时候，我很少直接甩学习路线图，反而更愿意把整套东西拆开来聊清楚——“AI 工程”这四个字，工程才是重点，AI 是放大器。

这篇内容会把 AI 工程从零起步需要搞明白的事情全部过一遍：先讲清楚它和算法岗、数据分析岗到底有什么不同，再给一条可落地的技术栈搭建路线，然后用一个完整的问答系统实战案例串起数据准备、模型选型、检索增强、性能调优这些环节，最后把我们在生产环境里摔过跤的地方整理成一份排查清单。适合刚入行想转 AI 工程方向的同学，也适合已经在做后端或者算法、想往工程侧扩展的开发者。

1. AI 工程到底在解决什么问题

很多人一听到 AI 工程，第一反应是“不就是训练模型嘛”。这是最大的误解。训练模型是算法工程师的核心工作，而 AI 工程关注的是模型之外的一切：数据怎么流转、模型怎么上线、上线之后怎么监控、业务指标怎么对齐。

1.1 算法岗和 AI 工程岗的本质区别

算法岗的核心交付物是一个“尽可能准的模型”，衡量标准是离线指标，比如准确率、召回率、AUC。而 AI 工程岗的核心交付物是一个“稳定可用的系统”，衡量标准是在线指标，比如服务延迟、可用性、吞吐量、单次调用成本。前者追求模型能力上限，后者追求系统整体下限。

用个生活化的类比：算法工程师是研发新菜谱的大厨，AI 工程师是负责把菜品标准化、开连锁店的运营团队。菜谱再好，没有稳定的供应链、标准化的烹饪流程、出餐速度控制和品控体系，就开不了店。AI 工程干的正是“开店”这一整套活儿。

1.2 一个 AI 系统里工程占了多大比重

我见过不少团队立项时把 80% 的精力放在“选哪个模型”上，结果项目后期 80% 的时间都在处理数据问题、接口兼容问题、并发压垮服务的问题、模型答非所问的问题。如果一个 RAG 问答系统最终效果不好，十有八九不是模型不够强，而是文档切分不合理、召回链路没调好、上下文拼接过长导致关键信息被稀释。

一个典型的 AI 应用，从用户提问到最终返回回答，中间要经过：请求接入层、权限校验、意图识别、查询改写、向量检索、重排、上下文组装、大模型推理、结果校验、流式返回、日志埋点。这些环节里真正属于“调用大模型”的只有一小段，剩下的全是工程问题。

1.3 AI 工程能力栈的整体视图

零基础入门的人最容易被各种新名词绕晕，Transformer、RAG、Agent、Fine-tuning、LoRA、LangChain 满天飞。我的建议是先画一张能力地图，把知识分成四层：

这四层不是严格串行的，很多人是边做项目边补。但基础层一定要先过关，不然后面每走一步都会被技术债绊倒。

2. 从零开始的技术栈搭建与选型思路

技术栈选型这件事，网上的推荐很多，但大部分没有解释“为什么选它”。我按自己在实际项目里的体验，把从零起步需要碰的技术挨个说一遍，顺便讲讲选择背后的考虑。

2.1 语言与基础工具：Python 之外的必修课

Python 是 AI 生态的入口，这点没有争议。但只学 Python 远远不够，AI 工程是个系统工程，至少要并行掌握三样东西:Linux 命令行（文件处理、进程管理、日志查看）、Git（代码协作与版本回滚）、以及至少一种数据库的操作能力（PostgreSQL 或 MySQL 都行）。原因是 AI 工程大量时间在和数据打交道，而数据不会老老实实躺在 CSV 文件里等你。

我在实操中最深的一个体会是：写 Python 的人很多，但能用 Python 写出健壮代码的人很少。健壮指的是异常处理、类型标注、日志规范、配置分离这四件事。AI 项目里的模型调用经常会因为网络超时、上下文超限、返回格式异常而失败，如果没有完善的异常捕获和重试机制，一个看起来能跑通的 demo，放到生产环境里整天报错是家常便饭。

2.2 模型访问方式：API 优先还是开源模型优先

刚入门时建议优先使用成熟模型的推理 API，而不是自己去部署开源模型。原因很现实：API 方式能让你直接跳过 GPU 部署、显存优化、推理加速这一大堆工程障碍，把精力集中在理解模型行为、设计应用链路上。等对模型的能力边界有了充分认知，再考虑用开源模型做私有化部署也不迟。

不过这不代表完全不懂部署。做 AI 工程，至少要能回答这几个问题：一个 7B 参数的模型需要多少显存、量化到 4bit 之后要多少显存、并发请求上来之后吞吐量怎么估算。这些知识不一定要通过部署大模型来获得，可以先从概念层面理解，后面专项突破。

2.3 向量数据库与检索组件的选择

RAG 是目前 AI 应用落地的主流范式，而 RAG 的基础设施是向量检索。市面上可选的有专业的向量数据库（Milvus、Qdrant、Weaviate），也有带向量能力的传统数据库（pgvector、Redis Search）。选型时不要盲目追求专业向量库，要看团队已经有什么基础设施。

几个选型判断依据：

• 如果业务数据量在百万级以下，pgvector 完全够用，还能复用现有的 PostgreSQL 运维体系
• 如果需要高并发检索、复杂的混合检索（向量+全文+过滤），专业向量库更合适
• 如果只是做个人项目或 demo，用 Chroma 这类轻量级方案，五分钟就能跑起来

2.4 编排框架：用还是不用

LangChain 这类编排框架刚出来的时候很火，但实际生产项目里很多人最后都选择了“去框架化”。原因很简单：框架封装太厚，出了问题不好排查，而且版本迭代快，接口经常变。我在项目里更倾向于自己写几十行代码完成同样的编排逻辑，清清楚楚，可控性强。

这不是说框架没用。对于快速验证想法、或者做简单的链式调用，框架能节省不少时间。我建议把它们当作学习资料——通过框架源码理解 RAG 的标准链路是怎么设计的，然后在自己的项目里手动实现核心部分，这样出了问题你能看懂调用栈，也能根据自己的场景定制逻辑。

3. 实战案例：从零搭建一个知识库问答系统

学 AI 工程最忌讳只看不练。我准备了一个完整的实战项目——知识库问答系统，从需求拆解到上线评估全部过一遍。这个项目的难度适中，覆盖面广，几乎包含了 AI 工程的每个核心环节。

3.1 需求拆解与整体架构设计

项目目标很朴素：让用户上传一批文档，然后用自然语言向文档提问，系统给出带依据的回答。拆解一下，核心功能无非四个：文档接入、离线索引、在线问答、效果评估。

这个需求对应的系统架构是这样的：

文档上传 → 格式解析 → 文本切分 → 向量化 → 写入向量库 用户提问 → 查询改写 → 向量检索 → 上下文组装 → 模型推理 → 结果输出

架构定下来之后要先想一个问题：哪些环节是耗时的同步操作，哪些必须走异步。文档接入和离线索引涉及大文件解析和大量文本向量化，耗时很长，必须用异步任务处理。而用户问答链路要求低延迟，同步处理，但模型推理本身可能就要几秒，所以还需要配合流式输出提升用户体感。

3.2 数据准备与文本切分的细节

数据准备是整个系统效果的天花板。很多人在这一步偷懒，直接把 PDF 丢给解析库，然后把整段文字塞给模型，结果是检索效果一塌糊涂。文本切分是 RAG 里最容易被低估的环节。

我实践下来比较可靠的切分思路是“结构优先、长度兜底”：先按文档的标题层级切出语义完整的章节，如果章节过长再按段落切，段落还长就按固定窗口切，同时保留相邻窗口的重叠。切分的目标是让每个切片尽量是“一个完整的小主题”，这样向量化之后能代表一个独立语义，检索时才不会出现一个片段里混了好几个问题的答案。

具体操作上，固定窗口切分时有两个参数需要调：窗口大小和重叠长度。窗口大小决定每个切片的文本量，一般 300 到 800 个字符比较合理，太小则语义不完整，太大则检索精度下降。重叠长度用于保留上下文连续性，通常取窗口的 10% 到 20%。这两个参数不是拍脑袋定的，需要通过检索评估来调整。

还要注意格式解析的坑：PDF 里的表格用普通文本提取会变得面目全非，扫描件必须走 OCR，复杂的 Word 文档直接读取文本可能会丢掉标题层级。这些问题在项目初期不会暴露，等到问答效果上不去了回头排查时才会发现是数据解析环节的问题。

3.3 向量化、检索与重排的实现细节

向量化的核心是选 Embedding 模型。市面上有开源的也有商业 API，选择标准是看模型的中文语义理解能力、向量维度、单条文本的最大长度限制。实测下来，中文场景下用针对中文优化的模型会比直接用通用模型效果好不少，向量维度也不是越高越好，高维度带来的是更大的存储开销和更慢的检索速度，最终还是要看检索效果。

检索链路我一个项目里常用的标准流程是：先用向量召回 top 50 个候选切片，再用重排模型精排，取 top 5 喂给大模型。为什么不能直接取 top 5？因为向量检索的召回率和精度之间存在权衡，如果一开始就只取少量结果，很容易把真正相关的切片漏掉。先粗召回再精排，是控制效果和成本的标准做法。

重排环节可以用的方案不少，轻量级的可以用关键词强匹配做加分（比如用户问题里的专有名词在切片中出现就加权），效果更好的用专门的 rerank 模型。我建议在资源有限的情况下，先用“向量召回 + 关键词加权重排”跑通，效果不够再升级到模型重排，这样能根据实际数据判断每一步的价值。

3.4 Prompt 设计与上下文组装的工程化

Prompt 是 AI 工程里最“软”也最不能忽视的部分。我在工程化 Prompt 时遵循几条原则：明确角色和任务边界、限定信息源（只基于给定上下文回答，不自行发挥）、规定不知道时的回复方式、要求输出格式结构化。

上下文组装是个隐蔽的性能杀手。很多模型限制上下文长度，如果把召回的所有切片不加筛选拼进去，很容易超过限制，或者把核心信息挤到中段而被模型忽略。我一般会把最相关的切片放在上下文的前部和尾部，因为模型对这两部分的注意力通常更强。这个说法虽然不完全严谨，但在实践中确实能提升回答质量。

3.5 在线服务的性能考量与流式输出

模型推理在线服务的两大痛点是延迟和成本。延迟方面，流式输出是必须的：模型是边生成边返回 token 的，如果等服务端全部生成完再一次性返回，用户要等好几秒才有反应，体感极差；改成 SSE 流式输出后，用户几百毫秒就能看到第一个字，等待焦虑大幅缓解。

成本方面，核心是控制输入长度。问答系统输入给模型的 prompt 中，绝大部分是检索出来的上下文切片。如果每个问题都要带 5000 个 token 的上下文，并发一旦上来，成本会让人肉疼。我的处理方式是设置检索数量上限和单切片长度上限，并在上下文拼装时做截断，必要时直接丢弃低质量切片。

4. 生产环境中的常见问题与排查技巧

这一部分全是真金白银的踩坑总结。AI 应用 debug 的思路和传统软件完全不同，传统软件的问题是可复现的，改一行代码就能定位；AI 应用的问题往往是概率性的、上下文相关性的，排查起来要费劲得多。下面按问题类别整理一份速查表。

4.1 回答质量类问题

回答质量问题的排查顺序有一个基本原则：先查数据，再查检索，最后才考虑模型和提示词。因为 80% 的质量问题出在“模型没看到该看的内容”上，而不是模型能力不行。

4.2 性能与稳定性类问题

AI 服务线上出问题，大多数集中在几个方面：并发上来后数据库连接池被打满、向量检索出现毛刺延迟、模型推理排队导致超时、异步任务失败后没有重试机制。这些问题的共性是——基础设施设计没有为 AI 负载做准备。

我在一个项目里就吃过亏：向量检索接口在测试环境响应只要 20 毫秒，上线后流量一冲直接涨到 500 毫秒。排查下来是向量库的连接池配置太小，单条查询本身不快，但排队耗时长。这类问题最好的预防方式不是事后优化，而是在压测阶段就模拟线上峰值流量，把每个环节的 P99 延迟测出来。

4.3 成本失控问题的自救方案

大模型 API 按 token 计费，很多项目上线前没算过账，上线后一看账单傻眼。控制成本有几个立竿见影的手段：缓存用户提问和回答（命中的话直接省掉模型调用）、prompt 里尽可能精简上下文、批量任务用低价模型、复杂任务用高配模型（分级路由）。

4.4 可观测性：评估与监控体系的搭建

AI 应用的监控比传统服务多一个维度——除了服务器指标和应用日志，还要监控模型输出的质量。我现在的项目里有一套非常朴素的监控方案：每个问答请求把用户问题、召回切片、模型输出、耗时成本全部落日志，然后抽样做人工评估，每周统计一次覆盖率指标。

评估体系是 AI 工程最容易被忽视的部分。没有评估，就没有办法判断改动是变好还是变坏。我建议建立一个固定的评测集，包含五十到一百条有代表性的问题，每次调整切分参数、换 Embedding 模型、改 prompt，都把评测集跑一遍，用准确率、拒答率、引用正确率三个指标对比。这样项目的每一步改动都变得可量化和可追溯。

5. 实操心得：关于学习节奏和个人项目选择

最后想聊一点偏个人经验的东西。从零开始学 AI 工程，最大的障碍不是技术难，而是领域太宽，容易迷失方向。我见过太多人今天学 LangChain，明天学 Fine-tuning，后天又去研究 Agent，最后每个方向都只会一点，却做不出一个完整的项目。

5.1 先横向跑通，再纵向挖深

我的建议是先选择一个完整的场景，横向把整条链路跑通，再针对薄弱环节纵向深入。所谓的“横向跑通”，就是哪怕效果一般，也要把文档上传、解析、切分、向量化、检索、推理、输出、监控这一整套流程完整地搭起来。“纵向挖深”是在跑通之后，针对切分质量、检索精度、服务性能这些具体点逐个优化。

一个能用的笨系统，比一个完美的架构图值钱得多。

5.2 用真实数据做练习

练习 AI 工程，最好别用网上现成的数据集，而是拿自己真实接触过的资料来搭知识库。用真实数据的好处是会遇到各种脏乱差的问题——格式混乱的 PDF、扫描件、表格错位、专有名词乱写——这些问题才是 AI 工程日常要处理的真实面貌。我在训练自己的过程中，就专门用团队过去一年的会议纪要和项目文档做了个问答系统，做完之后发现对文档结构、术语、上下文的理解能力明显提升。

5.3 保持对基础原理的敬畏

新框架和新技术层出不穷，几天不关注就觉得自己落伍了。但据我观察，很多新工具的本质并没有跳出已有的结构：RAG 依然是召回加生成，Agent 依然是推理加工具调用，多模态依然是编码加解码。框架会过时，但基础原理不会。在追新之前，先把向量检索的原理、大模型推理的基本过程、系统架构的基础知识吃透，这才是 AI 工程真正的地基。

我个人的体会是，AI 工程从零到能独立负责一个项目的周期，因人而异，但路径是清晰的：基础工具打底、API 先行理解模型、完整项目跑通全链路、评估监控补齐工程短板。别贪多，把一个项目做扎实，比浅尝辄止十个方向有用得多。