0032 AI Engineering （II）：动手干活的硬核技术

date

May 25, 2026

summary

AI Engineering 不能纸上谈兵，本文介绍它动手干活的硬核技术

status

Published

AI Engineering （II）：动手干活的硬核技术

一、RAG 与 Agents：给模型装上外挂

这章讲的是怎么让模型在回答问题时"有据可依"，而不是全靠脑补。

RAG：检索增强生成

RAG 的核心就两步：先查资料、再写回答。模型本身记不住所有东西（你也记不住），那就让它去查。

为什么长上下文不会终结 RAG？ 就算模型能处理 100 万 token 的上下文，也不意味着它能把 100 万 token 都用好——上下文越长，模型越容易"看花眼"，而且每个多余 token 都在烧你的钱。RAG 只给模型最相关的信息，省 token 又提效果。

检索算法

基于词项的检索：关键词匹配。代表有 Elasticsearch 和 BM25。快、便宜、开箱即用。但"transformer architecture"可能搜出一堆变压器的文章。

基于 Embedding 的检索：把文档转成向量，找语义相近的。支持向量数据库（FAISS、Milvus、Pinecone）和近似最近邻搜索算法（HNSW、LSH、Product Quantization、IVF）。空间换时间，效果可以更好，但贵得多。

混合搜索：先关键词粗筛，再 embedding 精排；或多个检索器并行用 RRF（倒数排名融合）合并结果。

检索优化四件套

Chunking 策略 — 块太小缺上下文、块太大信息杂。没有最佳块大小，得试

Reranking — 初次检索后二次精排，可结合时间、相关性等因素

Query Rewriting — 把"她呢？"改写为"Emily Doe 上次什么时候从我们这买东西？"

Contextual Retrieval — 给每个块加一段"小抄"辅助检索，Anthropic 的做法是用 AI 为每个块生成 50-100 token 的语境描述

RAG 与 Agent 架构对比图

表格数据 RAG

电商场景下：用户问"过去 7 天 Fruity Fedora 卖了多少件？" → Text-to-SQL 生成 SQL 查询 → 执行 SQL → 基于结果生成回答。

Agents：让 AI 自己干活

Agent = 环境 + 工具 + AI 大脑。AI 负责规划（怎么完成任务）、调用工具、反思和纠错。

工具三大类：

知识增强：RAG 检索、SQL 执行、联网搜索

能力扩展：计算器、翻译器、代码解释器——模型数学不好就给它个计算器，别死磕

写操作：发邮件、改数据库——厉害但危险，权限要最小化

ReAct 模式：Thought → Act → Observation → 循环直到任务完成。Reflexion 在其基础上加了专门的评估器（evaluator）和反思模块。

常见失败模式：调用了不存在的工具、参数错误、规划太差、以为自己完成了其实没有。

记忆系统

模型自己（内部知识）← 上下文（短期记忆）← 外部数据库（长期记忆）。短期内存不够时可以用 FIFO 或摘要策略把"溢出"的部分存到长期记忆里。

二、微调：让模型学会你的规矩

什么时候该微调？

核心原则：微调管形式，RAG 管事实。

模型输出格式不对、风格跑偏 → 微调

模型缺知识、信息过时 → RAG

先用 prompt 试，再上 RAG，最后才考虑微调

内存瓶颈

微调大模型最难的是显存。训练需要存权重 + 梯度 + 优化器状态。用 Adam 优化器调 13B 模型，光梯度和状态就要 78 GB。

量化降精度：FP32 → FP16 显存减半。FP32 的 13B 模型要 52 GB，FP16 只要 26 GB。还能更低：INT8、INT4，甚至 BitNet b1.58 1-bit LLM。

LoRA：最流行的微调方案

LoRA（Low-Rank Adaptation）把一个大权重矩阵分解成两个小矩阵的乘积，微调时只调小矩阵。

参数量降到原来的 0.0027%

推理时可以合并回原模型，不增加延迟

多 LoRA 服务：同一个基模型 + 不同适配器，服务 100 个客户只用存 1 套大权重 + 100 套小权重

QLoRA：把基模型量化到 4-bit（NF4 格式），65B 模型单卡 48GB 就能微调

模型合并

不想从头训练？把几个微调好的模型合并就行。常见方法：

线性组合 / SLERP：权重加权平均

Layer stacking：把两个模型不同层叠起来（Goliath-120B 就是这么来的）

TIES/DARE：剪掉冗余参数再合并，效果更好

三、数据集工程：数据才是真正的护城河

Data-Centric AI

别只盯着模型结构。同样的模型，数据好效果就好。GPT-3 团队只有 2 人负责数据处理，GPT-4 增加到 80 人——说明高质量数据越来越重要。

数据质量六要素

相关、符合任务要求、一致、格式正确、足够唯一、合规。10K 条精心编写的指令数据可能比几百万条噪声数据更有用。

数据量和多样性

简单任务几百条就够了，复杂任务可能需要上万条。先用 50 条试试水——如果 50 条都没效果，加数据也没用。多样性同样重要，Llama 3 的预训练数据里数学和代码占了 42%。

数据合成

AI 自己的数据也能用来训练：

Self-play：让 AI 自己跟自己下棋、谈判，生成训练数据

反向指令：拿高质量长文本（故事、维基），让 AI 生成可能产生这些文本的指令

翻译增强：把英语数据翻译成低资源语言

蒸馏：用大模型生成数据来训练小模型

但合成数据不能完全替代人工数据，混合使用效果最好。

四、推理优化：又快又省是王道

性能指标

TTFT（首 token 延迟）— 用户发出请求到看到第一个字的时间

TPOT（每 token 时间）— 之后每生成一个字的时间

吞吐量 — 每秒能生成的 token 数，直接关联成本

MFU/MBU — 芯片利用效率，看看你的 GPU 有没有在偷懒

计算瓶颈

大模型推理有两个阶段：Prefill（处理输入，计算密集）和Decode（逐个生成，带宽密集）。两者可以放在不同的机器上跑（prefill/decode 解耦）。

推理加速技术

模型层面：

量化：FP16 → INT8/INT4，显存减半甚至减四分之三。目前最常用的优化

蒸馏：大模型教小模型，小模型跑得快

剪枝：删掉不重要的参数（但实践中不常用）

推测解码：用一个小模型快速"起草"，大模型并行校验。效果好，不改变输出质量

并行解码（Medusa、Lookahead）：一次预测多个 token，打破顺序生成瓶颈

服务层面：

Batching：静态→动态→连续（Continuous batching），Orca 论文提出的连续批处理大幅提升吞吐

KV Cache 优化：vLLM 的 PagedAttention 把 KV 缓存分页管理，减少碎片

Prompt Caching：系统提示词缓存起来重复用

FlashAttention：把 attention 计算里的多个操作融合成一个 kernel，又快又省显存

推理优化技术栈

五、系统架构设计与用户反馈

搭建 AI 应用的六个台阶

基础版：用户 → API → 回答

加上下文：接入 RAG 检索、联网、工具

加护栏：输入输出过滤、敏感信息脱敏

加路由和网关：不同问题走不同模型、统一管理 API 密钥和调用限额

加缓存：精确缓存 + 语义缓存（语义相似的问题复用答案）

加 Agent：循环、条件分支、写操作（发邮件、下单）

可观测性

监控三件套：指标（Metrics）、日志（Logs）、链路追踪（Traces）。注意模型漂移——你的 prompt 没改，但 AI API 偷偷更新了底层模型，回答质量可能突然变差。

用户反馈的艺术

AI 应用的反馈比传统软件更丰富：

显式反馈：点赞/点踩、星级评分

隐式反馈：提前终止生成、纠错（"不对，我说的是……"）、重说、重新生成、编辑回答

对话分析：用户情绪、对话轮数、分享/删除对话等行为

小技巧：Midjourney 让你从四张图里选一张放大（upscale）或生成变体——每种操作都是隐式反馈。GitHub Copilot 用灰色显示代码建议，按 Tab 接受、继续打字无视——都在告诉它"这个建议好不好"。

但要小心退化反馈循环：用户喜欢猫 → AI 生成更多猫 → 吸引更多猫奴 → 你的应用变成猫主题公园。反馈偏见（宽容偏差、位置偏差）也需要留意。

总结

几个关键心法：

能走 prompt 别微调，先试 RAG 再考虑微调

数据质量 > 数据数量，精心准备的 50 条数据比 50 万条噪声更有用

评估是最容易被低估的环节（即使你已经读过前三章，这里还是要强调一遍）

推理成本决定产品能否落地 — 量化、缓存、批处理是你的好朋友

用户反馈是你的数据飞轮 — 设计好反馈机制就能持续改进产品

正如高人所说：AI 工程化的挑战很多，但不是所有挑战都有趣，但每个挑战都是成长和产生影响的机会。