从零搭建AI工程：数据管线、模型选型与生产落地的完整复盘

从ai-engineering-from-scratch这个标题说起。我最早看到这个词是在某个技术论坛的分享帖里当时第一反应是想起了自己从零搭第一套AI应用的那一年。那时候我以为最大的难点会是什么模型结构、损失函数、分布式训练结果真正把我磨掉一层皮的全是模型之外的东西。数据从哪来、怎么清洗、怎么评估输出好不好、怎么让服务稳定跑在线上、用户骂回来的时候怎么快速定位是检索的问题还是生成的问题——这些问题每一个都比调模型更耗人。这篇内容不是理论科普就是一次从零开始搭AI工程的完整复盘。我会把整条链路上实际踩过的坑、验证过的解法一起写出来覆盖数据管线、模型选型、评测体系、服务化部署、迭代闭环这些环节。适合手里有一个具体的AI应用想法、但不知道从哪起手的工程师或产品同学也适合已经跑通了一个Demo、正在往生产环境推进的团队。即使你现阶段只用API不碰训练里面讲的工程思路也一样用得上。1. 先搞清楚AI工程到底在工程什么很多人听到AI工程就想到训练、微调、提示词但工程这个词的语义重点在可交付、可运行、可维护。一个能出漂亮结果的Notebook不算工程一套能在线上稳定运行、出了错能排查、有了反馈能迭代的系统才算。这个认知差异基本决定了你后续每一步的工作方式。1.1 一个反直觉的起点模型反而是最简单的一环我第一次从零搭建的是一个面向企业内部知识库的问答系统。需求听起来很简单员工提问系统基于内部文档回答并标注答案引用出处。我原以为这个项目的大头在找一个大模型结果真正动手拆解的时候发现哪怕只画一个最粗糙的链路图也有这些东西要处理知识库原始文档的采集、格式解析、清洗与去重长文档的切片策略与向量化索引检索召回与相关性排序模型调用与提示词编排答案生成、引用溯源与置信度判断权限控制不同员工能问到的文档范围不一样审计日志谁问了什么、模型回了什么、引用了哪些原文评测基准拿什么标准衡量系统答得好不好灰度发布与线上反馈回流这条链路摆出来之后你会发现模型只是其中一环。而且从零开始的时候你连企业内部知识库的原始数据在哪这个问题都没有现成答案更别提什么微调了。我后来反复跟人讲一个结论如果一件事的链路里有八个环节你绝不能只盯着最亮眼的那一个。1.2 从零搭建的完整工作流轮廓我把整套流程归纳成六个阶段每个阶段有明确的产出物方便你对照自己的项目进度目标与范围定义明确系统解决什么问题、服务谁、接受的输入和输出长什么样。产出物是需求文档和验收标准。数据管线建设收集、解析、清洗、切片、索引原始数据。产出物是可检索的知识库和一份数据质量报告。模型层选型决定用商业API、开源模型还是自训练模型并设计提示词或微调策略。产出物是模型服务接口和一组示例输出。Harness工程搭建评测集、护栏机制、可观测性、权限审计。产出物是能衡量系统好坏并保证运行安全的支撑体系。推理服务化与性能调优并发处理、延迟优化、成本控制、模型路由。产出物是稳定的线上服务。迭代闭环设计线上bad case回流、评测集扩充、定期回归发布。产出物是持续进化的工作流。这六个阶段在实际推进时不是严格的线性关系尤其是2和4常常需要来回调整。但有了这个框架你至少知道自己处于哪个位置、下一个要解决的是什么问题。1.3 三个最容易翻车的认知误区误区一RAG就是接个向量数据库调个接口。很多人觉得检索增强生成很简单其实切片策略、召回数量、重排逻辑、引用溯源和置信度判断都在你的工程清单里任何一个环节粗糙用户感知到的就是这AI答非所问。误区二微调能解决所有任务失败。如果一个bad case是因为知识库里根本没有对应资料微调一万遍也补不上这个洞。任务效果差时先查数据覆盖和检索质量再考虑是不是模型能力不够。误区三上线之后就可以当甩手掌柜了。模型会漂移、知识库会过期、用户会问出你测试集里完全没出现过的问题。没有迭代机制的AI系统上线三个月基本就是一块会呼吸的化石。这三个误区我在自己项目里和同行交流时反复见到。你提前意识到后面就能少走一大圈弯路。2. 数据管线从零开始最先撞上的墙2.1 先盘点你的起点数据在哪里从零开始做数据管线最大的困境不是不会清洗数据而是根本不知道该处理什么数据。以知识库问答举例你手里的原始资料可能是几十个Word文档、从旧官网导出的HTML页面、扫描版的PDF、零散的会议纪要甚至还有同事直接发来的聊天记录。每一种格式的处理路径都不一样。我当时的做法是先把所有原始资料集中到一个待处理目录按文件类型分类盘点然后逐个解决格式解析问题。这一步不需要什么高深技术但很需要耐心。你需要在这个过程中回答几个问题哪些文件是真正有用的哪些是过期草稿哪些内容之间有重复哪些PDF是扫描件必须走OCR这些答案直接决定了你能构建出什么样的知识库。我踩过的坑是跳过了这一步直接写清洗脚本结果脚本处理完才发现核心的几十份文档因为编码问题根本没被正确读取白跑了一轮。2.2 清洗、去重与格式化的工程细节我整理了一份在大多数文档型知识库场景下都能用的清洗主流程供你参考编码与乱码处理优先统一转成UTF-8GBK和GB18030的兼容问题在中文文档里特别常见。HTML与PDF解析HTML用解析库抽取正文标签过滤导航、广告、页脚文字版PDF直接抽取扫描版走OCR。空值与无效内容过滤去掉空段落、无意义符号、超短文本。正文结构还原保留标题层级信息这对后面的切片策略至关重要。去重按段落或文档指纹做相似度去重重复内容会让检索结果过度集中在某几个片段上。敏感信息筛查在进入知识库之前过滤掉身份证号、手机号等敏感信息这个点在办公场景里尤其重要。切片这块我直接给一组实测过的基础参数适合大多数中文技术文档场景建议切片长度字符相邻重叠长度技术文档800-1200100-200规章制度600-100080-150会议纪要400-80050-100代码示例与说明500-80050-100切片为什么重要因为检索的粒度基本上就是切片的粒度。如果一段话被从中间切开用户问的恰好是跨边界的问题检索系统召回的内容就是残缺的。重叠长度也不能省它相当于给切片之间加了一层缓冲防止语义断裂。清洗脚本写成函数更利于复用我简单贴一个当时用的Python伪代码框架import re import hashlib def clean_text(text: str) - str: # 去除控制字符 text re.sub(r[\x00-\x08\x0b\x0c\x0e-\x1f], , text) # 统一换行 text re.sub(r\r\n?, \n, text) # 合并多余空行 text re.sub(r\n{3,}, \n\n, text) return text.strip() def chunk_text(text: str, chunk_size: int 800, overlap: int 120) - list[str]: chunks [] start 0 while start len(text): end min(start chunk_size, len(text)) # 优先在段落边界截断 if end len(text): pos text.rfind(\n, start, end) if pos start chunk_size * 0.6: end pos chunks.append(text[start:end]) start end - overlap return chunks核心思路很简单先清洗再切片切片时尽量在段落边界断句重叠部分保证上下文连续性。这套代码不复杂但能把后续检索和生成的质量拉高一个台阶。2.3 数据质量评估不能只靠人眼数据清洗完了你还要有一套标准来判断这批数据到底能不能用。靠人眼随机翻几篇文档是没有说服力的我用的方式是抽样评分从知识库中随机抽取100到200个切片从完整性、准确性、一致性、时效性四个维度人工打分每项1到5分然后统计整体均值。打个比方完整性看切片有没有把一句话拆碎准确性看切片内容是否是原始文档中的真实信息一致性看不同文档对同一个概念的表达有没有冲突时效性看信息是否过期。某家公司的组织架构文档还停留在三年前这就是典型的时效性问题。抽样评分跑完之后你会得到一份数据质量报告如果总分低于4分先别急着进入模型环节否则后面所有的检索和回答都会被连带影响。2.4 人工标注与合成数据的平衡早期阶段不要迷信合成数据。市面上有很多用模型批量造数据的方法论但我个人的经验是项目初期花一两天时间人工标注一两百条高质量问答对远比造几千条合成数据有用。人工标注这批数据会成为你的金标准后续验证检索效果、评测回答质量、判断模型升级好坏全部基于这个标准展开。等到评测体系跑通了再考虑用大模型辅助生成更多扩展样本也不迟。3. 模型选型与提示词三条路径和一条主线3.1 要不要从零预训练一场成本与收益的核算build a large language model from scratch这类概念在社区里很火我也能理解这种吸引力的来源——从零预训练一个大模型听上去就是硬核技术的代名词。但作为工程决策我要非常直白地泼一盆冷水从零预训练一个现代大参数量模型是一个国家实验室或顶级科技公司级别的资源配置对绝大多数团队来说不是技术路径而是灾难级的成本选择。你可以用自检清单来做个判断如果五条里有三条答不上来就先别碰你的数据集规模是否达到数万亿token量级并且有清晰的数据来源和版权归属你的算力预算是否覆盖训练期间的多次失败重试你的团队是否具备分布式训练、并行策略调优、断点恢复等底层能力你是否有明确的数据清洗与去重管线能支撑从原始数据到高质量训练语料的转换你的评测体系能否在训练过程中快速判断模型能力有没有真正在变好我在社区里看到build a reasoning model from scratch这类案例的时候第一反应是佩服第二反应是提醒自己别冲动。从零复现一个推理模型的难度比复现一个普通语言模型还要高一个量级它往往不是单模型问题而是数据配比、训练策略、后训练对齐的综合问题。除非你是做学术研究否则作为工程团队这条路的投入产出比低到没法看。3.2 开源模型微调、API调用与RAG的主流组合真正做工程的时候可选的路径就那么几条我的建议是不要把目光局限在任何单一选项上而是按场景混搭方案优势劣势适用场景纯商业API调用接入快效果稳定无需自建GPU单次成本高数据出域依赖供应商快速验证、非敏感数据、对效果要求高的任务开源模型微调数据可控可定制风格与领域能力需要微调与推理部署团队和成本领域术语密集、需要私有化部署、输出格式强约束RAG知识库增强补充最新事实答案可溯源无需重新训练依赖检索质量链路变长知识密集型任务如企业问答、客服、法规查询一个很常见的真实组合是用商业API做通用语义理解用RAG补私域知识再在关键场景微调一个小开源模型专门处理固定格式的输出任务。这种多模型协作的方式比押注单一方案稳得多。3.3 评估模型能力你的测试集和基准从哪来模型选型阶段最容易犯的错是靠手感。同一个模型今天回答得很好明天换了提示词又不行了到底什么时候算好你需要一套稳定的测试集。我的做法是围绕任务类型收集真实问题至少100条起步300条以上更稳。每条问题配一个期望行为描述不一定是标准答案但至少要写明回答里必须包含哪几个要点不能包含什么如果资料不足应该怎么回复。然后定一个通过标准比如回答准确性80%以上且引用可追溯让每次模型或参数调整都能跑一遍回归测试分数变化一目了然。这一步其实就是AI测试开发的地基。很多团队花几周调模型没进展最后发现是压根没有一个可重复的评测环境每次调整都是凭印象判断好像变好了。3.4 提示词工程在什么位置适配层而非能力层提示词工程prompt engineering在最近的热度很高但它的边界必须说清楚。提示词能改变输出的格式、语气、步骤拆解方式但它改变不了两个事实模型不知道的知识还是不知道模型推理不了的问题还是推理不了。它更像是模型与任务之间的适配层负责把模型能力翻译成任务需要的输出。实际操作中提示词优化的循环应该是修改提示词 → 跑回归测试集 → 对比bad case变化 → 判断问题到底出在提示词、数据覆盖还是模型能力。如果一百个bad case里有八十个是提示词导致的误用那优化提示词是高效的但如果问题是模型压根没有相关知识你再怎么优化提示词的措辞也是白费力气。4. Harness Engineering藏在模型背后的大头4.1 什么是Harness Engineering一个被低估的工程概念英语里harness有马具、挽具的意思引申到AI系统里它指的是围绕核心模型建立起来的一整套支撑工程体系——评测、护栏、可观测性、数据管道、反馈回路。模型像是引擎harness是让引擎能够在真实环境中稳定运转的所有外围装置。这个词之所以值得单独拿出来讲是因为业界越来越发现决定一个AI系统能不能交付的往往不是模型本身而是这套外围系统够不够扎实。最近不少AI编程工具和团队复盘案例都在强调这个方向像CodeBuddy在这个领域的实践就很典型一个AI编程工具最核心的竞争力不只在模型生成代码的能力更在于它能否通过测试运行、代码编译检查、用例验证这一整套harness机制把模型的输出变成可靠可用的代码。这个思路放在任何AI应用上都成立。4.2 评测体系从单点指标到任务级测试集我在做第一个项目的时候一开始的评测方法是看几个例子感觉不错就上线结果被用户反馈当场打脸。后来才老老实实搭了三层评测体系第一层是单元评测验证结构化输出是否正确。比如要求模型输出JSON格式的字段这里重点检查字段名、类型、是否缺失。第二层是集成评测跑端到端链路问题从入口进入经过检索、生成、溯源完整看最终输出质量。输出语气在线。第三层是回归评测把历史上所有的bad case收集起来形成回归集每次改动后统一重跑防止修好一个问题的同时弄坏三个旧问题。评测用例的关键字段可以参考这个结构字段说明输入用户问题或场景描述期望输出理想回答包含的要点、格式、态度判断逻辑精确匹配、关键词检查、LLM打分或人工评审关联文档该问题应该检索到的文档范围失败风险如果此题失败可能造成什么影响评测集的质量决定了后续迭代的速度。我见过团队花几周时间调模型最后发现是评测集本身写错了——期望答案和知识库内容对不上模型怎么调都不可能过。所以花力气把评测集做扎实远比急着调参数划算。4.3 护栏设计安全、权限与内容审计从零搭建AI系统时护栏机制是最容易忽略的工程环节因为它在大多数情况下看起来不会出问题。但真实环境永远比测试集复杂用户会问出你完全没预料到的内容模型也可能在极端输入下给出越权或不合规的输出。护栏设计我建议至少覆盖四层输入过滤识别并拦截越权访问、注入类提示词、超长文本从入口控制风险。输出校验检查模型输出是否符合预定义格式与内容约束不符合时触发重试或降级。权限控制不同角色可调用的模型能力和可见的数据范围不同同一套知识库下管理层和普通员工能检索的文档可以完全不一样。审计日志完整记录每次请求的时间、用户、输入、输出、引用来源出了问题能回溯合规审查时有据可依。这套护栏机制最好在系统设计之初就预留位置。等上线出问题再补等于开着车门装安全带又慌又容易漏。4.4 可观测性Trace、日志与反馈回路AI系统最大的排查难点在于链路太长。用户说回答不对你要判断是检索没召回正确内容还是模型没理解问题还是提示词编排出了问题。如果系统里没有可观测性设计排查起来只能靠猜。我的做法是给每一次请求生成一个request_id把完整链路串起来用户输入、检索到的文档片段及相似度分数、最终送入模型的prompt、模型原始输出、后处理结果、各环节耗时、消耗的token数、评测通过情况全部记录到结构化日志里。这样用户反馈一条bad case我五分钟内就能还原现场知道问题出在哪个环节。日志系统不需要一开始就做得很重但字段设计一定要从第一天就留好否则后期补成本成倍增加。5. 从Notebook到生产推理服务化与调度层5.1 从原型到服务的鸿沟Notebook里跑通代码和服务稳定运行在线上是两种完全不同的物种。Notebook阶段你可以慢慢等结果但线上服务面对的是并发、超时、失败重试、流量突增、下游服务不可用。我见过很多原型阶段很顺利的项目一上线就崩在没考虑并发和限流。举一个我踩过的具体例子当时调用一个模型API平时平均延迟800毫秒高峰期突然飙到5秒以上。最初代码里没有超时控制和重试逻辑用户看到的直接就是页面报错。后来我强行给所有外部调用加上了超时阈值3秒和指数退避重试最多3次超时后走降级文案用户感知立刻好了很多。这类问题不会出现在任何模型的精度报告中但它是真实工程里最磨人的东西。5.2 推理成本与延迟的平衡模型调用按token计费或者自建GPU推理成本控制都是一个绕不开的工程问题。我整理过一套组合拳实测能把整体推理成本降到原来的三分之一左右提示词缓存如果系统有大量相同的系统提示词前缀使用缓存可以大幅减少重复计费。语义缓存用户问出和之前相似度较高的问题时直接返回历史结果但需要注意设置一个相似度阈值和有效期避免答案过期。批处理优化离线任务尽量合并请求降低单次调用的开销。模型蒸馏用大模型高质量输出去训练一个小模型处理高频简单任务复杂问题才走大模型。小模型处理常规问题成本能下降一个数量级。动态路由简单问题走轻量模型复杂推理问题走重型模型。这个逻辑特别适合在Agent场景中实现省下的成本非常可观。成本画像我建议挂在可观测性系统里按用户、按场景、按模型分别统计。不看数据你根本不知道你的钱烧在了哪里。5.3 Agent与多模型协作的编排层现在做AI应用绕不开Agent编排和多模型协作的话题。多个模型协同工作的时候调度层就成了工程重点谁来规划任务拆分、谁来调用哪个模型、A模型失败要不要降级到B模型、上下文怎么在多轮之间传递和裁剪。我做过一个主Agent规划 → 检索模型召回 → 生成模型回答 → 审核模型校验的四段式协作流程。思路是每个环节职责单一中间通过结构化数据结构传递而不是直接把大段文本丢来丢去。审核模型负责检查回答是否包含必要信息、是否存在幻觉、格式是否正确不符合就触发一次重生成。这个流程跑起来之后系统整体的错误率比我单用一个模型低了很多。编排层还有一个容易被忽略的点超时与回滚。任何一个环节卡住整个链路就要有明确的兜底方案。比如检索环节超时了是继续用空上下文生成一个抱歉我找不到资料的回答还是直接返回失败这个决策需要提前定义而不是等线上出问题再拍脑袋。6. 让系统自己变好评估闭环与迭代机制6.1 快速跑通端到端先让整条链路转起来从零搭建AI系统最大的忌讳是在每个环节追求完美。我见过太多团队把时间耗在数据清洗和模型选型上结果几个月过去了连一个能点的演示都没有。我的建议是反着来先让整条链路以最粗糙的方式跑通。知识库就放十篇文档模型直接用API评测集就二十条case提示词写个初版。整条链路能出结果之后再逐个环节补密度扩充知识库、完善评测集、优化提示词、加缓存、加护栏。这样做的好处是你永远知道当前改动的效果在完整系统里是什么样而不是像盲人摸象一样优化一个局部却不知道全局变成了什么样。6.2 线上反馈回路怎么设计系统上线不是终点而是迭代的起点。线上用户的真实问题是任何离线测试集都比不了的宝贵素材。我设计过一套简单的周迭代节奏你也可以参考周一收集上一周所有bad case和用户反馈标记优先级。周二到周三清洗标注新case按需扩充分类别的知识库。周四跑全量回归评测观察改动是否引入了新问题。周五发布更新灰度一部分流量观察效果。这个节奏看起来朴素但它是AI系统持续变好的核心机制。没有这个闭环系统上线三个月后知识库过期了、模型行为漂移了、用户问题迭代了系统就会慢慢退化成一块糊在墙上的旧海报。6.3 一次真实的踩坑复盘从Demo到上线的问题清单最后分享一份我记忆中从Demo到上线过程中真实遇到过的典型问题清单每一条后面都跟着一个解法你可以当成一份参考来核对问题现象解法切片把一句话从中间切断检索召回的内容语义残缺切片时优先在段落边界断句增加重叠长度评测集只有正向case模型修改后冒出一堆意外行为建立回归bad case集每次调整统一重跑输出格式未校验偶发返回非JSON内容导致下游解析崩溃增加输出格式校验与自动重试逻辑权限控制上线后才补员工能检索到越权文档在索引和查询阶段都注入权限过滤条件没有语义缓存一周token成本超预算增加缓存层按相似度阈值返回历史答案日志字段不全用户反馈问题时无法还原现场从第一天起记录request_id、检索片段、模型输出、耗时模型升级后旧问题复发指标上升但某些老bad case重新出现保持回归评测集升级前全量验证Agent链路无超时单环节卡住导致整体无响应每个子任务设置超时阈值超时后自动降级这些问题单看都不复杂但它们叠在一起就是从零开始这个过程中最真实的日常。最后说点个人体会。从零做AI工程这一年多的经历给我留下最深的一个认知是模型能力决定的是系统的下限而工程体系决定的是上限。模型选得好不好当然重要但真正让系统稳定输出价值、让团队有信心持续迭代的是那些藏在模型背后、看不见摸不着但每一层都在兜底的东西——数据管线、评测集、护栏、可观测性、反馈闭环。如果你也正在从零搭自己的AI系统别急着羡慕那些训练了一个大模型的新闻先把地基上的每一块砖都铺扎实。地基不牢上面的模型再强也只是空中楼阁。