AI、机器学习与大模型到底是什么：小白的第一张概念地图

先用一句人话定义 AI

先不要看代码，也不要急着记住“大模型、Token、RAG”这些词。AI 可以先理解成一件事：让机器根据输入完成一个原本需要人判断、识别、生成或行动的任务。

一个 AI 任务至少要说清三件事：输入是什么？例如一封客服邮件。机器要输出什么？例如问题类别、回复草稿或下一步动作。怎样判断对不对？例如类别准确、金额不被改写、危险动作交给人工。

“智能”不是一句宣传语，而是这条输入—处理—输出链路在一组样本和边界条件下表现得足够可靠。先记住下面这组最小区别：

这些词不是同一层级：AI 是目标范围，机器学习和深度学习是方法，大语言模型是某类模型，RAG 和工具调用是把模型接进现实系统的方式。把它们并列成“十种模型”会从第一步就混淆。

用一个小例子验证这些定义

假设客服收到下面这封邮件：“我昨天晚上付了 299 元，银行卡已经扣款，订单页面还显示‘等待支付’。今天急着使用课程，请帮我查一下。订单号 KB202607280018。”

基本原理：目标 → 输入 → 输出 → 验收

AI 不是“看起来聪明”就算完成。先说清目标，再固定输入和输出，最后写出验收方式，才能判断它是在解决问题还是只是在生成一段像答案的话。高风险动作还要加权限、人工确认和失败出口；模型可以参与判断，但不能凭语言替代订单、金额或身份事实。

现在把同一封邮件拆成五个明确任务，逐个看“输入、输出、依据和风险”：

所以“AI 客服”不是一种技术，而是一条组合链：模型负责语言判断或草稿，检索负责提供政策证据，工具负责读取真实状态，规则和人工负责权限与风险。读懂这条链后，再看后面的术语才有落脚点。

再把最容易混淆的词放到一张图上

人工智能 AI
└─ 机器学习 Machine Learning
 └─ 深度学习 Deep Learning
 └─ 基础模型 Foundation Model
 └─ 生成式 AI Generative AI
 └─ 大语言模型 LLM
 └─ 聊天、搜索、写作、Agent 等应用

这是一张学习地图。现实技术有交叉，例如生成图像的扩散模型属于生成式 AI，也可能被称为基础模型，却属于大语言模型之外的路线。

读图：这不是一条“越往下越高级”的直线

读图时只看三件事：

1. 左侧是目标和方法：AI 说“机器要完成什么”，机器学习和深度学习说“从数据中怎样学”。规则系统仍然属于 AI，只是没有通过训练调整参数。
2. 中间是模型与输出形态：基础模型先学通用表示；生成式 AI 关注“产生内容”，LLM 只是处理语言的一类模型，不等于全部生成式 AI。
3. 右侧是应用接法：聊天、搜索、RAG、工具调用和 Agent 是把模型放进工作流的方式。RAG 提供资料，工具读取真实状态，Agent 负责多步编排，它们不是模型等级。

例如，上面的客服邮件可以同时使用“机器学习分类 + LLM 草稿 + RAG 查政策 + 工具查订单 + 人工审批”。这不是把一条链上的词全选一遍，而是为同一个任务组合不同组件。

人工智能：让机器完成需要判断的任务

AI 是最大范围的概念。它包含：

规则系统
搜索与规划
机器学习
计算机视觉
语音识别
自然语言处理
机器人

下面这段规则也能完成一种智能判断：

def route_ticket(text):
 if "退款" in text or "退钱" in text:
 return "refund"
 if "密码" in text or "登录" in text:
 return "login"
 return "other"

它的判断逻辑由人直接写出。规则少、边界稳定、需要强解释性时，这种方法很有价值。

机器学习：从样本里学出判断规则

准备历史工单：

机器学习算法寻找文本特征与标签之间的统计关系。训练完成后，模型可以对新邮件预测类别。

带标签历史数据
→ 算法调整模型参数
→ 得到分类模型
→ 输入新邮件
→ 输出各类别概率

模型学到的是数据中的模式。训练数据缺少“重复扣款”案例时，它在这个场景上的表现通常缺乏保障。

深度学习：用多层神经网络学习表示

传统机器学习常由人选择特征，例如：

是否包含“退款”
文本长度
订单号是否出现
感叹号数量

深度学习用多层神经网络从大量数据中逐步学习表示。文字、图片和声音会先变成数字，再经过多层计算。

一个极简神经元：

x 是输入数字，w 是权重，b 是偏置，f 是激活函数。训练会调整权重与偏置，让预测更接近期望答案。

现代模型包含大量这样的计算单元和连接。层数、连接方式、注意力机制与训练目标共同构成模型架构。

基础模型：先在大量数据上学习通用能力

基础模型先进行大规模预训练，再成为多个下游任务的起点：

大规模通用数据
→ 预训练
→ 基础模型
├─ 提示词直接使用
├─ RAG 接入私有知识
├─ 工具调用连接业务系统
└─ 微调适配特定任务

文字基础模型可以完成摘要、分类、提取、问答和代码生成。视觉基础模型可以理解或生成图像。多模态模型同时处理文本、图片、音频或视频中的多种输入。

生成式 AI：产生新的内容

分类模型从几个类别里选择一个：

{"category": "payment_issue"}

生成模型可以产生一段新文本：

已经记录您的订单号。系统需要先核对支付渠道回执与订单状态
核验完成后会给出处理结果。

生成内容来自模型根据上下文进行的概率预测。它可能流畅、相关，也可能出现事实错误、遗漏条件或不合规承诺，因此生产系统需要证据、约束和验证。

大语言模型：按上下文预测语言序列

大语言模型处理的基本单位叫 Token。Token 不是字符的固定别名：同一段文字在不同 tokenizer、词表和模型版本中可能得到不同切分；中文一个汉字可能对应一个或多个 Token，英文单词也可能被拆分。真正计费或检查上下文时，应使用目标模型随附的 tokenizer，而不是用字符数硬换算。

用户文本
→ Tokenizer 切成 Token
→ Token 变成向量
→ Transformer 多层计算
→ 得到下一个 Token 的概率
→ 选择一个 Token
→ 把新 Token 放回上下文继续生成

它逐步预测序列：

“订单状态需要”
→ “订单状态需要先”
→ “订单状态需要先核”
→ “订单状态需要先核对”

模型每一步都根据当前上下文计算下一个 Token 的概率分布。这个机制解释了三个现象：

1. 同一问题可能生成不同表述
2. 前文指令、示例和资料会影响后续输出
3. 流畅语言本身无法证明事实真实。

模型、算法、参数与权重分别是什么

把一个简单线性模型写成：

• 算法：怎样从数据中调整 w 和 b
• 模型：训练后可以接收输入并产生预测的计算结构
• 参数：训练过程中学到的 w、b 等数值
• 权重：参数中的主要一类，控制输入信号影响大小
• 超参数：训练前由人或搜索过程设置，例如学习率、批量大小、层数。

假设根据学习时长预测考试成绩：

训练前：score = 0.2 × hours + 10
训练后：score = 6.8 × hours + 34

训练数据推动参数发生变化。模型文件保存结构、参数以及运行所需配置。

“70B 模型”通常表示约 700 亿参数量级，是命名约定而不是质量保证。参数更多可能带来更强能力，也会增加显存、计算、延迟和成本需求。模型质量还受数据、架构、训练方法、推理配置和任务匹配影响。

训练和推理是两个阶段

训练：根据误差调整参数

准备数据
→ 模型做预测
→ 用损失函数计算预测与目标的差距
→ 反向传播计算参数该往哪个方向调整
→ 优化器更新参数
→ 重复许多批次

一个二分类样本：

输入：“扣款成功，订单未到账”
目标：支付异常
模型预测：
 支付异常 0.42
 退款 0.31
 登录 0.27

损失函数把预测与目标之间的差距变成一个数。优化过程持续降低训练损失，同时要在独立验证集上观察模型能否泛化到未见样本。

数据通常分成：

同一用户、同一文档的近似副本跨集合出现，会造成数据泄漏，让评测分数虚高。

推理：固定参数，计算一次输出

用户调用模型时通常发生推理：

输入
→ 预处理与 Tokenize
→ 固定模型参数执行前向计算
→ 解码输出
→ 后处理与验证

推理可以在线执行，也可以离线批量执行：

在线系统重点关注首 Token 延迟、总延迟、吞吐、错误率和成本。批量任务重点关注总处理量、失败重跑、版本记录和结果校验。

预训练、指令微调与人类偏好做了什么

基础语言模型常见的能力形成路径：

预训练
→ 在大量文本上预测缺失或后续 Token

指令微调
→ 学习“用户给任务，助手按要求回答”的样本

偏好优化
→ 学习人类或规则更偏好的回答风格与行为

安全与系统约束
→ 增加拒绝、边界和风险控制

预训练建立语言与世界模式，指令微调增强任务遵循，偏好优化塑造回答选择。产品接入模型后仍要承担输入、权限、事实、工具和结果验证。

Prompt、上下文与上下文窗口

Prompt 是一次请求中给模型的指令与材料。完整上下文可能包含：

系统规则
开发者规则
用户问题
对话历史
检索资料
工具结果
输出格式

上下文窗口是模型一次计算能够容纳的 Token 总量。它通常同时容纳输入和输出预算。

系统指令 900 Token
对话历史 4,200 Token
检索资料 8,000 Token
用户问题 180 Token
工具结果 1,100 Token
预留输出 2,500 Token
合计 16,880 Token

上下文过长会增加延迟和费用，也可能让关键规则被大量材料淹没。工程上需要选择信息、排序证据、压缩历史并预留输出空间。

提示词不会永久修改模型参数。它在本次上下文内影响生成。微调会通过训练更新一部分或全部参数，影响后续所有请求。

Temperature、Top-p 与“随机”

模型得到下一个 Token 的分数后，需要把它变成概率并选择输出。

温度调节概率分布：

较低温度 → 高概率候选更集中，输出通常更稳定
较高温度 → 更多候选获得机会，输出通常更发散

Top-p 从累计概率达到阈值的一小组候选中采样。两者都在解码阶段生效。

事实抽取、分类和结构化数据通常追求稳定；创意标题和故事可以允许更高多样性。固定温度仍然无法构成业务正确性保证，生产系统需要 Schema、规则校验与评测。

API 是程序调用模型的接口

聊天界面适合人直接使用。API 让程序发送请求并接收结果：

{
 "model": "example-model"
 "messages": [
 {
 "role": "user"
 "content": "从邮件中提取订单号和金额"
 }
 ]
}

服务返回：

{
 "output": {
 "order_id": "KB202607280018"
 "amount_yuan": 299
 }
 "usage": {
 "input_tokens": 86
 "output_tokens": 24
 }
}

不同服务商的字段会变化，通用调用链相似：

应用组织请求
→ HTTPS 发送到模型服务
→ 服务鉴权、排队和推理
→ 返回内容与用量
→ 应用解析、校验和保存

API key 属于服务凭证，应保存在服务端密钥环境中。浏览器页面和公开仓库会暴露其中的内容。

Embedding 把内容变成可比较向量

生成模型输出文字，Embedding 模型输出一串数字：

“课程退款规则” → [0.031, -0.284, 0.117, ...]

语义相近文本的向量通常距离更近。它可以用于：

语义搜索
相似问题推荐
聚类
去重
检索增强生成

Embedding 本身不直接给出最终业务答案。检索系统用它寻找候选资料，再由规则、排序或生成模型处理候选结果。

RAG、Agent 与微调解决三类不同问题

假设客服模型需要回答退款规则、查询订单并保持公司语气。

RAG：运行时把资料放进上下文

用户问题
→ 搜索退款制度
→ 取回相关条款
→ 条款与问题一起交给模型
→ 生成带引用回答

RAG 适合经常更新、需要引用、属于组织私有知识的事实。它依赖文档解析、切块、索引、权限、召回、重排和引用校验。

Agent：模型根据状态选择并调用工具

读取用户问题
→ 判断需要查订单
→ 调用 order.get
→ 读取工具结果
→ 判断是否满足自动处理条件
→ 回复或转人工

Agent 适合多步骤任务和外部动作。工具的参数、权限、幂等、审批和失败恢复决定它是否能进入生产。

微调：用训练样本改变模型行为

任务样本
→ 训练
→ 得到适配模型
→ 所有请求共享新参数行为

微调适合稳定、重复、可以准备高质量样本的行为模式，例如领域格式、分类边界、术语风格或小模型专项能力。经常变化的政策事实更适合在运行时检索。

选择顺序可以从问题来源出发：

这些能力可以组合。一个客服 Agent 可以先 RAG 查政策，再调用订单工具，并使用微调模型完成低成本分类。

幻觉的工程含义是“输出缺少可验证依据”

模型可能生成：

您的退款将在 24 小时内到账。

公司政策可能写的是 3—7 个工作日。模型生成了语言上合理、业务上错误的承诺。

常见原因：

训练数据中的模式与当前事实不同
上下文没有提供关键资料
检索召回了相似主题却漏掉限制条件
用户问题存在歧义
模型被要求回答超出证据的问题
解码产生了错误细节
工具结果被错误解释

工程措施：

1. 为关键事实提供权威数据源
2. 输出引用定位到文档版本与片段
3. 结构化字段经过类型和业务规则校验
4. 高风险动作交给确定性服务与审批
5. 缺少证据时返回未知或转人工
6. 使用真实失败样本持续评测。

“减少幻觉”需要变成可计算指标，例如：

事实字段准确率
引用支持率
关键条件遗漏率
不可回答识别率
越权动作率
人工接管率

模型输出为什么需要评测

同一句“效果挺好”无法支持上线。准备 100 条代表性工单：

对每条样本定义期望：

{
 "case_id": "pay-017"
 "expected_category": "payment_issue"
 "expected_order_id": "KB202607280018"
 "must_not_claim": ["已经退款", "24小时到账"]
 "requires_tool": "order.get"
 "requires_human": false
}

下面的数值只是一个项目的示例门槛（illustrative example），不是行业通用标准；正式项目要用自己的风险、基线、样本量和预算校准。模型版本、提示词、检索索引和工具契约变化后重新运行。发布门槛可以写成：

关键字段准确率 >= 99%
错误承诺率 = 0
越权工具调用率 = 0
引用支持率 >= 98%
P95 总延迟 <= 4.5 秒
单次平均成本 <= 0.08 元

指标阈值由业务风险、基线和预算决定。

用一条数据流看完整 AI 应用

用户输入
 ↓
身份与权限
 ↓
输入校验、隐私处理和风险分类
 ↓
上下文组装
├─ 系统规则
├─ 对话历史
├─ RAG 检索资料
└─ 工具可用列表
 ↓
模型推理
 ↓
结构化输出或工具调用
 ↓
Schema 与业务规则校验
 ↓
工具执行 / 人工审批
 ↓
生成最终回复
 ↓
日志、评测、成本与用户反馈

模型只占其中一个节点。账号隔离、数据来源 执行权限、失败恢复和监控同样属于产品质量。

第一个 AI 项目应该怎样选

适合第一次完成的项目拥有四个特征：

输入可以收集
输出可以人工判断
错误不会造成不可逆损失
一周内能积累 30—100 条测试样本

三个起点：

信息提取

输入：一封工单
输出：类别、订单号、金额、时间
验收：逐字段准确率

带引用的资料问答

输入：产品手册与用户问题
输出：答案、引用片段、文档版本
验收：召回率、引用支持率、不可回答识别

内容辅助

输入：主题、受众、事实材料
输出：标题、提纲、初稿
验收：事实错误、修改用时、采用率

第一个版本把结果作为草稿，由人确认。随着评测证据积累，再逐步扩大自动化范围。

一张可以带走的 AI 项目判断卡

把下面内容复制到聊天工具，替换方括号：

你是一名 AI 产品方案审查员。请基于我提供的信息完成任务拆解。

## 业务任务
[用户现在怎样完成任务，耗时多少，主要错误是什么]

## 目标用户
[谁使用，频率，使用环境]

## 输入
[文本、图片、表格、数据库字段；给出 3 个真实脱敏样例]

## 期望输出
[字段、文档、决策或动作；写出一个完整样例]

## 数据与事实来源
[哪些是权威来源 更新频率，访问权限]

## 风险
[错误结果会影响什么；哪些动作需要人工批准]

## 约束
[延迟、成本、语言、部署、隐私、合规]

请输出：
1. 把任务拆成“确定性代码、模型判断、检索、工具调用、人工审批”五类步骤。
2. 解释每一步为什么属于该类别。
3. 给出最小可行版本的数据流图。
4. 列出 20 条测试样本应覆盖的场景，其中包含正常、边界、失败和对抗样本。
5. 为质量、延迟、成本和风险分别定义可计算指标。
6. 判断当前应优先使用提示词、RAG、工具调用、Agent 或微调，并写出证据。
7. 列出项目启动前仍然缺失的信息。

所有结论必须引用我提供的事实。缺少信息时使用“待确认”标记。

项目决策记录保存为 ai-project-card.yaml：

project: support-ticket-assistant
owner: customer-service
users:
 - support_agent
task:
 input: customer_email
 output:
 - category
 - order_id
 - amount_yuan
 - reply_draft
authority:
 policy_source: support-policy-v12
 order_source: order-api-v3
model_role:
 - classify_ticket
 - extract_fields
 - draft_reply
deterministic_rules:
 - amount_yuan_must_be_non_negative
 - refund_commitment_requires_order_api
tools:
 - name: order.get
 side_effect: false
 timeout_ms: 1500
human_approval:
 - refund_over_500_yuan
 - identity_mismatch
evaluation:
 dataset: eval/support-v1.jsonl
 gates:
 field_accuracy: 0.99
 unsupported_claim_rate: 0
 unauthorized_action_rate: 0
 p95_latency_ms: 4500
observability:
 record:
 - model_version
 - prompt_version
 - retrieved_document_ids
 - tool_call_ids
 - token_usage

第一次练习：选择一个真实小任务，填写判断卡，准备 20 条脱敏输入与期望输出，先让人工逐条评分，再决定是否增加 RAG、工具或微调。

本地复现：先验证确定性边界，再接真实模型

文章中的规则路由、字段提取、上下文预算和“RAG/工具/微调/确定性代码”的选择卡可以先用零依赖夹具复现：

node --test tests/fixtures/ai-beginner-concept-map/ai_beginner_concept_map_lab.mjs
node --test tests/ai-beginner-concept-map-reproduction.test.mjs

夹具只证明教学模型的边界和不变量：订单号/金额能否被安全提取、上下文预算是否留出输出空间、不同风险任务是否选择不同技术。它不声称复现任何供应商的真实 tokenizer、模型输出或线上延迟；接入具体模型时还要锁定 tokenizer、模型版本、评测集和成本口径。

一手资料与继续学习

• Google Machine Learning Crash Course
• Google：Introduction to Large Language Models
• Google：Fine-tuning, distillation, and prompt engineering
• PyTorch：Neural Networks
• Hugging Face Transformers Pipelines
• Hugging Face：Summary of the tokenizers
• Attention Is All You Need
• NIST AI Risk Management Framework
• NIST Generative AI Profile