直接从标题聊起。现在GitHub上挂着大量带-from-scratch后缀的仓库但把AI工程和从零开始放一起我觉得重点不在复现一个Transformer或者手推一遍反向传播而在回答一个更粗糙的问题当我要把一个接大模型API的想法变成长期维护、能上线、出问题能查、迭代不慌的系统我该从哪里下手过去两三年我带团队落地过不少AI项目也看了很多从零起步的同学栽在同一个地方——不是模型不够强而是模型之外的工程底座没搭好。这篇就按我自己从零搭一套AI工程基座的顺序把关键决策、踩过的坑、以及现在回头看哪些地方最值得投入时间一次说透。1. 先别碰模型把AI系统拆成四层再动手我见过太多项目启动会第一件事就是讨论用哪个大模型。这其实是最不该先定的东西。模型是消耗品三个月就换一代今天的最优解下个季度可能就是遗留系统。真正值得花心思的是模型之外的那套骨架。我把一个完整的AI工程系统拆成四层需求层、数据层、智能层、交付层。需求层解决的是边界问题——这个系统到底做什么、不做什么、成功率目标是多少、失败以后兜底路径是什么。智能层反而是最薄的可能就是几个模型API调用或者一个微调后的底座模型加一层路由。数据层和交付层才是工作量的大头前者管数据怎么进、怎么洗、怎么存、怎么变成模型能用的形式后者管逻辑怎么编排、任务怎么异步执行、结果怎么落库、失败怎么重试、效果怎么观测。一个特别反直觉的结论从零开始搭AI工程你百分之八十的精力应该花在数据层和交付层而不是研究模型。原因不复杂——模型的错误率是客观存在且在短时间内不会归零的系统从玩具变成可用产品差距全靠这两层去补。我之所以建议在动手时强制走一遍四层拆解是因为这套流程能逼着你把那些最后一公里的问题提前暴露出来。很多项目死在Demo结束之后就是因为花了三周调提示词却完全没想过线上输入分布变了怎么办、请求量上来并发怎么控、某次调用超时时业务怎么走。这些事在Demo阶段不存在但在工程化第一天就存在。2. 工程地基Python版本、依赖管理、配置中心一个都不能省AI工程的项目骨架和普通后端服务有区别但也有大量共通的地基要打。根据我自己的实操经验从零起步阶段有五样东西值得一次做到位不然后面返工成本远高于一开始安装它们的时间成本。Python环境隔离用uv而不是裸的pip。uv解决了依赖锁和环境切换的问题一条命令能锁死依赖版本避免半年前能跑的代码今天在别人机器上起不来。实测下来uv让环境重建时间从分钟级降到秒级这对CI和多人协作的体验提升是决定性的。uv venv .venv uv pip install -e .[dev] uv lock依赖版本锁AI工程里尤其容易踩的坑是框架版本不兼容。transformers的大版本升级经常改APIopenaiSDK也在频繁变动。我的做法是lock文件必须提交进仓库走发布流程时用严格的版本范围绝不写裸依赖。配置与密钥分离所有API Key、数据库地址、模型Endpoint等信息一律走环境变量或者专门的密钥管理服务Vault、云厂商的Secret Manager都行代码仓库里只留模板和默认值。这不是洁癖——我见过Key被提交进GitHub后几分钟内就被抓去刷盗刷的案例这种事故一出就是成本级的。统一日志格式从第一天起用结构化日志JSON格式每条日志带request_id、module、level、message、timestamp。排查AI系统问题时链路追踪是最有效的工具如果没有请求ID串起一次完整调用你在生产环境看日志基本等于在草堆里找针。配置分层区分开发、测试、生产三套配置核心差异点包括模型版本、并发数、回调地址。别在生产配置里用测试模型的API Key这种低级错误在跑低成本项目时最容易出现。如果你问我这几件事哪个优先级最高我会说是环境隔离和配置分层。其他事情可以边做边补这两个漏了后面阶段随时踩雷。3. 数据层才是AI工程的护城河数据质量检查比调模型划算得多很多从零起步的团队会低估数据层的价值直接接个API就开始调。现实是模型本身的提升空间有限而喂给模型的数据质量直接决定了输出的天花板。我自己的感受是花了三周清洗和结构化数据之后系统的效果改善比花三周调提示词来得明显且稳定得多。数据层里有几件事是每个AI工程都必须处理的。3.1 结构化数据的接入管线如果你的业务本身有结构化数据订单、用户行为、工单记录第一步是把这些数据规范化到统一的Schema并且做字段级别的质量检查。核心检查项包括空值和默认值占比超过阈值比如5%的字段要报警时间字段的格式统一性时区一致性主键唯一性重复记录的处理策略枚举字段的取值分布异常类别是否占比例过大这套检查用dbt、pandas或者纯SQL都能做关键不是用什么工具而是把检查变成自动化流程的一部分。每次数据更新先跑质量检查不过关就不进入模型层。3.2 非结构化数据的解析与向量化RAG检索增强生成是现在AI工程最常用的模式但多数项目在向量化阶段就走错了路。有人在线上推理时实时调embedding接口导致响应延迟成倍增加有人把全文不分块直接丢进向量库检索精度惨不忍睹。我的经验是文档进来先做解析按标题结构、段落、语义边界切分然后对每个文本块做清洗去页眉页脚、去重复模板内容再生成embedding并落库。切块大小需要按业务实测没有通用标准。常见的起点是256到512个token之间重叠率10%到20%但要按你的文档特点调不要无脑套默认值。from langchain_text_splitters import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size400, chunk_overlap60, separators[\n\n, \n, 。, , ] )这里要提醒一个隐蔽的坑embedding模型和检索链路是强耦合的。你对线上文档做向量化用的embedding模型和用来做搜索查询向量化的模型必须一致否则向量空间不一样检索相关度直接崩掉。换embedding模型之前一定要强制全量重建向量库——这是数据层最容易犯、也最致命的一致性错误。3.3 数据漂移你猜不到线上会来什么数据漂移是AI工程躲不开的话题。线上真实输入和训练时或调试时见过的样本分布一定会不一样。关键是提前设计监测机制——不是等漂移造成事故再去查日志而是在数据入口统计长度分布、关键词种类、类别分布等特征设定基线值和告警线。以做客服问答为例你调试时处理的是平均长度50字的问句。上线后某天运营活动引发大量用户提问平均长度飙到200字你的RAG切块策略和检索TopK可能就不再合适。如果没有漂移告警你只会在响应质量投诉涌进来之后才发现而且根本定位不到根因。有了数据漂移监控这类问题在数据入口就被标出来损失大幅缩小。监控报表的展示尽可能简单直接我的习惯是给每个特征画一张趋势图把基线区间标注出来异常分布自然显眼。不要在一开始就追求复杂的机器学习监控模型简单的滑动窗口统计足够撑过很长一段时间。4. 编排层把多个模型和工具串成一条可靠的工作流单一模型调用的系统是最简单的AI工程但那只是起点。真实的业务系统通常涉及多步链路先做意图识别再检索知识库再让大模型总结有时还要调外部工具获取实时数据。这中间就轮到编排层上场。4.1 提示词也要进版本管理我见过大量团队把提示词写死在代码里或者放在不可控的在线Playground里调试。前者改一次提示词要重新发版后者则完全脱离流程、改了什么没人说得清。更好的做法是提示词作为一等公民管理起来提示词模板存成独立文件或用专门的提示词管理工具每个版本有编号和变更记录模板变量与业务字段严格对应避免依赖注入导致的格式混乱生产环境引用的提示词版本必须和评测时用的版本一致否则评测数据集就失去了参考意义跑AI项目之后你会发现提示词既是业务逻辑的一部分又是整个系统里改动最频繁的部分。把它当成可变代码来管能省掉大量系统哪里变了的扯皮。4.2 Agent架构的边界不要神话AgentAI工程圈子里Agent概念现在极热但以我落地项目的经验生产环境能用好的Agent全是边界清晰、工具受限、人类审核的形态。千万不要让Agent自由发挥——给它一个无限工具集和开放式目标等于把系统的正确性交给概率。我推荐的实践是给Agent划定明确的工作范围比如只能调用这三个查询函数、只能输出特定JSON结构、超时必报错。每次工具调用的入参和出参都要记录日志带调用链标识。这样系统出问题时你能准确定位是哪个工具调用导致了异常结果而不是对着整条链路一头雾水。再往上层的编排建议用状态机思想管理流程而不是把所有步骤堆在一个超长程序里。比如客服工单处理流程可以定义为意图识别 - 信息抽取 - 知识库检索 - 答案生成 - 人工复核五步每一步有独立输入输出Schema、独立重试和超时设置。4.3 并发与重试模型API的脆弱性必须设计进系统大模型API从可用性角度讲比传统数据库接口脆得多。超时、限流、返回格式突变、内容安全闸门触发这些都是日常会碰到的情况。工程上要做三件事超时控制、重试策略、熔断降级。超时单次模型调用的超时时间建议根据业务容忍度设置经验值在30到60秒之间比这更长的调用通常意味着该拆步骤而不是延长时间重试对限流类错误429和临时网络错误5xx做指数退避重试并设置最大重试次数一般3次避免无效请求堆积熔断同一个模型Endpoint连续失败率达到阈值时快速失败并切换到备用模型或固定离线兜底答案而不是继续打一个已经明显不健康的服务还会经常遇到输出格式问题——你要求输出JSON模型偶尔给你带一堆markdown标记或者解释性文字。我的做法是在SDK层统一做响应格式的解析和校正用函数限定的结构化输出再加一层格式校验不要期望靠提示词百分百约束住模型行为。5. 评测与可观测性上线前唯一的信心来源AI工程和传统软件工程最大的差异在于正确性的判断标准模糊了。传统逻辑代码你可以明确断言输入输出但AI系统的输出是分布式的没有官方正确答案。因此评测体系必须从第一天就建立并且独立于开发环境运行。5.1 离线评测集宁可小不可乱从零搭评测体系刚开始不需要追求上万的样本但每一条样本都要可靠。评测集样本至少包含输入、期望行为描述、可接受的输出范围、对应的困难等级。比如做一个信息提取系统评测样本要标注这条提取任务有多难简单字段直接出现在原文困难需要跨句推理。这样你后面对系统做改进时能清楚知道改动提升了困难case还是只优化了简单case。评估指标按任务类型选择。分类任务用精确率、召回率、F1生成任务用基于大模型的评分或对比评测更重要的是引入人工抽检机制每周抽检50到100条线上输出由业务人员打分。纯自动化评测量化不了语义质量人工抽检是AI系统效果评估的最后一道防线。评测结果变化要形成趋势报告。每次模型版本或提示词变更跑同一套评测集横向对比。我见过不少团队改进系统后只看了两个例子变好了就欢呼结果一跑评测集发现整体效果反而下降——这就是没有评测集的代价你在靠感觉开车。5.2 生产环境的可观测性花钱买信息增量线上系统必须能回答三个问题这个请求走了哪条链路、每一步花了多长时间、每一步消耗了多少成本。因为涉及真实用户和资金消耗这些问题没有观测工具就无解。链路追踪把每一条请求当作一个trace记录从进来开始到最终返回的每个环节的耗时和token消耗成本核算按模型调用单价、embedding数量、索引查询次数计算单请求成本按业务维度用户类型、功能模块聚合质量信号收集用户侧的行为反馈比如用户是否复制了生成结果、是否点了赞、是否对结果做了修改、是否发起二次追问我目前在生产环境中会建立一个基础的成本看板横轴是时间纵轴是单请求成本单位用厘和美分级别再按功能模块分线。很多项目不看这张表之前完全不知道某类长文档处理请求的成本是普通请求的十倍以上。这些观测信息直接决定了下一步优化方向是换更便宜的模型、调整上下文长度还是改切块策略。5.3 一个极简的评测脚本骨架如果你还在零基础阶段可以先从一个非常简单的脚本开始把评测集跑起来再说。核心逻辑就是调用你的系统、对比预期、累计指标、输出报告。import json from typing import Callable def run_evaluation(dataset_path: str, predict: Callable[[str], str]): with open(dataset_path, r, encodingutf-8) as f: cases json.load(f) results { total: len(cases), success: 0, fail_detail: [] } for case in cases: user_input case[input] expectation case[expectation] try: output predict(user_input) passed evaluate_case(output, expectation) results[success] int(passed) except Exception as exc: results[fail_detail].append({input: user_input, error: str(exc)}) results[accuracy] results[success] / results[total] return results def evaluate_case(output: str, expectation: dict) - bool: if must_contain in expectation: return all(keyword in output for keyword in expectation[must_contain]) return False这个骨架简陋但足以让你先跑通改一个参数看全量指标的循环。在此基础上再扩展分类指标、分数评分、分层报告都不迟。6. 从Demo到上线迭代路线上最容易失控的三种情况最后聊几个从零开始上路后我反复在新项目里和团队确认的事。它们不涉及具体代码但决定了你这条路由多长。第一需求方提的聪明功能往往不是第一优先级。上线第一版时把链路缩短、把交互变简单、把兜底做扎实比实现花哨的Agent行为更重要。系统的用户在早期阶段核心诉求是稳定可靠而不是每次回答都充满惊喜。你迭代的节奏应该是先解决显然不爽的地方再谈增强体验。第二模型供应商的变更应该是低成本的。我从第一天就在模型调用层做了抽象所有模型的接入都走统一的适配接口这样换模型时只改一处配置和适配器逻辑而不需要全链路改动。有的团队在代码里到处直接调某家SDK等到被供应商的价格调整或效果问题逼得想换才发现改动量已经大到改不起。这等于把自己锁死在单一供应商上AI工程的核心柔性就丧失了。第三AI系统的过拟合调试集非常普遍。你为了通过某个坏case调整了策略可能引入了另外两个坏case。所以任何一次改动都必须在全量评测集上跑一遍并且把评测集的版本也纳入版本管理。代码变了、提示词变了、数据变了、评测集变了全部要能对应上同一个时间点否则你没法判断系统提升究竟是改了什么带来的。顺着这条路走下去从零搭一套完整的AI工程基座其实最考验人的不是掌握某个框架而是能在模型快速迭代的噪音里保持系统级的稳定判断。模型随时可以换提示词可以改但数据管线、评测体系和可观测底座是越沉淀越值钱的东西。我在实际项目里体会最深的一个原则是凡是能用工程手段固化下来的判断就不要留给每次调用时的那一次概率。顺着这个原则往下做你的AI工程会慢慢从调通接口变成值得信任。
