过去两年“AI工程师”大概是招聘网站上被玩得最滥的词之一。我见过调了两天API就把这个头衔写进简历的也见过连embedding和token都说不清却在带团队的。这行当看起来门槛极低——ChatGPT谁不会用但真到生产环境问题一个接一个模型输出不稳定、数据一变效果就垮、线上出了幻觉没人敢负责、老板问准确率你拿不出一组数字。我给自己起了个项目名叫 ai-engineering-from-scratch就是想亲手把“从零开始做AI工程”这件事完整走一遍不靠感觉、不靠运气每一步都用工程方法去验证。这篇文章是这个项目的复盘也是我踩坑后的总结。如果你正在转型AI方向、刚接触大模型应用开发或者用过LangChain但一直觉得心里没底这篇应该能帮你少走不少弯路。我会从能力建设、第一个实战项目、评测体系和踩坑记录四个维度展开尽量把“为什么这么做”讲透。1. 先捅破窗户纸AI工程不是“调大模型”1.1 五个瞬间让我意识到自己不算AI工程师我一开始也天真地以为会写提示词、会调API、能用Streamlit搭个聊天界面就算AI工程师了。直到几个现实的瞬间把我打回原形。第一件事是我精心调好的Prompt在生产环境跑了一周后开始出现格式化错乱。明明测试的时候怎么问都稳定结果用户换了个问法模型直接输出了两段JSON拼接在一起的脏数据解析直接崩了。这时候我才意识到开发环境的那几个测试case根本代表不了真实用户的行为分布。第二件事更尴尬。底层模型从V1升级到V2之后我的业务效果不但没变好反而明显变差了。因为没有建立回归测试集我根本说不清楚到底哪些能力退化、退化了多少只能看着线上反馈干着急。第三件事发生在一个项目汇报会上。老板问我“这个知识库问答的准确率到底多少”我愣在当场因为我只有几个手工挑的“看起来不错”的例子拿不出一组像样的评测数字。第四件事是换个数据源之后效果腰斩。上一批文档质量高、格式规整效果怎么调都好换成扫描版PDF和一堆表格之后检索结果一塌糊涂整个链路瞬间变成废铁。第五件事是成本失控。我最初设计的流程里每个问题都要重新embedding一次用户query、还要循环调用大模型做意图判断和答案生成结果单日成本涨了5倍一查日志全是重复计算。这五个瞬间让我彻底明白AI工程的重点根本不在“AI”而在“工程”。模型只是流水线上的一台机器工程要做的是把原料数据、加工推理、质检评测、交付API和售后观测整条链路管起来。1.2 工程和炼丹的分野研发RD和AI工程师到底差在哪现在行业里普遍存在一个认知混淆把AI工程师当成“炼丹师”的降级版好像AI工程师就应该去改模型、调参数、搞训练。但实际工作中AI工程师和算法研究员也就是俗称的炼丹师分工完全不同。算法研究员的典型工作是设计模型结构、改进训练策略、做实验验证SOTA指标。他们关注的是“模型能力上限”产出通常是论文和实验报告。AI工程师的典型工作是在预算、延迟、稳定性、合规的约束下把现有模型变成可交付的服务。关注的是“系统在真实环境中的可维护性”产出是接口、链路、评测报告和监控面板。数据工程师解决的是“数据从哪来、怎么流”后端工程师解决的是“高并发下服务怎么不崩”而AI工程师站在中间负责把三者的产出串成一条能用的流水线还要额外承担模型行为不可控的那部分风险。这条岗位边界的定义直接影响你要学什么、不学什么。2. 从零开始的能力清单该学的和可以缓一缓的2.1 Python之外真正决定天花板的底层能力很多教程会给你列一张几百项的学习地图从CNN到Transformer、从概率论到凸优化看完直接劝退。我实践下来真正在AI工程日常工作里高频使用的底层能力其实就三类。第一类是数据结构和基础算法。这不是让你去刷LeetCode而是让你有“复杂度意识”。举个例子你要对一个10万条文本的集合做去重如果写出双层循环就是百亿次操作跑几个小时都完不成知道哈希和倒排索引的人几分钟就搞定了。工程里的很多性能问题本质都是算法复杂度问题。第二类是概率统计和业务指标的打通能力。AI工程的日常是跟“不确定性”打交道。模型输出不是确定的检索结果不是确定的甚至评测分数也有波动。这时候你至少要能看懂准确率、召回率、F1这些指标是怎么算出来的能理解“95%置信区间”是什么意思能在线上流量对比时判断差异是真是假。我见过最离谱的情况是有人拿10个样本跑A/B测试然后说B方案准确率高10个点所以B更好——这基本就是拿噪声当信号。第三类是数据处理能力。清洗、去重、格式转换、编码处理、PDF解析、正则抽取。这部分看起来最不起眼但在RAG类项目里数据质量往往决定了80%的效果。我后面会专门讲数据坑。2.2 工程基建三件套版本控制、容器化、实验追踪如果你只会写代码和调模型不懂版本控制、容器化和实验追踪那你在团队里基本属于“单机版开发”和协作无缘。版本控制不光是git add和commit更重要的是对数据、Prompt、代码、模型配置做联合版本管理。我用过最笨但最有效的方法就是把每一次Prompt改动、评测集更新、代码变更都对应到一次commit上这样任何时候都能回答“当前线上跑的到底是哪一套配置”。很多AI事故的根本原因就是版本失控——谁也不知道线上那个效果很烂的模型是什么时候部署上去的。容器化的核心价值是环境一致性。Python项目的依赖地狱大家都懂torch、transformers、faiss这些库组合在一起换台机器就装不起来。Docker这件事不用学得很深能把基础镜像、依赖安装、端口暴露搞清楚保证项目在别人电脑上能一键跑起来就已经超过60%的AI项目了。实验追踪一开始可以很简单用表格记录就行日期、模型、Prompt版本、评测指标、备注。等你的实验次数多了、变量复杂了再引入MLflow、WB或者LangSmith。但不管用什么工具养成记录的习惯比工具本身重要得多。2.3 我给自己的学习顺序以及为什么“反着来”更有效大多数学习路径是“先理论后实践”先学机器学习基础、再学深度学习、再学NLP、最后才碰LLM应用开发。这条路线适合在校学生对已经工作、想快速转型的人实在太慢了而且很难坚持——因为学了大半年你依然做不出一个能用的东西。我实际采用的顺序是反过来的先做一个完整的小项目建立整体感知再沿着项目里遇到的每一个问题去补底层知识。比如我做了RAG之后发现检索结果差才回去学embedding的原理、向量索引的类型、混合检索为什么有效。带着问题去学效率和留存率都高得多。这个顺序很适合成年人学习的逻辑让新知识和已有经验建立锚点。你没做过项目的时候听“向量数据库选型”完全是空的但当你真的跑过5000条文本的检索、发现速度慢到不能忍的时候再去看HNSW和IVF的差别一次就记住了。3. 第一个端到端项目RAG知识库从空目录到可交付3.1 为什么首战选RAG而不是微调如果你的第一个端到端项目是微调模型我大概率不建议。原因有三个。微调的数据要求太高。哪怕现在有LoRA这类低成本方案你依然需要几百上千条高质量指令数据而数据清洗和构造本身就是一门手艺新手很容易做出一个“看起来在学、其实在背”的模型。微调的迭代周期太长。一次训练跑几小时甚至几天反馈来得极慢不适合建立“改一下→测一下→看结果”的快速反馈闭环。工程能力的培养恰恰依赖快速反馈。微调的风险难以定位。模型效果差了你分不清是数据问题、超参问题还是基础模型问题排查链路非常长。相比之下RAG的每一环都是独立的可以单独测试、单独优化。所以我建议第一个项目做RAG知识库问答。它的业务场景常见客服、内部文档问答、个人知识库、数据获取容易找一批文档就行、效果提升链路清晰检索优化、排序优化、提示词优化都是独立环节更重要的是它能完整覆盖AI工程的全部核心环节。3.2 我的技术选型清单与理由我实测过几套方案之后最终固定的技术栈是这样的你可以直接参考起点不用纠结是不是最新最优组件选型选择理由基础模型Qwen2.5-7B-Instruct本地或 GPT-4o-miniAPI本地部署省钱可控API效果稳定但烧钱建议二选一甚至混用EmbeddingBGE-M3 系列中文效果好支持长文本开源可本地部署跟向量库配合成熟向量库Qdrant 或 pgvectorQdrant功能完整自带过滤pgvector能复用PostgreSQL适合已有MySQL/Postgres团队编排框架先用裸代码再上LangChain新手用框架容易黑盒裸代码能搞清每一步数据流跑通了再换框架提效检索方案向量 BM25 混合检索 重排单独用向量在专有名词精确匹配上很弱混合后召回率明显提升服务层FastAPI轻量、异步性能好、自动生成API文档调试方便前端Streamlit五分钟出界面适合个人项目和内部工具不值得花时间写React部署Docker Compose一套配置拉起所有服务适合单机部署这个选型组合的单位成本极低。如果全用本地开源模型7B量化版本地Embedding普通单卡GPU或16G内存的Mac可以跑起来推理走CPU也能接受就是慢一点。这意味着你可以在零API成本的情况下把整条链路学会对新手非常友好。3.3 七步走完一个可交付项目我把它拆成七个步骤每一步都有明确产出做完你就可以说“我独立做了一个AI应用”。第一步定范围和评测集。这是最容易被跳过的但也是最重要的。从公司官网、内部文档里挑20-30篇内容定义10-20个典型问题把正确答案写出来。这就是第一批评测集。没有评测集后面所有步骤都是盲人摸象。别急评测集后面会扩容到80-100条。第二步清洗和切分。PDF解析是第一个大坑文字版PDF还好扫描版要上OCR表格会被肢解成乱序文本页眉页脚会混入正文。清洗完之后做切分。我实测比较稳的参数是chunk_size设置为512字符中文场景可以略小到400overlap设为50-100字符。切分块太大检索粒度太粗精确信息被淹没切分块太小上下文不完整模型理解不了。第三步生成Embedding并入库。把切好的文档块逐批送入Embedding模型生成向量写入Qdrant同时记录原文、来源、章节位置这些metadata。这一步的核心是校验抽几条文本看语义相近的样本向量相似度是否确实高。第四步搭建检索。先做向量检索取回top_k20同时跑BM25关键词检索取回top_k20然后合并去重。这一步你会发现BM25和向量检索各有所长BM25对专有名词和精确编号很敏感比如“编号Q-2024-011”向量检索对语义改写效果更好。第五步加重排。用cross-encoder把合并后的候选重新打分取前5条拼接成上下文。这是我在所有优化步骤里性价比最高的一步——效果直线上升因为向量检索的粗粒度排序和真正的“与问题相关程度”之间存在差距重排模型正好弥补。第六步搭生成链路。把重排后的内容拼进Prompt明确告诉模型“只能依据给定上下文回答不知道就说不知道”temperature设到0.1-0.2尽可能降低幻觉。最后做一个简单的引用溯源让模型在回答末尾标注参考文档编号这样用户和管理者都能核查答案来源。第七步上线与观测。Docker Compose把FastAPI服务、Qdrant、前端一起拉起来API接口做简单鉴权请求日志里记录query、检索到的doc_id、模型回答、延迟、token数。日志就是最原始的数据资产后面做评测、做分析都靠它。这一步做完你就有了一个从数据到界面、能给别人用的完整产品而不是一段只能在Notebook里跑的代码。4. 评估和观测决定项目能不能活过三个月的部分4.1 没有评测就没有迭代在AI项目里评测体系不是可选项是生死线。道理很简单模型行为是不确定的你改了提示词、换了Embedding、调整了切分参数效果到底变好还是变坏不测根本不知道。没有评测的“优化”本质就是盲猜。我见过太多团队在这个问题上翻车。一个知识库项目上线前负责人拍胸脯说效果“挺好的”问他有没有测过他说“我们手动试了十几个问题都行”。然后一上线真实用户的问题形态完全不一样效果崩得没法看。根本原因就是没有构建有代表性的评测集把“测试通过”当成了“效果达标”。一个及格的评测体系要解决三个问题改动了任何环节能快速知道效果是变好还是变坏能定位是哪一环出了问题能给出业务方可理解的指标数据。有了这三条你的项目才谈得上“可持续迭代”。4.2 一套够用的离线评测方案我推荐的起步方案不需要任何付费工具一个脚本加数据文件就能搞定。评测集怎么造。从测试阶段的日志里抽真实用户问题加上领域专家整理的典型问题凑够80-100条。每条标注输入问题、标准答案或至少包含哪些要点、预期引用的文档范围。注意评测集要覆盖不同难度简单问答、需要多文档综合的复杂问题、知识库没有答案的越界问题专门测幻觉抑制能力。指标怎么算。RAG项目至少要看四个维度召回率正确的文档有没有被检索到、命中率正确答案要点出现的比例、忠实度回答有没有脱离上下文胡编、格式合规率该输出的结构化字段有没有完整输出。前两个可以用程序自动计算后两个可以人工抽评或者用大模型当裁判辅助打分。别追求精度极致能产出趋势数字就够了。用什么工具。裸脚本完全可以起步。# 伪代码示意评测循环 for case in eval_set: docs retrieve(case[question]) answer generate(case[question], docs) recall compute_recall(docs, case[expected_docs]) hit compute_answer_hit(answer, case[expected_points]) record({recall: recall, hit: hit, answer: answer}) print(aggregate_results()) # 输出平均召回率、命中率等等你跑熟了再上Promptfoo或DeepEval这类专业评测框架它们能帮你管理测试用例、批量跑实验、生成对比报告。但核心思想不变把评测当成测试用例集和代码一起放在仓库里每次改动就全量跑一遍回归。4.3 线上观测日志、追踪、成本三件套离线评测解决的是“这次改动好不好”线上观测解决的是“系统实际运行得怎么样”。两者缺一不可。日志是最基本的。每条请求至少记录时间戳、用户问题、检索到的doc_id列表、模型的原始输出、处理耗时、token消耗。这些日志沉淀下来就是未来的评测集和优化依据。我见过不少团队日志没打全出了问题连复盘都做不了。链路追踪解决的是“慢在哪、错在哪”。RAG链路里一个请求要过多个环节——检索、重排、LLM生成。如果用户反馈“很慢”你得能定位是检索慢还是模型推理慢。LangSmith、Arize Phoenix这类工具能自动绘制trace不想引入外部依赖的话自己在日志里给每个环节加耗时记录也能解决问题。成本观测最容易忽略。大模型应用的每一轮对话都在烧钱一天下来不看账单根本不知道花了多少。我自己的做法是在日志里累加每天的token数再按模型单价估算成本并设一个阈值报警。上线新功能之前先在评测集上估算总token数换算成成本再决策。这一招帮我挡掉了好几个“效果更好但贵得离谱”的方案。5. 我踩过的坑LLM工程最常见的翻车现场5.1 数据坑你以为的干净数据全是脏数据RAG项目里最伤人的坑在数据环节。我第一次拿PDF做知识库结果显示很多问题答不上来查了一圈发现是PDF解析出来的文本里表格被拆成了竖排碎片页眉页脚混进了正文还有一堆不可见的Unicode字符干扰了切分。后来换了专业的文档解析工具并对解析结果做人工抽检才把数据质量救回来。现在我的习惯是任何一批新文档入库之前先随机抽5-10块切分结果人工看一遍宁可在数据清洗阶段多花两小时也不要在上线后花两天排查。5.2 评测坑用大模型评大模型会偏心的图省事用GPT-4当裁判给Qwen的回答打分结果发现评分老是偏高。后来才反应过来大模型对“语料相似度高”和“内容正确”是分不清的。Qwen生成的表达风格跟GPT-4完全不同但内容可能是对的裁判却给低分。解决方法是能程序化判定的指标尽量用程序比如召回率、文档命中、格式合规需要主观判断的指标做“双人抽评差异仲裁”或者至少让裁判模型看不到模型名采取盲评。5.3 幻觉与格式坑ILuv JSON不等于JSON大模型最坑人的能力之一就是“自信地输出错误格式”。我试过让模型输出严格JSON它在绝大多数情况下能输出但偶尔会在JSON外面套一个markdown代码块或者字段值里多一个逗号。直接json.loads就会抛异常。后来我做了两件事一是加一层格式后处理用正则把代码块剥掉再做JSON修复二是temperature降到0.2以下明显减少了这类问题。永远不要假设模型输出一定符合规范这是AI工程和传统后端开发最大的差别——你在跟一个概率系统打交道。5.4 成本坑缓存不做的后果很可怕项目刚上线时没有加缓存同一个热门问题被不同用户反复问每次都重新跑完整链路embedding检索LLM生成一天下来成本高得吓人。加一个简单的Redis缓存对query做归一化后计算相似度命中缓存就直接返回结果缓存命中率跑到40%以上成本直接下降三成。这算是AI工程里最简单也最有效的优化手段了。6. 从RAG到Agent下一步怎么走6.1 什么信号说明你可以开始搞Agent了RAG项目稳定运行之后你自然会对Agent产生兴趣。但我建议不要急着上—— Agent开发的门槛和复杂度比RAG高一个量级因为它引入了“多步推理”和“工具调用”任何一个环节出错都很难定位。我建议等这几个信号出现了再动你的RAG项目评测集超过300条并且能持续更新你已经能熟练地把各种问题快速定位到具体环节你对模型输出概率性的容忍度变高了代码里到处都有容错处理。满足这些你才有余力去处理Agent的规划、记忆、工具编排这些复杂问题。RAG做好是Agent的地基地基不稳就盖楼塌了都不知道从哪修。6.2 我的每周刻意练习节奏从零开始学AI工程最怕的就是“看了一堆资料动手却很少”。我给自己定的规矩是每周至少两个小时的“固定动手时间”。形式不限给现有项目加一个功能、修一个评测集里的badcase、跑一遍新的Embedding模型对比效果、或者干脆把一段跑过的项目用不同框架重写一遍。关键是每次都留下痕迹——提交代码、写更新日志、固化结果。艾宾浩斯遗忘曲线的道理大家都懂放到工程学习中一样成立两周不动手LangChain的API你会忘掉一半三个月不动手整个链路的手感就没了。刻意练习的频率比长度重要这是我从自己身上验证过的结论。6.3 最后几句大实话把这个项目从零走完我最深的体会是AI工程的门槛不在“懂AI”而在“懂工程”。大模型的能力进步很快今天不好用的模型明天可能就很好用今天最优的架构三个月后可能就被替代但你对数据质量的敏感度、对评测体系的坚持、对系统可观测性的重视这些工程的底层素养永远有效。如果你现在正准备开始我的建议只有一条别等把理论学完再动手先拿一批文档、一个开源模型、一个空的Git仓库从零开始把一条RAG链路跑通。中途你会遇到无数问题但每一个问题都是在帮你建立真正的工程直觉。这比看一百篇教程都有用。