这两年“AI工程”这个词被频繁提及，但大多数人其实是被“AI”两个字吸引，却低估了“工程”两个字的分量。很多人自学时习惯先怼模型、调参、看loss曲线，忙活大半年发现自己连一个稍微复杂点的业务需求都接不住——不是因为算法不好，而是工程能力没跟上。我当初从纯后端转过来做AI应用落地的时候，也是从这种迷惘状态里爬出来的，所以今天想认真聊一聊“ai-engineering-from-scratch”到底该学什么、怎么学、按什么顺序学，以及这个过程中最容易被忽视的那些细节。这篇文章适合所有想系统进入AI工程方向的人，无论是刚毕业的校招生、打算转行的后端开发者，还是已经在做数据分析但想往工程侧拓展的从业者。
1. 先搞清楚：AI工程和AI研究、算法岗到底有什么区别
很多初学者第一个误区就是把这个方向理解成“搞模型”。我见过不少人简历上写“熟悉Transformer、熟悉BERT”，但实际上去到面试现场，连自己训练好的模型该怎么部署到Linux服务器上、怎么处理线上流量高峰、怎么做模型热更新，都答不上来。这就是典型的“算法思维”绑架了“工程思维”。
AI工程核心是“让模型稳定、可控、高效地运行在真实系统里”，而不是“把模型精度刷高零点几个点”。这两者的底层能力结构完全不同。算法岗的重心在模型结构设计、训练策略优化、实验对比分析；AI工程的重心在数据管线的健壮性、训练和推理的资源效率、模型版本管理和服务质量保障。换句话说，模型只是系统中的一个组件，而不是系统的全部。
再从技能栈上看，一个典型AI工程项目的全链路长这样：
- 数据采集与清洗：原始数据往往以各种格式散落在不同存储系统里，MySQL、MongoDB、日志文件、对象存储，甚至合作伙伴外包的Excel表格
- 特征工程与数据管线调度：清洗完的数据需要转换成模型能理解的张量格式，并按照稳定的节奏灌入训练和推理流程
- 模型训练与调优：这个环节看似核心，但其实只占全流程的小部分工作量，而且已经被大量工具框架化、标准化了
- 模型评估与验证：不只是看测试集准确率，还要看不同业务场景下的对抗性表现、带噪数据下的鲁棒性、长尾样本的召回率等
- 模型上线与服务化部署：以HTTP服务、gRPC服务或消息队列消费端的形式跑在生成环境，接住真实流量
- 监控告警与持续迭代：没有监控的模型服务就是盲飞，数据漂移、性能衰减、流量突刺都需要有感知、有预案
如果按时间投入来算，一个完成度比较高的AI工程项目，真正花在“调模型”上的时间可能只占三到四成，其余全在数据和工程环节。这就是为什么很多人照着教科书上的深度学习项目做练习时感觉很顺，一旦放到真实业务里就各种崩——因为教科书只教了那三到四成。
所以，如果你决定走AI工程这个方向，第一件事不是去背模型结构，而是先调整心智模型：你是在构建一套AI系统，而不是在训练一个模型。
1.1 从工程视角重新认识“AI系统”
什么是系统？系统就是能够应对输入变化、环境变化、硬件变化而依然维持功能正确性的整体。举个例子，你用notebook训练一个情感分析模型，输入一句“今天天气真好”，输出“positive”，这只是一个函数。但如果这个模型要服务一个每天几万次调用的客服系统，那它面对的就不仅仅是整齐划一的句子，而是包含错别字的、带emoji的、中英混合的、甚至有些是恶意攻击的文本。这些情况单靠模型本身无法全部兜住，需要靠数据预处理、后处理规则、超时重试、降级策略等工程手段来兜。
工程视角要求你具备一种“预防性思维”：在写每一步代码之前，先想清楚这一步可能遇到什么异常、怎么处理、怎么监控。这种思维不会随着你调出更好的模型而自动获得，必须通过大量的实际项目积累。而这正是“from scratch”的核心价值——你如果不从零把一个系统完整搭一遍，永远不知道自己漏了多少环节。
1.2 为什么“从零开始”是最快的学习路径
这里说“从零开始”，不是指从线性代数、高等数学开始啃，而是指不要依赖别人封装好的一站式平台，亲手用最基础的组件把一个AI服务打通。你可能会问：现在PyTorch、HuggingFace这些框架都这么成熟了，还有必要从零开始吗？有必要，而且比你想的更有必要。
理由很简单：框架帮你解决的是“从模型到张量运算”这一层，但没帮你解决“从原始数据到线上服务”这整个链路。如果你习惯了用AutoML平台或者别人写好的pipeline脚本，一旦出现一个平台不支持的诡异需求，你的排查能力几乎为零。而从零开始搭建意味着你亲手处理过数据编码、手动写过训练循环、自己配置过GPU环境、手工部署过推理服务——这些东西出错时给你的“肌肉记忆”，是任何框架都替代不了的。
所以这篇文章的路线会刻意避免“跑通一个notebook就算完事”的思路，而是围绕“能上线、能维护、能迭代”来组织内容。
2. 从零起步的基础必备：哪些知识真正值得花时间
这一节献给那些正处于“不知道学什么、什么都想学”状态的人。AI工程的知识面确实很广，但如果你按下面这几个板块来定位，就知道该把有限的时间放在哪儿了。
2.1 编程基础：为什么Python是首选，但不止Python
Python毫无疑问是AI工程领域的首选语言，原因很实际：PyTorch、TensorFlow等主流框架的接口都是Python优先；数据处理领域有完整的生态，pandas、numpy、scikit-learn一条龙；开发效率高，写原型和写胶水代码都很快。但AI工程做到后期，你一定会碰Python的边界。
典型场景：线上推理服务的高并发优化。Python因为有GIL（全局解释器锁），多线程在处理CPU密集型任务时效率很难榨干。这时候要么用多进程，要么把热点模块用C++重写（如TorchServe的底层实现），要么干脆把部分链路替换成Go或Java服务，通过RPC通信。我见过不少团队，Python写的推理服务扛不住QPS，最后是拆分服务、落盘缓存、改C++算子一步步解决的。
所以我的建议是：Python要熟练到看到需求直接能写出干净脚本的程度，SQL不能只会简单SELECT（AI工程常要处理复杂的多表聚合和数据质量探查），再有精力就补一点C++的基础语法和编译流程，不需要精通，但至少要能读懂推理引擎里的热点代码在干什么。
2.2 数学到底要学到什么程度
这是新手最爱纠结的问题。说真的，除非你要去做底层算法研究和模型架构创新，否则没有必要把《机器学习》教材里的公式推导全部啃透。但有几个关键概念你必须有直觉：
- 线性代数中的矩阵乘法、维度变换，这关系到你理解张量的shape变换和注意力机制中的QKV计算
- 概率论中的条件概率、贝叶斯思想，这关系到你对模型输出置信度的理解——它到底在表达什么，有多可信
- 微积分中的梯度下降逻辑，理解learning rate、梯度消失和爆炸的本质
- 损失函数部分的数学形态，知道分类问题为什么用cross entropy，回归问题为什么用MSE，以及什么情况下指标会失真
达到什么程度算够用？不是能推导公式，而是看到一个问题能用数学语言描述出来，并且理解优化目标与约束条件之间的关系。我在招聘时反而不太看候选人会不会背公式，更看重他能不能解释清楚“为什么这个场景用F1而不是accuracy”“模型在这里输出0.6的置信度，你敢不敢直接采信”。这些问题背后全是数学直觉。
2.3 Linux、Docker和版本控制：AI工程的隐形基本功
这部分在常规的自学之路里往往被忽略，但在真实工作中天天都在用。模型训练通常在Linux服务器上进行，你是通过SSH连上去操作的；你的项目需要复现，别人不可能把整个conda环境搬走，只能通过Docker镜像或者requirements.txt来复制环境；你的模型资产、代码、实验配置版本一多，没有Git管理就会陷入灾难。
我给每个准备入行的朋友一个比较朴素的动作清单：
- 掌握Linux常用命令，至少能在服务器上自由操作文件、查看GPU状态、定位CPU和内存占用
- 能用Dockerfile把一个Python服务装成镜像，并理解镜像分层、容器和虚拟机的区别
- 养成用Git做版本管理的习惯，不只是推送代码，还要学会处理冲突、回滚版本、管理分支
- 会配置conda或virtualenv虚拟环境，保证不同项目之间的依赖不互相干扰
这些技能在面试时很少被单独提问，但会在实际工作中随时卡住你。有很多人技术能力不错，就是因为环境装不好、代码管理混乱，导致项目进度一直在原地打转。
3. 核心技能栈拆解：AI工程的关键模块怎么学
过了基础铺垫阶段，就可以进入正式技能栈的搭建环节了。这是整个“ai-engineering-from-scratch”路线图的骨架，我按照数据、模型、部署、监控四个模块来讲，并给出每个模块里你需要达到的“合格线”。
3.1 数据工程能力：AI项目的地基，决定了天花板
数据是AI系统最底层的生产资料。数据质量出了问题，后面模型再强也救不回来，业内常说“garbage in, garbage out”，这不是一句玩笑话。我在一个实体识别项目里就栽过大跟头：初版模型训练时F1在0.9以上，看起来很好，一上线上实测跌到0.6，最后排查发现是训练数据里有大量错别字，而且标注规则的边界跟真实用户输入差异巨大。问题不在模型，在数据和标注环节。
那AI工程方向的数据能力具体指什么？至少包含这几个方面：
- 数据探查（EDA）：拿到一批数据后，通过描述性统计、分布图、抽样检查等手段快速判断数据质量、识别异常值、发现格式问题
- 数据清洗与预处理：处理缺失值、去重、统一格式、编码转换、文本规范化（全角半角、大小写、繁简转换等），不同业务场景的预处理逻辑不一样，要能按需开发
- 数据管线构建：用Python实现可复用的数据处理流程，配合Airflow、DolphinScheduler之类的调度工具定时跑批，保证数据稳定地从源头流向训练和推理模块
- 数据版本管理：训练集、验证集、测试集要能追溯到是哪个版本的数据生成的，特别是数据持续迭代的场景，一定要有类似DVC（Data Version Control）或自建数据快照的机制
实际上大多数AI项目的难点不在算法选型，而在“把非结构化的、脏乱的真实数据变成干净且具有代表性的训练样本”这个过程。这一步做扎实了，模型的调优空间和业务表现的稳定性都会大幅提升。
3.2 模型开发能力：从“会用框架”到“理解框架”
模型开发模块的重心不是问你读过多少篇论文，而是看你能不能快速、正确地用现有工具解决实际任务。当前的实际工作中，绝大多数场景不需要你从零实现一个新模型结构，而是要用好预训练模型和成熟框架。但这不意味着你只是一个“调包侠”，你需要真正理解框架背后的运行机制。
以PyTorch为例，你需要掌握的不只是nn.Module的写法，还要理解：
- DataLoader的加载机制、num_workers参数对数据吞吐的影响
- optimizer.step()、scheduler.step()、zero_grad()在训练循环中的正确调用顺序
- 模型如何从GPU显存加载，如何用.to(device)管理设备迁移
- 混合精度训练（AMP）怎么开启，它为什么能加速，以及什么情况下会造成数值不稳定
- 分布式训练里DDP（Distributed Data Parallel）的基本原理，多卡之间梯度怎么同步
这些知识在教科书上不一定讲得很细，但在翻车排查时特别有用。我之前遇到过新手训练loss出现NaN，一直以为是数据问题，查了半天才发现是学习率太高导致梯度爆炸。如果他对训练过程的数值流动有概念，就不会在这类问题上被卡住那么久。
另外模型评估这块要格外重视。不要只看单一指标，要学会分层看表现：分类任务要看每一类别的precision、recall、F1，而不是只看整体准确率；回归任务要看误差分布，特别关注极端case的预测偏离程度；排序任务要看不同位置的命中率差异；生成任务要结合业务场景去看语义相关性和事实准确性，而不只是ROUGE或BLEU分值。
我比较推荐每个项目都配一个评估套件（evaluation suite），把历史模型、当前模型、候选新模型放在同一套测试集上跑，自动生成对比报告。这能帮你快速定位哪个版本更好、好在哪里、有没有引入新的badcase。这种工程习惯能让你在模型迭代时心里有底。
3.3 服务化部署能力：让你的模型真正创造价值
模型在notebook里跑出多好的指标，不部署成服务就永远只是实验产物。部署环节是把AI能力转化为业务价值的关键一跳，也是AI工程和AI算法最显著的分水岭。这部分要掌握的内容主线路，我拆成三条。
第一条是推理服务的开发与封装。最常见的方案是把模型包成一个HTTP接口，用Flask、FastAPI或TorchServe等框架实现。这里要注意的不只是“能返回结果”，而是要考虑请求格式规范、异常处理、超时设置、并发策略和返回值结构设计。用FastAPI的人越来越多，因为它基于异步技术，性能好、交互文档自动生成，调试方便。
第二条是推理性能与成本控制。模型在GPU上推理比在CPU上快很多，但GPU贵，资源也未必充足。于是需要掌握一系列性能优化手段：模型量化（INT8、FP16，牺牲一点点精度换取成倍速度提升）、批推理（把多条请求拼成一个batch喂给模型）、结果缓存（对相同或近似输入直接返回历史结果）、蒸馏剪枝（用大模型指导小模型训练）。
举一个具体的例子：我做过一个文本分类服务，最初用BERT-base，单条推理延迟大约30~50ms，在GPU上跑还算能接受。但业务量一大，GPU实例费用就很可怕。后来做了三件事：把模型蒸馏成一个小模型，用时延从40ms降到10ms内，再把常见问题答案做了缓存，最终只需要原来三分之一的计算资源。这就是典型的工程优化，比换一个更大更强的模型有意义得多。
第三条是服务的稳定性和可运维性。模型文件要固化版本号，服务要支持优雅启停和健康检查，资源占用要有上限保护，流量突增时要有限流降级机制。这些要求在一个正规的AI工程项目里基本上都是标配，没有它们，这个服务就谈不上生产可用。
3.4 监控与持续迭代：上线只是开始，不是结束
很多团队把模型部署上线当作项目的终点，但AI工程和传统软件开发最不同的地方就在这里：模型会衰减（model decay），数据和业务环境一变，它的表现就会下降。你今天精心训练的模型，三个月后可能就成了摆设。
模型衰减来自多方面：用户在真实环境里的输入分布发生变化（比如出现新的话题类型、新的商品类目）；数据采集渠道调整；上下游系统的输出格式改动；甚至季节周期也会带来分布漂移。所以AI工程必须建立监控体系，以及配套的迭代机制。
监控至少包含三个层面：
- 系统层：服务器的CPU、内存、GPU利用率、请求时延、吞吐量、错误率
- 模型输入层：输入数据的特征分布、缺失率、异常文本比例，以及和训练期分布的差异程度，已经在工业界被广泛采用的PSI（Population Stability Index）就是一个常用指标
- 模型输出层：预测结果的类别分布、置信度分布、反馈转化表现，这个环节需要业务侧配合，最好能采集到线上反馈做闭环
有了监控数据之后，还需要一套模型更新的机制。哪类case多了、哪种错误变频繁了，这些要能快速沉淀成新的训练数据，触发再训练流程，并将新模型做A/B测试后平滑上线。这套机制听起来复杂，但在“ai-engineering”的实际工作中，它就是核心竞争力的体现。
4. 从0到1的完整实操：构建一个端到端的AI服务项目
光讲概念没有体感，我这一节用一个非常典型且适合初学者练手的项目来串联全链路——构建一个“文档智能问答服务”。这个项目的输入是一批公司内部文档（PDF、Word、TXT格式都有），输出是一个Web服务，用户可以用自然语言提问，服务返回相关答案并标注来源。它麻雀虽小五脏俱全，数据、模型、部署、监控四个核心模块全部覆盖。
4.1 第一步：明确需求与指标
项目一开始就要定清楚目标和验收标准，千万不要上线时再拍脑袋。我定的初始目标是这样：
- 支持上传PDF、TXT格式的文档，并解析出正文
- 建立文档向量索引，支持语义检索
- 用户提问后，系统能定位到最相关的若干段落，并生成一段回答
- 单条问答的端到端延迟小于5秒（在CPU环境），召回结果Top-3准确率不低于70%（这个标准可以根据选用的模型灵活调整）
这个验收标准看起来简单，但落实下来每一步都有讲究。
4.2 第二步：数据准备与文档解析
这一步发生在模型之前，却是整个项目成败的关键。我以这个项目为例，把数据流程完整展开一下。
文档解析的坑比想象中多得多。PDF文件可能是扫描件（需要OCR）、可能是纯文本型（可正常提取）、可能是表格密集型（需要版面分析）。如果无脑用pdfplumber或PyPDF2去抽文本，遇到扫描件时只会抽出一堆乱码或空字符串。我的做法是先加一个探测逻辑：读取文本后计算可打印字符比例，低于阈值就自动走OCR流程。OCR选的是PaddleOCR，中文场景下效果好，而且能输出文字块坐标，方便后续做段落重建。
Word文件用python-docx库提取段落文本；TXT要注意编码问题，GBK和UTF-8混杂是常态，需要先尝试解码或者用chardet做编码探测。另外还有一个细节：所有提取出来的文本要做规范化，把多余空白符压缩、全角符号转半角、清理页眉页脚。
文本清洗之后就是切分（chunking）环节。切分在RAG系统里是个直接影响检索效果的关键操作。切太短语义不完整，切太长检索粒度太粗。我这里采用的是“按段落优先、超长段落按句子边界二次切分”的策略，每个chunk控制在300~500字之间，并保留其来源文档名和页码，方便最后溯源。
4.3 第三步：向量化与检索
文档切分好之后，每一段都变成一个“检索单元”。要让这些检索单元能回答用户的问题，第一步是把它们转成向量并建立索引。
我当时选的嵌入模型是bge-large-zh-v1.5，中文语义匹配能力很不错（用FlagEmbedding加载），在普通CPU上做批量向量化也能接受。向量维度1024，不算夸张，但也已经不小了。为了后面检索速度快、存储体积可控，我用了FAISS建索引。
这里有一个新手很容易翻车的点：嵌入模型对长文本的效果是随着长度衰减的。你的chunk如果超过模型的max length，直接截断会导致向量质量急剧下降。所以要么把chunk控制在模型支持的token数以内，要么分段多次嵌入后做平均池化。我自己是两种方案都试过，实测下来“切在合理长度内+用CLS向量”效果最稳。
检索环节我用了“向量召回 + 字符串模糊匹配兜底”的双路策略。向量召回解决语义相似但字面不重合的问题；模糊匹配解决精确名词（产品型号、人名、编号）必须命中的问题。两条路的召回结果合并，再做一次重排。重排模型我选的是bge-reranker-large，效果明显比单纯靠向量相似度更准，代价是多了一次模型推理，但在这个场景延迟可以接受。
4.4 第四步：生成答案
检索到相关资料只是拿到了“素材”，要生成答案还要接一个LLM。这个项目里我用的是Qwen2-7B-Instruct（当时比较容易部署的中文开源模型），通过vLLM部署成一个推理服务。vLLM的优势是吞吐量和显存管理远远优于原生transformers，适合并发场景。
生成阶段有一个非常重要的工程细节：prompt模板和上下文管理。你要把检索到的文本块有序拼装进prompt，并明确告诉模型“只能根据给定资料回答，资料中没有的信息就说不知道”。这一步直接决定了生成内容会不会瞎编（hallucination）。同时还需要控制输出长度和超时时间，避免用户等太久或者模型无限制地生成。
我用的核心prompt结构比较简单，大致是：系统角色设定、资料列表（带来源标识）、用户问题、回答约束。注意资料列表不要一股脑全塞进去，上下文过长不仅浪费token，还会稀释模型对核心内容的注意力。一般控制在Top-3到Top-5以内就够。
最终返回的格式我设计为JSON结构：answer（回答正文）、sources（来源文档和页码）、confidence（置信度分数，结合检索分数和生成logits综合给出）。这个结构方便上层做展示和交互。
4.5 第五步：服务化与容器化
所有模块都能在本地串起来跑通之后，我开始做服务化。整体架构我用FastAPI包了一层Web服务，对外暴露两个接口：
- POST /upload：接收文档流，存到本地并触发异步的数据解析与索引更新
- POST /query：接收用户问题，同步走“检索-重排-生成”流程并返回结果
为了让服务不阻塞，上传接口和索引更新用了后台任务队列（我图简单用的FastAPI的BackgroundTasks，如果数据量大可以考虑Celery）。查询接口因为是同步返回，所以很看重推理链路的速度优化。当时实测下来，在单张T4 GPU上，走完整个pipeline大概需要2~3秒，在CPU上则要十几秒，所以生产环境我选择GPU推理。
容器化方面，用Docker把服务、模型依赖、运行环境打成一个镜像。Dockerfile里有一处值得注意的坑：模型文件很大，放进镜像会很大，构建和推送都慢。我后来把模型文件挂载到宿主机的目录，通过环境变量指定路径，镜像只放代码和依赖，build体积直接从十几GB降到2GB出头。
4.6 第六步：评估、监控与迭代
服务上线前，我先准备了一个小批量的手工测试集，大概50个问题，覆盖常见提问方式、含糊提问、超纲问题等类型。上线后用脚本自动跑评估，统计Top-3命中率、端到端延迟、无答案率这几个关键指标。
监控端我用了Prometheus + Grafana的组合。在FastAPI里加了一个中间件，记录每个接口的请求量、时延、错误码分布，再暴露出/metrics端口给Prometheus抓取。除了服务层监控，我还对向量库的状态加了日志：每次检索请求记录检索命中的文档ID和分数，便于追溯上线后有没有出现大量检索漂移。
整个项目从零到一跑完，大概需要两周到三周的全职时间。这个过程里学到的东西，比看十本书都多。特别是“数据切分策略”“检索重排的配合”“生成幻觉的抑制”这三点，纸上谈兵完全感受不到其中的微妙。
5. 常见问题与排查技巧实录
在“from scratch”的学习过程中，你会不断遇到各种匪夷所思的问题。我总结几个出镜率最高的故障场景，把解决思路一并写出来，希望能帮你少踩几步坑。
5.1 环境与依赖问题
症状一：同一个项目，在同事电脑上能跑，在自己电脑上就报各种奇怪的错。
原因通常是环境不一致带来的依赖错位。Python的包管理虽然方便，但版本问题极其痛苦，尤其CUDA、cuDNN、PyTorch三者的版本必须严格匹配，哪个对不上都可能出现“import torch报错”或者“运行时报 CUDA error: no kernel image is available”。
对策：尽量用Docker统一环境，把基础镜像固定到具体tag（比如pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime），不要再从基础ubuntu开始一遍遍装依赖。做实验时养成“一项目一虚拟环境”的好习惯，并把requirements.txt或者environment.yml同步进Git仓库。如果只在本地做开发，建议用conda管理Python版本，因为不同项目对Python版本的要求可能完全不同。
5.2 训练与推理的显存问题
症状二：模型加载到GPU时报out of memory。
这条问题出现概率极高。先看硬件资源：如果显存只有8GB，就不要直接加载需要16GB显存的模型，这是硬边界。再看框架层面：训练阶段out of memory通常和batch size、序列长度有关；推理阶段则要看模型的KV cache占用。
排查顺序我一般是这样：先用nvidia-smi确认显卡当前没有别人占用；然后逐步缩小batch size或者序列长度；再考虑换用梯度累积（gradient accumulation，用小batch模拟大batch）或者混合精度训练；还不行就考虑换模型或者用CPU offload。补充一个容易忽略的点：PyTorch的显存有时不会立即释放，程序里有大块tensor没删干净，扩展一下说就是del变量后还要torch.cuda.empty_cache()这步操作在某些场景下很有效。
5.3 模型上线后的效果严重下滑
症状三：离线测试指标很好，线上表现一塌糊涂。
这种情况多半出在“训练数据分布”和“线上真实输入分布”不一致上。比如训练集用的是整洁的新闻文章，线上来的是用户随手发送的短文本、带口语、带网络用语、带错别字。模型没见过这种风格，自然效果大跌。
思路是：先做badcase复盘，把预测错的线上样本收集起来归类，找共性；如果是表达风格差异，可以把线上日志里积累的真实样本纳入训练集，做一轮增量训练；如果是某个类别的样本太少导致的偏斜，就优先补该类的数据。定期做模型重训并设置“数据反馈闭环”，是解决这类问题的最根本手段。
5.4 检索系统查不到相关内容
症状四：在RAG项目里，用户的问题明明在文档里有答案，但检索环节漏掉了。
这个问题的原因集中在三处：切分粒度不合适、嵌入模型不够强、召回策略太单一。切分粒度方面，过长的chunk里包含大量无关信息，和用户query的向量相似度被稀释；过短的chunk缺少上下文，无法完整表达语义。嵌入模型方面，通用模型在某些垂直领域（法律、医疗、编程）表现较弱，可以换领域微调的embedding模型，比如中文场景下的bge系列就比很多老模型效果好。召回策略上，除了向量召回，可以加BM25或关键词匹配作为另一路，然后再用reranker去重排融合结果。
5.5 模型输出中的幻觉问题
症状五：生成式项目里，模型一本正经地编造文档里不存在的内容。
Transformer生成模型本身不具备事实判断能力，它的目标只是“生成看起来合理的文本”。所以抑制幻觉的关键在于外部机制：把事实约束在检索到的资料里，prompt明确说明“只能根据资料回答，禁止推测”，同时把回答和资料引用绑定，让用户可验证来源。更进一步的做法是训练一个“答案可支撑性确认”模型，判断生成内容能否从资料中找到依据。但说实话，工程上最有效的还是prompt约束和资料引用机制。
6. 个人经验：AI工程学习路径上的几点建议
项目做到这个程度，知识体系的大框架其实已经构建得差不多了，再往后就是持续深挖和横向拓展。我自己一路走下来，有几条体会想重点说给走这条路的人听。
第一，动手做项目做项目做项目，且要做带部署环节的项目。没有哪一种学习方式比亲手把一个模型服务放上公网、被真实用户调用更能逼你正视工程问题。部署这个环节至少能倒逼你去学Linux、Docker、服务运维这些在notebook环境里永远不会遇到的问题。
第二，尽早建立“系统全局”的意识。AI工程不是一段代码的事，而是数据、模型、服务、监控、业务反馈的多环节协同。你在改进模型的时候，始终要追问“这会怎么影响端到端的体验”“会不会给下游系统带来新负担”。一个局部的最优解，放在全局里可能并不是好选择。
第三，给自己持续制造“可控的麻烦”。训练时手动调低数据质量看看会不会崩；部署时故意模拟网络抖动和流量高峰看服务能不能扛住；上线后定期抽查badcase。这些在真实工作中属于必须做的质量保障，自己练习时也当成习惯来养。这种“自虐式”的训练，会让你在遇到线上故障时比别人镇定得多。
最后一点，也是很多新人容易忽略的——主动参与和分享。无论是开源社区、技术博客还是团队内部的代码评审，把你的设计思考和技术决策讲出来，本身就是一种强制性的知识梳理。你在解释一个系统的时候，才会发现自己哪里想得还不够清楚。还要留意和业务方多沟通，技术最终是拿来解决具体问题的，理解不了真实需求的技术方案，做出来也很容易是一辆没人开的豪华跑车。
