在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 向量库选型的对比与思考我在不同项目里用过多个向量数据库给你一个选型参考对比维度MilvusQdrantpgvectorElasticsearch向量版部署复杂度较高组件多中等单进程可跑低复用现有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提取文本文本分块自定义分块器按结构切分生成检索单元Embeddingbge-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分、其他环节全部不及格的团队。这也是“从零开始”这条路上最值得你记住的经验。