很多人问我“AI工程从零开始”到底怎么起步我通常先反问一句你做这个是想成为训练模型的研究型选手还是想把模型真的用起来、跑起来、持续迭代起来如果是后者那你和我现在做的事基本一样都属于AI工程这条路。这几年AI工程这个岗位很微妙很多人把“会调API、会套提示词”当成全部也有人一上来就啃神经网络论文结果学了半年还在原地打转。我的理解是AI工程的核心不是“发明模型”而是“让模型在真实业务里稳定干活”。今天这篇文章不打算给你列一堆课程链接也不做那种“30天精通AI”的唬人承诺我尽量用自己的真实项目经历把“从零开始”这几年踩过的坑、摸索出的路拆开了讲给你听。如果你正准备入行、刚接手AI项目或者想把手头业务跟大模型结合这篇文章会比较对胃口。另外先说明白我这里聊的“从零”不是从高等数学的零开始而是从“能动手、能出结果”的零开始。理论基础当然要补但顺序和方法非常关键顺序搞反了你会学得很痛苦而且看不到成果。1. 先把“AI工程”这个词拆明白1.1 AI工程师和研究员、算法工程师的分工边界在哪很多人看到“AI工程”四个字第一反应是“又要写神经网络了”。实际上AI工程更接近“搬运工装修工监理”的综合体。研究员的工作是探索新模型结构算法工程师的战场是模型训练与调参而AI工程师的核心精力往往花费在数据管道、模型调用的稳定性、推理成本、效果评测和上线后的持续监控上。举个真实例子我之前接过一个任务要把公司十几份产品手册做成内部问答机器人。研究员不需要关心这个问题算法工程师研究的是怎么微调一个开源模型来做这件事而我会优先考虑文档怎么清洗、切片策略怎么定、用哪种向量库、检索回来以后提示词怎么组织、模型推理延迟能不能压到两秒以内、误答了用户投诉怎么办。这个项目最终的瓶颈完全不在模型能力而在检索召回率和稳定性——这正是AI工程要解决的事。还有一层经常被忽视AI工程是连接业务和技术的那层“胶水”。你得能跟业务方聊清楚“什么能做、什么做不到”也得能跟后端同事解释“为什么这个接口偶尔会超时”。所以我的经验是入行第一课学的不是PyTorch而是“搞清楚角色边界”知道自己该在哪层发力。1.2 从零开始真正要练的是这三件事既然角色边界清楚了那从零开始练什么就呼之欲出。我自己的总结是三个能力第一数据获取与处理能力。模型是嘴数据是饭。你给模型吃什么它就只能说什么。清洗数据、格式统一、去重、切分这些活看起来不起眼却决定了项目成败。第二模型调用与集成能力。不管是API接口还是本地模型你得知道怎么稳定地调用、怎么处理超时、怎么做并发控制、怎么降级兜底。第三评估与迭代能力。没有评估就没有迭代方向。你能说出“现在的准确率比上周高了多少”才算真正开始做AI工程。这三件事对应到实操上就是你会反复摸到Python脚本、HTTP接口、JSON结构、日志分析和一点统计学常识。而写模型训练代码反而是阶段性需求不是每天都必须上手。注意这里说的“从零”我默认你至少会基本的Python语法和Linux命令。如果这两样还不熟先花两周补上别急着碰任何AI框架。2. 基础技能怎么补才不跑偏2.1 数学和统计不要恐惧但也不能完全跳过很多人一听AI就想起高等数学、线性代数、概率论吓得直接放弃。我的建议是分阶段学习第一轮不需要达到应试水平只需要“看得懂公式、说得出含义”。比如向量点积你不需要推导它的几何性质但要知道它衡量两个向量的相似程度因为后面所有向量检索都建立在这个概念上。矩阵乘法也一样你不需要手算但要明白它就是把一组特征变换到另一组空间模型的每一层都在做这个事。概率统计比较重要但也不需要啃数理统计教材。重点理解分布、均值、方差、条件概率尤其是贝叶斯思想你对一件事的判断会因为新增证据而更新。模型的“幻觉”问题本质就是一种概率生成过程理解了这种不确定性你就知道为什么模型不能保证每个字都准确为什么要在工程上设计兜底逻辑。我的学习方式是“逆向学习”先看一段代码发现理解不了某个参数再回头补对应的数学概念。比如看到Embedding向量的维度是768就回头理解一下为什么高维空间能表达语义相似性。这样学得快、记得牢。2.2 Python生态和学习路径以项目驱动而非知识点驱动我强烈不建议按“Python基础→Numpy→Pandas→机器学习算法→深度学习”这个顺序一路学到底因为九成的人会在机器学习算法那一步失去动力。换成“项目驱动”会好很多。你可以给自己定一个目标两个月内搭出一个能跑通的知识库问答小系统。围绕这个系统你用Python处理文档、用Pandas清理数据表、用Requests调用接口、用FastAPI写一个应用入口这些技能点都是自己冒出来的学起来效率极高。深度学习框架方面我建议首选PyTorch并不是因为别的框架不好而是它生态最大遇到问题搜索时容易找到答案。入门时别急着训练模型先把“加载一个预训练模型并做推理”跑通再尝试简单的微调。这一步做出来基础模型训练的流程你就走了一遍。至于Transformer结构知道自注意力机制大概在干什么就行不用一开始就手写注意力层。提示环境配置往往是新手第一道墙建议直接装Anaconda管理Python环境每个项目创建独立虚拟环境避免依赖冲突。这个习惯我从入行第一天保持到现在拯救过无数个周末。2.3 一套顺手的工具栈从第一天就养好习惯工欲善其事必先利其器。我推荐的起步工具栈是Git做版本管理Jupyter Notebook做探索分析VS Code做日常开发Docker做环境打包。这四样东西看起来跟AI没什么关系但每一项都能在项目关键节点救你一把。Git不多说了代码回溯、多人协作都离不开。Jupyter Notebook适合做数据分析、调试提示词和对返回结果做可视化诊断它的交互式特性让你能一边跑一边改。VS Code加上Python插件后调试和代码补全体验足够流畅。Docker一开始可能觉得难但我建议尽早接触因为模型依赖非常复杂六个环境变量、三个CUDA版本对不齐是常态。把环境写进Dockerfile里换机器跑的时候能少掉一层皮。除了这些你还需要一个实验管理工具。简单项目用Excel记录就行参数、数据集版本、效果得分写清楚复杂一点可以上MLflow、WandB或者类似工具。没有实验记录你调了三天的参数后会发现完全忘掉了哪组效果最好那种挫败感我体会过太多次。3. 完整实操从零搭一个RAG知识问答系统3.1 任务定义与数据准备纸上谈兵没意思我拿一个真实项目做样板做一个基于公司内部产品文档的知识问答系统。为什么选RAG而非微调主要原因有三个。第一文档内容持续更新微调一次模型成本高而RAG只需要换文档库。第二RAG生成的答案可以引用原文方便用户核对这在内部场景非常重要。第三初期我们并不需要模型具备新的推理能力只需要把已有知识准确提取出来RAG对这种“知识密度高、推理复杂度低”的场景高度匹配。数据准备阶段比想象中花时间。文档格式很杂有Word、PDF、Markdown还有扫描件。我的处理顺序是先统一转成文本再用脚本清洗页面页眉页脚、目录和乱码字符。这里有一个容易被忽视的细节PDF转文本后经常出现断行混乱如果直接切块语义会被破坏检索效果会很差。我的办法是先按段落边界重组文本再做下一步。切块策略上我推荐“标题感知切块”。简单说就是优先保留完整章节把文本按标题层级拆分控制每块在500到1000字之间块之间可以保留少量重叠。这样做的好处是后续检索命中的往往是一个语义完整的片段生成答案时上下文不会东拼西凑。3.2 向量化与检索实现数据准备好以后下一步是把文本块转换成向量。这里有两种思路用商用Embedding服务或本地开源模型。商用服务效果好、省心但涉及外部网络和费用本地模型部署自由、隐私更有保障但效果需要调。我这个项目最终选了本地方案用的是一个中等规模的Embedding模型输出向量维度是1024。切换模型的代价比想象中大因为不同模型的向量维度不一样一旦上线后要换模型整个向量库都得重新生成所以选型时尽量一次到位。向量化之后需要一个存储和检索的介质。数据量只有几万块文本时用FAISS就够了。它跑在内存里检索速度极快。构建索引时就几个步骤把向量喂进去指定相似度度量方式保存索引文件。我自己常用的是点积或余弦相似度具体选哪个看Embedding模型训的时候用的是什么没有绝对优劣。检索环节有一个标准代码之外的技巧叫“混合检索”。仅靠向量检索遇到专有名词、型号编号这类精确匹配场景很容易翻车因为向量相似度讲的是“语义相近”不是“字面相同”。我后来在向量检索之外加了一层BM25关键词检索把两种结果做加权融合。效果立竿见影用户问“XK-200型号的功率是多少”时字面匹配立刻能命中原文。# 简化的混合检索流程 # 1. 向量检索 vector_scores vector_index.search(query_vector, top_k20) # 2. 关键词检索BM25 keyword_scores bm25_index.search(query_text, top_k10) # 3. 结果融合简单加权去重 merged merge_results(vector_scores, keyword_scores, weight(0.7, 0.3))这一步走下来我最大的体会是不要迷信某一个检索方案的宣传效果组合拳远比单点最优靠谱。工程里最终看的是整体命中率而不是某一个环节的完美。3.3 生成链路与提示词设计检索出来的文本块不会自动变成答案需要交给生成模型组织语言。这个环节的关键有两个提示词结构和上下文控制。提示词我用了一段固定的System指令明确告诉模型“你是文档助手只能根据提供的资料回答资料里没有的内容就说不知道不要编造”。这段指令看起来简单但确实能明显降低幻觉比例。控制上下文长度同样很重要。模型输入有Token上限我的策略是检索结果的文本块拼接后按字数截断到模型可接受的输入范围同时保留引用来源。这里有个常被忽略的问题文本块之间的顺序影响模型输出质量。我一般把相关度最高的块放在最后因为部分模型会对输入末尾的内容更敏感这个操作在多次测试中都有正向收益。生成阶段还涉及一个隐蔽问题重复请求。在线问答场景里用户可能会反复问同一类问题。缓存策略可以省很多成本。我的做法是把“规范化后的问题句式检索到的文档块ID列表”作为缓存的Key如果后续命中的文档块没变化就直接复用之前的生成结果。如果文档库更新了就让Key自动失效避免旧答案污染。3.4 评估指标与上线部署效果好不好不能靠拍脑袋。我的评估方法分两层离线评估和在线监控。离线阶段准备一份带标准答案的测试集大概一两百条问题就够覆盖不同来源和问法。然后计算三个指标命中率检索结果是否包含关键信息、答案准确率生成答案和标准答案语义是否一致这里需要人看也可以辅助模型打分、拒绝率模型对未知问题说“不知道”的比例是否合理。这些指标跑完基本能判断系统能不能见人。在线监控又是另一套逻辑。在接口层记录每次请求的检索延迟、生成延迟、Token消耗和返回状态。答案本身的质量在线上不太容易自动化判断可以加一个用户反馈按钮也可以在下游做一个“内容漂移检测”——对比用户问到的问题和答案之间的相关性相关性异常就提醒人复核。部署阶段的标配是FastAPI加Docker。模型服务单独拆成一个进程业务API调它这样如果模型服务崩了业务层还能返回友好提示而不是直接超时。GPU资源的分配我当时很头疼因为推理服务很吃显存但业务API只需要CPU。后来把两部分拆到不同容器配合进程级并发控制才把资源利用理顺。上线之后我每天早晨第一件事是看昨天的监控指标而不是等用户投诉。4. 踩坑实录几个最容易翻车的地方4.1 切片策略不佳导致检索结果永远不准我调过最久的一个Bug是某类问题怎么调都检索不准。排查了很久最后发现根源是切块太机械。有些文本块从一句完整的话中间断开语义被切断向量化之后整个块的意义都偏了。检索模型看着觉得这块跟问题不相关自然不返回。后来我改成按段落和标题先做Luneng早先的重组再把长段落拆成有边界的子块块与块之间保留约50到100字的重叠。这个改动上线后命中率直接涨了十几个百分点。我想表达的是检索效果差的根因经常不在检索本身而在上游的文本切分质量。你要是遇到检索差先别急着换Embedding模型或调索引参数回去看看自己切出来的文本块长什么样。4.2 生成答案“看起来很对实际在胡扯”很多RAG系统都会遇到这个问题检索回来的资料里根本没有答案但模型还是答得一本正经。这就是幻觉的典型形态。我的处理办法是三层防线。第一层在提示词里反复强调边界资料没有就直说第二层在代码里做“证据检验”检查答案中的关键实体是否在检索回的文本块中出现没出现就拦截第三层是对高风险的问答类型放宽门槛比如数值类问题要求必须引用原文中的具体数字才能放行。三层防线叠加以后幻觉比例降到了一个可以接受的区间。注意我这里说的是“降低”不是“消除”任何做大模型应用的人都应该对“绝对可靠”保持警惕工程手段只能逼近不能等于。4.3 成本失控一次批量任务花了没必要的钱我接手过一个批量分析任务需要把一万多条客户反馈交给大模型做分类和总结。最初直接用长文本反复调用成本高得吓人。后来做两件事第一把每条反馈先压缩只保留关键句能把输入Token减少一半多第二对相似反馈做去重同模板的反馈只跑一次。就这么两个改动成本降到原来的四分之一。预算控制是AI工程里永远躲不开的命题。我的习惯是每个上线功能申请资源前先按最坏情况测算Token消耗写在接口文档里。同时给模型调用加两层限流用户维度限流和功能维度限流。别等功能被刷爆了才想起要做限流那会儿账单已经出来了。4.4 混合检索的权重与阈值也要调不是配好就能用前面提到混合检索效果好但它也不是开箱即用。我调试初期向量和关键词的融合权重是瞎拍的结果有的问题拼命命中关键词有的问题完全被高频词带偏。后来我用测试集做了小范围网格搜索把两个检索通道的结果都做了归一化再融合效果才稳定下来。还有一个细节不要把向量检索的Top K设得太大否则生成阶段的输入会被低质量文本块污染。也不要设太小否则漏召回会成为常态。具体数值因文档库而异但大概范围可以体会一下几百到几千条文本的库Top K取5到10比较常见。5. 在真实项目中继续成长的一些建议聊了这么多实操细节最后想说几句“如何持续成长”的真心话。AI工程这个方向更新太快今天还在用的框架明天可能就出了新的替代品。我的应对方式很朴素每个季度给自己立一个“新东西验证”任务比如新的推理框架、新的OCR工具、新的评估方法用一周时间做小规模试用并写一份给它“找茬”的记录。这个习惯让我面对技术演进时心态比较稳因为真正吃透过一个工具后再看同类工具会快很多。还有一点我特别想强调写文档写总结不是浪费时间而是修炼。每次项目复盘我必写三段哪里做得好、哪里做得差、下一次会怎么做。这些笔记是我自己的私人知识库。刚入行时我觉得写文档耽误写代码后来才发现代码会过时而经验不会。如果你也在从零开始走这条路我希望你记住一个朴素的原则不要跟风追逐每一个新词找一个真实场景的小问题用AI老老实实解决它把全流程走通。一个完整的、虽然小的项目胜过十本只翻了一半的书。技术栈可以慢慢替换你的工程判断力才是真正值钱的东西。等到能独立把一个AI项目从想法带到上线并让它稳定跑起来你那时候回过头来看会发现这个“从零开始”的起点已经在不知不觉中甩开了一大截。