先说实话现在市面上叫“AI”的东西太多了搞得很多人以为会调个API就是在做AI工程。但真正往深了走你会发现从拿数据到模型上线、再到稳定跑在业务里中间隔着一条巨大的工程鸿沟。这个ai-engineering-from-scratch项目说白了就是想把这条路上的坑提前帮你踩平从环境搭建、数据准备、模型微调到部署监控全链路都用最朴素的方式过一遍不依赖那些封装过头的高级框架让你知道底层到底发生了什么。我翻完这个项目的第一感觉是它适合两类人一类是刚入门、想系统建立 AI 工程知识体系的开发者另一类是已经在用现成平台调模型、但总感觉哪里不踏实、想补上底层功底的工程师。这篇文章我会结合项目内容把 AI 工程的整体框架、关键环节、实操过程和避坑经验完整拆给你希望能帮你把零散的知识点串成一条清晰的工程主线。1. AI Engineering 到底是什么先搞清楚边界再动手1.1 它和机器学习、数据工程、后端开发的区别很多人会把 AI Engineering 和传统的机器学习开发混为一谈这是第一个需要纠正的认知。传统机器学习项目核心精力往往花在特征工程和模型调参上而 AI Engineering 的工作重心已经发生了明显偏移——更侧重于如何把大模型或生成式模型可靠地集成到真实业务系统中。你可以把它理解成一种更靠近产品端的工程实践。举个例子三年前你做一个用户流失预测模型重点工作是清洗特征、调逻辑回归的参数、看 AUC 指标。但现在做一个智能客服问答系统你的工作变成了设计检索链路、处理文档分块、管理 Prompt 上下文、控制模型输出格式、处理幻觉问题、做服务高可用。后者涉及的技能面明显更宽它跨越了数据处理、向量检索、模型推理、后端服务、前端交互多个领域。数据工程关注的是管道和存储后端开发关注的是接口和稳定性而 AI Engineering 是把这两者和模型推理能力缝合在一起。它会用数据工程的手段准备语料用后端工程的手段暴露服务但核心逻辑是围绕模型能力来做文章。这个 var 项目的标题里强调 from scratch就是想让人先把这条缝合的过程亲手走一遍理解每一层是怎么协同工作的而不是直接套用别人封装好的模板。1.2 为什么选“从零开始”这个学习路径我的体会是AI 工程最大的陷阱就是封装过度。现在很多平台把模型部署简化成了点几个按钮的事你根本不需要关心底层跑的是什么推理引擎、显存怎么分配、请求队列怎么设计。这种便利会让人对系统的真实运作逻辑产生一种虚无的“掌控感”——看起来什么都会实际上出问题就抓瞎。从零开始的意义在于强制你面对每一层的真实复杂度。如果你自己写过数据清洗脚本你就知道网上那些“干净数据集”是怎么来的如果你自己手动把一个模型导出成推理格式你就知道量化为什么会导致效果下降如果你自己处理过并发请求下的显存溢出你就知道模型服务为什么需要队列和限流。这些经验用平台是学不到的它们只在亲手踩坑的过程中长进身体里。所以我一直建议初学者用“慢方法”来学不要一开始就上成套的 MLOps 平台先用 Jupyter Notebook 做实验、用 shell 脚本跑通流程、用裸 Docker 部署服务。等这些步骤你都操作过一遍再回头用那些自动化工具你会发现自己能看懂日志、能定位问题这时候工具才是你的杠杆而不是你的拐杖。1.3 一条清晰的能力演进路线基于这个项目的思路我认为 AI 工程的能力建设可以拆成五个递进的阶段。第一阶段是数据处理你要能从非结构化的原始文本里提取信息、清洗噪音、构建高质量语料第二阶段是模型能力你要理解怎么选基座模型、怎么做指令微调、怎么评估效果第三阶段是推理部署你要能把模型跑成低延迟高吞吐的服务第四阶段是应用构建你要能设计 RAG 链路、Agent 行为、上下文管理第五阶段是系统工程你要能监控线上表现、处理数据漂移、做 A/B 测试、持续迭代。这五层不是割裂的而是层层支撑关系。数据质量决定模型能力的上限部署架构决定模型能力的释放程度应用设计决定用户对模型能力的感知。每一步你欠下的技术债都会在后面的阶段加倍偿还。这个项目的价值就在于它把这些环节的依赖关系用工程实践的方式呈现了出来让你在起步阶段就知道后面的路是什么样子。2. 核心技能栈拆解从数据到交付的五层结构2.1 数据层AI 工程的地基工程数据层是整个 AI 工程的起点也是决定成败的最关键环节。我见过太多项目模型架构选得很先进部署架构也很完备最终效果却一塌糊涂原因百分百出在数据上。在 ai-engineering-from-scratch 这个实践里数据层的工作被拆成了采集、清洗、结构化、版本管理四个动作。采集阶段你要明确数据边界做问答系统需要什么类型的文档做分类任务需要多少条样本做生成任务需要什么风格的语料。没有边界的数据收集就是给自己埋雷。清洗阶段要处理的问题包括编码混乱、重复内容、无关信息、隐私数据这些噪音会直接污染模型的注意力。结构化阶段是很多人忽略的原始文档需要被拆分成合适的粒度太长了检索不到关键信息太短了丢失上下文。我给你一个参考标准——按语义完整性来切而不是按固定字符数硬切。版本管理是数据层最容易被新手跳过、但工程上最致命的一步。训练集和验证集必须严格隔离否则你的评估结果就是自欺欺人线上数据的分布变化必须被记录否则你根本不知道模型是从什么时候开始退化的。用 DVC 这类工具管理数据版本用统一的命名规范记录数据集变更这些习惯越早养成越好。这个环节看起来不产生直接效果但它决定了你后续所有实验的可复现性。2.2 模型层选型、微调与评估的艺术模型层的核心不是训练因为绝大多数场景不需要你从头训练模型。现在的正确姿势是站在开源基座模型的肩膀上做有针对性的适配。动手前先想清楚需要多强的通用能力需要多深的领域知识需要多高的推理速度。这三个需求会直接决定你用多大参数的模型、要不要做微调、用什么方式做微调。指令微调和全参数微调是两条截然不同的路径。全参数微调对算力要求极高而且在小数据集上容易灾难性遗忘指令微调只更新少量参数训练速度快效果在大多数业务场景下都已经足够。我的建议是优先尝试指令微调把节约下来的算力用于多跑几轮评测。评估环节也不能只看一个指标对话类任务要人工抽检生成质量检索类任务要看召回率和准确率的平衡分类任务要注意不同类别样本的分布均衡。实验追踪在这层必须一开始就建立起来。每次微调用什么基础模型、什么数据集、什么超参数、测评结果如何全部要记录在案。这个项目强调 from scratch其实就是在强调这种朴素的实验纪律。用 Weights Biases 或 MLflow 做记录把每次实验变成可比较的条目你才能知道到底是数据还是参数在影响效果。2.3 部署层从 Notebook 到生产环境的惊险一跃模型部署是 AI 工程里工程化属性最强的一环难点在于训练环境和推理环境之间存在巨大差异。你在 Notebook 里用 PyTorch 加载模型做推理一次只处理一个请求一切美好但到了线上环境你面对的是并发压力、延迟约束、显存限制、版本兼容这些问题。一个标准的部署流程是这样的先把训练好的模型导出成中间格式再选择合适的推理引擎然后封装成服务接口最后做压测和调优。选型时你会面临一个权衡用开源的 vLLM 做优化服务延时高吞吐高但兼容性有要求用简单的 FastAPI 封装则最快最简单但并发能力有限。我的实践经验是先按最简单的方案跑通再用压力测试工具看瓶颈最后根据瓶颈决定要不要换引擎。容器化是部署层的基本功。Docker 镜像要尽量精简模型文件和代码分开管理依赖版本必须锁死环境一变就复现不出来的教训太多了。GPU 资源的分配也需要提前规划即使在没有 GPU 的测试环境里你也要能模拟推理服务的逻辑保证代码的可测试性。这层的核心心法就是一切以稳定为先能复现的结果才算结果。2.4 应用层RAG、Agent 与产品逻辑的缝合模型部署完成后真正的产品体验取决于应用层的设计。现在最主流的技术路径是 RAG它通过检索外部知识库来增强模型生成能力有效缓解幻觉问题。RAG 链路里最关键的两个环节是文档分块质量和检索召回质量而我实践中无数次确认这两个环节的效果根本不是模型决定的而是数据处理决定的。Agent 设计是应用层的另一个热点。但要记住不要为了 Agent 而 Agent多数场景一个清晰的流程编排就够了。Agent 的价值在于需要模型做决策的环节比如根据用户意图选择调用哪个工具、判断任务是否需要追问。把不需要模型判断的步骤硬塞给模型只会增加延迟和出错概率。工程上的克制在这个领域是稀缺品质。Prompt 设计在应用层占据的特殊位置容易被低估。同样是调用同一个模型Prompt 写法不同效果可以天差地别。这个项目的实践里会强调用结构化 Prompt 管理输入输出通过规范化的格式约束让模型按预期方式工作。这不是什么高深技巧但确实能显著降低后处理逻辑的复杂度。2.5 观测层线上监控与持续运营模型上线不是终点只是运维的起点。AI 系统的监控比传统软件复杂你要监控的不只是 CPU、内存这类基础设施指标更关键的是模型行为指标请求成功率、响应延迟、Token 消耗、用户反馈分布。日志要记录上下文输入和模型输出便于事后追溯还需要关注安全合规不能记录敏感信息。数据漂移是 AI 系统特有的风险。用户输入风格变了业务场景变了知识库更新了这些都会导致模型效果下滑。解决思路是定期对线上抽样数据进行人工评估用评估结果反推需要调整的方向。把模型升级做成一个常态化机制而不是一次性项目这才是 AI 工程和软件工程最大的思路差异——模型是需要持续喂养和维护的生命体。3. 实操从零构建一个文档问答系统3.1 场景定义与方案选型用一个具体案例把前面讲的工程框架落一遍我选了最经典的 AI 工程任务文档问答系统。场景设定为“企业内部知识库问答”素材是一些技术文档、操作手册和项目总结用户通过自然语言提问系统返回精准答案并标注来源。方案选型遵循的是能用简单方案就不用复杂方案的思路。核心组件四个嵌入模型做向量化向量数据库做存储检索大模型做答案生成编排框架把链路串起来。这里不套用重框架用最基本的组件自己动手连接这样每个环节出问题你都能定位。嵌入模型选择国产开源的参数适中向量库选择本地方便开发的。模型调用走统一接口方便后续替换供应商。3.2 数据准备与清洗决定上限的流程假如手上有两百份 PDF 文档首先要把它们全部转换成纯文本这个过程会暴露大量问题PDF 里的表格解析出来会乱序扫描件是图片需要 OCR页眉页脚混在正文里形成噪音。清洗规则就围绕着消灭这些干扰展开再统一编码和格式。分块策略直接影响检索质量分块大小一般按 256-512 个字符切分但要注意保留语义完整性用段落和章节边界做硬分隔。每个分块还需要补充元数据信息比如来源文件名、页码、章节标题这些在后面做引用溯源时会被用到。数据质量做到这个程度才能继续往下一步走。3.3 向量化与检索让机器理解语义把分块好的文本变成向量是让机器能比较文本相似度的基础。加载嵌入模型后把每个文本块编码成向量并写入向量库同时建立原文与向量的映射关系便于检索后回溯。这里有一个实操经验——信息密度高的段落可以做滑窗式二次切分保证子片段之间的上下文关联。检索环节需要做向量相似度检索但只用向量检索有局限关键词命中在专有名词场景下很重要。我建议做混合检索向量检索负责语义相似BM25 负责精确词匹配两者结果用 RRF 算法融合。相关性阈值要经过测试太高漏答案太低给噪音。刻意设计一些刁钻问题检验检索链路你会发现很多问题都出在分块粒度上而不是模型能力上。3.4 生成与调用让答案有据可依生成阶段要把检索结果组织成 Prompt 的上下文但关键是要控制信息的质量而不是全部塞给模型上下文过长会淹没关键信息还拉高延迟。每个检索结果要标注来源并在 Prompt 里强制模型在回答中引用来源编号。输出解析也要提前设计要求模型输出 JSON 格式的答案和来源列表然后做格式校验。模型出现幻觉是最常见的失败模式必须对生成内容做校验核对引用编号是否真实存在。这个环节的工程原则是宁可让模型多结构思考也要保证输出的可解析性。用真实问题跑通全流程后再针对低质量回答做检索增强或拆解重检索。3.5 部署上线用 Docker 和 FastAPI 落地把链路封装成 HTTP 服务接口设计成输入问题返回答案和来源。Docker 里需要准备 Python 环境、系统依赖库、必要模型文件还有向量库的持久化存储目录。模型文件单独挂载避免打进镜像造成体积膨胀。并发性能需要压测常见瓶颈在嵌入模型的 CPU 推理速度和大模型的响应时间。调优时可以用缓存机制存热点问答限制最大请求并发数来保护模型服务。这个流程跑下来你会发现AI 应用部署和传统后端部署的核心思路完全一致依赖要管理状态要持久化接口要可观测。把日志加完整把错误处理写全这个服务才算是真正能交到用户手里了。4. 常见问题与排查技巧实录4.1 数据质量导致的模型效果差困惑最深的用户问题是“为什么我的模型总是胡说八道”而绝大多数时候问题不是模型不够强是检索到的内容质量太差。排查时先检查数据清洗环节有没有噪音内容分块是否太碎了上下文有没有被截断然后建立人工评估集合持续追踪对应问题的检索结果集对比正确和错误的样本差异。4.2 内存不足与推理性能优化处理大文档时向量化进程会直接占满内存应对策略是分批量处理并定期释放缓存。显存溢出则通常并发设置过高所致需要调低并发并开启连续批处理。实测数据表明结构化 Prompt 引导模型逐步推理虽然增加延迟但能显著提升复杂问题正确率。这里需要根据场景做取舍因为不是所有场景都需要那种深度思考式推理。4.3 版本管理与复现问题最让人崩溃的是两天前还能跑通的流程突然报错这种情况几乎都是依赖版本漂移导致的。解决方法是锁依赖版本并用 lock 文件做环境一致性管理同时把数据也纳入版本管理。这轮操作做下来你会切身理解为什么 AI 工程里“可复现”三个字是最高褒奖因为只有可复现才能持续迭代。5. 工具链选型心得合适比流行更重要5.1 不同阶段用什么工具工具选型要跟着能力和场景走而不是跟着热度走。起步阶段用开源模型加轻量向量库用 FastAPI 做服务用 Docker 做部署这些工具足够跑通全流程还能帮助你理解底层逻辑。进阶阶段再引入高吞吐推理引擎、分布式向量库、完整的 MLOps 平台。5.2 云服务与自建的关键取舍云服务的好处是省心缺点是对数据资产的掌控力弱自建的好处是灵活可控缺点是需要耗费精力维护基础设施。我的建议分三层看非核心数据或快速验证需求可以用云服务数据敏感场景优先自建混合架构把不同类型需求分线路处理。工具链选型没有标准答案重要的是匹配你当前的资源约束和长期目标。6. 学习路径与实操建议这个项目按数据工程、模型适配、服务部署、应用链路四个维度去学需要投入足够的时间在数据处理和工程化落地上。先找一个小场景跑通全流程会比做一个宏大框架更有收获。看再多的文档和视频都不如亲手把一个模型跑起来再把它成功部署成一个服务接口。最后再分享一点我的个人体会。这个项目让我印象最深的不是技术选型而是它贯穿始终的工程克制能复用开源就不重复造轮子能简单编排就不用过度复杂的框架。AI 工程领域的流行概念更新速度极快但底层的工程素养永远是那些最朴素的东西。希望你也能沉下心来从第一行代码开始把这条链路亲手走通一次那种获得感绝对值得。 从零构建AI工程：数据、模型、部署与RAG全链路实践
先说实话现在市面上叫“AI”的东西太多了搞得很多人以为会调个API就是在做AI工程。但真正往深了走你会发现从拿数据到模型上线、再到稳定跑在业务里中间隔着一条巨大的工程鸿沟。这个ai-engineering-from-scratch项目说白了就是想把这条路上的坑提前帮你踩平从环境搭建、数据准备、模型微调到部署监控全链路都用最朴素的方式过一遍不依赖那些封装过头的高级框架让你知道底层到底发生了什么。我翻完这个项目的第一感觉是它适合两类人一类是刚入门、想系统建立 AI 工程知识体系的开发者另一类是已经在用现成平台调模型、但总感觉哪里不踏实、想补上底层功底的工程师。这篇文章我会结合项目内容把 AI 工程的整体框架、关键环节、实操过程和避坑经验完整拆给你希望能帮你把零散的知识点串成一条清晰的工程主线。1. AI Engineering 到底是什么先搞清楚边界再动手1.1 它和机器学习、数据工程、后端开发的区别很多人会把 AI Engineering 和传统的机器学习开发混为一谈这是第一个需要纠正的认知。传统机器学习项目核心精力往往花在特征工程和模型调参上而 AI Engineering 的工作重心已经发生了明显偏移——更侧重于如何把大模型或生成式模型可靠地集成到真实业务系统中。你可以把它理解成一种更靠近产品端的工程实践。举个例子三年前你做一个用户流失预测模型重点工作是清洗特征、调逻辑回归的参数、看 AUC 指标。但现在做一个智能客服问答系统你的工作变成了设计检索链路、处理文档分块、管理 Prompt 上下文、控制模型输出格式、处理幻觉问题、做服务高可用。后者涉及的技能面明显更宽它跨越了数据处理、向量检索、模型推理、后端服务、前端交互多个领域。数据工程关注的是管道和存储后端开发关注的是接口和稳定性而 AI Engineering 是把这两者和模型推理能力缝合在一起。它会用数据工程的手段准备语料用后端工程的手段暴露服务但核心逻辑是围绕模型能力来做文章。这个 var 项目的标题里强调 from scratch就是想让人先把这条缝合的过程亲手走一遍理解每一层是怎么协同工作的而不是直接套用别人封装好的模板。1.2 为什么选“从零开始”这个学习路径我的体会是AI 工程最大的陷阱就是封装过度。现在很多平台把模型部署简化成了点几个按钮的事你根本不需要关心底层跑的是什么推理引擎、显存怎么分配、请求队列怎么设计。这种便利会让人对系统的真实运作逻辑产生一种虚无的“掌控感”——看起来什么都会实际上出问题就抓瞎。从零开始的意义在于强制你面对每一层的真实复杂度。如果你自己写过数据清洗脚本你就知道网上那些“干净数据集”是怎么来的如果你自己手动把一个模型导出成推理格式你就知道量化为什么会导致效果下降如果你自己处理过并发请求下的显存溢出你就知道模型服务为什么需要队列和限流。这些经验用平台是学不到的它们只在亲手踩坑的过程中长进身体里。所以我一直建议初学者用“慢方法”来学不要一开始就上成套的 MLOps 平台先用 Jupyter Notebook 做实验、用 shell 脚本跑通流程、用裸 Docker 部署服务。等这些步骤你都操作过一遍再回头用那些自动化工具你会发现自己能看懂日志、能定位问题这时候工具才是你的杠杆而不是你的拐杖。1.3 一条清晰的能力演进路线基于这个项目的思路我认为 AI 工程的能力建设可以拆成五个递进的阶段。第一阶段是数据处理你要能从非结构化的原始文本里提取信息、清洗噪音、构建高质量语料第二阶段是模型能力你要理解怎么选基座模型、怎么做指令微调、怎么评估效果第三阶段是推理部署你要能把模型跑成低延迟高吞吐的服务第四阶段是应用构建你要能设计 RAG 链路、Agent 行为、上下文管理第五阶段是系统工程你要能监控线上表现、处理数据漂移、做 A/B 测试、持续迭代。这五层不是割裂的而是层层支撑关系。数据质量决定模型能力的上限部署架构决定模型能力的释放程度应用设计决定用户对模型能力的感知。每一步你欠下的技术债都会在后面的阶段加倍偿还。这个项目的价值就在于它把这些环节的依赖关系用工程实践的方式呈现了出来让你在起步阶段就知道后面的路是什么样子。2. 核心技能栈拆解从数据到交付的五层结构2.1 数据层AI 工程的地基工程数据层是整个 AI 工程的起点也是决定成败的最关键环节。我见过太多项目模型架构选得很先进部署架构也很完备最终效果却一塌糊涂原因百分百出在数据上。在 ai-engineering-from-scratch 这个实践里数据层的工作被拆成了采集、清洗、结构化、版本管理四个动作。采集阶段你要明确数据边界做问答系统需要什么类型的文档做分类任务需要多少条样本做生成任务需要什么风格的语料。没有边界的数据收集就是给自己埋雷。清洗阶段要处理的问题包括编码混乱、重复内容、无关信息、隐私数据这些噪音会直接污染模型的注意力。结构化阶段是很多人忽略的原始文档需要被拆分成合适的粒度太长了检索不到关键信息太短了丢失上下文。我给你一个参考标准——按语义完整性来切而不是按固定字符数硬切。版本管理是数据层最容易被新手跳过、但工程上最致命的一步。训练集和验证集必须严格隔离否则你的评估结果就是自欺欺人线上数据的分布变化必须被记录否则你根本不知道模型是从什么时候开始退化的。用 DVC 这类工具管理数据版本用统一的命名规范记录数据集变更这些习惯越早养成越好。这个环节看起来不产生直接效果但它决定了你后续所有实验的可复现性。2.2 模型层选型、微调与评估的艺术模型层的核心不是训练因为绝大多数场景不需要你从头训练模型。现在的正确姿势是站在开源基座模型的肩膀上做有针对性的适配。动手前先想清楚需要多强的通用能力需要多深的领域知识需要多高的推理速度。这三个需求会直接决定你用多大参数的模型、要不要做微调、用什么方式做微调。指令微调和全参数微调是两条截然不同的路径。全参数微调对算力要求极高而且在小数据集上容易灾难性遗忘指令微调只更新少量参数训练速度快效果在大多数业务场景下都已经足够。我的建议是优先尝试指令微调把节约下来的算力用于多跑几轮评测。评估环节也不能只看一个指标对话类任务要人工抽检生成质量检索类任务要看召回率和准确率的平衡分类任务要注意不同类别样本的分布均衡。实验追踪在这层必须一开始就建立起来。每次微调用什么基础模型、什么数据集、什么超参数、测评结果如何全部要记录在案。这个项目强调 from scratch其实就是在强调这种朴素的实验纪律。用 Weights Biases 或 MLflow 做记录把每次实验变成可比较的条目你才能知道到底是数据还是参数在影响效果。2.3 部署层从 Notebook 到生产环境的惊险一跃模型部署是 AI 工程里工程化属性最强的一环难点在于训练环境和推理环境之间存在巨大差异。你在 Notebook 里用 PyTorch 加载模型做推理一次只处理一个请求一切美好但到了线上环境你面对的是并发压力、延迟约束、显存限制、版本兼容这些问题。一个标准的部署流程是这样的先把训练好的模型导出成中间格式再选择合适的推理引擎然后封装成服务接口最后做压测和调优。选型时你会面临一个权衡用开源的 vLLM 做优化服务延时高吞吐高但兼容性有要求用简单的 FastAPI 封装则最快最简单但并发能力有限。我的实践经验是先按最简单的方案跑通再用压力测试工具看瓶颈最后根据瓶颈决定要不要换引擎。容器化是部署层的基本功。Docker 镜像要尽量精简模型文件和代码分开管理依赖版本必须锁死环境一变就复现不出来的教训太多了。GPU 资源的分配也需要提前规划即使在没有 GPU 的测试环境里你也要能模拟推理服务的逻辑保证代码的可测试性。这层的核心心法就是一切以稳定为先能复现的结果才算结果。2.4 应用层RAG、Agent 与产品逻辑的缝合模型部署完成后真正的产品体验取决于应用层的设计。现在最主流的技术路径是 RAG它通过检索外部知识库来增强模型生成能力有效缓解幻觉问题。RAG 链路里最关键的两个环节是文档分块质量和检索召回质量而我实践中无数次确认这两个环节的效果根本不是模型决定的而是数据处理决定的。Agent 设计是应用层的另一个热点。但要记住不要为了 Agent 而 Agent多数场景一个清晰的流程编排就够了。Agent 的价值在于需要模型做决策的环节比如根据用户意图选择调用哪个工具、判断任务是否需要追问。把不需要模型判断的步骤硬塞给模型只会增加延迟和出错概率。工程上的克制在这个领域是稀缺品质。Prompt 设计在应用层占据的特殊位置容易被低估。同样是调用同一个模型Prompt 写法不同效果可以天差地别。这个项目的实践里会强调用结构化 Prompt 管理输入输出通过规范化的格式约束让模型按预期方式工作。这不是什么高深技巧但确实能显著降低后处理逻辑的复杂度。2.5 观测层线上监控与持续运营模型上线不是终点只是运维的起点。AI 系统的监控比传统软件复杂你要监控的不只是 CPU、内存这类基础设施指标更关键的是模型行为指标请求成功率、响应延迟、Token 消耗、用户反馈分布。日志要记录上下文输入和模型输出便于事后追溯还需要关注安全合规不能记录敏感信息。数据漂移是 AI 系统特有的风险。用户输入风格变了业务场景变了知识库更新了这些都会导致模型效果下滑。解决思路是定期对线上抽样数据进行人工评估用评估结果反推需要调整的方向。把模型升级做成一个常态化机制而不是一次性项目这才是 AI 工程和软件工程最大的思路差异——模型是需要持续喂养和维护的生命体。3. 实操从零构建一个文档问答系统3.1 场景定义与方案选型用一个具体案例把前面讲的工程框架落一遍我选了最经典的 AI 工程任务文档问答系统。场景设定为“企业内部知识库问答”素材是一些技术文档、操作手册和项目总结用户通过自然语言提问系统返回精准答案并标注来源。方案选型遵循的是能用简单方案就不用复杂方案的思路。核心组件四个嵌入模型做向量化向量数据库做存储检索大模型做答案生成编排框架把链路串起来。这里不套用重框架用最基本的组件自己动手连接这样每个环节出问题你都能定位。嵌入模型选择国产开源的参数适中向量库选择本地方便开发的。模型调用走统一接口方便后续替换供应商。3.2 数据准备与清洗决定上限的流程假如手上有两百份 PDF 文档首先要把它们全部转换成纯文本这个过程会暴露大量问题PDF 里的表格解析出来会乱序扫描件是图片需要 OCR页眉页脚混在正文里形成噪音。清洗规则就围绕着消灭这些干扰展开再统一编码和格式。分块策略直接影响检索质量分块大小一般按 256-512 个字符切分但要注意保留语义完整性用段落和章节边界做硬分隔。每个分块还需要补充元数据信息比如来源文件名、页码、章节标题这些在后面做引用溯源时会被用到。数据质量做到这个程度才能继续往下一步走。3.3 向量化与检索让机器理解语义把分块好的文本变成向量是让机器能比较文本相似度的基础。加载嵌入模型后把每个文本块编码成向量并写入向量库同时建立原文与向量的映射关系便于检索后回溯。这里有一个实操经验——信息密度高的段落可以做滑窗式二次切分保证子片段之间的上下文关联。检索环节需要做向量相似度检索但只用向量检索有局限关键词命中在专有名词场景下很重要。我建议做混合检索向量检索负责语义相似BM25 负责精确词匹配两者结果用 RRF 算法融合。相关性阈值要经过测试太高漏答案太低给噪音。刻意设计一些刁钻问题检验检索链路你会发现很多问题都出在分块粒度上而不是模型能力上。3.4 生成与调用让答案有据可依生成阶段要把检索结果组织成 Prompt 的上下文但关键是要控制信息的质量而不是全部塞给模型上下文过长会淹没关键信息还拉高延迟。每个检索结果要标注来源并在 Prompt 里强制模型在回答中引用来源编号。输出解析也要提前设计要求模型输出 JSON 格式的答案和来源列表然后做格式校验。模型出现幻觉是最常见的失败模式必须对生成内容做校验核对引用编号是否真实存在。这个环节的工程原则是宁可让模型多结构思考也要保证输出的可解析性。用真实问题跑通全流程后再针对低质量回答做检索增强或拆解重检索。3.5 部署上线用 Docker 和 FastAPI 落地把链路封装成 HTTP 服务接口设计成输入问题返回答案和来源。Docker 里需要准备 Python 环境、系统依赖库、必要模型文件还有向量库的持久化存储目录。模型文件单独挂载避免打进镜像造成体积膨胀。并发性能需要压测常见瓶颈在嵌入模型的 CPU 推理速度和大模型的响应时间。调优时可以用缓存机制存热点问答限制最大请求并发数来保护模型服务。这个流程跑下来你会发现AI 应用部署和传统后端部署的核心思路完全一致依赖要管理状态要持久化接口要可观测。把日志加完整把错误处理写全这个服务才算是真正能交到用户手里了。4. 常见问题与排查技巧实录4.1 数据质量导致的模型效果差困惑最深的用户问题是“为什么我的模型总是胡说八道”而绝大多数时候问题不是模型不够强是检索到的内容质量太差。排查时先检查数据清洗环节有没有噪音内容分块是否太碎了上下文有没有被截断然后建立人工评估集合持续追踪对应问题的检索结果集对比正确和错误的样本差异。4.2 内存不足与推理性能优化处理大文档时向量化进程会直接占满内存应对策略是分批量处理并定期释放缓存。显存溢出则通常并发设置过高所致需要调低并发并开启连续批处理。实测数据表明结构化 Prompt 引导模型逐步推理虽然增加延迟但能显著提升复杂问题正确率。这里需要根据场景做取舍因为不是所有场景都需要那种深度思考式推理。4.3 版本管理与复现问题最让人崩溃的是两天前还能跑通的流程突然报错这种情况几乎都是依赖版本漂移导致的。解决方法是锁依赖版本并用 lock 文件做环境一致性管理同时把数据也纳入版本管理。这轮操作做下来你会切身理解为什么 AI 工程里“可复现”三个字是最高褒奖因为只有可复现才能持续迭代。5. 工具链选型心得合适比流行更重要5.1 不同阶段用什么工具工具选型要跟着能力和场景走而不是跟着热度走。起步阶段用开源模型加轻量向量库用 FastAPI 做服务用 Docker 做部署这些工具足够跑通全流程还能帮助你理解底层逻辑。进阶阶段再引入高吞吐推理引擎、分布式向量库、完整的 MLOps 平台。5.2 云服务与自建的关键取舍云服务的好处是省心缺点是对数据资产的掌控力弱自建的好处是灵活可控缺点是需要耗费精力维护基础设施。我的建议分三层看非核心数据或快速验证需求可以用云服务数据敏感场景优先自建混合架构把不同类型需求分线路处理。工具链选型没有标准答案重要的是匹配你当前的资源约束和长期目标。6. 学习路径与实操建议这个项目按数据工程、模型适配、服务部署、应用链路四个维度去学需要投入足够的时间在数据处理和工程化落地上。先找一个小场景跑通全流程会比做一个宏大框架更有收获。看再多的文档和视频都不如亲手把一个模型跑起来再把它成功部署成一个服务接口。最后再分享一点我的个人体会。这个项目让我印象最深的不是技术选型而是它贯穿始终的工程克制能复用开源就不重复造轮子能简单编排就不用过度复杂的框架。AI 工程领域的流行概念更新速度极快但底层的工程素养永远是那些最朴素的东西。希望你也能沉下心来从第一行代码开始把这条链路亲手走通一次那种获得感绝对值得。