1. 先搞清楚AI工程到底在工程什么又是为谁服务的这几年AI工程师这个头衔被用得太滥了。有人写两个Prompt就说自己是AI工程师有人把模型封装成API也说自己在做AI工程。但我带过团队、面试过不少人之后越来越确信AI工程和算法研究是两种完全不同的事——前者要的是“在各种条件下都能稳定交付结果”的能力后者要的是“把某个指标在全球榜单上再刷高一点”的能力。如果你是从零起步先把这件事想清楚方向才不会跑偏。1.1 AI工程师和算法工程师的分工差异一个要精度一个要鲁棒性算法工程师的典型工作是调模型、改损失函数、洗数据集核心KPI是离线指标比如准确率、F1分数、BLEU分数。他们的战场在训练集群和实验记录里。AI工程师的战场完全不同。你要面对的是模型在用户真实输入下产生幻觉、API突然超时、上下文塞满导致输出退化、成本账单一天比一天高、某个用户的问题在你的知识库里明明有答案但检索就是捞不出来。AI工程的核心KPI不是你模型的SOTA成绩而是“端到端系统在真实场景下的可用率、准确率和成本可控性”。换句话说算法工程师追求“模型在测试集上更好”AI工程师追求“带着一堆不完美的模型把产品做成”。这个定位差异决定了你得懂一点算法但不需要成为算法专家——你更需要的是系统设计能力、数据工程能力、评估体系的搭建能力和对模型行为边界的敏锐直觉。1.2 AI工程要解决的核心问题集合我把自己过去几年在各类AI落地项目里遇到的问题归纳成了五类基本覆盖了AI工程的主要工作内容问题类别典型表现工程手段幻觉问题模型一本正经地编造不存在的政策条款检索增强RAG、引用溯源、约束解码延迟问题用户问一句话等半分钟才出结果模型分级、流式输出、缓存、推理优化成本问题一次复杂对话烧掉几百K Token上下文裁剪、语义缓存、小模型兜底可观测问题线上回答质量崩了但没人知道在哪一步崩的全链路日志、质量抽检、反馈闭环安全问题模型被提示词注入、输出涉敏内容、泄露内部知识输入输出过滤、权限隔离、护栏策略你会发现这些问题没有一个是“把模型换大一点”就能解决的每一个都需要系统工程手段去拆解、去兜底。这就是AI工程存在的意义。1.3 什么样的人适合从零开始走这条路我的建议是你不需要是数学天才但你必须是个愿意折腾的人。从零起步你至少要喜欢写代码、喜欢排查问题、对“为什么这个输出奇怪”有刨根问底的兴趣。数学门槛说实话没有想象中高——大部分时候你用到的只是矩阵乘法的直觉、比例缩放的理解和基本的概率思维。真正卡住多数人的不是数学而是工程基本功变量命名能不能坚持日志打得够不够全缓存失效有没有想清楚接口兼容性有没有考虑。这些基本功才是AI工程里每天都在用、也最容易被低估的东西。2. 从零起步的前置清单不用怕数学但有几个槛绕不过去我见过太多人一上来就问“我要不要先学三个月的线性代数再做AI工程”。我的回答一直是不用。你需要的是一边做项目、一边把缺的知识补上的能力。但有几个基础层面的东西是绕不过去的它们决定了你能不能顺利跑通第一个应用。2.1 编程与数据处理的底线要求语言上Python 是你绕不开的主语言。但别只学Python语法你至少得熟练以下这些东西用requests调用HTTP接口、处理JSON返回结构用pandas或纯Python处理批量数据做去重、过滤、格式化理解基本的异步编程概念因为调用大模型API时你经常会面临并发请求会用git管理代码会用pip / uv管理依赖环境除此之外我特别强调一个容易被忽略的能力SQL和结构化数据处理。很多AI应用要接企业的业务数据库你可能需要把订单表、用户表、商品表里的数据清洗出来构造成适合模型检索的格式。如果你连JOIN都写不利索这个环节会很痛苦。2.2 理解模型运行的物理事实Token、上下文窗口、推理开销这是我认为所有AI工程师必须建立的核心心智模型。大语言模型不是“程序”它更像一台“概率文本生成器”它一次能处理的文本量由上下文窗口决定但它实际能有效使用的信息量往往远小于窗口上限。举个例子一个上下文窗口为128K的模型不代表你把100K的内容全塞进去它就能记住。我实测下来当输入超过一定规模后模型对中间部分内容的注意力会明显减弱——这就是所谓的“Lost in the Middle”现象。上下文不是仓库不能只堆料上下文是注意力预算必须精打细算。还得理解Token这个概念。一个汉字大概等于1到1.5个Token价格和速度都按Token算。这意味着同一次问答你输入的Prompt越长延迟越高、费用越贵、出错概率越大。所以AI工程里非常重要的一个基本功就是“压缩输入”把最必要的信息用最精炼的方式组织进Prompt里。2.3 一套本地最小可行的学习环境怎么搭在学习阶段我强烈建议你搭一套“本地模型 API模型”双轨环境既能白嫖免费的模型体验又不至于在调试时烧掉太多API费用。具体做法是安装Ollama拉取一个7B级别的开源模型比如qwen2.5:7b或llama3.1:8b用于本地快速试错。注册一家大模型API服务商充值少量金额获取API Key用于体验更高质量的商业模型。用LangChain或直接写原生Python脚本我建议新手先写原生脚本理解了原理再上框架把两边都调通。这里插一句我踩过的坑本地模型看起来“免费又快”但7B模型的推理质量在复杂指令上明显不如商业模型。你用它做链路调试没问题但如果你用本地模型调出来的Prompt直接上生产环境效果往往会出问题。正确做法是本地模型调逻辑商用模型调效果。3. 工具链选择框架、模型、向量库、可观测平台怎么搭着用工具链不是越全越好也不是越新越好。我见过太多初学者把LangChain LlamaIndex ChromaDB Milvus FastAPI Grafana全拉起来搭了个“全家桶”结果连一次完整的问答都没跑通先花了两天解决依赖冲突。工具选型的核心逻辑是你当前的问题需要什么就上什么不需要的一律不碰。3.1 为什么我不建议一上来就All in某个全家桶这两年框架迭代极快LangChain的API说改就改LangGraph学起来又是另一套心智负担。如果你一上来就把所有抽象都压在框架上一旦框架升级你的应用可能直接崩掉。我的建议分两种情况学习阶段不要用框架封装得太狠的组件。直接用openai或各家的SDK写原生调用代码自己管理上下文列表和消息结构把大模型交互的基本逻辑吃透。产品阶段再用框架来做规范化流程。框架的价值不在于“省得写代码”而在于它把流程抽象成了可复用的模块比如检索节点、生成节点、记忆节点多人协作和后期调优更方便。3.2 模型选择的三个维度与我的推荐组合选模型不要只看“谁榜单分高”我通常只看三个维度指令遵循能力、延迟、成本。不同场景有不同的最优解场景类型推荐模型思路原因聊天、翻译、文案中档商用模型指令遵循好输出自然延迟可接受复杂推理、代码生成高档商用模型推理能力是硬门槛省得反复调优分类、抽取、格式化输出小模型或本地模型任务简单追求速度成本压到最低数据脱敏、私有部署本地开源模型数据不出域合规优先我个人的常用搭配是高难度任务走高性能模型简单任务走小模型的“模型分级路由”策略。比如先用一个小模型做意图分类判断问题复杂度复杂的才转发到大模型。这个做法能整体节省40%以上的成本而且线上响应速度会快很多。3.3 向量数据库的正确打开方式与常见误区向量数据库是RAG应用的热门组件但我发现很多人对它有个误解以为向量数据库是“知识库”把数据扔进去查询时它就能把正确答案捞出来。真相是向量数据库只负责“语义近似匹配”它不保证“正确匹配”。它做的是把你的一句话变成一串向量然后在库里找“方向最接近”的几段文本。如果知识库里相关段落本来就没切好或者与问题相关的信息被切到了两段里检索质量立刻崩。所以工具层面我倒不执着于用哪种向量库——ChromaDB做原型够用数据量大了再考虑Milvus、Qdrant或者云厂商托管方案。更关键的是你切块和嵌入的工作质量这部分我在下一章详细展开。4. 手把手复现一个RAG问答应用从数据清洗到首次返回纸上谈兵说了一堆这一章我们直接做一个能跑的RAG问答应用。场景选最经典的给一个使用手册做自动问答机器人。假设你手上有一份产品说明书用户会用自然语言问“这个设备怎么校准”“报错E-204怎么处理”你的机器人需要基于手册内容回答。4.1 场景和数据结构准备第一步永远是清洗数据。原始手册可能是PDF、Word、HTML混在一起的脏数据不能直接切块进向量库。我的处理顺序是统一转成干净文本PDF用PyMuPDF抽取Word用python-docxHTML用BeautifulSoup提取正文。去除页眉页脚、目录、页码、表格错位产生的乱序文本。按章节标题切成结构化文档保留标题层级信息。这一步看着不起眼但对最终效果影响极大。脏文本会产生大量“垃圾向量”它们不会让系统报错但会默默拉低检索准确率。4.2 切块与向量化的参数直觉切块参数是RAG里最有手感的操作。chunk_size块大小和overlap重叠长度怎么设要看你内容的粒度手册类文档段落边界清晰按“标题-段落”切块每块控制在300到500个Token重叠50到100个Token。长对话记录按对话轮次切保留上下文轮次。代码文档按函数或类切注释和定义尽量放在同一块。为什么需要重叠因为切片可能会把一句话从中间切开前后语义都变得残缺重叠能缓解这个问题。但重叠也不是越大越好重叠太多会产生大量重复内容的向量检索时容易出现“哪个都像哪个都不准”的情况。4.3 检索和生成的代码级实现下面是完整可跑的Python代码示例我用原生SDK加少量工具库实现方便你理解全链路。这里以OpenAI风格API为例你的代码里替换成任意兼容接口都能跑import os from openai import OpenAI import chromadb from chromadb.utils import embedding_functions client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL, https://api.openai.com/v1) ) # 初始化向量库与嵌入模型 embed_fn embedding_functions.OpenAIEmbeddingFunction( api_keyos.getenv(LLM_API_KEY), model_nametext-embedding-3-small ) chroma_client chromadb.PersistentClient(path./kb_store) collection chroma_client.get_or_create_collection( nameproduct_manual, embedding_functionembed_fn ) # 1. 文档入库 def ingest_documents(docs): ids, chunks, metadatas [], [], [] for i, doc in enumerate(docs): chunks.append(doc[text]) ids.append(fdoc_{i}) metadatas.append({source: doc[source], page: doc[page]}) collection.add(idsids, documentschunks, metadatasmetadatas) # 2. 检索 def retrieve(query: str, top_k: int 4): return collection.query(query_texts[query], n_resultstop_k) # 3. 生成把检索结果拼进上下文 def answer(query: str): hits retrieve(query) context_parts [] for i, text in enumerate(hits[documents][0]): source hits[metadatas][0][i].get(source, unknown) context_parts.append(f[{i1}] (来源: {source})\n{text}) context \n\n.join(context_parts) user_prompt f请仅根据以下资料回答问题。如果资料中没有相关信息请直接回答“资料中未找到相关信息”。 资料 {context} 问题{query} 回答 response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是一个严谨的资料问答助手。}, {role: user, content: user_prompt}, ], temperature0.2, ) return response.choices[0].message.content, hits print(answer(如何校准设备))这段代码的核心逻辑就三步把问题向量化去库里找相似文本、把找到的文本作为上下文拼给模型、模型基于上下文生成回答。没有魔法一切都很直白。4.4 让输出带上引用来源先解决看起来靠谱的问题RAG应用上线前我建议最先做的一件事就是强制模型输出引用来源。这个改动成本极低但对用户信任度提升极大。做法很简单要求模型在回答末尾以“参考资料”开头列出引用的编号前端再把编号对应到原始文档段落做成可点击的链接。这样即使模型偶尔答错用户以及你自己也能顺着线索发现问题出在哪里。提示这个功能不是为了装样子它是你后续排查线上质量问题最重要的定位工具。没有引用输出的RAG在线上出问题之后基本等于“盲人摸象”。5. 评估调优阶段从能回答到回答得可靠的实战指标跑通第一个Demo很容易难的是让回答稳定可靠。我见过太多团队止步在“demo演示效果不错”一上真实流量就原形毕露。原因很简单demo里的几个样例是你自己挑的而真实用户不会按你的剧本提问。所以从第一天起就要搭评估体系。5.1 离线评估集怎么构造你需要一批“问题和标准答案”的配对。注意这不是随便找几个问题就行而是至少准备50到100条有代表性的问题覆盖高频问题、边缘问题、模糊问题各三分之一。每条问题要标注“预期答案要点”不需要逐字逐句的标准答案但要有一个“必须覆盖的知识点”列表。把问题和预期答案固化成一个JSON或CSV文件放进代码库里像管理测试用例一样管理它。我推荐一个取巧的来源去翻客服聊天记录、用户反馈、社群高频提问这些才是真实用户需求的样本。凭空写的问题经常和实际脱节。5.2 召回率、答案准确率、引用准确率的计算方法RAG的评估不能只看“答得对不对”我把它拆成三个指标指标计算方式反映了什么召回率检索结果里包含正确答案相关段落的比例检索环节是否找对了资料答案准确率模型最终回答包含预期答案要点的比例生成环节是否答对了引用准确率模型引用的来源段落是否真的支持其说法是否一本正经地“编”引用实操里可以这样快速计算对每条评估问题人工把正确答案所在的源文档片段标出来然后跑检索看这条片段是否出现在TopK结果里这就是召回率的分子。答案准确率则靠人工或大模型裁判批量打分。5.3 用LLM做裁判时的偏见和规避方法人工评估50条问题一个人可能要半天时间团队大了还要统一标准很费劲。所以“用大模型评估大模型”几乎成了标配也就是LLM-as-a-judge。但我提醒你注意它的问题裁判模型会偏爱措辞华丽、结构完整的回答也会因为角度不同打错分。规避办法有三条评估时给出量化维度比如“是否包含知识点A”“是否包含知识点B”逐个打分不要用“总分”这种模糊标准。在同一批评估里把被评估模型的回答匿名化后打乱顺序避免模型认出自己的输出。关键样本一定要人工复核。机器评估负责“批量筛选异常”人工负责“最终裁定”。5.4 调优的顺序先检索后生成不要一上来改Prompt我在项目里见过一个常见错误回答质量不好第一反应就是去改Prompt。改来改去效果时好时坏最后发现根因是检索到的资料本身就是错的——Prompt改得再好也无济于事。我的调优标准顺序是先查检索结果打印出每次问答的Top5检索片段看看相关文本是否被捞出来了。如果没有去调切块方式、TopK数量、嵌入模型。再看上下文组装检查拼给模型的上下文是否足够紧凑、格式是否清晰、有没有互相矛盾的内容。最后才动Prompt把指令写得更明确约束输出格式限定回答范围。按这个顺序排查90%以上的RAG质量问题都能定位到确定的环节而不是靠运气瞎试。6. 部署上线与日常运维成本、延迟、幻觉监控一个都不能少开发环境跑通只是第一步把系统部署到线上、让别人用起来才是AI工程真正拉开差距的地方。很多项目挂在Demo阶段就是因为没人愿意处理部署和运维这些脏活累活。但AI工程这个岗位的价值恰恰就在这些环节。6.1 什么时候用实时API、什么时候用Batch、什么时候考虑微调模型调用方式的选择直接影响成本和架构。我的判断依据是“流量的实时性需求”和“任务的固定性”实时交互场景客服、助手走在线API流式输出要求低延迟。离线批量场景历史工单分类、内容打标走Batch API或异步任务队列价格通常只有实时API的一半甚至更低。固定领域、高频重复性极强的任务可以考虑微调一个专用小模型替换掉每个请求都使用的大模型成本可以再降一个数量级。微调不是万能的别一听“效果不好”就想微调。微调适合的是“格式固定、风格模仿、少量样例”类问题它不适合给模型注入大量新知识——新知识用RAG做成本低、更新快、可控性强。6.2 缓存与成本卡控语义缓存、限流、分级模型线上服务的成本结构里大模型调用费永远是最大头。我在团队里推行了三道成本控制手段第一道是语义缓存。把用户的问题向量化拿去缓存里找语义相似的历史问题如果找到且答案没变直接复用缓存结果。像“你们的退货政策是什么”这种高频问题命中缓存后一次Token都不用花。第二道是限流与熔断。给每个用户设置配额给每个功能设置并发上限防止异常流量把成本打爆。第三道是分级模型。前面提到过简单的分类、抽取、格式化任务用便宜的小模型复杂推理才用大模型。加上路由策略后系统整体的平均成本能下降非常明显。6.3 监控体系输入输出日志、质量抽样、用户反馈回路大模型应用的监控跟传统后端不一样。传统后端看的是错误率、响应时间、CPU使用率AI应用除了这些还要看“内容质量”——而内容质量恰恰是最难自动化的。我的做法是“三层监控”第一层可观测性监控。记录每一次请求的完整链路收到了什么输入、检索到了哪些片段、模型输出了什么、用了多少Token、耗时多少。出了问题能回溯到具体是哪一步。第二层质量抽检。按一定比例比如1%抽取线上问答记录用前文提到的LLM裁判批量打分异常分数进人工复核队列。第三层用户反馈闭环。在UI上加“满意/不满意”按钮不满意的记录自动进入人工标注池定期沉淀成新的评估集再回到调优环节。这层回路建立起来之后你的系统就不再是“上线后听天由命”而是越跑越稳越用越准。7. 我踩过的坑和总结的几条经验最后这部分分享几个我实际被坑过、也帮不少团队填过的经验希望对刚入行的你有参考价值。7.1 上下文塞得太满反而变傻我做过一个知识库问答前期为了“让模型有更多信息”把TopK从4调到8每次塞进好几千Token。结果线上反馈变差了——模型开始被大量边缘信息干扰甚至搞混了不同章节对同一问题的不同说法。后来把TopK降回3并加入“片段去重规则”效果立刻恢复。所以记住上下文是注意力预算不是硬盘空间。精简、精准、去重比“信息全”重要得多。7.2 本地模型或许省钱但它在复杂指令上会拖慢你的调试节奏我在一个私有化项目里用了本地部署的7B模型结果发现Prompts在不同模型间的迁移性没有想象中好。同一个指令商用模型一次就懂本地模型要反复拆解、降难度才能给出可用输出。这不是模型不行而是任务对推理能力的要求超过了小模型的承载范围。我的建议是在本地验证“链路是否跑通”用商用模型验证“业务效果是否达标”。如果宁可用本地模型硬扛那就要有认知你的Prompt设计和RAG流程可能要花更多功夫补偿模型的短板。7.3 评估自动化取代不了人工抽检LLM-as-a-judge确实帮我省了大量时间但我也吃过它的亏。曾经裁判模型给一个回答打了高分理由是“结构完整、语言流畅”但那条回答里的核心数据其实是错的只是错得比较隐蔽。从那之后我规定凡是涉及数据数字、政策条款、操作规范的答案必须人工抽检机器评估只做初筛。7.4 给刚入行的人的最后建议从零开始做AI工程不要被“每天都有新模型”的节奏吓到。模型是你的工具箱会不断更新但工程的底层逻辑变化并不快——评估、缓存、观测、调优这些基本功在任何一代模型上都要用。与其天天追新框架不如在一两个项目里把完整链路亲手走一遍。我第一次做RAG应用时也卡在过向量库依赖版本问题上也曾经为一个检索效果调了三天三夜但恰恰是这些“土办法”让我对每个环节的行为边界都有了直觉。希望你也能沉住气从一个小项目开始把它打通、打稳、打完整。这条路没有捷径但每一步积累的经验都会在后续的项目里成倍地回馈给你。