在技术社区聊了这么久，我越来越觉得“AI工程化”这个词被滥用得太厉害了。很多人把调通一个开源模型、跑通一个notebook、甚至套个LangChain的demo就叫做“搞AI”，但真要放到生产环境里，数据一变效果就崩、并发一高接口就超时、prompt微调一下线上指标直接跳水，连个像样的监控和评估都拿不出来。我自己带过好几个从零起步的AI项目，也踩过无数的坑，今天就想用一篇文章，把ai-engineering-from-scratch这件事真正讲透——从零开始搭建一个可靠的AI系统，每一个环节到底该怎么设计、怎么选型、怎么落地。这篇内容适合所有想把AI能力真正产品化的开发者、技术负责人以及刚刚从学术或传统后端转向AI领域的工程师，它不会教你调参炼丹，而是告诉你如何把模型变成业务里稳定运行的服务。
1. 为什么需要一套“从零开始”的AI工程化框架
1.1 AI工程化到底在解决什么问题
传统软件开发的核心特征是确定性：输入A，经过函数处理，输出B，预期可穷举、测试可覆盖、回滚可预期。但AI系统完全不是这个逻辑，模型输出的概率性、数据分布的动态性、以及效果与成本之间的非线性关系，让整个系统充满了不确定性。
举一个很实际的例子：你训练了一个意图识别模型，离线测试准确率95%，很漂亮。上线后跑了两个月，用户的语言习惯悄悄变了，老版本数据的分布已经不能代表线上真实流量，准确率跌到80%，但没有任何报错、没有Exception、服务一切正常——唯一不对劲的是业务方反馈“最近机器人像变傻了”。这种“没有Bug却在恶化”的状态，就是AI工程最容易忽略却又最致命的坑。
所以AI工程化真正要解决的核心问题有三个：如何管理不确定性，让模型在各种输入下都保持可接受的表现；如何建立反馈闭环，让模型的效果持续被度量、被追踪、被优化；如何控制复杂度与成本，在服务和迭代规模不断膨胀的时候，系统依然可控、可维护。
这些都不是靠单个算法能解决的，而是一整套工程体系的构建。
1.2 从“能跑”到“能上线”：AI工程师的能力模型
很多人问过我，AI工程师和算法工程师、传统后端工程师到底有什么区别。我自己的理解是，算法工程师的核心任务是把模型的效果从“能用”做到“好用”，追求的是指标上限；传统后端工程师追求的是系统的高可用和稳定性，代码确定性极强；而AI工程师恰好站在两者之间——既要理解模型的特性和训练流程，又要像后端工程师一样关心服务、并发、成本、可观测性。
我梳理过一个五层能力模型，基本覆盖了一个AI工程项目的全链路：
| 能力层 | 核心内容 | 常见交付物 |
|---|---|---|
| 数据工程层 | 采集、清洗、标注、版本管理、特征加工 | 高质量数据集、数据管道、数据血缘 |
| 模型技术层 | 选型、微调、量化、蒸馏、Prompt工程 | 可部署的模型产物、评测报告 |
| 推理服务层 | API设计、并发控制、缓存、弹性伸缩 | 高可用的推理服务、性能优化方案 |
| 评估质量层 | 离线评测集构建、线上指标监控、回归测试 | 评测集、质量看板、告警规则 |
| 产品迭代层 | A/B测试、灰度发布、多轮反馈机制 | 迭代计划、效果报告、用户反馈闭环 |
这五层缺一不可。绝大多数团队的问题不是模型选得不好，而是中间两层——推理服务层和评估质量层——几乎是空白的。这也是我写下这篇博文最大的动因：真正从零搭过一遍全流程，你才会对“AI系统是系统工程而非算法堆砌”这句话有切肤的认识。
2. 从零搭建AI系统的技术选型与架构规划
2.1 最小可用技术栈怎么选
先明确一点：所谓“最小可用技术栈”，是在满足业务需求的前提下，能够把端到端链路跑通的最精简组合。选型不是越新越好，更不是名气越大越好，最忌讳的是陷入框架之争。
抛开繁复的组件，一个典型AI应用的技术栈可以规划成下面几个模块。
- 开发语言：Python是主流选择，生态最完善，模型、数据处理、Web框架全都无缝衔接。如果你的团队有很强的Java/Go背景，也可以把Python限定在模型服务层，用Java或Go构建业务侧API，这个后面会详细说。
- 模型获取方式：企业内部落地的时候，最常纠结的就是调用商业API还是开源模型本地部署。我的建议是分阶段考虑：冷启动阶段直接调成熟API（比如OpenAI、国产大模型的商用接口），把产品验证跑通；日活和调用量上来了，再迁移到开源模型（Qwen系列、Llama系列等）本地部署或微调。不要一开始就执着于私有化部署，成本和时间往往会拖垮项目。
- 训练/微调框架：如果有微调需求，PyTorch是事实标准，Hugging Face Transformers是必备工具库。LoRA、QLoRA等高效参数微调方法现阶段已经非常成熟，消费级显卡也能胜任不少场景。
- 数据处理与管道：pandas、Polars处理表格数据，Spark处理海量数据。特征存储和数据版本管理用DVC或LakeFS，这是个容易被忽视但特别重要的组件，后面章节会展开。
- 服务框架：FastAPI基本是当前AI服务的首选，性能足够，自带OpenAPI文档，异步支持和模型推理的IO密集特性非常契合。如果你的模型服务吞吐量极小并且团队很熟悉Flask，那也可以继续用，但长期来看FastAPI的收益更大。
- 向量存储：做RAG或语义检索，需要落地一个向量数据库。Qdrant、Milvus、Chroma、Weaviate各有侧重，单机小规模用Qdrant或Chroma很舒服，大规模分布式场景Milvus用得更多。千万别一上来就抱着Elasticsearch加插件的思维不放，它的向量能力对比专业向量库还是有差距的。
整套技术栈的选型原则我总结成一句话：能用成熟方案就不自研，能单一组件解决就不引多组件，能SQL处理就不用Spark。初期的技术栈越轻，迭代效率越高。
2.2 数据与存储层的搭建要点
技术栈定了以后，第一步实际动手的地方不是模型，而是数据层。我见过太多项目死在这：Demo阶段无所谓，一旦做正式评估，因为数据版本对不上，实验根本无法复现。
数据层搭建第一件事就是把数据当成代码一样管理。要有一套明确的数据版本管理机制，每条数据样本最好都带有版本号、采集时间、标签来源、预处理记录。数据出问题远比代码出问题隐蔽，代码可以靠git回滚，数据覆盖了就是永久性丢失。DVC是目前比较成熟的方案，远端对接S3或者私有对象存储，git记录元数据，团队成员拉取数据就像拉代码一样顺畅。
第二件事是数据清洗和质量把控。质量规则没有统一标准，需要针对业务定义。我做文本类项目的时候，有一套固定的过滤逻辑：空文本、超短文本、高重复度文本、检测为乱码或非目标语言的样本，全部单独存放而不是简单删除。因为后续做模型迭代时，这些“脏数据”往往能反映边界情况，删了就再也找不回来。
存储层的选择要根据数据类型拆开：结构化的业务数据进PostgreSQL或MySQL，文件类数据（文档、图片、音频）进对象存储，向量数据进专门的向量数据库。特别强调元数据设计。向量数据库只负责高效找到相似向量，但你的检索结果往往需要过滤条件（比如只搜某用户、某品类、某时间段），这些过滤字段必须在向量库里同步保存。很多人建Collection的时候只存embedding和原始文本，后面一加过滤需求，整套方案推翻重来，这是我最常看到的重构原因之一。
3. 实战拆解：一个生产级RAG问答服务的诞生
3.1 数据准备：文档切分与Embedding
RAG（检索增强生成）大概是目前AI工程化落地度最高的应用形态。我拿一个企业知识库问答机器人举例，带大家从零到一过一遍核心链路。
先看数据准备。假设你手里有一堆PDF和Word格式的内部制度文档，不能直接一股脑全丢给模型。第一步是转成纯文本，然后清洗格式，去掉页眉页脚、无效换行、表格碎片。这一步看似枯燥，影响却极大——噪声一旦进入Embedding和检索，后面的所有优化都像是给烂地基加固，毫无意义。
接下来是文档切分。切分策略直接决定检索质量，这中间的权衡非常微妙：
- 固定长度切分：实现最简单，效果最稳定，切分长度通常按token数或字符数控制。
- 语义切分：按段落、标题语义切分，和文档结构贴合得很好，但实现复杂度高，PDF解析阶段就需要把章节结构提取出来。
- 递归切分：先按大块切，块超长再逐级向下切，兼顾结构和长度，LangChain里的RecursiveCharacterTextSplitter就是这个思路。
我自己实践下来的经验是，超长文档优先用语义切分，普通文档用固定长度加上重叠窗口。重叠非常重要，它能让相邻切片之间保留上下文连续的信息。具体参数参考：文本切片大小在256到512个token之间比较平衡，重叠50到100个token。如果业务文档经常包含完整表格或独立条目，切片尽量避开切断这类完整语义单元，硬切出来的检索结果往往牛头不对马嘴。
Embedding模型的选择同样关键。中文场景下，BGE系列（比如BGE-large-zh）和基于同义句训练的SimBERT在语义检索任务里都有不错表现。衡量Embedding模型的好坏不能光看榜单，一定要拿你自己业务里的query和文档片段构建一个小测试集，跑一下召回率。不同领域（法律、医疗、泛政企、电商）的文本表达差异很大，一个通用榜单排名靠前的模型，在你自己的数据上可能一塌糊涂。
3.2 检索与生成：参数调优和Prompt工程
检索阶段的核心问题是“怎么把最相关的文档片段捞出来”，这里有两个关键参数：召回数量（top_k）和相似度阈值（score_threshold）。
我踩过的典型坑是top_k设定太贪。有的同事一开始把top_k设为20，觉得多召回一点总没错，结果生成阶段上下文爆满，无关片段混进来，模型反而被带偏。经过反复对比，多数知识库问答场景top_k落在3到5之间是比较舒服的：太少容易漏信息，太多容易引入噪音。
相似度阈值的语义也很重要。它其实是在回答一个问题：“到底相似到什么程度才算相关？”我习惯在开发环境跑一批真实query，把检索结果的分数分布打印出来看一眼，再定阈值。阈值定太高会召回为空，定太低会放任垃圾结果进入上下文。建议先设为0.5左右，然后根据线下评估往高或往低调。而且不同Embedding模型的分数范围差异相当大，千万不要把一个模型的阈值经验直接套到另一个模型上。
生成阶段的Prompt设计也有明显的方法论。一个合格的RAG Prompt至少要让模型明白三件事：第一，它是一名知识库问答助手，必须优先依据给出的资料回答；第二，资料不足时，直接说不知道，不允许编造；第三，回答时尽量使用中文，保持条理和简洁。在实测中，加不加这套约束，对幻觉率的改善肉眼可见。
Prompt里我还固定要求模型做两步思考：先判断给定资料是否与问题相关，相关再提炼回答，不相关则明确告知；只在资料充分时才做总结，绝不自行脑补细节。模型的temperature参数我基本固定设为0.2左右，让回答保持稳定。部分平台服务还支持top_p核采样，二者同时调容易互相干扰，我的经验是只调一个，优先temperature。
3.3 服务化与性能优化
RAG服务的后端结构其实不复杂：一个HTTP接口接收用户问题，内部完成“查询向量库->拼装上下文->调用大模型->返回答案”的流程。但这个看似简单的链路，生产环境下毛病非常多。
第一优先级是缓存。用户的问题往往高度重复，特别是企业内部场景。我在服务层用Redis做了两级缓存：完全相同的query直接返回历史答案；语义相似的query（经过Embedding相似度比对）返回附近答案。加缓存之后，系统整体延迟中位数降了差不多70%，成本更是成倍下降。更大规模的团队还可以考虑引入专门的语义缓存组件，但小项目完全不必，用Voyage等Embedding模型配合Redis足够胜任。
第二是并发和限流。大模型推理是计算密集型操作，GPU资源有限，如果不做限流，突发流量直接打垮服务。我在FastAPI层接入了令牌桶限流，单用户每秒一个请求的粒度已经够平滑。同时用异步任务处理长耗时的生成请求，接口立刻返回任务ID，前端轮询结果。这样避免了HTTP连接长时间占用。
成本估算这块也值得给个参照。以标准开源7B-14B模型为例，单卡A10G（24GB显存）就能部署并支撑一定的并发；如果用商业API，每千token的价格大概在几分到几毛钱级别，超出一定量后成本上涨极快。毛估一个公式帮助决策：单日成本 = 每日调用次数 × 平均上下文token数 × 每token单价。缓存命中率每提高十个百分点，这部分成本基本同步下降。
提示：RAG链路里最容易忽略的是检索结果的措辞和引用格式。把回答里引用的文档ID和来源页传给前端，用户能知道答案是“从哪来的”，这既是产品体验问题，也是幻觉追责的依据。
4. 评估与监控：质量体系的建立
4.1 离线评估怎么搭：golden set与指标
很多团队完全凭感觉迭代AI系统：聊两句觉得“效果还行”就发版。这在业务规模小的场景可能还能糊弄过去，但到后面一定会被各种回归问题折磨——修复了A场景，搞坏了B场景，谁都不知道。
我强烈建议从第一天就把离线评估做起来。做一套离线评估的投入并不大，核心是一份高质量参考答案集（golden set）。从实际业务里收集几百条典型query，组织产品和运营的同学一起标注正确答案，每条尽量覆盖不同类型（高频问答、模糊表达、多轮追问、未知问题），凑足200到500条就能支撑第一版迭代。
离线指标至少要看四个维度，我整理成了一张表：
| 指标 | 计算方式 | 含义 |
|---|---|---|
| 召回准确率 | 检索到的片段中相关片段占比 | 检索阶段是否捞出了正确资料 |
| 回答完整率 | 模型答案包含参考要点的比例 | 生成是否遗漏了关键信息 |
| 幻觉率 | 模型答案出现无依据内容的比例 | 生成是否编造 |
| 端到端满意率 | 整体评分4星及以上的比例 | 综合体验 |
评测集上线后还要定期扩充和维护。每周从线上日志抽取新的代表性query，让标注同学补充答案，把离线评估集做成一个可持续生长的资产。没有这个资产，后面做的所有模型替换、Prompt优化、知识库更新都等于闭眼开车。
4.2 线上监控：数据漂移与异常告警
离线评估管的是“发版前”，线上监控管的是“发版后”。传统软件的监控看错误率、延时、机器负载就够了，AI系统还必须监控“质量指标”。
从实际操作经验看，线上监控至少要看这么几类：
- 调用量维度：成功调用率、超时率、限流次数，这些是基础中的基础。
- 响应质量维度：判断“不知道”“我无法回答”这类兜底回答出现的比例。兜底回答占比突然升高，意味着检索质量大概率出问题了。
- 数据分布维度：把线上输入的query做Embedding后，和训练集的分布做距离对比。分布偏移超过阈值，就要发起模型或知识库更新。
- 反馈维度：点赞、点踩、用户追问率，这些都是最真实的质量标签。
告警阈值该如何设定，我给一个常见起步参考：错误率红线设为1%，5分钟内连续超过则通知；兜底率基线加0.5个百分点就值得关注；单轮问答耗时的P95上限，RAG链路压在3至5秒之间，大模型生成占大头，超过需要盯。阈值一开始设宽一点没关系，关键是数据要先采起来，后面才有优化的依据。
5. 多人协作：把AI项目变成可持续迭代的工程
5.1 实验管理与模型版本化
AI项目一旦进入多人协作阶段，最大的混乱会出现在实验管理上。每个人都在调Prompt、换模型、改参数，最后都觉得自己调的那个版本效果最好，谁也说服不了谁。
破局的办法只有三个字：版本化。Prompt、模型、数据全部进版本管理。Prompt别散落在各个notebook里，统一放到代码仓库的YAML配置文件中，每个Prompt带版本号和变更记录；模型产物用Model Registry管理，每次微调产出的权重文件、量化版本、评测指标全部登记；数据版本用DVC关联到实验记录。这样任何一次效果波动，都能精确定位到是Prompt变化、模型更新还是数据替换导致。
还有一个极易被忽略的细节：实验记录的自动化。除了跑evaluation脚本的版本号，还要保留推理时使用的采样参数、随机种子、甚至推理框架的版本。大模型的生成结果受随机性影响很大，同一个输入在不同环境下跑出来的结果可能完全不一样。没有完整记录，任何指标对比都可能失真。
5.2 测试策略：不只测代码，还要测数据
传统软件工程把自动化测试当作质量底线，AI工程也一样，但测试的对象要扩一层。代码层面的测试至少包含：数据清洗函数的单元测试、接口层的集成测试、以及链路打通后的端到端冒烟测试，保证输入一个query一定返回一个合理JSON。
数据层面的测试同样重要。每次更新知识库或新增数据集，要自动检查：字段缺失率是否上升、文本长度分布是否发生显著偏移、Embedding向量的分布是否和旧数据有大的距离。这三项检查都该挂在CI/CD流水线上，任何一项异常都直接阻断合并或部署。
发版流程我也建议采用灰度策略。因为AI模型的效果波动是无形的，不具备传统代码那种“跑通就是没问题”的确定性。典型流程是：离线评测通过后，先发布到内部或小流量环境，收集真实反馈一两天，确认无异常，再逐步扩大至全量。有条件的话跑A/B测试，对比新旧版本的满意率，再做全量决策。这套流程虽然看起来繁琐，但长期看反而是最省心的。
6. 常见问题与避坑速查
6.1 高频故障排查表
把平时技术群里被问得最多的几类问题整理成速查表，建议收藏：
| 现象 | 可能原因 | 排查思路 |
|---|---|---|
| 回答质量突然下降 | 上游文档或知识库被改动 | 对比数据版本，用旧版本数据复现效果 |
| 检索结果不相关 | Embedding模型被切换或升级 | 跑一批固定query对比新旧模型的召回结果 |
| 接口延迟暴涨 | 缓存失效、并发突增、GPU争抢 | 先查缓存命中率，再查GPU利用率，随后看是否被限流 |
| 反复出现“不知道” | 检索召回为空或相似度阈值过高 | 查线上query的Embedding分数分布，调低阈值 |
| 模型开始胡说八道 | 上下文混入无关片段 | 试着减小top_k，清理资料中的低质内容 |
| 成本一个月翻几倍 | 缓存失效、prompt膨胀、重复调用 | 分析token消耗日志，增加缓存策略 |
| 线下评测好、线上效果差 | 评测集和真实分布不一致 | 扩充评测集，线上数据抽样加入回归集 |
6.2 几个值得长期关注的深坑
按照惯例，分享几个我踩过多次、最希望大家避开的坑。
第一个坑是追求“大而全”的架构。项目早期就引入向量库、编排框架、流处理引擎、任务队列，看起来专业，实际上把问题复杂化了好几倍。团队在排查问题上消耗了大量精力，业务价值却没进展。AI项目架构演进应该是“渐进式重构”：先用最直接的实现打通链路，用真实数据找到瓶颈，再针对性引入新组件。
第二个坑是过度信任RAG，以为有了向量检索就能解决一切问题。虽然RAG能缓解幻觉、解决知识过期问题，但它对query的改写、多轮对话的指代消解、复杂推理的支持都不够。我的体会是，RAG适合“事实性问答”，不适合“复杂推理任务”，遇到这类场景，要么换更强大的模型，要么引入多轮Agent结构，强行靠扩top_k和加索引补救，效果都很有限。
第三个坑是忽略冷启动时的大模型选型。很多团队在项目初期就浪费了大量时间去微调开源小模型，而当时最缺的其实是快速验证业务需求。商业API的高质量和快速接入，能让团队在两周内把端到端链路跑通，获取初步用户反馈。等拥有足够的业务数据、明白真正的模型瓶颈之后，再投入微调也不迟。先验证价值，再优化技术，这个顺序千万别颠倒。
做AI工程这一年多，我最大的体会是：真正难的从来不是某一个模型或某一个算法，而是是否愿意把每一个细节都当工程问题对待——数据有没有版本、Prompt有没有记录、评估有没有覆盖、监控有没有告警。这些听起来琐碎，恰恰决定了系统能不能从“实验室效果”走到“生产环境价值”。我可以大胆地说一句，模型能力的差距正在被开源生态急剧缩小，未来团队与团队的差距，会在工程化水平上完全拉开。希望这篇文章能帮你少走一些弯路，把从零到一的路踩得稳一点。
