看到“ai-engineering-from-scratch”这个标题我第一反应不是去看它是不是又一个仓库名或者课程名而是觉得这个词组值得认真拆开说。AI工程这个词被讨论了很多年但真正能讲清楚“从零怎么入手”的内容并不多。市面上大多数教程要么让你直接套LangChain模板要么抛一堆数学公式把人劝退真正能让你从零搭出一个“能跑、可控、有边界”的AI系统的路径反而很少被完整讲透。这篇文章我想用最近带团队做的知识库问答项目作主线把AI工程从零开始这件事掰开揉碎。主要是给三类人看想要转型做AI应用开发的程序员、刚入门但被各种概念绕晕的初学者以及在业务里需要把大模型能力落地的技术负责人。文章里不会堆玄乎的概念每一步都有对应的实现方案、参数选择逻辑和踩坑记录你可以直接照着搭。1. AI工程到底要会什么先把这个概念拆明白1.1 很多人把AI工程和“调模型”混为一谈我见过太多人把AI工程理解成“会用大模型API”或者“会写提示词”。这种理解不能说全错但偏差很大。调API只是整个AI工程里最表层的动作真正决定一个AI系统能不能稳定用的是周围那圈不那么性感的东西数据怎么清洗、请求怎么设计、结果怎么评测、错误怎么追踪、成本怎么控制。如果拿造房子来类比调模型相当于搬砖砌墙AI工程则是从地基到水电暖通的全盘设计。你光会砌砖造出来的房子可能能住但一定经不起台风。做AI应用也一样光会调用模型接口做出来的东西 demo 跑得通一上真实流量就各种翻车。这个项目标题里的“from-scratch”在我看来有两层意思。第一层是“零基础入门”即没有算法背景的工程师也能走通这条路第二层是“不依赖全套现成框架”即你最好先理解底层原理再决定要不要用LangChain这类工具。真正可靠的AI工程能力恰恰是在这两层同时下功夫。1.2 四条能力支柱缺一不可我在实际带项目时会把AI工程拆成四块能力工程能力、数据能力、模型落地能力、评测能力。工程能力指常规后端开发比如接口设计、并发处理、部署监控这是AI系统的骨架。数据能力指知道怎么把原始文本清洗成适合喂给模型的结构化数据包括去重、分块、格式统一。模型落地能力不是让你去训练模型而是懂得做模型选型、参数调优、上下文窗口管理、提示词结构。评测能力可能是最容易被忽视的一块。很多团队上线AI功能之前只靠几个人手动点点说“感觉还行”然后就被用户投诉淹没。专业的做法是提前设计离线评测集、定义指标、做回归测试让每一次模型或提示词改动都有量化依据。这四条支柱中如果只能选一条优先建立我会毫不犹豫推荐“工程能力”。因为工程能力是杠杆它能放大你所有其他能力。一个能把系统架构写得清晰的人即使模型选型不是最优也有足够多的迭代空间去修正反过来一个只会调API但系统一崩就束手无策的人天花板会很低。1.3 从零开始的正确顺序很多初学者会犯同一个错误一上来就钻研大模型原理把“注意力机制”推导了大半个月然后用一个简单的API demo感动自己。这不是从零开始这是绕远路。我建议的顺序是反过来的。第一步先把端到端的小系统跑通哪怕只是一个命令行工具输入一段文字能返回一段答案也行。第二步回到工程的细节把数据、接口、部署这些环节逐一加固。第三步再回头看模型本身理解为什么有些检索策略有效为什么某些提示词结构更稳定。第四步才是系统化学习算法理论这时候你有了大量感性认识再学原理会快得多。这种“先跑通再理解”的路径对工程师出身的人尤其适用。因为你有工程经验打底很多概念一对照就能明白。先说结论AI工程从零开始不是一条笔直的上山路线而是一条不断绕弯又不断拉直的过程。2. 从零搭建知识库问答助手核心设计拆解2.1 为什么拿知识库问答当练手项目要真正理解AI工程你得选一个能覆盖全流程的项目。我强烈推荐“本地知识库问答助手”——你有一堆文档比如产品手册、历史工单、技术规范系统能根据用户问题自动从文档里找相关信息再用大模型组织成自然语言回答。这个项目覆盖了AI工程的全部核心环节数据准备、检索、生成、评测、部署、迭代。同时它又不至于复杂到一个人搞不定。它不给大模型“喂”全部文档而是在每次回答前先从知识库里检索出相关资料再让模型基于资料作答。这样能有效减少幻觉也不用担心文档太多塞不进模型上下文。选这个项目的另一个原因是效果好量化。你很清楚一个回答有没有引用到正确的文档片段这让后续评测和优化有了明确方向。相比做一个天马行空的聊天机器人知识库问答是工程味最重的AI项目也是最接近企业真实需求的项目。2.2 数据准备被低估的关键环节很多人以为知识库问答的核心是模型实际上我做了几个项目之后发现数据准备的工作量至少占40%。你拿到的原始文档几乎不可能直接用。格式千奇百怪有的是PDF有的是Word有的甚至是从网页复制下来的带样式文本。第一道工序就是把它们统一转成干净的纯文本这一步决定了后续所有环节的质量。然后是去重。企业内部文档经常有多个版本同一个产品描述出现在三五个文件里措辞略有差异。如果不做去重检索结果会集中命中其中某一版导致答案不完整或者过时。我会用simhash或者向量余弦相似度做一次粗筛把相似度超过阈值比如0.9的内容标记出来人工确认。关键动作是文本分块。大模型对输入长度有限制而且也不是把所有文档一股脑塞进去就能得到好效果。分块策略要按语义边界来不能死板地按字符数切。我常用的做法是先把文档按标题和段落拆成“语义块”再对特别长的块细分每块控制在300到500字左右。如果语境是技术文档可以适当放宽到800字如果是碎片化的工单记录200字一档更合适。分块之间的衔接也很重要我会让相邻块有10%左右的重叠避免信息被拦腰截断。2.3 检索模块向量检索为主关键词检索兜底知识库问答里有一个行业共识检索质量决定回答质量上限。就算模型再聪明如果检索回来的资料跟问题不相关它也只能一本正经地胡说八道。所以我把检索模块当作核心来设计。第一步是把文本块转成向量。嵌入模型我常用bge-m3这类中文表现稳定的模型也可以用OpenAI的text-embedding-3-small。选型时主要看三点中文语义理解能力、向量维度、单条文本长度上限。bge-m3支持8192字符并且是多语言模型对中文文档特别友好。向量维度相对较高但换来的是更细腻的语义表达。向量检索的原理不复杂你把用户问题也转成向量然后在数据库里找跟它方向最接近的那些向量。我会用pgvector做存储和检索因为项目里已经有PostgreSQL了加一个扩展就能用不用额外维护一套新系统。也可以用Chroma或者Milvus但我的建议是如果你的文档规模没到百万级pgvector完全够用别再引入一个重型组件。纯向量检索有个毛病它比较擅长“语义相近”的召回但在精确匹配关键词的场景下会失手。比如产品型号“XG-200”向量检索可能返回一堆含义相关但没有这个确切型号的文档。我的做法是再加一路传统的BM25关键词检索然后把两路结果用RFF算法做融合排序。实测下来这个混合检索方案能把最终回答的准确率提升差不多20个百分点而且没有明显的代价。2.4 生成模块提示词结构比想象中重要检索拿到候选文本后接下来就是生成回答。生成这一步的核心工程问题是如何把“检索到的资料”和“大模型的生成能力”结合起来。直接说一句“根据以下资料回答问题”是不够的我在项目里用的提示词结构包括角色定位、任务约束、引用要求、无法回答时的兜底话术。提示词模板大概长这样你是一个客服助手。请仅根据以下资料回答用户问题。如果资料中找不到答案请直接说“知识库中暂无相关信息”不要编造。回答时引用资料编号例如[1][2]。 参考资料 [1] {文本块1} [2] {文本块2} 用户问题{question}不要小看这段话里的每个约束。“仅根据资料回答”限制了模型自由发挥的倾向“不要编造”是在做行为约束要求引用编号则让回答变得可追溯。加上这些约束之后回答质量会稳定很多尤其是遇到知识库里没有答案的问题时模型会更倾向于诚实地说不知道而不是硬造一个答案。模型参数也不能随意。我会把temperature设为0.2左右让回答更保守、更贴近资料原文。如果目标是创意型写作可以把temperature拉高到0.8但知识库问答这个场景不需要创造力稳定优先。max_tokens要根据回答长度设合理上限防止模型在长回答里越写越偏。这里补充一点每次生成时是需要计算prompt和回复的tokens的成本大头往往在检索回来的文本块太多上适当控制参考资料数量能省不少钱。2.5 评测先行上线前的必要动作我在前面说过评测能力是四根支柱之一这里展开讲。许多AI项目翻车的根本原因不是技术选型错了而是上线前没有评测机制。评测分两层离线评测和在线验证。离线评测用一批人工标注过的问题跑系统得到答案再跟标准答案对比。召回阶段看的是RecallK和MRR生成阶段看的是忠实度和完整性常需要人工打分也可以用大模型当裁判做初筛。我会准备至少50条有代表性的测试问题覆盖高频场景、边界场景和刁钻场景。比如知识库里存在但表述很绕的问题以及知识库完全没覆盖的问题。前者的作用是检验“找得准不准”后者的作用是检验“会不会乱说”。评测集建好之后每一次修改都要重新跑一遍防止优化一个问题却搞砸另一个功能。在线验证同样必要。离线指标再好看也跟真实用户的输入习惯有差距。我的做法是上线后先小范围内测仔细观察用户日志里“检索不到内容”和“用户重新提问”的比例。如果这两个指标偏高说明离线评测集还不够贴近真实场景需要往里补充新的问题样本。3. 把系统真正跑起来接口、部署与成本控制3.1 用FastAPI封装服务接口前面全是准备工作真正让系统变成可用产品的是接一层服务接口。我用FastAPI写HTTP服务原因无他类型校验简单、自带文档页面、异步支持顺手。接口设计保持两个端点就好一个接收查询请求返回答案另一个上报系统健康状态。接口层面最容易被忽略的是超时和错误处理。大模型API有时候会变慢甚至超时你不能让用户请求无限等下去。所以我会给每个环节设置明确的超时时间向量检索最多800毫秒模型生成最多15秒整体接口在20秒内必须返回。如果某个环节超时接口返回一个友好提示同时把错误日志打到追踪系统里。另外一个重要的工程习惯是给每个请求分配一个trace_id从头到尾记录这次请求的检索结果、中间耗时、模型消耗的token数。这样当用户反馈回答不对时你能凭trace_id快速定位到是检索阶段出了问题还是生成阶段出了问题。这个习惯在排查线上问题的时候能帮你节省大量时间。3.2 Docker部署与资源隔离我到现在还记得第一次部署AI应用时被依赖问题折磨的体验。Python环境、系统库、模型文件、CUDA版本哪个环节差一点都跑不起来。后来我彻底改用Docker把整个服务封装成镜像一次性解决环境一致性问题。Dockerfile核心结构很简单用python:3.10-slim做基础镜像安装依赖、拷贝代码、暴露8080端口。向量数据库如果用的是pgvector可以在docker-compose里一并起起来挂载一个volume做持久化。值得注意的是如果你的嵌入模型比较大镜像体积会很可观记得用模型分析工具裁剪无用依赖不要把整个PyTorch都打进去。我还习惯在容器里加入健康检查机制比如提供一个/api/ping接口让编排系统定时探测。同时把日志打到控制台由日志收集服务统一采集。这些操作乍看平凡但真正面对多实例部署或者服务升级时它们能让你少掉不少头发。3.3 成本估算别让账单吓到自己做AI工程的人如果不会估算成本迟早会被财务部门约谈。成本主要由三块构成嵌入模型调用费、大模型生成费、基础设施费用。嵌入成本相对低按字符数算生成成本跟输入输出token数强相关基础设施主要是服务器和向量库的占用。我做一个粗略的成本估算表供参考以中小规模知识库为例项目估算方式示例数值备注文档嵌入每千字符0.03元10万字文档约30元一次性成本后续新增少量向量库存储按实例内存pgvector在2GB内存实例上约几百元/月与文档量相关大模型生成按token计费每次问答约1500输入200输出token单次约0.03元1000次问答约30元服务器按实例配置2核4G约200元/月可用轻量云承载这组数值只是示例不同供应商定价差别很大但可以看出一个规律日常运行成本的大头是大模型生成调用而不是存储和嵌入。所以优化成本的首要手段是让检索结果更精准减少不必要的模型长回复。另外可以用一层缓存把高频问题连同回答存进Redis命中缓存直接返回不经过模型实测能把成本降下来30%以上。4. 真实项目里最常踩的坑排查与经验4.1 检索结果差先查数据而不是模型做知识库问答最容易犯的错是一遇到“回答不对”就怀疑模型能力然后疯狂改提示词。但根据我的统计绝大多数bad case的问题出在检索环节。你会看到模型引用了不相关的文档片段这不是模型不聪明是因为检索模块只找到了这些片段模型没有别的选择。排查思路很清晰用trace_id调出那次请求的实际检索结果看走了哪些文本块。如果Top3的文本块跟问题没有直接关系问题在检索侧。接着看是向量检索召回了错误内容还是关键词检索带偏了排序。如果是向量检索的问题先回头检查分块是否合理、嵌入模型是否选对如果是关键词检索的问题调整BM25参数或者给某些专业词加权重。一个很经典的案例有一回我们把某产品故障手册分成每块200字结果所有含有“故障代码”字样的块都被频繁召回但其中很多块只提到代码没有实际解决方案。后来重新按故障现象重新组织语义块把“现象描述”和“解决方案”绑定放在同一个块里召回的准确率一下就上来了。这个教训让我意识到分块不只是技术操作它本身就是对业务知识的重新梳理。4.2 幻觉问题靠约束和引用不靠模型换挡大模型的幻觉是所有生成式应用的通病知识库问答的优势在于你能用约束把幻觉压到最低。我给团队的硬性要求是回答必须带引用编号哪个资料块支撑了这句话必须标注出来。如果某个回答没办法给出引用说明它在编造系统会直接拦截。除了引用约束还可以在推理层面加一道校验。我习惯把检索到的文本块和生成结果做一次相关性比对如果模型在回答里出现了参考资料中完全没有的概念触发一次“重新生成”次数限制后仍然不一致就把这个回答判为可疑。这个方法不保证100%过滤幻觉但能显著降低它出现的频率。另外要特别注意模型版本升级带来的行为漂移。有时候你什么都没改只是模型供应商悄悄换了版本回答风格和质量就会变化。所以每次模型供应商发更新公告我都会跑一遍评测集确认没有回退。4.3 延迟忽高忽低缓存、并发与熔断AI系统有一个特性跟传统接口不一样单次请求的耗时波动很大。高峰期大模型服务拥挤延迟可能是平时的两到三倍。如果不对接口做保护一个慢请求会占用线程池引发连锁崩溃。我的防护策略是三层。第一层是Redis缓存高频问题和标准答案直接短路。第二层是并发限制用信号量控制同时输送给模型的最大请求数超出部分排队进入缓冲池。第三层是熔断如果连续多个请求超时或返回错误自动切换到备用回答策略比如只返回检索结果而不做生成保证用户至少有东西可用。这些策略写起来不难难的是提前想到并落地。很多团队是线上出事故了才回来补这些能力而我更希望大家在第一版就把它们设计进去。工程化的本质就是应对不确定性AI工程的不确定性更大所以更需要这些保护机制。4.4 一个排查速查表我把常见问题整理成一张速查表贴在团队内部文档里每次排查问题时先对照一遍常见现象可能原因排查动作修复建议回答内容与资料矛盾检索召回错误文本块查看trace_id记录调整分块与重排逻辑回答含编造成分提示词约束不足检查生成prompt增加引用与“不知道”约束接口响应慢模型调用排队看耗时分布加缓存与并发限制成本突然飙升上下文塞入过多文本查token使用日志限制参考资料数量同问题结果不稳定模型参数随机性跑多组测试调低temperature新文档未被检索到嵌入流程未覆盖新文档检查数据管道增加增量索引任务这张表背后的核心思想是任何AI系统问题都不是“神秘莫测”的它一定有具体的出错环节。把错误定位到环节修复就是顺理成章的事。5. 学习路径与进阶路线从最小系统到真正可交付5.1 少而精的资料库不用贪多很多初学者最喜欢的动作是收藏一堆教程然后一样都没看完。我推荐的路线是少而精把几份核心材料吃透就足够了。Python基础可以快速过一遍FastAPI官方文档认真读一遍检索模型和重排序的原理选一篇经典文章精读。真正的学习发生在项目里不在资料库里。大模型API文档是必读的。不管用哪家的模型它的API文档里关于上下文窗口、参数含义、速率限制都写得明明白白。我发现一个规律能独立读完API文档的人基本上不会被“不会用模型”这个问题卡住。很多看起来复杂的AI问题其实只是对API的能力边界不够了解。至于LangChain这类框架我的建议是先不用你手写一个20行的RAG调用逻辑对全流程有了体感之后再去看框架就觉得处处都好理解了。框架能把封装变简单但也会把问题变黑盒。先理解黑盒内部发生了什么才是真正的“from-scratch”。5.2 做项目驱动的学习节奏我建议每个阶段都给自己设一个交付物不要只停留在“看懂”层面。第一个交付物可以是一个200行以内的问答脚本第二个交付物加一个HTTP接口第三个交付物加上向量数据库和评测集第四个交付物完成Docker部署。每完成一个交付物你就越接近一个真正可交付的AI系统。这个节奏的好处是让学习成果变得可感知。你不需要问自己“我学得怎么样了”看交付物就知道。同时每个阶段都有验证点接口能不能调通检索准确率是不是在涨部署后稳定性如何这些验证点本身就是最好的老师。5.3 之后的进阶方向走完这条从零到一的路线你已经有能力交付一个中规中矩的AI应用。接下来可以根据业务场景继续往深走。如果知识库经常遇到多轮追问的场景深入学习Agent和多轮对话管理如果对离线响应速度有要求研究如何把模型量化后本地部署如果文档量持续膨胀研究更复杂的RAG优化方案。其他值得关注的方向包括把非结构化数据源从纯文本扩展到表格和图片给系统增加可观测性和主动告警把评测集扩展到自动化水平形成一套持续评估流水线。这些方向最终指向同一个目标把AI系统从一个“能动的demo”变成一个“可靠的业务组件”。6. 写在最后一些个人实操体会我做过不少AI项目也看了很多团队在这个领域的起落。最大的感受是步子别迈太大系统的可靠性永远比模型的聪明程度更重要。用户对AI的耐心比对传统软件的耐心低得多一次胡说八道就可能让整个团队几个月的心血被贴上“不靠谱”标签。所以“不知道就说不知道”这句话不只是提示词里的约束更应该是整个系统的设计原则。还有一个容易被忽略的点AI工程不是一个人的事情。即使你个人能力很强也要学会把数据准备、评测迭代、成本分析这些环节跟业务方对齐。技术团队知道“检索准确率”是什么意思业务方更关心“用户问题被正确解决的比例”。一开始就学会用业务语言解释技术指标能让项目推进顺畅很多。最后分享一个我自己的小习惯每次遇到难以解释的bad case我会把问题和系统给出的回答原文抄下来隔天再回看。有些错误当时觉得是模型的问题隔天再看才发现是数据或者评测集的问题。跳出来换个时间窗口审视往往能发现之前看不出的盲区。希望这篇分享能给你一些参考也欢迎在实际搭建中摸索出更适合自己的路径。