LLM Token/上下文窗口/Embedding
2.1 什么是 Token？
Token 是大语言模型处理文本的最小基本单位。模型不直接识别原始字符，而是先将文本切分成一个个 Token，再进行后续的处理与理解。
中文示例：
“我喜欢吃苹果” → ["我", "喜欢", "吃", "苹果"]（共4个Token）
英文示例：
“ChatGPT” → 可能被拆成 ["Chat", "G", "PT"]（共3个Token）
“Hello world” → ["Hello", " world"]（共2个Token）
2.2 Token 的重要影响
| 维度 | 说明 |
|---|---|
| 计费单位 | 几乎所有大模型API都按Token收费，是AI世界的“流量货币” |
| 能力边界 | 模型的上下文窗口以Token数量衡量 |
| 效率指标 | 模型处理速度通常表示为“每秒生成多少个Token” |
| 中英文差异 | 中文：1 Token ≈ 1.5~1.8汉字；英文：1 Token ≈ 0.75单词 |
2.3 Token 的产生过程
原始文本 → 分词器(Tokenizer) → Token序列 → Token ID → 模型输入
分词器使用BPE、WordPiece等算法，将文本“切碎”成词表中最匹配的语义片段，确保模型能准确识别和处理。
三、上下文窗口—— AI 的“记忆容量”
3.1 什么是上下文窗口？
上下文窗口是大语言模型在单次推理中，能够“记住”和“关注”的最大Token数量，涵盖用户的输入、模型的输出，以及两者之间的所有对话历史。
通俗理解：AI的短期记忆容量，记忆的“长度”由Token数量决定。
3.2 上下文窗口的重要性
| 场景 | 小窗口的局限 | 大窗口的优势 |
|---|---|---|
| 长文档处理 | 需要分段处理，易丢失关键信息 | 一次读完整本书/整篇论文，无需拆分 |
| 多轮对话 | 聊久了会忘记早期对话内容，上下文断裂 | 保持完整对话连贯性，不遗漏历史信息 |
| 代码分析 | 只能查看单个文件，无法关联上下文 | 可分析整个代码仓库，理解文件间关联 |
实际例子：Claude Opus 4.7 支持 1M Token 上下文，可一次性处理约55万字的材料（相当于一本长篇小说）。
3.3 上下文窗口的演进
| 时间 | 代表模型 | 窗口大小 | 说明 |
|---|---|---|---|
| 2018-2019 | BERT, GPT-1 | 512-1024 | 早期模型，窗口极小，仅能处理短句或片段 |
| 2020-2022 | GPT-3 | 2048-4096 | 可处理短文章、简单对话，满足基础需求 |
| 2023 | GPT-4, Claude 2 | 8K-128K | 可处理中等长度文档、多轮长对话，适配专业场景 |
| 2024-2026 | DeepSeek, Gemini | 1M-10M | 可处理整套三部曲书籍、大型代码仓库，能力大幅提升 |
3.4 上下文窗口的局限
- 成本随长度增加：计算复杂度为O(n²)，长文本的推理成本会显著上升，调用费用更高。
- “中间丢失”现象：在极长上下文中，模型对文本中间部分的信息召回率会下降，容易忽略关键内容。
- 并非越大越好：日常简单任务（如短句问答、简单文案）不需要超大窗口，过大窗口会造成资源浪费，降低处理效率。
五、Embedding（嵌入）—— 文字的“数字指纹”
4.1 什么是 Embedding？
模型无法直接理解文字，处理文本时，需要先将Token转换成数字向量——这就是Embedding。每个词（或Token）会被映射成高维空间中的一个坐标点，核心特点是：语义相近的词，在空间中的距离更近。
直观理解：
“国王” → [0.2, 0.8, -0.3, ...]
“女王” → [0.25, 0.75, -0.28, ...]（语义相似，空间距离近）
“苹果” → [-0.1, 0.3, 0.9, ...]（语义不同，空间距离远）
4.2 Token → Embedding 的转换流程
Token → Token ID → 查Embedding表 → 向量序列 → 模型输入
通俗类比：你说话（文字）→ 翻译成摩斯电码（Token ID）→ 查密码本（Embedding表）→ 变成模型能计算的数学向量（数学题）。