1. 什么是AI工程AI工程师到底在做什么“AI工程”ai-engineering最近是我们圈子里最火的搜索词朋友圈里到处是“转行AI”“三个月成为AI工程师”的帖子。如果你在正规的软件工程岗位干过几年再去看那些帖子会有点想笑——宣传稿里全是提示词模板、API调用的截图把这件事说得跟写拼音输入法似的。但真正的AI工程是另一回事它一半是传统的软件开发一半是处理一个暴躁又偷懒的同事哦不模型本身。它没有作业本上的标准答案只有不停爆发的意外。我做了几年后端转AI工程前一直有个错觉学会调用GPT的API就完事了。后来才发现API调用只是最基础的一步就像后端工程师会写数据库增删改查一样根本不值钱。真正的AI工程要解决的问题是怎么把一个大模型或好几个大模型高效、稳定、低延迟、低成本地嵌进一套生产系统里让它在真实业务的流量下表现稳定不瞎编不卡死不出事故。这篇博文就是干这个的——我把过去踩过的坑、最终跑通的方案以及我眼中“从零开始做AI工程”最该关注的三个维度性能、成本、可靠性一次性都写了。有方案选型有完整的RAG架构细节也有真实调试翻车记录。如果你准备往这个方向转或者已经在做但总觉得哪里不对劲这篇文章会给你一套比较扎实的地图。2. 认清AI工程和传统软件工程的本质差异2.1 同样的“Hello World”完全不同的生命周期传统软件工程里我写了三行代码跑起来输出是“Hello World”它永远是“Hello World”我能用单元测试把它锁死一百年。但AI工程完全不同——我做了一个客服机器人系统跑起来可能今天说“您好欢迎光临”明天说“请问有什么可以帮您”后天对着用户是“您好”还是“您好您是”都是随机的。API的输入有随机性模型版本更新有不可预测性用户输入更是千奇百怪这带来最本质的变化测试必须从“断言输出”改成“断言行为边界”。举个例子传统后端写接口/user/info我传入user_id1断言返回name张三。这没毛病。但AI工程写一个prompt用户输入“你们怎么退货”这个输入可以变形为“退钱”“想退款”“你帮我退货”“怎么发起售后”所有变体都要能落到同一个业务逻辑上。没有哪个断言能把所有排列组合写完你能做的是把所有相似的意图聚合然后给输出定义一个“安全区间”——比如必须包含“退货政策”关键词、必须在30秒内响应、不能出现敏感词。2.2 从“确定性”到“概率性”思维上的根本转变刚转行时我犯过最幼稚的错误用传统开发的逻辑去追一个“必现Bug”。有用户反馈“我家地址是XX你们快递怎么送错了”回答却驴唇不对马嘴。我给模型提供商开了工单把同一个请求重发了一百遍结果五十遍正确、五十遍出错。那一刻我才意识到这不是“Bug”这是模型的概率性质——同样的输入它就是有可能中招。后来我理解了AI工程的价值不在于消灭概率而在于用工程手段把概率压到业务可接受的范围。这里有两个方向一是提高单次调用的正确概率换更强的模型、更好的提示词、加RAG检索二是布置兜底逻辑当模型输出明显异常再用规则去纠正或触发人工。这一个“概率思维工程兜底”的结合才是AI工程师真正的核心竞争力。3. “调用API”之外的真正核心我的技术选型实战“AI工程”这个概念火起来后大量人把“调用OpenAI API”包装成AI工程。我毫不客气地说这是在侮辱工程两个字。真实生产环境里选型才是决定生死的第一步。3.1 LangChain、LlamaIndex还是自己拼我的选择几乎每个入坑的人都会遇到那几大框架LangChain、LlamaIndex、AutoGen。我前期也跟风用了LangChain真到生产环境才发现一个大坑——版本漂移极其严重而且抽象层太厚。底层模型换一个版本上层代码可能就要重构。那阵子开源社区流行一句话“LangChain是给你给没想清楚的人用的想清楚了的人都自己去写了”话有点极端但也不无道理。我现在自己的实践是写一个很薄的自维护 wrapper模块化设计调用LLM的逻辑、解析响应的逻辑、重试逻辑、缓存逻辑分开封装总共不超过200行代码。核心代码自己掌握出了问题一眼能定位改起来也不会牵连其他模块。框架类工具并不是一无是处它们适合快速验证原型但投入生产环境前你要问自己这个抽象层我Hold得住吗3.2 模型选型为什么我用多地打字卡在“延迟 vs 效果”的天平上再来说模型选型。一上来就用最强模型那是烧钱的做法。我服务过一个小型企业客服业务量高峰期每秒并发30请求如果用最强的模型单次响应耗时轻松3-5秒用户忍无可忍换成中等模型虽然逻辑推理没有那么复杂但配合良好的提示词和检索增强响应能压到1.2秒以内。在AI工程里延迟比效果更影响业务体验这一点很多人会踩坑。我整理了一个模型选型的经验对照表你可以参考业务场景延迟要求推荐层级工程策略智能客服即时回复 1.5s中小型模型快速响应必要时级联升级到大型模型复杂文档总结离线可容忍 10s-30s大型模型加入流式输出提升体验代码生成内部工具 5s中型模型给足上下文让模型发挥出性价比情感陪伴类对话 2s中型模型高质量RAG加持弱化逻辑推理需求实际上没有“哪个模型更好”只有“哪个模型在最合适的延迟和成本下能满足你的业务”。做AI工程必须对模型的边界上下文长度、token费用、并发上限、响应格式稳定性倒背如流否则写着写着就会被眼前的“聪明”反噬。4. 从零搭建一条生产级RAG流程踩坑实录与完整剖析4.1 数据清洗才是RAG的隐形护城河如今“RAG检索增强生成”几乎成了企业“AI落地”的同义词。但市面上99%的教程都是从“怎么切分PDF”开始。确实越基础的教程越不强调前期的数据清洗——这是所有翻车事故的开始。我处理过一个客户案例他们有一堆客服历史工单想做智能问答机器人。直接把几百个PDF丢进去压根没法用。原因很简单文档里有大量扫描件的OCR乱码表格、图表截断后上下文断裂多级标题嵌套切出来一个“孤立文本块”根本不知道在说什么问题。我的清洗流程分五步走文件格式识别区分PDF、Word、Excel、扫描件文本抽取针对扫描件调用OCR引擎我常用PaddleOCR中文效果不错段落重组按“标题层级”合并相关联的连续段落而不是机械按字数切去噪去掉页眉页脚、导航文字、签名档等无关语料过滤脏数据利用正则和简单分类器识别“无意义文本块”并剔除。光是清洗这一步就占了整个RAG项目的一半工作量。没有好的数据后面调提示词都是白搭。4.2 切分策略的“度”在哪里从文本块大小到检索效果的实验记录清洗完数据挑战第二步文本切分。这是我最想吐槽的部分因为网上90%的教程都是直接固定设置为256或512个token完全不动脑子。可事实上切分太小上下文割裂严重模型可能只能看到“快递到了”不知道说的是什么快递切分太大模型上下文窗口被噪音占满检索质量反而下降。我自己做了一个实验表用来确定最佳切分大小你可以直接当参考文本类型切分大小字符重叠区说明客服对话记录800-100080每段包含一个完整问答对长篇文章/技术文档1200-1500120段落语义相对独立列表型/表格型300-60050避免数字和文本被切开法律条文/合同500-800150上下文依赖极强保留条款边界这个方法的核心思路是“语义级切分”而非“字符级切分”。实在来不及分析文档结构时也可以按照Markdown标题、换行等自然定界符来做这比固定token合理得多。4.3 检索翻车为什么明明入库了却查不到洗了数据切了块做好了向量化你以为就完事了天真。实际运行后我收到最多的问题就是“资料明明在知识库里检索就是查不到答案也牛头不对马嘴。”用向量检索最大痛点是query与文档的关键词重叠太少。比如用户问“怎么申请退款”而文档里写的是“退款政策详见第六条”向量模型可能识别不出深层关联取决于模型的语义能力于是老老实实捡了一堆噪音返回。怎么解决我的组合拳是混合检索重排。混合检索同时跑“向量检索BM25关键词检索”两者结果各自取TopN比如各取50条再合并重排Rerank合并后用重排序模型如Cohere Rerank 或 BGE-Reranker按相关性重新打分只把Top 5喂给模型。这是一套性价比很高的方案。直接暴力堆上下文窗口在文档多、并发高的时候响应延迟和成本会一起失控。重排实际上就是“精挑细选”让我花在模型上的每分钱都物有所值。4.4 防幻觉的最后一公里缓存与兜底即使做到了上面所有步骤模型还是可能一本正经胡说八道。我把这称为“最后两成事故”它靠RAG本身解决不了必须靠工程兜底。我的兜底策略分三层置信度闸门让模型在输出核心回答时同时输出一个“依据引用”取自哪份文档的哪一段如果引用缺失或自相矛盾就降级为预设话术比如“抱歉我没找到相关信息请转人工”。规则引擎复核核心字段如金额、日期、订单号用正则二次校验防止模型改数字人工B计划被闸门拦截的失败请求自动生成工作流派给人工客服处理。听起来不浪漫但这就是工程。AI工程不是追求“机器永远全对”而是建一个“事故预防系统”让机器犯错时不至于让用户崩溃。5. 我踩过的生产事故一次让你少走三年弯路的复盘5.1 事故一莫名其妙的高延迟根因惊出我一身冷汗上线第一周用户投诉“响应太慢”后台监测发现有个接口P95延迟从800ms飙升到7秒。翻遍日志发现原因是——模型提供方会对超大Prompt做“排队”我没有做超时控制和功能降级一个用户请求卡住了后面所有请求全在等同一个连接。那次事故教给我三件事任何上游不可控都必须加熔断器每一个外部API调用都必须设置超时上限连接池要监控不能盲目复用。5.2 事故二Token刷爆预算一夜花了上万这是最记忆犹新的一次。原因是代码里一个疏忽拼接上下文的时候给了列表去重但没限制最大token数。一个长对话用户的上下文越滚越大直接推送了2万token给模型相当于把一天的调用量集中到几次请求上账单瞬间炸裂。现在我的代码里永远有两把锁调用前强制计算input_token output_token超阈值直接截断用消息摘要把历史最老的对话做摘要压缩而不是无限堆原始记录。5.3 事故三幻觉诞生了“无法退货”的噩梦又一次客服机器人事故模型对着用户说“您的商品超过退货期限无法退货”但业务规则明明是可以退的。为什么因为模型从某一份“过期的旧版退货政策”里检索到了错误信息喂给了用户。这就是RAG的老大难知识更新了但向量库里旧数据没有剔除检索时旧的还是能排前面。后来我加了一套“时效性权重”对文档元数据打了业务生效时间检索后重排时把过期文档降权。同时每天跑一次定时任务对“已生效/已废弃”的文档做索引管理。别小看这个在真实业务里这比任何高级Prompt都更有效。6. “从零开始”的正确路径我给初学者的避坑建议6.1 别从“框架”学起而是从“原理”学起看到这里你肯定发现我全文都在强调底层逻辑。对于刚入门的人我的建议永远是分四步走先学会直接调用API。把OpenAI或国产模型如通义千问、文心的官方接口文档翻一遍调用一下理解token、temperature等参数的实际影响。自己手工写一个RAG流程。只用Python脚本和几十行代码把数据清洗、切分、向量化、检索串起来。逼自己掉进坑里比看任何教程都管用。再学评估。搭一套自己的评估集50-100条业务问答每改一次提示词或切分策略就去跑一遍评估集看准确率涨了还是跌了。只要没有这一步你连调优都不知道往哪个方向调。最后再看框架。有了前两步的手感和对核心逻辑的理解再去看LangChain源码你会有一种恍然大悟的感觉也知道哪些模块有价值、哪些模块是冗余封装。6.2 保持理性击退“追新恐惧症”AI领域几乎是按“周”在刷新的。今天“Prompt Engineering”明天“Function Calling”后天“Agent”。我最想对新手说的一句话是不要被新概念卷走把80%的时间花在基础工程能力上。所谓基础工程能力就是数据清洗、接口调用、并发处理、链路监控、成本统计、缓存这些老掉牙的东西。真正复杂的AI产品往往不是靠一个酷炫的Agent框架而是把基础的“检索、调用、复核、降级”围绕业务场景拼得滴水不漏。新框架再猛也只是给你拼图提供了一条捷径拼图逻辑还是得靠你自己想通。6.3 如何持续验证你的“AI工程”水平最后分享一个我的个人习惯每个月都构造一个小型但全新的业务场景给自己24小时从数据到上线做一个MVP。比如这个月做“会议纪要生成器”下个月做“Excel数据分析助手”再下个月做“电商评论情感分析”。场景越细越能暴露你的盲区。什么框架都行自己顺手就好。每做一次你会明显感觉到对“AI工程”的理解又深了一层——就像从泥潭里爬出来回头一看原来沼泽长什么样你已经看得清清楚楚。这就是从零开始最大的收获。