你让模型”总结这篇文章”，它照做了；你换个说法”用三点概括核心观点”，它也能懂。但当你把同样的问题丢进一个长对话、或者加上 10 个示例再问——效果可能天差地别。

为什么？因为 LLM 不会”理解”你的意图，它只会对齐你给的上下文模式。你给它怎样的 Prompt、多大的上下文、多少示例，它就呈现怎样的能力。

这不是玄学，而是三个可操作的概念：

  1. Prompt（提示） — 你给模型的”剧本”，决定它做什么、怎样做
  2. Context Window（上下文窗口） — 模型的”短期记忆”，一次能”看到”多少内容
  3. In‑Context Learning（上下文学习） — 通过示例让模型”即学即用”，无需微调

搞懂它们，你就知道为什么同一个模型有时靠谱、有时跑偏，以及怎么设计 Prompt 才能稳定发挥。

📜 一、Prompt —— 给 LLM 的”剧本”

Prompt 就像导演给演员的剧本，告诉 LLM 做什么、怎样做、输出什么格式。

💡 Prompt 的处理流程：你输入的 Prompt → Tokenize（分词，见第一篇）→ Embedding（向量化）→ 进入 Transformer 处理 → 生成输出

1.1 按示例数量分类的 Prompt 类型

根据是否提供示例，Prompt 可以分为三类：

类型 定义 示例数量 示例 作用
Zero‑Shot Prompt 不提供示例，仅给指令 0 个 “请总结以下段落的核心观点。” 模型依赖预训练知识直接推理
Few‑Shot Prompt 提供少量输入‑输出示例 1–5 个 输入: A -> 1, B -> 2，然后问 C -> ? 通过示例引导模型学习任务模式与输出风格
Many‑Shot Prompt 提供大量输入‑输出示例 5+ 个 提供 10+ 个示例，展示复杂模式 学习更复杂的任务模式，但会占用更多 Context Window

比喻理解：

  • Zero‑Shot 就像演员即兴表演
  • Few‑Shot 就像给演员提前排练几次，告诉他们节奏和风格
  • Many‑Shot 就像让演员反复观看大量经典表演，学习复杂的表演技巧

💡 选择建议：

  • 简单任务：Zero‑Shot 通常足够
  • 中等复杂度：Few‑Shot 效果更好（如客服话术风格、工单分类——给 2–3 个示例即可对齐输出格式）
  • 复杂任务：Many‑Shot 可能有效，但要注意 Context Window 限制

1.2 User Prompt（用户指令）

User Prompt 是用户每次对话时输入的具体问题或任务指令：

  • 特点：

    • 每次对话都可能不同
    • 包含具体的任务需求、问题或上下文
    • 优先级相对 System Prompt 较低

  • 示例：

    请总结以下文章的核心观点：

    [文章内容...]
    将以下 Python 代码转换为 JavaScript：

    def hello():
        print("Hello, World!")

💡 设计要点：User Prompt 应该清晰、具体、包含必要的上下文，避免模糊或歧义的表达。

1.3 System Prompt（系统指令）

System Prompt 是 LLM 的”身份设定”，它常具有比用户 Prompt 更高的优先级：

  • 用途：定义模型角色、风格、全局行为规则

  • 示例：

    你是一个严谨、专业的测试专家。  

    你只输出 Markdown 表格，不写解释文字。

✅ 建议：合理设置 System Prompt，有助于模型行为一致、稳定

1.4 User Prompt vs System Prompt

💡 两个维度的区别：User/System 是按「谁发送」划分；Zero/Few/Many-Shot 是按「是否提供示例」划分。两者可以组合使用，例如 User Prompt 可以是 Zero-Shot 或 Few-Shot。

在实际使用中，LLM 通常接收两种类型的 Prompt：

类型 定义 特点 使用场景
System Prompt 系统级指令，定义模型的”身份”和全局行为 • 优先级更高
• 通常只设置一次
• 贯穿整个对话		 角色设定、输出格式要求、行为约束
User Prompt 用户的具体问题或任务 • 每次对话都可能不同
• 优先级相对较低		 具体问题、任务指令、对话内容

示例对比：

System Prompt（设置一次）：
你是一个专业的测试工程师，擅长编写清晰的测试用例。

User Prompt（每次对话）：
请为"用户登录功能"编写测试用例。

💡 关键理解：System Prompt 是”背景设定”，User Prompt 是”当前任务”。两者配合使用，才能让模型既保持一致性，又能灵活应对不同任务。

🪟 二、Context Window —— 模型的”短期记忆”

LLM 不可能”无限记忆”，它有一个长度限制 —— Context Window。

2.1 什么是 Context Window

  • 定义：模型在一次推理中”看到”的最大 Token 数

    💡 为什么用 Token 衡量？ 因为 Token 是模型处理的最小单位（见第一篇），所有输入都必须先 Tokenize 才能进入模型。

  • 组成部分：System Prompt + 历史对话 + 当前输入 + 模型已生成的内容（自回归生成时作为上下文）

  • 物理限制：Transformer 中 Self‑Attention 的计算复杂度与 Token 数量平方相关（见第一篇的 Self-Attention 部分）。当 Token 数量过多时，计算代价将迅速上涨（如 1000 Token 需要 100 万次计算，10000 Token 需要 1 亿次计算）

  • 实际示例：

    • 一段 1000 字的中文文章 ≈ 500-800 Token（取决于分词方式）
    • GPT-4 的 Context Window：128k Token（约 25-30 万字）
    • Claude 3.5 的 Context Window：200k Token（约 40-50 万字）

  • 超过限制的后果：当超过限制，最早的 Token 会被”遗忘” —— 即”上下文溢出 (overflow)”

    比喻：Context Window 就像办公桌，一张桌子放太多纸，旧纸就被挤下桌面

2.2 应对 Context Window 限制的策略

当 Context Window 接近或超过限制时，可以使用以下策略：

策略 方法 效果 适用场景
摘要 (Summarization) 将旧对话 / 内容整理为简短摘要 节省 Token，保留关键信息 长对话、多轮交互
记忆模块 (Memory) 抽取关键信息存入外部数据库，当需要时检索 关键信息不丢失 Agent 系统、长期记忆需求
RAG (Retrieval‑Augmented Generation) 只把与当前任务相关的片段放入窗口 支持超长文档处理 知识库问答、文档分析

实际应用示例：

场景：处理 100 页技术文档
1. 使用 RAG：只检索与当前问题相关的 3-5 个片段（约 2000 Token）
2. 结合摘要：将历史对话压缩为摘要（节省 80% Token）
3. 记忆模块：将关键结论存入数据库，后续可直接检索

💡 最佳实践：用摘要 / Memory / RAG 结合起来，是处理长对话 / 文档时的常见实践。RAG 会在第 4 篇中详细讲解。

✨ 三、In‑Context Learning (ICL) —— LLM 的”魔法”

ICL 允许 LLM 无需微调，仅通过 Prompt（尤其 Few‑Shot + 示例）学习新任务 / 模式

💡 Few‑Shot Prompt 与 ICL 的关系：Few‑Shot Prompt（见第一部分 1.1）是 ICL 的典型实现方式。当你提供示例时，模型就在进行 In‑Context Learning。

3.1 ICL 的本质

  • 不是改变模型参数

  • 而是在 Context Window 内识别输入‑输出示例之间的”模式 / 结构”，并应用到新输入上

  • 效果：快速上手新任务、无需大量数据

比喻：就像老师黑板上写几个例子，学生看懂规则，就能回答新问题

3.2 成功应用 — 思维链 (Chain‑of‑Thought, CoT)

CoT 是 ICL 的经典用法，在复杂推理、逻辑题、数学题中尤其有用

  • 做法：Prompt 要求模型”先写思考过程 (step by step)，再给答案”

  • 好处：

    1. 激活模型内部”逻辑推理链”

    2. 提供更多 Token “空间”给中间推理

    3. 输出可读、可复查、方便调试

CoT 类型 使用方式 示例 (prompt)
Zero‑Shot CoT 在问题后加一句 “请一步步思考” … + 请一步步思考。
Few‑Shot CoT Few‑Shot 示例中包含完整思考过程 [输入] → [详细思考过程] → [输出]

⚠️ 重要区别：ICL / CoT 与 Fine‑Tuning（微调） 是不同的：

维度 ICL / CoT Fine‑Tuning
是否改变模型参数 ❌ 不改变 ✅ 改变（更新模型权重）
持久性 临时（只在当前 Context Window 有效） 永久（模型参数已更新）
成本 低（只需提供示例） 高（需要训练数据和计算资源）
适用场景 快速尝试新任务、临时调整 需要长期稳定行为、领域定制

💡 简单理解：ICL 是”临时教学”，Fine‑Tuning 是”永久改造”

3.3 Fine‑Tuning（微调）详解

既然提到了 Fine‑Tuning，我们有必要了解其基础，以便在 ICL 和 Fine‑Tuning 之间做出正确选择。Agent 能力调优中的微调实践（LoRA、PEFT、RLHF-A）详见第 16 篇。

3.3.1 什么是 Fine‑Tuning

Fine‑Tuning（微调） 是在预训练模型的基础上，使用特定任务的数据集继续训练，更新模型参数，使模型适应特定任务或领域。

比喻理解：

  • 预训练模型 = 一个受过”通识教育”的学生（知道很多通用知识）
  • Fine‑Tuning = 针对特定专业（如医学、法律）进行”专业培训”
  • 训练后的模型 = 既保留通识知识，又具备专业能力

3.3.2 Fine‑Tuning 的工作原理

Fine‑Tuning 的核心流程：

1. 准备数据：收集特定任务的标注数据（如问答对、分类样本）
   ↓
2. 加载预训练模型：使用 GPT、BERT 等已训练好的模型作为起点
   ↓
3. 继续训练：在特定数据上训练，更新模型参数（权重）
   ↓
4. 保存模型：得到针对特定任务优化的新模型

关键点：

  • 不是从零训练：基于预训练模型，利用已有的通用知识
  • 参数更新：模型内部的权重（Weight）会根据新数据调整
  • 永久改变：训练完成后，模型行为永久改变

3.3.3 Fine‑Tuning 的常见方法

根据更新参数的范围，Fine‑Tuning 可以分为：

方法 更新范围 参数量 成本 适用场景
Full Fine‑Tuning（全量微调） 更新所有参数 100% 高（需要大量 GPU） 数据充足、计算资源丰富
LoRA (Low‑Rank Adaptation) 只更新少量低秩矩阵 < 1% 低（节省显存和计算） 资源有限、快速迭代
Adapter 在模型中插入小型适配层 < 5% 中 多任务场景、模块化设计
Prompt Tuning 只训练可学习的 Prompt 向量 极少量 极低 轻量级任务适配

💡 LoRA 是目前最流行的 Fine‑Tuning 方法：

简单理解：想象模型是一个巨大的调音台，有 1000 个旋钮（参数）。全量微调需要调整所有 1000 个旋钮，而 LoRA 只添加少量”小旋钮”（参数量 < 1%），通过这些小旋钮就能控制整个调音台的效果。

技术原理：LoRA 不直接修改原始模型参数，而是在模型旁边添加小型适配器。这些适配器只包含极少的参数（通常 < 1%），但通过巧妙的数学方法，能够”模拟”全量微调的效果。

优势：

  • ✅ 成本低：只需训练 < 1% 的参数，显存和计算需求大幅降低
  • ✅ 效果好：效果接近全量微调（通常能达到 90%+ 的效果）
  • ✅ 灵活：可以轻松切换不同的 LoRA 适配器，实现”一个模型，多种能力”

实际应用：现在很多开源模型（如 Stable Diffusion、LLaMA）的微调都使用 LoRA，因为它能让普通用户用消费级 GPU 就能训练自己的模型。

3.3.4 何时选择 Fine‑Tuning vs ICL

选择 Fine‑Tuning 还是 ICL，取决于你的具体需求：

考虑因素 选择 ICL 选择 Fine‑Tuning
任务频率 偶尔使用、临时任务 频繁使用、长期需求
数据量 少量示例即可 有大量标注数据（通常 > 1000 条）
计算资源 无特殊要求 需要 GPU/TPU 训练（详见扩展说明）
响应速度 可能较慢（Context Window 较长） 推理速度快（模型已优化）
成本 低（只需 API 调用） 高（训练成本 + 推理成本）
灵活性 高（可随时调整 Prompt） 低（需要重新训练才能调整）

实际决策示例：

场景 1：偶尔需要翻译技术文档
→ 选择 ICL：在 Prompt 中提供几个翻译示例即可

场景 2：每天需要处理 1000+ 条客服对话
→ 选择 Fine‑Tuning：训练专门的客服模型，提高效率和一致性

场景 3：需要模型理解特定领域的术语（如医疗、法律）
→ 选择 Fine‑Tuning：通过领域数据训练，模型能更好地理解专业术语

💡 最佳实践：

  • 先尝试 ICL：对于新任务，先用 Few‑Shot Prompt 测试效果
  • 再考虑 Fine‑Tuning：如果 ICL 效果不理想，或需要长期稳定使用，再投入资源进行 Fine‑Tuning
  • 混合使用：Fine‑Tuning 后的模型仍可使用 ICL 进行进一步优化

🔍 总结 — 与 LLM 有效对话的三把”钥匙”

  • Prompt = 剧本，清晰、具体的 Prompt 是控制 LLM 的基础

  • Context Window = 桌面，合理管理上下文，防止”记忆溢出”

  • ICL / CoT = 魔法，通过示例 + 思考链，让模型迅速适应新任务

掌握它们，就可以设计结构化、高稳定性的 Prompt，实现复杂任务处理。

📚 延伸阅读（含可直接访问链接）

以下资源按主题分类，每个资源都附有简要说明，帮助你选择合适的学习材料。

💬 Prompt Engineering（提示工程）

🎯 In‑Context Learning（上下文学习）

🔗 Chain‑of‑Thought（思维链）

🪟 Context Window（上下文窗口）

🔧 System Prompt & User Prompt

🎓 Fine‑Tuning（微调）

🛠️ 实战工具与框架

🇨🇳 中文资源

🔔 系列说明

本文是《🧠 LLM/Agent 从入门到精通：告别浅尝辄止》系列第 2 篇。上一篇：ChatGPT 几秒出千字？背后只做了一件事。下一篇：想要 JSON 却得到废话？Prompt 工程的三大核心技巧 —— 如何设计结构化、高稳定性的 Prompt？如何确保输出格式稳定、可解析？

💡 扩展：为什么 Fine‑Tuning 需要 GPU/TPU？

微调工程实践（LoRA、PEFT、RLHF-A）详见第 16 篇能力调优。本篇补充：Fine‑Tuning 需要 GPU/TPU 训练，这到底意味着什么？普通用户能进行 Fine‑Tuning 吗？

什么是 GPU 和 TPU？

GPU（Graphics Processing Unit，图形处理器）：

  • 原本用于游戏、图像处理
  • 擅长并行计算（同时处理大量简单运算）
  • 深度学习训练需要大量矩阵运算，GPU 正好擅长

TPU（Tensor Processing Unit，张量处理器）：

  • Google 专门为 AI 训练设计的芯片
  • 比 GPU 更高效，但主要 Google 内部使用

比喻理解：

  • CPU（普通电脑处理器） = 一个数学教授，能解决复杂问题，但一次只能做一个
  • GPU = 1000 个小学生，虽然每个能力有限，但能同时做大量简单计算
  • 训练 LLM = 需要同时计算几百万个数字，GPU 的并行能力正好匹配

为什么训练需要 GPU/TPU？

核心原因：训练 LLM 需要海量矩阵运算

实际数据：

操作 CPU 耗时 GPU 耗时 加速比
训练小型模型（100M 参数） 数周 数小时 100+ 倍
训练中型模型（7B 参数） 数年 数天 1000+ 倍
训练大型模型（70B+ 参数） 几乎不可能 数周 无法计算

为什么 CPU 这么慢？

  • CPU 核心少（通常 4-16 个），一次只能处理少量数据
  • GPU 核心多（数千个），能同时处理大量数据
  • 训练需要计算数百万个参数的梯度，GPU 的并行能力是关键

Fine‑Tuning 需要多少资源？

不同方法的资源需求：

方法 模型大小 GPU 显存需求 训练时间（示例） 成本估算
Full Fine‑Tuning 7B 参数 40GB+ 数天 高（需要 A100/H100）
LoRA 7B 参数 16GB 数小时 中（RTX 3090/4090 即可）
LoRA 13B 参数 24GB 数小时 中（需要多卡或 A100）
LoRA 70B 参数 80GB+ 数天 高（需要多张 A100）

💡 注意：以上是粗略估算，实际需求取决于：

  • 数据集大小
  • 训练轮数（Epoch）
  • 批次大小（Batch Size）
  • 优化器选择

普通用户如何获得 GPU 资源？

方案 1：云服务（推荐新手）

平台 特点 价格（示例） 适用场景
Google Colab 免费（有限制） 免费 / $10/月 学习、小模型实验
Kaggle 免费（每周 30 小时） 免费 学习、竞赛
AWS / Azure / GCP 按需付费 $0.5-5/小时 生产环境、大模型
RunPod / Vast.ai 共享 GPU $0.2-2/小时 性价比高

方案 2：购买 GPU（适合长期使用）

  • 消费级 GPU（如 RTX 3090/4090）：适合 LoRA 微调中小型模型
  • 专业级 GPU（如 A100/H100）：适合全量微调大模型，但价格昂贵（数万元）

方案 3：使用 Fine‑Tuning API（最简单）

  • OpenAI Fine‑Tuning API：上传数据，OpenAI 帮你训练
  • Anthropic Claude Fine‑Tuning：类似服务
  • 优势：无需管理 GPU，按使用付费
  • 劣势：成本较高，灵活性较低

实际成本对比

场景：微调一个 7B 参数的模型（使用 LoRA）

方案 A：使用云 GPU（RunPod，RTX 4090）
- GPU 成本：$0.5/小时 × 8 小时 = $4
- 数据准备：免费（自己准备）
- 总成本：约 $4（约 30 元人民币）

方案 B：使用 OpenAI Fine‑Tuning API
- 训练成本：$3/小时 × 训练时间
- 数据准备：免费
- 总成本：约 $10-50（取决于训练时间）

方案 C：购买 GPU（RTX 4090）
- 硬件成本：约 1.2 万元
- 适合：需要频繁训练、长期使用

总结

  • GPU/TPU 是必需的：没有它们，Fine‑Tuning 几乎不可能完成
  • 普通用户也能 Fine‑Tuning：通过云服务或 LoRA 方法，成本可控
  • 推荐路径：
    1. 新手：先用 Google Colab / Kaggle 免费资源学习
    2. 进阶：使用云 GPU 服务（RunPod / Vast.ai）进行实际项目
    3. 专业：考虑购买 GPU 或使用 Fine‑Tuning API

💡 关键理解：Fine‑Tuning 需要 GPU，但通过云服务和 LoRA 等优化方法，普通用户也能以合理成本进行 Fine‑Tuning。