AI工程从零到一：RAG知识库问答系统实战指南

先聊个很多人都会问的问题：AI 工程（AI Engineering）到底是不是个“新瓶装旧酒”的概念？我自己的判断是：它不是。早几年我们讲机器学习、深度学习，重心大多放在模型训练——调参、刷榜，谁 AUC 高谁厉害。但到了今天，一个模型能不能真正落地、能不能持续稳定地服务业务，靠的远不只是训练。数据怎么管、特征怎么算、模型怎么部署、上线之后怎么监控、效果变差了怎么捞回来，这些环节加在一起，才是完整闭环。而这个整体能力，就是 AI 工程。几年前没有人给你规划好这条路，网上资料要么偏算法理论，要么偏纯后端，能把这整条链路串起来讲的极少。这个“ai-engineering-from-scratch”要解决的就是这个痛点：从头梳理 AI 工程到底学什么、做什么、怎么一步步做成，适合刚入门想走 AI 工程方向的同学，也适合已经在做后端或算法、想补齐工程能力的人。下文就是我从零到一完整跑通这个体系的实战笔记，纯干货，不绕弯。

1. AI 工程到底是什么，为什么值得从头搭建

1.1 先搞清楚 AI 工程和传统软件工程的区别

很多人第一次听说 AI 工程，下意识会把它理解成“会写 Python 调模型”。如果只是这样，那和算法工程师有什么区别？行业里现在普遍接受的一种定义是：AI 工程是面向 AI 应用的软件工程实践，它把模型当作系统的一个组件，而不是全部。换句话说，AI 工程师的职责是让 AI 能力以稳定、可维护、可扩展的方式嵌入业务。

对比传统软件工程，最核心的区别有两个。第一，传统软件的逻辑是确定性优先——输入 A，输出 B，行为可预期。模型的逻辑是概率性的——同一个 prompt 或者同一批特征，结果可能有波动。所以工程上必须增加一层兜底和校验，比如阈值判断、降级方案、结果合理性检查。第二，传统软件的生命周期里，测试数据和真实数据分布通常一致；模型应用则经常出现“离线效果好、线上效果崩”的窘境。数据分布漂移这个变量，传统软件工程师几乎不需要考虑，但对 AI 工程来说是家常便饭。

所以 AI 工程不是算法工程师的“下位替代”，也不是普通后端的“加个模型接口”。它是一个更综合的位置：既要懂模型的基本工作原理，又得具备软件工程的纪律性，还得有数据敏感度。这也是为什么业界常说“AI 工程师是 transformer 时代的全栈工程师”——不是说你什么都会，而是说你需要具备跨层协调能力。

1.2 从零搭建的必要性：不经历底层，谈何上层

这轮大模型浪潮带来了很多“低门槛”工具，比如封装好的 SDK、托管服务、微调平台。我举双手赞成用工具提效，但我强烈不建议一上来就直接怼高层服务。理由很简单：你不亲手跑一遍训练、评估、部署、监控的完整流程，你根本不知道哪个环节会出问题，出了问题也不知道该看哪里。

举个很典型的例子。有人用了托管的模型 API 做问答应用，线上反馈偶尔出现胡说八道的情况。他第一反应是换个更强的模型，结果换了还是有问题。后来排查才发现，问题出在他处理用户输入时，把一些关键上下文截断了，模型根本没拿到足够信息。这个错如果他自己写过完整的 RAG 链路，一眼就能定位；但如果他只接触过 API 调用，就很容易在“模型不行”的错误方向上反复内耗。

这就是 from scratch 的核心价值：不是为了复古，是为了建立“故障直觉”。你亲手写过数据处理脚本，才知道脏数据长什么样；自己部署过推理服务，才知道延迟瓶颈往往卡在序列化和网络传输上；自己写过评估脚本，才明白人工评测在真实场景里有多不可靠。这些认知是任何工具替代不了的。

2. 核心能力地图：先画清楚要学什么，再动手

2.1 技术栈全景：从底到顶的六个层次

真要系统学习 AI 工程，我建议把它拆成六层来看，每一层都有明确的交付物和验收标准。这样学起来不会迷失方向，因为每一层都可以单独验证。

第一层是编程基础与工程素养，以 Python 为主，必须熟悉面向对象、类型注解、虚拟环境、git 工作流。第二层是数学与机器学习基础，重点不是推导公式，而是要理解损失函数、梯度下降、过拟合、评估指标这些概念背后的直觉。第三层是深度学习框架，PyTorch 为主，要做到能自己写训练循环、自定义数据集、断点续训。第四层是模型应用与微调，包括预训练模型的加载、prompt 工程、指令微调、参数高效微调。第五层是推理与部署，包括模型量化、服务化、容器化、GPU 资源管理。第六层是数据与评估体系，包括数据清洗、标注规范、离线评估、线上监控。

很多人会问：数学到底要学到什么程度？我的建议是，你不需要会推导 transformer 的全部公式，但必须理解以下几个概念：向量与矩阵乘法（做 attention 时能跟上）、概率分布（理解困惑度和采样）、损失函数与梯度（理解训练和过拟合）、以及统计显著性（理解 A/B 实验）。到这一步就够支撑任何工程决策。

2.2 关键思维转变：从“模型优先”到“系统优先”

真正动手做项目之后，我发现初学者最容易卡住的不是技术，而是思维。算法背景的人容易困在“我要把模型效果调到最好”这个单点目标里；后端背景的人容易困在“接口能用就行”的功能交付里。AI 工程要求的是一种系统思维：你需要在效果、成本、延迟、可维护性之间做权衡。

举个真实例子。在公司做智能客服的过程中，我们评估过两个方案：一个是直接调用商用大模型 API，answer 质量高，但每次调用成本高，延迟波动大；另一个是用小模型加本地知识库，answer 质量略低，但成本几乎为零，延迟稳定在 100ms 内。单看模型效果，方案一完胜；但放到真实业务里，客服系统日均调用量几十万次，成本差是数量级的，而且延迟一高用户立刻感知到页面卡顿。最终我们选了方案二，再用 prompt 优化和意图识别兜底，把质量差距压缩到可接受范围。

这就是“系统优先”的典型决策过程。在你的第一个项目里，就要有意识地去记录和权衡这类指标，而不是只盯着 accuracy 或者 BLEU。这个习惯越早建立，后面做真实项目时越不吃亏。

3. 从零到一实操：搭建一个完整的 AI 工程小项目

3.1 项目选型：为什么是“本地知识库问答”

前面讲了一堆理念，下面我们用一个小项目把这些串起来：构建一个基于本地知识库的问答系统。这个项目非常适合入门，原因有三个。第一，它覆盖了完整链路——数据处理、向量化、检索、模型生成、服务封装、评估，一个都不少。第二，它不需要昂贵资源，本地 CPU 也能跑。第三，它非常贴近企业真实需求，你做完之后能直接讲出这个故事的价值。

整体架构分成五块：知识库文档解析、文本切分、向量化与存储、检索、生成回答。对应的技术栈我分别选了：python-docx 和 pypdf 做文档解析，RecursiveCharacterTextSplitter 做文本切分，text2vec-base-chinese 或 bge-small-zh 做向量化，FAISS 做向量存储和检索，最后用 ChatGLM 或 Qwen 等开源模型做生成。

你可能会问，为什么不上 RAG 框架（比如 LangChain、LlamaIndex）？不是不能，而是我先建议你手工过一遍。手写过一遍之后，你才能深刻理解哪些步骤耗时、哪些参数影响大、哪些环节容易出问题。之后再上框架，你才算是在用框架，而不是被框架用。

3.2 步骤一：文档解析与文本切分

第一步是准备几份产品说明文档，比如把公司的某产品手册导出成 PDF 和 Word 两种格式。这时候你立刻会遇到第一个工程问题：PDF 解析出来的文本经常带乱码、多余换行和页码信息。

我的处理流程是这样：先写一个解析函数，从不同文件类型抽取纯文本；再写一个清洗函数，统一做去特殊符号、合并断行、去空白字符；最后打印前 500 字符做目检。注意，这一步千万不能省，因为后续文本切分和向量化的质量，完全取决于这一步。

文本切分是个容易被忽略但极其关键的环节。切太短，语义不完整，检索时噪声很大；切太长，向量表示被稀释，而且超出 embedding 模型的最大输入长度。实践经验是：先用 200 到 500 字作为初始窗口大小，重叠 50 到 100 字。这里的“重叠”是为了保证跨段落的语义不断裂。修改切分参数之后，一定要抽样检查切分结果，我在实际项目里发现过切出来的文本是一半表格一半正文的情况，这种质量是没法检索的。

3.3 步骤二：向量化与检索实现

接下来是向量化。小规模场景直接用 CPU 跑 text2vec 或者 bge 就够。关键点有三个：第一，模型要统一，查询和文档必须用同一个 embedding 模型，否则向量空间不一致；第二，文本要归一化，超长文本截断、空文本过滤；第三，向量要归一化，余弦相似度才能正确计算。

存储我建议先用 FAISS，本地文件存储即可。你只存两样东西：原始文本和向量。入库前还要维护一个 id 映射，方便后续检索返回原文本。

检索逻辑看起来简单——对 query 做向量化，然后查 top-k——但实际有几个坑。第一个坑是混合检索：单靠向量检索，遇到专业术语或缩写时容易召回不准确。实操解法是叠加 BM25 关键词检索，用加权融合的方式综合排序。第二个坑是重排序（rerank）：初筛 top 50，再精排成 top 5，效果提升非常明显。第三个坑是阈值过滤：即使相关性分数不高，系统也会硬返回结果，导致答非所问。正确做法是设定一个最低相似度阈值，低于阈值就返回“知识库中未找到相关信息”。

3.4 步骤三：生成回答与 Prompt 设计

生成阶段的关键是写好系统提示词（system prompt）。这里的经验法则是：先给角色定位，再给任务约束，再给知识上下文，最后给回答格式。以一个实际模板为例，我的提示词是“你是企业智能助理。请只依据提供的知识片段回答用户问题，每句话都需要有依据；如果知识片段中不含所需信息，请直接说明不知道，不要编造。回答控制在 5 条要点以内。知识片段如下：xxx。用户问题：xxx”。

这个模板里有几个值得注意的细节。第一，“每句话都需要有依据”这句话能显著减少幻觉，因为模型被要求对自己生成的内容进行隐含的“溯源”检查。第二，“不要编造”比“如实回答”更直接，行为约束更明确。第三，限制答案长度可以避免模型堆砌冗长文本。第四，把知识片段放在用户问题之前，让注意力机制在推理时更聚焦于知识内容。这些都是低成本高收益的优化，建议直接抄。

3.5 步骤四：把服务封装成可调用接口

一个可交付的系统最终要变成服务。我选择的是 FastAPI，理由很简单：自带 OpenAPI 文档、异步支持、Pydantic 校验、部署方便。你需要构建两个接口：一个负责写入知识（数据入库），一个负责查询问答（query 进来、answer 出去）。

接口设计有几个工程细节。第一个是统一响应结构，比如 {“code”: 0, “data”: {...}}，不要让前端同学猜你的字段。第二个是超时控制，模型推理可能很慢，必须设置合理的请求超时，避免连接堆积。第三个是并发控制，本地小模型在同一时间只能处理少量请求，可以用 Semaphore 限制并发数，收到超过负荷的请求时直接返回 503 提示稍后重试，而不是拖死进程。

我在这步踩过一个很深的坑：第一次部署用的是同步阻塞方式，结果两个人同时提问时，第二个人硬生生等了 30 秒。理论上模型推理本来就慢，但是用异步代理（把模型推理放到一个线程池里）之后，至少能让其他请求先响应起来，体感好了很多。这个优化很小，但是系统稳定性的关键。

4. 评估体系：你做的系统好不好，要用数据说话

4.1 离线评估：别只看准确率，要看细粒度

很多初学者做 RAG 系统，评估的时候只会看“几道题答对了几道”，然后报告一个准确率。这在真实项目里远远不够。我建议建立三套评估维度：检索质量、生成质量、端到端质量。

检索质量用 Recall@k 和 MRR。简单理解就是：正确答案是否出现在检索返回的前 k 条里？排得靠不靠前？这个指标能独立验证你的 embedding 选择和切分策略。

生成质量用 faithfulness 和 answer relevance。Faithfulness 检查生成内容是否有知识库依据，相关性检查回答是否契合问题。这两个指标在生成式模型上比准确率更有意义，因为它们能抓住“答非所问”和“胡编乱造”这两类高频问题。

最实用的做法是：准备 50 条覆盖不同难度的测试问题，逐条手动打分，并记录错误类型。每次改动系统（比如换了切割参数、换了 embedding 模型、改了 prompt），都用同一套测试集重新评估，用得分变化来指导决策。没有这套基线，你后面做的“优化”全是拍脑袋。

4.2 线上监控：让问题在产品化之前暴露

离线评估做得再好，线上也会出现新问题，比如用户问了知识库里没有的东西、用户输入里带错别字、知识库文档更新后没有同步向量库。我建议至少做三层的线上日志监控。

第一层是请求日志，记录 query、检索结果、最终回答、延迟和 token 消耗。第二层是效果评价，定期抽检日志，让业务人员给回答打标签，统计“优质回答率”。第三层是数据漂移监控，统计新 query 和知识库的相似度分布，如果相似度持续降低，说明用户的问法在变，可能需要更新知识库。

在 Python 中做好这两类监控套路已经相对成熟：日志直接输出到 JSON Lines 文件，再定时用脚本聚合统计；指标按天归档，做成最简单的小报表。早期项目不需要复杂监控平台，先把数据和工具链搭好，后面自然知道怎么扩展。

5. 常见问题与排查方向速查

做这个项目时，我一边写代码一边记录了踩坑日志，最终积累了下面这份排查速查表。如果你在做同类项目时遇到问题，可以直接对照定位。

上面这张表是我最常用的排查起点。现实中的问题往往不是单点故障，而是链路多个环节叠加，因此排查时要按“数据 → 检索 → prompt → 生成 → 部署”这条链路逐层过，别一上来就怀疑模型。

6. 下一步怎么往深处走

6.1 从 MVP 到可用的系统，还需要补什么

手工搭建完基础知识库问答之后，下一步我会按优先级补三块工程能力。第一块是自动化评测流水线，把 4.1 节里那套离线评估脚本接入 CI/CD，每次改代码自动跑一遍回归测试，避免“改坏了一处，过了两周才发现”。第二块是知识库管理后台，支持批量上传文档、增量更新向量库、人工修正错误回答并反馈到知识库。第三块是多路召回的进一步升级，比如引入意图识别、FAQ 精确匹配、甚至多跳检索来处理更复杂的问题。

这里插一句个人经验：很多项目死于“过度设计”。如果你只是做一个 Demo，不必一上来就上 Cranium 和庞大的 RAG 框架，先把核心链路跑通，再按真实数据暴露出的问题逐步迭代。框架只是手段，问题才是引领者。

6.2 技能栈的纵向延伸：三条可选路线

走完这个项目，你已经具备了 AI 工程的全链路基本盘。在此基础上可以按职业兴趣选择纵向深入。

第一条是算法纵深路线：继续深入模型训练，学指令微调、强化学习、模型评估方法论、推理优化。适合想走向算法专家路线的同学。第二条是工程纵深路线：学更多性能优化、分布式推理、GPU 调度、自动扩缩容和云原生部署，走向平台工程方向。第三条是数据纵深路线：深耕数据质量、标注体系、数据版本管理、合成数据技术。大模型时代，数据能力越来越值钱，走这条路的人相对少，但缺口很大。

这几条路线并不是互斥的。我的建议是，先用主线打通全链路，再用支线补强一两个方向。AI 工程最忌讳的就是“啥都接触，啥都不精”。

7. 一些实际的经验体会

最后聊几句实在话。我见过很多人学 AI 工程时最大的阻碍，不是资料少，而是“怕”字——怕数学看不懂，怕环境配不好，怕模型跑不起来。我的体会是：大部分 AI 工程问题，你动手去碰它，就已经解决一半了。环境变量报错就一行行看，模型推理慢就做性能分析，数据脏就写好清洗脚本，这些东西没有捷径，但都是确定性的，只要人肯坐在那里逐步磨，总能磨出来。

另一个特别想说的点是：要尽早养成把自己的过程沉淀成文档和脚本的习惯。做这个项目时我记了一本“踩坑手册”，后来它直接变成了团队的新人培训材料。AI 工程里很多隐形知识是跑在空气里的，只存在于某个人的工作经历里，你写下来，它才成为可复用的资产。

现在你手里的这份资料，本质上也是这么来的。我不建议你按部就班每一步都抄一遍，而是带着“如果这里出问题了会怎样”的疑问去过代码。跑通一遍之后，再试着换一个领域的小项目，比如做一个简历匹配助手、做一个内部信息检索机器人。一个项目能让你学会流程，两个不同领域的项目才能让你学会迁移，而迁移能力才是 AI 工程真正值钱的地方。