开头先泼一盆冷水AI工程不是“调个API、写两段提示词”那么简单。真正想从零搭起一套能用的AI系统你面对的是数据怎么处理、模型怎么选、推理怎么加速、成本怎么控制、效果怎么评估这一整条链路。我见过太多团队Demo跑得飞起一上生产就崩问题全出在“工程”两个字上。这篇文章想聊的就是一条从零开始的AI工程实战路径。没有什么高深莫测的理论全是踩过坑之后沉淀下来的实操经验。如果你是后端转AI、前端想搞点智能功能、或者算法工程师想补全工程能力这篇内容应该能帮你把碎片化的知识串成一条线知道每一步在做什么、为什么这么做、下一步该往哪走。1. 内容整体设计与思路拆解1.1 先搞清楚“AI工程”和“调接口”的边界很多人有个误区觉得AI工程就是调用大模型API写个Prompt然后解析返回结果。这套东西在个人项目或者内部工具里跑没问题但放到真实业务里远远不够。我习惯把AI工程拆成三层来看模型层选什么模型、微不微调、要不要部署开源模型数据层数据清洗、格式化、向量化、评测集构建系统层推理加速、缓存设计、限流熔断、监控告警、成本核算这三层是互相咬合的。你选了一个700亿参数的开源模型就要考虑显存够不够、推理延迟能不能扛住业务峰值你接了一个商用API就要考虑Token成本会不会把利润吃掉。所以做AI工程第一步不是写代码而是把整个技术选型和业务约束盘清楚。从零开始搞AI工程最忌一上来就奔着“高大上”去。上来就搞分布式训练、搞多机多卡大概率会死在环境配置上。我的建议是先跑通一条完整的小链路数据进来、模型处理、结果出去、日志记录。哪怕用最轻量的方式也要把闭环建起来。闭环在手后续所有优化都有地方做验证和回归。1.2 为什么“从零开始”意味着要先建评估体系这是我最想强调的一点也是无数团队翻车的地方没有评测体系就没有AI工程。传统软件功能对不对跑个单元测试就知道。AI系统不一样它是概率模型同一个输入可能这次对下次错。如果你没有一个评测集、没有一套打分标准你优化提示词、换模型、加上下文到底效果变好了还是变差了全靠感觉。靠感觉做工程离事故就不远了。我个人的习惯是任何项目动工前先花时间整理至少50到100条真实业务问题作为种子评测集。不用一次做到完美但要把“好答案”的标准定义清楚。比如客服场景答案准确是一方面态度话术也要符合品牌调性代码生成场景能跑通是第一优先级可读性和安全性也要打分。有了评测集之后你做的每一步改动都能量化。换模型、调温度、加RAG改动前后跑同一批题分一对比心里就有底了。这也是区分“算法工程师”和“AI工程师”的分水岭一个关注模型能到多少分一个关注系统怎么稳定地达到那个分数。2. 核心细节解析与实操要点2.1 提示词工程当前阶段最值得投入的环节“提示词工程”Prompt Engineering被很多人看作调参艺术但我更愿意说它是一门结构化学问。好的提示词不是靠灵感写出来的它有固定套路。我常用的提示词结构是四段式角色设定告诉模型它是什么角色、有什么约束任务描述用动词开头清晰说明要做什么输出格式规定结构、长度、风格边界条件说明什么不能做、遇到歧义怎么处理举个例子。你要做一个产品评论总结功能。弱提示词是“帮我把这些评论总结一下。”强提示词是你是一个电商平台的评论分析师。请从以下用户评论中提取核心关注点分类输出为【质量】【价格】【物流】【客服】四个维度每个维度总结不超过50字并给出该维度的正负面比例。如果评论中没有涉及某维度则标注“无反馈”。差异在哪弱提示词把判断权完全交给了模型输出结构不可控。强提示词把角色、任务、格式、边界全部定义清楚模型照章办事输出稳定可解析。生产环境里结构化输出能省掉一大半清洗代码。还有几个实操细节值得留意温度参数抽奖式任务模型选0.8以上刚需准确性任务设0.1到0.3上下文窗口不是填得越满越好过长的上下文反而会稀释注意力只放必要信息Few-shot示例给两到三个高质量示例效果往往比把规则写十行要好2.2 Agent化设计从单次问答到多步协作最近很火的AI Agent智能体概念本质上就是把一次性的问答扩展成“目标驱动、多步执行、工具调用”的工作流。你给Agent一个目标它自己拆解步骤、调用工具、根据中间结果调整策略。搞Agent化设计我建议从最简单的Pipeline开始。就比如做一个文档自动处理Agent第一步抽取文本第二步做语义分段第三步调用LLM做要点提取第四步把结果写入知识库。这四步写在一起就是一个最简Agent框架。每步互相独立出了问题单独排查比一个巨大的提示词包打天下要稳得多。进阶一点可以给Agent加上Tool Use能力。让模型自己决定什么时候调搜索引擎、什么时候查数据库、什么时候执行Python代码。这里核心是做好函数描述和参数校验。我见过很多新手在这块踩坑工具函数没有做超时控制模型调用失败后无限重试白白烧掉大量Token和时间。所以工具侧的容错设计优先级不比模型本身低。多Agent协作Multi-Agent是另一个方向。比如一个项目经理Agent负责拆解任务几个执行Agent并行干活最后汇总Agent整合输出。这个模式在一些重流程场景特别好用但要注意Agent之间的通信协议设计。别搞复杂的消息中间件先用一个共享的任务状态表就能跑通MVP。2.3 RAG检索增强生成让模型学会查资料大模型训练数据是有截止日期的而且它们天生不擅长精确记忆事实。当你的业务需要模型回答时效性强或私域化的问题时RAGRetrieval-Augmented Generation就是最务实的解法。RAG的核心逻辑就是“先检索再生成”把用户问题拿去知识库检索找到相关片段把片段塞进提示词作为参考上下文再让模型基于这些内容回答。这个流程能让模型从“背诵”变成“查阅”幻觉率大幅下降。落地RAG时几个最关键的参数是我的经验沉淀分块大小通用场景400到800字之间表现比较稳。太小语义不完整太大检索噪音多Top-K取值大多数场景取4到6个块返回就够堆得太多反而让生成环节迷路检索策略混合检索关键词BM25向量相似度比纯向量检索稳定很多特别是处理专有名词、ID号这类文本时刚开始做RAG的人最容易忽略的是知识库的更新机制。文档改了、新资料来了向量库里还是旧数据检索出来的内容自然过时。建议给每个知识块记录来源和版本号更新时同步标记。反正我自己的教训是知识库长时间不更新模型一本正经说错话的概率会越来越高。2.4 大模型选型与部署商用API还是开源模型模型选型是整个AI工程里最纠结的决策。商用API上手快、效果好但数据出境、成本不可控、依赖供应商稳定性开源模型自己部署隐私可控、成本可预测但需要工程团队扛起部署和调优的重任。我的选型经验是三问法业务对延迟敏感吗面向C端实时交互场景先看商用API的响应速度能不能接受数据敏感度有多高涉及用户隐私、商业机密的场景开源模型私有化部署几乎是唯一选择团队有没有运维能力开源模型不只是跑起来还得监控、升级、降级方案团队扛不扛得住这摊事如果决定走开源路线硬件门槛首先要算清楚。以目前热门的7B到8B参数模型为例FP16精度推理大约需要16GB显存INT4量化能压到6GB以内。如果部署一个带较长上下文的对话服务保守估计需要24GB显存的单卡如RTX 3090/4090。规模再往上走就是A100/H100这些企业级卡的世界。显存不够最常见的替代方案是上量化4bit量化在多数任务上损失极小但推理速度能提升不少。部署方案上vLLM是目前市面最成熟的推理加速框架PagedAttention机制让显存利用率大幅提升。吞吐量能做到原始方案的3到5倍。如果团队没有GPU资源也可以考虑用云服务商的模型托管平台把部署和扩容的活外包出去。3. 实操过程与核心环节实现3.1 搭建最小工程骨架从零到接口我在带团队时习惯让新人先做一个“最小可运行闭环”核心就三步模型调用封装、业务逻辑嵌入、HTTP接口暴露。第一步先把模型调用封装成统一接口。不管你后面要用OpenAI兼容格式还是自部署模型调用入口统一成一个函数返回结构也统一。这样后续切换模型时只需要改这个文件业务代码一行不用动。第二步把业务逻辑写进去。比如你要做一个命名实体识别接口就先定义好输入输出的数据结构和校验逻辑再设计好提示词模板。提示词模板我通常会单独放一个配置文件不硬编码在代码里。放在代码里的Prompt改起来要发版放配置里改完热加载就能生效。第三步用FastAPI这类轻量框架把功能暴露成HTTP服务。写代码时我特别强调错误处理逻辑模型超时怎么办、返回内容解析失败怎么办、并发量走高要不要限流。这些边界情况处理好了接口才算是生产级。from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class RequestModel(BaseModel): text: str lang: str zh class ResponseModel(BaseModel): entities: list tokens_used: int app.post(/ner, response_modelResponseModel) async def ner_endpoint(req: RequestModel): # 1. 参数校验 if len(req.text) 2000: raise HTTPException(status_code400, detailtext too long) # 2. 调用模型服务 try: result call_model_service(req.text, req.lang) except TimeoutError: raise HTTPException(status_code504, detailmodel inference timeout) # 3. 解析与返回 return parse_model_response(result)这段代码是标准的工程骨架读者可以直接照着改。核心思路是把外部不确定性模型延迟、格式漂移隔离在业务逻辑之外出问题时只影响单个请求不会拖垮整个服务。3.2 函数调用与工具集成实战让模型学会“用工具”是很多复杂AI应用的基础。比如你要做一个数据分析助手模型本身不会算数你需要让它决定“该调用计算器了”然后你帮它执行再把结果喂回去。实现方式其实不复杂。先给模型提供一组函数定义里面包含函数名称、参数描述、返回格式。模型在生成时会输出一个结构化的“调用意图”你的代码拦截到这个意图执行对应函数把结果作为新消息继续发给模型模型基于工具返回的结果生成最终答案。这个循环跑通之后Agent的雏形就出来了。代码结构上我建议把工具调用做成插件式。每新增一个工具只需要注册函数名和描述就行业务逻辑全部解耦。def register_tool(name: str, description: str, handler: Callable): tools[functions].append({ type: function, function: { name: name, description: description, parameters: json_schema } })每个工具要做好三件事超时控制、结果截断防止返回内容超出上下文窗口、异常上报。工具执行失败不要硬抛给模型而是返回结构化错误信息让模型知道“这个工具现在不可用换个思路”或者“我调不到数据请用户确认条件”。3.3 数据准备与评测闭环整个AI工程链路里数据质量决定了效果天花板。Prompt写得好可以提升下限但上限一定由数据和模型共同决定。做RAG项目知识库清洗不到位检索结果全是垃圾后面怎么调都白搭。数据准备分两步走。第一步是清洗和格式化。从PDF、Word、网页里抽取的文本要去掉页眉页脚、图表干扰、换行符错乱统一编码格式。第二步是分块和向量化。分块策略我刚才提过400到800字是个好区间重叠部分设置50到100字保证语义连续性。评测闭环是我今天反复强调的事。没有评测你的优化就是玄学。我常用的评测做法是建一个CSV文件每行是一个测试样本包括问题、标准答案、难度标签、所属业务域。跑完一版系统之后用程序批量调用模型生成回答再用规则或者人工打分全部记录在案。同样的问题集每次改动后重跑一遍分数一对比效果就清楚了。import pandas as pd eval_set pd.read_csv(eval_set.csv) results [] for _, row in eval_set.iterrows(): answer generate_answer(row[question]) score grade_answer(answer, row[reference]) results.append({ question: row[question], answer: answer, score: score }) report pd.DataFrame(results) print(f平均分: {report[score].mean():.2f}) print(f最高分: {report[score].max():.2f})3.4 一个完整案例从零搭建企业知识库问答助手理论讲再多不如看一个完整案例。我们以“企业内部知识库问答助手”为例走一遍从零到一的完整流程。这套系统的业务背景是公司有大量内部文档散落在各个Wiki和共享盘里员工想找某个流程说明或政策条款只能挨个翻文档效率很低。目标是做一个问答助手员工用自然语言提问系统直接给出答案及来源出处。整体架构分四块存储用SQLite存文本元数据和分块信息向量数据库存Embedding流程文档解析-分块-向量化-入库检索混合检索BM25关键词检索向量余弦相似度生成LLM基于检索片段生成答案同时标注来源文档入库流程是整套系统的地基别急着往里面塞几千份文档。第一步先把两三个文档处理干净验证分块质量和检索效果。当你好不容易处理完入库后可以试着问一句文档里明确写着的问题。如果这一步匹配出来的内容文不对题后面生成环节做得再好也是白搭。这时候的问题多半出在分块策略上比如块太大导致语义混杂要回到前面去调整。对于知识库问答助手来说答案的“依据可不查”比“内容对不对”更重要。为每个答案配上来源引用一方面让用户能自行验证另一方面一旦模型胡编用户能立刻发现并反馈倒逼系统改进。4. 常见问题与排查技巧实录4.1 模型“一本正经地胡说八道”怎么办幻觉问题是大家吐槽AI最多的痛点。模型自信地输出一个错误答案用户拿去直接用后果不堪设想。缓解幻觉的办法按优先级排引入RAG让模型基于检索到的真实资料回答这是目前最有效的手段在提示词中强制要求“如果资料不足请明确说不知道”放开拒绝的大门用低温度参数减少模型自由发挥的空间答案生成后加一道校验比如事实性问题的答案要求附资料原文引用我做客服类AI的一个技巧是要求模型在输出答案前先引用支持自己结论的原文片段再基于原文生成回答。这一步能把大量幻觉扼杀在生成阶段因为模型一旦被要求“摆证据”它编造的成本就升高了。4.2 检索效果差、匹配不准怎么办RAG系统的检索环节出问题通常表现为答案答非所问。排查顺序我建议是这样先看分块查原始文档的分块结果如果语义被切碎了检索必然不准再看Embedding模型通用Embedding模型处理专业领域词汇时效果确实一般必要时换领域适配模型再看检索策略纯向量检索匹配专有名词效果差把BM25加进来做混合检索最后看重排序在检索阶段让Top 20候选进来然后用交叉编码器重排序取Top 5效果提升显著检索调优建议建一个评测集专门测“检索准确率”每轮改动跑一次比凭感觉加阈值靠谱得多。RAG系统里有一个经典坑用户问的问题很泛比如“电梯坏了怎么报修”检索系统不了解上下文可能会匹配到“电梯维保记录”而不是“报修流程”。解决办法是加一轮“查询改写”先让LLM把用户问题改写成一个更适合检索的查询比如扩展成“电梯故障报修的流程步骤和联系人”再去检索命中率明显会好。4.3 耗Token太多、成本压不住怎么办大模型API应用最大的隐性成本是Token消耗。很多系统刚上线时看不出来跑一两个月账单出来吓一跳。省Token的核心三板斧缓存。相同问题命中缓存直接返回不再调用模型。语义缓存更高级相似问题也能命中。一个简单的归一化处理加上向量相似度判断就能省下不少调用量精简上下文。把不必要的历史对话、大段背景知识从提示词中摘出去只留当前轮次需要的核心信息模型分级。简单问题走便宜的小模型复杂问题才走大模型。做一次意图分类把大部分常见问题用7B甚至更小的模型搞定还有一个容易被忽视的点输出Token往往比输入Token更贵部分商业API如此。让模型“说得简短点”不只是体验优化还能直接降低账单。我见过有些业务方要求模型每次都输出完整报告格式其实用户根本不需要那么多字数纯属烧钱。4.4 上线后效果变差、指标抖动模型服务上线后效果变差是AI工程和传统软件最不一样的地方。传统软件代码没动就不会变AI系统你可什么都没改效果莫名其妙就掉了。原因往往出在数据漂移——用户的提问方式变了、知识库内容过时了、或者上游模型供应商偷偷更新了底层版本。针对这类问题你需要一套线上监控体系。每一轮问答都做数据留痕记录用户问题、模型答案、检索命中片段、推理耗时、Token用量。每周做一次抽样复盘拿过去一周的问题去跟种子评测集对比着跑基本就能定位出是数据问题还是模型问题。模型服务商更新版本导致行为变化这种“隐形变更”最容易让团队抓狂。应对手段是锁定模型版本不用默认的“最新”。线上版本升级要像传统软件发版一样经过完整评测对比确认没有回归再切换。这步省不得我见过太多团队因为“新模型很厉害”盲目升级结果核心链路效果暴降的案例。4.5 典型问题速查表我把实战中最常踩的坑整理成一个速查表方便大家定位问题现象常见原因优先排查点回答跑题指令理解偏移提示词是否任务定义不清晰回答过时知识库更新不及时检查向量库是否有新版数据覆盖格式不稳未强制输出模板是否在提示词中约定JSON结构延迟偏高模型过大或序列过长确认是否超长输入塞爆上下文成本飙升重复调用和无效重试检查缓存命中和超时重试策略答案安全不足缺少系统护栏是否做了输出侧内容风控过滤相似问题结果不一致温度参数过高业务场景温度是否在0.2以下这个表是实时更新的每次踩到新坑就往里加。用表格记录踩坑经验比记在文档里好因为团队其他人也能查得到避免重复填坑。5. 工程进阶路径与协作实践5.1 从单机脚本到成熟的AI服务架构当业务规模变大单个脚本就撑不住了。这时候的改造方向是组件化和异步化。组件化指把AI能力拆成独立服务。模型调用一个服务、检索一个服务、数据同步一个服务各管各的互不干扰。改检索逻辑不影响模型服务模型升级也不影响上层业务。同时配套上消息队列文档进来先发消息异步处理入库处理完再通知业务侧不阻塞主流程。我见过团队在主业务流程里同步跑OCR、向量化、模型推理一个环节慢就整条链路卡死。拆成异步后就舒服多了用户提交任务立刻返回“处理中”后台慢慢搞搞完发通知。体验上反而更顺滑系统的吞吐量也上来了。异步化的副作用是要处理任务状态管理。我会在数据库里加一个任务表记录每个任务的阶段排队中、处理中、已完成、失败再加上重试机制和失败告警。这套东西不复杂但有了它线上出了问题你能快速定位到具体是哪个环节、哪个任务挂了。5.2 AI工程师的核心工作流协同AI工程从来不只是写代码的人的事。一个健康运作的AI项目至少需要三种角色打好配合算法方向的人负责模型选型和效果提升工程方向的人负责系统稳定性和性能业务方向的人负责评测标准制定和数据反馈。但现实里中小企业往往没有这么分工。一个人兼三个角色也很常见比如我自己就长期处于这种状态。这时候最重要的能力是“把需求翻译成技术方案”跟业务聊的时候听懂他们到底是想要“一个能写报告的助手”还是“一个能减少人工编辑成本的报告工具”。后者往往意味着你需要的不只是模型能力还需要一套模板化流程和人工审核机制。多角色协作中我强烈建议把“评测集”当作团队之间的契约。业务方往评测集里投真实场景的问题算法方对评测集负责工程方跑通评测流程。新功能上线前过一遍评测效果好坏双方心里有数少很多扯皮。AI工程还有一个常被忽视的方面可解释性与审计。尤其是在一些需要合规的应用场景里模型的决策依据、数据来源、调用记录都要能追溯。这不是形式主义当业务方或用户质疑某个回答时你能立刻拉出完整的调用链日志来说明“这个答案检索了哪些资料、基于什么逻辑生成”既是信任保障也是系统持续优化的依据。所以我做AI服务有个习惯核心业务链路全程留痕不仅是为了排查故障也是为了回答“为什么模型会这么回答”这类问题。5.3 持续学习与自我迭代AI工程技术迭代得太快。几个月前还先进的技术可能很快就有更好的替代方案。这个领域最重要的不是掌握某个具体技能而是保持快速学习和判断的能力。我的学习方法是“项目驱动”从自己手头项目出发遇到问题去查资料、做实验、总结沉淀。每做完一个项目把过程中的技术选型、踩坑记录、性能数据写成一份复盘文档。时间长了这些文档就是你最宝贵的经验库。很多人问我该不该追新框架、新模型。我的回答是只有能落到你的业务流程里的技术才是好技术。新技术出来先保持关注评估它对当前项目的潜在价值值得就小范围试点对比效果好再全面铺开切忌盲目跟风。这个领域永远有更好的模型、更新的架构但能够稳定支撑业务并持续产生价值的永远是贴近场景的工程方案。写在最后一点私人体会从零开始做AI工程说到底是心态的转变。过去我们写代码追求的是逻辑确定、行为可预期现在做AI你得接受不确定性得学会跟一个“概率性”的系统共处。我刚入行时候踩过一个大坑用RD的思维方式去调一个生成式模型想把它的输出严格约束在预设的轨道上。结果就是无休止地加规则、修提示词系统却越搞越脆弱。后来想明白了一件事——AI工程真不是追求“绝对正确”而是在“足够好”和“可控”之间找平衡。厉害的工程师不是说自己的模型从未出过错而是说自己的系统出了问题能快速发现、快速定位然后把带病数据拒之门外。说实话衡量一个AI工程师的好坏代码写得漂不漂亮还在其次最关键的是他有没有敬畏之心敬畏数据、敬畏概率、敬畏线上每一行日志。技术和经验会过时但这种对系统稳定性的执着是这个行业里最容易碰得头破血流也最值得代代传下去的东西。