传统模型：
知识 → 训练 → 参数 → 推理 → 答案
（知识固化在参数里，更新成本高）

RAG：
知识 → 索引 → 向量库 → 检索 → 推理 → 答案
（知识和模型解耦，更新成本低）

"猫" → (0.2, 0.8, 0.1)
"狗" → (0.3, 0.7, 0.2)    ← 和"猫"很近，都是宠物
"汽车" → (0.9, 0.1, 0.3)  ← 和"猫"很远，不同类别

相似对：
("如何重置密码", "密码重置方法")
("API 超时设置", "配置 API 超时时间")

不相似对：
("如何重置密码", "API 超时设置")
("密码重置方法", "今天天气怎么样")

L = -log( exp(sim(q, p+)/τ) / Σexp(sim(q, pi)/τ) )

其中：
- q 是 query 的向量
- p+ 是正样本的向量
- pi 是所有样本（包括正样本和负样本）
- sim 是相似度函数（如余弦相似度）
- τ 是温度参数

cosine(a, b) = (a · b) / (||a|| × ||b||)

其中：
- a · b 是向量点积
- ||a|| 是向量的模长

结果范围：[-1, 1]，越大越相似

单次检索计算量：
100万 × 1024 = 10亿次浮点运算

耗时估算：
单核 CPU ≈ 100-500ms
GPU ≈ 10-50ms

第 0 层：所有节点
第 1 层：部分节点（概率选取）
第 2 层：更少的节点
...

搜索时：
从最高层开始，快速跳到目标区域附近
逐层下降，越来越精确
最后在第 0 层找到最近邻

离线阶段：
1. 用 K-means 聚类，找到 K 个中心点
2. 把每个向量分配到最近的中心点
3. 每个中心点维护一个列表（倒排表）

在线检索：
1. 找到离 query 最近的几个中心点
2. 只在这几个中心点的倒排表里搜索
3. 不用遍历所有向量

原始向量：1024 维浮点数 = 4096 字节

压缩方法：
1. 把 1024 维分成 8 组，每组 128 维
2. 每组用 K-means 聚类，生成 256 个中心点
3. 每个向量每组只需 1 字节（存储中心点编号）

压缩后：8 字节
压缩比：512 倍

文档："错误码 401 表示认证失败"
用户问："401 是什么意思"

向量检索可能召回：
"常见错误码及解决方案"（语义相似）
"权限问题排查"（语义相似）

而不是精确包含 "401" 的那段。

文档："JSON Web Token 的有效期默认为 1 小时"
用户问："JWT 的有效期"

向量检索：可能召回，也可能不召回，取决于模型是否学过 JWT = JSON Web Token

文档："v2.3.1 版本新增了批量导出功能"
用户问："v2.3.0 有什么新功能"

向量检索：可能召回 v2.3.1 或 v2.3.2 的内容，因为"版本更新"语义相似

候选集 = 向量检索（语义） + 关键词检索（字面） + 元数据过滤（业务规则）

┌─────────────────────────────────────────────────────────────────┐
│  阶段 1：索引（Indexing）                                        │
│                                                                 │
│  文档 → 解析 → 切分 → Embedding → 写入向量库                      │
│                                                                 │
│  核心问题：怎么切分才能让每个 chunk 成为独立的证据？                 │
└────────────────────────┬────────────────────────────────────────┘
                         ▼
┌─────────────────────────────────────────────────────────────────┐
│  阶段 2：检索（Retrieval）                                       │
│                                                                 │
│  Query → Embedding → 向量检索 → 关键词检索 → 融合 → Rerank        │
│                                                                 │
│  核心问题：怎么召回相关内容，同时减少噪声？                          │
└────────────────────────┬────────────────────────────────────────┘
                         ▼
┌─────────────────────────────────────────────────────────────────┐
│  阶段 3：生成（Generation）                                      │
│                                                                 │
│  Query + Chunks → Prompt 组装 → LLM → 答案 + 引用                 │
│                                                                 │
│  核心问题：怎么让模型严格依据证据回答，不自由发挥？                   │
└─────────────────────────────────────────────────────────────────┘

原始文档：
### 2.3 校准流程
将旋钮调至 3 档，等待指示灯变为绿色。

按段落切分后，chunk 变成：
"将旋钮调至 3 档，等待指示灯变为绿色。"

问题：用户问"ZK-200 怎么校准"，这个 chunk 不会召回，因为：
- 没有"ZK-200"（在文档标题里）
- 没有"校准"（在章节标题里）

补充上下文后：
"【ZK-200 操作手册 > 2.3 校准流程】
将旋钮调至 3 档，等待指示灯变为绿色。"

{
  "id": "唯一标识",
  "content": "文本内容",
  "document_id": "所属文档",
  "source": "知识库来源",
  "title": "文档标题",
  "section": "章节路径",
  "chunk_index": "在文档中的位置",
  "created_at": "创建时间"
}

用户问："销售合同模板在哪下载？"

不过滤：
搜索范围 = 所有文档（产品、研发、销售、HR...）
结果可能混入研发部门的合同管理规范

按 department="sales" 过滤：
搜索范围 = 销售部门文档
结果更精准

参考资料：{chunks}
问题：{query}
请回答：

你是一个文档助手。请根据以下参考资料回答问题。

要求：
1. 答案必须基于参考资料，不要编造
2. 如果参考资料中没有答案，请直接说"根据现有资料无法回答"
3. 回答时标注引用来源，格式：[来源: 文档名 > 章节]

参考资料：
{chunks}

问题：{query}

请回答：

答案："API 的超时时间默认为 30 秒 [来源: API 规范 > 3.2 超时配置]"

微调：
- 让模型学会输出 JSON 格式
- 让模型学会引用来源
- 让模型学会说"不知道"

RAG：
- 提供最新的业务知识
- 提供可追溯的证据
- 提供领域专业信息

□ 能回答核心问题吗？
  └── 准备 20 个关键问题，正确率 > 70%

□ 能解释答案来源吗？
  └── 每个答案都有引用，用户能追溯

□ 答案错了能定位吗？
  └── 有 Inspect 页面，能看到检索结果

□ 知道下一步优化什么吗？
  └── 有评测指标，知道哪类问题表现差

□ 文档更新后能同步吗？
  └── 有增量更新机制，不是全量重建