1. 从零搭建AI工程体系为什么我劝你别一上来就调包“ai-engineering-from-scratch”这个标题第一次看到的时候我愣了一下。不是因为陌生恰恰相反是因为它戳中了我这几年带团队、做项目、面试候选人时反复遇到的一个痛点太多人把“会调API”当成了“会做AI工程”。我见过不少简历上写着“熟悉大模型应用开发”的同学聊下来发现他们的全部经验就是pip install几个库然后写个prompt模板把OpenAI或者国内某家的接口一包前端接个对话框就觉得自己在做AI产品了。这种项目能跑吗能跑。能上线吗也能。但一旦遇到线上并发上来、响应延迟抖动、成本失控、输出不稳定、需要私有化部署、需要做效果评估和迭代立刻就露馅了。所以当我看到“ai-engineering-from-scratch”这个项目标题时我的理解是它要解决的不是“怎么调用一个模型”而是“怎么从零开始把AI能力真正工程化地落地成一个可维护、可扩展、可观测的系统”。这件事的价值远比多学一个框架大得多。这篇文章我想聊的就是如果你真的想从零构建一套AI工程体系应该怎么想、怎么做、怎么避坑。适合谁看适合那些已经会写Python、懂一点后端、但对“AI工程”这个交叉领域还没有系统认知的开发者也适合那些已经在做AI应用、但总觉得自己的系统“哪里不对劲”的工程师。我会尽量用大白话把每个决策背后的逻辑讲清楚让你看完能直接抄作业也能理解为什么这么抄。2. 先想清楚AI工程到底在工程什么2.1 模型只是冰山一角别把全部精力押在选模型上很多人做AI项目第一步就是纠结“用哪个模型”。GPT-4还是Claude开源的通义还是Llama本地部署还是调API这个问题重要吗重要但它绝对不是最重要的。我打个比方。模型就像是一台发动机。你造一辆车发动机当然关键但你不能只买一台发动机就上路了。你还需要底盘、变速箱、刹车、油箱、仪表盘、散热系统。AI工程里的“底盘和变速箱”是什么是数据管道、是推理服务、是缓存层、是评估体系、是监控告警、是成本控制。我实际做过一个对比同一个业务场景用同一个模型只是把prompt组织方式、上下文管理策略、结果缓存机制做了优化端到端的响应时间从平均4.2秒降到了1.8秒token消耗降低了约60%。模型没换效果反而更稳了。这就是工程的价值。所以在“from scratch”的语境下我的建议是先不要急着选模型先把你的系统骨架搭出来。骨架包括输入输出的数据结构、请求的生命周期、失败重试的策略、日志和追踪的埋点。这些东西定好了模型是可以随时替换的插件。2.2 从零构建的三个核心层次接入层、编排层、评估层如果让我把AI工程拆成最核心的三层我会这么分接入层负责和模型打交道。包括API调用、本地推理、流式输出、并发控制、超时重试、密钥管理。这一层的关键词是“稳定”和“可控”。编排层负责把多个AI能力串起来。比如一个问答系统可能需要先做意图识别再检索知识库再生成回答最后做敏感词过滤。这一层的关键词是“灵活”和“可观测”。评估层负责回答“效果到底好不好”。包括离线评测集、在线A/B测试、人工反馈收集、指标看板。这一层的关键词是“可量化”和“可迭代”。很多从零开始的项目接入层勉强能用编排层全靠if-else硬编码评估层基本没有。结果就是系统越做越乱改一个prompt可能影响三个业务线谁也不敢动。2.3 为什么“从零”反而比“用框架”更有优势现在市面上有很多AI应用开发框架LangChain、LlamaIndex、Dify等等。它们当然好用能帮你省很多事。但“from scratch”的意义在于你会被迫理解每一层在干什么。我自己的经验是先用框架快速搭一个原型验证想法然后一定要花时间把关键路径用原生代码重写一遍。重写的过程就是你真正理解系统瓶颈在哪里的过程。比如你会发现框架帮你封装的“检索”环节其实在特定场景下可以用更简单的关键词匹配替代延迟能降一个数量级。这种优化不自己动手是发现不了的。而且从零构建还有一个好处依赖少可控性强。框架升级导致接口不兼容、某个依赖库突然不维护了、安全漏洞需要紧急修复这些坑我都踩过。自己写的核心逻辑改起来心里有底。3. 接入层实操把模型调用这件事做扎实3.1 统一接口设计让模型可插拔接入层的第一件事是定义一个统一的模型调用接口。不管你后面接的是哪家API还是本地跑的推理服务对上层都暴露同样的方法签名。我一般会定义这样一个抽象class LLMProvider: def chat(self, messages: list[dict], **kwargs) - str: raise NotImplementedError def stream_chat(self, messages: list[dict], **kwargs): raise NotImplementedError然后针对不同的后端写具体的实现类。这样做的好处是上层编排逻辑完全不关心底层用的是谁。今天用A家的API明天想换成B家或者本地部署一个开源模型只需要新增一个实现类改一行配置。这里有个细节要注意不同模型的输入格式、参数命名、返回结构都不一样。比如有的用max_tokens有的用max_output_tokens有的返回content有的返回text。统一接口的意义就是把这些差异全部消化在实现类内部对外只暴露标准化的数据结构。提示统一接口不要设计得太“万能”。我见过有人试图把所有模型的参数都塞进一个巨大的kwargs里结果代码里全是if-else判断。更好的做法是定义一套核心参数如temperature、max_tokens、top_p特殊参数通过extra_body传递。3.2 超时、重试与降级别让一个请求拖垮整个服务模型调用最大的特点就是“不确定”。网络会抖服务会限流模型会抽风。如果你不做任何保护一个慢请求就可能占满你的线程池导致整个服务雪崩。我的做法是三层防护第一层超时控制。每个请求必须设置超时时间。流式请求和非流式请求的超时策略不一样。非流式我一般设15到30秒流式的话首token超时设5秒整体超时设60秒。超过就主动断开不要让连接一直挂着。第二层重试策略。不是所有错误都值得重试。网络超时、429限流可以重试400参数错误、401鉴权失败重试也没用。重试次数我一般设2次采用指数退避第一次等1秒第二次等2秒。而且重试要加抖动避免多个请求同时重试造成新的峰值。第三层降级方案。当主模型不可用时能不能切到备用模型当模型完全不可用时能不能返回一个兜底话术这些都要提前设计好。我见过一个线上事故某家API大面积故障因为没做降级整个产品直接不可用持续了将近一个小时。import time import random def call_with_retry(provider, messages, max_retries2): for attempt in range(max_retries 1): try: return provider.chat(messages, timeout20) except RateLimitError: if attempt max_retries: raise sleep_time (2 ** attempt) random.uniform(0, 0.5) time.sleep(sleep_time) except TimeoutError: if attempt max_retries: return fallback_response() time.sleep(1)3.3 并发控制与成本核算每一分钱都要算清楚AI应用的成本结构和传统Web应用完全不同。传统应用主要成本是服务器AI应用的大头是token消耗。如果不做控制一个恶意用户或者一个死循环的prompt可能几分钟就烧掉你几百块。并发控制我一般用信号量或者令牌桶。根据你的预算和模型限流情况设定一个最大并发数。超过的请求排队或者直接拒绝而不是无限堆积。成本核算要细化到每次调用。记录输入token数、输出token数、使用的模型、耗时、用户ID。这些数据积累起来你才能回答“哪个功能最烧钱”“哪个用户消耗最多”“优化prompt能省多少”这些问题。我做过一个粗略的估算一个中等复杂度的问答场景输入平均800 token输出平均300 token用某主流模型单次成本大约在0.01到0.03元之间。如果日活一万每人每天问5次一天就是500到1500元。一个月就是1.5万到4.5万。这个数字如果不监控很容易失控。注意流式输出场景下token计数要在流结束后统一结算。有些API在流式模式下不返回usage字段需要自己用tokenizer估算。估算会有误差但用于成本监控足够了。4. 编排层实操把复杂流程管起来4.1 用状态机代替面条式代码编排层最容易犯的错误就是写成一长串if-else。今天加一个“先检索再回答”明天加一个“如果检索不到就换个方式问”后天加一个“回答完再检查敏感词”。代码很快就变成一团乱麻。我的建议是用状态机来组织。每个状态是一个独立的处理单元状态之间的跳转由明确的条件决定。这样做的好处是流程可视化、可测试、可扩展。举个实际例子。一个知识库问答的流程可以拆成这几个状态意图识别判断用户是在问事实、在闲聊、还是在下指令。查询改写把用户的口语化问题改写成适合检索的形式。知识检索从向量库或关键词库中召回相关内容。答案生成把检索结果和问题一起交给模型生成回答。后处理敏感词过滤、格式整理、引用标注。每个状态只做一件事输入输出都是标准化的数据结构。这样你想调整检索策略只需要改第3步想换生成模型只需要改第4步。互不影响。4.2 上下文管理别把整个对话历史都塞进去上下文窗口是有限资源而且是要花钱的。很多新手会把整个对话历史原封不动地传给模型结果token消耗飞快效果还不一定好。我的策略是分层管理最近N轮对话保留原文。N一般取3到5保证短期连贯性。更早的对话做摘要。用模型或者规则把之前的对话压缩成一段简短的背景描述。系统提示词单独维护。不要和对话历史混在一起方便独立修改和版本管理。检索到的知识按相关性排序只取top K。K一般取3到5太多会稀释重点太少可能漏掉关键信息。这里有个经验值对于大多数问答场景总上下文控制在2000到4000 token之间效果和成本的平衡比较好。超过这个范围边际收益递减很明显。4.3 缓存策略能省的钱一定要省AI应用里很多请求是重复的。比如“你们公司地址在哪”“怎么退货”“客服电话是多少”这些问题每天可能被问几百遍。如果每次都调模型纯属浪费。缓存我一般分两级精确缓存用户问题完全一样直接返回上次的结果。用Redis或者内存缓存都行设置合理的过期时间。语义缓存用户问题不一样但意思相同比如“怎么退款”和“退款流程是什么”。这种需要把问题向量化然后做相似度匹配。相似度超过阈值比如0.95就命中缓存。语义缓存的效果非常明显。我在一个客服场景里实测命中率能达到30%到40%直接省掉三分之一的模型调用。而且响应速度从秒级降到毫秒级用户体验也好了。提示语义缓存的阈值不要设太低。设到0.85以下很容易把不同意思的问题匹配到一起导致答非所问。宁可少命中也不要错命中。5. 评估层实操没有评估就没有迭代5.1 离线评测集你的AI系统的“单元测试”传统软件有单元测试AI系统也需要。离线评测集就是你的“单元测试集”。它是一组问题和标准答案每次修改prompt、换模型、调整流程都跑一遍看效果是涨了还是跌了。评测集怎么建我的做法是从真实用户日志里采样覆盖主要场景和边界情况。人工标注标准答案或者至少标注“好/中/差”三档。定期更新把线上发现的新问题补充进去。规模不用很大初期100到200条就够用。关键是质量要高每条都要有明确的评判标准。评测指标我一般看这几个指标含义目标准确率回答正确的比例越高越好幻觉率编造信息的比例越低越好拒答率无法回答的比例适中太高说明能力不足平均耗时端到端响应时间越低越好平均成本单次调用token成本越低越好5.2 在线A/B测试让真实用户告诉你哪个方案好离线评测过了不代表线上效果就好。真实用户的提问方式、使用场景、容忍度和评测集里的完全不一样。所以上线前一定要做A/B测试。A/B测试的做法很简单把用户随机分成两组一组用旧方案一组用新方案跑一段时间对比核心指标。核心指标不一定是准确率可能是用户满意度、追问率、会话时长、转化率。这里有个坑要注意AI系统的效果波动比较大A/B测试需要足够的样本量才能得出可靠结论。我一般会跑至少一周或者积累至少1000次有效对话再看数据。5.3 人工反馈闭环把用户吐槽变成改进动力自动指标只能反映一部分问题。用户点踩、投诉、转人工这些信号非常宝贵。我会在产品里加一个简单的反馈按钮让用户可以标记“这个回答有帮助”或者“没帮助”。对于标记“没帮助”的case定期人工review找出共性问题。这些共性问题就是下一轮迭代的输入。可能是prompt需要调整可能是知识库有缺失可能是检索策略有问题。没有这个闭环你的系统就是闭门造车。6. 常见问题与排查技巧实录6.1 模型输出不稳定同样的问题答案不一样这是最常见的问题。原因通常是temperature设置过高。对于需要确定性的场景如事实问答、数据提取把temperature设到0到0.3之间。对于创意生成场景可以设到0.7到1.0。如果temperature已经很低了还不稳定检查一下是不是上下文里有随机因素比如检索结果排序不稳定、时间戳变化等。6.2 响应太慢用户等不及先定位瓶颈在哪一层。如果是模型调用慢考虑换更小的模型、开流式输出、加缓存。如果是检索慢考虑优化索引、减少召回数量、加缓存。如果是编排层逻辑复杂考虑并行化可以并行的步骤。流式输出是提升感知速度的利器。首token时间从3秒降到1秒用户体感完全不同。即使总耗时没变用户也觉得快多了。6.3 成本失控账单超预期第一检查有没有死循环或者异常重试导致的重复调用。第二检查上下文是不是太长了有没有把不该传的东西传进去了。第三检查缓存命中率是不是很多重复请求没被缓存。第四考虑用更便宜的模型处理简单任务复杂任务才用贵模型。我一般会设一个日预算告警超过阈值就发通知。再设一个硬上限超过就自动降级到便宜模型或者限流。6.4 知识库更新后模型还是回答旧信息这是检索和生成不同步的问题。检查知识库更新后向量索引有没有重建。很多向量库不会自动更新索引需要手动触发。另外检查缓存有没有过期旧答案可能被缓存住了。还有一个可能模型在生成时忽略了检索结果凭自己的“记忆”回答。这种情况要在prompt里强调“只根据提供的资料回答资料中没有的信息说不知道”。6.5 敏感内容过滤误伤正常回答敏感词过滤太严会把正常内容也拦掉。我的做法是分级过滤高危词直接拦截中危词替换或者打码低危词只记录不拦截。同时保留人工申诉通道误伤了可以快速恢复。另外过滤要在生成之后做不要在生成之前做。生成之前过滤会限制模型的表达能力生成之后过滤只影响最终输出更精准。7. 我踩过的几个大坑和最后的小建议第一个坑过早优化。一开始就想着做多模型路由、做复杂的缓存策略、做精细的成本核算结果核心功能还没跑通精力全耗在基础设施上了。后来我学乖了先用最笨的办法把流程跑通再逐步优化。第二个坑忽视日志。AI系统的日志比传统系统更重要。每次调用的输入、输出、耗时、token数、模型版本都要记下来。出了问题这些日志就是唯一的线索。我现在的习惯是日志字段在设计接口的时候就定好后面不用改。第三个坑不做版本管理。prompt改了、模型换了、检索策略调了效果变了但不知道是哪个改动导致的。后来我给每个配置项都加了版本号每次变更都记录出问题可以快速回滚。最后分享一个小技巧如果你刚开始做AI工程不知道从哪里下手就先做一个最小的闭环。一个简单的问答机器人接一个模型加一个日志加一个反馈按钮。跑起来之后你会自然发现下一个该优化的点在哪里。不要一开始就追求完美架构迭代出来的系统比设计出来的系统更健壮。这个方向后续还可以往很多地方扩展比如多模态输入输出、Agent自主规划、私有化部署、模型微调等等。但不管往哪个方向走接入层、编排层、评估层这三层骨架是不会变的。把这三层做扎实上面盖什么楼都稳。