很多人以为“ai-engineering-from-scratch”是教你怎么从零训练一个模型其实不是。这个标题里的“from scratch”指的是把一个AI应用从想法变成真正能上线、能维护、能迭代的工程系统——不依赖任何现成的“AI一体机”方案也不依赖那种“调个API就完事”的浅层集成。我做AI应用开发这几年最大的感受是demo人人会写但能把一个AI系统从0搭到生产环境、还能稳定跑下去的少之又少。这篇文章就是我对自己完整搭建一套AI工程系统的复盘包含技术选型、架构拆分、实操细节和一堆踩坑记录适合正在做AI应用落地、或者准备从传统后端转AI工程方向的朋友参考。1. 先想清楚AI工程化到底在解决什么问题1.1 重新定义“从零开始”我们得先把“从零开始”这四个字掰开揉碎。如果你理解的从零是“从张量流开始自己写Transformer”那你看错方向了。今天说的从零是不依赖任何封装好的AI应用框架自己动手搭建一套完整的AI系统。什么意思就是你不用LangChain那种大而全的编排工具把一切都“黑盒化”而是自己掌握数据怎么进、模型怎么调、检索怎么做、上下文怎么拼、结果怎么评估。这个“从零”的价值在于你对系统的每一层都有掌控力出了问题你知道去哪里排查而不是对着框架的堆栈报错发呆。我见过太多团队犯同一个错误项目一开始就追求“接入大模型”Demo第一版三天就出来了老板看了很满意然后一到生产环境就翻车。翻车的原因从来不是模型不够聪明而是数据没洗干净、上下文拼接策略不对、检索召回质量差、没有评估手段、成本完全失控。这些问题恰恰是“AI工程”这个title真正要解决的。1.2 AI工程师和算法工程师、后端工程师的区别在哪现在业界对“AI工程师”的定义其实很模糊。很多团队招的是“调包侠”有的招的是“训练师”但真正有价值的是能横跨两端的复合角色。算法工程师关心模型效果——准确率、召回率、loss曲线他们不关心线上QPS和成本后端工程师关心系统稳定性——延迟、并发、缓存但他们对模型推理细节一窍不通。AI工程师恰恰要补齐中间这段真空地带懂一点模型原理能选对模型懂一点系统架构能设计服务懂一点数据工程能把非结构化数据变成模型可用的输入懂一点产品思维知道用户真正需要什么。从scratch做AI工程本质上就是在逼自己补齐这套“端到端”的能力。因为没有任何框架帮你兜底每一步都得自己决策每个决策背后都有取舍。这个过程很痛苦但收获也是成倍的。1.3 一套完整的AI系统到底包含哪些层我在动手之前先把整个系统拆成了几个层面。没有这个拆解后面所有工作都会变成一团乱麻数据层源数据接入、清洗、格式化、切分、向量化、存储。这是金字塔的底座也是决定天花板的地方。模型层选什么模型、用什么量化方式、跑在什么推理框架上、部署在哪里。推理层并发策略、批处理策略、缓存策略、容错策略。这块是很多人忽视的重灾区。应用层上下文编排、Prompt组装、工具调用Function Calling、业务逻辑嵌入。可观测层日志、指标、成本追踪、评估、数据回流。这五层是递进关系每一层都依赖前一层而且每一层都有独立的优化空间。后面我会按照这个分层逐一展开我的实现细节。2. 技术选型与架构设计不追新只追稳2.1 顶层架构的三个原则我做技术选型时给自己定了三条铁律每条都是拿真金白银的教训换来的。第一标准协议优先。所有组件之间的通信尽量走HTTP/OpenAI兼容接口不走私有协议。原因很简单模型要换框架要换但OpenAI兼容协议在整个行业已经成了“事实标准”换哪个环节都不需要动其他环节。我见过深刻教训某团队用了某个私有化的模型服务SDK结果换模型时所有业务代码都要重写痛苦不堪。第二组件可替换。数据存储、向量库、推理引擎这些都要求可以独立替换。你永远不知道半年后会出现什么更好的方案如果被某个组件绑架升级成本会让你绝望。第三能开源不商用。不是说商业产品不好而是AI这个领域迭代太快闭源产品很容易跟不上节奏出了问题你连源码都看不到。开源方案至少可以自己改、自己排查。2.2 模型选型的核心思路选模型不是选最聪明的而是选最合适的。我整理了一个模型选型对比表基本能覆盖大多数场景场景推荐路线原因通用聊天/写作中等体积开源模型7B-14B量化后部署效果够用成本可控数据可控复杂逻辑推理/代码闭源或大参数商用API推理能力确实有差距自己部署成本太高私有化数据问答开源embedding RAG 中规模LLM数据不出内网检索兜底准确率高并发低延迟场景小模型1.5B-4B 蒸馏/微调吞吐优先效果靠数据弥补这个表背后有个重要逻辑能用检索解决的不要指望模型记忆能用小模型的不要上大模型。我做过一个文档问答项目一开始图省事把整篇文档都塞进Prompt用14B模型跑效果差还贵。后来改成RAG架构用7B模型加一个不错的embedding准确率反而上去了成本降了六成。这个案例后面会细说。2.3 量化方案怎么选GGUF、AWQ还是GPTQ量化是本地部署绕不开的话题。群里经常有人问“为什么同一个模型别人跑得比我快为什么我显存老是不够”——多半是量化方式没选对。先看一张对比表量化方式格式优点缺点适用场景GGUF Q4_K_MGGUF兼容性好llama.cpp生态CPU推理表现一般个人电脑、低资源环境AWQ4bit推理速度快显存占用低需要专门内核支持高并发在线服务GPTQ4bit/8bit成熟稳定生态完善显存占用略高于AWQ大多数GPU部署场景FP8原生精度损失极小仅限新卡支持有H100/L40S等高端的用户我的经验是线上服务优先AWQ自用和内部工具选GGUF追求精度就FP8。很多人为了省显存盲目选低精度量化结果模型效果崩了又开始怀疑是Prompt问题——排查半天最后发现是量化精度背锅。2.4 推理框架的选择vLLM还是TGI还是SGLang推理框架现在主流就是vLLM、TGIText Generation Inference和SGLang三个。我之前一直用vLLM后来在某个高并发场景对比过一次。结论是vLLM的兼容性最好、社区最活跃、坑最少SGLang在复杂推理场景下调度更优但生态还不够成熟TGI适合对Hugging Face生态依赖很重的团队。我现在的默认选项是vLLM。它最核心的两个优势是PagedAttention分页注意力和Continuous Batching连续批处理。前者解决了显存碎片问题后者大幅提高了GPU利用率。实测一个7B模型裸跑单并发可能只能到30 tokens/s但用vLLM开连续批处理后并发32路还能维持在单路20 tokens/s以上整体吞吐直接翻了几十倍。注意vLLM对模型格式有要求一般要转成AWQ或FP16的格式。GGUF格式需要转换后才能用不要直接在vLLM里跑GGUF文件。3. 核心实操从零搭一个可用的RAG问答系统3.1 为什么第一步不是模型而是数据我见过最典型的新手错误项目一开始就去部署模型模型跑起来了才想起来“我的数据在哪”。等数据来了发现质量参差不齐、格式五花八门清洗就干了两个星期。所以我的建议是搞AI应用先把数据管道打通。一个RAG系统能取得好效果数据质量占七成模型能力占三成。数据流程简单拆解如下数据接入确定数据源类型PDF、Word、HTML、数据库、API写统一的接入器。清洗与标准化去重、去噪、纠错、统一编码格式。这一步千万别省脏数据进向量库后面检索全是坑。结构化解析把PDF的表格、页眉页脚剥离掉保留正文核心内容。我推荐用PyMuPDF加自定义规则来做比现成的库更可控。切分按语义边界切分控制每个chunk在200-500字之间带50-100字重叠。向量化与入库选择embedding模型把chunk变成向量存入向量数据库。我之前踩过一个坑某份PDF扫描件直接塞进去之后检索结果全乱。排查发现是OCR质量太差模型把表格和正文混在一起了。后来加了一步“版面分析”先识别标题、正文、表格、图片再分别处理效果立竿见影。3.2 切分策略的细节不是切得越碎越好很多人以为RAG就是把文档切成小块扔进去。大错特错。切分粒度直接决定检索质量这个参数必须根据你的文档类型和数据特点来调。我用的切分策略是**“结构优先 语义补充”**有标题结构的文档Markdown、HTML、排版规范的PDF先按标题层级切同一小节的内容尽量完整保留一个chunk。无标题结构的文档用递归字符切分器按段落边界切设置overlap重叠200字符左右防止语义断流。表格数据单独处理保留表头信息避免切碎后“不知所谓”。这里给出一个推荐起点参数表参数推荐值说明chunk_size300-500字符中文场景可按此基准过小丢语义过大难精准chunk_overlap50-100字符保证相邻chunk语义连续检索返回数量top_k 4-6太少可能漏答案太多引入噪声embedding模型维度768-1536高维度准但慢需权衡切分完之后一定要抽样检查千万别直接批量入库。我每个项目都会随机抽几十个chunk人工看一遍看有没有断句、乱码、重复、错切。这个习惯救了我很多次。3.3 检索链路不要只用向量相似度检索光靠向量相似度检索的RAG到了生产环境基本都会“翻车”。原因是向量检索只考虑语义相似不考虑关键词精确匹配、不考虑文档结构权重、不考虑结果之间的去重。我的实践是**“混合检索 重排序”**第一路向量检索召回语义相近的内容。第二路BM25关键词检索召回包含关键术语的文档。两路结果合并送入重排序模型Reranker打分取top_k进Prompt。整个链路我画不出来图但逻辑可以这么理解向量检索负责“找相似的”关键词检索负责“找包含的”Reranker负责“最后判断哪个是对的”。三管齐下准确率相比纯向量检索能提升20%-30%。我实测过一个数据纯向量检索的命中率大约67%加了混合检索和Reranker之后提升到89%提升明显。3.4 Prompt拼接的工程细节上下文不是越长越好Prompt怎么拼这里面的门道非常多。最核心的一条是上下文越长模型注意力越分散回答越容易跑偏。我见过有人一次性把20个chunk全塞进去模型回答的质量反而不如只塞5个。我常用的拼接模板大致如下系统Prompt定义角色、任务边界、输出格式约束。检索上下文按相关度排序的chunk每个chunk前面加一个标识来源的标签。用户问题确保用户问题独立成段不要被上下文淹没。输出约束如果要求格式化输出这里给出明确的格式模板。这里有个细节很多人忽略相关度最高的chunk要放在中间偏前的位置而不是放在最后。因为模型对开头和结尾的记忆最强中间部分是“遗忘重灾区”。你把最核心的事实放中间很可能被模型忽略。我是做了好几轮对比实验才发现的这个规律亲测有效。3.5 成本估算你会为盲目上大模型买单成本这部分很多人算的是糊涂账。我给你一个可以直接套用的公式单次请求成本 输入token数 × 输入单价 输出token数 × 输出单价举个例子假设用某商用模型的API输入每百万token 20元输出每百万token 60元。一个典型的RAG请求输入大约2000 token上下文问题输出大约500 token。算下来单次成本约输入2000 / 1,000,000 × 20 0.04元输出500 / 1,000,000 × 60 0.03元单次总计约0.07元一天一万次请求就是700元。一个月就是2.1万。但如果把输入压缩到800 token、输出控制在200 token单次成本直接降到0.03元以下一个月能省接近六成。Prompt瘦身不是追求美观是实打实地省钱。自己部署模型则是另一笔账。以7B模型FP16为例显存需求 ≈ 参数量 × 精度字节数 7B × 2字节 ≈ 14GB加上KV Cache和中间激活值实际需要20GB以上显存。一张24GB的4090刚好能跑。算算电费、服务器折旧、人力维护成本如果日请求量低于1万其实用API更划算。我的建议是低于一定规模别自建这是用钱买时间。4. 常见故障与排查技巧实录4.1 模型“失忆”不读上下文位置偏差问题这是我最常被问到的问题“我明明在Prompt里放了答案为什么模型就是不用”有次排查了一个下午最后发现是两个原因叠加一是相关chunk被排到了Prompt中间偏后模型根本没“读到”二是Prompt总长度超过了6000 token模型对中段内容的注意力急剧下降。排查思路分三步。先看检索返回的顺序确认高相关chunk在前面再看Prompt总长度超长就做摘要或截断最后测试把关键信息手动放到Prompt开头和结尾对比模型回答。这个“大海捞针”测试法是我每次调试RAG的必做动作把答案藏在Prompt的不同位置看模型能不能每次抓得住。4.2 检索空结果或召回劣质的处理套路RAG系统检索不到相关内容不是模型问题是数据管道问题。常见原因就三个切分粒度不当导致语义丢失、embedding模型与领域数据不匹配、向量库里的脏数据干扰了相似度计算。我的排查顺序是首先抽样看向量库中的chunk内容是不是干净完整其次跑一遍单个文档的端到端检索测试定位是切分还是向量化环节出错最后换一个embedding模型做对比实验。embedding模型这一环非常关键我之前在一个医疗文档项目里通用embedding召回率只有51%换成领域微调的embedding后直接升到78%。选embedding模型不能只看排行榜要拿自己的数据测。4.3 GPU显存OOM不是加显存就完事本地跑模型最常见就是OOM。我的经验是分三步排查看模型本身占了多少显存用nvidia-smi看进程占用筛选显存大头。看KV Cache占了多少并发越高KV Cache越大。vLLM可以通过--max-num-seqs限制最大并发数也可以设置--gpu-memory-utilization预留空间。看推理框架的开销有些框架默认会预分配很大比例显存导致其他进程没得用。我推荐一个非常实用的预估公式以7B、FP16、2048长度、8并发为例KV Cache每token字节数 ≈ 2K和V × 2字节 × 层数 × 注意力头数 × 头维度一个7B模型大约32层、32个注意力头、头维度128单条请求2048 token的KV Cache约2 × 2 × 32 × 32 × 128 × 2048 / 1024³ ≈ 0.5GB8并发就是4GB。加上模型权重14GB一共约18GB。如果你只有一张16GB的卡就必须开量化、限制并发或者缩短输入长度否则必炸。4.4 幻觉问题期望模型“不胡说”的觉悟幻觉是LLM的“原罪”你不可能让模型完全不说错话但可以从工程上限制胡说八道的空间。我的实践是三层防御。第一层Prompt明确指令“如果上下文中没有信息回答‘资料未提及’”。这能挡住大部分无中生有。第二层RAG检索到的信息如果相关度太低宁可拒绝回答也不要硬凑。我给检索结果设了个相关度阈值低于阈值的chunk不进入Prompt。第三层文档来源带引用标注让输出结果可溯源。这三点加起来能压制大部分幻觉但说实话不可能根除。4.5 性能瓶颈定位与优化顺序系统上线后发现延迟高、吞吐低很多人第一反应是换更贵的GPU。但在AI系统里性能瓶颈往往不在GPU上。我优化系统的顺序固定如下先看数据层向量检索是不是全表扫描有没有索引数据量涨了没再看推理层有没有开连续批处理KV Cache有没有复用并发限制设对了吗再看应用层你的Prompt是不是无意义的在变长有没有做缓存最后看基础设施网络、磁盘IO、中间件有没有瓶颈。按这个顺序90%的性能问题在第三层之前就能解决。我优化过的一个项目最初P95延迟2.8秒单纯靠加Prompt缓存和优化检索索引就把P95压到了0.9秒完全没碰模型和GPU。5. 可观测性与评估闭环没有度量就没有优化5.1 日志和指标要打到什么颗粒度评估是AI工程里最反人性但也最值钱的一环。没有评估你优化Prompt全靠“感觉变好了”这是拿项目在赌博。我搭建了一套最小可行的评估体系观测维度指标采集方式成本每次请求token数、token单价、总成本网关侧统计性能P50/P95延迟、QPS、吞吐链路追踪质量回答相关性、忠实度、检索命中定期人工抽样自动评分稳定性模型报错率、超时率、降级次数监控报警每次Prompt改动都要跑同一批测试集做对比记录分数变化。没有这个过程你就是在黑箱里优化。5.2 自动评估与线上数据的闭环回流评估不一定要全靠人工。我建议跑一个自动评估流水线准备几百条测试问题每次版本发布前自动跑一遍用大模型当裁判给回答打分忠实度、相关性、完整性三项再和基线对比。虽然模型打分不完全等于人感但对于捕捉明显的退化已经够用。更重要的闭环是把线上真实问答数据捞回来定期补充进测试集。用户实际在问什么模型答得怎么样这些数据是评估体系的灵魂。没有线上数据回流的评估系统永远是在“用假想题测真系统”偏差很大。我在每个项目里都会搭一个简单的“误反馈回流表”用户点了“没有帮助”的问答进列表定期人工分析把典型bad case补充到测试集。这个动作看起来费劲但对系统提升的帮助非常大。6. 从零到一的工程落地清单写到这里我把一套AI工程系统的最小落地清单整理在下面。照着这个清单走基本上能避开大多数坑数据层统一接入器、清洗脚本、切分策略、向量化任务、数据质量校验模型层选型报告、量化方案、推理框架部署、压测应用层Prompt版本管理、检索编排、重排序链路、工具调用可观测层日志、指标、成本报表、bad case回流评估层测试集、自动评测脚本、版本对比报告、人工复核流程这六块缺一不可但每块的投入比例可以按项目阶段动态调整。冷启动阶段重点砸数据管道模型和框架先用最稳妥的跑通之后重点砸评估和可观测因为这时你才有资格谈优化。我自己做了这么多AI项目之后最大的心得就一句话AI工程的成功不在于你用了多先进的模型而在于你把基础环节做得有多扎实。数据、检索、评测、成本这四个看似不起眼的环节恰恰决定了系统的真实水平。很多人迷信“大模型能力”把项目失败归咎于模型不够聪明——其实大多数时候问题出在你自己这侧的工程细节。最后分享一个小习惯我每次启动一个新的AI项目都会先花半天时间把“从数据输入到答案输出”的完整链路画在纸上。别小看这张图它能帮你一次性想清楚所有组件间的依赖关系避免后面反复返工。你从零开始搭AI系统时也可以先试试这个笨办法。