1. 内容整体设计与思路拆解1.1 从“会调接口”到“懂工程”的必经之路聊起 ai-engineering-from-scratch 这个标题我先说一个特别常见的现象很多人学 AI第一步就是装个 OpenAI 的 SDK写几行代码把接口调通然后觉得自己“会 AI 了”。等真到了生产环境模型回答不稳定、上下文长度爆掉、并发一高就超时、成本跑起来吓人一跳——这些才是 AI 工程真正要面对的日常。所谓“from scratch”不是说让你从头发明深度学习框架也不是非要手写反向传播才算入门。它指的是把 AI 能力接入真实业务时从架构设计、数据准备、模型选型、接口封装到评测、部署、监控、迭代这一整条链路你能自己搭起来、讲明白、踩过坑、修得掉。这不是“调包侠”能覆盖的能力而是一套系统的工程思维。这个内容适合谁三类人跑去学最值第一类是从传统后端转 AI 应用开发的工程师你有服务端功底缺的是对模型能力和局限的完整认知第二类是已经在用 AI 接口做 Demo 的产品经理或独立开发者你做过验证但没上过生产需要补工程化的课第三类是计算机专业学生趁早把工程观念植入比毕业后在项目里吃亏再补要强得多。我自己是从传统推荐系统转过来的早期也天真地以为“只要模型够强一切都能解”。后来被线上事故教育了几轮才慢慢总结出这套从零搭建 AI 工程体系的方法下面按模块拆给你看。1.2 为什么“从零搭建”比“拿来就改”更能建立体系你可能会问现在开源社区里框架一大把直接拿 LangChain、LlamaIndex 改改不香吗为什么非要自己从零搭一遍我的回答是为了建立“边界感”。框架封装得太好你会失去对底层每一环的感知。比如 LangChain 帮你把文档切块、向量化、检索、拼 Prompt 全串好了看起来很顺。但线上检索效果不好时你很难定位是切块策略的锅、向量模型的锅还是 rerank 逻辑的锅。因为你没亲手搭过就没有“每一层应该长什么样”的直觉。我自己带项目时有个习惯新成员第一周不许碰框架先用手写的方式实现一个最小链路——读文档、切文本、调向量模型、存向量库、写检索、拼 Prompt、调大模型、输出解析、加日志、写评测脚本。虽然糙但这一圈下来他对每个环节的数据流就心里有数了之后再上手框架才不会被黑盒牵着走。这不是否定框架框架是提高效率的但前提是你得知道它在替你做什么。AI 工程能力的核心不在“怎么调最强的模型”而在“怎么让模型在你的系统里稳定地发挥作用”。这套能力没有捷径只能靠亲手把每一块积木搭一遍来完成。1.3 三条主线贯穿始终数据、模型、评测如果要把 AI 工程的骨架压缩成三根骨头我会选数据、模型、评测。再强的模型没有合适的数据喂进去输出就是空中楼阁数据再好模型选不对路效果也会打折而如果缺少评测体系前面的一切都只是“感觉还行”根本谈不上可持续迭代。从零开始时数据这条线最容易被人忽略。大家都盯着模型的能力很少有人先把数据管道当一等公民对待。实际上RAG 项目里检索效果差、知识库回答胡编绝大多数问题都出在数据清洗和切分策略上而不是大模型本身。模型这条线很多人以为就是“选最贵那个”实际上要考虑的是任务类型、延迟要求、成本约束和部署环境的组合。评测这条线是国内团队普遍最弱的环节很多人凭感觉验收导致版本迭代成了“拍脑袋”。这三条线不是割裂的。数据质量直接决定评测基线模型选择决定数据的处理方式评测结果反过来指导数据迭代和模型换型。我强烈建议所有想系统学 AI 工程的人先拿这三个词当自己的目录结构data、model、eval。后面的所有内容都会围绕它们展开。2. 核心细节解析与实操要点2.1 数据准备清洗、切分、生成三件套数据是 AI 工程的地基但地基往往是最脏的活。我这里给一套经过实战检验的处理流程你直接套用能省掉大量的返工时间。第一步是清洗。真实业务里的原始文档五花八门有的是 PDF 扫描件、有的是从网页抓下来的带标签文本、有的是多级标题和页眉页脚混在一起的 Word。清洗的目标不是“干净到发亮”而是“让模型能稳定提取信息”。我常用的清洗顺序是转统一文本格式、去掉干扰字符页眉页脚、水印、乱码、保留层级结构。这里有个经验清洗时要把“标题”单独摘出来后面切分和检索时标题是天然的语义锚点效果远好于纯文本流。第二步是切分。这是 RAG 系统里最值得反复调的参数之一。很多人直接用固定字符数切8192 或 4096 就上了。但不同文档的语义密度差太多——代码文档和闲聊文本的最佳块大小能差一个数量级。我的做法是先按 Markdown 标题或段落边界做“语义切分”再对超长段落做二次切分并设置重叠窗口比如前后各重叠 50~100 字符防止关键词正好落在两块之间被截断。切完以后要做一次抽样检查你亲手读个二十来块比任何切分公式都管用。第三步是数据增强。真实项目数据量不够时别急着上采集爬虫。我试过最有效的方法是用大模型反向生成拿已有的少量高质量问答对让模型扩写同义改写、变换问法、补充边界情况。比如你卖的是保险产品知识库拿 10 条基础问题可以让模型扩出 200 条不同问法的变体这个数据我拿去做检索评测非常有效。清洗、切分、增强整个阶段我踩过最大的坑是“清洗过度”。有次我把文档里的表格全部拍平结果模型后来回答“上季度销售额是多少”这类问题时压根找不到数字。表格结构本身就是信息不能无脑拍平。正确的做法是用 OCR 表格识别工具保留结构或者至少把表格转成 Markdown 格式再进向量库。2.2 模型选型不是贵的就好要匹配场景模型选型简直是个“选择困难症地狱”。GPT 系列、Claude 系列、Gemini、国产的 Qwen、DeepSeek、GLM……每年都在更新换代。我的选型框架很简单就三条任务类型、延迟要求、成本预算。任务类型决定了你要的是“语言理解为主”还是“推理能力为主”。如果只是做分类、抽取、改写中小尺寸模型完全够用用大模型反而贵且慢如果做多步推理或复杂指令遵循那确实得上能力更强的模型。延迟要求直接关系到用户体验C 端实时对话模型响应超过 1.5 秒用户就开始不耐烦而离线批量任务跑几分钟都没关系。成本预算最简单也最容易被忽略——你别光看 token 单价要把“跑一轮完整评测的钱”算进去成本会超出你的预期。我常用的做法是“三级选型”先拿一个贵模型定天花板确定任务“上限效果”长什么样再拿一个便宜模型试下限看最省钱方案能不能接受最后在中档模型里挑平衡点。这个做法能帮你快速锁定候选集而不用几十个模型逐个试。顺便说一句本地部署的模型好用不一定非得“开源”。你要考虑的是 GPU 占用、推理框架支持和生态成熟度。有次我看一个模型评测分数很高结果发现社区生态太差连个像样的量化工具都没人维护部署成本反而上去了。选模型看的不是单点分是“整套运维的性价比”。2.3 接口与编排Prompt 是代码参数是配置模型选好了接下来就是怎么调它。我特别想强调一个观念Prompt 不是“写几句话”而是工程代码的一部分。它需要版本管理、可测试、可回滚。我在项目里会把每个 Prompt 单独存成一个模板文件里面用变量占位绝不把业务字段硬编码在代码里这样换场景时不用改代码只改模板。写 Prompt 的核心技巧用四个字总结分而治之。复杂任务拆分成多个简单子任务分别用不同 Prompt 处理再做编排。比如做一个“客户反馈分类系统”你不应该指望一个 Prompt 同时完成意图识别、情绪判断、紧急程度分级。拆成三步第一步判断意图第二步判断情绪第三步判断紧急度。每一步都简单直接输出质量会显著提升排查问题也容易——哪一步效果差就调哪一步的模板不会牵一发动全身。参数配置方面temperature 和 max_tokens 是我最常调的两个。不要以为 temperature 只是“随机性旋钮”它直接影响任务的稳定性。抽取类任务调低0~0.2创意写作调高0.7~0.9。max_tokens 更要注意很多人不设这个值结果模型输出的长度不可控要么截断要么多余。我的习惯是估算目标输出的上限然后加 30% 的余量再配合输出校验和截断逻辑保证系统永远能拿到完整的结构化结果。2.4 工程化封装输出校验比模型能力更重要真正到生产环境你很快会发现模型的输出是不可信的。它不是你的函数没有返回值协议它会多输出、少输出、格式不对、输出 JSON 里带注释。所以工程化的核心我认为不是“让模型更强”而是“让模型输出的错误可以被拦住”。我的做法是在所有模型输出后面挂一道“校验器”。如果任务要求输出 JSON那就用 JSON Schema 做强校验失败就自动重试一次重试时把错误信息带回去让模型自己修。这招实测能把 JSON 解析失败率从 5% 降到 0.1% 以下。所谓“让模型自己修”不是玄学本质上就是把异常信息喂给模型让它看到具体哪个字段不对再生成一版正确的。校验器之外还要重视“重试策略”。网络超时、限流、瞬时报错在这些场景下重试是必须的。但重试不能是无脑的我见过有人把 429 也拿来重试结果越试越限流。合理的做法是对限流响应做退避重试退避时间指数增长最多三次对模型侧的 5xx 错误可以短时间快速重试对校验失败则要走“带纠错信息的重试”而不是简单重发。接口封装的另一个关键点是流式输出。C 端场景我建议优先上流式用户看到文字一个字一个字蹦出来心理等待时间会大幅下降。但流式也有麻烦——你没法等全部输出再校验所以要把“边出边校验”的极限放宽先校验框架比如是否以合法 JSON 开头最终再整体校验。3. 实操过程与核心环节实现3.1 最小链路搭建实录从文档到问答为了把“from scratch”落到实处我给你展示一条完整的最小链路搭建过程。场景做一个公司内部知识库问答机器人输入是一堆产品文档输出是回答用户问题的文本。整个过程不依赖任何编排框架用最朴素的代码串起来但结构是你后面替换任何组件的骨架。环境准备方面Python 3.10 即可核心依赖就三个库一个 HTTP 客户端requests 或 httpx、一个向量数据库客户端我用的是 Qdrant本地装 Docker 就能跑、一个大模型 SDK。你不需要装 LangChain 这类重型依赖先跑通再优化。第一步文档加载与清洗。我写了一个 load_docs()读取本地 Markdown 文件去掉 YAML front-matter就是文档开头的 metadata再把标题行单独存进每个 section 的结构里。这里我特意保留标题信息因为后面生成 embedding 时我会把“标题 摘要 正文开头”拼在一起做向量化效果比纯正文好很多——这属于“语义锚点”技巧。第二步切分。我用的切分逻辑是先按二级标题把文档切成多个 section每个 section 如果超过 1500 字符再往里找最近的段落边界硬切每块之间重叠 80 字符。直接上代码逻辑大概是这样维护一个 current_section 变量遇到标题行就入栈开启新块对超长块用递归二分。这块代码不复杂但你要重点调试的是“重叠窗口别把标题吞了”我在项目里反复调的就是这个。第三步向量化与入库。我选了一个 embedding 模型把文本转成 1024 维向量然后批量写入 Qdrant。写入时给每个点带上元数据来源文件名、章节标题、原文 ID。这步看着简单但元数据会决定后面引用溯源能不能做所以千万别省。写入脚本跑完我习惯打印几条随机数据检查一下距离分布如果向量都挤成一堆距离特别近说明分块粒度或模型选的不对趁早调。第四步检索。用户提问时先对问题生成 embedding再去向量库查 top_k5 的相似块然后做一个简单的重排把包含用户问题中关键词的块权重抬高一点。这个手法朴素但管用能显著提升精确匹配类的查询效果。接着把前 5 块拼进 Prompt 的 context 区域让模型基于这些内容回答同时要求“引用来源编号”方便做引用溯源。第五步问答输出。模型返回后我做了两个校验一是检查回答中是否出现了“根据文档”这类幻觉信号正常回答应该带来源标注二是检查有没有直接引用我在 Prompt 里塞的上下文原文说明模型在抄答案而不是理解。这两条规则之后可以在评测阶段量化成指标。这条链路跑通后你就拥有了一套“地基”。之后无论你换向量库、换 embedding、换大模型、加 rerank都是在这套骨架的某个节点上动手术而不是推翻重来。我的建议是动手搭之前先用一份 30 篇左右的文档做测试集别一上来几万篇不然你根本分不清是链路 bug 还是数据质量问题。3.2 评测体系搭建不量化就无法迭代很多从零开始的工程师忽略评测导致项目上线后每次模型升级都在“赌运气”。我吃过这个亏所以强烈建议你在所有功能开发之前先花时间搭评测框架。评测别搞太复杂先建三个层级的指标第一层“基础正确性”回答是否忠实于上下文是否出现关键事实错误。实现方式是人工标注一批测试问题50~100 条跑一轮人工打分。别在乎自动化这一层就是要靠人眼去看因为它会建立你判断质量的“手感”。第二层“检索质量”这一层特别重要也是我最推荐的自动化评测起点。方法很简单准备一批问题每个问题人工标好“应命中的文档 ID”然后跑检索统计 hit_rate答案是否在被检索到的文章里和 recallk。这两个指标能直接反映你的切分和向量模型是否靠谱。我在项目里会把 hit_rate 低于 70% 的版本直接挡在发布门外。第三层“端到端效果”用大模型当裁判对模型回答打分。比如给你提交的答案和标准答案让裁判模型像批卷老师一样打分。这个办法有不少噪音但用来筛版本足够了——它能把明显更差的版本筛掉上线前再人工抽检一批效果就很稳。评测的数据管理是我反复强调的点每一轮评测的输入、输出、评分、模型版本、Prompt 版本都要记录。我见过太多团队评测完就删脚本下次想复现完全找不到当时用的数据。评测数据本身就是宝贵资产它让你每次改动都有据可查而不是靠记忆。3.3 部署与监控上线只是开始模型应用到了部署阶段“AI 工程”的工程二字才算真正体现出来。这里我只讲两个核心资源弹性和线上监控。资源弹性方面模型接口的调用量通常不是均匀的白天波峰、夜间波谷突发流量更是家常便饭。如果你用云函数或 Serverless那会自动扩容省心如果用固定 GPU 服务器得提前做好队列和限流防止请求雪崩。我常用的方案是消息队列缓冲 多 worker 消费模型调用队列削峰能有效避免限流。监控层面我会盯四个核心指标调用量QPS、延迟p50/p95/p99、错误率、token 消耗。延迟的 p99 尤其重要——平均值突然变好但 p99 变差说明系统里有一批慢请求可能是模型侧波动或网络问题。错误率要分错误类型看是限流、超时、还是模型侧故障。token 消耗直接和钱挂钩要按天、按版本、按用户维度拆开看哪块成本涨了立刻能定位。日志这块我建议保存每次请求的完整信息输入 prompt、输出结果、耗时、模型版本、参数配置。这些日志既是排查问题的依据也是后续做微调或评测的数据源。成本确实会涨一点但和排障节省的时间相比这钱花得太值了。还有一个容易被忽略的点灰度发布。模型版本升级别一把梭先在 10% 流量上验证几天稳定了再全量。我在项目里吃过一次亏新模型在离线测试分数高上线后因为处理风格变化导致用户投诉猛增但因为灰度只有小流量损失可控。从那以后模型变更我必定走灰度流程这是 AI 工程红线中的红线。3.4 迭代闭环让系统越用越聪明最后一步是迭代。AI 系统不是一次建完就结束的它必须能根据线上反馈持续进化。迭代闭环的核心是线上收集 badcase → 人工分析根因 → 调整数据/模型/提示词 → 跑评测 → 灰度发布 → 持续监控。线上 badcase 收集我建议重点捞两类一是用户明确反馈“答错了”的问题二是系统自动判定的低置信度回答比如校验器没过、重试多次仍失败。拿到 badcase 后别急着改 Prompt先做根因分析是检索没找到资料、找到了但模型没理解、还是模型理解了但答偏了不同的根因对应不同的修法——检索不好就调切分或换 embedding理解不行就优化 Prompt 或换模型答偏了就调 temperature 或加约束。迭代的节奏我建议固定为一周一个版本周二收集整理上周 badcase周三分析根因周四改数据/Prompt周五跑评测出结论下周三灰度。这个节奏听起来慢实际执行下来效率反而高因为每次改动都有评测兜底不会把系统越调越乱。这里我给你一个实战心得迭代过程中80% 的效果提升来自“把高频 badcase 解决掉”而不是追求“所有问题都完美解决”。聚焦高频问题每轮解决掉 3~5 个一个月后系统质量就会有明显跃升。贪多嚼不烂AI 工程尤其如此。4. 常见问题与排查技巧实录4.1 检索结果不相关先别怪模型先查检索引擎我做 RAG 项目时遇到次数最多的问题就是“模型回答莫名其妙感觉像在胡编”。很多人第一反应是换个大模型但我告诉你十有八九根因在检索——模型根本没拿到相关资料它只能靠自己的知识硬答自然就开始胡编。排查思路按顺序来第一步把用户问题直接打印出来人眼确认问题没被改写坏第二步单独跑一遍检索看返回的 top_k 片段里有没有相关内容。如果检索结果就不相关问题出在检索链路跟模型毫无关系如果检索结果相关但模型答得偏才是模型环节的问题。检索结果不相关时优先查三处切分粒度是否合适、embedding 模型是否匹配领域、召回数量是否够用。切分粒度过小语义不完整过大噪音太多。embedding 模型用通用领域做垂直行业专业名词的相似度会不可靠。召回数量太少正确片段没进候选集后面 rerank 再强也救不回来。我常用的调法是把 top_k 从 5 提到 10配合 rerank 重排命中率能明显提升。4.2 输出格式不稳定用 Schema 校验和循环纠错“明明跟模型说了输出 JSON它偏给你一段 Markdown 包裹的代码块”这种问题我相信做 AI 应用的人都遇到过。模型的指令遵循能力不是百分百你不能靠“再强调一次”来根治要从流程上兜底。我的方案是双保险。第一道在 Prompt 层要求模型严格输出纯 JSON 片段不要用代码块包裹也不要在前面加解释文本第二道在代码层用 JSON Schema 校验库解析输出解析失败就触发“纠错循环”——把错误信息拼接进原始提示词让模型看到哪里错了再生成一次。循环最多三次再失败就降级到默认响应。这套逻辑我实测能把格式错误率压到极低。这里有个细节纠错循环时模型重试的输入要把“上一版错误输出”也带上让它知道自己哪里错了。不然你只是把原 prompt 再发一遍它很可能再犯同样的错。把错误信息当作上下文的一部分喂回去等于给模型“批改作业”比单纯重发有效得多。4.3 成本失控没有成本感知的开发都是耍流氓我曾见过一个项目开发阶段跑评测就把一个月预算烧掉一半——因为没人算过一轮评测到底要花多少钱。成本感知是 AI 工程的基本功不是财务的事。控制成本先建一个简单的估算公式单轮请求成本 模型 token 单价 ×输入长度 输出长度× 请求次数。评测前先估算目标测试集跑一轮要多少钱心里有数再动手。开发时多用缓存同一个 prompt 相同参数的结果缓存起来重复测试时不重复计费。生产环境更要加缓存层高频相似问题直接命中缓存成本立省。另一个容易忽略的地方是“输入膨胀”。你搜到的 10 个检索片段全塞进 Prompt可能一次请求就吃掉几千 token。成本压力大时要砍掉低相关片段只保留 2~3 个关键片段成本能降一大截效果下降却有限。我项目里就靠这招把月成本砍了 30% 以上。成本控制不是抠门是让你能把省下来的钱投给更值得的业务场景。4.4 常见问题速查表直接照着排查我把从零搭建过程中最高频的几类问题整理成一张表你遇到时直接按表排查能省很多弯路现象可能原因优先排查项常见解法回答胡编乱造检索没返回相关片段单独跑检索确认相关片段是否在 result 中调切分粒度、换 embedding、提高 top_k输出 JSON 格式错误指令遵循不稳定检查是否被 Markdown 包裹加输出校验 纠错循环最多循环三次回答一致但答案偏老上下文里没有最新数据检查知识库是否及时更新增加知识库刷新机制按版本管理数据请求大量超时模型接口限流看错误码是 429 还是 5xx加退避重试、消息队列削峰、限流成本快速上涨Prompt 过长或重复调用打印实际 token 用量缓存高频请求、精简检索片段、降温度参数模型版本更新后效果变差新模型行为不一致对比新旧版本日志走灰度发布保留旧版本回滚通道这张表不是万能药但它覆盖了我见过的 80% 新手上线事故。你按这个顺序排查多数问题能在几分钟内定位到具体环节而不是在系统里乱试。5. 实操总结与升级扩展5.1 写在最后AI 工程是“持续优化的手艺”如果你一路读到这应该已经意识到所谓的 ai-engineering-from-scratch根本不是学一个框架、抄一份代码就能搞定的。它是一门“持续优化的手艺”——每一环都是细节每一环都可能出问题但每一环也都有迹可循。我个人在实操中最深的体会是AI 工程的核心能力不是“会调最好的模型”而是“能在一个系统里让模型稳定地发挥价值”。这需要你把数据、模型、评测三根线牢牢攥在手里每一个决策都有依据每一次改动都有验证。这条路没有捷径但走一遍下来你对 AI 的理解会脱胎换骨——从“会调用”变成“真懂行”。最后再分享一个小技巧从零搭建时务必给整个系统写一份“设计决策记录”ADR把每个关键选择的原因、替代方案、最终决定记下来。三个月后再回看你会惊讶于这份文档的价值——它让你能复述每一个设计的前因后果也让团队协作时有据可依。AI 工程这片海很大但只要方向对、耐心够、够细致你完全可以自己划船到对岸。从今天这份拆解开始动手搭你的第一条最小链路吧——数据、检索、模型、评测、监控、迭代一步一个脚印走完你会看到一个更真实的 AI 世界。
