从零搭建AI工程：避开三大思维陷阱，掌握RAG与评估体系

1. 从“调包”到“造楼”AI工程最常见的三座思维之坑这些年我见过太多人做AI项目翻车原因几乎都一样不是技术不行而是思维方式卡住了。如果你正准备从零开始搞AI工程我建议你先别急着装环境、拉模型先把下面这三座思维之坑看清楚。这三座坑每一个我都掉进去过也看着无数人前赴后继地掉进去。1.1 第一座坑把“模型”当成项目的全部“我们用GPT-4o还是Claude或者干脆微调一个开源模型”——这通常是项目启动会上被问得最多的问题。但我现在听到这种问题基本都会反问一句你的数据在哪你的评估标准是什么你的延迟预算和成本预算是多少很多人以为AI工程的核心是模型其实根本不是。模型只是最终执行推理的那一小块零件。一个真正能落地的AI项目至少包含五个部分数据管道、模型推理、业务逻辑编排、评估反馈、部署监控。模型只是“推理”这一环里的一个组件而已。你花两周时间对比各家大模型的能力边界不如花两天时间先把你自己的数据格式、脏数据比例、标注一致性搞清楚。我做过一个文档解析项目最开始团队盯着一众模型API的参数调来调去后来发现真正的性能瓶颈居然来自PDF里扫描件的OCR质量。同样的模型数据干净和脏乱之间的效果差异能有云泥之别。模型选型这种事情你投入的边际收益越到后面越低反而是数据、评估、工程架构越早投入回报越大。实操建议项目启动的第一周不要允许团队讨论“选哪个模型”。第一周只做两件事梳理数据的来龙去脉定义清楚什么叫做“效果不错”。1.2 第二座坑把“AI工程”等同于“训练模型”这方面我和不少从算法岗转来做工程的朋友聊过他们最强的执念是我得训练一个模型最好从零训练才有技术成就感。但如果你想快速交付一个靠谱的产品“从零训练”几乎是最不划算的路径——除非你的领域极度小众、数据极度特殊否则在这上面死磕只是在浪费你的时间预算。AI工程思维的第一课是学会“复用”。复用成熟的开源模型、复用大家验证过的推理框架、复用现成的部署方案。不是所有东西都要从零开始你把“从零”用在对问题的拆解上比用在模型训练上要有价值得多。通俗一点说你不会为了喝杯牛奶从头开始养一头牛但你会为了让这杯牛奶更好喝去研究水温、奶源和杯子的温度。我见过一个做智能客服的团队一开始执意要自己训练一个对话模型结果训练了两个月效果还不如直接用现成模型加一份质量打磨过的知识库。后来他们只是把重心从“训练”挪到“评估和修正答案”上项目立刻提速了一个量级。拿捏住这个分寸你的AI工程之路会顺很多。1.3 第三座坑忽略“评估”环节凭感觉调优这条绝对是“从零开始”人群里最普遍的灾难。模型跑通了demo演示效果很好领导说“不错不错”然后项目就进入了一种非常危险的状态没有评测集没有量化指标没有回归测试大家的共同语言只剩“我感觉效果好像变好了”。这种感觉驱动型的项目我几乎没见过能顺利上线的。因为你根本说不清改动一个参数后是变好了还是变坏了你也无法向合作方解释为什么这版模型比上版强你更没有办法在后续迭代中防止“修好一个case回归十个case”。AI工程的评估环节不是最后一刻的“验收”而是从第一天起就要建的“度量衡”。它不一定多复杂——先把50条典型case定下来跑一个能自动化打分的脚本每天跟踪几个核心指标的变化这就已经能甩开绝大多数项目了。记住没有评估的AI项目就是一架没有仪表盘的飞机你敢开乘客不敢坐。2. 从零搭建AI项目的完整流程环境、数据、选型与工作流想清楚了上面三个思维之坑我们就可以进入实操语境了。这里说的“从零”不是指你自己写一个深度学习框架而是指你从项目初始阶段就把AI能力揉进整个工程链路。下面这个流程是我反复打磨后的一套顺序不一定适用所有场景但非常适合大多数“用已有模型能力解决业务问题”的项目。2.1 环境与依赖管理先定版本再谈其他很多新手拿到一个AI项目第一步就是装包然后陷入“缺什么补什么”的地狱。我不建议大家这么做。正确的姿势是先确定版本策略再安装依赖。尤其是涉及深度学习框架和大模型库的时候版本混用会带来各种莫名其妙的兼容性问题折腾一圈后发现浪费了几个小时最后只是版本冲突。工程化一点的方案是这样用Python 3.10或3.11作为基线版本很多最新的AI库会对这两个版本优化得最好使用虚拟环境或容器镜像来隔离项目至少做到“换个机器项目还能跑”关键依赖要锁版本比如transformers、torch、vllm这些核心库不要用“最新版”要用你验证过的版本。我在本机搭建过一套LLM微调环境torch和CUDA版本不对一跑就报undefined symbol最后查了半天才发现是torch版本和cuDNN的兼容性出了岔子。从那以后我学乖了一律用docker镜像固定好CUDA、Python、PyTorch三者的版本组合并且在项目文档里写明避免团队其他人重复踩坑。2.2 数据管道设计八成工作量都藏在这里如果说AI工程里有一个环节最不起眼但最决定成败那就是数据。本质上模型只是一个函数逼近器你喂给它的数据边界就是它的能力边界。数据里的偏见、缺失、噪音模型会忠实地学习并放大。对于从零开始的项目数据管道至少要解决这么几个问题数据从哪里来内部积累、公开数据集、爬虫采集、人工标注要明确来源并记录好元数据数据怎么清洗去重、去噪、格式统一、敏感信息脱敏这步能自动化尽量自动化数据怎么切分训练集、验证集、测试集切分时要避免“数据泄漏”比如同一用户的多次记录不能同时出现在训练集和测试集中数据怎么更新尤其在线系统数据的分布会随时间漂移你要有增量更新的机制。说一个我亲手处理的例子有一个文本分类项目原始数据里有大量的HTML标签、表情符号、乱码字符直接丢给模型训练效果很差。后来我写了几个规则脚本把文本统一清洗成纯文本格式并且做了长度截断与分布采样模型的F1分数直接涨了十多个点。对比起来我换模型结构都没这么大的提升。数据清洁度的杠杆远超大多数人的想象。注意数据管道的每个环节都要留下日志和版本记录。否则三个月后你连当时的训练集长什么样都不知道出了问题根本没得溯源。2.3 模型选型别比最好的要比最合适的模型选型这块我不打算给你一张大而全的榜单因为榜单更新得太快今天写出来明天就过时。我只想给你一套判断框架让你面对任何新模型都能自己拿主意。第一看任务类型是生成文本、抽取信息、分类打标还是多模态理解不同任务适配的模型差异很大。第二看数据规模你手头的数据量是否足够支撑微调还是只能做提示工程或者RAG第三看推理成本与延迟这个项目是实时交互型还是离线批处理型第四看生态成熟度模型周边工具链是否完善文档是否友好社区答疑是否多。一个新鲜但偏门的模型能力再强只要它在部署上没有现成的推理方案、没有稳定的API封装我就会认真权衡。反过来说一个老牌但成熟的模型虽然能力不是最顶尖但生态完备踩坑的人多得到的帮助也多工程推进起来反而更稳。AI工程最终是“完成比完美更重要”别为了追求最尖端的参数而牺牲整个项目的稳定性。2.4 工作流编排从“一段脚本”升级为“一条流水线”当你的项目只有一两个模型调用时用脚本串起来没问题。但当你的项目有数据预处理、检索召回、模型推理、结果校验、外部工具调用等多个环节时你就要开始考虑工作流编排了。这一步是“从零到工程化”的分水岭。简单场景下你可以用LangChain或者LlamaIndex这类编排框架快速搭一条链子复杂场景下我会推荐用更通用一点的任务队列和工作流引擎比如Prefect、Airflow之类把每个环节做成独立节点通过DAG的方式定义执行顺序和依赖关系。好处有三点可观测、可重试、可局部替换。举个实际场景做RAG问答系统标准的流程是“意图识别→检索召回→重排序→生成回答→引用溯源”。如果全塞进一个函数里后续想单独优化重排序那一步就得把整条链子翻出来改但如果你一开始就用工作流拆开了优化重排序只需要替换一个节点其他节点不动。这种架构上的主动权就是工程化和“写脚本”的本质区别。3. 从提示工程到RAG大模型落地绕不开的两条路径现在聊模型能力几乎绕不开两条路径一条是“提示工程/上下文工程”另一条是“检索增强生成RAG”。作为从零开始的实践者这两条路你都需要掌握并且要清楚它们的边界。3.1 提示工程便宜见效快但天花板很明显提示工程说到底是在不改变模型参数的情况下通过精心设计输入格式、指令、示例让模型输出更符合预期。它最大的优点是零成本、零延迟损耗适合快速验证想法。它最大的缺点是上限有限——模型的知识是训练时刻死的它没法凭空产生它没见过的信息。我做提示工程的经验可以浓缩成三句话把任务背景写在前面模型需要知道“你是谁、你要干什么”把输出格式约束写清楚最好给出JSON结构或示例把“不能做什么”也写上负面约束有时候比正面约束还有效。比如写一个总结助手你可以在系统提示里明确“你是会议记录摘要助手输出必须包含‘会议决议’和‘待办事项’两个部分不要出现推测性内容”。实测下来这种结构化指令可以把合规率提升不少。但前面说了提示工程的天花板就在那里如果你要基于私有的、动态更新的文档回答问题光靠提示工程搞不定。3.2 RAG让模型学会“查资料”RAG的基本思路很简单在模型回答前先从外部知识库里检索出相关的片段把片段拼接进上下文再让模型基于这些片段回答问题。它本质上不是让模型“记住更多”而是让模型“看到更多”。RAG项目从零搭建有几个核心点值得反复打磨文档切分策略按固定长度切分往往效果很差你需要结合文档结构标题、段落、列表来切让每一块片段保持语义完整性向量化与检索选择合适的embedding模型也别忘了重排序rerank环节它通常比单纯提高向量检索的数量更能提升精准度检索时机与数量不是所有问题都需要检索也不是检索得越多越好。多了容易引入噪音少了容易漏掉关键信息引用溯源生产环境里答案最好能附上来源片段方便用户核对。这也是纯生成模型很难做到的。我有一个做企业知识库问答的项目最初直接拿大模型硬答效果惨不忍睹要么胡说八道要么答非所问。后来切换成RAG架构把几百份产品文档切分成块建立索引再在检索后加了一步重排序最终回答的准确率从四成左右干到了八成多。从那以后我的态度很明确凡是涉及私有知识的问答RAG是首选方案。经验之谈RAG不是一次搭好就一劳永逸的。索引更新、切分策略调优、检索参数调整都需要在评估指标驱动下持续打磨。上线只是开始不是结束。3.3 微调的定位并非万能但有时无法回避谈到RAG免不了要说到微调。RAG解决的是“知识新鲜度”和“私有知识”的问题微调解决的是“风格、格式、行为习惯”的问题。这两者不冲突甚至经常组合使用。如果你希望模型在特定领域内输出特定术语或者你需要模型稳定地遵循某种业务格式——比如法律文书、病历摘要、代码审查意见那么可以考虑微调。但微调需要精心构造训练样本需要评估对通用能力的“灾难性遗忘”影响也需要一定的算力预算和训练调试能力。它比RAG重得多所以我的习惯是能用RAG解决就先不上微调RAG解决不了行为层面的需求再微调。4. 评估体系搭建没有度量衡就没有优化空间前面已经反复强调评估的重要性这里我想把评估体系的搭建方法具体化。在一个从零开始的AI项目里评估绝不是“最后填一个准确率”那么简单。你需要搭三套不同的评估机制。4.1 离线评估回归测试防止效果反弹离线评估的核心是“固定测试集自动评分”。我建议你从第一天就建立一个包含几百条典型案例的评测集覆盖正常场景、边界场景、异常输入。每次改动prompt、检索策略、模型版本后都要在这个评测集上跑一遍记录关键指标的升降。这个机制就是AI项目的“单元测试”它虽然不能保证上线一定成功但能防止你把模型越调越坏。评测集的质量与数量一样重要。我见过有的团队搞了上千条测试集但九成是重复且简单的case测出来的结果虚幻而美好换个场景立刻现原形。构建评测集时一定要刻意加入那些“不好答”的case“不好答”才见真章。4.2 在线评估用户真实反馈是终极标准离线指标再好看也无法完全模拟真实用户的复杂输入和多样需求。在线评估通常关注几类北极星指标用户采纳率用户是否复制或使用了AI的输出、用户纠错率用户是否反复修改AI的答案、请求成功率、服务延迟。如果用户根本不采纳你AI生成的答案那离线指标再高也是自嗨。做在线评估的关键是日志。每条请求的输入、输出、上下文、用户后续行为、延迟、Token数都要完整埋点。只有积累了足够的真实日志你才有机会发现离线评测里发现不了的分布外问题——比如用户开始问离知识库很远的八卦问题或者输入的格式从中文变成了中英混杂。4.3 人工评估当自动指标不灵了怎么办很多生成式任务自动指标比如ROUGE、BLEU未必能反映真实质量。这时候你需要人工评估。搭建一个简单的人工评估流程不需要什么高端平台几张共享表格就能起步每行放一条输入、模型的输出旁边留几个评分维度相关性、准确性、格式合规性再留一列备注。让两三个人独立打分每周固定抽一批新case评估。人工评估最大的问题是不能频繁跑。所以我的节奏通常是这样日常迭代靠自动指标快速筛选每一到两周做一次人工评估做兜底校验。两者结合才能既快又稳。5. 部署与运维上线不是终点是新的起点很多教程讲到“部署上线”就结束了仿佛模型跑起来就大功告成。但真正干过AI工程项目的人都知道上线才是最考验工程能力的开始——模型在测试集上表现得再好落到生产环境里面对真实流量、真实数据分布、真实并发压力各种意料之外的情况会一股脑冒出来。5.1 推理服务响应速度与成本之间的取舍部署大模型推理服务第一道选择题就是延迟、吞吐和成本之间的取舍。你是要实时交互延迟必须控制在几百毫秒内还是离线批处理一分钟出一批结果也无所谓这两者的架构完全不一样。实时场景里我会优先考虑vLLM这类高性能推理框架它对显存管理、连续批处理continuous batching做了大量优化能显著提升吞吐。离线场景里简单粗暴的批处理可能就够了甚至不需要常驻GPU服务。上线之初别追求花哨的一堆特性先把最基本的“模型响应接口封装调用限流”跑稳再逐步加东西。5.2 监控与告警别等用户投诉了才知道出问题AI服务在生产环境里最容易出两类问题一类是性能问题响应变慢、GPU显存溢出一类是效果问题答案开始胡说八道。效果问题的监控尤其容易被忽略因为代码没报错系统也正常但输出变糟糕了。对于效果监控我建议你至少做两件事一是对生成的输出做规则级的“健康检查”比如检查输出长度是否合理、是否包含敏感词、是否完整遵循了输出格式二是持续对比线上输入分布和训练/评测时输入分布的差异一旦发现分布偏移超过阈值就触发告警并考虑重新调整策略或索引更新。注意监控告警的阈值要设置得当太灵敏会导致告警疲劳太迟钝会导致故障发现延迟。建议上线初期把阈值调得偏保守一些宁可多看几条告警也不要放过出问题的苗头。5.3 持续迭代RAG更新、Prompt调优、模型替换的节奏感AI系统的迭代节奏我总结下来是“小步快跑、以评促改”。每次改动不要贪多比如这周只调检索的top-k参数下周只换一个embedding模型再下周只调一段prompt。每次只动一个变量配合离线回归测试和在线指标观察你才能准确地知道“哪次改动带来了什么效果”。如果同时改了三四个地方效果提升了你不知道是哪个起的作用效果下降了你也不知道要回滚哪个。这种“试错不可分”的状态在AI项目里是极大的时间杀手。建立健康的迭代节奏比任何单一技术优化都更能提升团队的整体速度。6. 一份可以直接启动的AI工程练习从零到一的五周路线理论说了不少最后我推荐一个自己试过且觉得非常适合用来练手的方向从零搭建一个“本地个人知识库问答系统”。这个方向几乎覆盖了我上面讲到的所有环节而且对硬件要求不高用开源模型也能跑出不错的效果适合个人开发者或小团队用来练兵。项目链条大致是收集自己的文档技术笔记、论文PDF、日常记录→ 清洗解析 → 切块 → 向量化 → 建立检索服务 → 接入大模型 → 形成问答接口 → 搭建评估用例 → 部署到本地或云服务器。每一步的体积都不大但每一步都能让你体会到“工程”二字的重量。五周的推进节奏我给一个参考阶段时间核心产出关键指标数据准备第1周干净的文档库、切分策略、样例评测集数据覆盖率、切分后片段的有效率检索搭建第2周向量检索重排序流程检索召回率、重排序后Top5准确率生成流程第3周RAG问答主链路答案合规率、引用溯源率、回答延迟评估迭代第4周离线评估体系首次人工评估离线指标趋势、人工评分均值部署与监控第5周推理服务上线、日志与基础监控请求成功率、平均延迟、在线采纳率你可以根据自己的速度和资源调整周期但这个顺序本身非常重要先有数据和评估再搭检索和生成最后才考虑部署。倒着来也可以跑通但你会发现自己后期有大把时间在返工。做这个练习的时候我最想强调的一点是不要追求做“大而全”的完美系统要在每一周结束时保证“当前环节闭环”。哪怕第五周只部署到本机只要整个链路是通的、评估指标是客观的你已经比大多数停留在“调API”阶段的开发者领先一大截了。我个人是这种“小步闭环”练习的忠实信徒。手里有一个能自我迭代的完整项目远比收藏一百个教程要实在得多。按这套路径走完一遍你会对“AI工程”这四个字产生全新的体感——它不再是空中楼阁而是一个你可以掌控的系统。