一、全局：六个概念分属三个层次
1. 模型与部署层
– LLM：负责理解上下文并生成内容，是系统的基础模型。
– 微调：改变模型参数或增加可训练适配参数，使模型形成更稳定的特定行为。
– 量化：降低模型权重或激活值的数值精度，减少显存、内存和计算成本。
2. 知识与连接层
– RAG：先从外部知识中检索相关内容，再把内容交给模型生成答案。
– MCP：用统一协议把 AI 应用和外部数据、工具、工作流连接起来。
3. 任务执行层
– Agent：围绕目标，在模型、工具、状态和循环控制之间持续决策并推进任务。
如果把一个 AI 系统比作一名技术人员：
LLM = 大脑和语言能力
RAG = 临时查阅的资料库
MCP = 连接各种系统的标准接口
Agent = 接到目标后持续推进工作的执行机制
Fine-tuning = 针对特定工作进行再训练
Quantization = 在尽量保留能力的前提下降低运行成本
上面例子只是通俗来讲，真正的关系要看它们在系统中的数据流。
┌─ RAG：检索外部知识并放入上下文
用户目标 → Agent 循环 → LLM
│ └─ MCP：发现并调用外部数据和工具
└──── 状态、观察结果、停止条件、人审 ────┘
模型上线之前：
训练数据 → Fine-tuning → 形成适配后的模型
模型权重 → Quantization → 形成成本更低的部署版本
这里最关键的一点是：
RAG、MCP 和 Agent 通常发生在应用运行阶段；微调和量化更多发生在模型准备与部署阶段。它们不是六选一，而是在解决不同层面的问题。
二、LLM：会根据上下文继续生成，但不天然等于事实数据库
LLM 是 Large Language Model，也就是大语言模型。
LLM 是从大规模数据中学习语言模式，并根据当前上下文预测后续 token 概率的生成模型。
1. token
模型并不是直接看到完整的中文词语或英文句子，而是先通过 tokenizer 把输入切成一串 token。token 可能是一个字、一个词的一部分、标点或特殊符号。
例如一句话进入模型后，大致会经历：
文本
↓ Tokenization
Token ID 序列
↓ Embedding
向量表示
↓ 多层 Transformer 计算
每个候选下一 token 的分数 logits
↓ 概率与采样策略
选择下一个 token
↓
把新 token 加回上下文，继续生成
现代 LLM 大多建立在 Transformer 及其变体之上。Transformer 的关键价值，是通过注意力机制让模型在处理一个位置时，能够结合上下文中其他位置的信息。
2. 为什么 LLM 看起来像“懂了”
预训练过程中，模型不断根据上下文预测被遮住或后续的内容。要把这个任务做好，它会在参数中逐渐形成语言结构、概念关系、常见事实、推理模式和代码模式的统计表示。
因此，我们看到的是“它能回答问题”，训练目标看到的却是“在当前上下文中，什么 token 更可能出现”。
这并不等于模型只是随机接词。大规模参数和训练数据让预测过程可以表达复杂的语义关系，但它也解释了一个重要局限：
LLM 的基础目标是生成符合上下文的内容，不是查询一张永远正确、永远最新的事实表。
3. 幻觉为什么会发生
当模型缺少可靠信息时，它仍可能生成形式完整、语言流畅的答案。因为“像一个合理答案”与“经过外部事实验证”不是同一件事。
所以不能简单地把 LLM 当数据库，也不能因为回答流畅就认为结论已被证明。需要最新事实、私有数据或精确引用时，通常要引入检索、工具调用或外部校验。
4. 什么时候直接使用 LLM
适合：
– 文本理解、分类、摘要、改写和生成；
– 代码解释与常见代码生成；
– 基于已经放入上下文的信息进行推理；
– 允许一定开放性的创作与讨论。
不适合单独承担：
– 必须实时更新的事实查询；
– 要求逐条可追溯依据的专业回答；
– 涉及真实系统副作用的操作；
– 不能容忍错误、又没有外部校验的关键决策。
5. 成本和风险
– 上下文越长，通常输入计算和调用成本越高；
– 输出越长，生成耗时和 token 成本越高；
– 采样具有不确定性，同一个问题可能得到不同表达甚至不同结论；
– 模型参数中的知识存在时间边界，也不能自然访问企业私有数据；
– 提示词只能影响本次上下文，不能自动改变底层模型参数。
三、RAG：不是让模型重新学习，而是让它先查资料再回答
RAG 是 Retrieval-Augmented Generation，中文通常叫“检索增强生成”。
RAG 在生成答案之前，从外部知识源中检索相关内容，再把检索结果放入模型上下文中生成回答。
最直观的理解是“开卷考试”。模型参数没有因为这次查询发生改变，只是答题前临时拿到了相关资料。
1. RAG 有两条流程
第一条是离线的知识准备流程：
文档/网页/数据库记录
↓ 解析与清洗
切分成 chunk
↓
计算 embedding 或建立其他检索索引
↓
写入向量库、全文索引或其他知识存储
↓
保存来源、时间、权限等 metadata
第二条是在线问答流程：
用户问题
↓ 查询改写或意图识别
检索候选内容
↓ 权限过滤、去重、重排
选出最相关上下文
↓
问题 + 检索内容 + 回答规则 → LLM
↓
答案与引用
很多入门文章把 RAG 等同于“向量数据库”，这是不完整的。向量检索只是常见方式，RAG 也可以组合关键词检索、SQL 查询、知识图谱、元数据过滤和重排模型。
RAG 的原始工作强调把模型参数中的“参数化记忆”和外部检索到的“非参数化记忆”结合起来。
2. RAG 解决什么问题
– 新鲜度：知识更新时可以更新索引，不必重新训练整个模型；
– 私有知识：把企业制度、项目文档、数据口径等按权限提供给模型；
– 可追溯性：保留文档来源和段落位置，支持引用与复核；
– 可维护性：发现文档错误后，可以修正文档和索引，而不是修改模型权重。
3. RAG 为什么仍然可能答错
RAG 至少包含两个独立质量问题：
1. 检索是否找对了：应该出现的资料有没有进入候选结果；
2. 生成是否忠于资料：模型有没有正确使用检索内容。
如果第一步没有检索到正确内容，后面的模型再强也可能无依据可用；如果检索正确但提示设计、上下文组织或模型遵循性不足，也可能出现答非所问或引用不一致。
因此，评估 RAG 不能只看最终答案，还要分别看检索召回、排序质量、上下文相关性、答案忠实度和引用正确性。
4. 什么时候应该使用 RAG
适合：
– 知识频繁变化；
– 需要查询企业私有文档；
– 回答需要引用来源；
– 数据量很大，无法全部塞进上下文；
– 不希望通过训练把每次知识更新写入模型参数。
不适合或没必要：
– 知识很少，直接放进提示词已经足够；
– 任务不是知识问题，而是要求模型形成稳定输出格式或行为；
– 根本没有可靠知识源；
– 精确结果应直接由数据库查询或确定性程序计算，而不是从文档相似度中猜。
5. 成本和风险
– 文档解析、切分和索引质量会直接影响结果；
– 索引更新不及时会产生“看起来接了知识库，实际仍然过期”的问题；
– 权限过滤错误可能造成跨用户或跨部门数据泄露；
– 被检索文档可能包含恶意指令，形成间接 Prompt Injection；
– 检索、重排和额外上下文会增加延迟与调用成本。
RAG 适合解决最新、私有、可引用的知识问题，它不修改模型权重，而是通过检索质量和上下文组织影响本次生成。
四、MCP：它不是工具本身，而是 AI 连接工具的统一协议
MCP 是 Model Context Protocol，即模型上下文协议。
官方定义中，MCP 是连接 AI 应用与外部系统的开放标准。AI 应用可以通过它连接数据源、工具和工作流。当前官方文档也把它类比成 AI 应用的“USB-C 接口”。
MCP 规定 AI 应用如何发现和调用外部能力，以及双方如何交换结构化请求、结果和上下文。
1. 为什么需要 MCP
没有统一协议时，每个 AI 客户端连接每个外部系统，都可能单独开发一套适配：
“`
客户端 A → 数据库适配器 A
客户端 A → 文件系统适配器 A
客户端 B → 数据库适配器 B
客户端 B → 文件系统适配器 B
“`
随着客户端和工具增加，连接关系会越来越多。
MCP 把连接方式标准化后，可以变成：
“`
AI Host / Client ← MCP → Server A：数据库能力
← MCP → Server B：文件能力
← MCP → Server C：业务系统能力
“`
服务端按协议声明自己能提供什么，客户端按协议发现并调用。这样做降低的是集成重复劳动，不是模型推理难度。
2. Host、Client、Server 怎么理解
– Host：承载 AI 应用并负责用户授权、安全策略和连接管理；
– Client：由 Host 管理，负责和某个 MCP Server 通信；
– Server：对外暴露某一类数据或能力。
MCP Server 常见可以暴露三类原语：
– Tools：可执行动作，例如查询、计算、写入或调用业务接口；
– Resources：可读取的上下文数据，例如文件内容、配置或记录；
– Prompts：可复用的提示或工作流模板。
客户端和服务端还需要通过能力声明与发现，明确双方实际支持哪些功能。
3. MCP 不等于 Agent，也不等于 RAG
MCP 解决的是“怎么连接和交换”，不负责决定“下一步该做什么”。决定是否调用工具、调用哪个工具、如何处理结果，通常属于应用或 Agent 的控制逻辑。
RAG 解决的是“怎样为生成找到外部知识”。RAG 的检索器可以通过普通 API 调用，也可以通过 MCP 暴露；MCP Server 也可以提供与 RAG 完全无关的计算、文件或业务操作。
所以三者关系是：
“`
Agent 决定是否行动
MCP 提供统一连接方式
RAG 提供一种外部知识获取方案
“`
4. 什么时候应该使用 MCP
适合：
– 希望同一外部能力被多个 AI 客户端复用；
– 需要运行时发现工具、资源和能力；
– 工具数量较多，需要统一描述、调用和审计；
– 希望减少对某一家 Agent 框架的专用适配。
没必要强行使用：
– 系统只有一个非常简单、稳定的内部 API；
– 普通函数调用已经满足需求；
– 团队没有能力维护额外协议服务；
– 只是为了使用“MCP”这个名词，却没有复用、发现或标准化需求。
5. 成本和风险
– MCP Server 本身仍然是需要部署、授权、监控和维护的软件；
– 工具描述正确，不代表工具执行一定安全；
– 参数必须校验，高风险操作需要确认、最小权限和审计；
– 远程 Server、返回内容和第三方依赖都存在供应链与提示注入风险；
– “协议统一”不等于“权限自动正确”。
MCP 标准化的是模型应用与外部工具、资源和提示之间的连接与调用，不负责替 Agent 做决策，也不会自动解决授权和安全问题。
五、Agent：不是模型名称，而是一套围绕目标持续执行的系统
Agent 这个词目前没有唯一实现，但在工程上可以用一个相对稳定的结构理解：
Agent 是模型在工具、状态和控制规则约束下，为完成目标而进行“判断—行动—观察—再判断”循环的系统。
它不是某一种新模型，也不是在 LLM 前面加一个“你是智能体”的提示词。
1. 一个 Agent 至少需要什么
“`
目标 Goal
↓
模型 Model：理解、规划、选择下一步
↓
工具 Tools：读取、查询、计算、修改或执行
↓
状态 State：保存已经发生什么、当前到哪里
↓
观察 Observation：获取工具真实结果
↓
控制 Loop：继续、重试、换路、停止或请求人审
“`
可以把它简化成：
“`
Agent = Model + Tools + State + Loop + Control
“`
Anthropic 在工程实践中区分了 workflow 和 agent：workflow 的路径主要由预先编写的代码决定，而 agent 会根据中间结果动态决定如何使用工具和继续推进。
2. Agent 与普通聊天有什么区别
普通 LLM 调用通常是：
“`
输入 → 模型 → 输出
“`
Agent 更像：
“`
目标 → 模型判断 → 调工具 → 观察结果
↑ ↓
└──── 修正与继续 ┘
“`
区别不在于回答更长，而在于系统可以根据真实执行结果改变下一步。
3. Agent 什么时候有价值
适合：
– 任务需要多个步骤，且后续步骤依赖前一步结果；
– 任务路径事先无法完全确定；
– 需要跨文件、数据库、浏览器或业务系统协作；
– 需要长任务状态、失败恢复和阶段验证。
不适合：
– 一次模型调用就能解决；
– 任务流程固定，可以用普通程序稳定实现；
– 操作风险很高，却没有权限控制、回滚和人审；
– 无法定义成功标准和停止条件。
工程上应该优先选择最简单、最确定的方案。能用函数解决，就不要为了“Agent 化”增加循环和不确定性；只有任务路径确实依赖反馈时，Agent 才体现价值。
4. Agent 为什么容易失控或烧钱
每一轮循环都可能再次调用模型和工具。若停止条件不清、工具结果含糊或模型不断尝试同一条路，就可能出现：
– token 和调用费用不断增加；
– 重复执行或产生副作用；
– 状态越来越乱；
– 错误假设在多轮中被不断放大；
– 最终没有完成任务，却消耗了大量时间。
因此生产 Agent 必须有预算、超时、最大步数、幂等控制、权限边界、失败策略、人工确认点和完整审计。
Agent 用模型选择动作，用工具影响外部环境，用状态和循环持续推进目标；它适合路径依赖中间结果的复杂任务，不适合替代可以确定编码的简单流程。
六、Fine-tuning：改变的是模型行为，不是临时给它一本资料
Fine-tuning 就是微调。
微调是在预训练模型基础上，使用特定数据继续训练，使模型参数或附加适配参数更符合目标任务。
1. 微调与提示词的区别
提示词只影响当前请求的上下文：
“`
同一个模型 + 不同 Prompt → 本次输出行为不同
“`
微调会通过训练产生新的参数状态或适配器：
“`
基础模型 + 训练数据 + 优化过程 → 适配后的模型
“`
因此，提示词像“这次告诉员工怎么做”，微调更像“长期训练员工形成稳定习惯”。
2. 全参数微调与 PEFT
全参数微调会更新模型中大量甚至全部参数。它的适配能力强，但显存、计算、存储和训练风险都很高。
PEFT是 Parameter-Efficient Fine-Tuning，只训练少量新增或选定参数。常见的 LoRA 会冻结基础模型权重，用两个较小的低秩矩阵表示权重更新：
“`
W’ = W + ΔW
ΔW = B × A
“`
原来的大矩阵 `W` 不直接训练，只训练小矩阵 `A` 和 `B`。这样可以显著减少需要训练和保存的参数。
QLoRA则进一步把冻结的基础模型以低比特形式加载，再训练 LoRA 适配器，以降低微调时的显存需求。
3. 微调适合解决什么
– 让模型稳定遵循某种输出格式；
– 适应固定领域的语言、术语和表达方式；
– 提高某类稳定任务的行为一致性；
– 学习大量示例中反复出现的模式；
– 在评测集证明提示词和 RAG 仍不足时进一步适配。
4. 微调不适合解决什么
– 每天变化的新闻、价格、制度或业务数据；
– 需要精确引用来源的知识问答；
– 可以通过几条清晰提示或确定性代码解决的问题；
– 没有高质量数据和评测集，只是觉得“微调可能更专业”。
最容易出现的误区是：把企业文档直接拿去微调，希望模型以后能像数据库一样准确背出全部内容。
这样做不仅难以保证准确和更新，还难以删除某条知识、追踪来源和控制权限。对于变化知识，RAG 往往比微调更合适；对于稳定行为，微调才更有价值。
5. 成本和风险
– 数据清洗、去重、标注和覆盖范围决定训练上限；
– 错误数据会被模型系统性学习；
– 可能出现过拟合、能力退化或灾难性遗忘；
– 需要基线、训练后评测、安全测试和回滚方案；
– 基础模型升级后，旧适配器可能需要重新验证甚至重训；
– 训练成本只是开始，模型版本和数据版本还要长期治理。
微调适合改变稳定的行为、格式和领域模式，而不是维护频繁变化、需要引用和权限控制的事实知识。
七、Quantization：减少数值精度，换取更低的部署成本
Quantization 是量化。
在这篇文章里，“量化”指模型量化，不是项目汇报中的“量化指标”。
模型量化用更低精度的数据类型表示权重或激活值，以减少存储、内存、显存和计算成本。
1. 为什么降低精度能省资源
假设一个权重原来用 32 位浮点数表示，如果改成 8 位整数，单个权重的理论存储量约变成四分之一；改成 4 位，理论上约变成八分之一。
以 70 亿参数模型的权重为例，只做非常粗略的原始权重估算：
“`
FP16：7B × 2 byte ≈ 14 GB
INT8：7B × 1 byte ≈ 7 GB
INT4：7B × 0.5byte ≈ 3.5 GB
“`
实际运行还需要 KV Cache、临时张量、运行时缓冲和量化元数据，所以不能把上面数字直接当成最终显存占用。
量化的基本思想，是把连续浮点值映射到较少的离散值。简化表达为：
“`
q = round(x / scale) + zero_point
x ≈ scale × (q – zero_point)
“`
恢复后的 `x` 只是原值的近似，因此会引入量化误差。
Hugging Face 的官方概念文档将量化总结为：用 INT8 等低精度类型表示权重或激活，从而降低模型的内存与计算成本。
2. 常见量化方式
– PTQ（训练后量化）：模型训练完成以后再量化，成本低、使用方便；
– QAT（量化感知训练）：训练过程中模拟量化误差，让模型学习适应，成本更高；
– Weight-only：只量化权重；
– Weight + Activation：权重和激活都量化，潜在收益更大，难度也更高。
3. 量化解决什么问题
– 模型太大，无法放进目标 GPU、CPU 或端侧设备；
– 推理服务显存成本过高；
– 内存带宽成为瓶颈；
– 需要在可接受质量下降范围内提高吞吐或降低延迟；
– 希望把同一硬件用于更多并发或更多模型实例。
4. 量化不能做什么
– 不会给模型增加新知识；
– 不会让模型自动更懂业务；
– 不等于微调；
– 不等于删除参数的剪枝；
– 不等于训练一个更小学生模型的蒸馏。
5. 为什么量化后不一定更快
“位数更低”只说明数据更小，不保证端到端速度一定提升。真实收益取决于：
– 硬件是否原生支持该精度；
– 推理框架是否有高效内核；
– 量化与反量化是否引入额外开销；
– 当前瓶颈是算力、显存容量还是内存带宽；
– 模型结构和批处理方式是否匹配。
所以量化不能只比较模型文件大小，还要在真实硬件和真实任务集上测质量、首 token 延迟、生成速度、吞吐、显存和成本。
6. 成本和风险
– 低比特通常更容易损失精度；
– 某些层、异常值或任务对量化更敏感；
– 不同硬件和推理框架兼容性不同；
– 只测通用基准可能看不出业务任务退化；
– 量化模型仍需版本管理、回归测试和回退模型。
量化通过降低权重或激活的数值精度换取更小内存和更低推理成本，但必须在目标硬件和业务评测集上验证精度与真实性能。
八、把六个概念放进一个真实问题
“`
用户目标
↓
Agent 维护任务状态并决定下一步
├─ LLM：理解、规划、生成
├─ RAG：检索口径与文档证据
└─ MCP：连接数据库、文件和工具
↓
执行、校验、回答、审计
模型侧按需要：
Fine-tuning：改善稳定行为
Quantization：降低部署成本
“`
九、最容易混淆的五组关系
1. LLM 与 Agent
– LLM 是模型；
– Agent 是包含模型、工具、状态和控制循环的系统。
没有工具和循环的单次 LLM 调用，不应因为提示词写了“你是 Agent”就被当成完整 Agent。
2. RAG 与微调
– RAG 在请求时提供外部知识，不修改模型权重；
– 微调通过训练改变模型参数或适配器，形成更稳定的行为模式。
变化事实优先 RAG，稳定行为优先考虑微调。
3. MCP 与工具调用
– 工具调用是一种能力：模型或应用请求执行某个函数；
– MCP 是把工具、资源和提示的发现与调用标准化的一套协议。
工具调用不一定使用 MCP，MCP 也不只是一个函数调用接口。
4. MCP 与 RAG
– MCP 解决连接标准化；
– RAG 解决外部知识增强生成。
RAG 检索器可以通过 MCP 暴露，但两者不是上下级替代关系。
5. 微调与量化
– 微调的目标是改变行为或能力适配；
– 量化的目标是降低存储和推理成本。
QLoRA 同时使用“量化的基础模型”和“LoRA 微调”，所以名字里同时出现两者，但它们在其中仍然承担不同作用。
十、面对需求时，应该先选哪个
可以先用下面这组问题判断：
| 真实问题 | 优先考虑 | 原因 |
|—|—|—|
| 需要自然语言理解和生成 | LLM | 提供基础语言与推理能力 |
| 需要最新、私有或可引用知识 | RAG | 请求时检索外部知识 |
| 需要让多个 AI 客户端统一连接工具和数据 | MCP | 标准化发现、调用和交换 |
| 任务要根据中间结果持续决定下一步 | Agent | 提供状态、工具和执行循环 |
| 模型在固定行为、格式或领域模式上长期不稳定 | Fine-tuning | 通过训练形成稳定适配 |
| 自托管模型太大、太慢或太贵 | Quantization | 以精度换取资源与成本收益 |
还可以用排除法：
– 一段 Prompt 能解决，就先不做微调；
– 直接 SQL 能精确计算，就不要让 RAG 猜数；
– 普通函数能稳定完成，就先不做 Agent；
– 单个内部接口已经足够，就不必为 MCP 而 MCP；
– 没有业务评测集，就不要声称量化“几乎无损”；
– 没有可靠知识源，就不要指望 RAG 自动消除幻觉。
