Appearance
2.4 2023.3: GPT-4 / Claude — 能力跃升
2023 年 3 月 14 日，OpenAI 发布了 GPT-4 [1]。同月，Anthropic 发布了 Claude（初代）[2]。这是 LLM 能力的一次质变——不只是「更聪明」，而是开始具备看图和调用工具的能力。
text
┌─────────────────────────────────────────────────────────────────────┐
│ 2023.3: GPT-4 / Claude — 能力跃升 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌─────────────────┐ ┌──────────────┐ │
│ │ 文字输入 │ │ │ │ 文字输出 │ │
│ │ + │ ──▶ │ GPT-4 │ ──▶ │ + │ │
│ │ 图片输入 │ │ │ │ 函数调用 │ │
│ └──────────────┘ └─────────────────┘ └──────────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────────────┐ │
│ │ 🆕 多模态（能看图了） │ │
│ │ 🆕 Function Call │ │
│ │ 🆕 更大的 Context │ │
│ │ 🆕 更强的推理能力 │ │
│ └───────────────────────┘ │
│ │
│ ✅ 能看图片 ✅ 能调用外部工具 ✅ Context 8K → 32K │
│ ✅ 推理能力强 ✅ 幻觉大幅减少 ✅ 代码能力显著提升 │
│ │
│ ❌ 仍然无状态 ❌ 仍然有知识截止 ❌ 价格贵（是 GPT-3.5 的 20 倍）│
│ │
└─────────────────────────────────────────────────────────────────────┘GPT-4 vs GPT-3.5 的能力差距：
GPT-4 发布时，OpenAI 展示了一组惊人的数据 [1:1]：
| 考试 | GPT-3.5 | GPT-4 |
|---|---|---|
| 律师资格考试 (Bar Exam) | 后 10% | 前 10% |
| SAT 数学 | 70th percentile | 89th percentile |
| GRE 写作 | 4.0/6.0 | 4.0/6.0 |
| AP 生物 | 3/5 | 5/5 |
从「后 10%」跳到「前 10%」，这不是渐进式改进，而是质变。
2.4.1 多模态：不只是文字了
「多模态」（Multimodal）的意思很简单：模型不再只能处理文字，还能处理图片。
GPT-4V（Vision）是 2023 年 9 月正式开放的 [3]，但 GPT-4 发布时就已经展示了这个能力。经典演示是给它看一张手绘草图，它能直接生成对应的网页代码。
text
【多模态的实际用途】
开发场景：
- 截图报错信息，让 AI 直接分析
- 拍摄白板上的架构图，让 AI 转成文字描述
- 上传 UI 设计稿，让 AI 生成前端代码
物联网场景：
- 拍摄接线图，让 AI 检查是否正确
- 上传设备面板截图，让 AI 解读状态
- 拍摄现场部署照片，让 AI 识别问题这对开发者来说是巨大的效率提升——以前你需要把图片里的内容手动打成文字描述，现在直接截图丢进去就行。
| 概念 | 英文 | 解释 | 为什么重要 |
|---|---|---|---|
| 多模态 | Multimodal [3:1] | 模型能同时处理文字、图片等多种输入 | 扩展了 AI 的应用场景 |
| 视觉语言模型 | Vision-Language Model (VLM) | 能「看图说话」的模型 | GPT-4V、Claude 3 都属于此类 |
2.4.2 Function Call：从「回答问题」到「执行动作」
2023 年 6 月 13 日，OpenAI 为 GPT-4 和 GPT-3.5 加入了 Function Call 功能 [4]。这是一个关键转折点——模型不再只是「回答问题」，而是可以「执行动作」。
在这之前，LLM 只能输出文字。你问它「今天天气怎么样」，它只能基于训练数据猜测，或者说「我无法获取实时信息」。
有了 Function Call 之后：
text
【没有 Function Call】
用户：今天北京天气怎么样？
AI：抱歉，我无法获取实时天气信息。我的知识截止于 2023 年...
【有 Function Call】
用户：今天北京天气怎么样？
AI（内部决策）：这个问题需要实时数据，我应该调用天气 API
AI（输出）：{
"function": "get_weather",
"arguments": { "city": "北京" }
}
系统：调用天气 API，返回结果
AI：今天北京晴，气温 15-23°C，空气质量良好。Function Call 的工作原理：
text
┌─────────────────────────────────────────────────────────────────────┐
│ Function Call 工作流程 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 1. 开发者定义可用函数 │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ functions: [ │ │
│ │ { name: "get_weather", params: { city: string } }, │ │
│ │ { name: "search_docs", params: { query: string } }, │ │
│ │ { name: "send_email", params: { to, subject, body } } │ │
│ │ ] │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 2. 用户提问 │
│ "帮我查一下北京的天气，然后发邮件告诉老板" │
│ │ │
│ ▼ │
│ 3. 模型决策：需要调用哪些函数？ │
│ → get_weather({ city: "北京" }) │
│ → send_email({ to: "boss@...", subject: "天气", body: "..." }) │
│ │ │
│ ▼ │
│ 4. 系统执行函数，返回结果 │
│ │ │
│ ▼ │
│ 5. 模型整合结果，生成最终回复 │
│ │
└─────────────────────────────────────────────────────────────────────┘为什么 Function Call 是 Agent 的基础？
后面我们会讲到 Cursor、Claude Code 这些工具。它们能帮你读文件、写代码、运行命令——这些都是 Function Call 的应用。
- 读文件 = 调用
read_file函数 - 写文件 = 调用
write_file函数 - 运行命令 = 调用
execute_command函数 - 搜索代码 = 调用
search_codebase函数
没有 Function Call，就没有 Agent。这就是为什么 2023 年 6 月是 AI 编程的一个分水岭。
| 概念 | 英文 | 解释 | 为什么重要 |
|---|---|---|---|
| Function Call | Function Calling [4:1] | 模型输出结构化的函数调用请求 | Agent 能「执行动作」的基础 |
| 工具使用 | Tool Use | 更通用的说法，包括 Function Call | Anthropic 称之为 Tool Use [5] |
2.4.3 RAG：让 AI「有据可查」
LLM 有两个根本性问题：
- 知识截止：训练数据有截止日期，不知道「今天发生了什么」
- 幻觉：当不确定时，会一本正经地编造
RAG（Retrieval-Augmented Generation，检索增强生成） 是解决这两个问题的关键技术 [6]。
RAG 的核心思想：
「与其让模型记住所有知识，不如在需要时去查。」
这就像开卷考试 vs 闭卷考试的区别——RAG 让 AI 从「凭记忆回答」变成「先查资料再回答」。
text
┌─────────────────────────────────────────────────────────────────────┐
│ RAG 工作流程 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 【没有 RAG】 │
│ │
│ 用户问题 ──────────────────────────▶ LLM ──────▶ 回答 │
│ │ │
│ │ (只能靠训练时的记忆) │
│ │ │
│ ▼ │
│ 可能产生幻觉 │
│ │
│ 【有 RAG】 │
│ │
│ 用户问题 │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ 检索器 │ ← 「这个问题需要查什么资料？」 │
│ │ (Retriever) │ │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ 知识库 │ ← 文档、数据库、网页、代码库... │
│ │ (Knowledge │ │
│ │ Base) │ │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ 相关文档片段 │ ← 检索到的 Top-K 结果 │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────────────────────────┐ │
│ │ LLM │ │
│ │ │ │
│ │ Context = 用户问题 + 检索到的文档 │ │
│ │ │ │
│ └─────────────────┬───────────────────────┘ │
│ │ │
│ ▼ │
│ 有据可查的回答 │
│ │
└─────────────────────────────────────────────────────────────────────┘RAG 的历史背景：
RAG 的概念由 Facebook AI Research（现 Meta AI）在 2020 年提出 [6:1]。论文标题是《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》——用检索增强生成来处理知识密集型任务。
当时这篇论文的影响有限，因为 2020 年的 LLM 还不够强。但到了 ChatGPT 时代，RAG 突然变得极其重要——因为大家发现，光靠增大模型参数解决不了「知识更新」和「领域专业性」的问题。
为什么 RAG 比「重新训练」更实用？
| 方法 | 成本 | 时效性 | 可控性 |
|---|---|---|---|
| 重新训练模型 | 极高（数百万美元） | 慢（数周到数月） | 低（无法精确控制学到什么） |
| 微调（Fine-tuning） | 高（数千到数万美元） | 中等（数天） | 中等 |
| RAG | 低（只需维护知识库） | 实时（随时更新文档） | 高（精确控制信息来源） |
RAG 的技术细节：
RAG 系统的核心是向量检索。简单说：
- Embedding（嵌入）：把文本转换成「向量」——一串数字，表示文本的「语义位置」
- 向量数据库：存储所有文档的向量，支持快速相似度搜索
- 相似度匹配：用户问题也转成向量，找到「语义最接近」的文档
text
┌─────────────────────────────────────────────────────────────────────┐
│ 向量检索原理（简化版） │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 文档入库阶段 │
│ ┌──────────────────────────────────────────────────────────────┐│
│ │ ││
│ │ "Python 是一种编程语言" ──▶ [0.12, 0.85, 0.33, ...] ││
│ │ "JavaScript 用于网页开发" ──▶ [0.15, 0.82, 0.41, ...] ││
│ │ "今天天气很好" ──▶ [0.91, 0.12, 0.08, ...] ││
│ │ │ ││
│ │ ▼ ││
│ │ 向量数据库存储 ││
│ │ ││
│ └──────────────────────────────────────────────────────────────┘│
│ │
│ 检索阶段 │
│ ┌──────────────────────────────────────────────────────────────┐│
│ │ ││
│ │ 用户问题: "Python 怎么学？" ││
│ │ │ ││
│ │ ▼ ││
│ │ [0.11, 0.87, 0.35, ...] (问题向量) ││
│ │ │ ││
│ │ ▼ ││
│ │ 计算与所有文档的「距离」 ││
│ │ │ ││
│ │ ▼ ││
│ │ 最相似: "Python 是一种编程语言" (距离: 0.03) ✅ ││
│ │ 次相似: "JavaScript 用于网页开发" (距离: 0.15) ││
│ │ 不相关: "今天天气很好" (距离: 0.89) ││
│ │ ││
│ └──────────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────────────┘主流向量数据库：
| 名称 | 特点 | 适用场景 |
|---|---|---|
| Pinecone | 托管服务，开箱即用 | 快速上手，不想自己运维 |
| Weaviate | 开源，支持多种模态 | 需要灵活定制 |
| Milvus | 开源，高性能 | 大规模生产环境 |
| Chroma | 轻量级，Python 友好 | 本地开发、原型验证 |
| pgvector | PostgreSQL 扩展 | 已有 PostgreSQL 的团队 |
RAG 在开发工具中的应用：
你可能没意识到，但你每天用的 AI 编程工具，核心就是 RAG：
| 工具 | RAG 应用 | 知识库 |
|---|---|---|
| Cursor | @codebase 搜索 | 你的代码库 |
| Claude Code | 代码搜索、文件读取 | 当前项目文件 |
| GitHub Copilot | 上下文感知补全 | 当前文件 + 相关文件 |
| ChatGPT Search | 联网搜索 | 互联网 |
| Perplexity | 实时检索 + 引用 | 互联网 + 学术论文 |
当你在 Cursor 里说「帮我找到所有处理用户认证的代码」，它做的事情就是：
- 把你的问题转成向量
- 在代码库的向量索引中搜索
- 找到最相关的代码片段
- 把这些片段塞进 Context，让 LLM 基于真实代码回答
RAG 的局限性：
RAG 不是万能的，它有几个常见问题：
| 问题 | 说明 | 缓解方法 |
|---|---|---|
| 检索质量 | 找到的文档可能不相关 | 优化 Embedding 模型、调整检索策略 |
| Context 限制 | 检索太多文档会超出 Context Window | 分块（Chunking）、重排序（Reranking） |
| 信息整合 | 多个文档的信息可能冲突 | 让模型标注信息来源 |
| 延迟 | 检索步骤增加响应时间 | 缓存、预计算 |
Chunking（分块）策略：
把长文档切成小块是 RAG 的关键步骤。切得不好，检索效果会很差：
text
【不好的分块】—— 按固定字数切割，切断了语义
"...这个函数用于处理用户登" | "录，它会验证密码并生成..."
↑ ↑
第 1 块结束 第 2 块开始
→ 检索「用户登录」时可能两块都找不到
【好的分块】—— 按语义边界切割
"这个函数用于处理用户登录，它会验证密码并生成 JWT token。"
→ 完整的语义单元，检索效果好常见的分块策略：
- 按段落：适合结构清晰的文档
- 按句子 + 重叠：每块包含前一块的最后几句，保持上下文
- 按代码结构：函数、类、模块为单位
- 语义分块：用模型判断语义边界
我的理解：
RAG 本质上是在说：「LLM 的强项是理解和推理，不是记忆。让它专注于强项，记忆的事交给检索系统。」
这和人类的工作方式很像——好的专家不是「什么都记得」，而是「知道去哪里查，查到后能理解和应用」。
| 概念 | 英文 | 解释 | 为什么重要 |
|---|---|---|---|
| RAG | Retrieval-Augmented Generation [6:2] | 先检索相关文档，再让 LLM 基于文档生成回答 | 解决知识截止和幻觉问题 |
| Embedding | Embedding [7] | 把文本转换成向量表示 | RAG 检索的基础 |
| 向量数据库 | Vector Database | 专门存储和检索向量的数据库 | 支撑大规模 RAG 系统 |
| Chunking | Chunking | 把长文档切分成适合检索的小块 | 影响 RAG 检索质量 |
[!TODO] 素材准备
- [ ] RAG 原理示意图（可参考 LangChain 文档）
- [ ] 向量检索可视化（二维空间中的语义聚类）
- [ ] Cursor @codebase 功能演示截图
2.4.4 Claude 的入场
2023 年 3 月 14 日，就在 GPT-4 发布的同一天，Anthropic 发布了 Claude [2:1]。这家公司由前 OpenAI 员工创立，包括 GPT-3 论文的第一作者 Dario Amodei。
Claude 的差异化定位是更安全、更诚实。它更愿意说「我不知道」，而不是编造答案。这在当时是一个明显的风格差异。
到 2024 年 3 月，Claude 3 系列发布，Context Window 直接拉到 200K tokens——是 GPT-4 的 6 倍多。这意味着你可以把一整本书丢进去让它分析。
竞争格局的变化：
| 时间 | 格局 |
|---|---|
| 2022.11 | OpenAI 一家独大（ChatGPT） |
| 2023.3 | Anthropic 入场（Claude），双雄对峙 |
| 2023.12 | Google Gemini 发布，三足鼎立 |
| 2024 | 开源模型崛起（Llama、Mistral），百花齐放 |
| 2025.1 | DeepSeek R1 发布，中国力量入场 |
2.4.5 我的亲历视角：Prompt 整理期
作者观点
以下是我个人在这段时期的使用经历。
说实话，这段时期我在代码方面的工作不多，所以没有太强的「GPT-4 比 GPT-3.5 强多少」的直接体感。
但我做了一件事：开始整理常用的 prompt。
这个阶段另一个明显的转变是：我渐渐只用 ChatGPT Search，不再用传统搜索引擎了。
以前查资料的流程是：Google 搜索 → 点进去 → 发现不对 → 换个关键词 → 再搜 → 再点。现在变成：直接问 ChatGPT → 它帮你整合多个来源 → 一次性给你答案。
这个习惯转变，其实就是后面 Part 4 会讲的「Context Engineering」的雏形——你开始意识到，如何组织信息给 AI，比单纯「问问题」更重要。
[!TODO] 素材准备
- [ ] GPT-4 发布时的官方演示截图（手绘草图生成网页）
- [ ] Function Call 工作原理示意图
- [ ] GPT-4 vs GPT-3.5 考试成绩对比图
- [ ] 补充「我的常用 prompt」例子
参考资料
🔬 L1 | GPT-4 | OpenAI - OpenAI 于 2023 年 3 月 14 日发布 GPT-4。 ↩︎ ↩︎
🔬 L1 | Introducing Claude | Anthropic - Anthropic 于 2023 年 3 月发布 Claude。 ↩︎ ↩︎
🔬 L1 | GPT-4V(ision) system card | OpenAI - GPT-4 视觉能力于 2023 年 9 月正式开放。 ↩︎ ↩︎
🔬 L1 | Function calling | OpenAI - OpenAI 于 2023 年 6 月 13 日发布 Function Calling 功能。 ↩︎ ↩︎
🔬 L1 | Tool use | Anthropic - Anthropic 的工具使用文档，功能类似 OpenAI 的 Function Call。 ↩︎
🔬 L1 | Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks | arXiv - Facebook AI Research（现 Meta AI）2020 年发布的 RAG 原始论文，Patrick Lewis 等人。首次提出将检索系统与生成模型结合的范式。 ↩︎ ↩︎ ↩︎
📝 L3 | What are embeddings? | Vicki Boykis - Vicki Boykis 的深度长文，详解 Embedding 的原理、历史和应用，被广泛推荐为入门必读。另见 Embeddings | OpenAI。 ↩︎