先聊个比较实在的话题现在到处都在说 AI 工程、AI 应用开发打开招聘软件满屏都是“大模型工程师”“AI Agent 开发”这类岗位可真正能把一条 AI 应用从零到一、从代码到线上跑通的人其实比想象中少很多。原因很简单市面上绝大多数教程只教你调 API、套模板最多教你招一个聊天机器人但真实工程里你遇到的问题往往是回答质量不稳定怎么办、检索出来的东西不对怎么办、模型响应太慢怎么办、上线之后怎么观察它有没有退化。我把“ai-engineering-from-scratch”这条路线从头到尾走了一遍从对一个语言模型只知道“输入一句话就能返回一句话”到做出带知识库的 RAG 问答、带工具调用的 Agent再把它容器化部署上线做监控评估。这篇文章就是把这条路线上的核心知识点、选型逻辑、实操步骤和踩过的坑一次性讲清楚希望能帮你少走几个月的弯路。1. 先想清楚AI 工程到底在解决什么问题1.1 它和“调 API”不是一回事很多人有个误解AI 工程就是拿大模型 API 拼聊天窗口。如果真这么简单那这个岗位就不会开出这么高的薪资了。我理解的 AI 工程是把一个大模型从一个“试用阶段的东西”变成“稳定生产系统”的全部工作。它至少包含五个板块提示工程把业务需求翻译成模型能理解、能稳定执行的输入。检索增强RAG把外部知识、私有数据交给模型让它回答得准而不是瞎编。Agent 能力让模型不只是“说”而是能调工具、执行动作、完成多步任务。部署与推理优化把模型放到服务里控制延迟、吞吐和成本。评估与监控用数据说话保证每次改动不会让效果变差。这五块不是割裂的是一条完整链路。从零开始学的时候千万别光抓着“提示词”这一个点死磕提示词是基本功但不是全部。1.2 从零开始的正确路径是什么我见过太多人一上来就啃 Transformer 论文、从头复现 LLaMA结果被数学公式劝退然后就没有然后了。作为一个过来人我给的建议是**“应用驱动倒推知识”**先跑通一个最简单的调用。做一个带知识库的问答系统理解 RAG。再做带工具调用的 Agent理解模型怎么和外部世界交互。然后把它部署成服务理解并发、延迟、成本。最后回来补基础比如注意力机制、token 原理、采样参数这时候你再看理论会觉得全都对得上。这条路最大的好处是每个阶段都有看得见的成果人不容易放弃。2. 入门技术栈与工具选型别被“全家桶”忽悠了2.1 提示工程先打底这是性价比最高的投入我至今觉得提示工程是 AI 工程里“投入产出比”最高的一项技能。不需要显卡不需要买课不需要复杂的代码把模型的行为逻辑理解透就行。核心要掌握的四个方法角色设定给模型一个明确的身份和行为边界。少样本示例Few-shot与其解释一堆抽象规则不如直接给 2-3 个输入输出例子。思维链Chain-of-thought让模型“先分析再输出”对复杂推理任务效果提升非常明显。结构化输出用 JSON Schema 或 XML 标签约束输出格式方便后续代码解析。我自己写提示词有个习惯先写“你是做什么的、你能做什么、不能做什么”然后给 2 个示例再进入正式输入。不要写“请”“亲爱的”这些废话模型不需要礼貌需要的是清晰。2.2 应用框架怎么选别一上来就上框架现在主流的框架有 LangChain、LlamaIndex还有 Spring AI 这类偏向 Java 生态的如果你的团队是 Java 技术栈Spring AI 很值得关注。但我的建议是前两周亲自用裸 Python 代码调模型不要碰框架。因为你只有先用纯代码体验过“把文本切开、转成向量、塞进向量库、搜出来、拼给模型”这个过程你才能真正理解框架帮你省了什么工作量。不然框架对你来说就是一个黑盒出问题你完全不知道从哪排查。之后再用框架也不是全盘照抄。LangChain 我常用到的其实就那几个DocumentLoader、TextSplitter、Embedding、VectorStore、Retriever、ChatPromptTemplate。其余概念网上吹得天花乱坠实际生产里用得很少。2.3 模型部署和推理工具链是分水岭很多人做 demo 很流畅一到部署就卡壳。这里我给你一条可以直接照抄的选型路线场景工具说明快速实验 / 个人项目云端模型 API成本低、上手快适合验证想法私有化部署 / 数据敏感vLLM 或 TGI高吞吐推理引擎兼容 OpenAI 接口协议中小团队推理服务vLLM FastAPI部署灵活可控性强大规模集群KServe K8s自动伸缩、多模型管理运维成本高这里我特别推荐 vLLM它在吞吐优化上做得非常激进连续批处理、PagedAttention 这些技术能让同样一张显卡跑出大几倍的请求量。后文我会专门演示怎么用它。3. 实操从零搭一个 RAG 知识问答系统3.1 整体设计思路假设咱们要做一个“公司内部规章制度问答机器人”。传统的做法是把文档放在某个目录里让人自己翻现在我们要让模型基于文档内容来回答。整体流程拆开就三步灌知识索引、搜知识检索、生成答案生成。每一步都有对应的工程决策。我画一个最简链路给你看读入 PDF / Word / 网页文本按语义切分成长度合适的片段每个片段用 Embedding 模型转成向量向量存入向量数据库用户提问时把问题转成向量做相似度检索把检索到的片段和问题拼接成 Prompt模型综合上下文给出答案并标注来源3.2 文档切分细节决定 RAG 的上限说实话RAG 系统效果烂八成问题出在切分上而不是模型上。切分太粗片段里包含大量噪声检索召回不精确切分太细单个片段语义不完整模型也答不到点上。我在实际项目里常用的策略是**“按结构优先、按长度兜底”**如果是 Markdown 或带标题的文档先按标题层级切尽量保证一个二级标题下的内容作为一个整体。如果没有结构用固定长度切中文一般 300-500 字一个 chunk重叠 50-100 字。不要小看重叠部分它能避免句子被拦腰截断导致语义丢失。一个简单的切分代码骨架from langchain_text_splitters import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size400, chunk_overlap80, separators[\n\n, \n, 。, , , ., !, ?, ], ) chunks splitter.split_text(long_text) print(len(chunks))这里的 separator 顺序很重要先按段落再按句子最后按单词。这个顺序能最大程度保留语义完整性。3.3 Embedding 与向量库选型Embedding 模型负责把文本变成向量。选型标准有三个维度、中文效果、部署成本。目前中文场景比较常用的是 BGE、M3E 系列的 Embedding 模型效果不错而且可以在本地跑。如果你的数据以英文为主OpenAI 的 text-embedding-3-small 也够用。注意一个坑检索用的 Embedding 模型要和生成模型区别对待它不追求“会说话”只追求“语义距离准确”。向量数据库的选择我从三个档位给你参考档位方案适用场景入门Chroma / FAISS个人项目、文档量百万以下生产Milvus / Qdrant需要高并发、复杂过滤轻量运维PostgreSQL pgvector团队已有 PG不想引新组件我个人最喜欢 pgvector。因为它不需要单独维护一套数据库业务数据也在 PG 里直接就能做 SQL 级别的过滤比如“只检索部门 A 的文档”非常方便。3.4 检索不是搜出来就完事检索之后要不要重排序我的答案是如果你的数据量超过 1 万条强烈建议加。第一次向量检索召回 Top 20再用一个轻量的 Cross-Encoder 模型对这 20 条做精确打分取 Top 5 给到模型。这样做的好处是第一阶段向量检索负责“宽进”把候选尽量捞全第二阶段精排负责“精选”把真正相关的排到前面。这里附一个完整 RAG 检索端代码from qdrant_client import QdrantClient from qdrant_client.models import Distance, VectorParams from bge_embedding import BGEEncoder # 伪代码按你的模型导入 encoder BGEEncoder() client QdrantClient(hostlocalhost, port6333) # 建集合 client.create_collection( collection_namecompany_docs, vectors_configVectorParams(size768, distanceDistance.COSINE), ) # 写入向量 points [ {id: i, vector: encoder.encode(chunk), payload: {text: chunk}} for i, chunk in enumerate(chunks) ] client.upsert(collection_namecompany_docs, pointspoints) # 查询 query_vec encoder.encode(请假流程是什么) results client.search( collection_namecompany_docs, query_vectorquery_vec, limit20, )3.5 生成环节把 Prompt 拼对答案质量翻倍很多人以为生成环节就一段用户问题、一段检索内容拼一起就行了实际上你把顺序和结构控制好效果差异非常大。我的 Prompt 模板长这样你是一家公司的行政助手请根据【资料】中的内容回答用户的问题。 要求 1. 只能基于资料回答不要编造。 2. 如果资料里没有答案明确说“资料中未找到相关信息”。 3. 用简洁的中文回答可以分点。 4. 最后一行附上你参考的资料编号。 【资料】 [1] 请假三天以内需部门主管审批... [2] 请假三天以上需分管副总审批... 【用户问题】我要请一周假应该找谁审批这句话其实是 RAG 组合的正确姿势把检索到的内容放在用户问题之前。实测下来上下文放在前面比放在后面模型的回答稳定性更高。4. 再进一步把 RAG 升级成 Agent4.1 为什么 RAG 还不够RAG 能解决“知识型问答”但它有个明显的天花板它只会查不会做。比如用户问“帮我查一下这个月的服务器账单超过预算就发邮件给财务”。这里涉及到数据库查询、判断逻辑、发邮件这三个动作这不是简单的检索生成能搞定的你需要 Agent。Agent 的核心思想叫ReAct模型交替进行“思考Reasoning”和“行动Acting”。模型可以请求调用工具工具返回结果后再决定下一步直到任务完成。用一句话说RAG 是让模型“知道得多”Agent 是让模型“做得了”。4.2 一个最小 Agent 的长什么样以 OpenAI Function Calling 或通用工具调用协议为例模型输入不再是纯文本而是带有一组“工具说明”。模型在回答时会生成一个结构化的调用请求我们解析这个请求执行对应代码把结果返回给模型。一个工具调用的最小实现长这样import json from openai import OpenAI client OpenAI() tools [ { type: function, function: { name: get_server_bill, description: 获取指定月份的服务器账单金额, parameters: { type: object, properties: { month: {type: string, description: 月份如 2026-01}, }, required: [month], }, }, } ] messages [{role: user, content: 一月份账单是多少}] response client.chat.completions.create( modelgpt-4o, messagesmessages, toolstools, ) # 看模型是否想调用工具 print(response.choices[0].message.tool_calls)经典的坑是模型说出“我要调用 get_server_bill 工具”但代码里根本没有对应的执行逻辑或者工具名称写错匹配不上。你需要在工具层做一层注册表把函数名和实际函数绑定并加超时和异常处理。4.3 规划、记忆与人工兜底Agent 在真实生产环境里比 RAG 难得多。核心难点在三个地方规划失败模型在复杂任务上容易漏步骤或者步骤顺序不对。我建议把复杂任务拆成子任务别指望模型一次规划到底。记忆混淆多轮对话中模型容易把当前轮次和之前轮次的信息混在一起。每个 Agent 会话要有独立的记忆空间按轮次组织。不可逆操作涉及发邮件、删除数据、扣款这类高风险动作一定要设计“二次确认”。我的做法是工具调用先进入“待确认”队列由用户在前端点击确认后才真正执行。Agent 不是玩具它需要你比做 RAG 的时候更谨慎。5. 部署、评估与监控让应用真正能上线5.1 模型推理服务化如果你用的是云端 API这部分很简单就是常规的 Web 服务开发。但如果你的场景要求私有化部署那就绕不开推理引擎。我强烈建议用 vLLM 部署开源模型。它极其适合中文场景也支持 OpenAI 兼容接口意味着你本地起一个服务后代码里只需要改一个 base_url 就能把 API 调用平滑迁移到本地模型。启动一个 vLLM 服务很简单pip install vllm vllm serve Qwen/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.85 \ --max-model-len 8192启动后你的代码里只需要from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) resp client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[{role: user, content: 你好}], )前后端代码一行不改就能切换模型这个统一接口标准的好处你越用越能体会到。5.2 评估没有指标改动就是开盲盒我一直有个观点没有评估体系的 AI 项目等于没有刹车系统的车。你今天换了一个 Prompt感觉回答“好像变好了”但你不知道是不是只是这一条变好了另外十条变差了。我初期踩过最大的坑就是靠感觉调优今天调调这个明天换换那个效果时好时坏。后来我学乖了花一天时间建了一个 100 条问题的评测集每条问题包含标准问题参考答案关键词期望来源文档之后每次改动跑一遍评测集统计几个关键指标指标含义衡量方式命中率回答里是否包含参考答案的关键信息关键词匹配或 LLM 评分幻觉率回答里是否有材料外的编造内容人工抽检 引用溯源检索召回正确文档是否被检索到计算命中比例跑评测集这个过程很枯燥但是它能帮你守住底线每次改动至少不会让整体效果倒退。5.3 线上监控日志比你想的重要上线第一天你觉得一切完美。第三天有用户反馈回答开始出错。你查了半天发现是文档库被误更新了。这种事故我见过不止一次。所以一个 AI 应用上线前必须把日志做全。我自己的日志体系分成三层请求日志用户问题、完整 Prompt、模型输出、耗时、token 数。链路日志检索了哪些文档、每个文档的分数、重排序结果。反馈日志用户是否有点赞/点踩、是否复制了回答、是否有二次提问。有了这些数据你才能做三件事定位问题、分析用户真实需求、持续迭代。否则它就是个黑盒。6. 常见问题与避坑实录6.1 高频问题速查表问题现象根本原因解决方案回答内容跟给的材料无关检索失败向量召回质量差检查 Embedding 模型、增加重排序、调整切分粒度回答还没材料就结束了Prompt 对资料引用约束太弱强化“只能依据资料”的指令并限制输出长度同一问题多次回答不一致采样温度太高把 temperature 调到 0-0.3或固定 seed模型开始瞎编知识库没覆盖该问题加入“未知即未知”的 Prompt 兜底并完善知识库服务并发一高就超时推理引擎配置不足上 vLLM开启连续批处理或加节点6.2 几个我反复踩过的坑第一个坑盲目追求大模型。我一开始直接用 72B 的模型效果确实好但成本爆炸。后来换成 7B 做好的 RAG 和 Prompt业务效果几乎没差。工程上先优化数据再优化 Prompt最后才考虑换大模型这个顺序别搞反。第二个坑把 Embedding 模型和业务模型混用。有的团队为了省事直接用同一个模型做 Embedding 又做生成。这是彻头彻尾的错误Embedding 模型追求表示学习生成模型追求文本生成两者任务完全不同硬混用效果一定差。第三个坑对检索结果不加过滤。一开始我不管相似度分数多低都塞给模型。结果就是明明没有相关内容模型还要硬答。后来加了一个相似度最低阈值低于阈值就提示“知识库暂无相关内容”反而用户满意度提高了。第四个坑没有注意 token 消耗。检索回来的文档片段是越多越好吗不是。3 个片段能讲清楚的不要喂 10 个片段。因为上下文拉长以后模型容易注意力发散回答质量下降还费钱。我的习惯是从少到多调先给 3 个片段不够再加。6.3 给新人的几条建议如果你也是从零开始我很想告诉你三件事不要跳过基础。至少要搞懂 Token 是什么、嵌入向量维度意味着什么、相似度是怎么算的、温度参数影响的是什么。这些基础不牢后面每一步都像踩在棉花上。一定要亲手写一遍 RAG。不要复制。从读文件、切分、Embedding、向量检索到拼 Prompt跟着代码逐行走一遍这个过程的价值远超刷十遍教程。多跟行业的人交流。AI 工程更新迭代太快一个人闷头学容易走偏。找到同路的人互换经验比自己闭门造车高效得多。我自己刚入门那阵也经常因为跑不通一个效果沮丧到想放弃。后面慢慢明白AI 工程跟传统软件开发最大的不同是它带有一层“不确定性”。你不能像写业务代码那样期望一次就对你要学会用数据、日志和评估去逼近一个“稳定可用”的状态。这条路没有终点但每一步积累的能力都是真实的。希望这篇长文能帮你把 roadmap 看清楚少踩几个我踩过的坑。动手永远是第一步跑起来再说。