1. 先从“从零”这两个字说起

做 AI 工程这件事，很多人是被“从零”两个字劝退的。打开招聘软件一看，大模型算法工程师要求五个项目经验、三篇顶会论文，再一看某个 AI 应用开发课程，上来先让你手写一个 Transformer。说实话这路走偏了。“ai-engineering-from-scratch”这个标题的核心含义，不是让你从数学原理开始推倒重来，而是让你用工程的方式、从最底层的逻辑开始，把一个 AI 系统从无到有搭建起来。你在过程中需要做数据清洗、模型微调、Prompt 设计、服务部署、效果评估，这一整套链路，才是 AI 工程。

我见过太多人卡在“模型下载下来之后不知道往哪放”，或者“在 Notebook 里跑通了一个 Demo 但不知道怎么变成一个能给别人用的东西”。这篇文章就是来解决这个问题的。不管你是刚转行的后端工程师、数据分析师，还是学生，只要你会基本的 Python，就有希望在这条路上走下去。我会把整条技术路线拆开，讲清楚每个环节的定位、关键动作和实操细节，也会附上我实际踩坑的记录。

顺着这个思路，接下来先说清楚一个核心问题：我们到底在做什么事情。AI 工程不是一个岗位，它是一个复合体，背后牵扯到数据、模型、算力、产品、运维等多个领域的协作。如果你脑子里没有一个全局图，很容易陷入“一直在调参，永远没产出”的泥潭。

2. AI 工程到底是什么：一个完整系统的解剖

2.1 AI 工程和做研究是两码事

很多人有个误解，觉得 AI 工程就是要自己发明新模型、发论文，其实绝大多数公司需要的不是研究能力，而是把已有的成熟模型工程化落地的能力。这中间的差别，我用一句话总结：AI 研究追求的是“别人没做过”，AI 工程追求的是“能稳定跑起来”。工程师的职责不是探索模型上限，而是在给定资源下，把系统的可靠性、性能、成本和效果调到一个商业上可接受的状态。

举一个例子：你用 Llama 或 Qwen 这类开源模型搭一个文档问答机器人。研究者的注意力会放在模型的注意力机制上，工程要处理的问题却是：用户上传的 PDF 格式千奇百怪，PDF 里的表格怎么抽、扫描件怎么 OCR、切分片段时如何避免把语义切断、检索召回率不高怎么办、模型对长上下文出现“中间迷失”怎么缓解。这些问题每一个都不“性感”，但每一个都是真正要命的地方。

从工作节奏来看，研究者在实验阶段大量使用 Notebook，代码写得乱没关系，能出结果就行。但工程代码必须考虑模块化、可测试性、可监控性和可回滚性。比如你要线上跑一个微服务，输入输出要有明确的 Schema，错误要有分类，日志要能追踪到某一次请求。这个意识，是从 Notebook 式思维切换到工程思维的第一步。

2.2 一条完整的 AI 工程链路

如果让我画一张 AI 工程的最小闭环地图，核心是以下六个环节：

• 需求定义与指标设定：你要解决的问题是什么？怎么量化“好用”？
• 数据准备：数据从哪来、质量怎么把控、怎么切分训练集和评测集。
• 模型选型与训练/微调：选开源基座还是 API 调用？要不要微调？
• 推理与性能优化：模型跑一个请求要多久？显存够不够？成本多少？
• 服务化与部署：怎么封装成一个 API？怎么处理高并发？
• 评估与持续迭代：线上效果怎么监控？bad case 怎么反哺训练数据？

这六个环节不是线性走一遍就结束，而是一个循环。你在部署上线后发现某些问题答不对，然后把这些问题加入评测集，再调整 Prompt 或微调数据，重新评估，再发布。所谓 AI 工程，本质上是把这个循环跑得又快又稳。

这里要特别强调一个容易被忽略的点：指标设定要在项目一开始就做。很多团队做了几个月，最后发现“效果不好”但谁也说不清哪里不好，因为没有 baseline，没有评测集，没有口径统一的指标。你哪怕一开始只定义三个指标：回答准确率、请求延迟 P95、单次调用成本，整个项目就有了坐标。

2.3 初学者的常见误区清单

根据我的观察，刚入门的同学最容易踩这几个坑：

• 只学框架不学工程：会调用 Transformers 库但不会写 Dockerfile，不知道 GPU 驱动和 CUDA、PyTorch 版本之间的匹配关系。
• 轻视数据工作：花大量时间调 Prompt，却不舍得花时间去清洗数据、构造高质量对齐语料。
• 一上来就想微调大模型：数据量不够、算力不够，效果反而远不如直接用 RAG 或者好的 Prompt 方案。
• 忽略成本意识：本地跑通一个 Demo 很容易，但上线后每天百万次调用，API 费用或 GPU 费用烧得人心慌。
• 不重视评估：没有评测集，全凭感觉调参，改了一版 Prompt 也不知道是变好了还是变坏了。

后面我会在工具选型和实操环节，分别针对这些坑展开讲解法。

3. 从零开始的核心技能栈与工具选型

3.1 代码能力是一切的基础

先给一个坦诚的建议：纯零基础想直接进入 AI 工程是不现实的，你至少需要具备 Python 基础。这里说的基础不是会打印 Hello World，而是能熟练操作字典、列表、列表推导式，能读懂类和装饰器，能用 pip 管理依赖，会写基本的异常处理。另外，pandas 和 NumPy 的基本操作也要过关，因为数据清洗环节基本离不开它们。

有人会问，Java 或者 Go 工程师转过来行不行？行，但 Python 这一关必须补。原因很简单，AI 生态的工具链，从 Hugging Face 到 PyTorch，到各种部署框架，Python 是事实上的“通用语言”。你可以通过调用接口的方式用其他语言做服务层，但模型训练、微调、数据处理这些环节你还是绕不开 Python。

函数式编程的一些思维，比如 map、filter、高阶函数，虽然不是必须，但写数据处理代码时很顺手。我自己的经验是：能用列表推导式解决的事，绝不写三层 for 循环，代码可读性完全不一样。

3.2 机器学习与大模型：从原理到选型

你要真的做 AI 工程，不可能完全不懂模型原理，但也不需要陷进去。我的建议是把精力集中在几个核心概念上：Embedding 是什么、Transformer 的基本结构、自注意力机制在做什么、预训练和微调的区别、Token 怎么切分、上下文窗口是什么意思。这些概念不需要你手推公式，但要能解释给产品经理听，能根据需求做选型判断。

模型选型是一个很现实的决策。现在的选择大致分成两类：

• 闭源 API：OpenAI、Claude、国内的通义、文心、智谱、月之暗面等，按 Token 计费，上手快、效果稳定，但数据出域合规、长期成本可控性低。
• 开源模型：Qwen、Llama、DeepSeek、ChatGLM、Yi 等，可私有化部署，数据安全可控，推理成本随规模增大而摊薄，但要自己有工程能力。

实际项目里，很多公司的做法是：核心能力用开源模型私有化部署，外围或者特定 agent 的任务调用商业 API 做对比、兜底或并行多路投票。这个“组合拳”思路，既能控制成本，又能保证效果。

具体到部署框架，我个人建议初学者从 vLLM 入手。它的 PagedAttention 机制能显著提升吞吐量，而且 OpenAI 兼容接口让你从 API 切换到自建服务时，代码改动极小。如果显存不够或者部署的是端侧场景，可以再看 Ollama、llama.cpp 这类轻量方案。但主力服务端部署，vLLM 目前是社区的事实标准。

3.3 数据与评测：决定效果上限的水位线

AI 圈子有句常听到的话：数据决定了效果的上限，模型只是逼近这个上限。这句话有点夸张但不无道理。做 AI 工程，你花在数据上的时间往往是最多的。数据工作包含四个环节：

• 采集：从业务日志、公开数据集、人工标注、合成数据等渠道获取原始语料。
• 清洗：去掉重复、噪声、敏感信息，处理格式问题。
• 构造：根据任务目标把数据转换成“输入-输出”对，或者更复杂的多轮对话格式。
• 评测集构建：单独留出一部分数据，评估 Prompt 改动或模型微调前后的效果差异。

评测集特别重要。我强烈建议从项目第一天就建一个评估集，哪怕刚开始只有 50 条，每一条都标好标准答案。之后你每次做改动，都在这个集合上跑一遍，算准确率或打分。这个习惯能救你于水深火热之中。否则你会陷入“改了 Prompt 好像变聪明了又好像变傻了”的玄学循环。

评测的指标也要分情况：

任务类型	常用指标	说明
分类	准确率、F1、召回率	特别关注少数类，防止模型偷懒
生成/问答	ROUGE、BERTScore、大模型评分	生成没法完全靠自动指标，人工抽检要做
检索/RAG	Recall@K、MRR	检索不到，后面的生成再强也白搭
延迟/成本	P95 延迟、单次调用成本	工程落地的生死线

3.4 工程化必备：Docker、GPU 编程基础与 API 设计

很多做算法的人死在工程化，做工程的人死在算法细节，所以全栈型的 AI 工程师才有稀缺性。工程化的三大利器，我建议尽早学：Docker、Linux 基础、带鉴权和监控的 API 设计。

Docker 解决了“在我机器上是好的”这个经典问题。你写一个 Dockerfile，把 Python 版本、CUDA 依赖、模型文件路径、启动命令都固化下来，无论在本地还是服务器上，行为都一致。部署环境千差万别，镜像化是唯一的确定性来源。我的经验是，镜像里要固定 Python 依赖的版本号，最好用 pip freeze 或者 poetry.lock，避免包版本漂移造成的不兼容。

GPU 编程不要求你会写 CUDA kernel，但要懂几个概念：显存有多少、批量大小怎么影响显存占用、混合精度是什么、为什么要用。很多人部署大模型时 OOM（显存溢出），根本原因就是不懂这些基础。

API 设计方面，做一个高质量的模型服务，至少要包含：

• 输入输出 Schema：用 Pydantic 强类型校验，别让脏数据进到模型里。
• 超时和重试机制：避免一个慢请求拖垮整个服务。
• 鉴权：至少用 API Key 控制访问。
• 日志与监控：记录每次请求的延迟、Token 数、错误码，方便出了问题复盘。

4. 完整实操：构建一个支持 RAG 的文档问答系统

这一节我会用一个经典项目——企业文档智能问答系统——来走完整个 AI 工程流程。这个项目非常适合作为“ai-engineering-from-scratch”的第一个实战，因为它涵盖了数据、向量检索、大模型生成、服务封装、效果优化几乎所有关键模块。

4.1 需求拆解与方案设计

假设你所在的公司有成百上千篇产品文档、内部规章制度、技术手册，散落在各个地方。你的任务是做一个问答机器人，让员工可以用自然语言提问，例如“年假标准是什么”“线上故障处理流程是什么”，机器人要给出准确的答案，并注明来源出处。

我们来拆一下需求：

• 答案必须基于公司文档，不能由模型凭空编造，这意味着要用 RAG（检索增强生成）方案，而不是纯靠模型记忆。
• 要标注答案来源，方便用户溯源核对。这条要求会影响检索模块的结构设计。
• 数据是私有数据，不能直接把文档喂给商业 API，所以模型必须私有化部署，或者至少用私有化向量库做在线检索。

整体方案我选的是：将文档解析、切分成 chunk → 用 Embedding 模型转成向量 → 存入向量数据库 → 用户提问时先向量检索 Top-K → 把检索到的文档拼进 Prompt → 大模型基于检索结果和问题生成最终答案。

4.2 数据准备：解析与切分这步最容易翻车

第一步是把不同格式的 PDF、Word、Markdown 全部转成纯文本。很多人的项目死在这一步，因为看似简单实际暗坑无数。PyPDF2 对扫描版 PDF 无能为力，需要用 OCR 方案；Word 文档里有页眉页脚、表格嵌套，直接提取会得到一堆乱码。我的建议是：能用专业工具就用专业工具，免费的方案是 PyMuPDF 结合规则处理，商业方案如一些云厂商的文档解析服务，效果会稳定很多。

文本切分是 RAG 效果的关键一环。切得太短，一段话被腰斩，语义不完整，检索容易召回一堆没头没尾的碎片；切得太长，一段文本包含多个主题，跟用户问题的相关性被稀释，而且占用上下文窗口。我的经验是把“语意单元”作为切分的基本依据。你可以先用章节标题作为天然切分点，然后在每个段落内部按 200 到 500 个 Token 为一个块，块之间加 20% 的 overlap（重叠），确保跨越边界的语义不丢失。这里放一段我常用的切分逻辑示意代码：

from typing import List

def chunk_text(text: str, chunk_size: int = 400, overlap: int = 80) -> List[str]:
    words = text.split()
    if len(words) <= chunk_size:
        return [text]
    chunks = []
    start = 0
    while start < len(words):
        end = start + chunk_size
        chunk = " ".join(words[start:end])
        chunks.append(chunk)
        if end >= len(words):
            break
        start = max(0, end - overlap)
    return chunks

这里的核心思想是“保存上下文”。看起来简单，但我去过不少团队，有人直接用字符切分、有人不设 overlap，导致检索质量特别差，还反过来怀疑 embedding 模型不行。其实很多问题都出在上游的数据切分上。

4.3 向量化与检索：选择 Embedding 和度量方式

文本切好之后，要做 embedding 向量化。目前常用的 Embedding 模型有 OpenAI 的 text-embedding-3-small、智源的 BGE 系列、阿里的 text-embedding-v3 等。如果你要私有化部署，BGE-M3 是开源的，支持中文效果好，显存占用又不算大。选 embedding 模型的唯一准则是：在你的业务数据上做召回评测，而不是看榜单分数。同一个模型在通用语料上效果好，不代表在你的专业术语、文档风格上效果就好。

向量数据库的选择也很多，Milvus、Qdrant、Weaviate、Chroma、pgvector 各有适用场景。如果你公司已经用了 PostgreSQL，pgvector 是最省心的，加一个扩展就能用；如果数据量在千万级别以上、对高并发实时检索有要求，Milvus 或 Qdrant 更合适。初学者做原型，Chroma 就够了，本地跑通再迁移到生产库。

检索的时候，最基础的方式是余弦相似度找出 Top-K。但这里有一个很关键的工程优化：混合检索。只用向量检索有一个问题——它是一个“语义近似”的过程，对精确匹配（比如员工编号、产品型号、制度条款编号）不敏感。所以生产环境中我强烈建议引入 BM25 这种传统的稀疏检索方式，与向量检索做加权融合（RRF 或加权和）。很多开箱即用的检索框架同时支持这两种方式，省心很多。

RAG 流程里 top_k 是个要调的参数。设小了可能漏答案，设大了上下文里塞满噪声，模型反而会被带偏。根据我的经验，top_k = 5 是一个比较稳妥的起点，然后结合答案召回率和上下文容量做调整。如果你的上下文窗口有 128K，top_k 可以稍微放大，但一定要约束拼接后的 Prompt 长度。

4.4 大模型生成：Prompt 设计中的关键细节

检索到相关内容后，要把这些内容和用户问题一起组装成 Prompt。Prompt 设计有个常见误区：以为写得越长越专业。我实测下来，冗长的“角色设定”和“注意事项”并不会让模型变聪明，反而会淹没重点。核心原则是“指令刚好覆盖任务边界”。

以文档问答为例，我给一个我反复打磨过的模板：

你是企业内部的文档助手。请仅根据下方提供的文档片段回答用户问题。
要求：
1. 如果文档中没有相关信息，直接回答“文档中未找到相关内容”，不要编造。
2. 回答时优先引用原文表述，并标注来源（文件名和章节）。
3. 如果信息之间有冲突，请指出冲突内容，不要自行妥协。

文档片段：
{context}

用户问题：
{question}

这里有个我踩过的坑：如果不强约束“仅依据文档信息作答”，模型会自动结合自己的预训练知识补充很多看似合理但文档里根本没写的内容。这在企业场景中很有风险。加了约束之后，模型的“幻觉”显著减少，代价是在文档确实覆盖不到的问题上，模型会略显生硬，但工程上我们优先保证可控。

另外，一定要在代码里做输出格式校验。比如要求模型返回 JSON，就用 JsonOutputParser 这类解析器约束输出，或者用 few-shot 示例引导格式。我的经验是，在 Prompt 里给一个输出示例，比写一大堆“你必须输出合法 JSON”更有效。

4.5 模型服务化：从 Notebook 到 API 的最后一公里

模型在 Notebook 里跑通不代表可以上线。你需要把推理逻辑封装成一个服务。常用的方案有两类：一是直接用 FastAPI 写一个调用封装，适合逻辑相对简单的场景；二是用 LangChain 或 LlamaIndex 这类框架组装流程，适合流程里有多步判断、多工具调用的场景。

不管用哪种方案，服务层的核心是把“业务逻辑”和“模型细节”解耦。我的习惯是项目文件做这样几个模块： document_loader.py 负责文档解析， retriever.py 负责向量检索， prompt.py 负责模板管理， generate.py 负责调用模型生成， api.py 负责 FastAPI 接口。每个模块只干一件事，测试和后续迭代都会轻松很多。

部署方面，如果使用 vLLM 作为模型后端，它本身自带一个 OpenAI 兼容的 HTTP 服务。你只需要在你的应用代码里把 base_url 指到 vLLM 服务的地址，然后像调用 OpenAI 一样调用即可。我看过很多团队在这个环节绕远路，自己写了一套抽象层去对接不同家的模型，最后维护成本居高不下。

4.6 部署上线与资源估算：成本和性能的平衡

部署一个 7B 级别的对话模型，用 FP16 精度，大概需要 14GB 显存；用 AWQ 或 GPTQ 量化到 4bit，显存占用能压到 5 到 7GB。这块经验很重要，因为很多人选型卡在“显存不够”，其实量化一下就能解。

关于并发和成本的估算，我给出一个最简化的计算方式：

• 一个 7B 模型，单张 A100（80GB）上，vLLM 实测大约能做到每秒几十个请求的吞吐（取决于输入输出长度）。
• 每百万 Token 的生成成本，取决于你的 GPU 月租价格和利用率。假设 A100 月租 1500 美元，每天跑满 24 小时，那么每小时成本大约 2 美元；若能产出 30 万 Token 的输出，则每百万 Token 的输出成本大约 6.7 美元，换算成人民币大约 50 元，对比商业 API 还有竞争力。
• 但如果不跑满，成本会摊薄得非常难看。所以工程上的第一原则是：把 GPU 用起来，不要让它在 90% 的时间里空转。

想省钱有几个切实可行的方向：用量化模型降低显存；用冷热分层，高频问题走短 Prompt 模板，复杂问题再走完整 RAG 链路；批量推理合并请求，减少重复计算。这些属于持续优化的范畴，但一开始选型的时候就要有规划。

5. 进阶方向：AI Agent、微调与工具链扩展

一天下来完成了基础的 RAG 问答项目，可以更有底气去触及硬骨头了。下面这三个方向是“ai-engineering-from-scratch”路线图上必选的进阶关：AI Agent，微调，以及围绕提示工程的工具链。

5.1 AI Agent 的工程本质：让模型学会调用工具

当前 AI 工程热度最高的话题毫无疑问是 AI Agent。热词里也反复出现了“agent”“tool calling”，这确实是下一个阶段的重点。一个 Agent 与问答机器人的本质区别是：问答机器人只做“文本进，文本出”，Agent 却能把“规划、调用工具、观察结果、再决策”这个循环跑起来。

工程实现上，Agent 的核心是让模型在生成过程中输出结构化的函数调用指令，比如输出 search_document(keyword=...) ，然后由程序执行这个函数，把结果再传回模型。OpenAI 的 function calling、Anthropic 的 tool use，国内的通义、智谱也都支持类似能力。而在开源社区，基于 ReAct 模式的 Agent 框架（如 LangGraph、AutoGen）是主流。

我的建议是：不要一开始就上复杂的 Agent 框架，先用一次最简单的工具调用跑通。自己定义一个 get_weather 函数，让模型根据用户输入决定要不要调用、调用时传什么参数。理解了这个机制，再去看 LangGraph 里的状态机逻辑会轻松很多。Agent 的工程化难点在于：任务拆解的正确率怎么保证、工具的异常输出怎么反馈给模型、多步操作如何防止陷入死循环、以及最关键的——如何做好权限隔离和操作审计。这些不是模型能力问题，是工程架构问题。

5.2 什么时候需要微调，什么时候别碰微调

微调被很多人奉为灵丹妙药，实际它是个偏方。绝大多数场景下，通过 RAG 和 Prompt 工程解决不了的问题，微调也解决不了。如果问题出在“模型不知道某些知识”，你用 RAG 解决；如果问题是“模型不理解某种格式/风格/推理模式”，这才是微调发挥的舞台。

举个例子：你要让模型从一堆合同条款中自动抽取指定类型的风险点，并输出 XML 结构。Prompt 怎么调都不稳，因为任务本身对模型来说不是“知识”而是“能力”。这时你用几百条标注好的“合同文本 → 抽取结果”数据做 LoRA 微调，效果提升会非常明显。LoRA 是一种参数高效的微调方法，它只训练一小部分新增参数，显存占用小，单卡就能跑。

微调的数据格式强烈推荐使用 ChatML 模板，每条数据组织成多轮对话，系统提示词控制行为，用户输入任务，助手输出期望结果。数据量级上，效果类微调至少是几百条高质量样本，几千到几万条更好。低于一百条，基本属于浪费算力，不如回去琢磨 Prompt。

我建议微调项目走这个流程：准备 50 条种子数据，先用 Prompt 工程跑 baseline；人工检查失败样本；筛选出符合你格式要求但模型做不对的样本，扩充到 500 条；用 LoRA 微调；同一个评测集精确对比微调前和微调后的结果。整个过程切忌“感觉变好了”，一定要有数据支撑。

5.3 AIGC 时代的提示工程工具链

提示工程这个工作在其他 AI 工程环节里是门槛最低但最容易被人低估的一块。什么叫会写 Prompt？“请帮我总结这篇文章”，和“请以三段式结构总结这篇文章，第一段概括核心结论，第二段列举支撑论据，第三段指出潜在的局限性”，效果天差地别。

这里有一个通用性很强的思路：上下文（context）—指令（instruction）—示例（few-shot）—限制（constraint）—输出格式（output format）。任何任务你写 Prompt 时，都按这个框架走一遍，起码能超过 70% 随手写 Prompt 的人。它背后其实是对齐问题，模型需要知道你的意图、边界、格式和可信依据。

现在很多工具在做 Prompt 的版本管理和评估。我的建议是，哪怕你只是一个人开发，也要把 Prompt 当成代码一样管理。不用工具至少用 Git 管理不同版本的 Prompt 文件，配一条注释说明改动目的。Prompt 是会退化的，不记录版本，你永远不知道哪一版是最好的。

6. 故障排查与避坑实录

6.1 模型输出质量差？先查数据再怪模型

做了 AI 工程之后，你会养成一个习惯：“效果差”之后第一反应不再是“模型不行”，而是先按链路逐层排查。举个例子，RAG 系统回得不准，你先看两件事：检索出来的文档片段到底对不对？如果片段不对，那问题在检索侧；如果片段都对但答案还是错的，问题在生成侧或 Prompt。这个排查思路帮我省了无数时间。

数据质量的影响再怎么强调都不过分。我见过一个团队花了两周时间调 Prompt，后来发现他们的知识库里存了几十篇同一文件不同版本的重复文档，模型每次都被旧版本的错误信息引导。把重复、过期文档清理掉之后，准确率立刻涨了 10 个百分点。先清洗数据，再调模型，顺序千万不能反。

6.2 部署层经典事故：显存溢出、超时、并发阻塞

模型服务部署时最常见的错误排行榜上，OOM（显存溢出）绝对排第一。7B 模型 FP16 推理需要 14GB 显存，但很多人忽略了 KV Cache 占用的显存。KV Cache 大小跟并发量和序列长度直接相关，并发一高，显存立刻爆掉。vLLM 较好地解决了这个问题，它通过 PagedAttention 和连续批处理（continuous batching）机制，能显著提高显存利用率和请求吞吐。

超时问题也频繁。如果你的上游服务只给 3 秒超时，而模型生成一个长答案需要 10 秒，那你再好的模型也白搭。解决思路是：对接口按场景分级超时，短问答走短模型或限制 max_tokens，长文档总结走异步任务，前端轮询结果。把同步阻塞和异步任务分开设计，是工程成熟度的分水岭。

并发阻塞是另一种经典问题。很多人起服务时只开一个 worker，第一个请求占住 GPU 慢慢生成，后面的请求全部排队。vLLM 内部能处理连续批处理，但如果你在外面套了 FastAPI，就要注意并发模式设置，别让 FastAPI 把请求串行化。压力测试永远是上线前必做的一步，哪怕只是用 Locust 或 wrk 简单测一下，也能暴露很多隐藏问题。

6.3 成本失控怎么排查

月底账单吓人也是 AI 工程常客。我先给一个排查顺序：先看 Token 输入输出比，很多系统输入是输出的几十倍，因为每次请求都把几十个文档片段灌进上下文，其中只有少部分有用；其次看缓存命中率，同样的用户提问是不是每次都重新跑一遍模型；再看有没有无效请求在不停重试。

优化方向上，高频相似问题的 Embedding 缓存是最立竿见影的手段。用户问题经过 embedding 后先查缓存，完全一样的问法直接返回历史答案。有条件的可以上语义缓存，相似度超过 0.95 就视为同一问题命中缓存。这一步通常能砍掉 20% 到 40% 的模型调用量。

6.4 从模型幻觉到安全对齐的工程护栏

在企业环境中，模型的输出直接面向员工或客户，幻觉问题会演变成合规风险。工程上的护栏手段主要有：

• 输出侧过滤：关键词黑名单 + 敏感信息脱敏（身份证、手机号、地址等）。
• 输入侧过滤：Prompt 注入检测，防止用户试图套取系统 Prompt 或诱导模型做越权操作。
• 引用溯源：RAG 场景强制要求模型标注来源，人工审核时能快速追踪。
• 审计日志：记录每一次输入输出，方便出现问题时定责和复盘。

这些能力不依赖强大的模型，而是工程机制。很多团队在模型效果上投入大量精力，却没在护栏上下足功夫，等项目上线出了问题再来补，往往代价极高。我始终认为，一个连审核日志都没有的 AI 系统，没有资格称为“工程系统”。

7. 学习路线：按周拆解的从零进阶方案

如果你看完前面这些内容还觉得抽象，这里给你一条可以直接照着走的学习路线。前提是你已经有 Python 基础，每天能投入一到两小时。

• 第 1 周：补齐模型基础概念，把 Transformer、Token、Embedding、注意力机制弄明白，配合 Hugging Face 的 Transformers 库跑通一个最简单的文本分类小例子。
• 第 2 周：学 LangChain 或者直接裸写 RAG，完整做一个简单的文档问答原型，感受切分、向量化、检索、生成这条链路。
• 第 3 周：学 Docker 和基本的模型部署，用 vLLM 本地部署一个 7B 开源模型，写一个 FastAPI 接口调用它。
• 第 4 周：做评测。给你第 2 周的原型建一个 50 条问题的测试集，反复优化切分参数和 Prompt，记录每个版本的得分变化。
• 第 5 到 6 周：做工具调用实验。用 OpenAI 的 function calling 或开源的 ReAct 框架做一个能调搜索、能查数据库的 Agent 雏形。
• 第 7 到 8 周：选一个垂直场景（客服、简历筛选、合同审核），从头做一套带微调和评测闭环的完整项目，整理成作品集。

整个路线的时间不是死数，核心是每一步都要产出一个“能运行的东西”，不要停留在看教程。我一直觉得，AI 工程是“做”出来的，不是“学”出来的。你看十个小时视频，不如花十分钟把代码跑起来。遇到问题去查文档、去问社区、去读源码，这个过程积累的经验，才是你真正的能力。

8. 我个人的一些体会

做了几年 AI 工程之后，最大的体会是：这个领域变化太快，但底层的工程素养永远保值。今天流行的模型，明年可能就过气，今天好用的框架，后天也许就换了一代。但数据清洗的严谨、评测体系的搭建、部署运维的规范、成本控制的敏感，这些在任何一代 AI 技术上都用得上。

如果你要开始这条路，我的建议是先放下对“新模型”“黑科技”的追逐兴奋感，老老实实把一个用开源模型做的 RAG 问答系统从数据到部署走通一遍。这个项目做完，你对 AI 工程的认知会比看一百篇文章都深刻。过程中你会遇到各种问题——库装不上、显存不足、检索不准、回答幻觉，每个坑跨过去，都是在给自己积累确定性。

最后再分享一个小技巧：尽早建立自己的“测试集”习惯。每次模型或代码改动，跑一遍同一个测试集，记录结果变化。这个习惯会帮你建立对改动的判断力，也会让你在团队里显得异常靠谱。祝你在“从零”的路上顺利，这行确实不容易，但走通了，风景真好。