From 091387cc4ae80c8a56ba7f5361e9c888740b5f7f Mon Sep 17 00:00:00 2001
From: shbone <598924626@qq.com>
Date: Wed, 24 Jan 2024 01:15:07 +0800
Subject: [PATCH] Revert "update"
This reverts commit e827f40a2c1280c01fad1eb6496dee377c6840b2, reversing
changes made to 8c630ca27bb43d8f1f9ac1ea27862dbb7e5f0d94.
---
README.md | 2 +-
src/zh/posts/README.md | 8 -
src/zh/posts/eval/M3KE.md | 1 +
.../{reasoning => prompt}/MathPrompter.md | 296 ++++++++---------
src/zh/posts/{reasoning => prompt}/SoT.md | 298 +++++++++---------
5 files changed, 299 insertions(+), 306 deletions(-)
rename src/zh/posts/{reasoning => prompt}/MathPrompter.md (98%)
rename src/zh/posts/{reasoning => prompt}/SoT.md (98%)
diff --git a/README.md b/README.md
index 5d1aec669..378e9708b 100644
--- a/README.md
+++ b/README.md
@@ -13,7 +13,7 @@
`category` 请从以下类别中选择
-- 检索增强生成(`RAG`)
+- 检索增强生成RAG
- 语言模型(`LLM`)
- 提示技术(`Prompt`)
- 微调技术(`Finetune`)
diff --git a/src/zh/posts/README.md b/src/zh/posts/README.md
index fdf0e8c1c..7258471da 100644
--- a/src/zh/posts/README.md
+++ b/src/zh/posts/README.md
@@ -9,19 +9,11 @@ article: false
本页面包含一些论文分享的分类：
-<<<<<<< HEAD
-- [检索增强生成(RAG)](./rag/)
-=======
- [检索增强生成RAG](./rag/)
->>>>>>> 8c630ca27bb43d8f1f9ac1ea27862dbb7e5f0d94
- [语言模型](./llm/)
- [提示技术](./prompt/)
- [微调技术](./finetune/)
- [评估方法](./eval/)
- [数据集](./dataset/)
- [大模型推理](./reasoning/)
-<<<<<<< HEAD
- [Token、分词](./token/)
-=======
-- [Token、分词](./token/)
->>>>>>> 8c630ca27bb43d8f1f9ac1ea27862dbb7e5f0d94
diff --git a/src/zh/posts/eval/M3KE.md b/src/zh/posts/eval/M3KE.md
index 067c4266a..84f6fdeb7 100644
--- a/src/zh/posts/eval/M3KE.md
+++ b/src/zh/posts/eval/M3KE.md
@@ -61,3 +61,4 @@ M3KE 收集了 20,477 个真人标准化考试题目（包含 4 个候选答案
（2）大部分经过微调后的中文大模型仅达到随机结果（25%）水平，即使在小学阶段的测试中（Table 6&7）。这说明较低教育阶段中的知识仍然是当前中文大模型的短板之一。
（3）在零样本评估中，BELLE-7B-2M 取得了中文大模型中最好的成绩，但仍然与 GPT-3.5-turbo 有 14.8% 的差距。此外，有监督微调指令的数量也是一个重要的因素，经过两百万指令微调的 BELLE-7B-2M 好于经过二十万指令微调的 BELLE-7B-0.2M（Table 4）。
+
diff --git a/src/zh/posts/reasoning/MathPrompter.md b/src/zh/posts/prompt/MathPrompter.md
similarity index 98%
rename from src/zh/posts/reasoning/MathPrompter.md
rename to src/zh/posts/prompt/MathPrompter.md
index ebfb64053..74c725308 100644
--- a/src/zh/posts/reasoning/MathPrompter.md
+++ b/src/zh/posts/prompt/MathPrompter.md
@@ -1,148 +1,148 @@
----
-author: lx
-icon: wand-magic-sparkles
-date: 2023-03-30
-shortTitle: "MathPrompter: 数学推理"
-category:
- - 提示技术
-tag:
- - 推理
- - LLM
- - CoT
----
-
-# MathPrompter: 数学推理
-
-[该文](https://mp.weixin.qq.com/s/DUS4pc7izs9CS3Pmz3WMxg)介绍了 `MathPrompter: 数学推理` 框架，解决需要多步推理的复杂数学问题。
-
-
-
-
-
-> 论文要解决的问题
-
-（1）数学问题通常只有一个正确答案，对于一个需要**多步推理**的复杂数学问题，语言模型通常都无法给出正确答案，即便有「思维链」技术的加持，往往**中间步骤也会出错**。
-（2）并且，在数学问题上，现有的语言模型通常不会对自己的答案**提供置信度**（`confidence`），让用户无从判断生成答案的可信度。
-
-> 采用方法
-
-（1）`MathPrompter` 使用 `Zero-shot` 思维链提示技术生成多个**代数表达式**或 **`Python` 函数**，以不同方式解决同一个数学问题，从而提高输出结果的可信度。
-（2）相比其他基于提示的 `CoT` 方法，`MathPrompter` 还会检查中间步骤的有效性。
-
-> 结果
-
-基于 `175B` 参数 `GPT`，使用 `MathPrompter` 方法将`MultiArith` 数据集的准确率从 `78.7%` 提升到了 `92.5%`。
-
----
-
-## 1 专攻数学的Prompt
-
-最近自然语言处理的发展很大程度上归功于大型语言模型（LLMs）在规模上的不断扩展，其展现出了惊人的 `zero-shot` 和 `few-shot` 能力，也促成了 `prompting` 技术的发展，用户只需要在 `prompt`中给 `LLM` 输入几个简单的样例即可对新任务进行预测。`prompt` 对于**单步**的任务相当成功，但在需要**多步骤推理**的任务中，提示技术的性能仍然不够。
-
-人类在解决一个复杂问题时，会将其进行**分解**，并尝试一步步地解决，思维链（CoT）提示技术就是将这种直觉扩展到 `LLMs` 中，在一系列需要推理的NLP任务中都得到了性能改进。
-
-本篇论文主要研究用于解决数学推理任务的 `Zero-shot-CoT` 方法，之前的工作已经在 `MultiArith` 数据集上得到了显著的准确率改进，从 $17.7\%$ 提升到了 $78.7\%$，但仍然存在两个关键的不足之处：
-（1）虽然模型所遵循的思维链改进了结果，但却没有检查思维链提示所遵循的每个步骤的有效性；
-（2）没有对LLM预测结果提供置信度（`confidence`）。
-
-
-## 2 MathPrompter
-
-为了在一定程度上解决上述差距，从人类解决数学题的方式中得到启发，将复杂问题分解为更简单的多步程序，并利用多种方式在每一个步骤中对方法进行验证。
-
-
-
-由于LLM是生成式模型，要确保生成的答案是准确的，特别是对于数学推理任务，就变得非常棘手。通过观察学生解决算术问题的过程，总结出了学生为验证其解决方案而采取的几个步骤：
-（1）遵循已知结果（`Compliance with known results`），通过将解决方案与已知结果进行比较，可以评估其准确性并进行必要的调整；当问题是一个具有成熟解决方案的标准问题时，这一点尤其有用。
-（2）多重验证 （`Multi-verification`），通过从多个角度切入问题并比较结果，有助于确认解决方案的有效性，确保其既合理又准确。
-（3）交叉检查 （`Cross-checking`），解决问题的过程与最终的答案同样必要；验证过程中的中间步骤的正确性可以清楚地了解解决方案背后的思维过程。
-（4）计算验证 （`Compute verification`），利用计算器或电脑进行算术计算可以帮助验证最终答案的准确性。
-
-具体而言，给定一个问题 $Q$。
-
-::: code-tabs#plain
-
-@tab EN
-
-```plain
-Q:At a restaurant, each adult meal costs \$5 and kids eat free. If a group of 15people came in and 8 were kids, how much would it cost for the group to eat？
-```
-
-@tab CN
-
-```plain
-在一家餐厅，每份成人餐的价格是5美元，儿童免费用餐。如果有15个人进来，其中8个是孩子，那么这群人要花多少钱吃饭？
-```
-
-:::
-
-
-### 2.1 生成代数模板 Generating Algebraic template
-
-首先将问题转化为代数形式，通过使用键值映射将数字项替换为变量，然后得到修改后的问题 $Qt$。
-
-```plain
-Qt: at a restaurant, each adult meal costs A and kids eat free. if a group of B people came in and C were kids, how much would it cost for the group to eat？
-
-Mapping：{A：5， B：15， C：8}
-```
-
-### 2.2 数学提示 Math-prompts
-
-基于上述多重验证和交叉检查的思维过程所提供的直觉上，使用两种不同的方法生成 `Qt` 的分析解决方案，即代数方式和 `Pythonic` 方式，给 `LLM` 提供以下提示，为 `Qt` 生成额外的上下文。
-
-```plain
-Algebraic prompt: Write a mathematical equation and generate the answer format starting with 'Answer ='
-
-Python prompt: Write a Python function that returns the answer.
-```
-提示可以是**推导出一个代数表达式**或**编写一个Python函数**
-`LLM` 模型在响应提示后可以输出如下表达式。
-
-```python
-# Algebraic expression output
-Answer = A * (B - C)
-
-# Python expression output
-def total_price(A, B, C):
- return A * (B - C)
-```
-
-上述生成的分析方案为用户提供了关于LLM的「中间思维过程」的提示，加入额外的提示可以提高结果的准确性和一致性，反过来会提高MathPrompter生成更精确和有效的解决方案的能力。
-
-
-### 2.3 计算验证 Compute verification
-
-使用 `Qt` 中输入变量的多个随机键值映射来评估上一步生成的表达式，使用 `Python` 的 `eval()` 方法对这些表达式进行评估。
-然后比较输出结果，看是否能在答案中找到一个**共识**（`consensus`），也可以提供更高的置信度，即答案是正确且可靠的。
-
-```python
-Algebraic-answer = 35
-Pythonic-answer = 35
-```
-
-一旦表达式在输出上达成一致，就使用输入 $Q$ 中的变量值来计算最终的答案。
-
-### 2.4 统计学意义 Statistical significance
-
-为了保证各种表达式的输出结果达成共识，实验中将步骤2和3重复大约5次，并记录出现最频繁的答案值。在没有明确共识的情况下，重复步骤2、3、4。
-
-## 3 实验结果
-
-在 `MultiArith` 数据集上对 `MathPrompter` 进行评估，其中的数学问题专门用来测试机器学习模型进行复杂算术运算和推理的能力，要求应用多种算术运算和逻辑推理才能成功地解决。
-
-
-
-在 `MultiArith` 数据集上的准确率结果显示，`MathPrompter`的表现优于所有的 `Zero-shot` 和 `Zero-shot-CoT` 基线，将准确率从 $78.7\%$ 提升到 $92.5\%$
-
-可以看到，基于 $175B$ 参数 `GPT3 DaVinci` 的 `MathPrompter` 模型的性能与 $540B$ 参数模型以及 `SOTA` 的 `Few-shot-CoT` 方法相当。
-
-
-
-从上表可以看到，`MathPrompter`的设计可以弥补生成的答案有时会有一步之差的问题，可以通过多次运行模型并报告共识结果来避免。
-
-此外，推理步骤可能过于冗长的问题，可以由 `Pythonic` 或`Algebraic` 方法可以解决这个问题，通常需要较少的 `token`。
-
-此外，推理步骤可能是正确的，但最终的计算结果却不正确，`MathPrompter` 通过使用 `Python` 的 `eval()` 方法函数来解决这个问题。
-
-在大部分情况下，`MathPrompter` 都能生成正确的中间和最终答案，不过也有少数情况，如表中的最后一个问题，代数和 `Pythonic` 的输出都是一致的，但却有错误。
+---
+author: lx
+icon: wand-magic-sparkles
+date: 2023-03-30
+shortTitle: "MathPrompter: 数学推理"
+category:
+ - 提示技术
+tag:
+ - 推理
+ - LLM
+ - CoT
+---
+
+# MathPrompter: 数学推理
+
+[该文](https://mp.weixin.qq.com/s/DUS4pc7izs9CS3Pmz3WMxg)介绍了 `MathPrompter: 数学推理` 框架，解决需要多步推理的复杂数学问题。
+
+
+
+
+
+> 论文要解决的问题
+
+（1）数学问题通常只有一个正确答案，对于一个需要**多步推理**的复杂数学问题，语言模型通常都无法给出正确答案，即便有「思维链」技术的加持，往往**中间步骤也会出错**。
+（2）并且，在数学问题上，现有的语言模型通常不会对自己的答案**提供置信度**（`confidence`），让用户无从判断生成答案的可信度。
+
+> 采用方法
+
+（1）`MathPrompter` 使用 `Zero-shot` 思维链提示技术生成多个**代数表达式**或 **`Python` 函数**，以不同方式解决同一个数学问题，从而提高输出结果的可信度。
+（2）相比其他基于提示的 `CoT` 方法，`MathPrompter` 还会检查中间步骤的有效性。
+
+> 结果
+
+基于 `175B` 参数 `GPT`，使用 `MathPrompter` 方法将`MultiArith` 数据集的准确率从 `78.7%` 提升到了 `92.5%`。
+
+---
+
+## 1 专攻数学的Prompt
+
+最近自然语言处理的发展很大程度上归功于大型语言模型（LLMs）在规模上的不断扩展，其展现出了惊人的 `zero-shot` 和 `few-shot` 能力，也促成了 `prompting` 技术的发展，用户只需要在 `prompt`中给 `LLM` 输入几个简单的样例即可对新任务进行预测。`prompt` 对于**单步**的任务相当成功，但在需要**多步骤推理**的任务中，提示技术的性能仍然不够。
+
+人类在解决一个复杂问题时，会将其进行**分解**，并尝试一步步地解决，思维链（CoT）提示技术就是将这种直觉扩展到 `LLMs` 中，在一系列需要推理的NLP任务中都得到了性能改进。
+
+本篇论文主要研究用于解决数学推理任务的 `Zero-shot-CoT` 方法，之前的工作已经在 `MultiArith` 数据集上得到了显著的准确率改进，从 $17.7\%$ 提升到了 $78.7\%$，但仍然存在两个关键的不足之处：
+（1）虽然模型所遵循的思维链改进了结果，但却没有检查思维链提示所遵循的每个步骤的有效性；
+（2）没有对LLM预测结果提供置信度（`confidence`）。
+
+
+## 2 MathPrompter
+
+为了在一定程度上解决上述差距，从人类解决数学题的方式中得到启发，将复杂问题分解为更简单的多步程序，并利用多种方式在每一个步骤中对方法进行验证。
+
+
+
+由于LLM是生成式模型，要确保生成的答案是准确的，特别是对于数学推理任务，就变得非常棘手。通过观察学生解决算术问题的过程，总结出了学生为验证其解决方案而采取的几个步骤：
+（1）遵循已知结果（`Compliance with known results`），通过将解决方案与已知结果进行比较，可以评估其准确性并进行必要的调整；当问题是一个具有成熟解决方案的标准问题时，这一点尤其有用。
+（2）多重验证 （`Multi-verification`），通过从多个角度切入问题并比较结果，有助于确认解决方案的有效性，确保其既合理又准确。
+（3）交叉检查 （`Cross-checking`），解决问题的过程与最终的答案同样必要；验证过程中的中间步骤的正确性可以清楚地了解解决方案背后的思维过程。
+（4）计算验证 （`Compute verification`），利用计算器或电脑进行算术计算可以帮助验证最终答案的准确性。
+
+具体而言，给定一个问题 $Q$。
+
+::: code-tabs#plain
+
+@tab EN
+
+```plain
+Q:At a restaurant, each adult meal costs \$5 and kids eat free. If a group of 15people came in and 8 were kids, how much would it cost for the group to eat？
+```
+
+@tab CN
+
+```plain
+在一家餐厅，每份成人餐的价格是5美元，儿童免费用餐。如果有15个人进来，其中8个是孩子，那么这群人要花多少钱吃饭？
+```
+
+:::
+
+
+### 2.1 生成代数模板 Generating Algebraic template
+
+首先将问题转化为代数形式，通过使用键值映射将数字项替换为变量，然后得到修改后的问题 $Qt$。
+
+```plain
+Qt: at a restaurant, each adult meal costs A and kids eat free. if a group of B people came in and C were kids, how much would it cost for the group to eat？
+
+Mapping：{A：5， B：15， C：8}
+```
+
+### 2.2 数学提示 Math-prompts
+
+基于上述多重验证和交叉检查的思维过程所提供的直觉上，使用两种不同的方法生成 `Qt` 的分析解决方案，即代数方式和 `Pythonic` 方式，给 `LLM` 提供以下提示，为 `Qt` 生成额外的上下文。
+
+```plain
+Algebraic prompt: Write a mathematical equation and generate the answer format starting with 'Answer ='
+
+Python prompt: Write a Python function that returns the answer.
+```
+提示可以是**推导出一个代数表达式**或**编写一个Python函数**
+`LLM` 模型在响应提示后可以输出如下表达式。
+
+```python
+# Algebraic expression output
+Answer = A * (B - C)
+
+# Python expression output
+def total_price(A, B, C):
+ return A * (B - C)
+```
+
+上述生成的分析方案为用户提供了关于LLM的「中间思维过程」的提示，加入额外的提示可以提高结果的准确性和一致性，反过来会提高MathPrompter生成更精确和有效的解决方案的能力。
+
+
+### 2.3 计算验证 Compute verification
+
+使用 `Qt` 中输入变量的多个随机键值映射来评估上一步生成的表达式，使用 `Python` 的 `eval()` 方法对这些表达式进行评估。
+然后比较输出结果，看是否能在答案中找到一个**共识**（`consensus`），也可以提供更高的置信度，即答案是正确且可靠的。
+
+```python
+Algebraic-answer = 35
+Pythonic-answer = 35
+```
+
+一旦表达式在输出上达成一致，就使用输入 $Q$ 中的变量值来计算最终的答案。
+
+### 2.4 统计学意义 Statistical significance
+
+为了保证各种表达式的输出结果达成共识，实验中将步骤2和3重复大约5次，并记录出现最频繁的答案值。在没有明确共识的情况下，重复步骤2、3、4。
+
+## 3 实验结果
+
+在 `MultiArith` 数据集上对 `MathPrompter` 进行评估，其中的数学问题专门用来测试机器学习模型进行复杂算术运算和推理的能力，要求应用多种算术运算和逻辑推理才能成功地解决。
+
+
+
+在 `MultiArith` 数据集上的准确率结果显示，`MathPrompter`的表现优于所有的 `Zero-shot` 和 `Zero-shot-CoT` 基线，将准确率从 $78.7\%$ 提升到 $92.5\%$
+
+可以看到，基于 $175B$ 参数 `GPT3 DaVinci` 的 `MathPrompter` 模型的性能与 $540B$ 参数模型以及 `SOTA` 的 `Few-shot-CoT` 方法相当。
+
+
+
+从上表可以看到，`MathPrompter`的设计可以弥补生成的答案有时会有一步之差的问题，可以通过多次运行模型并报告共识结果来避免。
+
+此外，推理步骤可能过于冗长的问题，可以由 `Pythonic` 或`Algebraic` 方法可以解决这个问题，通常需要较少的 `token`。
+
+此外，推理步骤可能是正确的，但最终的计算结果却不正确，`MathPrompter` 通过使用 `Python` 的 `eval()` 方法函数来解决这个问题。
+
+在大部分情况下，`MathPrompter` 都能生成正确的中间和最终答案，不过也有少数情况，如表中的最后一个问题，代数和 `Pythonic` 的输出都是一致的，但却有错误。
diff --git a/src/zh/posts/reasoning/SoT.md b/src/zh/posts/prompt/SoT.md
similarity index 98%
rename from src/zh/posts/reasoning/SoT.md
rename to src/zh/posts/prompt/SoT.md
index 312dceed0..f0bea53da 100644
--- a/src/zh/posts/reasoning/SoT.md
+++ b/src/zh/posts/prompt/SoT.md
@@ -1,149 +1,149 @@
----
-author: lx
-icon: wand-magic-sparkles
-date: 2023-06-05
-shortTitle: "Skeleton-of-Thought: 思维骨架"
-category:
- - 提示技术
-tag:
- - 推理
- - LLM
- - SoT
----
-
-# Skeleton-of-Thought: 思维骨架
-
-[该文](https://mp.weixin.qq.com/s/9t1opfhUYm3yJuEoKPvVuQ) 介绍了清华与微软合作提出的一种全新**思维骨架**(SoT)，大大减少了LLM回答的延迟，并提升了回答的质量。
-
-
-
-由于当前先进的LLM采用了**顺序解码**方式，即一次生成一个词语或短语。然而，这种顺序解码可能花费较长生成时间，特别是在处理复杂任务时，会增加系统的延迟。受人类思考和写作过程的启发，来自清华微软的研究人员提出了「思维骨架」（SoT），以减少大模型的端到端的生成延迟。
-
-核心思想：SoT引导LLM，首先生成答案的**骨架**，然后进行并行API调用或分批解码，并行完成每个骨架点的内容。SoT不仅大大提高了速度，在11个不同的LLM中可达2.39倍，而且还可能在多样性和相关性方面提高多个问题类别的答案质量。研究人员称，SoT是以数据为中心优化效率的初步尝试，揭示了推动LLM更像人类一样思考答案质量的潜力。
-
-
-
----
-
-## 1 SoT，让大模型并行解码
-
-### 1.1 背景
-
-目前，最先进的LLM的推理过程依旧缓慢，交互能力大大减分。LLM推理慢的3个主要原因：
-
-（1）大模型需要大量内存，内存访问和计算。比如，GPT-3的FP16权重需要350 GB内存，这意味着仅推理就需要5×80GB A100 GPU。即使有足够多的GPU，繁重的内存访问和计算也会降低推理（以及训练）的速度。
-（2）主流Transformer架构中的核心注意力操作受I/O约束，其内存和计算复杂度与序列长度成二次方关系。
-（3）推理中的顺序解码方法逐个生成token，其中每个token都依赖于先前生成的token。这种方法会带来很大的推理延迟，因为token的生成无法并行化。
-
-先前的研究中，大多将重点放在**大模型规模**，以及**注意力操作**上。这次，研究团队展示了，现成LLM**并行解码**的可行性，而无需对其模型、系统或硬件进行任何改动。
-
-> 研究人员可以通过Slack使用Claude模型将延迟时间从22秒，减少到12秒（快了1.83倍），通过A100上的Vicuna-33B V1.3将延迟时间从43秒减少到16秒（快了2.69倍）。
-
-### 1.2 思路
-
-这个想法，来源于对人类自身如何回答问题的思考。对于我们来讲，并不总是按顺序思考问题，并写出答案。相反，对于许多类型的问题，首先根据一些策略推导出骨架，然后添加细节来细化和说明每一点。那么，这一点在提供咨询、参加考试、撰写论文等正式场合中，更是如此。我们能够让LLM以同样的方式思考吗？为此，研究人员提出了「思维骨架」（SoT）。具体来说，
-
-
-
-（1）引导LLM首先自己推导出一个骨架。
-（2）在骨架的基础上，LLM可以并行地完成每个点，从而提高速度。SoT既可用于加速分批解码的开源模型，也可用于加速并行API调用的闭源模型。
-（3）最后，研究人员在最近发布的11个LLM上测试SoT。结果显示，SoT不仅提供了相当大的加速度（最高可达2.39倍） ，而且它还可以在多样性和相关性方面提高几个问题类别的答案质量。
-
-
-
-### 1.3 SoT框架
-
-（1）骨架阶段。
-
-SoT首先使用骨架提示模版$T^{s}$，以问题$q$为参数，组装一个骨架请求 $T^{s}(question = q)$ 。编写骨架提示模板是为了引导LLM输出**简洁的答案骨架**。然后，研究人员从LLM的骨架答案 $R^{s}$ 中提取B点。
-
-（2）点扩展阶段
-
-基于骨架，让LLM在每个点上平行展开。具体地说，对于带有索引 $b$ 和骨架 $R^{s}_{b}$ 的点，SoT使用 $R^{s}, point \ index = b, point \ skeleton = R_{b}^{s}$ 作为LLM的点扩展请求，其中 $T^{pe}$ 是点扩展提示模板。最后，在完成所有的点之后，研究人员连接点扩展响应 $\{R^{pe}_{b}\}_{b = 1, \cdots, B}$ 来得到最终的答案。
-
-如下，Prompt 1和 Prompt 2显示了，研究人员当前实现使用的骨架提示模板图片和点扩展提示模板图片。
-
-
-
-
-
-（3）骨架提示模板。
-
-为了使输出的骨架简短且格式一致，以提高效率和便于提取要点，骨架提示模板（1）精确描述了任务，（2）使用了两个简单的示范，（3）提供了部分答案「1」为LLM继续写作。
-
-（4）点扩展提示模板。
-
-点扩展提示模板描述点扩展任务，并提供部分答案。研究人员还提供了指示「在1ー2个句子中非常简短地写出」的说明，以便LLM使答案保持简洁。
-
-（5）并行点扩展。
-
-对于只能访问API的专有模型可以发出多个并行的API调用。对于开源模型，让模型将点扩展请求作为批处理。
-
-### 1.4 为什么SoT降低了解码延迟？
-
-首先要对SoT为什么能够带来显著的端到端加速有一个高层次的理解。为了简单起见，在这里集中讨论点扩展阶段。
-
-具有并行API调用的模型。普通方法向服务器发送一个API请求，而 SoT 并行发送多个 API 请求以获得答案的不同部分。
-
-根据经验，研究人员观察到，在论文中使用的API的延迟与响应中的token数呈正相关。如果请求数量没有达到速率限制，SoT显然会带来加速。
-
-采用批量解码的开源模型。普通的方法只处理一个问题，并按顺序解码答案，而SoT处理多个点扩展请求和一批答案。
-
-
-## 2 实验结论
-
-实验数据集：使用Vicuna-80数据集，它由跨越9个类别的80个问题组成，如编码、数学、写作、角色扮演等。
-
-模型：对11个最近发布的模型进行SoT测试，其中包括9个开源模型和2个基于API的模型。
-
-
-
-### 2.1 效率评估
-
-（1）SoT减少不同模型上的端到端延迟
-
-应用SoT后，11个模型中，有6个模型速度有2倍以上的提升（即LLaMA2-Chat-7B，LLaMA2-Chat-13B，Vicuna-7B V1.1，OpenChat-13B，Vicuna-33B V1.3，UltraLM-13B）。在ChatGPT-3.5，Vicuna-13B V1.3和Vicuna-7B V1.3上则有1.8倍以上的速度提升。但在StableVicuna-13B和Claude中，速度几乎没有提升。
-
-如果排除数学和代码的问题类别，速度提升会较排除前略高。
-
-
-
-（2）SoT减少不同类别问题的端到端延迟
-
-下图显示了每个问题类别在所有模型中的平均速度提升。那些SoT能够提供高质量答案的问题类别标记为绿色，不能的其他问题类别标记为红色。当前的SoT已经可以提升所有类别问题的速度。但对于那些SoT可以提供高质量答案的5个问题类别（即知识、常识、通用、角色扮演、虚拟情景），SoT可以将整体答案生成过程加速1.95倍-2.27倍。
-
-
-
-（3） SoT和正常生成的延迟对比
-
-下图显示了模型正常生成和SoT生成的绝对延迟的比较。与正常生成相比，应用SoT的模型生成的速度提升是显而易见的。而**解码阶段**是内容生成端到端延迟的主要原因。因此，尽管SoT在骨架阶段比正常生成具有较高的预填充延迟，但这对总体延迟和总体速度提升几乎没有影响。
-
-
-
-### 2.2 质量评估
-
-为了比较正常的顺序生成（以下简称为正常）和SoT生成的答案质量，研究采用了两个基于LLM的评估框架: FastChat和LLMZoo。评估过程是向LLM评判器（本研究中为ChatGPT-3.5）展示一个问题和一对答案（由正常和SoT生成），并询问其偏好。回答可能是SoT的答案胜出、与正常答案并列、输给正常答案。
-
-（1）整体质量：
-
-下图显示了使用FastChat和LLMZoo两个指标下使用SOT的模型在所有问题下的赢/平/输率。在SoT严格优于基线时，两个指标之间存在差异(49.0% vs.10.4%)。但这两个指标都认为，在超过76%的情况下，SoT并不比基线（正常生成）差。对于FastChat指标，研究人员还展示了排除数学和编码问题（SoT不适用于这些问题，请参见3.2.2节）的比率：在超过90％的情况下，SoT与基准相当。这表明SoT的答案保持着良好的质量。
-
-
-
-（2）SOT在不同类别问题上的表现
-
-下图计算了所有问题类别的净胜率（胜率-败率）。LLMZoo指标下SoT的质量比FastChat的更好。但不论在哪个框架指标下，SoT在泛型、常识、知识、角色扮演和反事实方面的表现都相对较好，而在写作、费米问题、数学和编码方面表现相对较差。
-
-
-
-## 3 局限性
-
-由于提示集的限制、现有LLM判断的偏差，以及LLM属性评价的内在困难，研究人员目前对LLM问题的答案质量的评价还远不全面。
-
-对更可靠的质量评价而言，扩展提示集，以及用人工评价补充基于LLM的评价非常重要。
-
-然而，目前的研究主要集中在揭示潜在的效率效益上，即通过重新思考现有LLM「全序列解码」的必要性，可以实现相当大的加速。
-
-因此，研究人员在最后将对答案质量的更彻底的评估留给了未来的工作。
-
-## 4 参考
+---
+author: lx
+icon: wand-magic-sparkles
+date: 2023-06-05
+shortTitle: "Skeleton-of-Thought: 思维骨架"
+category:
+ - 提示技术
+tag:
+ - 推理
+ - LLM
+ - SoT
+---
+
+# Skeleton-of-Thought: 思维骨架
+
+[该文](https://mp.weixin.qq.com/s/9t1opfhUYm3yJuEoKPvVuQ) 介绍了清华与微软合作提出的一种全新**思维骨架**(SoT)，大大减少了LLM回答的延迟，并提升了回答的质量。
+
+
+
+由于当前先进的LLM采用了**顺序解码**方式，即一次生成一个词语或短语。然而，这种顺序解码可能花费较长生成时间，特别是在处理复杂任务时，会增加系统的延迟。受人类思考和写作过程的启发，来自清华微软的研究人员提出了「思维骨架」（SoT），以减少大模型的端到端的生成延迟。
+
+核心思想：SoT引导LLM，首先生成答案的**骨架**，然后进行并行API调用或分批解码，并行完成每个骨架点的内容。SoT不仅大大提高了速度，在11个不同的LLM中可达2.39倍，而且还可能在多样性和相关性方面提高多个问题类别的答案质量。研究人员称，SoT是以数据为中心优化效率的初步尝试，揭示了推动LLM更像人类一样思考答案质量的潜力。
+
+
+
+---
+
+## 1 SoT，让大模型并行解码
+
+### 1.1 背景
+
+目前，最先进的LLM的推理过程依旧缓慢，交互能力大大减分。LLM推理慢的3个主要原因：
+
+（1）大模型需要大量内存，内存访问和计算。比如，GPT-3的FP16权重需要350 GB内存，这意味着仅推理就需要5×80GB A100 GPU。即使有足够多的GPU，繁重的内存访问和计算也会降低推理（以及训练）的速度。
+（2）主流Transformer架构中的核心注意力操作受I/O约束，其内存和计算复杂度与序列长度成二次方关系。
+（3）推理中的顺序解码方法逐个生成token，其中每个token都依赖于先前生成的token。这种方法会带来很大的推理延迟，因为token的生成无法并行化。
+
+先前的研究中，大多将重点放在**大模型规模**，以及**注意力操作**上。这次，研究团队展示了，现成LLM**并行解码**的可行性，而无需对其模型、系统或硬件进行任何改动。
+
+> 研究人员可以通过Slack使用Claude模型将延迟时间从22秒，减少到12秒（快了1.83倍），通过A100上的Vicuna-33B V1.3将延迟时间从43秒减少到16秒（快了2.69倍）。
+
+### 1.2 思路
+
+这个想法，来源于对人类自身如何回答问题的思考。对于我们来讲，并不总是按顺序思考问题，并写出答案。相反，对于许多类型的问题，首先根据一些策略推导出骨架，然后添加细节来细化和说明每一点。那么，这一点在提供咨询、参加考试、撰写论文等正式场合中，更是如此。我们能够让LLM以同样的方式思考吗？为此，研究人员提出了「思维骨架」（SoT）。具体来说，
+
+
+
+（1）引导LLM首先自己推导出一个骨架。
+（2）在骨架的基础上，LLM可以并行地完成每个点，从而提高速度。SoT既可用于加速分批解码的开源模型，也可用于加速并行API调用的闭源模型。
+（3）最后，研究人员在最近发布的11个LLM上测试SoT。结果显示，SoT不仅提供了相当大的加速度（最高可达2.39倍） ，而且它还可以在多样性和相关性方面提高几个问题类别的答案质量。
+
+
+
+### 1.3 SoT框架
+
+（1）骨架阶段。
+
+SoT首先使用骨架提示模版$T^{s}$，以问题$q$为参数，组装一个骨架请求 $T^{s}(question = q)$ 。编写骨架提示模板是为了引导LLM输出**简洁的答案骨架**。然后，研究人员从LLM的骨架答案 $R^{s}$ 中提取B点。
+
+（2）点扩展阶段
+
+基于骨架，让LLM在每个点上平行展开。具体地说，对于带有索引 $b$ 和骨架 $R^{s}_{b}$ 的点，SoT使用 $R^{s}, point \ index = b, point \ skeleton = R_{b}^{s}$ 作为LLM的点扩展请求，其中 $T^{pe}$ 是点扩展提示模板。最后，在完成所有的点之后，研究人员连接点扩展响应 $\{R^{pe}_{b}\}_{b = 1, \cdots, B}$ 来得到最终的答案。
+
+如下，Prompt 1和 Prompt 2显示了，研究人员当前实现使用的骨架提示模板图片和点扩展提示模板图片。
+
+
+
+
+
+（3）骨架提示模板。
+
+为了使输出的骨架简短且格式一致，以提高效率和便于提取要点，骨架提示模板（1）精确描述了任务，（2）使用了两个简单的示范，（3）提供了部分答案「1」为LLM继续写作。
+
+（4）点扩展提示模板。
+
+点扩展提示模板描述点扩展任务，并提供部分答案。研究人员还提供了指示「在1ー2个句子中非常简短地写出」的说明，以便LLM使答案保持简洁。
+
+（5）并行点扩展。
+
+对于只能访问API的专有模型可以发出多个并行的API调用。对于开源模型，让模型将点扩展请求作为批处理。
+
+### 1.4 为什么SoT降低了解码延迟？
+
+首先要对SoT为什么能够带来显著的端到端加速有一个高层次的理解。为了简单起见，在这里集中讨论点扩展阶段。
+
+具有并行API调用的模型。普通方法向服务器发送一个API请求，而 SoT 并行发送多个 API 请求以获得答案的不同部分。
+
+根据经验，研究人员观察到，在论文中使用的API的延迟与响应中的token数呈正相关。如果请求数量没有达到速率限制，SoT显然会带来加速。
+
+采用批量解码的开源模型。普通的方法只处理一个问题，并按顺序解码答案，而SoT处理多个点扩展请求和一批答案。
+
+
+## 2 实验结论
+
+实验数据集：使用Vicuna-80数据集，它由跨越9个类别的80个问题组成，如编码、数学、写作、角色扮演等。
+
+模型：对11个最近发布的模型进行SoT测试，其中包括9个开源模型和2个基于API的模型。
+
+
+
+### 2.1 效率评估
+
+（1）SoT减少不同模型上的端到端延迟
+
+应用SoT后，11个模型中，有6个模型速度有2倍以上的提升（即LLaMA2-Chat-7B，LLaMA2-Chat-13B，Vicuna-7B V1.1，OpenChat-13B，Vicuna-33B V1.3，UltraLM-13B）。在ChatGPT-3.5，Vicuna-13B V1.3和Vicuna-7B V1.3上则有1.8倍以上的速度提升。但在StableVicuna-13B和Claude中，速度几乎没有提升。
+
+如果排除数学和代码的问题类别，速度提升会较排除前略高。
+
+
+
+（2）SoT减少不同类别问题的端到端延迟
+
+下图显示了每个问题类别在所有模型中的平均速度提升。那些SoT能够提供高质量答案的问题类别标记为绿色，不能的其他问题类别标记为红色。当前的SoT已经可以提升所有类别问题的速度。但对于那些SoT可以提供高质量答案的5个问题类别（即知识、常识、通用、角色扮演、虚拟情景），SoT可以将整体答案生成过程加速1.95倍-2.27倍。
+
+
+
+（3） SoT和正常生成的延迟对比
+
+下图显示了模型正常生成和SoT生成的绝对延迟的比较。与正常生成相比，应用SoT的模型生成的速度提升是显而易见的。而**解码阶段**是内容生成端到端延迟的主要原因。因此，尽管SoT在骨架阶段比正常生成具有较高的预填充延迟，但这对总体延迟和总体速度提升几乎没有影响。
+
+
+
+### 2.2 质量评估
+
+为了比较正常的顺序生成（以下简称为正常）和SoT生成的答案质量，研究采用了两个基于LLM的评估框架: FastChat和LLMZoo。评估过程是向LLM评判器（本研究中为ChatGPT-3.5）展示一个问题和一对答案（由正常和SoT生成），并询问其偏好。回答可能是SoT的答案胜出、与正常答案并列、输给正常答案。
+
+（1）整体质量：
+
+下图显示了使用FastChat和LLMZoo两个指标下使用SOT的模型在所有问题下的赢/平/输率。在SoT严格优于基线时，两个指标之间存在差异(49.0% vs.10.4%)。但这两个指标都认为，在超过76%的情况下，SoT并不比基线（正常生成）差。对于FastChat指标，研究人员还展示了排除数学和编码问题（SoT不适用于这些问题，请参见3.2.2节）的比率：在超过90％的情况下，SoT与基准相当。这表明SoT的答案保持着良好的质量。
+
+
+
+（2）SOT在不同类别问题上的表现
+
+下图计算了所有问题类别的净胜率（胜率-败率）。LLMZoo指标下SoT的质量比FastChat的更好。但不论在哪个框架指标下，SoT在泛型、常识、知识、角色扮演和反事实方面的表现都相对较好，而在写作、费米问题、数学和编码方面表现相对较差。
+
+
+
+## 3 局限性
+
+由于提示集的限制、现有LLM判断的偏差，以及LLM属性评价的内在困难，研究人员目前对LLM问题的答案质量的评价还远不全面。
+
+对更可靠的质量评价而言，扩展提示集，以及用人工评价补充基于LLM的评价非常重要。
+
+然而，目前的研究主要集中在揭示潜在的效率效益上，即通过重新思考现有LLM「全序列解码」的必要性，可以实现相当大的加速。
+
+因此，研究人员在最后将对答案质量的更彻底的评估留给了未来的工作。
+
+## 4 参考