AI从数据学习到商业系统的完整原理
AI 不是某一个软件,也不是聊天机器人的同义词。它是一组让计算机完成感知、预测、分类、生成、规划和决策辅助等任务的方法。规则引擎、搜索排序、传统机器学习、深度学习、大语言模型和多模态模型都可以参与 AI 系统。
零基础最容易犯两个错误:
- 把 AI 等同于调用一次大模型 API。
- 只背模型名称,却不知道数据怎样变成模型、模型怎样产生结果、结果为什么会错误。
本章从一个最基础的问题开始:计算机原本只会执行确定的指令,它怎样从历史数据中学到一个可用于新数据的规律?然后再把这条原理连接到神经网络、大模型、RAG、Tool Calling、Agent 和商业系统。
一、学完本章应该具备什么能力
学完后,你应该能够:
- 区分 AI、规则系统、机器学习、深度学习、生成式 AI 和大模型。
- 解释样本、特征、标签、参数、超参数、Loss、梯度、训练、验证、测试和推理。
- 从零讲清一个监督学习模型怎样通过数据更新参数。
- 解释训练集表现好为什么不等于遇到新数据也好。
- 解释神经网络怎样从线性变换和非线性激活逐层学习表示。
- 解释大模型预训练、微调和逐 Token 推理分别在做什么。
- 区分模型参数里的统计规律、RAG 外部知识和工具返回的实时事实。
- 判断一个业务问题应该用规则、搜索、传统 ML、RAG、工具还是大模型。
- 画出商业 AI 请求从鉴权到响应的完整链路,并说明每一步缺失的后果。
- 根据证据排查“模型不准、突然退化、成本升高、结果越权”等问题。
二、先建立完整概念地图
flowchart TD
A["AI人工智能"] --> B["规则、搜索与规划"]
A --> C["机器学习"]
C --> D["传统机器学习"]
C --> E["深度学习"]
E --> F["视觉、语音与自然语言模型"]
F --> G["基础模型"]
G --> H["大语言模型"]
G --> I["视觉语言、扩散等生成模型"]
H --> J["生成式AI应用"]
I --> J
J --> K["Prompt、RAG、Tool与Agent"]| 概念 | 核心含义 | 例子 |
|---|---|---|
| AI | 让计算机完成通常需要理解、判断或规划的任务的总称 | 路径规划、推荐、异常识别、问答 |
| 规则系统 | 人明确写出条件和动作 | 金额大于10万元必须二次审批 |
| 机器学习 | 从样本中估计输入到输出的规律 | 根据历史交易识别欺诈风险 |
| 深度学习 | 使用多层神经网络学习复杂表示 | OCR、语音识别、图像分类 |
| 基础模型 | 在大规模数据上训练、可适配多个下游任务的模型 | 语言模型、视觉语言模型 |
| 大语言模型 | 以大规模文本或代码训练、按上下文生成Token的模型 | 问答、摘要、代码、抽取 |
| 生成式AI | 生成文本、图像、音频、视频或结构化内容 | 工单摘要、营销图、语音合成 |
| AI应用 | 把模型、业务数据、权限、工具和工程治理组合起来 | 企业知识助手、采集运维助手 |
包含关系不是“新技术完全替代旧技术”。一个订单系统可以同时使用:
- 规则判断订单状态能否流转。
- 传统 ML 预测欺诈风险。
- 搜索引擎查错误码和商品。
- RAG 查询企业制度。
- 大模型总结工单。
- Tool Calling 查询实时订单状态。
三、规则编程和机器学习有什么不同
3.1 传统规则编程
程序员明确写出规则:
def risk_level(amount: float, failed_login_count: int) -> str:
if amount >= 100_000 or failed_login_count >= 5:
return "high"
return "normal"执行关系是:
规则 + 输入 → 输出优点是确定、可审计、容易解释;缺点是现实模式复杂时,规则数量会爆炸,很多边界也难以由人准确写出。
3.2 机器学习
机器学习把历史输入和正确结果交给算法,让算法寻找一组参数:
历史输入 + 历史正确输出 + 学习算法 → 模型参数
模型参数 + 新输入 → 预测输出flowchart TD
A["历史样本"] --> B["定义输入特征与目标标签"]
B --> C["模型根据当前参数预测"]
C --> D["Loss衡量预测与标签差距"]
D --> E["计算参数应调整的方向"]
E --> F["优化器更新参数"]
F --> G{"训练是否结束"}
G -- "否" --> C
G -- "是" --> H["固定模型用于新数据推理"]机器学习并不是把训练数据原样保存后查表。它的目标是从有限样本中学习可推广到未见样本的模式,这种能力称为泛化。
四、必须掌握的基础术语
假设要预测用户是否会流失:
| 术语 | 含义 | 流失预测例子 |
|---|---|---|
| 样本 Sample | 一条用于训练或评估的数据 | 一个用户在某个观察周期的数据 |
| 特征 Feature | 模型看到的输入变量 | 登录天数、付费次数、投诉数 |
| 标签 Label | 希望模型学习的正确目标 | 30天内是否流失,0或1 |
| 模型 Model | 参数化的输入到输出函数 | 逻辑回归、决策树、神经网络 |
| 参数 Parameter | 训练过程中由数据学习的值 | 每个特征对应的权重和偏置 |
| 超参数 Hyperparameter | 训练前或搜索时设定的配置 | 学习率、树深、Batch大小 |
| 预测 Prediction | 模型对输入产生的结果 | 流失概率0.82 |
| Loss | 单个或一批预测与目标差距的数学度量 | 二元交叉熵 |
| Metric | 人用于衡量业务效果的指标 | Precision、Recall、F1 |
| 训练 Training | 根据Loss更新参数 | 反复处理历史用户样本 |
| 推理 Inference | 固定参数,对新输入计算输出 | 给今天的新用户打风险分 |
4.1 参数和超参数不要混淆
权重 w 和偏置 b 是模型根据训练数据学出来的参数;学习率、训练轮数、网络层数通常是超参数。超参数不会通过普通反向传播自动变成最优值,需要实验、搜索和验证集选择。
4.2 Loss和业务指标不是一回事
Loss 必须适合优化,通常连续、可求导;业务指标负责回答系统是否有价值。例如欺诈识别中,训练交叉熵下降,不代表高风险欺诈的 Recall 一定达到上线要求。
如果只看 Accuracy,在 10,000 笔交易中只有 10 笔欺诈时,模型全部预测“正常”也有 99.9% Accuracy,却一笔欺诈都没抓到。因此必须看混淆矩阵、Precision、Recall、F1、成本和风险分层。
五、一个模型怎样真正学到参数
先用最简单的线性模型理解训练。假设用学习时长 x 预测考试成绩 y:
预测值 y_hat = w × x + bw 表示学习时长增加一单位时,预测成绩怎样变化;b 是基准偏置。刚开始 w、b 可以随机或置零,此时预测通常不准。
5.1 前向计算
把样本输入当前模型:
x = 2小时
w = 10
b = 20
y_hat = 10 × 2 + 20 = 40
真实成绩 y = 605.2 Loss衡量差距
使用均方误差的单样本形式:
Loss = (y_hat - y)²
= (40 - 60)²
= 400Loss 大表示当前参数产生的预测离标签远,但它还没有告诉我们参数应该增大还是减小。
5.3 梯度表示局部变化方向
梯度是 Loss 对参数的导数。对当前例子:
dLoss/dw = 2 × (y_hat - y) × x
dLoss/db = 2 × (y_hat - y)由于 y_hat - y = -20,梯度为负,沿梯度反方向更新会让 w、b 增大,使预测靠近 60。
5.4 梯度下降更新参数
新参数 = 旧参数 - 学习率 × 梯度学习率太大可能越过低点甚至发散;太小则训练很慢。更新一次只是一步,训练会对许多 Batch、许多轮重复前向、Loss、反向和更新。
flowchart TD
A["Batch输入模型"] --> B["前向计算预测"]
B --> C["根据标签计算Loss"]
C --> D["反向传播计算各参数梯度"]
D --> E["优化器更新参数"]
E --> F["处理下一个Batch"]
F --> G{"本轮Epoch结束"}
G -- "否" --> A
G -- "是" --> H["验证集评估"]
H --> I{"继续训练或早停"}
I -- "继续" --> A
I -- "停止" --> J["保存模型与训练元数据"]六、可运行Demo:不用框架训练一个线性模型
下面只使用 Python 标准库,目的是看清训练循环,而不是替代成熟机器学习框架。
from dataclasses import dataclass
@dataclass
class LinearModel:
weight: float = 0.0
bias: float = 0.0
def predict(self, x: float) -> float:
return self.weight * x + self.bias
def mean_squared_error(model: LinearModel, samples: list[tuple[float, float]]) -> float:
return sum((model.predict(x) - y) ** 2 for x, y in samples) / len(samples)
def train(
model: LinearModel,
samples: list[tuple[float, float]],
learning_rate: float,
epochs: int,
) -> None:
for epoch in range(epochs):
grad_w = 0.0
grad_b = 0.0
# 前向计算后,根据全部样本求平均梯度。
for x, y in samples:
error = model.predict(x) - y
grad_w += 2.0 * error * x
grad_b += 2.0 * error
grad_w /= len(samples)
grad_b /= len(samples)
# 梯度下降:沿着使Loss减小的反方向更新。
model.weight -= learning_rate * grad_w
model.bias -= learning_rate * grad_b
if epoch in {0, 9, 99, epochs - 1}:
print(
f"epoch={epoch + 1:4d} "
f"loss={mean_squared_error(model, samples):.6f} "
f"w={model.weight:.4f} b={model.bias:.4f}"
)
if __name__ == "__main__":
# 人工构造关系:y = 8x + 30。
training_samples = [
(1.0, 38.0),
(2.0, 46.0),
(3.0, 54.0),
(4.0, 62.0),
(5.0, 70.0),
]
model = LinearModel()
before = mean_squared_error(model, training_samples)
train(model, training_samples, learning_rate=0.01, epochs=3000)
after = mean_squared_error(model, training_samples)
# 6小时没有出现在训练集中,用它演示对未见输入推理。
prediction = model.predict(6.0)
print(f"before={before:.4f}, after={after:.6f}, prediction(6)={prediction:.4f}")
assert after < before
assert abs(prediction - 78.0) < 0.5这段代码展示了四个关键事实:
- 训练前参数不知道真实规律。
- 每轮根据预测误差计算梯度并更新参数。
- Loss 下降意味着对训练目标的数学误差减小。
- 对未出现的
x=6预测接近 78,说明模型学到了这一简单数据分布的规律。
真实业务远比直线复杂,还存在噪声、错误标签、非线性、分布变化和因果混淆,因此不能因为训练集 Loss 很低就直接上线。
七、训练集、验证集和测试集为什么必须分开
7.1 三者职责
| 数据集 | 用途 | 是否用于更新参数或选方案 |
|---|---|---|
| Training | 计算梯度并更新模型参数 | 更新参数 |
| Validation | 选择超参数、阈值、训练轮数和模型方案 | 选择方案 |
| Test | 最后估计未见数据上的泛化效果 | 不应反复用于调参 |
如果看完测试集结果又不断修改模型,测试集就间接参与了优化,最终分数会过于乐观。此时应准备新的独立测试数据。
7.2 数据泄漏是什么
数据泄漏是训练或特征中出现了预测时本不应知道的信息。例如预测用户是否会流失,却把“流失注销时间”作为特征;离线分数会非常高,线上预测时却没有这个字段。
常见泄漏:
- 同一个用户的近似记录同时落入训练集和测试集。
- 先对全量数据计算均值和词表,再切分数据。
- 时间序列随机切分,让未来信息进入过去训练。
- 文档切片随机切分,使同一文档内容出现在训练和测试两边。
- 人工标注时把标准答案写入输入模板。
7.3 为什么常按用户、设备、文档或时间分组切分
随机按行切分只保证“行不同”,不能保证业务实体不同。商业评估常需要:
- 按用户分组,检验新用户泛化。
- 按设备或医院分组,检验跨环境泛化。
- 按文档分组,避免同源切片泄漏。
- 按时间向前验证,模拟真实未来流量。
八、欠拟合、过拟合和泛化
8.1 欠拟合
模型过于简单、训练不足或特征缺失,训练集和验证集都表现差。例如用一条直线拟合强非线性关系。
8.2 过拟合
模型记住训练样本甚至噪声,训练集非常好,验证集却变差。它像背下练习题答案,却没有掌握规律。
flowchart TD
A["观察训练与验证指标"] --> B{"训练集是否也很差"}
B -- "是" --> C["可能欠拟合"]
B -- "否" --> D{"验证集是否明显更差"}
D -- "是" --> E["可能过拟合或数据分布不同"]
D -- "否" --> F["继续检查测试集与业务指标"]
C --> G["改进特征、模型或训练"]
E --> H["更多数据、正则化、早停、去泄漏"]8.3 常见治理方法
- 增加有代表性的高质量数据,而不是只复制现有样本。
- 减少错误标签和近重复数据。
- 正则化,限制模型过度依赖极端参数。
- Dropout、数据增强等方法降低记忆倾向。
- 根据验证集早停。
- 降低模型复杂度。
- 重新检查训练和线上数据是否同分布。
九、监督、无监督、自监督和强化学习
9.1 监督学习
每个训练样本有目标标签,例如垃圾邮件分类、金额预测、实体抽取。模型根据预测与标签的差距更新参数。
9.2 无监督学习
没有人工目标标签,算法从数据结构中寻找聚类、低维表示或异常模式。聚类结果不是天然业务真相,仍需业务解释和验证。
9.3 自监督学习
从原始数据自身构造学习目标。语言模型的下一个 Token 预测就是典型方向:文本本身提供前文和后续目标,因此可以利用海量未人工逐条标注的语料。
9.4 强化学习
智能体观察状态、选择动作并获得奖励,目标是学习长期累计回报。奖励设计错误会导致模型钻规则漏洞,这称为 Reward Hacking。大模型对齐可能使用偏好数据和强化学习方向的方法,但具体训练流程因模型而异。
这四类不是互斥产品标签。一个商业系统可能先用自监督预训练模型,再用监督微调和偏好对齐,应用运行时又通过规则和工具控制动作。
十、神经网络为什么能表达复杂关系
10.1 单个神经元方向
一个简单神经元先做加权求和:
z = w1x1 + w2x2 + ... + b再经过激活函数:
a = activation(z)如果很多层只有线性变换而没有非线性激活,多层仍可合并成一次线性变换,表达能力有限。ReLU、GELU、Sigmoid 等非线性函数让网络能组合出复杂决策边界。
10.2 层怎样学习表示
以图像为直觉:浅层可能响应边缘和纹理,中层组合局部形状,深层形成与类别相关的抽象表示。现代模型的具体表示是分布式的,不能简单断言某一个神经元永远只代表某个固定概念,但“逐层变换形成更适合任务的表示”是理解方向。
10.3 反向传播做什么
前向传播保存每层计算关系;得到 Loss 后,反向传播使用链式法则,从输出层向前计算每个参数对 Loss 的影响。优化器再使用这些梯度更新参数。
flowchart TD
A["输入特征"] --> B["第1层线性变换与激活"]
B --> C["中间隐藏表示"]
C --> D["输出层预测"]
D --> E["根据标签计算Loss"]
E --> F["链式法则反向计算梯度"]
F --> G["优化器更新各层参数"]
G --> A十一、大语言模型是怎样从文本学会生成的
11.1 Tokenization
文本先被 Tokenizer 切成 Token,再映射为整数 ID。Token 不严格等于汉字或英文单词,不同模型词表和算法不同。
11.2 Embedding
Token ID 本身只是编号,模型通过 Embedding 表把每个 Token 映射为连续向量,并加入位置信息,使网络能够处理含义和顺序。
11.3 Transformer
Self-Attention 让当前 Token 的表示根据上下文中的相关 Token 聚合信息;多层 Attention、前馈网络、残差和归一化不断变换表示。
11.4 预训练目标
自回归语言模型常以“根据之前 Token 预测下一个 Token”为训练方向:
输入:数据库事务必须保证
目标:一致性模型在大量序列位置上计算预测分布与真实目标的交叉熵,通过反向传播更新参数。为了持续降低 Loss,它逐渐学习语法、共现关系、文本结构、部分事实模式、代码模式和任务模式。
11.5 SFT和对齐
预训练模型只擅长延续文本,不一定能稳定按助手方式回答。监督微调使用指令—回答样本学习遵循任务;偏好对齐让模型更倾向有帮助、安全和符合预期的响应。对齐提高行为倾向,不会让事实永远正确。
11.6 推理为什么逐Token进行
推理时未来 Token 不存在,模型先计算第一个输出 Token,再把它追加到上下文预测下一个:
flowchart TD
A["消息经过Tokenizer"] --> B["Prefill处理已有上下文"]
B --> C["计算下一个Token的Logits"]
C --> D["Softmax与解码选择Token"]
D --> E["把新Token加入上下文"]
E --> F{"命中EOS、停止词或长度上限"}
F -- "否" --> C
F -- "是" --> G["返回完整响应"]因此输出越长,Decode 步骤越多;流式输出只是让用户更早看到 Token,不一定减少总计算时间。
更深入的 Q/K/V、Causal Mask、KV Cache 和显存计算见 大模型Token、训练与推理原理 与 Transformer原理。
十二、模型“知道知识”究竟是什么意思
12.1 参数不是可精确查询的数据库
训练把统计规律分布式编码进大量参数。模型可以生成训练中常见的事实模式,但不能像数据库那样:
- 保证每条记录实时更新。
- 根据租户和角色执行行级权限。
- 返回唯一、可审计的权威值。
- 自动知道某个订单此刻的状态。
- 保证引用来自哪条原始记录。
12.2 三类“知识来源”必须区分
| 来源 | 适合内容 | 更新方式 | 可靠边界 |
|---|---|---|---|
| 模型参数 | 通用语言和稳定模式 | 重新训练、微调或换模型 | 可能过期、幻觉、难精确引用 |
| RAG上下文 | 企业文档、制度、手册 | 更新文档并重建或增量更新索引 | 取决于检索、ACL、版本和引用校验 |
| Tool结果 | 订单、库存、任务、实时指标 | 实时调用权威业务系统 | 取决于工具鉴权、超时、幂等和业务状态 |
用户问“CAP 是什么”可以依赖模型通用能力;问“公司当前报销制度”应使用 RAG;问“订单 20260716001 是否支付”必须调用订单系统。
十三、模型能力为什么看起来像理解和推理
模型在大规模训练中学习了语言、代码、任务步骤和示例模式,因此能根据上下文形成有用的中间表示并生成多步答案。对应用来说,这种能力可以完成真实任务。
但工程上不能把流畅表达等同于:
- 拥有人类意识。
- 输出一定是事实。
- 给出的解释一定忠实反映内部计算。
- 自己知道用户权限。
- 自己能够承担业务责任。
合理态度是:把模型当作强大的概率式理解和生成组件,通过数据、工具、验证和流程把它约束在可接受风险内。
十四、为什么会产生幻觉
模型优化的是“正确目标 Token 的概率”或对齐目标,不是数据库一致性。以下情况会让错误但流畅的答案概率变高:
- 训练数据中没有该事实、事实过期或相互冲突。
- 用户问题含糊,模型自动补全了错误前提。
- RAG 没召回正确文档,或错误片段进入最终 Prompt。
- 上下文过长,关键证据被截断或淹没。
- 工具失败,却被应用包装成空结果让模型猜。
- Prompt 中规则相互冲突。
- 采样增加了输出变化。
- 模型能力不足,却被要求强行回答。
治理不能只写“不要幻觉”:
权威事实走RAG或Tool
+ 证据不足正确拒答
+ 引用由应用校验
+ 结构化输出三层校验
+ 高风险人工审核
+ 固定评估集和线上监控十五、传统机器学习和大模型怎样选择
| 问题 | 优先考虑 | 原因 |
|---|---|---|
| 表格特征预测流失、风险、需求量 | 传统ML或专用模型 | 成本低、指标清晰、易批处理 |
| 固定规则审批 | 规则引擎 | 确定、可审计 |
| 错误码和字段名精确查找 | 搜索或混合检索 | 精确词匹配可靠 |
| 文档语义问答 | RAG加大模型 | 需要检索证据和自然语言生成 |
| 合同摘要和字段抽取 | 大模型加Schema校验 | 输入非结构化、输出可校验 |
| 实时订单状态 | Tool Calling | 事实必须来自权威系统 |
| 高风险退款或删除 | 工作流、后端规则、人工审批 | 模型不能成为最终授权者 |
不要因为大模型通用就替代本来简单、确定、低成本的方案。商业 AI 的目标是解决业务问题,不是让每条链路都经过大模型。
十六、一个生产AI请求完整经过什么
flowchart TD
A["用户请求"] --> B["认证、租户、限流和参数校验"]
B --> C["场景路由与风险分级"]
C --> D{"事实来源是什么"}
D -- "固定规则" --> E["规则或工作流"]
D -- "企业文档" --> F["带ACL的RAG检索"]
D -- "实时业务数据" --> G["受控Tool调用"]
D -- "通用生成" --> H["Prompt编排"]
F --> H
G --> I["后端鉴权、参数与幂等校验"]
I --> H
H --> J["模型网关选择能力与预算合适的模型"]
J --> K["模型推理"]
K --> L["解析、Schema、业务和安全校验"]
L --> M{"是否需要人工确认"}
M -- "是" --> N["人工审核或审批"]
M -- "否" --> O["返回或提交业务结果"]
N --> O
O --> P["Trace、指标、审计与评估反馈"]16.1 每一步为什么存在
| 步骤 | 解决的问题 | 缺失后果 |
|---|---|---|
| 认证与租户 | 确认请求主体和数据范围 | 越权和跨租户泄露 |
| 限流与预算 | 控制并发、Token和金额 | 服务拥塞、费用失控 |
| 场景路由 | 选择规则、RAG、Tool或模型链路 | 所有请求都走最贵且不可靠路径 |
| RAG ACL | 只召回当前用户可见证据 | 越权文档进入内存、日志和模型 |
| Tool后端校验 | 权限、参数、幂等和业务状态 | 误操作、重复写和越权写 |
| 模型网关 | 根据能力、数据驻留、SLO和成本路由 | 模型不支持工具或Schema,成本不可控 |
| 输出校验 | 检查语法、字段、事实引用和业务规则 | 错误结果直接进入数据库或前端 |
| 人工确认 | 控制高风险和低置信度任务 | AI错误直接造成业务损失 |
| 观测评估 | 复现、发现退化和证明改进 | 线上效果只能靠感觉 |
十七、可运行Demo:按事实来源和风险路由
下面 Demo 不调用真实模型,专门演示生产架构最重要的决策:问题应走哪条权威链路,以及高风险动作为什么不能直接执行。
from dataclasses import dataclass
from enum import Enum
class Route(str, Enum):
RULE = "rule"
RAG = "rag"
TOOL_QUERY = "tool_query"
APPROVAL = "approval"
MODEL = "model"
@dataclass(frozen=True)
class Principal:
user_id: str
tenant_id: str
roles: frozenset[str]
@dataclass(frozen=True)
class Decision:
route: Route
reason: str
can_execute_directly: bool
def decide(question: str, principal: Principal) -> Decision:
text = question.strip()
if not text:
raise ValueError("question不能为空")
if any(word in text for word in ("退款", "删除", "修改价格", "停用账号")):
return Decision(
Route.APPROVAL,
"写操作风险高,模型不能成为最终授权者",
False,
)
if any(word in text for word in ("订单状态", "库存", "任务状态")):
allowed = "support" in principal.roles
return Decision(
Route.TOOL_QUERY,
"实时事实必须查询权威业务系统",
allowed,
)
if any(word in text for word in ("制度", "接口文档", "字段含义")):
return Decision(
Route.RAG,
"企业私有知识应按租户和角色检索并返回引用",
True,
)
if any(word in text for word in ("忘记密码", "如何登录")):
return Decision(Route.RULE, "固定流程优先使用确定性规则", True)
return Decision(Route.MODEL, "通用理解或生成任务可使用模型", True)
if __name__ == "__main__":
user = Principal("u-1001", "hospital-a", frozenset({"employee", "support"}))
cases = {
"忘记密码怎么办": Route.RULE,
"订单状态是什么": Route.TOOL_QUERY,
"patient_id字段含义": Route.RAG,
"帮我删除客户数据": Route.APPROVAL,
"把这段文字总结一下": Route.MODEL,
}
for question, expected in cases.items():
decision = decide(question, user)
assert decision.route is expected
print(question, "=>", decision)
assert decide("删除客户数据", user).can_execute_directly is False真实项目在 TOOL_QUERY 分支仍必须由后端根据 Principal 校验资源归属,不能让模型生成 tenantId;RAG 分支必须在召回前应用 ACL;APPROVAL 分支要生成不可变计划并由业务审批系统提交。
十八、AI项目从需求到上线的全过程
flowchart TD
A["定义业务问题和不用AI的基线"] --> B["定义成功指标与风险红线"]
B --> C["确认数据来源、授权和质量"]
C --> D["选择规则、ML、RAG、Tool或模型方案"]
D --> E["制作训练或评估数据集"]
E --> F["实现最小可评估链路"]
F --> G["离线质量、安全、延迟和成本评估"]
G --> H{"是否达到门禁"}
H -- "否" --> I["定位数据、检索、Prompt、模型或流程问题"]
I --> D
H -- "是" --> J["影子、内部或小流量灰度"]
J --> K["监控业务指标、风险和成本"]
K --> L{"线上是否稳定"}
L -- "否" --> M["回滚并沉淀失败样本"]
L -- "是" --> N["逐步扩大与持续评估"]18.1 先建立非AI基线
如果 FAQ 搜索已经能以更低成本解决 95% 的固定问题,大模型方案必须证明额外收益。没有基线,就无法回答模型是否真正节省工时、提高召回或降低转人工率。
18.2 指标必须在开发前定义
示例:
字段抽取准确率 >= 98%
高风险字段必须人工确认
越权样本通过率 = 0%
P95总延迟 <= 5秒
单成功任务成本 <= 0.08元
低证据问题正确拒答率 >= 95%“感觉回答不错”不是上线标准。
18.3 数据授权先于训练和评估
需要确认数据是否允许用于训练、第三方模型调用、日志和人工标注;敏感数据是否已经最小化和脱敏;删除请求怎样传播到数据集、索引和缓存。
18.4 灰度不是只分流量
应记录应用、Prompt、模型、知识库、Embedding、Reranker 和 Tool Schema 版本,按租户、场景、风险和用户组观察。高风险场景即使平均分提升,也不能用普通样本收益抵消安全退化。
十九、AI为什么会“离线很好,线上很差”
常见原因:
- 训练/测试数据泄漏,离线分数虚高。
- 测试样本过于简单,没有覆盖真实长尾。
- 线上输入格式、用户群或时间分布变化。
- 数据预处理线上和离线不一致。
- RAG 在线索引版本、ACL 或 Query Rewrite 与评估不同。
- 模型 Provider 或版本变更。
- 线上上下文被截断、缓存串权限或工具超时。
- 人工评价只看表达流畅,没有检查事实和业务结果。
这说明模型指标必须和完整应用链路指标分开。Embedding 召回正确不代表正确片段进入 Prompt;Prompt 中有证据也不代表最终答案被证据支持;模型提出正确工具也不代表后端执行成功。
二十、生产故障排查Runbook
20.1 模型效果突然下降
- 用 requestId 确认场景、应用版本、Prompt 版本、模型路由和知识库版本。
- 判断是全部场景下降,还是某租户、某标签、某语言或某时间段下降。
- 固定线上原始输入,在上一稳定版本和当前版本重放对比。
- 检查模型、Prompt、RAG、工具、预处理和输出解析哪个阶段首先产生差异。
- 检查 Provider 是否静默升级模型,路由是否切到降级模型。
- 指标触及门禁时先回滚,再做原因分析。
- 把线上失败样本脱敏后加入固定回归集。
20.2 传统ML预测突然偏移
- 比较线上特征缺失率、均值、分位数、类别分布和训练基线。
- 检查特征计算代码、时间窗口、时区、单位和默认值是否改变。
- 检查标签定义是否因业务流程变化而漂移。
- 看各分组 Precision、Recall,而不是只看总 Accuracy。
- 判断是 Data Drift、Concept Drift、上游数据故障还是模型服务故障。
- 必要时切回规则/旧模型并重新训练评估。
20.3 AI请求变慢
拆分查看:
排队等待
+ 鉴权和网关
+ RAG检索与Rerank
+ Tool调用
+ Prompt编译
+ 模型TTFT
+ Decode每Token耗时
+ 输出校验只看总耗时无法判断应优化向量库、下游接口、上下文长度、模型并发还是输出长度。
20.4 成本突然升高
检查输入 Token、输出 Token、模型路由、重试次数、Agent 循环、RAG TopK、历史长度、工具结果大小、缓存命中率和失败请求占比。成本要看“每个成功业务任务”,因为失败后重试三次再成功会被单请求均价掩盖。
20.5 出现越权回答
这是安全事故:
- 停止受影响场景或回滚。
- 确认越权数据在检索、缓存、Prompt、Tool 还是渲染阶段进入。
- 检查租户和角色是否来自认证上下文。
- 检查 RAG ACL 是否在打分前生效。
- 检查缓存 Key 是否包含租户、ACL 和版本。
- 评估日志、评估集和第三方 Provider 是否已接收越权内容。
- 清理污染缓存,补确定性权限测试和安全回归样本。
二十一、常见误区及后果
| 误区 | 为什么错误 | 可能后果 |
|---|---|---|
| AI就是大模型 | 忽略规则、传统ML、搜索和规划 | 用昂贵模型替代简单可靠方案 |
| 训练Loss低就能上线 | Loss不是完整业务指标 | 线上高风险样本失败 |
| Accuracy高就是好模型 | 类别不平衡会掩盖少数类失败 | 欺诈、故障全部漏报 |
| 测试集可以反复调参 | 测试集被间接过拟合 | 泛化分数虚高 |
| 模型参数就是知识库 | 参数不能实时、精确、按权限查询 | 过期事实和幻觉 |
| RAG等于把全部文档放进Prompt | 成本、噪声和权限风险 | 答非所问或数据泄露 |
| 模型可以自己鉴权 | 自然语言不是权限系统 | 越权查询和写操作 |
| temperature设为0就绝对确定 | 服务和版本仍可能变化 | 复现和审计失败 |
| 流式输出让总计算变快 | 主要改善首Token体验 | 错误容量规划 |
| 只监控模型服务 | 故障可能在检索、Tool、缓存和解析 | 无法定位根因 |
二十二、面试标准回答
22.1 AI、机器学习、深度学习和大模型是什么关系
AI 是让计算机完成感知、预测、生成和规划等任务的总称;机器学习通过数据学习参数;深度学习使用多层神经网络学习复杂表示;大模型是在大规模数据和计算上训练、可适配多任务的一类深度学习模型。大模型不是 AI 的全部,商业系统通常组合规则、搜索、传统 ML、RAG、工具和模型。
22.2 机器学习模型怎样学到规律
先定义样本、特征和标签,模型用当前参数前向计算预测,Loss 衡量预测与标签差距,反向传播计算各参数梯度,优化器沿降低 Loss 的方向更新参数;多个 Batch 和 Epoch 后固定参数,在独立验证和测试数据上评估泛化,再用于新数据推理。
22.3 训练和推理有什么区别
训练有目标标签,要计算 Loss、梯度并更新参数,耗费前向、反向和优化器资源;推理固定模型参数,只对新输入计算预测。自回归大模型训练时已知目标 Token,可并行计算多个位置的 Loss;推理时下一个 Token 未知,必须生成后才能继续,因此 Decode 具有逐 Token 依赖。
22.4 为什么大模型不是万能知识库
模型参数编码的是训练数据中的统计规律,不是可实时更新、按权限查询和精确审计的数据库。最新企业文档应通过带 ACL 的 RAG 提供,订单、库存等实时事实应通过后端工具查询,最终还要做引用、Schema、业务和权限校验。
22.5 AI应用为什么不能只调用模型API
生产系统还需要认证、限流、场景路由、Prompt 编排、RAG 权限过滤、Tool 鉴权和幂等、结构化输出校验、评估、成本监控、审计、灰度、回滚和人工兜底。模型只是概率式理解和生成组件,不能替代权威数据、权限系统和业务事务。
面试页只保留简洁答案,更多问题见 AI应用工程化面试题。
二十三、学习路线与关联知识点
- 大模型Token、训练与推理原理:深入理解 Token、Loss、Prefill、Decode 和 KV Cache。
- Transformer原理:深入理解 Self-Attention、Q/K/V 和 Causal Mask。
- Prompt任务编译、安全与发布:把业务任务编译成可评估协议。
- Embedding与向量库:理解语义向量和近似检索。
- RAG完整管道:学习离线建库、在线召回、权限和索引发布。
- Tool Calling:理解模型建议动作与后端安全执行的边界。
- Agent:理解状态、行动、观察、终止、审批和恢复。
- AI应用架构:学习模型网关、任务状态机、配额和观测。
- AI评估:建立质量、安全、延迟和成本门禁。
- AI安全:治理注入、越权、敏感数据和高风险工具。
二十四、学习验收清单
- [ ] 能用自己的话解释规则编程和机器学习的输入输出关系。
- [ ] 能区分样本、特征、标签、参数和超参数。
- [ ] 能手画前向、Loss、梯度、优化器更新的训练循环。
- [ ] 能运行并解释本页线性模型 Demo 的每一行核心逻辑。
- [ ] 能说明训练集、验证集、测试集为何不能混用。
- [ ] 能举出时间泄漏、实体泄漏和目标泄漏的例子。
- [ ] 能根据训练和验证指标区分欠拟合与过拟合。
- [ ] 能解释神经网络为什么需要非线性激活和反向传播。
- [ ] 能说明大模型预训练、SFT、对齐和推理分别做什么。
- [ ] 能区分参数知识、RAG知识和Tool实时事实。
- [ ] 能为业务问题选择规则、传统ML、搜索、RAG、Tool或大模型。
- [ ] 能画出生产AI请求从认证到审计的完整链路。
- [ ] 能说明为什么权限、幂等和高风险审批不能交给模型。
- [ ] 能根据requestId定位模型退化、延迟、成本和越权问题。
只有这些问题都能解释并通过 Demo 和场景验证,才算真正建立了 AI 基础,而不是只记住几个模型名。
