1. 从零搭建AI工程体系为什么我劝你别一上来就调包ai-engineering-from-scratch这个标题第一次看到的时候我愣了一下。市面上讲AI的文章十篇里有八篇在教你pip install几个库然后调个API就宣称自己搞定了AI工程。但真正在生产环境里趟过坑的人都知道从零构建一套AI工程体系跟调包跑个demo之间隔着的不是几行代码而是一整套思维方式的转变。我自己是从传统后端转过来的头两年做AI项目基本就是能跑就行的状态——模型加载进来接口包一层返回结果就完事。直到有一次线上推理服务在高峰期直接雪崩排查了整整两天才发现是预处理环节的tokenizer在多线程下出现了资源竞争。那次之后我才真正意识到AI工程不是把模型跑起来而是要把数据管道、模型服务、监控告警、版本管理这一整套东西从地基开始搭稳。这篇内容适合几类人看一是刚入行AI方向、还没被生产环境毒打过的工程师二是从其他技术栈转过来、想系统理解AI工程全貌的开发者三是带团队做AI产品、需要判断技术方案合理性的技术负责人。我会把从零搭建AI工程体系的核心环节拆开讲包括整体架构怎么设计、数据管道怎么搭、模型服务怎么做、监控怎么做以及那些只有踩过坑才知道的细节。不堆概念只讲能落地的东西。2. 整体架构设计先想清楚数据怎么流再想模型怎么跑2.1 为什么从零反而是一种优势很多人觉得从零搭建是劣势什么都得自己写。但我的实际经验恰恰相反——从零开始意味着你对每一层都有完全的控制权不会出现这个框架封装太深、出了问题根本查不到的情况。举个具体的例子。用现成的推理框架部署模型表面上很省事但一旦遇到性能瓶颈你面对的是一个黑盒。你不知道请求在框架内部经过了哪些队列、哪些线程池、哪些内存拷贝。而如果你从零搭建哪怕只是用一个简单的HTTP服务包一个模型你至少清楚每一个环节发生了什么优化的时候知道该动哪里。从零搭建的另一个好处是你对技术选型的理解会深刻得多。当你自己实现过一个简易的批处理调度器之后再用vLLM或者TGI这类框架你就能理解它们到底在优化什么参数该怎么调而不是照着文档瞎填。当然从零不等于什么都自己造轮子。我的原则是核心链路的每一层都要能自己实现一遍以理解原理但生产环境该用成熟方案就用成熟方案。理解原理是为了在出问题时能定位用成熟方案是为了效率和稳定性。2.2 分层架构的核心思路一套完整的AI工程体系我习惯把它分成五层来看层级职责常见实现数据层数据采集、清洗、标注、存储对象存储 数据处理管道训练层模型训练、微调、实验管理训练框架 实验追踪工具服务层模型推理、批处理、路由推理服务 负载均衡应用层业务逻辑、Prompt管理、编排业务服务 编排框架观测层日志、指标、追踪、告警监控系统 日志系统这个分层不是拍脑袋定的而是按照数据流向来划分的。数据从底层往上流每一层只关心自己的职责层与层之间通过明确的接口通信。这样做的好处是任何一层出问题影响范围是可控的替换某一层的实现也不会牵一发而动全身。我见过太多项目把数据处理、模型推理、业务逻辑全揉在一个服务里结果就是改一个Prompt模板都要重新部署整个服务数据清洗的逻辑和推理的逻辑耦合在一起测试都没法写。分层不是为了好看是为了让每一部分都能独立演进。2.3 技术选型的取舍逻辑选型这件事我的核心原则是优先选你能hold住的而不是最火的。拿推理服务来说市面上有vLLM、TGI、TensorRT-LLM、Ollama等等。如果你团队里没人懂CUDA底层那TensorRT-LLM的编译优化对你来说就是灾难。vLLM的PagedAttention确实香但如果你连KV Cache是什么都说不清楚出了问题只能干瞪眼。我的建议是分阶段来第一阶段验证期用最简单的方案比如FastAPI包一个模型先把链路跑通理解请求从进入到返回的完整流程。第二阶段优化期引入批处理、缓存、异步处理自己实现一个简易的调度器理解吞吐量和延迟之间的权衡。第三阶段生产期根据实际瓶颈选择成熟框架这时候你已经知道该关注哪些指标了。数据库选型也是同理。向量数据库有Milvus、Qdrant、Weaviate、pgvector等等。如果数据量在百万级别以下pgvector完全够用而且省去了维护一套独立系统的成本。别一上来就上分布式向量数据库运维成本会教你做人。3. 数据管道搭建AI工程里最容易被低估的环节3.1 数据管道的核心职责数据管道在AI工程里的地位怎么强调都不过分。我甚至可以说一个AI项目的成败七成取决于数据管道三成才是模型本身。数据管道要干的事包括数据采集、格式统一、去重、清洗、分块、向量化、存储、更新。每一个环节都有坑。先说格式统一。原始数据可能来自各种来源——网页、PDF、数据库、API返回的JSON。这些数据的结构千差万别你得先统一成一种内部格式。我习惯用JSONL作为中间格式每行一条记录包含id、content、metadata三个字段。简单、通用、好处理。去重这件事比想象中复杂。简单的完全匹配去重只能去掉一模一样的文本但实际数据里大量存在近似重复——比如同一篇文章的不同版本、同一问题的不同表述。这时候就需要用MinHash或者SimHash这类近似去重算法。我的经验是去重阈值设在0.85到0.9之间比较合适太低会误删有用数据太高又去不干净。3.2 分块策略决定检索质量的关键分块chunking是RAG系统里最关键的环节之一但很多人随便按固定长度切一切就完事了。实际上分块策略直接决定了检索质量。我试过几种分块方式各有适用场景固定长度分块按token数或字符数切简单粗暴。适合结构规整的文本比如日志、代码。但容易把一句话切断导致语义不完整。递归分块按段落、句子、短语的层级递归切分尽量保持语义完整。适合文章、文档类内容。LangChain的RecursiveCharacterTextSplitter就是这个思路。语义分块用embedding计算相邻句子的相似度在相似度骤降的地方切分。效果最好但计算成本高。结构化分块按文档本身的结构切比如Markdown按标题切、代码按函数切。适合有明确结构的内容。我的实际做法是混合策略先按文档结构切大块再在大块内部按语义或递归方式切小块。块大小控制在256到512个token之间块与块之间保留10%到20%的重叠避免边界信息丢失。注意分块大小没有万能值。短查询为主的场景块可以小一点256 token需要长上下文理解的场景块要大一点512到1024 token。一定要根据实际检索效果来调。3.3 向量化与索引构建向量化这一步核心是选embedding模型。选型时关注三个维度效果、速度、维度。效果方面可以看MTEB榜单但别迷信榜单。榜单上的高分模型在你的领域数据上不一定好。我的做法是拿一批真实查询和对应文档人工标注相关性然后测几个候选模型的召回率。这个工作量不大但能避免选错模型。速度方面如果数据量大embedding的生成速度会成为瓶颈。可以考虑用GPU加速或者用ONNX Runtime做推理优化。批量处理比逐条处理快得多batch size设到32或64通常能跑满GPU。维度方面维度越高表达能力越强但存储和检索成本也越高。768维和1024维在实际效果上差距不大但存储成本差不少。我的建议是除非有明确的性能需求否则768维是个不错的平衡点。索引构建这块如果数据量不大百万级以下用HNSW索引就够了召回率和速度都不错。数据量再大就得考虑IVF或者量化索引了。索引参数比如HNSW的M和efConstruction需要根据实际数据调没有万能值。3.4 数据更新的处理数据更新是很多人忽略的问题。实际业务里数据是不断变化的——新文档要加进来旧文档要删除已有文档要修改。全量重建索引最简单但数据量大时耗时太长。增量更新是更好的方案但实现起来复杂。我的做法是新文档直接插入索引同时记录插入时间。删除文档用软删除标记为已删除检索时过滤掉。修改文档当作删除插入处理。定期比如每周做一次全量重建清理掉软删除的数据重新平衡索引结构。这样既保证了更新的实时性又避免了索引碎片化。4. 模型服务化从能跑到跑得稳的距离4.1 推理服务的核心挑战把模型跑起来不难难的是在高并发下稳定运行。推理服务面临的核心挑战有三个延迟、吞吐量、资源利用率。延迟和吞吐量是一对矛盾。单条请求处理延迟低但吞吐量上不去批处理吞吐量高但单条延迟会增加。怎么平衡取决于业务场景。如果是实时对话延迟优先如果是离线批量处理吞吐量优先。资源利用率是另一个问题。GPU很贵如果利用率上不去成本就下不来。提高利用率的手段包括动态批处理、请求排队、模型量化、KV Cache复用等等。4.2 动态批处理的实现思路动态批处理是提升吞吐量最有效的手段之一。核心思想是不立即处理每个请求而是等一小段时间比如10毫秒把这段时间内到达的请求攒成一批一起处理。实现上需要一个请求队列和一个调度循环。调度循环不断从队列里取请求攒够一批或者等待超时就调用模型推理。推理完成后把结果分发给对应的请求。这里有个关键参数最大等待时间。设得太短攒不到足够的请求吞吐量上不去设得太长延迟增加用户体验变差。我的经验值是10到50毫秒具体看业务对延迟的容忍度。还有一个参数是最大批大小。批太大显存可能不够批太小吞吐量上不去。这个要根据模型大小和显存容量来算。粗略估算批大小乘以单条请求的显存占用不能超过可用显存的80%。4.3 模型量化与加速模型量化是降低推理成本的重要手段。常见的量化方案有FP16半精度显存减半效果几乎无损。基本是标配。INT88位整数显存再减半效果略有下降。适合对效果要求不那么极致的场景。INT44位整数显存进一步降低效果下降明显。适合显存极度受限的场景。量化的实现方式有PTQ训练后量化和QAT量化感知训练。PTQ简单直接对训练好的模型做量化但效果可能下降较多。QAT在训练时就模拟量化效果更好但需要重新训练。我的建议是优先用FP16如果显存不够再考虑INT8。INT4除非万不得已否则别用效果下降太明显。除了量化还有KV Cache优化、Flash Attention、连续批处理等技术都能显著提升推理效率。这些技术的原理值得单独写一篇这里不展开。4.4 服务的高可用设计生产环境的推理服务高可用是必须的。核心手段包括多副本部署至少两个副本避免单点故障。健康检查定期检查服务状态不健康的副本自动摘除。优雅降级过载时返回简化结果或排队提示而不是直接报错。限流熔断防止突发流量打垮服务。我踩过的一个坑是健康检查只检查了HTTP端口是否响应没检查模型是否真的能推理。结果有一次模型加载失败但HTTP服务正常健康检查通过了流量全打到这个坏副本上用户全部报错。后来改成健康检查里实际跑一次推理才解决了这个问题。5. 监控与可观测性看不见的问题最致命5.1 监控体系的三个支柱AI工程的监控比传统后端监控要复杂。除了常规的CPU、内存、网络指标还要监控模型相关的指标。我把它分成三类系统指标CPU、内存、GPU利用率、显存占用、网络IO。这些是基础用Prometheus Grafana就能搞定。业务指标QPS、延迟分布P50、P95、P99、错误率、超时率。这些反映服务质量。模型指标推理延迟、批大小分布、缓存命中率、输出长度分布。这些反映模型服务的健康度。这三类指标缺一不可。只看系统指标你不知道业务表现如何只看业务指标出了问题不知道是哪里卡的不看模型指标你不知道模型服务本身有没有异常。5.2 日志与追踪日志是排查问题的第一手资料。AI服务的日志要记录请求ID、输入摘要、输出摘要、耗时、模型版本、错误信息。请求ID特别重要它能把一次请求在多个服务间的日志串起来。我习惯用UUID作为请求ID在请求入口生成一路透传下去。追踪tracing比日志更高级能可视化请求的完整调用链。OpenTelemetry是目前的通用方案支持多种语言和框架。接入成本不高但排查复杂问题时价值巨大。注意日志里不要记录完整的用户输入和模型输出涉及隐私。记录摘要或哈希值即可。这个坑我踩过后来花了很大力气做数据清理。5.3 告警策略的设计告警不是越多越好太多告警会导致告警疲劳真正重要的问题反而被忽略。我的告警设计原则是只对可行动的问题告警收到告警后知道该做什么否则不告警。分级告警P0立即处理、P1当天处理、P2本周处理。设置合理的阈值和持续时间避免瞬时抖动触发告警。比如错误率超过5%持续5分钟才告警。常见的告警项包括错误率突增、延迟P99超过阈值、GPU利用率持续过高或过低、显存接近上限、队列积压等等。5.4 常见问题排查速查表现象可能原因排查方向延迟突然升高请求量突增、批处理等待过长、GPU降频看QPS曲线、批大小分布、GPU温度吞吐量上不去批大小太小、GPU利用率低、CPU瓶颈看批大小分布、GPU利用率、CPU使用率显存溢出批太大、KV Cache没释放、内存泄漏看显存曲线、批大小、请求数输出质量下降模型版本变更、Prompt被改、数据漂移对比模型版本、检查Prompt、看输入分布服务无响应死锁、线程池耗尽、依赖服务挂了看线程栈、连接数、依赖服务状态这张表是我自己排查问题时总结的实际遇到问题时按这个顺序查能省不少时间。6. 实操心得与避坑指南6.1 那些只有踩过才知道的坑坑一tokenizer不是线程安全的。很多tokenizer库在多线程下会有资源竞争问题。解决方案是每个线程一个tokenizer实例或者加锁。我当初就是栽在这上面线上服务跑着跑着就卡死。坑二GPU显存碎片化。长时间运行的服务显存会逐渐碎片化最终导致明明有足够显存却分配失败。解决方案是定期重启服务或者用显存池化管理。坑三批处理不等于越快越好。批处理会增加单条请求的延迟。如果业务对延迟敏感批处理窗口要设得很小甚至不用批处理。我见过为了追求吞吐量把批处理窗口设到500毫秒的用户体验极差。坑四模型版本管理混乱。没有版本管理出了问题不知道回滚到哪个版本。解决方案是用模型注册表每次部署记录版本号和对应的配置。坑五忽略冷启动。服务重启后第一批请求会特别慢因为模型要加载、缓存要预热。解决方案是启动时做预热跑几条假请求把缓存填上。6.2 性能优化的优先级性能优化要有优先级别上来就抠细节。我的优先级排序是先解决瓶颈用profiling工具找到真正的瓶颈别凭感觉优化。再优化架构架构层面的优化收益最大比如加缓存、改批处理策略。然后调参数批大小、超时时间、线程数这些参数调优。最后抠代码代码层面的微优化收益最小放在最后。我见过太多人一上来就优化代码结果瓶颈根本不在代码上白费功夫。6.3 团队协作的注意事项AI工程不是一个人的事团队协作有几个点要注意接口先行层与层之间的接口先定义好各自并行开发。配置外置所有配置项外置不同环境用不同配置别硬编码。文档同步架构变更、接口变更及时更新文档别让文档变成摆设。代码评审AI代码也要评审特别是数据处理和模型推理部分容易出隐蔽的bug。6.4 持续迭代的思路AI工程体系不是搭完就完事了要持续迭代。迭代的方向包括效果迭代换更好的模型、优化Prompt、改进检索策略。性能迭代优化推理速度、降低延迟、提升吞吐量。成本迭代量化模型、优化资源调度、降低单位请求成本。稳定性迭代完善监控、优化告警、提升容错能力。迭代要有数据支撑别拍脑袋。每次迭代前定义好指标迭代后对比指标用数据说话。7. 从零搭建的完整流程回顾把整个流程串一遍从零搭建AI工程体系的步骤大致是需求分析明确业务场景、性能要求、成本预算。架构设计分层设计定义层间接口。数据管道搭建采集、清洗、分块、向量化、索引。模型服务搭建推理服务、批处理、缓存、高可用。监控体系搭建指标、日志、追踪、告警。测试与调优功能测试、性能测试、参数调优。上线与迭代灰度发布、监控观察、持续迭代。每一步都有细节都有坑。但只要你理解了每一层在干什么、为什么这么干遇到问题就能定位、能解决。我自己走完这一整套流程花了大概半年时间中间踩了无数坑。但现在回头看这些坑都是值得的。因为踩过之后你对整个系统的理解是调包调不出来的。你知道每个环节的边界在哪里知道什么情况下会出问题知道怎么优化。最后分享一个我个人的习惯每搭完一个环节我都会写一份如果这个环节挂了会怎样的分析。这个习惯帮我提前发现了很多单点故障也让我对系统的整体可靠性有了更清晰的认知。从零搭建AI工程技术是一方面更重要的是这种系统性的思考方式。