从零搭建AI工程能力这件事我前前后后折腾过好几轮。最早的时候我也走过弯路觉得把模型跑起来、能推理出结果就算入门了后来真正在项目里落地才发现从能跑通到能上线、能维护、能迭代之间隔着一整条工程化的鸿沟。ai-engineering-from-scratch这个方向之所以值得单独拿出来聊是因为它解决的不是模型怎么调的问题而是一套AI系统怎么从零搭起来、并且长期稳定运转的问题。它适合两类人一类是有算法基础但没做过完整工程落地的同学另一类是有后端或数据工程背景、想切入AI系统建设的老手。接下来我会把这条路径拆成几个真实的工程环节讲清楚每一步为什么这么做、坑在哪里、怎么绕过去。1. 先搞清楚从零到底从哪一层开始很多人一上来就问用什么框架、选哪个模型这其实是把顺序搞反了。AI工程和传统软件工程最大的区别在于它的核心不确定性来自数据和模型而不是代码逻辑。所以从零的起点不是写代码而是先定义清楚这套系统要解决的任务边界。1.1 任务边界决定了后面所有的技术选型我见过太多项目死在什么都想做上。一个AI系统在起步阶段最该明确的是三件事输入是什么形态、输出要满足什么标准、错误容忍度有多高。举个例子如果你做的是文档问答输入是长文本加自然语言问题输出是带出处的答案那么错误容忍度就取决于场景——内部知识检索可以容忍偶尔答偏但如果是面向客户的合规问答答错一次代价就很大。这三件事一旦定下来后面的模型选型、检索方案、评估指标基本就锁死了一大半。反过来如果边界模糊你会陷入模型换了又换、效果始终说不清的泥潭。我的经验是把任务边界写成一句话的需求文档比如给定用户上传的PDF回答其中的事实性问题答案必须能定位到原文段落这句话本身就是验收标准。1.2 区分原型阶段和生产阶段的目标从零搭建最容易犯的错是用原型的标准去做生产或者用生产的复杂度去卡原型。原型阶段的目标只有一个用最短路径验证这件事到底能不能成。这时候你甚至可以用最笨的办法比如把文档全塞进上下文、用最简单的提示词先看效果天花板在哪。生产阶段才需要考虑延迟、成本、并发、可观测性、数据更新这些工程问题。我一般会把这两个阶段明确分开原型阶段允许脏、允许硬编码但必须快速给出可行性结论生产阶段则要求每一个环节都可替换、可监控、可回滚。把这两个阶段混在一起结果往往是原型没跑通、生产也没搭起来。1.3 一张表看清两个阶段的核心差异维度原型阶段生产阶段首要目标验证可行性稳定与可维护模型选择用最强的最省事权衡成本与延迟数据处理手动、一次性自动化、增量更新评估方式人工看几条指标化、可回归错误处理基本不管全链路兜底迭代节奏天级周级、带灰度这张表不是让你照搬而是提醒你每进入一个新阶段都要重新审视之前的决策还成不成立。我踩过最深的坑就是把原型阶段临时凑合的检索逻辑直接带进了生产结果数据一多召回质量断崖式下跌返工成本极高。2. 数据管道是AI工程真正的地基模型可以换框架可以换但数据管道一旦搭歪后面全是补丁。AI工程里所谓的数据管道不只是把数据读进来而是包含采集、清洗、切分、向量化、存储、更新这一整条链路。这条链路的每一个环节都会直接影响最终效果而且影响往往是隐性的。2.1 文档切分不是按字数切这么简单新手最容易忽略的就是切分策略。我早期做知识库的时候直接按固定字符数切结果一个完整的表格被切成两半模型拿到半张表自然答不对。后来我总结了几条经验优先按语义结构切标题、段落、列表项其次才是按长度兜底切分时要保留一定的重叠避免关键信息正好落在边界上对于表格和代码块要尽量保证它们作为整体存在。具体操作上我会先解析文档的结构树把标题层级、段落、表格、代码块分别识别出来然后以最小语义单元为切分粒度再根据模型上下文窗口做合并。重叠部分一般取切分长度的10%到20%这个比例是我实测下来比较平衡的值——太小了边界信息丢失太大了检索时会返回大量重复内容。2.2 向量化和检索的取舍逻辑向量化这块核心决策是用什么模型编码和怎么存怎么查。编码模型的选择要看你的语种和领域通用模型在垂直领域往往表现一般这时候要么用领域数据微调要么在检索后加一层重排。存储方面向量库的选择很多但真正影响体验的是索引参数和检索策略。我一般会采用向量召回加关键词召回的混合策略。纯向量检索对语义相似但用词不同的情况友好但对精确匹配比如产品型号、专有名词容易漏关键词检索正好相反。两者结合再通过重排模型统一打分召回质量会明显提升。这里有个细节混合检索的权重不要拍脑袋定要用一批真实问题做小规模评测来调我通常从向量0.7、关键词0.3开始试。2.3 数据更新是最容易被低估的环节系统上线后数据是会变的。文档会新增、会修订、会删除如果更新机制没设计好检索结果就会越来越脏。我的做法是给每个数据块打上来源标识和版本号更新时按来源做增量替换而不是全量重建。全量重建在数据量小的时候无所谓一旦上到几十万块每次重建的时间和成本都很难接受。另外要处理删除这个动作。很多向量库的删除是软删除或者延迟生效的如果不做额外标记被删掉的内容还可能被检索出来。我会在元数据里加一个有效标志位检索时强制过滤这样即使底层删除有延迟也不会污染结果。提示数据管道的每个环节都要留可观测的日志尤其是切分后的块数、向量化耗时、检索命中率。这些数字在出问题时是你唯一的线索。3. 模型调用层要按可替换来设计把模型调用写死在业务代码里是从零搭建AI系统时最常见的架构错误。模型会迭代、价格会变、供应商会调整如果每次变动都要改业务逻辑维护成本会失控。正确的做法是在业务和模型之间加一层抽象把调用模型这件事变成一个可配置、可切换的能力。3.1 抽象层该抽象什么这层抽象至少要覆盖四件事请求的组装、响应的解析、重试与降级、用量统计。请求组装负责把业务参数翻译成具体模型的调用格式响应解析负责把不同模型的返回统一成内部结构重试与降级处理超时、限流、报错用量统计则让你随时知道钱花在哪了。我一般会定义一个统一的调用接口输入是标准化的消息列表和参数输出是标准化的文本加元信息。具体模型通过配置注册进来业务代码只依赖接口不依赖具体实现。这样换模型时只需要新增一个适配器业务代码一行不用动。3.2 重试和降级不是可选项线上环境里模型调用失败是常态而不是例外。超时、限流、偶发的服务波动都会发生。如果没有重试机制用户会直接看到报错。我的经验是对幂等的调用做指数退避重试重试次数控制在两到三次避免雪崩对非幂等或者重试也失败的走降级路径比如返回缓存结果、返回兜底话术、或者切换到备用模型。这里有个容易忽略的点重试要有上限并且要区分错误类型。网络超时可以重试参数错误重试多少次都没用反而浪费资源。我会在适配器里对错误做分类只对可恢复的错误触发重试。3.3 成本控制要前置到设计阶段模型调用是花钱的而且花起来很快。从零搭建时如果不把成本控制设计进去上线后很容易超预算。我的做法是对输入做长度控制超长内容先摘要或截断对简单任务用小模型复杂任务才用大模型对高频相同请求做缓存。缓存这块要特别注意键的设计。同样的输入在不同上下文下可能语义不同所以缓存键要包含足够的上下文信息否则会返回错误结果。我一般会把系统提示、用户输入、关键参数一起做哈希作为缓存键并设置合理的过期时间。4. 评估体系决定了系统能不能持续变好没有评估的AI系统等于闭着眼睛开车。很多人做完系统就靠感觉还行来判断这是最危险的。评估体系的价值在于它让效果从主观感受变成可比较的数字从而支撑每一次迭代决策。4.1 先建评测集再谈优化评测集是一批带标准答案的真实问题。它的来源可以是历史用户提问、业务专家整理、或者从文档里反向构造。规模不用很大几十到几百条就能看出趋势但必须覆盖主要场景和边界情况。我一般会把评测集分成核心场景和长尾场景两组核心场景要求高通过率长尾场景用来发现盲区。建评测集最忌讳的是自己出题自己答。出题的人要尽量贴近真实用户答案要经过核对。如果条件允许让不参与开发的人来出题效果会更好因为他们不知道系统的弱点在哪出的题更客观。4.2 自动评估和人工评估要配合使用自动评估适合跑回归比如用另一个模型给答案打分或者用规则检查关键信息是否命中。它的优点是快、便宜、可重复缺点是可能和真实质量有偏差。人工评估适合做阶段性验收和疑难案例分析优点是准缺点是慢、贵。我的做法是日常迭代用自动评估快速筛发现指标异常或者要上线新版本时再抽样做人工评估。两者结合既保证了迭代速度又守住了质量底线。自动评估的指标要选得合理比如答案相关性、忠实度、完整性不要只看一个总分。4.3 把评估接进迭代流程评估不是一次性动作而是要固化到流程里。每次改动——换模型、调提示词、改检索策略——都要跑一遍评测集对比改动前后的指标。如果指标下降就要分析原因而不是凭感觉上线。我一般会维护一个改动记录表记录每次改动的内容、指标变化、结论时间长了这就是团队最宝贵的经验库。改动类型关注指标常见风险换模型相关性、延迟、成本风格突变、格式不兼容调提示词忠实度、完整性过拟合评测集改检索召回率、命中位置引入噪声、延迟上升改切分召回率、上下文完整度边界信息丢失这张表是我实际用过的检查清单每次改动前先想清楚要盯哪些指标改完立刻验证避免改好了A、弄坏了B。5. 上线之后才是真正的考验系统上线不是终点而是另一个起点。生产环境里的问题很多在开发阶段根本遇不到。可观测性、灰度发布、用户反馈闭环这三件事决定了系统能不能在真实环境里活下来。5.1 可观测性要覆盖全链路AI系统的链路比传统系统长从用户输入到最终输出中间经过检索、模型调用、后处理等多个环节。任何一个环节出问题用户看到的都是答得不对。所以日志要覆盖每个环节的输入输出、耗时、状态。我一般会在关键节点打结构化日志方便后续检索和分析。除了日志还要有指标监控。比如请求量、成功率、平均延迟、模型调用成本、检索命中率。这些指标要能实时看到并且设置告警阈值。我踩过的坑是只监控了整体成功率结果某个特定类型的请求大量失败却没被发现因为它在总量里占比小。所以监控要能按维度下钻。5.2 灰度发布降低上线风险新版本直接全量上线风险太大。灰度发布的做法是先把新版本放给一小部分流量观察指标和用户反馈确认没问题再逐步扩大。灰度期间要重点对比新旧版本的核心指标一旦发现异常立即回滚。灰度的粒度可以按用户、按请求类型、按时间。我一般会先按内部用户灰度再按小比例外部流量灰度。灰度期间要保证回滚路径畅通配置要能一键切换否则出了问题手忙脚乱。5.3 用户反馈是最真实的评估信号评测集是有限的用户的问题是无限的。把用户的反馈收集起来是持续改进系统最直接的来源。反馈的形式可以是显式的点赞点踩、纠错提交也可以是隐式的追问、放弃、复制答案。显式反馈准确但量少隐式反馈量大但需要解读。我会把反馈和具体的请求日志关联起来这样分析时能看到完整的上下文。对于负面反馈集中的问题类型优先排查和修复。时间长了这些反馈本身就能沉淀成新的评测样本形成正向循环。6. 几个我反复踩过的坑和对应的解法前面讲的都是框架性的东西这一节说几个具体的、我实际踩过的坑。这些坑在文档里基本不会写但每一个都让我付出过代价。6.1 上下文塞太满反而效果差早期我总觉得给模型的信息越多越好把检索到的所有内容一股脑塞进上下文。结果发现模型经常被无关信息干扰答非所问。后来我做了对比实验发现把检索结果按相关性排序、只保留前几条效果反而更好。原因是模型的注意力是有限的噪声多了会稀释关键信息。现在的做法是检索返回较多候选但经过重排后只取最相关的几条进入上下文并且对每条内容做长度控制。如果确实需要长上下文也要把最重要的信息放在靠前或靠后的位置因为模型对中间部分的注意力相对弱。6.2 提示词越改越复杂是个陷阱遇到效果不好就加提示词是很多人的本能反应。我也这么干过结果提示词越写越长规则越加越多最后自己都维护不动而且效果并没有变好。问题在于提示词里的规则之间可能互相冲突模型无所适从。后来我改变了策略提示词只保留最核心的角色定义和输出格式要求把复杂的逻辑交给代码处理。比如格式校验、字段提取这些用代码做比用提示词做更可靠。提示词要简洁、明确、无歧义而不是靠堆砌规则来覆盖所有情况。6.3 忽略冷启动和边界情况系统刚上线时数据少、用户少很多问题暴露不出来。等数据量上来了才发现检索变慢、成本飙升、某些查询类型完全失效。所以从零搭建时就要考虑冷启动和边界情况比如空输入、超长输入、特殊字符、并发高峰。我的做法是在开发阶段就构造一批边界测试用例专门测这些情况。空输入要有兜底提示超长输入要有截断或摘要策略特殊字符要能正确解析并发高峰要有队列和限流。这些看起来是小事但线上出问题时往往就是这些小事引发的。注意边界情况的处理逻辑要尽量简单可靠不要引入新的复杂度。兜底方案的目标是不出错而不是答得好。7. 从零搭建的推荐推进顺序最后说一下我推荐的推进顺序这个顺序是我多次实践后总结出来的能帮你少走弯路。核心原则是先打通链路再优化效果最后做工程加固。第一步明确任务边界写出一句话的验收标准。第二步用最简方案跑通端到端哪怕效果一般先证明链路可行。第三步建一个小规模评测集把效果量化。第四步针对评测结果做优化优先解决影响最大的问题。第五步补齐工程能力包括可观测性、重试降级、成本控制。第六步灰度上线收集反馈持续迭代。这个顺序的关键在于每一步都有明确的产出和验证标准不会出现做了很多但不知道有没有用的情况。我见过太多人一上来就追求架构完美结果链路都没跑通时间全花在了搭架子上。先把事情做出来再把它做好这个顺序在AI工程里尤其重要。我个人在实际操作中的体会是AI工程最难的不是某个技术点而是把数据、模型、工程、评估这几件事串起来形成一个能自我改进的闭环。技术点可以查文档、可以问人但闭环的设计和坚持靠的是对业务的理解和对细节的耐心。从零搭建的过程本质上就是建立这个闭环的过程闭环建起来了系统就有了生命力。