最近“AI工程”这个词突然火了。不只技术社区在聊招聘软件上相关岗位的需求也明显涨了起来。我也经常被人问到一个很具体的问题从零接触 AI怎么才算“会做 AI 工程”有人觉得会用个大模型 API、写点提示词就算入门有人觉得非得从训模型开始才算“正宗”。我的看法是这两个方向都偏了。AI 工程从零到一真正的核心不是“模型”本身而是把模型落成一个可靠系统的完整链路。这也是这篇内容想一次性讲清楚的事。这个标题里的“from-scratch”其实很有分量。它意味着你没有现成的脚手架可以依赖要从数据怎么组织、检索怎么设计、效果怎么评估、成本怎么控制这些地基问题一个个解决。我会从技能拆解、学习路线到完整的实操案例把 AI 工程化的整条路径走一遍。既有适合新手的认知框架也有可以直接照做的代码方案。无论你现在是刚开始接触还是已经踩了某几个坑这篇都能提供一些参考。1. AI工程到底在解决什么问题1.1 为什么你需要“从零开始”而不是“直接调好一个模型”很多人有个误解觉得做 AI 工程就是训练或微调模型。真实的业务场景里大部分时间根本不是这样。我在企业里做过几个落地项目最深的体会是模型能力只是整个链条的一个环节真正拉开差距的是系统设计。AI 工程的核心任务是把模型能力变成稳定的产品能力。这个“变”的过程牵扯到六个方面数据怎么获取、清洗、评价数据质量检索怎么从海量信息里快速召回相关片段编排怎么把多个步骤组合成一个流程评测怎么衡量系统好不好用包括离线指标和在线反馈部署怎么让系统稳定可靠地跑起来成本怎么让每个请求的消耗控制在可接受范围。如果你只盯着“调模型”这件事前面说的这六类问题全都会被忽略最后做出来一个demo容易、上线就崩的东西。这也是“from-scratch”这个词的题眼你要从零开始把这些环节逐个打通而不是跳过它们。换个类比可能更好理解。模型就像一个刚聘进来的高材生能力很强但怎么安排他工作、给他什么资料、怎么检查他的产出、怎么控制他的工作量这属于管理系统的问题。AI 工程做的就是这套管理系统。1.2 “AI工程”和“算法工程师”到底有什么区别不少读者会混淆这两个概念我简单做个拆分。算法工程师的工作重心通常偏向模型本身比如设计模型结构、改进训练策略、提升基准测试分数等。他们的产出物是一个或多个“能力更强的模型”。AI 工程更偏向整体交付它关心的是用户把这个模型接入业务之后它的综合体验是否可用。举个具体例子一个客服项目模型单轮的问答准确率再高如果检索二十分钟出不了结果、或者同样的问题隔一星期回答完全不一样用户依然觉得这是个烂系统。这两个岗位当然有交叉但出发点不同。AI 工程真正关心的不是“模型的上限”而是“系统的下限”——保证系统在不确定的真实数据、大量并发请求、持续变化的环境下也能给出一致且可用的表现。我这里整理了一张对比表格方便你直观理解对比维度算法工程师AI 工程师核心目标模型能力提升系统稳定性与交付主要产出模型权重、论文、指标报告服务接口、工作流、监控系统关注指标准确率、F1、BLEU 等延迟、成本、可用率、效果一致性日常任务训练调参、数据清洗、实验比较流程编排、检索优化、评估部署交付边界给出模型给出可用的整体解决方案我是从传统后端开发转过来的早期也差点走偏花大量时间研究模型架构结果项目真正需要的是跑通一条数据处理链路。后来才想明白AI 工程的本质是要打通“数据 → 模型 → 产品”的整个流程而不是只照亮其中一段。1.3 一个端到端AI工程项目的基本流程不管做什么场景AI 工程的落地流程大体是一致的。我总结下来通常分五步第一步需求澄清。很多人跳过这一步直接写代码这是最贵的坑。需求不是说“老板要一个智能问答机器人”这种空话而是要问清楚用户输入是什么形态对回答的时效性有没有要求出错代价有多高需要控制在什么量级。第二步链路设计。根据需求决定用纯大模型生成还是要引入检索增强或者要做复杂的工具调用。这一步要画出系统架构图明确每个环节的输入输出。第三步建立评测基准。从真实场景里抽一批有代表性的问题定义清楚“什么样的回答算好”。这一步越早做越好否则后续根本没法判断改动是变好还是变坏。第四步迭代优化。跑通最小闭环之后再一个环节一个环节地改。比如先优化检索再优化提示词再考虑微调。每次只改一个变量才能知道改动效果来自哪里。第五步上线与运维。部署成可监控的服务记录延迟、成本、错误率、用户反馈形成迭代闭环。整个过程最容易被初学者忽略的是第三步“评测”但恰恰是这一步决定了项目能不能持续地往前走。没有评测的 AI 工程就像开车不看仪表盘跑得再快也是瞎跑。2. 从零入门AI工程的知识地图与优先级排序2.1 核心硬技能清单如果说 AI 工程需要一套“知识地图”我不会把它规划成很大的一棵树因为这会让初学者无从下手。我更愿意把它压缩成几块必须掌握的能力块第一块Python 工程能力。不要求你成为语言专家但至少得熟练使用 venv 或 poetry 管理依赖、写类型注解、用 requests 或 httpx 调接口、把逻辑封装成函数和类。这个基础不牢固后面每走一步都会卡壳。第二块API 调用与基础策略。会调用主流平台的 chat/completions 接口理解 temperature、top_p、max_tokens 这些参数的实际影响并且会写结构化的提示词。这里的关键不是“怎么把 prompt 写出来”而是“怎么把 prompt 当代码一样管理”所以 Git 管理提示词版本也一样重要。第三块检索与向量数据库。知道什么是文本切块什么是向量化什么是相似度检索会使用至少一种向量数据库如 Chroma、Milvus 或 Qdrant。这块是 RAG检索增强生成应用的地基。第四块评估。能基于真实场景构建测试集选择合适的指标衡量效果并把评估做成自动化流程。第五块部署与监控。能用 FastAPI 或 Gradio 把应用包装成服务能记录日志和关键指标知道怎么定位线上问题。这五块能力并不是并列关系它们有强烈的依赖顺序。第一块和第二块是基础上路之后直接到第三块然后立刻把第四块养成习惯最后才是第五块。2.2 为什么建议先用API再学微调关于学习路线我强烈建议大多数“from-scratch”选手先把大模型 API 用好而不是一开始就折腾微调。理由很实际。微调是加大模型内部知识容量、改变风格与行为的方法。对于多数真实业务直接用现成模型配合检索方案就能解决 80% 的问题。直接学微调会同时面对数据构建、训练资源、过拟合、评测回归等等一堆问题这山头太难爬。先用 API 的好处是模型能力是现成的你可以把注意力全部放在周边系统上比如数据怎么流转、检索怎么接、逻辑怎么编排。这些才是 AI 工程的核心。等你把链路跑通确认“通用模型的表现已经不错但某些风格场景确实不稳定”时再有针对性地微调成功率会高很多。我是见过不少反例的。有人微调了下模型结果把原有能力给覆盖了回答明显变“笨”了还找不出原因。更合理的路径应该是“先用通用模型做出基线再根据评测结果决定要不要动模型本身”。2.3 建议的工具选型和理由工具选型这东西特别容易让人纠结。我的原则很简单优先选社区活跃、上手成本低、够用的工具而不是一步到位选最“重”的方案。关于这一块我整理了一份相对固定的组合能力域推荐工具选择理由语言与运行时Python 3.10生态最全AI 项目首选依赖管理poetry 或 uv环境隔离清晰依赖锁定可靠模型调用OpenAI SDK / 国内平台 SDK参数规范文档齐全向量数据库Chroma 起步Milvus 或 Qdrant 进生产起步简单后续扩展性够服务框架FastAPI性能好自动生成 API 文档评估工具自建数据集 自动化脚本贴合业务不依赖黑盒监控Langfuse 或 LangSmith可观测链路与 token 消耗仓库管理Git Hugging Face 数据集版本管理的基础设施如果你完全没有 AI 工程基础我的建议是别把时间花在“挑选工具”上面。确定一个主流组合花半天到一天时间把环境跑起来先用起来再谈优化。工具是服务于项目的不是用来收藏的。3. 实操案例企业知识库问答助手的完整落地3.1 需求澄清与场景边界我们用一个具体案例来串联前面说到的所有环节一个面向企业内部员工的知识库问答助手。员工可以提问比如“请假流程是什么”“报销额度上限是多少”助手需要基于企业内部的文档返回准确答案并给出引用来源。这个项目的关键点在于答案不是大模型自己编出来的而是从内部文档里“检索出来再整理”的所以它天然适合用 RAG 架构。先做需求澄清。很多人在这一步就开始上模型了但我们应该先列出关键边界知识来源公司内部的规章制度、操作手册等格式主要是 PDF、Word、Markdown数据更新频率这些文档会变动季度性更新比较常见用户规模初期几百人后期可能上千响应要求内部工具不是面向客户的高并发场景但希望能达到秒级响应错误容忍度这是规章制度类问答错误回答可能直接影响员工操作所以“不回答”比“乱回答”更可接受。基于这几点我们可以确定技术选型和链路设计。3.2 核心链路搭建从解析文档到向量检索RAG 的第一件事是把文档变成可检索的结构化数据。这里最容易犯的错误是直接拿整个 PDF 去生成向量然后检索时再整个塞进上下文。这种方式不仅召回效果差token 成本还高得吓人。正确的做法是切块chunking。常用的切块策略有两种固定长度切块和语义切块。固定长度简单可靠按字符数分割并设置重叠区间以保护段落上下文语义切块依赖模型判断语义边界效果上限更高但实现复杂。对大多数企业文档我建议从固定长度切块开始后续再优化。这里有一段可以参考的切块代码Pythondef split_text(text, chunk_size800, overlap150): 按固定字符数切分文本并保留重叠区间。 chunk_size 按 characters 计不同语言可微调 overlap 用于补偿切在句子中间导致的上下文断裂。 chunks [] start 0 while start len(text): end start chunk_size chunk text[start:end] # 尝试在句号或换行处截断而不是生硬切断 for sep in [\n\n, \n, 。, , ]: last_index chunk.rfind(sep) if last_index ! -1 and last_index chunk_size * 0.5: chunk chunk[: last_index len(sep)] end start last_index len(sep) break chunks.append(chunk) start end - overlap # 重叠部分保留上下文 return chunks切块完成之后用 embedding 模型把每个块转成向量存入向量数据库。这里我用 Chroma 做示例from chromadb import Client from chromadb.config import Settings client Client(Settings(anonymized_telemetryFalse)) collection client.get_or_create_collection( namecompany_docs, metadata{hnsw:space: cosine} # 使用余弦相似度适配文本检索 ) # 假设 docs 是 [{id: 001, text: ..., metadata: {source: onboarding.pdf}}] for doc in docs: embedding get_embedding(doc[text]) # 伪代码实际用对应SDK collection.add( ids[doc[id]], embeddings[embedding], documents[doc[text]], metadatas[doc[metadata]], )检索的核心是找到与用户问题最相关的文档片段而不是把整个文档端给模型。我在生产项目里经常都会再加一步重排来提升最终召回质量。重排的必要性很容易理解。向量检索出来的 Top-10 里可能只有前两条是真正切题的。如果直接把这 10 块都塞给大模型噪音会干扰回答而且 token 成本翻倍。用重排模型比如 bge-reranker对候选片段重新打分可以稳定提升检索精度。3.3 检索参数的选择与调优策略这里说几个我在实操中反复调整的参数以及调整原因。第一chunk_size 到底选多大。我试过 400、800、1500 这些档位。总体感觉是 800 以内效果比较稳定切得太碎容易丢失上下文切得太大又容易混入无关信息。这个没有绝对最佳最好按你文档的实际句子长度来调整。第二Top-K 的取值。在加了重排之后通常向量检索先取 Top-10 或 Top-20重排后再截断到 Top-3 或 Top-5。这样既保证了候选的覆盖度又限制了进入模型的噪声。第三embedding 模型选型。我比较推荐中文场景优先考虑 bge-m3它对中文语义理解比较协调而且在多个检索任务上表现都不差。实际选型要在自己的测试集上跑一次对比别盲信宣传指标。第四重排模型。bge-reranker-base 或 larger 都可用。重排耗时增加约几十到几百毫秒但效果提升通常很值得对内部工具来说这个延迟成本完全可控。调优策略的核心是单变量实验。一次只改一个参数用固定的测试集对比结果否则改了三个变量后你根本不知道是哪个真正起了作用。3.4 评估方案不过关就不上线这个案例里我设计了两个维度的评估。第一检索效果评估。用 MRRMean Reciprocal Rank来衡量正确片段是否排在前面。这里我分享一个计算 MRR 的思路对每个测试问题让检索系统返回 Top-10 候选人工标注正确片段的位置取位置的倒数再对所有问题取平均。第二回答质量评估。这里用两个关键指标忠实度回答是否严格基于召回片段中的信息有没有幻觉造出文档里没有的内容完整度用户关心的信息点是否都覆盖到了。现在我可以构建一个较小的自动化评估脚本# 评估脚本核心思路 test_set [ {question: 2024年新员工的年假天数是多少, gold: 15天}, {question: 报销的发票有效性要求是什么, gold: 电子发票或纸质发票均可}, ] def evaluate(test_set): total len(test_set) at_least_one_correct 0 for item in test_set: answer run_pipeline(item[question]) # 简化判定判断回答中是否包含gold中的关键信息 if any(keyword in answer for keyword in [item[gold]]): at_least_one_correct 1 return at_least_one_correct / total这个脚本看起来有点粗糙但自动化可重复比“感觉变好了”更有价值。上线前至少要确保在 50 条以上真实问题的测试集上指标达到与业务方约定的阈值比如完整度不低于 80%。4. 常见问题与排查技巧实录4.1 离线评测表现不错线上效果很差这是做 AI 工程最容易碰到的“玄学问题”。我印象很深的一次经历是在测试集上答案什么都对一上线就被业务方投诉说是乱回答。后来排查发现核心原因就两个。第一测试集是从文档里抽出来的“中心问题”但线上用户提问的措辞很随意比如“年假能不能凑着一起休”跟测试集风格差很多。第二真实文档更新了但向量数据库里还是旧的索引导致新旧信息冲突。现在的解决思路有两条。一是构建测试集时覆盖真实用户的历史提问并且持续补充新问题二是给数据加上更新时间标记定期重建索引或者引入增量更新的机制。评估集不是做一次就完事的它要跟着业务一起迭代。4.2 上下文越来越长token成本直线飙升RAG 应用上线后我几乎每个项目都会被成本吓一跳。因为随着检索结果变多、历史轮次变多系统每次请求塞进去的 token 越来越多费用就悄悄涨上去了。控制 token 的第一个手段是限制检索片段数量。前面说的 Top-3 而不是 Top-10就是典型的有效手段。第二个手段是精简提示词模板很多提示词里的大段“角色设定”每次都发送这其实是一笔不小的固定开销。第三个手段是对多轮对话做剪枝只保留与当前问题最相关的历史内容而不是把所有历史全塞进去。最有效的动作是记录每次请求的 token 消耗。如果你不能量化每个会话的平均成本就没法做针对性优化。我建议每轮请求把 prompt_tokens 和 completion_tokens 都写入日志定期统计单均成本。4.3 检索召回的片段不相关怎么系统性地排查一个常见场景是用户问 A检索出来的片段却讲的是 B。出现这种问题的原因通常有三个层次第一层切块粒度不对。片段太长、信息混杂或切得太碎、语义断裂。这时先手工看几条切块结果感受一下切得是否自然。第二层embedding 模型不匹配。很多场景换一个更适配的 embedding 模型检索效果立刻就不一样了。如果你用的还是通用领域的旧模型可以试试换 bge-m3 这类新模型做对比。第三层查询本身有歧义。用户的问题里带着指代比如“这个流程怎么走”系统不知道“这个”指什么。解决方式是做查询改写把历史会话里的关键信息补全成独立的查询语句。排查时要按这个顺序来先看切块本身再看向量比较的相近程度最后才怀疑是模型能力不够。不要一上来就盲目换模型那样问题定位会越来越偏。4.4 幻觉问题到底能不能彻底解决直接给结论不能百分之百消除但可以把发生概率压到很低。我通常用“边界约束”的思路来控制幻觉。一是给大模型明确指令只允许用给定的检索片段回答找不到就说不知道二是要求回答附带引用来源让业务方和用户可以核实三是增加一层校验让模型输出前先用检索片段做个“自检”不过关就拒答。这几种方式叠加之后大部分业务场景下的幻觉率可以压到可接受区间。剩下那些漏网之鱼就靠用户反馈渠道和人工抽检来兜底。与其追求一个完美的模型不如建立一个“错误能被发现、能被修正”的系统。最后分享一个小技巧根据我个人经验做 AI 工程最容易被低估的是日志系统。当你开始记录每个会话的 token 消耗、每类问题的答非所问率、每次检索的命中位置时你对系统的理解会远远超过任何监控面板能提供的。我习惯每天跑一次统计第二天早上看一页摘要然后顺着问题修链路。这种节奏跑起来优化效果非常线性你每一步都能感受到系统在变得更可靠。AI 工程从零到一确实没有捷径但也不需要恐惧。只要把数据、检索、评估、部署这条链路一步一步补起来你会发现最终交付的不是一个模型而是一个稳定可信的系统。从 scratch 开始不是从零起步的困难而是一个完全建起一座建筑的自由。