第一篇：大模型全景——从核心概念到本地实战

⏱ 推荐分享时长：65 分钟
设计思路：这是整个系列的第一篇，目标是让团队成员在一次分享内建立起对大模型完整且实用的认知框架。
整体逻辑：是什么 → 热门概念 → 怎么用 → 怎么选 → 怎么部署/微调 → Embedding/RAG → 团队怎么落地 → 动手做

1.1 什么是大语言模型（LLM）

开场：一个真实的效率革命

想象一下这个场景：团队每次做技术方案评审，需要整理会议纪要——手动从录音里扒文字、整理成结构化文档、标注 action items，一个人至少要花 2 小时。现在用 AI，视频录制 → Whisper 转文字 → LLM 整理成文档，5 分钟搞定。

这不是科幻，这就是大语言模型（Large Language Model，简称 LLM）在日常工作中的真实应用。

从 NLP 到 LLM 的演进脉络

自然语言处理（NLP）的演进大致经历了四个时代：

规则时代             统计时代            深度学习时代          大模型时代
(1950s-1990s)       (1990s-2010s)       (2010s-2017)         (2017-至今)
┌─────────┐        ┌─────────┐        ┌──────────┐        ┌──────────────┐
│ if-else  │   →   │ 朴素贝叶斯 │  →   │ LSTM/RNN │   →   │ Transformer  │
│ 正则匹配 │        │ 隐马尔可夫 │       │ Word2Vec │        │ GPT/BERT     │
│ 模板填充 │        │ SVM      │        │ Seq2Seq  │        │ ChatGPT      │
└─────────┘        └─────────┘        └──────────┘        └──────────────┘
 人工写规则            靠统计概率          能学上下文            真正"理解"语言

规则时代：人写 if-else，"包含关键词 X 就回答 Y"。可想而知，规则越写越多，维护成本爆炸。
统计时代：让机器从数据中学习概率模式。垃圾邮件过滤就是这个时代的产物。
深度学习时代：神经网络登场，LSTM/RNN 能处理序列数据，但有个致命问题——处理长文本时前面的内容会被"遗忘"。
大模型时代：2017 年 Google 发布论文 "Attention Is All You Need"，提出了 Transformer 架构，彻底改变了游戏规则。

Transformer 为什么重要

Transformer 的核心创新是自注意力机制（Self-Attention）。用一个类比来理解：

想象你在读一篇文章，传统方法像是"逐字阅读，读到后面忘了前面"；而 Transformer 像是"把整篇文章同时铺在桌上，每读一个词都能回头看到任意位置的内容"。

这带来了三个关键突破：

突破	传统 RNN	Transformer
上下文理解	像传话游戏，越远越模糊	任意两个位置都能直接"对话"
并行计算	必须逐词处理，速度慢	所有位置同时计算，可充分利用 GPU
可扩展性	模型难以做大	模型越大，效果越好（Scaling Law）

正是因为 Transformer 可以并行计算、可以高效利用大量数据，才让"大力出奇迹"成为可能——参数量从百万级到千亿级，推动了从 BERT 到 GPT-4 再到如今 GPT-5 的演进。

三阶段训练范式：预训练 + 微调 + RLHF

理解 LLM 的训练过程，有助于理解为什么同一个基座模型有不同"版本"：

阶段一：预训练                阶段二：指令微调              阶段三：RLHF
Pre-training                Instruction Fine-tuning      人类反馈强化学习
┌──────────────┐           ┌──────────────┐            ┌──────────────┐
│ 互联网海量文本  │     →    │ 高质量问答对   │      →    │ 人类标注偏好   │
│ 书籍、论文、代码│           │ "请帮我总结…"  │            │ "回答A比B更好" │
│ 数千亿Token   │           │ "请用Python…"  │            │ 安全、有用、诚实│
└──────────────┘           └──────────────┘            └──────────────┘
  学会了"语言"                 学会了"听指令"                学会了"说人话"
  能续写文本                   能回答问题                    拒绝有害请求
  但不会对话                   但可能不够安全                  像个靠谱助手

预训练（Pre-training）：用互联网海量文本（几 TB）训练，让模型学会语言的统计规律。这个阶段烧钱最多（GPT-4 的预训练成本估计超过 1 亿美元），产出的是基座模型（Base Model）——它能续写文本，但不会对话。
指令微调（Instruction Fine-tuning）：用精心标注的问答对（几万到几十万条）训练，让模型学会"听懂人话、按指令做事"。这就是从 GPT-4-base 到 GPT-4 的关键一步。
RLHF（Reinforcement Learning from Human Feedback）：人类标注员对模型的多个回答进行排序（"A 比 B 好"），训练一个奖励模型，再用强化学习优化。这让模型变得安全、有帮助、诚实——不会教你做炸弹，会承认"我不确定"。

为什么理解这个很重要？

当你看到 DeepSeek-V3（基座）vs DeepSeek-V3-Chat（对话）vs DeepSeek-R1（推理增强），就知道它们是同一家族的不同训练阶段产物。选模型时，Chat 版本用于对话，Base 版本用于微调。

闭源 vs 开源的本质区别

维度	闭源模型	开源模型
代表	GPT-5、Claude Opus、Gemini Pro	DeepSeek、Qwen、Llama
能力天花板	通常更高（训练资源多）	追赶迅速（DeepSeek 已接近 GPT-4）
数据隐私	数据发送到第三方服务器	可本地部署，数据不出内网
部署灵活性	只能调 API	可本地、私有云、自定义部署
成本	按 Token 付费，量大时昂贵	自部署需要 GPU，小规模用 API 更划算
可定制性	只能通过 Prompt/微调 API	可以修改模型本身

一句话总结：闭源模型是"拎包入住的五星酒店"，开源模型是"自己装修的房子"——前者省心、后者灵活，大多数场景两者混用。

1.2 核心概念

这些概念是和同事讨论 AI、调用 API 时的基本词汇表。每个概念用一句话定义 + 一个实际场景讲清楚。

Token：计费的基本单位

一句话定义：Token 是模型处理文本的最小单位，可以理解为"词的碎片"。

英文大致 1 个单词 ≈ 1.3 个 Token
中文大致 1 个汉字 ≈ 1.5~2 个 Token（因为中文需要更多字节编码）
代码中的标点、缩进也算 Token

为什么 Token 重要——它决定了你调 API 花多少钱：

以 GPT-4o 为例（2026 年定价）：
- 输入：$2.50 / 百万 Token
- 输出：$10.00 / 百万 Token

一次典型的对话（1000 Token 输入 + 500 Token 输出）≈ $0.0075

看起来很便宜？如果你的产品每天有 10 万用户，每人平均 10 次对话：
  10万 × 10 × $0.0075 = $7,500/天 = $22.5万/月

换成 DeepSeek V3：
- 输入：$0.27 / 百万 Token（便宜 ~10 倍）
- 输出：$1.10 / 百万 Token（便宜 ~10 倍）
- 同样场景：$2.25万/月 → 省了 $20万

实用工具

OpenAI 官方提供了 Tokenizer，可以直接粘贴文本查看 Token 数量。LangChain 中使用 tiktoken 库估算 Token 数量。

Context Window（上下文窗口）：你能塞多少资料

一句话定义：Context Window 是模型一次能"看到"的最大文本长度，包含输入 + 输出的总 Token 数。

模型演进中的上下文窗口扩展：

GPT-3 (2020):    4,096 Tokens   ≈ 3,000 字   ≈ 6 页 A4 纸
GPT-4 (2023):    128K Tokens    ≈ 96,000 字   ≈ 一本小书
Claude 3 (2024): 200K Tokens    ≈ 150,000 字  ≈ 一本中等小说
Gemini 2 (2025): 2M Tokens      ≈ 1,500,000 字 ≈ 整套《哈利波特》

上下文窗口决定了你的用法：

4K 窗口：只能做简单问答，塞不下长文档
128K 窗口：可以把一份完整的技术文档丢进去分析
2M 窗口：可以把整个代码仓库作为上下文

注意

"支持 128K" ≠ "128K 都能用好"。后面 1.4 节会讲到 "Lost in the Middle" 现象——模型对上下文中间部分的注意力会衰减。把关键信息放在开头或结尾更靠谱。

Temperature / Top-P：控制创造力的"旋钮"

一句话定义：Temperature 控制模型输出的随机性，值越高越有创意、越低越确定。

Temperature = 0（确定性最高）
  "北京的首都是？" → "北京是中国的首都"（每次都一样）
  适用：代码生成、数据提取、事实性问答

Temperature = 0.7（适度随机）
  "写一段产品描述" → 每次措辞略有不同但质量稳定
  适用：通用对话、内容撰写

Temperature = 1.2（高度随机）
  "写一首诗" → 每次风格和用词差异很大
  适用：创意写作、头脑风暴

开发中的经验法则：
  代码 / 数据处理 → Temperature = 0
  通用对话 / 客服 → Temperature = 0.3~0.7
  创意 / 营销文案 → Temperature = 0.8~1.2

Top-P（核采样） 是另一个控制随机性的参数，和 Temperature 效果类似。一般只调一个：要么调 Temperature，要么调 Top-P，不要两个同时调。大多数场景只用 Temperature 就够了。

System Prompt / User Prompt / Assistant：对话角色

LLM 的 API 调用采用多角色对话格式，理解这三个角色是写代码调用 API 的基础：

json

{
  "messages": [
    {
      "role": "system",
      "content": "你是一个专业的代码审查助手。请用中文回复，指出代码中的问题并给出改进建议。"
    },
    {
      "role": "user",
      "content": "请帮我审查这段代码：\nfunction add(a, b) { return a - b }"
    },
    {
      "role": "assistant",
      "content": "我发现了一个 Bug：函数名是 `add`（加法），但实现是 `a - b`（减法）..."
    },
    {
      "role": "user",
      "content": "谢谢，还有其他问题吗？"
    }
  ]
}

角色	作用	类比
system	设定 AI 的身份、行为规则、输出格式	给员工的岗位说明书
user	用户的输入	客户的需求
assistant	AI 的回复	员工的工作输出

System Prompt 是最重要的"控制面板"

好的 System Prompt 能让 AI 稳定输出你想要的格式和风格。第二篇会深入讲 Prompt Engineering 最佳实践。

幻觉（Hallucination）："一本正经地胡说八道"

一句话定义：模型生成的内容看起来流畅合理，但实际上是虚构的或错误的。

为什么会有幻觉？ 模型的本质是"根据概率预测下一个 Token"，它不是在"查询知识库"，而是在"统计最可能的下一个词"。当训练数据中没有明确答案时，模型倾向于"编一个看起来合理的答案"而不是说"我不知道"。

常见幻觉场景：

1. 虚构引用
   问："推荐一篇关于 React 性能优化的论文"
   答："Smith et al. (2024). 'React Performance Patterns'..."（这篇论文不存在）

2. 事实错误
   问："Node.js 是哪年发布的？"
   答："Node.js 于 2011 年发布"（实际是 2009 年）

3. 过度自信
   问："这段代码有 Bug 吗？"
   答："这段代码完全正确，没有任何问题"（实际有明显的内存泄漏）

工程侧如何缓解幻觉？

策略	做法	效果
RAG	先检索相关文档，让模型基于事实回答	⭐⭐⭐⭐⭐ 最有效
降低 Temperature	设为 0 或接近 0，减少随机性	⭐⭐⭐ 有帮助
要求引用来源	Prompt 中要求"引用原文出处"	⭐⭐⭐ 可验证
Self-Consistency	多次生成取共识	⭐⭐ 成本高但有效
人工审核	关键输出必须人工确认	⭐⭐⭐⭐ 最后防线

多模态输入：不只是文字

现代 LLM 已经能处理多种类型的输入：

输入类型	支持的模型	典型应用
文本	所有 LLM	对话、写作、编程
图片	GPT-4o、Claude 3.5、Gemini	图片描述、UI 截图分析、OCR
音频	GPT-4o、Gemini	语音对话、音频转写
视频	Gemini	视频内容分析、视频问答
文件	GPT-4o（PDF）、Claude（PDF）	文档分析、数据提取

typescript

// 多模态调用示例（Node.js + OpenAI SDK）
import OpenAI from 'openai'

const openai = new OpenAI()

const response = await openai.chat.completions.create({
  model: 'gpt-4o',
  messages: [
    {
      role: 'user',
      content: [
        { type: 'text', text: '这个 UI 设计稿有什么可以改进的地方？' },
        {
          type: 'image_url',
          image_url: {
            url: 'data:image/png;base64,{base64_encoded_image}',
          },
        },
      ],
    },
  ],
})

1.3 当下 AI 热门概念速览

这一节是"扫盲节"，每个概念快速过，目标是"听完能在茶水间聊天时不掉队"。

AI 编程范式

范式	一句话解释	典型场景	质量
Vibe Coding	凭感觉让 AI 写代码，"你懂我的意思吧"	快速原型、Hackathon	⚠️ 不可控
Spec Coding	先写详细规约（需求/接口/测试），再让 AI 照着写	正式项目开发	✅ 可控
Agentic Coding	AI Agent 自主完成完整开发循环：读代码→改代码→跑测试→修 Bug	复杂任务、自动化重构	✅✅ 高质量

演进关系：

Vibe Coding（随意发挥）
    ↓ 发现质量不可控
Spec Coding（先写规约再编码）
    ↓ 发现 AI 能做更多
Agentic Coding（AI 自主完成全流程）

AI 编程工具

工具	定位	核心特色
Cursor	AI-native 编辑器	Rules 机制自定义 AI 行为，Composer 多文件编辑
Claude Code	终端 AI Agent	命令行里完成复杂开发任务，直接操作文件系统
GitHub Copilot	代码补全 + Chat	生态最完善，VS Code/JetBrains 插件
Trae	AI IDE	字节出品，SOLO 模式 + 技能系统
Windsurf	AI IDE	Cascade 模式，智能上下文理解
Augment	AI 编程助手	专注大型代码库理解和导航

协议与标准

MCP（Model Context Protocol）：Anthropic 提出，"AI 的 USB-C"——让不同的 AI 工具（Cursor、Claude Code、Trae）通过统一协议连接外部工具和数据源。你开发一个 MCP Server，所有支持 MCP 的 AI 工具都能用。
A2A（Agent-to-Agent）：Google 提出的 Agent 间通信协议。多个 Agent 之间如何互相发现、通信和协作。
Skills：AI 编辑器中的可复用能力模块。把 Prompt + 工作流封装成一个 SKILL.md 文件，类似"给 AI 装插件"。
Tool Use / Function Calling：让模型调用外部函数。模型说"我需要查天气"→ 你的代码调天气 API → 把结果返回给模型。这是 Agent 能"干活"的基础，1.4 节详细展开。

工程方法论的演进

Prompt Engineering        Context Engineering         Harness Engineering
 提示工程 (2023)            上下文工程 (2025)            驾驭工程 (2026)
┌────────────┐           ┌────────────────┐          ┌────────────────┐
│ 写好 Prompt  │    →     │ 系统设计整个     │    →    │ 给 Agent 设计   │
│ 让模型听懂   │           │ 喂给 LLM 的上下文 │         │ 约束、反馈、验证 │
│ 一个技巧     │           │ 一套方法论       │          │ 一套治理体系    │
└────────────┘           └────────────────┘          └────────────────┘
"怎么问问题"              "怎么给模型准备信息"          "怎么让 Agent 戴着缰绳跑"

Prompt Engineering：关注"怎么写 Prompt"——措辞、格式、Few-shot 示例
Context Engineering：更系统化——不只是 Prompt，还包括检索的文档、工具描述、历史对话、用户画像……精心设计所有输入给模型的信息
Harness Engineering：围绕 AI Agent 设计约束和反馈机制——最大迭代次数、输出校验、人工审核节点、预算控制，让 Agent "戴着缰绳跑"

1.4 开发实战中的关键机制

这是第一篇最"工程化"的一节，每个机制都配代码片段。

JSON Mode / Structured Output

为什么需要：调 API 拿到自然语言回复后，还得自己解析——正则匹配不稳定，JSON.parse 经常报错。Structured Output 让模型直接输出合法的 JSON。

typescript

// Node.js + OpenAI SDK：使用 Structured Output
import OpenAI from 'openai'
import { z } from 'zod'
import { zodResponseFormat } from 'openai/helpers/zod'

const ReviewResult = z.object({
  hasIssues: z.boolean(),
  issues: z.array(
    z.object({
      line: z.number(),
      severity: z.enum(['error', 'warning', 'info']),
      description: z.string(),
      suggestion: z.string(),
    })
  ),
  summary: z.string(),
})

const openai = new OpenAI()

const completion = await openai.beta.chat.completions.parse({
  model: 'gpt-4o',
  messages: [
    { role: 'system', content: '你是一个代码审查助手，请分析代码中的问题。' },
    { role: 'user', content: 'function add(a, b) { return a - b }' },
  ],
  response_format: zodResponseFormat(ReviewResult, 'review_result'),
})

const result = completion.choices[0].message.parsed
// result.hasIssues → true
// result.issues[0].description → "函数名为 add 但实现了减法"

不同模型的结构化输出支持

OpenAI：response_format: { type: "json_schema" } 或 Zod Schema
Anthropic：通过 Tool Use 间接实现结构化输出
DeepSeek：兼容 OpenAI 的 JSON Mode
通用方案：在 Prompt 里明确要求 JSON 格式 + 后处理校验

Function Calling / Tool Use

从"聊天"到"干活"的关键跨越——让模型不再只是生成文字，而是能调用你的代码。

用户："北京今天天气怎么样？"

没有 Function Calling：
  模型："北京今天大概是晴天吧"（瞎猜的，可能是错的）

有 Function Calling：
  模型："我需要调用 get_weather 函数"  ← 模型决策
    → 你的代码调用天气 API              ← 程序执行
    → 返回 { temp: 28, weather: "晴" }  ← 真实数据
  模型："北京今天天气晴朗，气温 28°C"    ← 基于真实数据回答

typescript

// Node.js 实现 Function Calling
const tools = [
  {
    type: 'function' as const,
    function: {
      name: 'get_weather',
      description: '获取指定城市的实时天气信息',
      parameters: {
        type: 'object',
        properties: {
          city: {
            type: 'string',
            description: '城市名称，如"北京"、"上海"',
          },
        },
        required: ['city'],
      },
    },
  },
]

const response = await openai.chat.completions.create({
  model: 'gpt-4o',
  messages: [{ role: 'user', content: '北京今天天气怎么样？' }],
  tools,
})

// 模型返回 tool_calls，你的代码执行函数并把结果返回给模型
const toolCall = response.choices[0].message.tool_calls?.[0]
if (toolCall?.function.name === 'get_weather') {
  const args = JSON.parse(toolCall.function.arguments)
  const weatherData = await fetchWeather(args.city) // 你的 API 调用
  // 把结果返回给模型生成最终回复...
}

Function Calling 是 Agent 的基石——第二篇讲的所有 Agent 能力（搜索、数据库查询、代码执行）都建立在这个机制之上。

流式输出（Streaming）

为什么需要流式输出：LLM 生成一段 500 字的回复可能需要 3~5 秒。如果等全部生成完再返回，用户体验很差（像"卡住了"）。流式输出让每个 Token 生成后立刻返回给前端，像打字机一样逐字出现。

非流式（等 3 秒后一次性返回）：
  [等待...等待...等待...] → "完整的500字回复一次性出现"

流式（立刻开始逐字输出）：
  → "北" → "京" → "今" → "天" → "天" → "气" → "晴" → "朗" → ...
  用户 0.3 秒就看到第一个字（TTFT = 0.3s）

两个核心指标：

TTFT（Time To First Token）：从请求发出到看到第一个字的时间，通常 0.2~1 秒。这是用户体验的核心指标——用户不在乎全部生成要多久，在乎"是不是卡了"。
TPS（Tokens Per Second）：每秒生成多少 Token，决定了"打字速度"。通常 30~100 TPS。

typescript

// Node.js 流式输出实现
const stream = await openai.chat.completions.create({
  model: 'gpt-4o',
  messages: [{ role: 'user', content: '介绍一下 React Hooks' }],
  stream: true, // 关键：开启流式
})

for await (const chunk of stream) {
  const content = chunk.choices[0]?.delta?.content || ''
  process.stdout.write(content) // 逐字输出
}

typescript

// 前端 SSE 渲染示例（React）
function ChatMessage() {
  const [text, setText] = useState('')

  async function handleStream() {
    const response = await fetch('/api/chat', {
      method: 'POST',
      body: JSON.stringify({ message: 'Hello' }),
    })

    const reader = response.body!.getReader()
    const decoder = new TextDecoder()

    while (true) {
      const { done, value } = await reader.read()
      if (done) break
      const chunk = decoder.decode(value)
      setText(prev => prev + chunk) // 逐步追加文本
    }
  }

  return <div>{text}</div>
}

Rate Limit 与错误处理

TPM / RPM 是什么：

TPM（Tokens Per Minute）：每分钟可用的 Token 总量
RPM（Requests Per Minute）：每分钟可发送的请求数

OpenAI GPT-4o 的默认限制（Tier 1）：
  RPM: 500    （每分钟 500 个请求）
  TPM: 30,000 （每分钟 3 万 Token）

如果超过限制 → 返回 HTTP 429 Too Many Requests

指数退避重试策略：

typescript

async function callWithRetry(
  fn: () => Promise<any>,
  maxRetries = 3
) {
  for (let i = 0; i < maxRetries; i++) {
    try {
      return await fn()
    } catch (error: any) {
      if (error.status === 429 && i < maxRetries - 1) {
        const delay = Math.pow(2, i) * 1000 + Math.random() * 1000
        console.log(`Rate limited. Retrying in ${delay}ms...`)
        await new Promise(resolve => setTimeout(resolve, delay))
      } else {
        throw error
      }
    }
  }
}

// 使用
const result = await callWithRetry(() =>
  openai.chat.completions.create({
    model: 'gpt-4o',
    messages: [{ role: 'user', content: 'Hello' }],
  })
)

重试策略要点

指数退避：第 1 次等 1 秒，第 2 次等 2 秒，第 3 次等 4 秒
加随机抖动：避免多个请求同时重试造成"雪崩"
设置最大重试次数：避免无限循环
记录日志：方便排查是不是经常触发限流（说明需要申请更高额度或优化调用频率）

上下文窗口 ≠ 有效利用长度

"Lost in the Middle" 现象：研究发现，当上下文很长时，模型对开头和结尾的内容关注度高，对中间部分的内容"视而不见"。

上下文中不同位置的信息被模型注意到的概率：

位置:     开头      ↓      中间       ↓      结尾
注意力:   ████████  ████  ██  ██  ████  ████████

把关键信息放在中间 → 容易被模型忽略
把关键信息放在开头或结尾 → 更容易被注意到

实践建议：

将最重要的信息（如 System Prompt、关键指令）放在开头
将用户当前问题放在结尾
参考资料放在中间，但要用明确的标记分隔（如 <context>...</context>）
如果上下文超过 32K Token，考虑使用 RAG 只检索最相关的片段

缓存与成本优化

Prompt Caching：如果你的多次请求有相同的前缀（比如一样的 System Prompt），OpenAI 和 Anthropic 都支持缓存复用，缓存命中的部分打 5 折甚至更低。

场景：客服系统，每次请求的 System Prompt 都一样（2000 Token）

没有 Prompt Caching：
  请求 1: 2000 (system) + 500 (user) = 2500 Token 全价
  请求 2: 2000 (system) + 300 (user) = 2300 Token 全价

有 Prompt Caching：
  请求 1: 2000 (system, 首次全价) + 500 (user) = 2500 Token
  请求 2: 2000 (system, 缓存命中 50% off) + 300 (user)
  ...后续所有请求的 system 部分都是半价

节省：如果每天 10 万请求，system prompt 占 40% Token
  → 40% × 50% = 20% 总成本节省
  → 按月可能省下数万美元

其他成本优化策略：

策略	做法	节省幅度
模型分级	简单问题用便宜模型（GPT-4o-mini），复杂问题用强模型	30~60%
减少输出	Prompt 中明确要求简洁回复，限制 max_tokens	20~40%
批量处理	用 Batch API（延迟换价格，通常 50% off）	50%
Prompt 精简	减少冗余指令和示例	10~30%
开源替代	非核心场景用 DeepSeek / Qwen 替代 GPT-4	50~90%

1.5 评测榜单与核心指标

选模型不能只看官方宣传，得看第三方评测。这一节帮你读懂榜单。

主流评测榜单

榜单	特色	可信度	链接
LMSYS Chatbot Arena (LM Arena)	人类盲测 Elo 排名，用户不知道对比的是哪两个模型	⭐⭐⭐⭐⭐	lmarena.ai
Artificial Analysis	综合智能指数 + 性价比 + 延迟等工程指标	⭐⭐⭐⭐	artificialanalysis.ai
HuggingFace Open LLM Leaderboard	开源模型排行，社区驱动	⭐⭐⭐⭐	huggingface.co
SuperCLUE	中文模型专项评测	⭐⭐⭐	superclue.ai
LiveBench	定期更新题目，防止训练集污染	⭐⭐⭐⭐	livebench.ai

为什么 LM Arena 最受信任？ 因为它采用"人类盲测"——用户同时向两个匿名模型提问，选出更好的回答，基于 Elo 评分机制（类似国际象棋排名）。模型厂商无法通过"刷分"作弊。

核心指标解读

看到这些指标名字不用慌，记住常用的几个就够了：

指标	测什么	怎么理解
MMLU / MMLU-Pro	知识广度（57 个学科选择题）	"高考成绩"，越高说明知识越全面
HumanEval	代码生成（164 道编程题）	"编程面试成绩"，程序员最关心这个
SWE-bench	真实 GitHub Issue 修复	"实际工作能力"，比 HumanEval 更贴近真实开发
GSM8K	小学数学应用题	基础推理能力，大部分模型都能到 90%+
MATH	竞赛级数学	高级推理能力，区分度高
Arena Elo	人类偏好排名	"综合满意度"，最接近真实用户体验

工程师最应该关注的指标：

选代码助手 → 看 SWE-bench + HumanEval
选通用对话 → 看 Arena Elo
选中文场景 → 看 SuperCLUE
选部署方案 → 看延迟 / 吞吐量 / 每百万 Token 价格

如何看待评测分数

评测分数 ≠ 实际体验

训练集污染：模型可能在训练时"见过"评测题，分数虚高
任务选择偏差：榜单只测特定题型，不代表所有场景
版本差异：API 版本和开源版本性能可能不同
最佳实践：用你自己的业务数据做 A/B 测试，才是最可靠的选型依据

1.6 2026 年主流模型全景图

模型迭代很快，这里给出 2026 年的主流格局，帮你快速了解"都有谁、谁擅长什么"。

闭源第一梯队

模型	厂商	核心优势	推荐场景
GPT-5.4	OpenAI	全能型，原生 Computer Use	Agentic 任务、通用对话
Claude Opus 4.6 / Sonnet 4.6	Anthropic	代码与深度推理王者，极低幻觉率	代码审查、复杂推理、长文档分析
Gemini 3.1 Pro	Google	多模态综合第一，2M tokens 上下文	多模态场景、超长文档

开源标杆

模型	核心优势	推荐场景
DeepSeek V3.2 / R1	性价比之王（$0.02/M token），代码+数理突出	日常开发、成本敏感场景
Qwen 3.5	中文理解第一，开源可商用	中文业务、国产化要求
Llama 4	社区生态最完善	需要社区支持的二次开发
智谱 GLM-5	综合均衡	全能型国产选择

国产新势力

模型	特色
Kimi K2.5	长文本办公场景，月之暗面出品
MiniMax M2.7	多模态交互
字节豆包 2.0	轻量化交互
文心一言 5.0	百度生态联动

API 聚合平台

一个 API Key 调多家模型——适合快速验证和对比不同模型。

平台	特色	适用场景
OpenRouter	海外模型一站式接入，统一 API 格式	想用多家模型又不想管多个账号
硅基流动（SiliconFlow）	国内低价聚合，DeepSeek/Qwen 一键调用	国内开发者首选
火山引擎	字节官方渠道	内部同学可关注

1.7 微调、本地部署与算力基础

这一节是"开眼界"定位，讲概念不讲操作。

模型微调（Fine-tuning）

什么时候需要微调？ 当 Prompt 工程搞不定时才考虑：

Prompt 能搞定的：
  ✅ "用更礼貌的语气回复" → 改 System Prompt
  ✅ "输出 JSON 格式" → 用 Structured Output
  ✅ "参考这些资料回答" → 用 RAG

Prompt 搞不定，需要微调的：
  ❌ "像我们团队的文档风格一样写" → 风格一致性
  ❌ "准确使用我们行业的专业术语" → 领域术语
  ❌ "严格按照这个复杂格式输出" → 格式严格控制
  ❌ "推理速度要更快" → 蒸馏小模型

微调方式对比：

方式	训练参数量	显存需求	效果	适用
全量微调	全部参数	极高（几十GB~几百GB）	最好	大公司、大预算
LoRA	<1% 参数	中等	接近全量	大多数场景推荐
QLoRA	<1% 参数	低（4-bit 量化）	略低于 LoRA	显存受限时

核心经验：数据质量 > 数据数量。几百条高质量标注数据的效果，往往好过几万条噪音数据。

本地部署与推理

为什么要本地部署：数据隐私（不出内网）、离线可用、成本可控（高频调用时）、延迟敏感（内网 < 公网）。

Ollama——一行命令跑本地模型：

bash

# 安装 Ollama（macOS）
brew install ollama

# 下载并运行 DeepSeek（7B 参数，约 4GB 显存）
ollama run deepseek-r1:7b

# 之后就可以像 ChatGPT 一样对话了
>>> 用 Go 写一个 HTTP 服务器

模型量化——用精度换速度：

FP16（半精度）→ INT8（8-bit）→ INT4（4-bit）

7B 模型显存需求：
  FP16:  ~14 GB
  INT8:  ~7 GB
  INT4:  ~4 GB  ← MacBook Pro (M2, 16GB) 能跑

精度损失：
  FP16 → INT8: 几乎无损
  FP16 → INT4: 轻微损失，日常使用足够

GPU 与算力概念

GPU 型号	显存	定位	能跑什么模型
RTX 4090	24 GB	消费级旗舰	7B~13B（量化后 30B）
A100	40/80 GB	数据中心主力	70B（单卡）
H100	80 GB	最新主力	70B+（训练和推理）
Apple M2/M3/M4	共享内存 16~192 GB	Mac 用户	7B~13B（统一内存优势）

前端同学的 Mac 能不能跑模型？

能！Apple Silicon 的统一内存架构意味着 16GB 内存的 MacBook Pro 可以跑 7B 量化模型。用 Ollama 体验非常流畅，适合本地开发和快速验证。推理速度约 10-30 TPS（看模型大小），日常使用完全够。

什么时候该用什么方案

                API 调用                    本地部署                   微调
              ┌──────────┐              ┌──────────┐              ┌──────────┐
难度:          │   最简单   │              │   中等    │              │   最复杂   │
成本:          │ 按量付费   │              │ 硬件投入   │              │ 数据+算力  │
适用:          │ 大多数场景  │              │ 隐私/离线  │              │ 特定任务   │
              └──────────┘              └──────────┘              └──────────┘
                  ↓                          ↓                        ↓
            快速验证和上线              数据不能出网/高频调用          通用模型效果不够好
              日常开发                    降低 API 成本                风格/术语/格式
                                                                    需要高度定制化

决策路径：先 API → 不满足再本地部署 → 再不满足才微调

1.8 Embedding 与 RAG 基础

这一节是正式知识点，建立对 RAG 的基础认知。第三篇会深入展开。

引子：为什么 ChatGPT 答不了你公司的问题

你："我们内部的 XX 服务怎么部署？"
ChatGPT："抱歉，我没有关于贵公司 XX 服务的信息..."

为什么？因为：
1. 模型训练数据截止到某个日期，没有最新信息
2. 你的内部文档不在互联网上，模型从没见过
3. 即使你把文档丢进对话框，如果太长也超出上下文窗口

解决方案就是 RAG（Retrieval-Augmented Generation，检索增强生成）。

Embedding 是什么："把文字变成坐标"

文本                              向量（数字列表）
"React 性能优化"        →    [0.12, -0.34, 0.56, ..., 0.78]  (1536维)
"前端渲染速度提升"       →    [0.11, -0.32, 0.58, ..., 0.75]  (1536维)
"Go 微服务架构"         →    [-0.45, 0.23, -0.12, ..., 0.34]  (1536维)

计算相似度（余弦相似度）：
  "React性能优化" vs "前端渲染速度提升" = 0.92（非常相似！）
  "React性能优化" vs "Go微服务架构"    = 0.23（不太相关）

Embedding 的本质：把文字的语义编码成数学向量，语义越接近的文本，在向量空间中的距离越近。这就是"语义搜索"的基础——不是匹配关键词，而是匹配意思。

向量数据库："语义搜索的引擎"

当你有百万条文档的 Embedding 向量，需要快速找到"和用户问题最相似的 5 条"——这就需要向量数据库。

用户问题: "怎么解决 React 列表渲染卡顿？"
          ↓ Embedding
    [0.15, -0.28, 0.61, ...]
          ↓ 向量数据库检索（毫秒级）
    Top 1: "React 虚拟列表优化方案" (相似度 0.94)
    Top 2: "React.memo 避免不必要渲染" (相似度 0.89)
    Top 3: "React useMemo/useCallback 实践" (相似度 0.85)

常见向量数据库：ChromaDB（轻量级）、Qdrant（高性能）、Milvus（分布式）、pgvector（PostgreSQL 插件）。

RAG：让 AI "开卷考试"

RAG 的完整流程：

离线阶段（建索引）：
  公司文档 → 分块（每段500字）→ Embedding向量化 → 存入向量数据库
  ┌────┐    ┌─────┐    ┌──────────┐    ┌────────┐
  │ PDF │ →  │chunk1│ →  │[0.1,0.3,]│ →  │        │
  │ MD  │    │chunk2│    │[0.2,0.5,]│    │ 向量DB  │
  │ Doc │    │chunk3│    │[0.4,0.1,]│    │        │
  └────┘    └─────┘    └──────────┘    └────────┘

在线阶段（回答问题）：
  用户提问 → Embedding → 向量检索 Top-K → 拼入 Prompt → LLM 生成回答
  ┌──────┐    ┌────┐    ┌────────┐    ┌─────────────┐    ┌──────┐
  │用户问题│ →  │向量│ →  │相关chunk │ →  │System Prompt │ →  │ 回答  │
  │       │    │    │    │chunk2   │    │+ 检索结果    │    │+引用  │
  │       │    │    │    │chunk5   │    │+ 用户问题    │    │      │
  └──────┘    └────┘    └────────┘    └─────────────┘    └──────┘

RAG vs 微调

维度	RAG（开卷考试）	微调（考前突击）
类比	带着参考书去考试	考试前把知识背到脑子里
知识更新	更新文档即可，立即生效	需要重新训练模型
成本	向量数据库 + 检索成本	训练成本（GPU 时间）
准确性	答案有引用来源，可追溯	可能产生幻觉
适用场景	知识库问答、最新信息查询	风格调整、特定任务优化
推荐	⭐ 大多数场景优先选 RAG	作为补充手段

应用场景

知识库问答：内部技术文档 → "XX 服务怎么部署？"
智能客服：产品帮助文档 → "怎么重置密码？"
文档搜索：法律法规/合同条款 → "关于数据隐私的条款有哪些？"
代码检索：代码仓库 → "哪里处理了用户认证逻辑？"

只要涉及"让 AI 基于私有数据回答问题"——都是 RAG 的用武之地。

1.9 公司内部 AI 平台

这一节需要根据公司实际情况填充，以下是通用框架。

内部平台概览

维度	说明
平台定位	公司统一的 AI 能力中台，封装了模型调用、内容安全、成本管控
核心优势	免翻墙、免申请海外 API Key、数据合规、内部计费
vs 直接调外部 API	多了一层封装，但省去了合规审批、Key 管理、安全审计

可用模型

模型类型	示例	能力
自研模型	豆包系列	通用对话、轻量化场景
第三方接入	GPT-4o / Claude / DeepSeek	复杂推理、代码生成
专项模型	翻译 / OCR / 语音	特定任务

如何接入

1. 申请流程：内部工单系统 → 部门审批 → 获取 API Key
2. 调用方式：
   - HTTP REST API（通用）
   - Python SDK / Node.js SDK
   - 兼容 OpenAI 格式（大多数平台都提供兼容层）
3. 文档入口：[内部文档平台链接]

平台特色能力

Prompt 管理与调试工具：在线编辑、版本管理、效果对比
知识库 / RAG 能力：部分平台内置向量检索，上传文档即用
应用编排：低代码/可视化搭建 AI 应用（类似 Dify / Coze）
内容安全：内置合规审核，敏感词过滤

使用限制与计费

QPS 限制：根据申请级别不同
Token 配额：部门预算制
审批流程：涉及敏感数据需额外审批

1.10 模型选型实战指南

按场景选模型

场景	推荐模型	原因
通用对话	GPT-4o / Claude Sonnet	综合能力强，响应快
编程辅助	Claude Opus / DeepSeek R1	代码理解和生成能力顶尖
数学推理	DeepSeek R1 / Claude Opus	推理链完整，准确率高
多模态	Gemini Pro / GPT-4o	图片/视频理解
超长文档	Gemini Pro (2M) / Claude (200K)	超大上下文窗口
中文业务	Qwen 3.5 / DeepSeek V3	中文理解更准确

按成本选模型

价格从高到低（每百万输入 Token）：

$30+   │ Claude Opus 4.6
$15    │ GPT-5.4
$3     │ GPT-4o / Claude Sonnet
$0.5   │ GPT-4o-mini / Claude Haiku
$0.27  │ DeepSeek V3
$0.14  │ DeepSeek V3（硅基流动）
$0     │ Ollama 本地部署（只需硬件）

策略：简单任务用便宜模型，复杂任务用强模型

团队落地建议

前端（React + Node.js）：

typescript

// 推荐：Vercel AI SDK（前端友好，SSE 开箱即用）
import { streamText } from 'ai'
import { openai } from '@ai-sdk/openai'

const result = streamText({
  model: openai('gpt-4o'),
  prompt: 'Hello',
})

// 或者直接用 OpenAI SDK
import OpenAI from 'openai'
const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY })

后端（Go）：

// 推荐：直接 HTTP 调用（Go 生态的 LLM SDK 不如 Python 成熟）
// 或使用 sashabaranov/go-openai
import openai "github.com/sashabaranov/go-openai"

client := openai.NewClient("your-api-key")
resp, err := client.CreateChatCompletion(
    context.Background(),
    openai.ChatCompletionRequest{
        Model: openai.GPT4o,
        Messages: []openai.ChatCompletionMessage{
            {Role: openai.ChatMessageRoleUser, Content: "Hello"},
        },
    },
)

决策流程图

需要 AI 能力？
    ├── 快速验证/Demo → 直接用 API（GPT-4o / DeepSeek）
    ├── 正式项目？
    │   ├── 数据能出网？
    │   │   ├── 是 → 闭源 API（GPT/Claude）or 开源 API（DeepSeek/硅基流动）
    │   │   └── 否 → 本地部署（Ollama + 开源模型）or 内部平台
    │   ├── 效果不够好？
    │   │   ├── 知识缺失 → RAG（第三篇深入讲）
    │   │   └── 风格/格式问题 → 微调（LoRA）
    │   └── 成本太高？
    │       ├── 换便宜模型（GPT-4o-mini / DeepSeek）
    │       ├── Prompt Caching
    │       └── 模型分级路由
    └── 团队协作 → 统一 LLM 调用层 + Prompt 管理

1.11 实战：本地部署 Whisper 实现视频转文章

用一个小项目串联第一篇的知识点。

项目目标

输入：一个视频文件（会议录像、技术分享等）输出：一篇结构清晰、排版整洁的文章

完整流程

视频文件                    音频文件                  原始转写文本             结构化文章
┌──────┐   FFmpeg提取   ┌──────┐   Whisper转写   ┌──────────┐   LLM整理   ┌──────────┐
│ .mp4  │  ────────→   │ .wav  │  ────────→    │ 口语化文本 │  ────────→ │ 结构化文章 │
│ .mov  │              │ .mp3  │               │ 有错别字   │            │ 标题+段落  │
└──────┘              └──────┘               └──────────┘            └──────────┘
                        本地运行                 本地运行                  API调用

Whisper 模型简介

Whisper 是 OpenAI 于 2022 年开源的语音识别模型，支持 99 种语言的语音转文字，完全免费、本地运行。

模型尺寸选择：

模型	参数量	显存需求	速度（相对）	准确率
tiny	39M	~1 GB	最快（32x）	一般
base	74M	~1 GB	快（16x）	还行
small	244M	~2 GB	中（6x）	不错
medium	769M	~5 GB	慢（2x）	很好
large-v3	1.55B	~10 GB	最慢（1x）	最好

安装与运行

bash

# 安装 Whisper（需要 Python 环境）
pip install openai-whisper

# 安装 FFmpeg（音视频处理）
brew install ffmpeg

# Step 1：从视频提取音频
ffmpeg -i meeting.mp4 -vn -acodec pcm_s16le -ar 16000 meeting.wav

# Step 2：Whisper 转写
whisper meeting.wav --model medium --language Chinese --output_format txt

# 输出：meeting.txt（原始转写文本）

LLM 整理成结构化文章

python

import openai

with open("meeting.txt", "r") as f:
    raw_text = f.read()

# 如果文本太长（超过上下文窗口），需要分段处理
MAX_CHARS = 12000  # 约 8000 Token

if len(raw_text) > MAX_CHARS:
    chunks = [raw_text[i:i+MAX_CHARS] for i in range(0, len(raw_text), MAX_CHARS)]
else:
    chunks = [raw_text]

articles = []
for i, chunk in enumerate(chunks):
    response = openai.chat.completions.create(
        model="deepseek-chat",  # 用 DeepSeek 省钱
        messages=[
            {
                "role": "system",
                "content": """你是一个专业的内容编辑。请将以下口语化的会议转写文本整理成结构清晰的书面文章。
要求：
1. 添加合适的标题和小标题
2. 修正口语表达为书面语
3. 去除重复内容和语气词（"嗯"、"然后"、"就是说"）
4. 保留所有关键信息和技术细节
5. 输出 Markdown 格式"""
            },
            {"role": "user", "content": f"第 {i+1} 部分转写文本：\n\n{chunk}"}
        ],
        temperature=0.3  # 低 temperature，保持忠实原文
    )
    articles.append(response.choices[0].message.content)

final_article = "\n\n".join(articles)
with open("article.md", "w") as f:
    f.write(final_article)

print("文章生成完成！")

串联回顾

这个小项目串联了第一篇的哪些知识点？

知识点	在项目中的体现
1.1 什么是 LLM	Whisper（语音模型）和 GPT/DeepSeek（语言模型）都是 AI 模型
1.2 Token	LLM 整理文章时需要估算 Token 数，超长文本需要分段处理
1.2 Temperature	设为 0.3，保持忠实原文（不需要创意发挥）
1.4 Streaming	可以加上流式输出，让用户看到文章逐步生成
1.6 模型选型	用 DeepSeek 替代 GPT-4o，效果接近但成本低 10 倍
1.7 本地部署	Whisper 完全本地运行，不需要联网，数据不出内网
1.7 模型大小选择	medium vs large-v3 的精度/速度权衡

总结

第一篇到这里就结束了。回顾一下我们建立的认知框架：

✅ 是什么（1.1~1.2）：LLM 的本质、核心概念
✅ 热门词汇（1.3）：Vibe Coding、MCP、Context Engineering...
✅ 怎么用（1.4）：JSON Mode、Function Calling、Streaming、Rate Limit
✅ 怎么选（1.5~1.6）：评测榜单、主流模型全景
✅ 怎么部署（1.7）：微调、本地部署、GPU 基础
✅ RAG 基础（1.8）：Embedding、向量数据库、RAG 流程
✅ 团队落地（1.9~1.10）：内部平台、选型指南
✅ 动手做（1.11）：Whisper 视频转文章实战

下一篇预告：第二篇：AI 开发工具链与 Agent 入门——从框架选型到 Prompt Engineering，从 Agent 设计模式到 MCP/Tool/Skills，最后实现一个 Mini-OpenClaw。

第一篇：大模型全景——从核心概念到本地实战 ​

1.1 什么是大语言模型（LLM） ​

开场：一个真实的效率革命 ​

从 NLP 到 LLM 的演进脉络 ​

Transformer 为什么重要 ​

三阶段训练范式：预训练 + 微调 + RLHF ​

闭源 vs 开源的本质区别 ​

1.2 核心概念 ​

Token：计费的基本单位 ​

Context Window（上下文窗口）：你能塞多少资料 ​

Temperature / Top-P：控制创造力的"旋钮" ​

System Prompt / User Prompt / Assistant：对话角色 ​

幻觉（Hallucination）："一本正经地胡说八道" ​

多模态输入：不只是文字 ​

1.3 当下 AI 热门概念速览 ​

AI 编程范式 ​

AI 编程工具 ​

协议与标准 ​

工程方法论的演进 ​

1.4 开发实战中的关键机制 ​

JSON Mode / Structured Output ​

Function Calling / Tool Use ​

流式输出（Streaming） ​

Rate Limit 与错误处理 ​

上下文窗口 ≠ 有效利用长度 ​

缓存与成本优化 ​

1.5 评测榜单与核心指标 ​

主流评测榜单 ​

核心指标解读 ​

如何看待评测分数 ​

1.6 2026 年主流模型全景图 ​

闭源第一梯队 ​

开源标杆 ​

国产新势力 ​

API 聚合平台 ​

1.7 微调、本地部署与算力基础 ​

模型微调（Fine-tuning） ​

本地部署与推理 ​

GPU 与算力概念 ​

什么时候该用什么方案 ​

1.8 Embedding 与 RAG 基础 ​

引子：为什么 ChatGPT 答不了你公司的问题 ​

Embedding 是什么："把文字变成坐标" ​

向量数据库："语义搜索的引擎" ​

RAG：让 AI "开卷考试" ​

RAG vs 微调 ​

应用场景 ​

1.9 公司内部 AI 平台 ​

内部平台概览 ​

可用模型 ​

如何接入 ​

平台特色能力 ​

使用限制与计费 ​

1.10 模型选型实战指南 ​

按场景选模型 ​

按成本选模型 ​

团队落地建议 ​

决策流程图 ​

1.11 实战：本地部署 Whisper 实现视频转文章 ​

项目目标 ​

完整流程 ​

Whisper 模型简介 ​

安装与运行 ​

LLM 整理成结构化文章 ​

串联回顾 ​

总结 ​

第一篇：大模型全景——从核心概念到本地实战

1.1 什么是大语言模型（LLM）

开场：一个真实的效率革命

从 NLP 到 LLM 的演进脉络

Transformer 为什么重要

三阶段训练范式：预训练 + 微调 + RLHF

闭源 vs 开源的本质区别

1.2 核心概念

Token：计费的基本单位

Context Window（上下文窗口）：你能塞多少资料

Temperature / Top-P：控制创造力的"旋钮"

System Prompt / User Prompt / Assistant：对话角色

幻觉（Hallucination）："一本正经地胡说八道"

多模态输入：不只是文字

1.3 当下 AI 热门概念速览

AI 编程范式

AI 编程工具

协议与标准

工程方法论的演进

1.4 开发实战中的关键机制

JSON Mode / Structured Output

Function Calling / Tool Use

流式输出（Streaming）

Rate Limit 与错误处理

上下文窗口 ≠ 有效利用长度

缓存与成本优化

1.5 评测榜单与核心指标

主流评测榜单

核心指标解读

如何看待评测分数

1.6 2026 年主流模型全景图

闭源第一梯队

开源标杆

国产新势力

API 聚合平台

1.7 微调、本地部署与算力基础

模型微调（Fine-tuning）

本地部署与推理

GPU 与算力概念

什么时候该用什么方案

1.8 Embedding 与 RAG 基础

引子：为什么 ChatGPT 答不了你公司的问题

Embedding 是什么："把文字变成坐标"

向量数据库："语义搜索的引擎"

RAG：让 AI "开卷考试"

RAG vs 微调

应用场景

1.9 公司内部 AI 平台

内部平台概览

可用模型

如何接入

平台特色能力

使用限制与计费

1.10 模型选型实战指南

按场景选模型

按成本选模型

团队落地建议

决策流程图

1.11 实战：本地部署 Whisper 实现视频转文章

项目目标

完整流程

Whisper 模型简介

安装与运行

LLM 整理成结构化文章

串联回顾

总结