在AI领域待久了，你会发现一个有趣的现象：绝大多数人聊的“AI工程”，其实只是“跑模型”或者“调API”。但真正的ai-engineering，是从零开始，把数据、模型、推理、评测、成本、安全这些东西串成一个能稳定运行的系统。本文不聊理论，只讲我从零搭建AI工程体系的完整路线、工具选型逻辑和踩坑经验，给那些想系统上手、而不是只会调库的人做参考。
1. AI工程化和跑通Demo之间，隔着一整条生产线
先说个最扎心的现状：很多人花一周时间就能跑通一个基于LangChain的聊天机器人，但花三个月都搞不定一个能上生产环境的问答系统。原因很明显——Demo和工程之间差的不是模型效果，而是稳定性和可维护性。
我理解的AI工程化，至少包含了下面这几个层面的内容：
- 数据层：数据采集、清洗、解析、分块、Embedding、版本管理
- 模型层：选型、微调、量化、压缩、多模型路由
- 推理层：服务化封装、并发控制、批处理策略、延迟优化
- 应用层：Agent编排、RAG检索链路、工具调用、业务逻辑嵌入
- 平台层：部署、弹性伸缩、可观测性、灰度发布
- 治理层：评测体系、成本治理、安全合规、权限隔离
每一层都不是可选项，而是生产系统的刚需。
为什么很多人觉得AI工程门槛高？我觉得核心原因是：传统软件工程处理的是确定性逻辑，你可以用单测覆盖；而AI系统处理的是概率输出，同一个输入可能产生波动，你没法用传统的测试思维去验证。这就导致了一个很尴尬的现状：很多工程师带着做Web项目的习惯去搞AI系统，结果连“怎么定义这个版本做对了”都不知道。
所以，如果你想从零开始进入AI工程，第一件事不是选模型，而是转变思维模式。你得接受三个事实：输出是不确定的；质量是需要评测体系来保证的；系统的瓶颈往往不在模型本身，而在数据管道和工程基建。
我见过不少团队，把大量精力花在换更强的大模型上，结果瓶颈明明出在数据分块策略不合理、检索召回率太低。这就是典型的“把工程问题误判成模型问题”。这也是为什么我坚持认为，ai-engineering的核心不是模型知识，而是系统工程能力。
1.1 一套成熟的AI系统，时间都花在哪里
如果拿一个典型的AI问答系统来拆，你会发现真正花时间的地方，和你想的可能完全不同：
- 数据准备和清洗占35%左右
- 检索链路优化占25%左右
- 评测体系和回归测试占20%左右
- 模型选型和微调只占15%左右
- 剩下的5%才是花里胡哨的Agent编排
这个比例是我做了多个项目后的真实感受。很多人一上来就研究微调大模型，其实如果没有高质量的数据集和干净的评测方法，微调大概率是白费劲。
1.2 从零搭建的主干逻辑
我通常建议初学者按照下面的主线去搭建自己的第一个AI工程化系统：
- 明确业务场景和输入输出边界
- 搭建数据管道，解决数据从哪来、怎么清洗、怎么存储
- 建立检索或提示词链路，跑通最小可用版本
- 搭评测集和评测管道，量化当前效果
- 服务化部署，加上监控和日志
- 迭代优化，用数据驱动的方式改进每一个环节
这个顺序是反直觉的——大多数新手会从步骤3开始，然后发现效果不行，又回过头来折腾数据。所以我的建议是：从数据开始，哪怕你的场景根本用不到RAG，数据质量也决定了整个系统的天花板。
2. 基础设施与数据闭环：从零开始的第一场硬仗
我现在搭建任何AI项目，第一周永远是基础设施和数据管道的建设，而不是下载模型。原因很简单：如果你的数据管道不稳定，后面所有环节都会跟着抖。
2.1 开发环境和GPU资源怎么规划
在硬件层面，你不需要一上来就搞多卡集群。我建议按照下面的渐进路线来：
- 个人开发调试：单张消费级显卡（24GB显存就够起步），或者直接用云GPU按量付费
- 小规模推理验证：两张A10或一张L40S，跑量化后的开源模型
- 生产环境推理：根据并发量决定，一般是多张A10/A100做推理集群，CPU节点负责数据管道
如果你的业务还在验证期，尽量不要一上来就采购大量GPU硬件。我见过太多团队，花大几十万买了服务器，最后模型一直没定下来，硬件先闲置了。先用云资源跑通业务，再决定是否自建。
在软件环境上，我强烈建议所有组件都用容器化部署。用Docker管理模型服务、向量数据库、应用服务，用Kubernetes做编排。即便你只有一台服务器，容器化也能让你换个模型版本跟切个开关一样简单。
2.2 数据管道：清洗、解析、分块、Embedding
数据管道是整个AI工程里最不起眼但最要命的部分。我把它拆成四个步骤来操作：
第一步，数据收集和解析。根据数据格式选择不同的解析方案。PDF、Word、HTML、Markdown，各种格式的解析逻辑完全不同。这里要注意的是，不要迷信网上说的“用某个库一把梭”，真实场景里的PDF往往带表格、扫描页、复杂排版，你需要的是分层解析策略——先转成结构化中间格式，再做内容提取。
第二步，数据清洗。清除重复内容、广告文本、无关模板、敏感信息。很多数据源之间重叠度很高，如果你不做去重，Embedding之后向量库里会出现大量高度相似的向量，检索的时候会严重干扰排序结果。
第三步，文本分块。分块策略是RAG系统效果好坏的关键之一。我的经验值是：通用文本用800到1200字符的块大小，重叠区间100到200字符，但这个值一定要根据你的业务数据特点去调。代码类数据分块要按函数和类来切，法律文档要按条款来切，表格数据要保留表格结构信息。无脑套固定长度分块，大概率效果会打折扣。
第四步，Embedding生成。Embedding模型的选择直接影响召回效果。这里有一个关键的工程经验：不要把Embedding和关系型数据混在一起搞。向量检索和结构化查询是两种完全不同的能力，你需要一个专门的向量数据库，同时保留结构化字段做预过滤。
2.3 向量库选型的对比与思考
我在不同项目里用过多个向量数据库，给你一个选型参考：
| 对比维度 | Milvus | Qdrant | pgvector | Elasticsearch向量版 |
|---|---|---|---|---|
| 部署复杂度 | 较高，组件多 | 中等，单进程可跑 | 低，复用现有PostgreSQL | 较高，需要维护ES集群 |
| 数据规模 | 十亿级没问题 | 千万级稳定 | 百万级够用 | 亿级可用 |
| 混合检索能力 | RF、稀疏向量、标量过滤都行 | 支持Payload过滤 | 弱，扩展不太方便 | 强，文本检索和向量结合好 |
| 运维成本 | 高 | 中 | 低 | 高 |
| 适合阶段 | 大规模生产 | 中小规模生产 | 早期原型 | 已有ES技术栈的团队 |
个人建议是：原型阶段用pgvector就够了，省掉一个中间件；当数据量到了几百万向量并且对查询延迟有要求时，再迁到Qdrant或Milvus。别一上来就上重武器，部署和运维成本会拖慢你的验证速度。
2.4 为什么说“数据先行”是铁律
我把数据管道放在第一优先级，是因为模型效果的天花板早在数据阶段就已经定死了。
举个真实例子：之前做一个合同问答项目，产品经理坚持用最新的旗舰大模型，觉得效果一定好。结果测试集上一跑，关键条款的召回率一直上不去。排查到最后发现是解析阶段出了问题——合同里的表格被错误的解析逻辑直接拍平成纯文本，导致条款之间的逻辑关系全丢了。模型再强，输入的前置检索就是错的，生成结果自然是胡编。
所以我在团队里定了条规矩：任何效果问题，先排查数据和检索链路，再谈模型问题。这条规矩帮我省掉了无数个无效调参的周末。
3. 模型选型之外，推理与部署层才是真正的分水岭
模型本身已经高度商品化了，说实话，今天你很难通过“换个模型”建立优势。真正让AI系统产生差异的，是推理层的工程质量和部署层的稳定性。
3.1 模型服务化的标准姿势
建议所有模型服务都做成OpenAI兼容接口。这不是为了跟风，而是生态问题——OpenAI的接口协议已经成了事实标准，你用它，就能直接对接市面上大部分框架和工具。
自建推理服务时，我推荐用以下组合：
- vLLM做高性能推理，吞吐量比原生Transformers高出数倍
- SGLang偏重复杂采样策略和结构化输出控制
- Ollama适合本地开发和低并发场景，生产环境慎用
部署时要注意几个细节：第一，模型并行策略。如果单卡放不下，要决定是用张量并行还是流水线并行。第二，KVCache的大小。一个很常见的坑是，长文本场景下KVCache占满显存导致OOM。这就是为什么用vLLM时，我建议显式设置--max-model-len参数，避免动态申请导致显存碎裂和反复OOM。第三，模型预热。部署完不要直接接流量，先跑几轮请求把CUDA Kernel和KVCache预热起来，否则前几个请求延迟会非常难看。
3.2 延迟、吞吐和成本的三方博弈
推理层的本质是用工程手段在延迟、吞吐、成本之间找平衡：
| 优化手段 | 优点 | 代价 | 适用场景 |
|---|---|---|---|
| 量化（INT8/FP8/INT4） | 显存减半，吞吐提升 | 精度轻微下降 | 对效果不敏感的场景 |
| 连续批处理 | 吞吐大幅提升 | 单请求延迟波动 | 高并发场景 |
| 语义缓存 | 避免重复计算 | 需要缓存命中率支撑 | 重复问题多的场景 |
| 小模型路由 | 简单问题用小模型，成本低 | 需要额外路由逻辑 | 混合复杂度的业务 |
| 蒸馏/剪枝 | 推理速度本质提升 | 需要训练资源 | 有算法团队的团队 |
我的实践经验是：不要一上来就追求最大模型。你应该先定一个效果底线，然后在这个底线之上选择成本最低的方案。很多场景下，一个7B到14B的量化模型加一个良好的RAG管道，效果已经足够好，推理成本却只有旗舰模型的几十分之一。
3.3 Agent编排层的工程化思路
Agent已经不是一个新鲜概念了。工程化Agent和写死链路的最大区别在于可控性。
我建议采用以下分层策略：
- 顶层用LangGraph或自研状态机管理多步骤流程，明确每一步的输入输出
- 中间层用工具调用封装外部API，工具描述必须写好，因为大模型就是靠描述来决定调哪个工具
- 底层用Pydantic或其他校验框架，对大模型的输出做结构化校验
这里有一个常见的坑：Agent在复杂任务中会产生非常长的推理链路，一旦中间某一步出错，错误会沿着链路放大。解决思路是给Agent加上“护栏”，比如做递归的自我反思单步校验、设置最大迭代次数、关键步骤上强制人工确认。不要相信大模型的自我修正能力，你要靠工程约束来兜底。
4. 复现一个完整的AI工程样例：从文档到知识库问答系统
理论讲再多都不如来一个完整的实现。我以知识库问答为例子，把从零搭建一个AI系统的完整流程拆给你看。这个场景最适合练手，因为它覆盖了数据管道、向量检索、生成链路、评测体系，是一堂标准的AI工程必修课。
4.1 场景定义与最小技术栈
先说场景：你有几十份内部技术文档，要做一个能回答“文档里写了什么”的问答系统，用户提问之后必须在限定时间内给出带引用出处的回答。
我的最小技术栈是这样：
| 组件 | 推荐方案 | 作用 |
|---|---|---|
| 文档解析 | unstructured + PyMuPDF + Tika | 从PDF/Word/HTML提取文本 |
| 文本分块 | 自定义分块器（按结构切分） | 生成检索单元 |
| Embedding | bge-m3或text-embedding-3-small | 向量化文本 |
| 向量存储 | pgvector起步 | 存储和检索向量 |
| 主模型 | GPT-4o-mini或Qwen2.5-7B | 生成回答 |
| 服务框架 | FastAPI | 封装HTTP接口 |
| 评测工具 | Langfuse + 自建评测集 | 追踪和评估 |
4.2 数据准备阶段的完整步骤
Step 1，数据解析。所有文档先转成统一的Markdown或JSON格式。这一步千万不要跳过，因为后续分块和检索的质量，全部取决于这个中间格式的质量。
Step 2，分块。我推荐按语义结构分块，而不是无脑按字符数切。脚本逻辑大概是：先识别标题层级，然后按标题把文档拆成区块，再把过长的区块按段落二次切分。
Step 3，生成Embedding。分块之后会得到一条条独立记录，每一条包含id、source_doc、chunk_text、embedding、metadata五个字段。metadata很关键，比如文档标题、页码、章节路径，这些元信息在后续做权限过滤和时间过滤时特别有用。
Step 4，写入向量库。批量写入时注意控制批次大小，建议500条一批。向量维度要和Embedding模型匹配，比如bge-m3的输出是1024维，你建的字段就得对应这个维度。
4.3 检索与生成的核心链路
检索链路我建议做成混合结构，而不是只用向量。具体来说做三层：
第一层，召回。向量检索的top200和基于BM25的全文检索结果合并。这样能兼顾语义匹配和关键词精确匹配。第二层，重排。用一个轻量的Cross-Encoder或Rerank模型对200条候选重新打分，取出top5至top10。第三层，精排或过滤。根据业务规则去掉不符合条件的片段，比如过期文档、权限不匹配的记录。
生成层把top片段拼进Prompt模板。我在项目中用过一套比较稳定且不依赖花哨技巧的Prompt结构：
- 系统指令：明确你是知识库助手，只基于给定片段回答
- 引用文档：把候选的文本块按编号列出
- 用户问题：原始提问
- 输出约束：要求附上引用编号，不允许编造不存在的引用
这套结构虽然朴素，但效果稳定，比很多“角色扮演”式的花哨Prompt可靠得多。
4.4 效果不达预期时的排查顺序
如果你做完之后发现回答质量不行，按以下顺序排查：
- 先看检索命中率。单独把检索链路拎出来，看用户问题能不能检索到正确答案所在的文本块。如果召回命不中，生成阶段做得再好也没用。
- 再看上下文污染。有时候检索结果确实正确，但混入了大量无关片段，把模型带偏了。这就要调整重排阈值，或者压缩传入的上下文数量。
- 最后才看生成模型。如果检索没问题，Prompt结构也没问题，效果还是差，再考虑换更强的模型。
我见过太多人卡在第三步，实际上绝大多数问题出在前两步。记住这句话：检索决定上限，生成决定下限。
5. 评测、成本与安全：生产环境的三道夺命关
很多项目Demo时很完美，一上生产就崩。崩的原因通常不在模型，而在评测缺失、成本失控和安全漏洞。这三个问题我一个个说。
5.1 评测体系：没有量化就没有迭代
我在所有项目里坚持的第一件事，就是先建评测集再优化。没有评测集，你根本无法判断改动是好是坏。
评测集怎么建？有几个原则：
- 覆盖所有核心场景。每个业务场景至少20到50条问题
- 包含边界情况和易错点。例如涉及权限的问题、多文档综合回答的问题、需要明确引用来源的问题
- 标注标准答案和关键命中点。评估时不仅仅看生成文本是否相似，还要看关键事实点是否覆盖
评测方式我推荐两层结合：
第一层，自动评估。用LLM-as-a-Judge的方式，用一个更强或中立的模型对回答从“正确性、完整性、忠实度、引用准确性”四个维度打分。注意要设计好评分标准，防止评分模型自己也在瞎编。第二层，人工抽检。每周从线上日志里抽10到20条真实用户问题，人工判断回答质量。
有了这套评测体系，你做的任何优化都能用数据说话，而不是靠感觉说话。
5.2 成本控制：钱是花在看不见的地方
AI项目的成本失控通常来自三个原因：重度用户高频调用、长上下文消耗、重复检索计算。
我常用的成本方案有：
- 上下文压缩。把不重要的历史消息摘要后丢弃，不要每次都把所有历史塞给模型
- 语义缓存。相同或相似问题直接命中缓存，不重复调用模型。这个在大促咨询、客服场景下效果非常显著
- 模型分级。简单问题走小模型，复杂问题才走大模型
- 定时批量推理。对非实时的场景（比如夜间文档增强处理），错峰执行
还有一个实际经验：同一个任务，用结构化输出强制模型输出JSON，往往比让模型输出自由文本然后你再解析JSON要便宜得多，因为你可以用更小的模型完成同样的事。
5.3 安全与合规：工程中最容易漏掉的一环
AI系统的安全问题和普通Web应用有很大区别。主要威胁包括：
- 提示注入：用户通过输入恶意指令，让系统执行危险操作
- 敏感信息泄露：系统回答中带出了不该暴露的内部信息
- 越权访问：通过构造特定问题绕过权限过滤
基础的防护手段我整理如下：
| 威胁类别 | 防护手段 |
|---|---|
| 提示注入 | 输入侧做敏感指令检测，输出侧加系统级“不执行额外指令”约束 |
| 敏感信息泄露 | 检索前做权限过滤，对文档按密级打标 |
| 越权访问 | 把权限判断放在检索层而不是生成层，模型无法绕过 |
| 输出错误 | 强制要求引用来源，无引用不回答 |
这里有一个很重要的认知：安全不能靠大模型自己去判断。你要把安全责任做进架构里，比如权限过滤在检索阶段就完成，而不是让模型“不许告诉别人机密信息”。让模型来判断哪些信息是敏感的，这个方案极不可靠。
6. 从零到一的团队落地节奏：先跑通，再迭代
最后聊聊把一个AI工程从零搭起来的时间表和团队配合问题。这部分心得来自我带项目的经验，不一定适合所有团队，但至少能帮你在起步阶段少走弯路。
6.1 第一个月和第二个月分别做什么
第一个月，不要追求大而全。只做一件事：跑通端到端的最小链路。选一个窄场景，比如“仅回答报销流程相关问题”，把数据、检索、生成、评测全部搭起来。宁可场景窄，也不要链路不全。
第二个月，开始扩展和优化。扩大数据范围，用评测集量化当前效果，找到最大的短板去补。通常是数据清洗或者检索召回的问题。这里要注意：每做一次优化，都要把评测集跑一遍，保证不是“按下葫芦浮起瓢”。
第三个月以后，才考虑生产化：服务部署、监控告警、成本治理、权限体系。
我发现最容易出问题的阶段恰恰是第一个月——大家总想一步到位，结果做了很久连一个能用的闭环都没有。先跑通一个窄场景的价值在于：它能让你尽早暴露真实的技术难点和工程问题，而这些是你看再多文档也学不到的。
6.2 最容易忽略的角色分工
AI工程化的团队，光是会写Python是不够的，至少要包含三类角色：
- 数据工程向的人：负责管道搭建、数据质量、Embedding策略
- 平台工程向的人：负责推理部署、稳定性、监控、成本
- 算法应用向的人：负责Prompt编写、Agent编排、评测集设计
小团队里很多人要身兼多职，但你心里得清楚每件事需要有明确的人来负责。最怕的就是评测没人管，数据质量没人管，出了问题大家一起“调模型”。
6.3 对“从零开始”这件事的最后一点体悟
其实“从零开始做AI工程”最难的，不是某个具体的技术点，而是面对一个充满不确定性的系统时，你还能保持工程化的定力。模型输出不稳定，你就用评测来兜底；数据脏乱差，你就用管道来清洗；成本不可控，你就用路由和缓存来控制。这些手段单独看都不惊艳，但组合起来，就是一套能稳定运行的AI系统。
我一直跟我团队说的一句话是：AI工程不是做一场炫技的魔术，而是修一条漫长的管道。把每一个环节都做到80分，系统的整体效果就会远超那些把某一个环节做到120分、其他环节全部不及格的团队。这也是“从零开始”这条路上，最值得你记住的经验。
