★ FEATURED ARTICLE 1. 为什么我决定把AI工程当一门手艺来练先交代下背景。我原本是做后端服务的干了五年多日常和分布式系统、数据库、消息队列打交道。这两年大语言模型火起来之后团队里开始有越来越多用AI解决问题的需求给内部知识库做问答、把客服工单自动分类、给产品做内容总结。最开始我也就是调调API把提示词写得花哨一点感觉好像AI也没那么难。但真正开始做正经的AI工程我很快发现两码事会调API和能交付一个可靠的AI系统之间隔着一条巨大的鸿沟。响应超时、token开销失控、检索出来的内容不对、同一条问题换个人问就崩、模型悄悄编造事实……这些问题在没有工程化思维的人手里每一个都像玄学。所以我决定从头系统地把AI工程这条链路打通不再靠零散的文章和片段式的教程。我给自己定的目标是不止是跑通而是能做到可复现、可评估、可维护、可上线。这个计划我大概执行了半年的时间中间踩了很多坑也整理出了一套还算清晰的学习路径。这篇就把它完整分享出来。如果你也是后端、前端或者测试转AI方向或者你是刚入门想找一条靠谱路线的学生又或者你已经在用API做一些小功能但总觉得不系统——这篇内容应该对你有用。我会把这条路拆成能力地图、学习阶段、实战项目、坑位清单和进阶方向五块来讲全部基于我真实的实践经历。2. 先想清楚AI工程到底在解决什么问题我见过不少人的误解AI工程不就是训练模型吗或者是把模型封装成接口其实都偏了。AI工程的核心是构建一个以模型能力为底座、但工程上完全可控的软件系统。换句话说模型只是系统里的一个组件和数据库、缓存、消息队列没有本质区别。你的价值不在于把模型跑起来而在于让整个系统稳定、可靠、可观测、成本可控地服务于真实业务。2.1 AI工程和算法研究的分工差异要理解AI工程的位置需要先分清三种角色的差别角色关心的问题交付物算法研究员模型能力能不能更强论文、实验报告、新模型算法工程师模型效果如何提升训练流程、效果调优AI工程师模型如何稳定服务业务可靠系统、应用功能、评估体系我认识不少算法转AI工程的人最不适应的就是工程上的脏活数据清洗、prompt版本管理、接口超时重试、线上的badcase分析。这些不做模型再强也落不了地。反过来纯后端转过来的优势是天然具备系统思维缺的只是对模型特性的理解。2.2 LLM时代AI工程的能力地图如果画一张AI工程师的能力地图大概是这六块编程与数据处理Python为主SQL是必须的数据处理pandas、JSON、CSV、正则是日常机器学习基础理解模型的训练、推理、输入输出逻辑不一定要会从零训练但要知道怎么用、怎么评估提示词与模型交互这是LLM时代独有的技能本质是和模型的沟通协议RAG系统构建知识库问答、文档检索、向量数据库这是目前AI工程落地场景最密集的方向模型服务化与性能优化部署、推理加速、缓存策略、异步处理、成本控制评估与监控离线评测集、在线指标、badcase分析、回归测试这个地图很重要因为它决定了学习顺序和方法。我当时列完这张表才意识到市面上大量的AI教程其实只覆盖了第3块而真正拉开差距的是第4到第6块。3. 从零到能干活的三个学习阶段有了能力地图下一步就是怎么学。我把自己的学习过程压缩成了三个阶段每个阶段有明确的目标和自测标准。不管你是刚毕业还是工作几年想转方向都可以按这个节奏走。3.1 阶段一编程、数据与Python生态约3周很多人一上来就啃《机器学习》教材我劝你先别急。AI工程里80%的时间在处理数据而不是在训练模型。你的Python能力需要能达到拿到一堆数据能快速清洗、转换、变成模型能用的输入的程度。我当时给自己定的练习目标熟练使用Python处理JSON、CSV、Excel、PDF文本等常见格式用pandas做基本的数据清洗、分组、聚合、合并能用正则表达式处理脏文本切分、抽取、去噪理解Python的async机制因为后面调用模型API会大量用到并发熟悉Docker基本操作能自己写一个简单的Dockerfile这个阶段不用刷太多题关键是每天写代码。我当时做了一个小练习把一份5000条的客服问答Excel清洗成一个给模型用的JSON训练集包含了去重、格式统一、字段抽取。这个练习做完Python和数据的底子就基本到位了。3.2 阶段二机器学习核心概念与评估思维约3周这个阶段不是让你去从头训练模型或者研究论文而是建立起模型怎么用、怎么评估的思维框架。你需要理解什么是训练集/验证集/测试集为什么划分什么是过拟合为什么模型在训练数据上表现好但在真实数据上翻车准确率、召回率、F1等基本指标的意义嵌入embedding的概念——这是理解向量检索的关键生成式模型和判别式模型的区别其中最重要的是评估思维。AI系统最坑的地方在于好像能用但不知道好不好。没有评估思维你根本没法判断一次修改是变好了还是变坏了。我当时买了两本书交叉看一本讲机器学习基础的一本讲评价指标的。看完之后我做了一件小事找了一个公开的分类数据集用现成库跑了几个模型对比它们的准确率和召回率。这不难但让我第一次直观理解了同一个问题用不同指标看结论可能完全不同。3.3 阶段三LLM应用开发栈约4-6周这个阶段是真正的AI工程核心。基础装备如下Prompt工程与结构化输出学习系统提示词、少样本示例、思维链提示最关的是一个点——让模型按固定JSON格式输出这直接决定后续程序能不能稳定解析LangChain或同类框架理解Chain、Retriever、Agent等核心抽象向量数据库选一个主流方案比如FAISS或Chroma跑通文本-向量-相似检索的全链路RAG完整实现文档加载、切分、向量化、索引、检索、与LLM拼接、生成回答简单的FastAPI服务把整套逻辑封装成HTTP接口加上超时、重试、错误处理这个阶段我花的时间最长因为概念不难但细节极多。比如文档切分切成多长最合适太长会超出模型上下文且检索粒度太粗太短则丢失语义上下文。自测标准很简单你能够不看教程从零写出来一个上传PDF - 基于内容回答问题的完整服务。如果能做到说明基础链路已经通了。4. 第一个端到端项目私有知识库问答系统这是我自己在这条路线上做的最重要的一步——一个端到端落地项目。项目不难但五脏俱全覆盖了数据、检索、生成、服务化、评估全链路。4.1 为什么选这个项目因为知识库问答是当前AI工程里需求最密集、技术栈最通用的场景。无论是企业内部的制度问答、客户支持自动化还是个人资料库检索本质都是同一套架构。做完这一个项目你可以很自然地把能力迁移到很多真实业务里。4.2 系统架构和关键选择整个系统的数据流是这样的文档 - 加载解析 - 切分成chunk - 向量化 - 存入向量库 | 用户提问 - 向量化 - 向量检索topK - 拼装prompt - LLM生成 - 返回回答我做选择时的核心考量有这几个切分策略我最终选了固定长度重叠窗口的方式每个chunk约300字相邻重叠50字。原因很简单基于语义的切分比如按标题、段落效果更好但通用性差不同文档结构差异太大。固定长度最稳也最容易调。重叠窗口是为了避免切断语义导致检索命中丢失。向量化方案本地用开源embedding模型保证隐私不走外部API。数据不上传外网在线服务延迟也更可控。检索策略先在向量库里做相似度检索取top20再做一次重排rerank取top5送入大模型。这比单靠向量检索的效果好不少因为向量相似度不够可靠加一个重排模型能显著提升准确率。4.3 关键代码与踩坑细节文档加载与切分def split_document(text: str, chunk_size: int 300, overlap: int 50): chunks [] start 0 while start len(text): end start chunk_size chunk text[start:end] chunks.append(chunk) start end - overlap return chunks这个函数看起来简单但实际使用中要注意切分不能把表格、代码块这种结构化内容切乱。我后来的处理是先按段落粗切再对超长段落做二次细分。向量化与检索from sentence_transformers import SentenceTransformer import numpy as np model SentenceTransformer(BAAI/bge-small-zh-v1.5) def embed_texts(texts: list[str]) - np.ndarray: return model.encode(texts, normalize_embeddingsTrue) def search(query: str, index_matrix: np.ndarray, top_k: int 20): q_vec model.encode([query], normalize_embeddingsTrue)[0] scores index_matrix q_vec # 余弦相似度 top_indices np.argsort(scores)[::-1][:top_k] return top_indices这里有个非常重要的细节向量必须要做normalize。我第一次做的时候没做归一化结果检索结果乱七八糟查了半天才发现余弦相似度的计算需要归一化向量不然长度会干扰相似度排序。prompt拼装与生成system_prompt 你是一个企业内部知识库助手。请严格基于给定的资料回答问题。 如果资料中找不到答案请直接回复资料中未找到相关信息不要编造。 引用资料时请标注来源片段编号。 def build_prompt(question: str, retrieved_chunks: list[str]) - str: context \n.join( f[片段{i}] {chunk} for i, chunk in enumerate(retrieved_chunks) ) return f基于以下资料回答问题。 资料 {context} 问题{question} 要求只基于给定资料回答不要使用外部知识。注意系统prompt里那句不要编造。这个约束不可能100%杜绝幻觉但能显著降低概率。我后面还会专门讲幻觉问题。4.4 这个项目真正教会我的三件事做完这个项目我最大的收获不在代码而在三个认知数据质量决定了系统效果的上限——文档本身乱七八糟、重复、过时你的RAG系统再好也没用。我在实践中花了大量时间做源文档的清理和更新机制。评估是迭代的前提——没有一个可以反复跑的评测集你每次改动都不知道效果是变好还是变坏。这个我在下一节详细讲。延迟和成本在架构阶段就要考虑——不是功能跑通之后才优化。比如检索策略不同调用LLM的次数和上下文长短完全不同成本差好几倍。5. 我在落地过程中踩过的坑和总结的经验这个部分是我最想写的。因为AI工程的坑往往不在模型不行而在工程没做好。我把踩过的坑整理成几类每一类都附带了具体的处理经验。5.1 评测集是AI工程的第一块地基我刚开始做RAG系统的时候完全靠自己问几个问题看效果。结果就是每次改完prompt或切分参数感觉都好像变好了但说不清哪里好了。后来我花了整整两天从业务资料里整理了一批真实的高频问题每条问题都写好了标准答案做成了大约80条数据的小评测集。每次系统有任何修改就用这80条问题全量跑一遍统计回答的准确率、关键词命中率、错误率。这个评测集还不完善但瞬间让我的工作方式从感觉主义变成了数据驱动。有一个具体的例子我在调切分chunk大小的时候分别试了200、300、500三种主观上感觉都差不多但评测集跑下来300字在准确率上明显优于另外两个。没有评测集这个优化我根本不会发现。关于评测集的做法我的建议是问题要来自真实用户场景不要自己设计刁钻问题答案以要点为单位记录方便自动比对评测集要持续扩充线上发现badcase就不断加入每次改动全量回归花不了多少时间但效果显著5.2 向量检索不等于语义理解重排是刚需这是我最想分享的一个认知。很多人以为向量检索距离近就意味着语义相似实际上它对关键词敏感、对长文本和复杂语义的理解非常有限。举个例子在知识库里有工资发放时间和绩效奖金计算方式两篇文章你问这个月工资什么时候到账向量检索可能同时命中两篇。靠向量分数根本没法区分哪个才是真正需要的。解决手段就是重排。我用了一个专门的cross-encoder重排模型先让向量检索召回20条候选再让重排模型对问题和每条候选的相关度精排取前5条送入大模型。效果好得明显我的评测集准确率大概有10个点左右的提升。5.3 上下文管理的隐藏成本很多人设计RAG系统的时候只想着把相关内容都放进去结果prompt越来越长。问题有三层成本层按token计费上下文越长越贵延迟层输入越长模型首字响应越慢质量层过长且包含噪声的上下文会干扰模型判断反而降低回答质量我实测过在相同问题下prompt从1000字涨到4000字接口延迟大概翻倍。所以我在架构里加了一个策略先粗筛大量候选再用较重的模型精挑细选最后只给大模型喂必要的上下文。宁可检索多做一点也要让prompt保持精简。5.4 关于幻觉工程手段比模型选择更可靠幻觉问题没有彻底解决方案但工程上能做很多事情prompt层面明确标注只基于资料回答资料中没有就直说没有引用层面要求回答时标注来源片段编号方便人工追溯和核验后验层面对回答做一致性校验检查回答中的关键信息是否能在检索到的资料里找到依据兜底层面低置信度时直接返回未找到答案而不是硬编我的经验是允许不知道是幻觉治理里最有效的一招。很多系统为了让用户体验好强行让模型回答所有问题结果就是幻觉爆发。在知识库场景里诚实说不知道的可信度远高于错误的自信回答。6. 下一步从能做demo到能交付系统走完上面这些你其实已经有了一个能跑通、能评估、能优化的完整RAG系统。但这只是AI工程的第一站。如果你想继续深入有以下几个方向可以选。6.1 从单一问答到Agent系统如果你需要的是根据用户问题判断是否要查询数据库、多轮对话中记住用户偏好、自动调用外部工具完成一个流程这时候你就需要引入Agent的设计。Agent系统的核心问题不再是怎么让回答更准而是怎么让模型在多个步骤之间做对决策。我自己的经验是Agent比RAG复杂得多排错难度也大得多建议先把RAG做扎实再上Agent。6.2 从本地实验到线上监控做demo的时候跑挂了重启就行。但线上的AI系统需要考虑输入输出日志记录方便badcase回溯响应时间和token消耗实时监控定期抽样检查回答质量人工审核最低不能低于一个阈值模型版本升级的计划与回滚机制我在线上跑了一段时间后最大的体会是——AI系统的可观测性比普通系统更重要因为你面对的模型输出是不确定的没有日志和监控你根本不知道系统在干什么。6.3 关于微调要不要学我的建议初期完全不用学微调。RAG prompt工程解决80%以上业务场景已经绰绰有余。微调的成本高需要GPU、数据标注、实验管理而且在大模型能力越来越强的趋势下微调的实际收益越来越小。在什么情况下需要微调比如你要模型模仿某种特定的写作风格、固定输出某种格式、或者RAG无法解决的大规模知识注入问题这时候再考虑。6.4 我现在的个人实践最后说说我目前的状态。我现在每次接到新的AI需求会先做三个动作一是厘清核心场景这是一个问答系统还是一个流程系统用户的核心痛点是什么 二是搭一个最小评测集哪怕只有十条问题也要先把好定义清楚。 三是先端到端跑通再优化绝不全链路设计完了再动手。这样做看起来少了一点精致感但效率极高。因为AI系统的效果实在太多变量只有先把最简版本跑起来才能知道真正的瓶颈在哪里然后有的放矢地去优化。这条路走了半年我最大的体会是AI工程并不神秘它就是把用模型这件事变得可落地、可量化、可持续迭代。你不需要成为算法专家但你需要成为一个懂模型特性的工程专家。把基础打好做一个完整的项目建立自己的评测体系——你就能成为那个靠谱的能把AI落地的人。
阅读完成 · 觉得有帮助？
