1. 从零搭建AI工程能力为什么我劝你别一上来就啃论文这两年“AI工程”这个词被炒得火热招聘JD上动不动就要求“具备大模型落地经验”“熟悉RAG架构”“能独立完成Agent开发”。很多做后端、做前端甚至做数据分析的朋友跑来问我到底怎么才能从零把AI工程这套东西学明白我的回答通常很直接——别一上来就抱着Transformer原论文死磕也别急着去调参微调先把“工程”两个字吃透。ai-engineering-from-scratch这个项目标题核心讲的其实就是一件事从工程视角而非学术视角把AI应用从想法到上线的完整链路跑通一遍。它解决的不是“模型为什么能预测下一个token”这种理论问题而是“我手上有个业务需求怎么用现成的模型能力把它做成一个稳定、可维护、能扛住真实流量的服务”。适合谁来参考我认为有三类人最该看一是传统软件工程师想转型AI方向二是产品/运营想自己动手验证AI想法三是学生或刚入行的开发者想补齐工程化这块短板。我自己的背景是后端开发转AI应用踩过的坑不比谁少。最开始我也走过弯路花两个月啃深度学习理论结果真到要做项目时连一个带上下文记忆的对话服务都搭不利索。后来我调整了思路把AI工程拆成“数据接入—模型调用—业务编排—服务部署—监控迭代”这几个环节逐个击破才慢慢摸到门道。这篇内容我就按这个思路把从零搭建AI工程能力的完整路径拆开讲包含方案选型逻辑、关键参数计算、实操步骤和避坑经验尽量让不同基础的人都能照着复现。2. 整体设计与思路拆解AI工程到底在工程什么2.1 先搞清楚AI工程和算法研究的边界很多人把AI工程和算法研究混为一谈这是第一个要纠正的认知。算法研究关心的是模型结构、损失函数、训练策略目标是提升指标AI工程关心的是如何把模型能力稳定、高效、低成本地交付给业务目标是让功能可用、好用、用得起。举个具体例子算法同学会研究怎么把准确率从92%提到94%而AI工程同学要解决的是“这个模型响应延迟800毫秒用户等不了怎么优化到200毫秒以内”。这个边界划清楚之后学习路径就完全不同了。你不需要自己训练一个大模型但你必须懂推理服务的部署方式、上下文窗口的限制、token计费规则、并发请求的处理策略。这些才是AI工程师日常打交道的东西。我见过太多人卡在“要不要自己微调”这个问题上其实对绝大多数业务场景来说用好提示词工程加检索增强效果已经足够成本还低得多。2.2 技术选型的三个核心决策点从零搭建AI工程能力绕不开三个选型决策我把它总结成一张表方便你对照自己的情况做判断。决策点可选方案适用场景我的建议模型来源闭源API / 开源自部署 / 混合快速验证选API数据敏感选自部署起步阶段一律先用API别碰自部署编排框架原生SDK / LangChain类框架 / 自研轻量层简单场景原生SDK复杂流程用框架先原生SDK跑通再考虑引入框架向量存储内存方案 / 专用向量库 / 传统数据库扩展数据量小用内存上规模用专用库十万条以内先用内存方案为什么起步阶段强烈建议用闭源API因为自部署一个可用的开源模型光是环境配置、显存规划、推理加速这几件事就能耗掉你两周时间而且效果未必比API好。工程学习的核心是快速拿到反馈闭环不是炫技。等你把整条链路跑通了再根据成本或合规要求考虑替换模型来源这时候切换成本也低因为你的业务代码和模型调用层是解耦的。2.3 分层架构让每一层都能独立替换我在实际项目里总结出一个分层思路把AI应用拆成四层接入层、编排层、能力层、数据层。接入层负责请求接收和鉴权编排层负责流程控制和提示词组装能力层封装模型调用和工具调用数据层管理向量库和业务数据库。这样分层的好处是任何一层想换实现其他层几乎不用动。比如你一开始用某家API后来想换成另一家只需要改能力层的适配代码编排层和接入层完全无感。再比如你一开始用内存向量存储后来数据涨到百万级要换专用向量库也只动数据层。这种解耦设计是AI工程能长期维护的关键很多demo项目之所以没法变成产品就是因为所有逻辑揉在一个文件里改一处崩三处。3. 核心细节解析与实操要点把每个环节拆到能上手3.1 环境准备与依赖管理环境这块我踩过的最大坑是依赖版本冲突。AI相关的Python包更新极快今天装的版本明天可能就不兼容了。我的做法是用虚拟环境隔离并且把关键依赖的版本号锁死。具体操作上我习惯用venv加requirements.txt而不是直接全局安装。python -m venv ai-env source ai-env/bin/activate # Windows下用 ai-env\Scripts\activate pip install openai python-dotenv fastapi uvicorn pip freeze requirements.txt这里有个细节pip freeze会把所有间接依赖也写进去版本锁得很死好处是可复现坏处是升级麻烦。我的折中方案是主依赖手动指定版本范围间接依赖让它自动解析。另外API密钥这类敏感信息绝对不要写进代码用.env文件管理并且把.env加进.gitignore。我见过有人把密钥提交到公开仓库结果被人跑了几百块账单这种低级错误一定要避免。注意虚拟环境目录不要提交到版本控制团队协作时每个人本地创建自己的环境靠requirements.txt保证一致性。3.2 模型调用层的封装要点直接调API谁都会但工程化的调用层要考虑的东西多得多。我封装调用层时必做四件事超时控制、重试机制、错误分类、用量记录。超时控制是防止请求卡死拖垮整个服务一般设30秒重试机制针对网络抖动但要注意只对可重试的错误重试比如限流错误可以退避重试参数错误重试多少次都没用。错误分类这块我吃过亏。最开始我把所有异常都当成一种处理结果限流错误和认证错误混在一起排查了半天。后来我按HTTP状态码分类401是密钥问题429是限流500是服务端问题分别对应不同的处理策略。用量记录则是为了成本控制每次调用记录token消耗月底一算账心里有数。import time from openai import OpenAI, APIError, RateLimitError client OpenAI(timeout30.0) def call_model(prompt, max_retries3): for attempt in range(max_retries): try: resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}] ) return resp.choices[0].message.content except RateLimitError: wait 2 ** attempt time.sleep(wait) except APIError as e: if e.status_code 401: raise # 密钥问题重试无意义 time.sleep(1) raise Exception(重试次数耗尽)这段代码里退避重试用的是指数退避第一次等1秒第二次2秒第三次4秒。为什么用指数而不是固定间隔因为限流往往是短时间高频触发固定间隔容易继续撞墙指数退避给服务端喘息时间成功率更高。3.3 提示词工程的工程化落地提示词工程不是随便写几句话工程化落地要解决可维护、可测试、可版本管理三个问题。我的做法是把提示词从代码里抽出来单独放在模板文件里用占位符注入变量。这样改提示词不用动代码也方便做A/B测试。提示词模板我一般分三部分角色设定、任务描述、输出格式约束。角色设定让模型知道自己是干什么的任务描述说清楚要做什么输出格式约束保证结果可解析。比如做信息抽取我会明确要求“以JSON格式输出字段包括name、date、amount”这样后续代码直接解析就行不用再做自然语言处理。提示输出格式约束里给一个具体的示例比单纯描述更有效。模型看到示例后格式遵循率能提升一大截。3.4 检索增强的完整链路检索增强是AI工程里最实用的技术之一它让模型能基于你的私有数据回答问题。完整链路包括文档切分、向量化、存储、检索、重排、拼接提示词。每一步都有讲究。文档切分不是随便按字数切要考虑语义完整性。我一般按段落切如果段落太长再按句子切切分块大小控制在300到500字。为什么是这个范围太小了上下文不完整太大了检索精度下降还浪费token。向量化就是把文本转成向量用现成的embedding模型即可不用自己训练。存储用向量库检索时算余弦相似度找最接近的几块。重排这一步很多人会忽略但它对效果影响很大。初步检索出来的结果按相似度排序但相似度高不代表真的相关。重排用一个更精细的模型对候选结果重新打分能显著提升最终质量。我实测下来加了重排之后回答准确率能提升15%左右。4. 实操过程与核心环节实现从零跑通一个完整服务4.1 需求定义做一个能查内部文档的问答服务为了把前面讲的东西串起来我拿一个真实场景来演示做一个能查询内部技术文档的问答服务。需求很明确——用户输入问题系统从文档库里找到相关内容让模型基于这些内容生成回答。这个场景覆盖了AI工程的大部分核心环节又不至于太复杂。先明确技术指标响应时间控制在3秒以内单次回答成本控制在0.01元以内支持每天1000次调用。这些指标决定了后面的选型。3秒响应意味着不能用太大的模型成本限制意味着要控制token用量1000次调用意味着并发不高单机部署足够。4.2 文档处理与向量化实操文档处理是第一步。我准备了一批Markdown格式的技术文档先用脚本把它们切分成块。import os from pathlib import Path def split_document(text, chunk_size400, overlap50): paragraphs text.split(\n\n) chunks [] current for para in paragraphs: if len(current) len(para) chunk_size and current: chunks.append(current.strip()) current current[-overlap:] para else: current \n\n para if current.strip(): chunks.append(current.strip()) return chunks docs [] for md_file in Path(docs).glob(*.md): content md_file.read_text(encodingutf-8) for i, chunk in enumerate(split_document(content)): docs.append({source: md_file.name, index: i, text: chunk})这里overlap参数是重叠字数设50是为了避免正好在切分点丢失上下文。比如一句话被切成两半重叠部分能让两块都包含完整语义。切分块大小400字是我反复测试后的经验值太小检索不准太大浪费token。切分完就是向量化。我用的是现成的embedding接口把每块文本转成向量存起来。这里要注意向量化是有成本的文档多的时候要批量处理别一条一条调那样又慢又贵。4.3 检索与回答生成的串联检索环节用户问题先向量化然后和库里所有向量算相似度取Top 5。为什么取5块而不是1块因为单块可能不完整多取几块让模型有更全的上下文。但也不能太多太多会超出上下文窗口还增加成本。5块是我实测下来效果和成本的平衡点。import numpy as np def retrieve(query_vec, doc_vecs, top_k5): scores np.dot(doc_vecs, query_vec) / ( np.linalg.norm(doc_vecs, axis1) * np.linalg.norm(query_vec) ) top_idx np.argsort(scores)[-top_k:][::-1] return top_idx, scores[top_idx]拿到Top 5的文本块后拼进提示词里让模型生成回答。提示词里我会明确要求“只基于提供的资料回答资料里没有的信息不要编造”。这句话很关键能大幅降低模型胡说的概率。4.4 服务化与接口设计最后把整个流程包成一个HTTP接口用FastAPI实现。接口设计上我留了question和top_k两个参数top_k默认5允许调用方调整。返回结果里除了回答还带上引用的文档来源方便用户核实。from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class Query(BaseModel): question: str top_k: int 5 app.post(/ask) def ask(q: Query): q_vec embed(q.question) idx, scores retrieve(q_vec, doc_vecs, q.top_k) context \n\n.join(docs[i][text] for i in idx) answer call_model(build_prompt(q.question, context)) return { answer: answer, sources: [docs[i][source] for i in idx] }部署用uvicorn起服务前面挂个Nginx做反向代理。单机跑1000次调用绰绰有余等量上来了再考虑加机器或上容器编排。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 模型返回格式不稳定怎么办这是最高频的问题。你要求输出JSON模型有时候给你包一层Markdown代码块有时候字段名拼错有时候干脆输出一段解释文字。我的应对策略分三层第一层在提示词里给明确示例第二层在代码里做容错解析第三层加校验重试。容错解析就是先用正则把可能的JSON部分抠出来再尝试解析。解析失败就触发重试重试时在提示词里强调“只输出JSON不要任何其他文字”。实测下来加了重试之后格式问题基本能解决。如果某个场景反复出问题那就要考虑换更强的模型或者把任务拆得更细。5.2 检索结果不相关怎么调检索不准通常有三个原因切分不合理、embedding模型不适合、相似度算法问题。排查顺序我建议从切分开始把检索出来的块打印出来看如果块本身语义不完整那问题就在切分。如果块没问题但检索不到那可能是embedding模型对领域词汇不敏感考虑换一个在相关领域表现更好的模型。还有一个容易被忽略的点是查询改写。用户的问题往往口语化直接拿去检索效果差。我一般先用模型把用户问题改写成几个关键词或标准问法再拿去检索命中率能提升不少。这一步多花一次模型调用但值得。5.3 成本失控怎么控制成本失控一般发生在两个地方上下文太长和调用太频繁。上下文太长是因为检索回来的块太多或太大解决办法是控制Top K和块大小并且定期清理低质量的块。调用太频繁可能是代码里有循环调用或者缓存没做好。我强烈建议加一层缓存。相同或相似的问题直接返回缓存结果不用每次都调模型。缓存用问题文本的哈希做key简单有效。另外用量记录一定要做每天看一次消耗发现异常及时排查。我见过有人因为一个死循环一晚上跑掉几百块有监控就能避免。问题现象可能原因排查方向解决手段回答胡编乱造提示词约束不足检查是否要求“仅基于资料”加强提示词约束加引用来源响应超过5秒模型太大或检索慢分段计时定位瓶颈换小模型优化检索索引格式解析失败输出不稳定看原始返回内容加示例、容错解析、重试成本突然升高调用量或token异常查看用量记录加缓存限制上下文长度检索结果重复切分重叠过多检查切分参数减小overlap去重5.4 并发上来后服务不稳定单机测试没问题一上并发就崩这是很多demo项目的通病。原因通常是同步阻塞调用把线程占满了。模型API调用是网络IO应该用异步方式。把requests换成httpx的异步客户端FastAPI的接口改成async def并发能力能提升一个数量级。另外模型API本身有速率限制并发太高会触发限流。我的做法是在调用层加一个信号量控制并发数超过就排队等待。这样虽然单个请求可能慢一点但整体服务稳定不会雪崩。6. 能力进阶与持续迭代从能跑到好用6.1 建立评估体系让优化有依据项目能跑起来只是第一步怎么知道改得好不好必须有评估体系。我一般准备一批测试问题每个问题有标准答案或参考答案每次改动后跑一遍看准确率变化。没有评估体系优化就是盲人摸象改了半天可能还退步了。评估指标我关注三个准确率、响应时间、单次成本。准确率靠人工标注的测试集响应时间和成本靠代码自动统计。这三个指标要一起看不能为了准确率无限堆模型和上下文那样成本受不了。6.2 从单轮到多轮的演进单轮问答跑通后自然会想支持多轮对话。多轮的核心是上下文管理要把历史对话带上。但历史不能无限带会超窗口还费钱。我的策略是保留最近N轮更早的做摘要压缩。摘要用模型生成把长对话压成几句话既保留关键信息又控制长度。多轮还有个坑是指代消解。用户说“它怎么样”这个“它”指什么模型不一定知道。解决办法是在提示词里把历史对话结构化明确标出每轮的问答让模型自己推断指代关系。实测下来结构化之后指代准确率明显提升。6.3 工具调用扩展能力边界模型本身能力有限但可以通过工具调用扩展。比如查实时数据、做计算、调外部接口都可以封装成工具让模型调用。工具调用的关键是工具描述要清晰模型靠描述判断什么时候调哪个工具。描述里要写清楚工具做什么、参数是什么、什么时候用。我封装工具时遵循一个原则一个工具只做一件事。不要做一个万能工具参数一大堆模型根本不知道怎么填。拆成多个小工具每个职责单一模型调用准确率高得多。工具调用的结果也要做容错外部接口可能失败失败时要给模型一个明确的错误信息让它决定是重试还是换方案。6.4 监控与日志上线只是开始服务上线后监控和日志是生命线。我必看的几个指标请求量、成功率、平均延迟、token消耗、错误分布。这些指标用简单的日志加统计就能实现不用上复杂的监控系统。关键是每天看发现异常及时处理。日志里我会记录每次请求的问题、检索到的文档、模型返回、耗时和token数。出问题时能完整复现整个链路排查效率高很多。日志要注意脱敏用户隐私信息不能明文记录。保留周期一般设30天太久了占空间太短了不够排查。7. 我在这条路上踩过的几个真实坑最后分享几个我实际踩过的坑都是文档里不会写但特别容易中招的。第一个坑是过度设计。刚开始做的时候我总想着一步到位上微服务、上消息队列、上向量数据库集群结果光搭环境就花了两周业务逻辑一行没写。后来全部推倒重来用最简单的单机方案两天就跑通了。先跑通再优化这个顺序不能反。第二个坑是忽视提示词的版本管理。我改提示词改得很随意今天改一版明天改一版结果效果时好时坏还不知道是哪版导致的。后来我把提示词纳入版本控制每次改动记录原因和效果才理清楚。提示词就是代码必须同等对待。第三个坑是不做降级方案。有次模型API出故障整个服务直接不可用。后来我加了降级逻辑模型调不通时返回预设的兜底话术至少服务不崩。任何依赖外部服务的系统都要考虑依赖不可用时的表现。第四个坑是忽略token计费的细节。不同模型的计费方式不一样有的按输入输出分开算有的有缓存折扣。我一开始没注意预算算错了。后来我把每次调用的输入输出token都记下来按实际计费规则算成本才做到心里有数。这些经验归结起来就一句话AI工程的重点在工程不在AI。模型能力是现成的把它稳定、高效、低成本地交付出去才是工程师的价值所在。从零搭建这套能力不需要你懂反向传播但需要你有扎实的工程思维和持续迭代的耐心。把上面这些环节一个个跑通你就已经超过大部分只会调API的人了。