直接说结论别再把“会用ChatGPT”当成AI能力了。真正的分水岭是你能否把一个大模型API变成一条别人也能维护、能评估、能上线的数据流水线。这两年我陆陆续续帮团队带过不少人也踩过不少坑发现绝大多数人缺的不是模型知识而是“ai-engineering”里那套工程化的思维和方法论。这篇文章我就把从零开始构建AI工程能力的主线梳理一遍从能力拆解、技术选型到亲手搭一个可运行的RAG问答系统再到生产环境里那些文档里不会写的排查经验一次讲透。适合刚入门想做AI应用开发的工程师也适合已经在调API、但总觉得项目像“一次性实验”的人。1. 先从零开始理解AI工程到底在解决什么问题1.1 别把AI工程等同于“调接口”很多人拿到OpenAI或国内大模型的API Key之后第一反应是写个脚本把问题拼进Prompt然后等返回结果。这个动作本身没有问题但它只是AI工程最外层的那个壳。真正的工程问题是当这个脚本变成一个产品之后你如何保证它回答得稳定、成本可控、效果可测、出问题了能定位。这一连串问题才是ai-engineering的核心。打个比方调API就像拿到一台很厉害的发动机但AI工程是造车——你不光要把它装进车架还要解决散热、转向、刹车、仪表盘以及用户踩油门时那一下的平顺感。没有这层工程化能力再强的模型也是实验室里的展示品不是能交付的产品。1.2 一条完整的学习主线上下文、生成、检索、评估、迭代从零开始学AI工程我建议不要把精力平均分配给每个名词。真正要抓住的主线是“上下文工程”这条线。大模型本质是一个无状态的函数它不知道你是谁也不记得昨天聊过什么。AI工程做的事情说白了就是把用户的问题、背景知识、工具能力、历史信息组合成一份高质量的上下文喂给模型再把模型的输出拉回你的业务系统里做校验和落地。所以整条学习主线可以拆成五个环节上下文组装、生成控制、知识检索、结果评估、迭代调优。你去看招聘网站上那些AI工程师的岗位描述不管写的是RAG、Agent还是微调底层都是这五件事在不同场景里的组合。先把这条主线走通再去追那些眼花缭乱的新框架心里会有底得多。1.3 不同基础的人应该怎么规划学习路径如果你是个后端工程师优势在于工程习惯好重点补的是“大模型输入输出有什么脾气”这部分——Token怎么算、参数怎么调、Prompt为什么不稳定。如果你是个算法工程师优势在于模型理解深但要补的是系统设计——缓存怎么加、服务怎么拆、数据怎么流转。如果你只是产品经理或者刚入门的学生我的建议更直接先手写一个不依赖任何框架的RAG小项目再去看LangChain这类工具的源码最后再回来做自己的项目。我发现一个规律凡是只靠框架拖拽搭过演示的人遇到线上问题普遍懵凡是亲手写过一遍请求、拼过上下文、自己写检索逻辑的人哪怕代码丑遇到问题也总能一步步查下去。这个差别就是“会用”和“能做工程”的分界线。所以这篇文章的实操部分我会刻意不依赖于重量级框架先让你看清楚底层到底发生了什么。2. 技术选型从零开始的第一个十字路口2.1 模型层选型不是越强越好而是匹配场景从零做AI工程第一个绕不开的选择是模型。这里我不做具体的产品推荐但给几条选型原则。第一先看“上下文窗口”和“价格/质量的平衡点”。如果你做的是客服问答中档模型往往性价比远高于旗舰模型如果你想做复杂推理或长文档分析那窗口和推理能力就是硬指标。第二同一道题不同模型的输出风格差异很大你必须用自己的测试集跑一遍而不是看榜单分数。我在实际项目中就遇到过某个模型逻辑能力很强但输出格式极其不稳定最后不得不加一层JSON校验和重试逻辑代价不小。第三也是容易被忽略的模型的版本稳定性。厂商更新模型后你的产品表现可能一夜之间变化。所以在选型时我会优先考虑支持固定版本号的API或者干脆通过网关层把模型版本锁死避免“被动升级”。2.2 检索和向量库从零搭建时的取舍RAG检索增强生成是AI工程里最常用到的模式。它的核心逻辑是把外部知识切块、向量化、存进向量库用户提问时找出最相关的几个片段拼进Prompt让模型参考。向量库怎么选我的经验是分阶段。第一阶段数据量在几万条以内直接用内存式的向量索引就够了比如faiss或者chroma零运维成本跑在本机就能验证效果。第二阶段数据量上来并且需要多人协作、权限管理时才考虑上独立的向量数据库。切块策略上我从零开始实践时走过弯路一开始按固定字符数硬切导致语义被切断检索质量惨不忍睹。后来我改成“按语义结构切块”——段落优先、再按最大长度截断、同时保留相邻块之间的重叠。这样检索召回率明显提升。具体参数后面实操部分我会给出可以直接抄的配置。2.3 框架选型什么时候该用LangChain什么时候不该用这是新手最容易纠结的问题。我的看法很明确学框架之前先自己手写一遍完整链路。手写一遍你才会理解LangChain里那堆抽象——Chain、Agent、Tool——到底是为了解决什么痛点出现的。当你手写过一遍之后再用框架就会很舒服因为你看到的不再是“魔法”而是“封装”。我自己在项目中的使用习惯是轻量场景直接手写链路复杂到需要多工具协调、多步决策时才借助框架来收敛代码结构。依赖抽象的同时保留自己控制关键环节的能力这条原则值得一直记着。2.4 评估选型从零就该打造的“黄金数据集”AI工程和传统工程最大的不同在于模型输出是概率性的。你不能用“跑通一次”来衡量正确必须建立一套评估机制。从零开始评估不用做得很重但有三样东西必须建起来一是“黄金数据集”也就是几十到几百条覆盖典型场景的输入输出对二是“离线评估脚本”能批量请求模型并和预期结果比对三是“线上日志”能把每次真实请求的输入、输出、评分记录下来。这三样东西是你迭代的基石。没有它们你调Prompt就是在盲人摸象——改一次感觉好了过两天又坏了根本不知道为什么。3. 实操从零手写一个可运行的RAG问答系统3.1 需求定义与数据准备我以一个“公司内部文档问答机器人”为例走一遍完整流程。这个场景最有代表性因为大部分AI工程入门项目都是这类资料是现成的问题是开放式的用户需要的是“基于这些文档的回答”而不是模型瞎编。先把数据准备好。我用的是一批Markdown格式的运维手册大概几百个文件。这里有个关键步骤清洗。Markdown里的代码块、表格、重复的导航文本如果不处理切块之后会产生大量无效片段直接影响检索质量。我实践下来的处理顺序是去HTML标签、去掉重复的页眉页脚、统一换行符、把表格转成“键值对”形式的纯文本。清洗这块很多教程一笔带过但实际它对最终效果的影响能占到三成。宁可多花一小时清洗也不要让脏数据流进后面的链路。3.2 检索链路embedding、切分与召回接下来是检索链路我按步骤拆开讲。第一步选Embedding模型。如果你在中文场景直接考虑开源的中文向量模型比如bge-large-zh或者更轻量的bge-small-zh。选它的原因很实际中文效果更好且本地部署无API成本。用bge-small-zh生成的向量维度是512维十万条文档大概占用不到1GB内存个人电脑跑完全无压力。第二步切块。我用的参数是chunk_size 300字符、overlap 50。为什么是300因为中文一句话平均20到40个字符300个字符大约是8到10句话语义相对完整作为“一个知识点”的大小很合适。重叠50个字符是为了避免切在句子的关键连接处。这里有一个很实用的细节按句号、问号、感叹号先切句再按300字聚合句子成块而不是直接硬切字符。这样做能显著减少语义断裂。第三步向量化和存储。把每个块丢给embedding模型生成向量连同原文、文件名、块序号一起存进向量库。此时你的库里就有了“可检索的知识单元”。第四步召回。用户提问后把问题转成向量在库里做相似度检索取top-k个最相关的片段。这里k一般取3到5不是越多越好——片段太多会稀释模型的注意力还增加Token消耗。做RAG初期最容易犯的错就是贪婪地取top-10结果模型反而不知道该看哪一段。检索这块我补充一个进阶操作召回时不要把“相似度最高”当作唯一原则可以在检索结果里加一点“多样性”——比如按来源文件分组每个文件最多取1到2个片段。原因很简单用户问“磁盘满了怎么办”可能一份文档里连续几段都在讲同一件事全取出来就是信息冗余。让模型看到不同来源的多个思路回答质量反而更高。3.3 生成链路上下文组装与提示词模板检索到的片段要组装成Prompt。这一步是AI工程“说人话”的关键环节。我常用的模板骨架是这样的先给模型一个身份和任务描述然后把检索到的知识片段用清晰的标记包起来再给用户问题最后加输出约束。用伪代码来表示组装逻辑大概是这样的结构system: 你是一名技术支持工程师请严格基于给定的知识片段回答用户问题。 如果知识片段中没有相关信息请直接回答“根据现有资料无法确认”不要自行猜测。 knowledge: [1] (来源: 运维手册-磁盘管理.md) ... [2] (来源: 运维手册-故障排查.md) ... question: 服务器磁盘空间不足应该怎么处理 要求 - 回答不超过200字 - 引用相关片段编号这里有个非常关键的细节知识片段一定要带“来源标记”。不要只给模型一段光秃秃的文本你要让模型知道它看的是什么、来自哪里。加了来源标记后模型的回答会更倾向“引用原文”而不是自由发挥这也给你后续做引用溯源留下了数据基础。另一个参数要点是temperature。问答场景我一般设置为0.2到0.3太低容易变成机械复读太高容易幻觉。做代码生成、创意文案时再根据需要调高。这个参数是AI工程里最值得反复实验的旋钮之一。3.4 评估与迭代让系统越用越准系统跑通之后立刻进入评估阶段。我强烈建议你从第一天就记录所有线上问答的日志并把“用户是否点了赞/踩”或“答案是否有用”作为反馈信号存下来。离线评估的方式也很朴素准备30到50个典型问题每轮修改后批量跑一遍人工打分对比前后的分数变化。打分维度我常用三个相关性答案是否切题、忠实度是否基于给的资料而非编造、完整性用户关心的点是否都覆盖了。有一件事值得警惕不要因为单条回答变好了就开心要看同一批测试集上的整体分数。修改Prompt最怕的就是“按上一个错误答案调参”最后变成了对着测试集过拟合。我每隔一段时间就会往测试集里加新问题防止系统只会在旧题上表现好。4. 常见问题与排查技巧实录4.1 上下文溢出与Token失控做AI工程你迟早会遇到“Token用完了”的报错。这通常发生在两种场景一是用户粘贴了超长文本二是你的RAG检索片段拼得太多。我排查时第一步看日志里的Token统计——是输入超了还是输出超了。输入超了优先压缩检索片段降低chunk_size或不相关片段过滤输出超了检查max_tokens参数和回答长度约束。第二步看有没有冗余内容被塞进了上下文比如重复的指令、多余的示例。很多长文本场景真正有效的知识只有中间一段前后都是噪音。这里分享一个实用技巧给Prompt设置“预算意识”。假设模型窗口是8K我一般预留2K给输出剩下6K给输入。在拼装检索片段时动态计算总Token量超过阈值就丢弃相似度最低的片段。这个逻辑不复杂但能让你的系统在极端输入下依然稳定而不是直接报错。4.2 回答幻觉模型开始“一本正经地胡说”幻觉是RAG系统最头疼的问题。排查顺序如下先看“检索是否命中了相关内容”。如果检索回来的片段本身就是弱相关的模型就会用自己的常识补全这是幻觉的第一来源。我见过不少案例问题出在Embedding模型对专业术语理解不到位导致召回了一堆表面相似但实际无关的文本。再看“Prompt是否给了模型编造的空间”。如果你只写了“回答问题”而没有“基于给定资料”模型的自由发挥程度会高很多。我实践中最有效的约束手段是在Prompt里显式声明“如果资料中没有答案请直接说明无法回答”同时把输出格式限定为“先给结论再列出依据片段编号”。最后上线前一定要跑一遍“对抗性测试”——故意问一些库里根本没有答案的问题。一个合格的系统在面对这类问题时应该“老实认怂”而不是强行给出一段顺滑的编造。4.3 检索质量差召回了一堆不相干内容这个问题的排查点有三个方向。第一检查数据清洗是否做干净了。如果检索回来的片段带着大量重复导航文本和混乱格式说明清洗环节漏了。第二检查切块参数是否合理。chunk_size过大一个块里混了多个主题overlap过小关键信息正好被切断。第三检查查询时的top-k设置。如果k值太大后面几名的相似度已经很低纯属噪音。一个经常被忽略的优化手段是“查询改写”。用户的问题往往是口语化的比如“那个东西坏了咋办”而文档里写的是“设备故障处理流程”。直接拿用户的原文去检索效果一定差。可以在检索前加一步用一个轻量模型把口语化问题改写成“关键词组合”或“书面语检索式”。这一步对检索质量提升非常明显代价就是多一次模型调用但值得。4.4 成本飞涨API账单让人肉疼从零做AI工程成本失控几乎是每个人的必修课。我的省钱经验按优先级排序第一加缓存。相同或高度相似的问题直接命中缓存不再调用模型。相似度缓存可以用Embedding做设置一个相似度阈值命中就返回上次答案。第二压缩Prompt。减少多余指令、缩短历史对话轮数、用更精简的系统提示都能直接降Token消耗。第三用“规则路由”分流简单问题。如果系统能判断用户问的是“你好/谢谢”这类寒暄根本不用调模型直接返回固定文案即可。成本优化的核心思想是不要让模型做它不该做的事。能用规则解决的绝不用模型能用小模型解决的绝不用大模型。这套分流思路在大流量场景下能把成本降到原来的十分之一。5. 再往前走一步从Demo到可交付的AI产品5.1 可观测性建设别让系统变成黑盒Demo阶段跑通功能你就开心了。但产品一旦上线模型输出的不确定性会让“排查问题”变成一场灾难。所以从第一天起就要记录三个东西完整请求日志包括Prompt快照、Token消耗统计、响应延迟。有了这些你才能回答最经典的三个线上问题为什么这条回答质量差看当时的Prompt拼了什么、为什么成本暴涨看哪个环节Token消耗最多、为什么变慢了看是不是检索环节拖了后腿。我见过太多团队出了线上问题连当时的Prompt长什么样都查不到只能靠肉眼复现效率极低。5.2 多步Agent的工程控制如果你开始做Agent——也就是模型自己去调用工具、做多步决策——那就进入AI工程的深水区了。我的经验是控制比智能更重要。这意味着两件事一是要给Agent的每一步都加“护栏”比如工具调用的参数校验、最大步数限制、超时熔断二是要把Agent的决策过程记录下来。我在Agent里会给每一步编号要求模型在调用工具前先输出“计划”这样一旦跑偏你能定位到是第几步的决策出了问题。很多人一上来就追求“全自动”结果Agent自己在沙箱里绕圈子、反复调用同一个工具。我的建议是先做“半自动”每次工具调用前让用户确认。虽然体验笨一点但可控性大幅提升。等链路成熟了再把确认步骤逐步去掉才是最稳妥的路径。5.3 面对模型更新把变化当成常态最后聊聊心态问题。在AI工程这个领域唯一不变的就是变化。底层模型每几个月就有新版本框架接口说改就改今天好用的Prompt明天可能就失效。我现在的应对方式是尽量把业务逻辑与具体模型解耦。所有模型调用都走统一接口层外层代码不关心底层是GPT还是开源模型Prompt模板集中管理版本化存放改一条Prompt像改配置一样能追溯关键效果指标持续监控一旦发现模型升级或接口变更导致指标下降能第一时间发现并回滚。这个领域最好的生存策略不是追着最新模型跑而是把工程体系搭稳让模型成为体系里一个可替换的组件。我自己绕了不少弯路才想明白这个道理写在这里希望能让后来的人少踩一些坑。6. 我最后想补的几句实在话学AI工程这件事最大的门槛其实不是技术而是“接受不确定性”的心态。传统开发里代码跑不通就是跑不通错因是确定的但大模型应用同样一个输入两次输出可能不一样效果还忽好忽坏。很多人卡在第一步就是因为他们受不了这种不可控感。我的建议是从最小闭环开始不要一上来就想做一个完美的Agent平台先拿一个具体场景手写一个带检索、生成、日志记录的最小RAG系统跑到能稳定回答为止。这个闭环会逼你走完上下文组装、检索、评估、迭代的完整链路。走完之后你对ai-engineering的理解会有一个质的飞跃。再就是一定要保持记录的习惯。每一个改动、每一次效果变化、每一组参数都写下来。我做这个项目时最庆幸的一件事就是从第一天开始维护一份“调参记录文档”——哪些Prompt改过、当时效果如何、后来为什么又改了。这份文档现在成了团队里新人的入门教材也让我自己少做了很多重复实验。最后送大家一句话做AI工程不是去追那些日新月异的模型而是把“用模型解决问题”这件事本身做成一个可靠的系统。把基础链路走扎实你手里的模型无论换多少代你都有能力迅速接住。