From c1fc96d752adef022bb372c858f5acfd61cdb76b Mon Sep 17 00:00:00 2001 From: sheli00 <44807582+sheli00@users.noreply.github.com> Date: Tue, 31 Oct 2023 14:52:01 +0800 Subject: [PATCH 1/4] add category (#166) --- README.md | 2 + src/.vuepress/sidebar/zh.ts | 2 + src/zh/README.md | 8 + src/zh/posts/README.md | 2 + src/zh/posts/dataset/README.md | 2 +- src/zh/posts/eval/README.md | 2 +- src/zh/posts/finetune/README.md | 2 +- src/zh/posts/llm/README.md | 2 +- src/zh/posts/prompt/README.md | 2 +- .../posts/{llm => rag}/Chunking-Strategies.md | 317 +++++++++--------- src/zh/posts/{token => rag}/LLMretrieval.md | 3 +- src/zh/posts/{llm => rag}/LSR.md | 225 ++++++------- src/zh/posts/rag/README.md | 12 + .../{llm => rag}/RetrieveTextGeneration.md | 3 +- src/zh/posts/{llm => reasoning}/GPT4Reason.md | 2 +- src/zh/posts/reasoning/README.md | 12 + .../{prompt => reasoning}/llmReasonSurvey.md | 2 +- src/zh/posts/token/README.md | 2 +- src/zh/posts/{llm => token}/Token-Crisis.md | 2 +- 19 files changed, 323 insertions(+), 281 deletions(-) rename src/zh/posts/{llm => rag}/Chunking-Strategies.md (98%) rename src/zh/posts/{token => rag}/LLMretrieval.md (99%) rename src/zh/posts/{llm => rag}/LSR.md (99%) create mode 100644 src/zh/posts/rag/README.md rename src/zh/posts/{llm => rag}/RetrieveTextGeneration.md (99%) rename src/zh/posts/{llm => reasoning}/GPT4Reason.md (99%) create mode 100644 src/zh/posts/reasoning/README.md rename src/zh/posts/{prompt => reasoning}/llmReasonSurvey.md (99%) rename src/zh/posts/{llm => token}/Token-Crisis.md (99%) diff --git a/README.md b/README.md index 8b3b78757b..460f17708b 100644 --- a/README.md +++ b/README.md @@ -13,11 +13,13 @@ `category` 请从以下类别中选择 +- `RAG` - 语言模型(`LLM`) - 提示技术(`Prompt`) - 微调技术(`Finetune`) - 评估方法(`Eval`) - 数据集(`Dataset`) +- 推理方法(`Reasoning`) - `Token` 在 [src/zh/posts/${category}](https://github.com/HUSTAI/HUSTAI.github.io/tree/main/src/zh/posts/) 目录下增加一个新的 `md` 文件，参考[配置](https://theme-hope.vuejs.press/zh/config/frontmatter/info.html)来设置 `Frontmatter` diff --git a/src/.vuepress/sidebar/zh.ts b/src/.vuepress/sidebar/zh.ts index 34d669af3b..431c1f9890 100644 --- a/src/.vuepress/sidebar/zh.ts +++ b/src/.vuepress/sidebar/zh.ts @@ -8,11 +8,13 @@ export const zhSidebar = sidebar({ icon: "lightbulb", prefix: "posts/", children: [ + "rag/", "llm/", "prompt/", "finetune/", "eval/", "dataset/", + "reasoning/", "token/" ] // activeMatch: "^/zh/posts/", diff --git a/src/zh/README.md b/src/zh/README.md index 95262804ef..19634549ee 100644 --- a/src/zh/README.md +++ b/src/zh/README.md @@ -11,6 +11,10 @@ tagline: 分享知识-分享快乐 article: false projects: + - icon: circle-question + name: RAG + link: /zh/category/rag/ + - icon: circle-question name: 语言模型 link: /zh/category/语言模型/ @@ -31,6 +35,10 @@ projects: name: 数据集 link: /zh/category/数据集/ + - icon: puzzle-piece + name: 推理方法 + link: /zh/category/推理方法/ + - icon: puzzle-piece name: Token link: /zh/category/token/ diff --git a/src/zh/posts/README.md b/src/zh/posts/README.md index ab064a9788..9f4d10faec 100644 --- a/src/zh/posts/README.md +++ b/src/zh/posts/README.md @@ -9,9 +9,11 @@ article: false 本页面包含一些论文分享的分类： +- [RAG](./rag/) - [语言模型](./llm/) - [提示技术](./prompt/) - [微调技术](./finetune/) - [评估方法](./eval/) - [数据集](./dataset/) +- [推理方法](./reasoning/) - [Token](./token/) \ No newline at end of file diff --git a/src/zh/posts/dataset/README.md b/src/zh/posts/dataset/README.md index 4bbbe72a41..e9e344658a 100644 --- a/src/zh/posts/dataset/README.md +++ b/src/zh/posts/dataset/README.md @@ -8,5 +8,5 @@ category: tag: - Dataset dir: - order: 5 + order: 6 --- \ No newline at end of file diff --git a/src/zh/posts/eval/README.md b/src/zh/posts/eval/README.md index 493d5f7c6b..e024a09cf8 100644 --- a/src/zh/posts/eval/README.md +++ b/src/zh/posts/eval/README.md @@ -8,5 +8,5 @@ category: tag: - Eval dir: - order: 4 + order: 5 --- \ No newline at end of file diff --git a/src/zh/posts/finetune/README.md b/src/zh/posts/finetune/README.md index b9fccdca09..575a84ecc6 100644 --- a/src/zh/posts/finetune/README.md +++ b/src/zh/posts/finetune/README.md @@ -8,5 +8,5 @@ category: tag: - Finetune dir: - order: 3 + order: 4 --- \ No newline at end of file diff --git a/src/zh/posts/llm/README.md b/src/zh/posts/llm/README.md index a13b3d3896..2645094ef0 100644 --- a/src/zh/posts/llm/README.md +++ b/src/zh/posts/llm/README.md @@ -8,5 +8,5 @@ category: tag: - LLM dir: - order: 1 + order: 2 --- \ No newline at end of file diff --git a/src/zh/posts/prompt/README.md b/src/zh/posts/prompt/README.md index 905239e9cb..0f90bb1fb3 100644 --- a/src/zh/posts/prompt/README.md +++ b/src/zh/posts/prompt/README.md @@ -8,5 +8,5 @@ category: tag: - Prompt dir: - order: 2 + order: 3 --- \ No newline at end of file diff --git a/src/zh/posts/llm/Chunking-Strategies.md b/src/zh/posts/rag/Chunking-Strategies.md similarity index 98% rename from src/zh/posts/llm/Chunking-Strategies.md rename to src/zh/posts/rag/Chunking-Strategies.md index 1900f60994..cbb348b53f 100644 --- a/src/zh/posts/llm/Chunking-Strategies.md +++ b/src/zh/posts/rag/Chunking-Strategies.md @@ -1,158 +1,159 @@ ---- -author: 研究生鱼皮-yjf -icon: pen-to-square -date: 2023-09-04 -category: - - 语言模型 -tag: - - 检索 -# sticky: 10 ---- - -# 大语言模型应用中的文本分块策略 - -这篇博文讨论了在构建与大语言模型（LLM）相关的应用中使用的文本分块策略。分块是将大段文本分解为较小段的过程，它对于优化向量数据库返回内容相关性至关重要。 - - - -文章来源：https://www.pinecone.io/learn/chunking-strategies/ - -## 1 介绍 - -在构建与LLM相关的应用时，**分块（chunking）** 是将大段文本分解为较小段的过程。当我们使用LLM嵌入内容时，chunking是一项帮助优化向量数据库返回内容相关性的基本技术。在这篇博文中，我们将探讨它是否以及如何帮助提高LLM相关应用的效率和准确性。 - -往向量数据库中索引的任何内容都需要首先向量化（称为嵌入，embedding）。分块的主要原因是确保我们向量化的内容的噪音尽可能少，并且具有语义相关性。 - -例如，在语义搜索（semantic search）中，我们索引文档语料库。每个文档都包含有关特定主题的有价值的信息。通过应用有效的分块策略，可以确保搜索结果准确捕获用户查询的本质。区块太小或太大，可能会导致搜索结果不精确或错失显示相关内容的机会。**根据经验，如果文本块在没有周围上下文的情况下对人类有意义，那么它对语言模型也有意义。** 因此，为语料库中的文档找到最佳区块大小对于确保搜索结果准确且相关至关重要。 - -另一个例子是会话代理（conversational agents）。我们使用向量化的块来构建基于知识库的会话代理的**上下文**，该知识库使代理基于**受信任**的信息。在这种情况下，对分块策略做出正确的选择很重要，原因有两个：首先，它将确定上下文是否真正与我们的提示（prompt）相关。其次，它将确定是否能够在将检索到的文本发送到外部模型提供者（例如OpenAI）之前将其放入上下文中，因为我们可以为每个请求发送的token数量受到限制。在某些情况下，例如将 GPT-4 与 32k 上下文窗口一起使用时，拟合区块可能不是问题。尽管如此，使用非常大的块可能会对从向量数据库返回的结果的相关性产生不利影响。 - -我们将探讨几种分块方法，并讨论在选择分块大小和方法时应考虑的权衡。最后，我们将提供一些建议，以确定适合您的应用的最佳区块大小和方法。 - -## 2 嵌入短内容和长内容 - -当我们嵌入内容时，我们可以根据内容是短（如句子）还是长（如段落或整个文档）来预测不同的行为。 - -当嵌入**句子**时，生成的向量侧重于句子的特定含义。与其他句子嵌入相比，比较自然会在该级别上进行。这也意味着嵌入可能会错过段落或文档中更广泛的上下文信息。 - -嵌入**整个段落或文档**时，嵌入过程会考虑整体上下文以及文本中句子和短语之间的关系。这可以产生更全面的矢量表示，从而捕获文本的更广泛含义和主题。另一方面，较大的输入文本大小可能会引入干扰或稀释单个句子或短语的重要性，从而在查询索引时更难找到精确匹配项。 - -查询的长度也会影响嵌入之间的相互关系。较短的查询（例如单个句子或短语）将专注于细节，并且可能更适合与句子级嵌入进行匹配。跨越多个句子或段落的较长查询可能更符合段落或文档级别的嵌入，因为它可能正在寻找更广泛的上下文或主题。 - -索引也可能是非同类的，并且包含不同大小的块的嵌入。这可能会在查询结果相关性方面带来挑战，但也可能会产生一些积极的后果。一方面，由于长内容和短内容的语义表示之间存在差异，查询结果的相关性可能会波动。另一方面，非同构索引可能会捕获更广泛的上下文和信息，因为不同的块大小表示文本中的不同粒度级别。这可以更灵活地适应不同类型的查询。 - -## 3 chunking注意事项 - -几个变量在确定最佳分块策略方面发挥作用，这些变量因用例而异。以下是需要牢记的一些关键方面： - -1. **被索引的内容的性质是什么？** 您是处理较长的文档（如文章或书籍）还是较短的内容（如推文或即时消息）？答案将决定哪种模型更适合您的目标，从而决定应用哪种分块策略。 - -2. **您使用的是哪种嵌入模型，它在哪些块大小上表现最佳？** 例如，[sentence-transformer](https://huggingface.co/sentence-transformers)模型在单个句子上效果很好，但像[text-embedding-ada-002](https://openai.com/blog/new-and-improved-embedding-model)这样的模型在包含 256 或 512 个token的块上表现更好。 - -3. **您对用户查询的长度和复杂性有何期望？** 它们是简短而具体的还是冗长而复杂的？这也可能会告知您选择对内容进行分块的方式，以便嵌入式查询和嵌入式区块之间有更紧密的相关性。 - -4. **检索到的结果将如何在您的特定应用程序中使用？** 例如，它们是否用于语义搜索、问答、摘要或其他目的？例如，如果你的结果需要被输入到另一个具有令牌限制的LLM，你必须考虑到这一点，并根据你想要适应LLM请求的块数来限制块的大小。 - -回答这些问题将允许您开发平衡性能和准确性的分块策略，这反过来又将确保查询结果更具相关性。 - -## 4 分块方法 -有不同的分块方法，每种方法可能适用于不同的情况。通过检查每种方法的优点和缺点，我们的目标是确定应用它们的正确方案。 - -### 4.1 固定大小的分块 -这是最常见和最直接的分块方法：我们只需决定块中的代币数量，以及它们之间是否应该有任何重叠。通常，我们希望在块之间保持一些重叠，以确保语义上下文不会在块之间丢失。在大多数常见情况下，固定大小的分块将是最佳路径。与其他形式的分块相比，固定大小的分块在计算上便宜且易于使用，因为它不需要使用任何 NLP 库。 - -下面是使用 [LangChain](https://api.python.langchain.com/en/latest/api_reference.html) 执行固定大小的分块的示例： - -```Python -text = "..." # your text -from langchain.text_splitter import CharacterTextSplitter -text_splitter = CharacterTextSplitter( - separator = "\n\n", - chunk_size = 256, - chunk_overlap = 20 -) -docs = text_splitter.create_documents([text]) -``` - -### 4.2 “内容感知”（Content-aware）分块 -这些是一组方法，用于利用我们正在分块的内容的性质并对其应用更复杂的分块。以下是一些示例： - -#### 4.2.1 句子切分 -正如我们之前提到的，许多模型都针对嵌入句子级内容进行了优化。当然，我们会使用句子分块，并且有几种方法和工具可用于执行此操作，包括： - -- **朴素切分**：最简单的方法是按句点（“.”）和换行符切分句子。虽然这可能既快速又简单，但这种方法不会考虑所有可能的边缘情况。下面是一个非常简单的示例： - -```Python -text = "..." # your text -docs = text.split(".") -``` - -- **[NLTK](https://www.nltk.org/)**：自然语言工具包（NLTK）是一个流行的Python库，用于处理人类语言数据。它提供了一个句子分词器，可以将文本切分为句子，帮助创建更有意义的块。例如，要将NLTK与LangChain一起使用，您可以执行以下操作： -```Python -text = "..." # your text -from langchain.text_splitter import NLTKTextSplitter -text_splitter = NLTKTextSplitter() -docs = text_splitter.split_text(text) -``` - -- **[spaCy](https://spacy.io/)**：spaCy是另一个强大的Python库，用于NLP任务。它提供了复杂的分句功能，可以有效地将文本划分为单独的句子，从而在生成的块中更好地保留上下文。例如，要将spaCy与LangChain一起使用，您可以执行以下操作： -```Python -text = "..." # your text -from langchain.text_splitter import SpacyTextSplitter -text_splitter = SpaCyTextSplitter() -docs = text_splitter.split_text(text) -``` - -#### 4.2.2 递归分块 -递归分块使用一组分隔符以分层和迭代方式将输入文本划分为较小的块。如果拆分文本的初始尝试未生成所需大小或结构的块，则该方法会使用不同的分隔符或条件递归调用生成的块，直到达到所需的块大小或结构。这意味着，虽然块的大小不会完全相同，但它们仍然追求具有相似的大小。 - -下面是如何在 LangChain 中使用递归分块的示例： -```Python -text = "..." # your text -from langchain.text_splitter import RecursiveCharacterTextSplitter -text_splitter = RecursiveCharacterTextSplitter( - # Set a really small chunk size, just to show. - chunk_size = 256, - chunk_overlap = 20 -) - -docs = text_splitter.create_documents([text]) -``` - -#### 4.2.3 专用分块 - -Markdown和LaTeX是您可能会遇到的结构化和格式化内容的两个例子。在这些情况下，您可以使用专门的分块方法在分块过程中保留内容的原始结构。 - -- **[Markdown](https://www.markdownguide.org/)**：Markdown 是一种轻量级标记语言，通常用于格式化文本。通过识别 Markdown 语法（例如，标题、列表和代码块），您可以根据内容的结构和层次结构智能地划分内容，从而产生语义上更一致的块。例如： -```Python -from langchain.text_splitter import MarkdownTextSplitter -markdown_text = "..." - -markdown_splitter = MarkdownTextSplitter(chunk_size=100, chunk_overlap=0) -docs = markdown_splitter.create_documents([markdown_text]) - -``` - -- **[LaTex](https://www.latex-project.org/)**：LaTeX是一种文档准备系统和标记语言，通常用于学术论文和技术文档。通过解析 LaTeX 命令和环境，您可以创建尊重内容逻辑组织（例如，部分、子部分和公式）的块，从而获得更准确和上下文相关的结果。例如： - -```Python -from langchain.text_splitter import LatexTextSplitter -latex_text = "..." -latex_splitter = LatexTextSplitter(chunk_size=100, chunk_overlap=0) -docs = latex_splitter.create_documents([latex_text]) -``` - -## 5 确定应用的最佳块大小 -以下是一些指导意见，可帮助您在常见的分块方法（如固定分块）不容易应用于您的应用场景时提出最佳块大小。 - -- **预处理数据** - 在确定应用的最佳区块大小之前，需要先预处理数据以确保质量。例如，如果您的数据是从网络上抓取的，则可能需要移除具有干扰作用的 HTML标记或特定元素。 - -- **选择一组区块大小** - 预处理数据后，下一步是选择要测试的潜在区块大小范围。如前所述，选择应考虑内容的性质（例如，短消息或长文档）、您将使用的embedding模型及其功能（例如，token限制）。目标是在保留上下文和保持准确性之间找到平衡。首先探索各种块大小，包括用于捕获更精细语义信息的较小块（例如，128或256个token）和用于保留更多上下文的较大块（例如，512或1024个token）。 - -- **评估每个区块大小的性能** - 为了测试各种区块大小，您可以使用多个索引或具有多个[命名空间](https://docs.pinecone.io/docs/namespaces)的单个索引。使用代表性数据集，为要测试的区块大小创建嵌入向量，并将其保存在索引（或多个索引）中。然后，可以运行一系列查询，以便评估质量，并比较各种区块大小的性能。这很可能是一个迭代过程，您可以在其中针对不同的查询测试不同的区块大小，直到您可以确定内容和预期查询的最佳性能区块大小。 - -## 6 总结 -在大多数情况下，对内容进行分块非常简单。但是当您开始徘徊在人迹罕至的地方时，它可能会带来一些挑战。文本分块没有一刀切的解决方案，因此适用于一个场景的方法可能不适用于另一个场景。希望这篇文章能帮助你更好地了解如何为您的应用进行文本分块。 - - - +--- +author: 研究生鱼皮-yjf +icon: pen-to-square +date: 2023-09-04 +category: + - rag +tag: + - 检索 + - rag +# sticky: 10 +--- + +# 大语言模型应用中的文本分块策略 + +这篇博文讨论了在构建与大语言模型（LLM）相关的应用中使用的文本分块策略。分块是将大段文本分解为较小段的过程，它对于优化向量数据库返回内容相关性至关重要。 + + + +文章来源：https://www.pinecone.io/learn/chunking-strategies/ + +## 1 介绍 + +在构建与LLM相关的应用时，**分块（chunking）** 是将大段文本分解为较小段的过程。当我们使用LLM嵌入内容时，chunking是一项帮助优化向量数据库返回内容相关性的基本技术。在这篇博文中，我们将探讨它是否以及如何帮助提高LLM相关应用的效率和准确性。 + +往向量数据库中索引的任何内容都需要首先向量化（称为嵌入，embedding）。分块的主要原因是确保我们向量化的内容的噪音尽可能少，并且具有语义相关性。 + +例如，在语义搜索（semantic search）中，我们索引文档语料库。每个文档都包含有关特定主题的有价值的信息。通过应用有效的分块策略，可以确保搜索结果准确捕获用户查询的本质。区块太小或太大，可能会导致搜索结果不精确或错失显示相关内容的机会。**根据经验，如果文本块在没有周围上下文的情况下对人类有意义，那么它对语言模型也有意义。** 因此，为语料库中的文档找到最佳区块大小对于确保搜索结果准确且相关至关重要。 + +另一个例子是会话代理（conversational agents）。我们使用向量化的块来构建基于知识库的会话代理的**上下文**，该知识库使代理基于**受信任**的信息。在这种情况下，对分块策略做出正确的选择很重要，原因有两个：首先，它将确定上下文是否真正与我们的提示（prompt）相关。其次，它将确定是否能够在将检索到的文本发送到外部模型提供者（例如OpenAI）之前将其放入上下文中，因为我们可以为每个请求发送的token数量受到限制。在某些情况下，例如将 GPT-4 与 32k 上下文窗口一起使用时，拟合区块可能不是问题。尽管如此，使用非常大的块可能会对从向量数据库返回的结果的相关性产生不利影响。 + +我们将探讨几种分块方法，并讨论在选择分块大小和方法时应考虑的权衡。最后，我们将提供一些建议，以确定适合您的应用的最佳区块大小和方法。 + +## 2 嵌入短内容和长内容 + +当我们嵌入内容时，我们可以根据内容是短（如句子）还是长（如段落或整个文档）来预测不同的行为。 + +当嵌入**句子**时，生成的向量侧重于句子的特定含义。与其他句子嵌入相比，比较自然会在该级别上进行。这也意味着嵌入可能会错过段落或文档中更广泛的上下文信息。 + +嵌入**整个段落或文档**时，嵌入过程会考虑整体上下文以及文本中句子和短语之间的关系。这可以产生更全面的矢量表示，从而捕获文本的更广泛含义和主题。另一方面，较大的输入文本大小可能会引入干扰或稀释单个句子或短语的重要性，从而在查询索引时更难找到精确匹配项。 + +查询的长度也会影响嵌入之间的相互关系。较短的查询（例如单个句子或短语）将专注于细节，并且可能更适合与句子级嵌入进行匹配。跨越多个句子或段落的较长查询可能更符合段落或文档级别的嵌入，因为它可能正在寻找更广泛的上下文或主题。 + +索引也可能是非同类的，并且包含不同大小的块的嵌入。这可能会在查询结果相关性方面带来挑战，但也可能会产生一些积极的后果。一方面，由于长内容和短内容的语义表示之间存在差异，查询结果的相关性可能会波动。另一方面，非同构索引可能会捕获更广泛的上下文和信息，因为不同的块大小表示文本中的不同粒度级别。这可以更灵活地适应不同类型的查询。 + +## 3 chunking注意事项 + +几个变量在确定最佳分块策略方面发挥作用，这些变量因用例而异。以下是需要牢记的一些关键方面： + +1. **被索引的内容的性质是什么？** 您是处理较长的文档（如文章或书籍）还是较短的内容（如推文或即时消息）？答案将决定哪种模型更适合您的目标，从而决定应用哪种分块策略。 + +2. **您使用的是哪种嵌入模型，它在哪些块大小上表现最佳？** 例如，[sentence-transformer](https://huggingface.co/sentence-transformers)模型在单个句子上效果很好，但像[text-embedding-ada-002](https://openai.com/blog/new-and-improved-embedding-model)这样的模型在包含 256 或 512 个token的块上表现更好。 + +3. **您对用户查询的长度和复杂性有何期望？** 它们是简短而具体的还是冗长而复杂的？这也可能会告知您选择对内容进行分块的方式，以便嵌入式查询和嵌入式区块之间有更紧密的相关性。 + +4. **检索到的结果将如何在您的特定应用程序中使用？** 例如，它们是否用于语义搜索、问答、摘要或其他目的？例如，如果你的结果需要被输入到另一个具有令牌限制的LLM，你必须考虑到这一点，并根据你想要适应LLM请求的块数来限制块的大小。 + +回答这些问题将允许您开发平衡性能和准确性的分块策略，这反过来又将确保查询结果更具相关性。 + +## 4 分块方法 +有不同的分块方法，每种方法可能适用于不同的情况。通过检查每种方法的优点和缺点，我们的目标是确定应用它们的正确方案。 + +### 4.1 固定大小的分块 +这是最常见和最直接的分块方法：我们只需决定块中的代币数量，以及它们之间是否应该有任何重叠。通常，我们希望在块之间保持一些重叠，以确保语义上下文不会在块之间丢失。在大多数常见情况下，固定大小的分块将是最佳路径。与其他形式的分块相比，固定大小的分块在计算上便宜且易于使用，因为它不需要使用任何 NLP 库。 + +下面是使用 [LangChain](https://api.python.langchain.com/en/latest/api_reference.html) 执行固定大小的分块的示例： + +```Python +text = "..." # your text +from langchain.text_splitter import CharacterTextSplitter +text_splitter = CharacterTextSplitter( + separator = "\n\n", + chunk_size = 256, + chunk_overlap = 20 +) +docs = text_splitter.create_documents([text]) +``` + +### 4.2 “内容感知”（Content-aware）分块 +这些是一组方法，用于利用我们正在分块的内容的性质并对其应用更复杂的分块。以下是一些示例： + +#### 4.2.1 句子切分 +正如我们之前提到的，许多模型都针对嵌入句子级内容进行了优化。当然，我们会使用句子分块，并且有几种方法和工具可用于执行此操作，包括： + +- **朴素切分**：最简单的方法是按句点（“.”）和换行符切分句子。虽然这可能既快速又简单，但这种方法不会考虑所有可能的边缘情况。下面是一个非常简单的示例： + +```Python +text = "..." # your text +docs = text.split(".") +``` + +- **[NLTK](https://www.nltk.org/)**：自然语言工具包（NLTK）是一个流行的Python库，用于处理人类语言数据。它提供了一个句子分词器，可以将文本切分为句子，帮助创建更有意义的块。例如，要将NLTK与LangChain一起使用，您可以执行以下操作： +```Python +text = "..." # your text +from langchain.text_splitter import NLTKTextSplitter +text_splitter = NLTKTextSplitter() +docs = text_splitter.split_text(text) +``` + +- **[spaCy](https://spacy.io/)**：spaCy是另一个强大的Python库，用于NLP任务。它提供了复杂的分句功能，可以有效地将文本划分为单独的句子，从而在生成的块中更好地保留上下文。例如，要将spaCy与LangChain一起使用，您可以执行以下操作： +```Python +text = "..." # your text +from langchain.text_splitter import SpacyTextSplitter +text_splitter = SpaCyTextSplitter() +docs = text_splitter.split_text(text) +``` + +#### 4.2.2 递归分块 +递归分块使用一组分隔符以分层和迭代方式将输入文本划分为较小的块。如果拆分文本的初始尝试未生成所需大小或结构的块，则该方法会使用不同的分隔符或条件递归调用生成的块，直到达到所需的块大小或结构。这意味着，虽然块的大小不会完全相同，但它们仍然追求具有相似的大小。 + +下面是如何在 LangChain 中使用递归分块的示例： +```Python +text = "..." # your text +from langchain.text_splitter import RecursiveCharacterTextSplitter +text_splitter = RecursiveCharacterTextSplitter( + # Set a really small chunk size, just to show. + chunk_size = 256, + chunk_overlap = 20 +) + +docs = text_splitter.create_documents([text]) +``` + +#### 4.2.3 专用分块 + +Markdown和LaTeX是您可能会遇到的结构化和格式化内容的两个例子。在这些情况下，您可以使用专门的分块方法在分块过程中保留内容的原始结构。 + +- **[Markdown](https://www.markdownguide.org/)**：Markdown 是一种轻量级标记语言，通常用于格式化文本。通过识别 Markdown 语法（例如，标题、列表和代码块），您可以根据内容的结构和层次结构智能地划分内容，从而产生语义上更一致的块。例如： +```Python +from langchain.text_splitter import MarkdownTextSplitter +markdown_text = "..." + +markdown_splitter = MarkdownTextSplitter(chunk_size=100, chunk_overlap=0) +docs = markdown_splitter.create_documents([markdown_text]) + +``` + +- **[LaTex](https://www.latex-project.org/)**：LaTeX是一种文档准备系统和标记语言，通常用于学术论文和技术文档。通过解析 LaTeX 命令和环境，您可以创建尊重内容逻辑组织（例如，部分、子部分和公式）的块，从而获得更准确和上下文相关的结果。例如： + +```Python +from langchain.text_splitter import LatexTextSplitter +latex_text = "..." +latex_splitter = LatexTextSplitter(chunk_size=100, chunk_overlap=0) +docs = latex_splitter.create_documents([latex_text]) +``` + +## 5 确定应用的最佳块大小 +以下是一些指导意见，可帮助您在常见的分块方法（如固定分块）不容易应用于您的应用场景时提出最佳块大小。 + +- **预处理数据** - 在确定应用的最佳区块大小之前，需要先预处理数据以确保质量。例如，如果您的数据是从网络上抓取的，则可能需要移除具有干扰作用的 HTML标记或特定元素。 + +- **选择一组区块大小** - 预处理数据后，下一步是选择要测试的潜在区块大小范围。如前所述，选择应考虑内容的性质（例如，短消息或长文档）、您将使用的embedding模型及其功能（例如，token限制）。目标是在保留上下文和保持准确性之间找到平衡。首先探索各种块大小，包括用于捕获更精细语义信息的较小块（例如，128或256个token）和用于保留更多上下文的较大块（例如，512或1024个token）。 + +- **评估每个区块大小的性能** - 为了测试各种区块大小，您可以使用多个索引或具有多个[命名空间](https://docs.pinecone.io/docs/namespaces)的单个索引。使用代表性数据集，为要测试的区块大小创建嵌入向量，并将其保存在索引（或多个索引）中。然后，可以运行一系列查询，以便评估质量，并比较各种区块大小的性能。这很可能是一个迭代过程，您可以在其中针对不同的查询测试不同的区块大小，直到您可以确定内容和预期查询的最佳性能区块大小。 + +## 6 总结 +在大多数情况下，对内容进行分块非常简单。但是当您开始徘徊在人迹罕至的地方时，它可能会带来一些挑战。文本分块没有一刀切的解决方案，因此适用于一个场景的方法可能不适用于另一个场景。希望这篇文章能帮助你更好地了解如何为您的应用进行文本分块。 + + + diff --git a/src/zh/posts/token/LLMretrieval.md b/src/zh/posts/rag/LLMretrieval.md similarity index 99% rename from src/zh/posts/token/LLMretrieval.md rename to src/zh/posts/rag/LLMretrieval.md index d659f8ed80..0c54d1af3f 100644 --- a/src/zh/posts/token/LLMretrieval.md +++ b/src/zh/posts/rag/LLMretrieval.md @@ -4,10 +4,11 @@ icon: clipboard-list date: 2023-09-07 shortTitle: "大模型外挂知识库优化" category: - - Token + - rag tag: - LLM - 检索 + - rag --- # 如何通过大模型实现外挂知识库优化 diff --git a/src/zh/posts/llm/LSR.md b/src/zh/posts/rag/LSR.md similarity index 99% rename from src/zh/posts/llm/LSR.md rename to src/zh/posts/rag/LSR.md index 88727efe88..9ad7b22816 100644 --- a/src/zh/posts/llm/LSR.md +++ b/src/zh/posts/rag/LSR.md @@ -1,112 +1,113 @@ ---- -author: 研究生鱼皮-yjf -icon: pen-to-square -date: 2023-08-23 -category: - - 语言模型 -tag: - - 检索 -# sticky: 10 ---- - -# 学习稀疏检索的统一框架 - -学习稀疏检索是一种结合机器学习和信息检索的方法，旨在优化文本检索效果。通过学习模型，将查询和文档映射到稀疏表示空间，实现高效的检索。在训练阶段，利用已标记的查询-文档对和相关性标签，通过优化模型参数，学习如何选择、加权和组合特征，使相关文档在稀疏表示中更接近查询。学习稀疏检索方法可应用于大规模信息检索任务，如搜索引擎和推荐系统，以提高检索效率和准确性。 - - - -## 1 背景和目的 - -自然语言查询的文本检索是信息检索（IR）系统的核心任务。之前的研究采用了两阶段的流程来解决这个问题，首先通过快速的检索器从文档集合中检索出一组初始文档，然后由更复杂的模型进一步重新排名。对于第一阶段的检索，神经网络的密集表示在语义匹配方面具有很大的潜力，在许多自然语言处理任务中超越了稀疏方法，但在强调长文档检索和精确匹配的情况下不一定成立。此外，对于极大规模（例如100亿）的候选文档集合，密集方法不得不在效率与准确性之间权衡。传统的基于术语的稀疏表示，也称为词袋（BoW），如TF-IDF和BM25，可以有效地进行字面匹配，因此在工业级IR系统中扮演着核心角色。然而，传统的基于术语的方法通常被认为表示能力不足，不适用于语义级匹配。 - -学习稀疏检索最早由Zamani等人在论文《From Neural Re-Ranking to Neural Ranking: Learning a Sparse Representation for Inverted Indexing》中提出。SNRM（Standalone Neural Ranking Model）是一种独立的神经排序模型，旨在解决神经排序模型在效率方面的问题。它通过引入稀疏属性，为每个查询和文档学习潜在的稀疏表示。其中“潜在”Token在反向索引过程中扮演传统术语的角色。关于SNRM的一个挑战是它失去了原始术语的可解释性，这对于工业系统至关重要。 - -该论文研究了学习稀疏检索（LSR）方法，这是一类用于生成查询和文档稀疏词汇表示的首阶段检索方法，用于倒排索引。虽然有许多LSR方法已被引入，其中Splade模型在MSMarco数据集上取得了最先进的性能，但不同的实验设置和配置难以进行有效的比较和洞察。在这项工作中，作者分析了现有的LSR方法，识别出关键组成部分，并建立了一个统一的LSR框架，将所有LSR方法放置在一个统一的视角下。然后，作者重新实现了所有重要的方法，并在相同环境中重新训练，以便量化不同框架组成部分如何影响效果和效率。研究发现：（1）文档词项加权对方法的效果最具影响，（2）查询加权略有正面影响，（3）文档扩展和查询扩展效果相互抵消。因此，作者提出了如何从最先进的模型中移除查询扩展，以显著降低延迟，同时在MSMarco和TripClick数据集上保持性能。该工作旨在提供一种统一的LSR框架，深入分析了不同组成部分对效果和效率的影响，并为LSR方法的进一步优化提供了指导。 - -## 2 统一框架的建立 - -学习稀疏检索 (LSR) 使用查询编码器 $f_Q$和$f_D$文档编码器 将查询和文档投影到词汇大小的稀疏向量： $w_q=f_Q(q)=w_q^1,w_q^2,\dots ,w_q^{|V|}$和$w_d=f_D(d)=w_d^1,w_d^2,\dots ,w_d^{|V|}$。 查询与文档之间的分数是其对应向量之间的点积：$sim(q,d) = \sum _{i=1}^{|V|}w_q^iw_d^i$。 该公式与 BM25 等传统稀疏检索方法密切相关； 事实上，BM25 可以表述为： - -$$\begin{aligned} \text {BM25}(q,d)&= \sum _{i=1}^{|q|} \text {IDF}(q_i) \times \frac{tf(q_i, d) \times (k_1 + 1)}{tf(q_i, d) + k_1 \cdot \left( 1 - b + b \cdot \frac{|d|}{\text {avgdl}}\right) } \\&= \sum _{j=1}^{|V|} \underbrace{ \mathbb {1}_{q(v_j)} \text {IDF}(v_j)}_{\text {query encoder}} \times \underbrace{\mathbb {1}_{d(v_j)} \frac{tf(v_j, d) \times (k_1 + 1)}{tf(v_j, d) + k_1 \cdot \left( 1 - b + b \cdot \frac{|d|}{\text {avgdl}}\right) }}_{\text {doc encoder}} \\&= \sum _{j=1}^{|V|} f_Q(q)_j \times f_D(d)_j \\ \end{aligned}$$ - -使用 BM25，IDF 和 TF 分量可以被视为查询/文档术语权重。 LSR 的不同之处在于使用神经模型（通常是 Transformer）来预测术语权重。 LSR 与稀疏检索的许多技术兼容，例如倒排索引和附带的查询处理算法。 然而，LSR 权重的差异可能意味着现有的查询处理优化变得不太有用，从而激发新的优化。 - -在本节中，我们介绍一个由三个组件（稀疏编码器、稀疏正则化器、监督）组成的概念框架，它捕获了我们观察到的现有学习稀疏检索方法之间的关键差异。 随后，我们描述了文献中的 LSR 方法如何适应这个框架。 - -稀疏（词法）编码器是学习稀疏检索方法的主要组成部分，用于将查询和段落编码为相同维度的权重向量。与密集编码器相比，稀疏编码器具有三个主要特征。首先，稀疏编码器生成稀疏向量，其中大多数权重为零，这由稀疏正则化器控制。其次，稀疏权重向量的维度通常与词汇表中的术语数量相对应，而密集编码器生成较小的压缩向量，没有明确的术语与维度对应关系。第三，稀疏编码器只产生非负权重，因为稀疏检索方法依赖于传统词汇搜索的堆栈，其中权重始终是非负的术语频率。 - -这些差异可能导致学习稀疏检索（LSR）方法和密集检索方法在行为上有系统性的不同。一些研究表明，LSR模型和一些密集模型在基准测试上表现更好，例如在BEIR基准上，LSR模型和类似ColBERT的令牌级密集模型通常具有更好的泛化能力。近期也有工作提出了混合检索系统，将稀疏表示和密集表示相结合，以获得域内和域外的有效性优势。 - -1.稀疏编码器： 稀疏编码器是对查询和段落进行编码的组件，构建在Transformer主干上。不同的稀疏编码器架构包括： - - a.BINARY： 标记输入中的术语，并考虑术语的存在。 - - b.MLP： 使用多层感知器生成每个输入项的分数，重点关注术语权重。 - - c.expMLP： 在MLP编码器之前进行术语扩展。 - - d.MLM： 根据BERT的屏蔽语言模型生成术语权重。 - - e.clsMLM： 简化版的MLM编码器，仅输出序列中位置0的[CLS]标记的logits。 - -2.稀疏正则化器： 控制权重向量的稀疏性，以提高查询处理效率。包括： - - a.FLOPs： 估计点积运算的浮点运算次数，通过平滑函数计算权重向量之间的点积。 - - b.Lp 范数： 应用于输出向量的规范化，减轻过度拟合。 - - c.Top-K： 保留top-k最高的权重，将其余置零。 - -3.监督： 为了区分LSR方法并考虑效果，引入监督组件，包括负样本和标签。 - - a.负样本： 用于训练的负样本影响性能，可以从语料库中选择难度适中的负样本。 - - b.标签： 标签分为类型（人工、教师、自我）和级别（术语级、段落级）。 大多数方法使用段落级标签。 - -!["图2.1 现有 LSR 方法的定义"](/assets/images/llm/lsr_1.png "图2.1 现有 LSR 方法的定义") - - -在表中，总结了适合概念框架的学习稀疏检索（LSR）方法。这些方法可以根据概念相似性分为四个组： - -A. 无扩展方法： 包括 DeepCT 和 uniCOIL。它们使用MLP编码器对查询和文档中的术语进行加权，Equ2稍作修改。 DeepCT在监督方面使用术语召回进行监督，而uniCOIL使用段落级别标签。 - -B. 无查询扩展方法： 包括 uniCOIL $_{dT5q}$、uniCOIL $_{tilde}$ 和EPIC。它们使用具有文档扩展功能的expMLP或MLM编码器替代A组中的MLP文档编码器。其中，uniCOIL $_{dT5q}$ 和uniCOIL $_{tilde}$ 使用第三方模型进行术语扩展，而EPIC使用训练有素的MLM架构进行端到端的文档扩展和术语评分。 - -C. 无查询扩展或加权方法： 包括DeepImpact、Sparta、TILDE和TILDEv2。它们简化了B组中的方法，通过删除查询编码器来减少查询编码时间，没有查询扩展和加权功能。 - -D. 充分展开和加权方法： 包括Splade-max和distilSplade-max。它们使用共享的MLM架构在查询和文档端进行加权和扩展。这些方法没有选择前k个项，而是使用FLOPs正则化器来稀疏表示。Splade-max和distilSplade-max之间的差异在于监督方法，其中Splade-max使用多个批次的BM25负样本进行训练，而distilSplade-max使用蒸馏技术和硬负样本进行训练。 - -总的来说，这些LSR方法在概念框架下的适用性根据是否进行扩展、加权以及监督方法的不同而有所不同。不同方法之间微小的差异可能涉及非线性选择、术语质量或段落质量函数等方面。 - - -## 3 实验 - -作者对已有的LSR方法进行复现，以下是复现结果，效果采用MRR指标进行评估。 - -!["图3.1 复现结果"](/assets/images/llm/lsr_2.png "图3.1 复现结果") - -## 4 结论 - -### 4.1 研究问题一（RQ1）：LSR论文的结果是否可重现？ - -在复现过程中，我们采用了原始论文和代码中所述的实验设置来训练LSR方法，并将结果与原始工作进行比较。大部分方法的得分要么略高于原始工作，要么与其相当。其中，DeepCT、uniCOIL、EPIC、TILDE $_{v2}$ 和 distilSplade $_{max}$ 的MRR稍高，而DeepImpact 和 uniCOIL $_{dT5q}$ 的复现得分稍低。Sparta方法在原始论文中没有进行MSMarco评估，因此无法与其他方法进行比较。 - -复现的结果显示，DeepCT 和 uniCOIL（没有 docT5query 扩展）方法通常效率较低，而 distilSplade $_{max}$ 方法实现了最高的 MRR。值得注意的是，具有相同架构但不同训练方法的方法之间得分差异显著。例如，将 DeepCT 的监督信号从令牌级权重改为段落级相关性，使得 uniCOIL 方法的 MRR 从 24.6 跃升 28% 至 31.6。这表明监督对性能至关重要，段落级别标签有助于更好地学习术语权重以实现段落级相关性。同样，使用硬负样本挖掘和蒸馏技术将 Splade 模型的 MRR 从 34.0 提高到 37.9。这种监督方法的改变使得 distilSplade $_{max}$ 成为考虑中最有效的 LSR 方法。如果没有这种高级训练，Splade $_{max}$ 的性能与 uniCOIL $_{dT5q}$ 和 uniCOIL $_{tilde}$ 相当。在组 (B) 中，EPIC 方法似乎已经达到其性能极限，其 MRR 显著低于两个 uniCOIL 变体。这可能是因为 EPIC 最初是在 40000 个三元组上进行训练的，而其他方法是在多达数百万个样本上进行训练的。 - -### 4.2 研究问题二（RQ2）：LSR方法如何在最新的高级训练技术下表现？ - - -Splade模型在MSMarco上展现出令人印象深刻的排名得分。尽管这些改进可能是因为架构选择（如查询扩展）等原因，但Splade还通过高级训练过程中挖掘的难负样本和交叉编码器蒸馏等技术受益。实验结果显示，与Splade相同的训练方式使得许多旧方法的效果显著提升。其中，旧的EPIC模型的MRR@10分数增加了36%，变得与Splade相当。 - -由于不同环境可能引起公平比较的困难，作者在一致的环境中进行了所有方法的训练，证明这是有效的。在最有效的监督设置下，即使用蒸馏和硬负片进行训练的 distilSplade $_{max}$ ，作者发现最低效的方法（如DeepCT）和最高效的方法（如distilSplade $_{max}$ ）保持在相同位置。而介于这两个端点之间的方法根据其效果而变化。实验结果显示，多数方法在这种设置下取得了提升，其中EPIC和Sparta的改进最为显著，分别相对于MSMarco提升了8.0和4.2个MRR点。EPIC在训练时间更长和改进的监督下，有效性提升使其在相对排名中跃升为第二位，并与MSMarco上的distilSplade $_{max}$ 相竞争。而在TREC DL 2019和TREC DL 2020上，EPIC和distilSplade $_{max}$ 之间的NDCG@10差距更大。 - -作者还注意到在使用不同架构类型方面，使用MLM架构（无论是在文档端还是查询端）的方法通常在三个数据集上表现更好，然而MLM也会导致显著增加索引大小和延迟。最后，通过引入独立的编码器以减少文档和查询之间的术语激活概率相似性，成功解决了Splade中的延迟问题，进一步支持了这一解决方法的重要性。 - -### 4.3 研究问题三（RQ3）：编码器架构和正则化的选择如何影响结果？ - - -通过在共同训练环境中进行实验，作者量化了不同架构决策（如扩展、加权和正则化）对系统效果和效率的影响。他们发现文档加权对系统的有效性影响最大，而查询加权的影响较为适中，尽管查询加权通过减少无用术语改善了检索延迟。查询和文档扩展之间存在抵消效应，因为一侧扩展时，另一侧的扩展对系统效果的提升会受到影响，表明查询扩展对于LSR系统表现良好并不是必需的。 - -作者的实验结果还表明，不同的正则化方法对有效性和效率影响不大。总体而言，这些发现揭示了在优化LSR方法时，文档加权、查询加权、查询扩展和文档扩展之间的权衡，同时对正则化方法的选择在某些情况下可能不太重要。 - -作者展示了仅在查询端或文档端进行扩展的系统结果。这些结果进一步支持了之前的发现，即查询扩展和文档扩展之间存在抵消效应。他们还指出，将MLM查询编码器替换为MLP查询编码器（distilSplade $_{qMLP}$ ）可以在不显著影响排名指标的情况下降低检索延迟，从而提高效率。这种变化可以被视为更有效的替代方式，进一步强调了提高LSR方法效率的可能性。 +--- +author: 研究生鱼皮-yjf +icon: pen-to-square +date: 2023-08-23 +category: + - rag +tag: + - 检索 + - rag +# sticky: 10 +--- + +# 学习稀疏检索的统一框架 + +学习稀疏检索是一种结合机器学习和信息检索的方法，旨在优化文本检索效果。通过学习模型，将查询和文档映射到稀疏表示空间，实现高效的检索。在训练阶段，利用已标记的查询-文档对和相关性标签，通过优化模型参数，学习如何选择、加权和组合特征，使相关文档在稀疏表示中更接近查询。学习稀疏检索方法可应用于大规模信息检索任务，如搜索引擎和推荐系统，以提高检索效率和准确性。 + + + +## 1 背景和目的 + +自然语言查询的文本检索是信息检索（IR）系统的核心任务。之前的研究采用了两阶段的流程来解决这个问题，首先通过快速的检索器从文档集合中检索出一组初始文档，然后由更复杂的模型进一步重新排名。对于第一阶段的检索，神经网络的密集表示在语义匹配方面具有很大的潜力，在许多自然语言处理任务中超越了稀疏方法，但在强调长文档检索和精确匹配的情况下不一定成立。此外，对于极大规模（例如100亿）的候选文档集合，密集方法不得不在效率与准确性之间权衡。传统的基于术语的稀疏表示，也称为词袋（BoW），如TF-IDF和BM25，可以有效地进行字面匹配，因此在工业级IR系统中扮演着核心角色。然而，传统的基于术语的方法通常被认为表示能力不足，不适用于语义级匹配。 + +学习稀疏检索最早由Zamani等人在论文《From Neural Re-Ranking to Neural Ranking: Learning a Sparse Representation for Inverted Indexing》中提出。SNRM（Standalone Neural Ranking Model）是一种独立的神经排序模型，旨在解决神经排序模型在效率方面的问题。它通过引入稀疏属性，为每个查询和文档学习潜在的稀疏表示。其中“潜在”Token在反向索引过程中扮演传统术语的角色。关于SNRM的一个挑战是它失去了原始术语的可解释性，这对于工业系统至关重要。 + +该论文研究了学习稀疏检索（LSR）方法，这是一类用于生成查询和文档稀疏词汇表示的首阶段检索方法，用于倒排索引。虽然有许多LSR方法已被引入，其中Splade模型在MSMarco数据集上取得了最先进的性能，但不同的实验设置和配置难以进行有效的比较和洞察。在这项工作中，作者分析了现有的LSR方法，识别出关键组成部分，并建立了一个统一的LSR框架，将所有LSR方法放置在一个统一的视角下。然后，作者重新实现了所有重要的方法，并在相同环境中重新训练，以便量化不同框架组成部分如何影响效果和效率。研究发现：（1）文档词项加权对方法的效果最具影响，（2）查询加权略有正面影响，（3）文档扩展和查询扩展效果相互抵消。因此，作者提出了如何从最先进的模型中移除查询扩展，以显著降低延迟，同时在MSMarco和TripClick数据集上保持性能。该工作旨在提供一种统一的LSR框架，深入分析了不同组成部分对效果和效率的影响，并为LSR方法的进一步优化提供了指导。 + +## 2 统一框架的建立 + +学习稀疏检索 (LSR) 使用查询编码器 $f_Q$和$f_D$文档编码器 将查询和文档投影到词汇大小的稀疏向量： $w_q=f_Q(q)=w_q^1,w_q^2,\dots ,w_q^{|V|}$和$w_d=f_D(d)=w_d^1,w_d^2,\dots ,w_d^{|V|}$。 查询与文档之间的分数是其对应向量之间的点积：$sim(q,d) = \sum _{i=1}^{|V|}w_q^iw_d^i$。 该公式与 BM25 等传统稀疏检索方法密切相关； 事实上，BM25 可以表述为： + +$$\begin{aligned} \text {BM25}(q,d)&= \sum _{i=1}^{|q|} \text {IDF}(q_i) \times \frac{tf(q_i, d) \times (k_1 + 1)}{tf(q_i, d) + k_1 \cdot \left( 1 - b + b \cdot \frac{|d|}{\text {avgdl}}\right) } \\&= \sum _{j=1}^{|V|} \underbrace{ \mathbb {1}_{q(v_j)} \text {IDF}(v_j)}_{\text {query encoder}} \times \underbrace{\mathbb {1}_{d(v_j)} \frac{tf(v_j, d) \times (k_1 + 1)}{tf(v_j, d) + k_1 \cdot \left( 1 - b + b \cdot \frac{|d|}{\text {avgdl}}\right) }}_{\text {doc encoder}} \\&= \sum _{j=1}^{|V|} f_Q(q)_j \times f_D(d)_j \\ \end{aligned}$$ + +使用 BM25，IDF 和 TF 分量可以被视为查询/文档术语权重。 LSR 的不同之处在于使用神经模型（通常是 Transformer）来预测术语权重。 LSR 与稀疏检索的许多技术兼容，例如倒排索引和附带的查询处理算法。 然而，LSR 权重的差异可能意味着现有的查询处理优化变得不太有用，从而激发新的优化。 + +在本节中，我们介绍一个由三个组件（稀疏编码器、稀疏正则化器、监督）组成的概念框架，它捕获了我们观察到的现有学习稀疏检索方法之间的关键差异。 随后，我们描述了文献中的 LSR 方法如何适应这个框架。 + +稀疏（词法）编码器是学习稀疏检索方法的主要组成部分，用于将查询和段落编码为相同维度的权重向量。与密集编码器相比，稀疏编码器具有三个主要特征。首先，稀疏编码器生成稀疏向量，其中大多数权重为零，这由稀疏正则化器控制。其次，稀疏权重向量的维度通常与词汇表中的术语数量相对应，而密集编码器生成较小的压缩向量，没有明确的术语与维度对应关系。第三，稀疏编码器只产生非负权重，因为稀疏检索方法依赖于传统词汇搜索的堆栈，其中权重始终是非负的术语频率。 + +这些差异可能导致学习稀疏检索（LSR）方法和密集检索方法在行为上有系统性的不同。一些研究表明，LSR模型和一些密集模型在基准测试上表现更好，例如在BEIR基准上，LSR模型和类似ColBERT的令牌级密集模型通常具有更好的泛化能力。近期也有工作提出了混合检索系统，将稀疏表示和密集表示相结合，以获得域内和域外的有效性优势。 + +1.稀疏编码器： 稀疏编码器是对查询和段落进行编码的组件，构建在Transformer主干上。不同的稀疏编码器架构包括： + + a.BINARY： 标记输入中的术语，并考虑术语的存在。 + + b.MLP： 使用多层感知器生成每个输入项的分数，重点关注术语权重。 + + c.expMLP： 在MLP编码器之前进行术语扩展。 + + d.MLM： 根据BERT的屏蔽语言模型生成术语权重。 + + e.clsMLM： 简化版的MLM编码器，仅输出序列中位置0的[CLS]标记的logits。 + +2.稀疏正则化器： 控制权重向量的稀疏性，以提高查询处理效率。包括： + + a.FLOPs： 估计点积运算的浮点运算次数，通过平滑函数计算权重向量之间的点积。 + + b.Lp 范数： 应用于输出向量的规范化，减轻过度拟合。 + + c.Top-K： 保留top-k最高的权重，将其余置零。 + +3.监督： 为了区分LSR方法并考虑效果，引入监督组件，包括负样本和标签。 + + a.负样本： 用于训练的负样本影响性能，可以从语料库中选择难度适中的负样本。 + + b.标签： 标签分为类型（人工、教师、自我）和级别（术语级、段落级）。 大多数方法使用段落级标签。 + +!["图2.1 现有 LSR 方法的定义"](/assets/images/llm/lsr_1.png "图2.1 现有 LSR 方法的定义") + + +在表中，总结了适合概念框架的学习稀疏检索（LSR）方法。这些方法可以根据概念相似性分为四个组： + +A. 无扩展方法： 包括 DeepCT 和 uniCOIL。它们使用MLP编码器对查询和文档中的术语进行加权，Equ2稍作修改。 DeepCT在监督方面使用术语召回进行监督，而uniCOIL使用段落级别标签。 + +B. 无查询扩展方法： 包括 uniCOIL $_{dT5q}$、uniCOIL $_{tilde}$ 和EPIC。它们使用具有文档扩展功能的expMLP或MLM编码器替代A组中的MLP文档编码器。其中，uniCOIL $_{dT5q}$ 和uniCOIL $_{tilde}$ 使用第三方模型进行术语扩展，而EPIC使用训练有素的MLM架构进行端到端的文档扩展和术语评分。 + +C. 无查询扩展或加权方法： 包括DeepImpact、Sparta、TILDE和TILDEv2。它们简化了B组中的方法，通过删除查询编码器来减少查询编码时间，没有查询扩展和加权功能。 + +D. 充分展开和加权方法： 包括Splade-max和distilSplade-max。它们使用共享的MLM架构在查询和文档端进行加权和扩展。这些方法没有选择前k个项，而是使用FLOPs正则化器来稀疏表示。Splade-max和distilSplade-max之间的差异在于监督方法，其中Splade-max使用多个批次的BM25负样本进行训练，而distilSplade-max使用蒸馏技术和硬负样本进行训练。 + +总的来说，这些LSR方法在概念框架下的适用性根据是否进行扩展、加权以及监督方法的不同而有所不同。不同方法之间微小的差异可能涉及非线性选择、术语质量或段落质量函数等方面。 + + +## 3 实验 + +作者对已有的LSR方法进行复现，以下是复现结果，效果采用MRR指标进行评估。 + +!["图3.1 复现结果"](/assets/images/llm/lsr_2.png "图3.1 复现结果") + +## 4 结论 + +### 4.1 研究问题一（RQ1）：LSR论文的结果是否可重现？ + +在复现过程中，我们采用了原始论文和代码中所述的实验设置来训练LSR方法，并将结果与原始工作进行比较。大部分方法的得分要么略高于原始工作，要么与其相当。其中，DeepCT、uniCOIL、EPIC、TILDE $_{v2}$ 和 distilSplade $_{max}$ 的MRR稍高，而DeepImpact 和 uniCOIL $_{dT5q}$ 的复现得分稍低。Sparta方法在原始论文中没有进行MSMarco评估，因此无法与其他方法进行比较。 + +复现的结果显示，DeepCT 和 uniCOIL（没有 docT5query 扩展）方法通常效率较低，而 distilSplade $_{max}$ 方法实现了最高的 MRR。值得注意的是，具有相同架构但不同训练方法的方法之间得分差异显著。例如，将 DeepCT 的监督信号从令牌级权重改为段落级相关性，使得 uniCOIL 方法的 MRR 从 24.6 跃升 28% 至 31.6。这表明监督对性能至关重要，段落级别标签有助于更好地学习术语权重以实现段落级相关性。同样，使用硬负样本挖掘和蒸馏技术将 Splade 模型的 MRR 从 34.0 提高到 37.9。这种监督方法的改变使得 distilSplade $_{max}$ 成为考虑中最有效的 LSR 方法。如果没有这种高级训练，Splade $_{max}$ 的性能与 uniCOIL $_{dT5q}$ 和 uniCOIL $_{tilde}$ 相当。在组 (B) 中，EPIC 方法似乎已经达到其性能极限，其 MRR 显著低于两个 uniCOIL 变体。这可能是因为 EPIC 最初是在 40000 个三元组上进行训练的，而其他方法是在多达数百万个样本上进行训练的。 + +### 4.2 研究问题二（RQ2）：LSR方法如何在最新的高级训练技术下表现？ + + +Splade模型在MSMarco上展现出令人印象深刻的排名得分。尽管这些改进可能是因为架构选择（如查询扩展）等原因，但Splade还通过高级训练过程中挖掘的难负样本和交叉编码器蒸馏等技术受益。实验结果显示，与Splade相同的训练方式使得许多旧方法的效果显著提升。其中，旧的EPIC模型的MRR@10分数增加了36%，变得与Splade相当。 + +由于不同环境可能引起公平比较的困难，作者在一致的环境中进行了所有方法的训练，证明这是有效的。在最有效的监督设置下，即使用蒸馏和硬负片进行训练的 distilSplade $_{max}$ ，作者发现最低效的方法（如DeepCT）和最高效的方法（如distilSplade $_{max}$ ）保持在相同位置。而介于这两个端点之间的方法根据其效果而变化。实验结果显示，多数方法在这种设置下取得了提升，其中EPIC和Sparta的改进最为显著，分别相对于MSMarco提升了8.0和4.2个MRR点。EPIC在训练时间更长和改进的监督下，有效性提升使其在相对排名中跃升为第二位，并与MSMarco上的distilSplade $_{max}$ 相竞争。而在TREC DL 2019和TREC DL 2020上，EPIC和distilSplade $_{max}$ 之间的NDCG@10差距更大。 + +作者还注意到在使用不同架构类型方面，使用MLM架构（无论是在文档端还是查询端）的方法通常在三个数据集上表现更好，然而MLM也会导致显著增加索引大小和延迟。最后，通过引入独立的编码器以减少文档和查询之间的术语激活概率相似性，成功解决了Splade中的延迟问题，进一步支持了这一解决方法的重要性。 + +### 4.3 研究问题三（RQ3）：编码器架构和正则化的选择如何影响结果？ + + +通过在共同训练环境中进行实验，作者量化了不同架构决策（如扩展、加权和正则化）对系统效果和效率的影响。他们发现文档加权对系统的有效性影响最大，而查询加权的影响较为适中，尽管查询加权通过减少无用术语改善了检索延迟。查询和文档扩展之间存在抵消效应，因为一侧扩展时，另一侧的扩展对系统效果的提升会受到影响，表明查询扩展对于LSR系统表现良好并不是必需的。 + +作者的实验结果还表明，不同的正则化方法对有效性和效率影响不大。总体而言，这些发现揭示了在优化LSR方法时，文档加权、查询加权、查询扩展和文档扩展之间的权衡，同时对正则化方法的选择在某些情况下可能不太重要。 + +作者展示了仅在查询端或文档端进行扩展的系统结果。这些结果进一步支持了之前的发现，即查询扩展和文档扩展之间存在抵消效应。他们还指出，将MLM查询编码器替换为MLP查询编码器（distilSplade $_{qMLP}$ ）可以在不显著影响排名指标的情况下降低检索延迟，从而提高效率。这种变化可以被视为更有效的替代方式，进一步强调了提高LSR方法效率的可能性。 diff --git a/src/zh/posts/rag/README.md b/src/zh/posts/rag/README.md new file mode 100644 index 0000000000..b90719e2ae --- /dev/null +++ b/src/zh/posts/rag/README.md @@ -0,0 +1,12 @@ +--- +title: RAG +icon: puzzle-piece +index: false +article: false +category: + - rag +tag: + - rag +dir: + order: 1 +--- \ No newline at end of file diff --git a/src/zh/posts/llm/RetrieveTextGeneration.md b/src/zh/posts/rag/RetrieveTextGeneration.md similarity index 99% rename from src/zh/posts/llm/RetrieveTextGeneration.md rename to src/zh/posts/rag/RetrieveTextGeneration.md index 4a9a365fb6..68d4a4ff4a 100644 --- a/src/zh/posts/llm/RetrieveTextGeneration.md +++ b/src/zh/posts/rag/RetrieveTextGeneration.md @@ -3,10 +3,11 @@ author: 最后的开神-wkyc icon: pen-to-square date: 2023-09-21 category: - - 语言模型 + - rag tag: - 检索 - 文本生成 + - rag # sticky: 10 --- diff --git a/src/zh/posts/llm/GPT4Reason.md b/src/zh/posts/reasoning/GPT4Reason.md similarity index 99% rename from src/zh/posts/llm/GPT4Reason.md rename to src/zh/posts/reasoning/GPT4Reason.md index 0cc6ef7cff..b1b9df64ed 100644 --- a/src/zh/posts/llm/GPT4Reason.md +++ b/src/zh/posts/reasoning/GPT4Reason.md @@ -5,7 +5,7 @@ date: 2023-08-13 shortTitle: 探究GPT4的推理能力 title: 探究GPT-4到底有没有推理能力？ category: - - 语言模型 + - 推理方法 tag: - GPT-4 - Reasoning diff --git a/src/zh/posts/reasoning/README.md b/src/zh/posts/reasoning/README.md new file mode 100644 index 0000000000..7ee3002fcc --- /dev/null +++ b/src/zh/posts/reasoning/README.md @@ -0,0 +1,12 @@ +--- +title: 推理方法 +icon: gem +index: false +article: false +category: + - 推理方法 +tag: + - Reasoning +dir: + order: 7 +--- \ No newline at end of file diff --git a/src/zh/posts/prompt/llmReasonSurvey.md b/src/zh/posts/reasoning/llmReasonSurvey.md similarity index 99% rename from src/zh/posts/prompt/llmReasonSurvey.md rename to src/zh/posts/reasoning/llmReasonSurvey.md index 375a597a27..e57ae04f5d 100644 --- a/src/zh/posts/prompt/llmReasonSurvey.md +++ b/src/zh/posts/reasoning/llmReasonSurvey.md @@ -5,7 +5,7 @@ date: 2023-07-14 shortTitle: LLM推理综述 title: 论文分享：基于提示学习的大型语言模型推理综述 category: - - 提示技术 + - 推理方法 tag: - Survey - LLM diff --git a/src/zh/posts/token/README.md b/src/zh/posts/token/README.md index 4aa84861fe..0474cb9505 100644 --- a/src/zh/posts/token/README.md +++ b/src/zh/posts/token/README.md @@ -8,5 +8,5 @@ category: tag: - token dir: - order: 6 + order: 8 --- \ No newline at end of file diff --git a/src/zh/posts/llm/Token-Crisis.md b/src/zh/posts/token/Token-Crisis.md similarity index 99% rename from src/zh/posts/llm/Token-Crisis.md rename to src/zh/posts/token/Token-Crisis.md index 9070ddbfea..6d24c924a3 100644 --- a/src/zh/posts/llm/Token-Crisis.md +++ b/src/zh/posts/token/Token-Crisis.md @@ -4,7 +4,7 @@ icon: pen-to-square date: 2023-05-31 shortTitle: Token危机 category: - - 语言模型 + - Token tag: - 模型 - 深度学习 From 1fc195ff5baf91e45f0d74e3d2dd821366362ca2 Mon Sep 17 00:00:00 2001 From: sheli00 <44807582+sheli00@users.noreply.github.com> Date: Tue, 31 Oct 2023 15:46:45 +0800 Subject: [PATCH 2/4] add category (#167) --- src/zh/README.md | 4 ++-- src/zh/posts/README.md | 2 +- src/zh/posts/reasoning/GPT4Reason.md | 2 +- src/zh/posts/reasoning/README.md | 4 ++-- src/zh/posts/reasoning/llmReasonSurvey.md | 2 +- 5 files changed, 7 insertions(+), 7 deletions(-) diff --git a/src/zh/README.md b/src/zh/README.md index 19634549ee..cddeedeb99 100644 --- a/src/zh/README.md +++ b/src/zh/README.md @@ -36,8 +36,8 @@ projects: link: /zh/category/数据集/ - icon: puzzle-piece - name: 推理方法 - link: /zh/category/推理方法/ + name: 大模型推理 + link: /zh/category/大模型推理/ - icon: puzzle-piece name: Token diff --git a/src/zh/posts/README.md b/src/zh/posts/README.md index 9f4d10faec..5c14e0ad64 100644 --- a/src/zh/posts/README.md +++ b/src/zh/posts/README.md @@ -15,5 +15,5 @@ article: false - [微调技术](./finetune/) - [评估方法](./eval/) - [数据集](./dataset/) -- [推理方法](./reasoning/) +- [大模型推理](./reasoning/) - [Token](./token/) \ No newline at end of file diff --git a/src/zh/posts/reasoning/GPT4Reason.md b/src/zh/posts/reasoning/GPT4Reason.md index b1b9df64ed..04ea4a6a29 100644 --- a/src/zh/posts/reasoning/GPT4Reason.md +++ b/src/zh/posts/reasoning/GPT4Reason.md @@ -5,7 +5,7 @@ date: 2023-08-13 shortTitle: 探究GPT4的推理能力 title: 探究GPT-4到底有没有推理能力？ category: - - 推理方法 + - 大模型推理 tag: - GPT-4 - Reasoning diff --git a/src/zh/posts/reasoning/README.md b/src/zh/posts/reasoning/README.md index 7ee3002fcc..d73ddc5d43 100644 --- a/src/zh/posts/reasoning/README.md +++ b/src/zh/posts/reasoning/README.md @@ -1,10 +1,10 @@ --- -title: 推理方法 +title: 大模型推理 icon: gem index: false article: false category: - - 推理方法 + - 大模型推理 tag: - Reasoning dir: diff --git a/src/zh/posts/reasoning/llmReasonSurvey.md b/src/zh/posts/reasoning/llmReasonSurvey.md index e57ae04f5d..a050dfa603 100644 --- a/src/zh/posts/reasoning/llmReasonSurvey.md +++ b/src/zh/posts/reasoning/llmReasonSurvey.md @@ -5,7 +5,7 @@ date: 2023-07-14 shortTitle: LLM推理综述 title: 论文分享：基于提示学习的大型语言模型推理综述 category: - - 推理方法 + - 大模型推理 tag: - Survey - LLM From 457714b4b6f050f05de0df2948808928b4c2f29a Mon Sep 17 00:00:00 2001 From: sheli00 <44807582+sheli00@users.noreply.github.com> Date: Tue, 31 Oct 2023 15:47:43 +0800 Subject: [PATCH 3/4] Update README.md (#168) --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 460f17708b..2a5a51624d 100644 --- a/README.md +++ b/README.md @@ -19,7 +19,7 @@ - 微调技术(`Finetune`) - 评估方法(`Eval`) - 数据集(`Dataset`) -- 推理方法(`Reasoning`) +- 大模型推理(`Reasoning`) - `Token` 在 [src/zh/posts/${category}](https://github.com/HUSTAI/HUSTAI.github.io/tree/main/src/zh/posts/) 目录下增加一个新的 `md` 文件，参考[配置](https://theme-hope.vuejs.press/zh/config/frontmatter/info.html)来设置 `Frontmatter` From 103b19480ce990ddb763090af3376dbb7b2c44ee Mon Sep 17 00:00:00 2001 From: shbone <598924626@qq.com> Date: Wed, 1 Nov 2023 11:08:20 +0800 Subject: [PATCH 4/4] docs:shb update category and note --- README.md | 2 +- src/zh/README.md | 4 +- src/zh/posts/README.md | 4 +- src/zh/posts/eval/M3KE.md | 8 +- src/zh/posts/rag/README.md | 2 +- src/zh/posts/{prompt => reasoning}/CoT.md | 176 +++++------ src/zh/posts/{prompt => reasoning}/GoT.md | 0 .../{prompt => reasoning}/MathPrompter.md | 296 ++++++++--------- src/zh/posts/{prompt => reasoning}/SoT.md | 298 +++++++++--------- src/zh/posts/{prompt => reasoning}/ToT.md | 216 ++++++------- src/zh/posts/{prompt => reasoning}/thor.md | 0 src/zh/posts/token/README.md | 2 +- 12 files changed, 504 insertions(+), 504 deletions(-) rename src/zh/posts/{prompt => reasoning}/CoT.md (97%) rename src/zh/posts/{prompt => reasoning}/GoT.md (100%) rename src/zh/posts/{prompt => reasoning}/MathPrompter.md (98%) rename src/zh/posts/{prompt => reasoning}/SoT.md (98%) rename src/zh/posts/{prompt => reasoning}/ToT.md (98%) rename src/zh/posts/{prompt => reasoning}/thor.md (100%) diff --git a/README.md b/README.md index 2a5a51624d..d3a11380ce 100644 --- a/README.md +++ b/README.md @@ -13,7 +13,7 @@ `category` 请从以下类别中选择 -- `RAG` +- 检索增强生成(`RAG`) - 语言模型(`LLM`) - 提示技术(`Prompt`) - 微调技术(`Finetune`) diff --git a/src/zh/README.md b/src/zh/README.md index cddeedeb99..b483601269 100644 --- a/src/zh/README.md +++ b/src/zh/README.md @@ -12,7 +12,7 @@ article: false projects: - icon: circle-question - name: RAG + name: 检索增强生成(RAG) link: /zh/category/rag/ - icon: circle-question @@ -40,7 +40,7 @@ projects: link: /zh/category/大模型推理/ - icon: puzzle-piece - name: Token + name: Token、分词 link: /zh/category/token/ footer: 分享知识-分享快乐 diff --git a/src/zh/posts/README.md b/src/zh/posts/README.md index 5c14e0ad64..6a0eb0cebc 100644 --- a/src/zh/posts/README.md +++ b/src/zh/posts/README.md @@ -9,11 +9,11 @@ article: false 本页面包含一些论文分享的分类： -- [RAG](./rag/) +- [检索增强生成(RAG)](./rag/) - [语言模型](./llm/) - [提示技术](./prompt/) - [微调技术](./finetune/) - [评估方法](./eval/) - [数据集](./dataset/) - [大模型推理](./reasoning/) -- [Token](./token/) \ No newline at end of file +- [Token、分词](./token/) \ No newline at end of file diff --git a/src/zh/posts/eval/M3KE.md b/src/zh/posts/eval/M3KE.md index fe137c7d2e..ff6af998c8 100644 --- a/src/zh/posts/eval/M3KE.md +++ b/src/zh/posts/eval/M3KE.md @@ -7,11 +7,11 @@ date: 2023-07-08 tag: - 语言模型 - 评估 -shortTitle: M3KE数据集分享 +shortTitle: M3KE-大模型中文评估 --- -# M3KE评估数据集分享 +# M3KE-大模型中文能力综合评估 M3KE数据集是一种针对大语言模型的多层次、多主题的知识评估数据集，旨在衡量中文大型语言模型在零样本和少样本设置中获取知识的能力。 @@ -26,12 +26,12 @@ M3KE数据集是一种针对大语言模型的多层次、多主题的知识评 ::: -## 1 数据集数据 +## 1 评估数据 M3KE 收集了 20,477 个真人标准化考试题目（包含 4 个候选答案），覆盖 71 个任务，包括小学、初中、高中、大学、研究生入学考试题目，涉及人文、历史、政治、法律、教育、心理学、科学、工程技术、艺术等学科。 ![图1.1 M3KE数据集中任务分布](/assets/images/eval/M3KE_1.png "图1.1 M3KE数据集中任务分布" =430x400) -## 2 数据集优势 +## 2 评估优势 （1） 契合中国教育体系，覆盖多教育阶段 研究人员模仿中国学生的教育经历，即小学、初中、高中、大学等主要教育阶段，旨在评估中文大模型在不同教育阶段下的表现。由于每个教育阶段需要掌握的知识点不同（例如，在语文学科中，小学和初中的知识或考点存在明显的差异），因此，M3KE 在不同教育阶段会包含相同的学科。为了提高数据集中学科知识点的覆盖范围，研究人员选择了中国升学考试中的统考试题，包括小升初、中考、高考，研究生入学考试和中国公务员考试等真题题目。 （2） 覆盖多学科领域 diff --git a/src/zh/posts/rag/README.md b/src/zh/posts/rag/README.md index b90719e2ae..3ebba10c2e 100644 --- a/src/zh/posts/rag/README.md +++ b/src/zh/posts/rag/README.md @@ -1,5 +1,5 @@ --- -title: RAG +title: 检索增强生成(RAG) icon: puzzle-piece index: false article: false diff --git a/src/zh/posts/prompt/CoT.md b/src/zh/posts/reasoning/CoT.md similarity index 97% rename from src/zh/posts/prompt/CoT.md rename to src/zh/posts/reasoning/CoT.md index 6dfea5fb94..267691d339 100644 --- a/src/zh/posts/prompt/CoT.md +++ b/src/zh/posts/reasoning/CoT.md @@ -1,88 +1,88 @@ ---- -author: lx -icon: wand-magic-sparkles -date: 2023-06-05 -shortTitle: "Chain-of-Thought: 思维链" -category: - - 提示技术 -tag: - - 推理 - - LLM - - CoT ---- - -# Chain-of-Thought: 思维链 - -该文介绍了 `Chain-of-Thought: 思维链` 框架，结合 `in-context`, `few-shot prompting` 以及多步中间推理，通过大模型来改善数学计算、常识推理的效果。 - - - -::: tip -论文题目：Chain-of-Thought Prompting Elicits Reasoning in Large Language Models -作者：Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed H. Chi, Quoc V. Le, Denny Zhou -机构：Google -::: - - - - - ---- - -## 1 背景介绍 - -> 语言模型的本质是对任意一段文本序列的概率进行建模 - -用一个训练好的大语言模型求解推理任务的几种范式： - -### 1.1 Zero-Shot - -![图1.1 Zero-Shot](/assets/images/prompt/cot1.png "图1.1 Zero-Shot" =550x) - -这里语言模型的输入就是一道数学题，连接上一个字符串 `The answer is`，然后让语言模型帮助续写。续写的答案就是80。 - -### 1.2 Zero-Shot-CoT - -![图1.2 Zero-Shot-CoT](/assets/images/prompt/cot2.png "图1.2 Zero-Shot-CoT" =550x) - -`Zero-Shot-CoT` 在 `Zero-Shot` 的基础上增加了一句 `Let's think step by step.`，大语言模型会自动续写推理过程并得出最后的答案。 - -### 1.3 Manual-CoT - -![图1.3 Manual-CoT](/assets/images/prompt/cot3.png "图1.3 Manual-CoT" =400x) - -在输入问题之前，**手动设计**一些问题和答案的样例。`Manual-CoT` 比 `Zero-Shot-CoT` 的性能要好，因为在输入端提供了问题，推理，答案的样例供参考。然而为了提供这些样例就需要人工设计，这就增加了人工的成本。 - -### 1.4 Auto-CoT - -![图1.4 Auto-CoT](/assets/images/prompt/cot4.png "图1.4 Auto-CoT" =400x) - -如何将人工设计样例的过程自动化？步骤如下： -（1）通过多样性选择有代表性的问题 -（2）对于每一个采样的问题，接上 `Let's think step by step.`，直接丢给语言模型，让它帮我们生成中间推理步骤和答案。然后把所有采样的问题和模型自动生成的推理步骤和答案全部拼接在一起来构成 `Few-Shot-Learning` 所需要的样例，最后跟上下面需要求解的问题，一起丢给语言模型，让其帮我们续写。 - - -## 2 思路 - -结合 `in-context`, `few-shot prompting` 以及多步中间推理，通过大模型来改善数学计算、常识推理的效果 - -![图2.1 CoT](/assets/images/prompt/cot5.png "图2.1 CoT" =600x) - -`CoT` 思维链的灵感来源于人做推理的过程，作者借鉴了这个过程，通过设计类似于思维链来激发大模型，使之拥有推理能力，并且能由于这个有逻辑性的思维链的存在，多步的中间推到可以得到最终的正确答案。 - -![图2.2 CoT Examplars](/assets/images/prompt/cot6.png "图2.2 CoT Examplars" =600x) - -## 3 实验结果 - -![图3.1 不同模型实验结果](/assets/images/prompt/cot7.png "图3.1 不同模型实验结果" =480x) - -100B（1000亿参数）参数量以下的模型效果不好，侧面反映了他们的instruct fine-tune不够，COT很难激发他的in-context 推理能力。而在100B以上模型效果很好，甚至超过了之前基于监督训练的SOTA模型。 - - -## 4 参考 - - +--- +author: lx +icon: wand-magic-sparkles +date: 2023-06-05 +shortTitle: "Chain-of-Thought: 思维链" +category: + - 提示技术 +tag: + - 推理 + - LLM + - CoT +--- + +# Chain-of-Thought: 思维链 + +该文介绍了 `Chain-of-Thought: 思维链` 框架，结合 `in-context`, `few-shot prompting` 以及多步中间推理，通过大模型来改善数学计算、常识推理的效果。 + + + +::: tip +论文题目：Chain-of-Thought Prompting Elicits Reasoning in Large Language Models +作者：Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed H. Chi, Quoc V. Le, Denny Zhou +机构：Google +::: + + + + + +--- + +## 1 背景介绍 + +> 语言模型的本质是对任意一段文本序列的概率进行建模 + +用一个训练好的大语言模型求解推理任务的几种范式： + +### 1.1 Zero-Shot + +![图1.1 Zero-Shot](/assets/images/prompt/cot1.png "图1.1 Zero-Shot" =550x) + +这里语言模型的输入就是一道数学题，连接上一个字符串 `The answer is`，然后让语言模型帮助续写。续写的答案就是80。 + +### 1.2 Zero-Shot-CoT + +![图1.2 Zero-Shot-CoT](/assets/images/prompt/cot2.png "图1.2 Zero-Shot-CoT" =550x) + +`Zero-Shot-CoT` 在 `Zero-Shot` 的基础上增加了一句 `Let's think step by step.`，大语言模型会自动续写推理过程并得出最后的答案。 + +### 1.3 Manual-CoT + +![图1.3 Manual-CoT](/assets/images/prompt/cot3.png "图1.3 Manual-CoT" =400x) + +在输入问题之前，**手动设计**一些问题和答案的样例。`Manual-CoT` 比 `Zero-Shot-CoT` 的性能要好，因为在输入端提供了问题，推理，答案的样例供参考。然而为了提供这些样例就需要人工设计，这就增加了人工的成本。 + +### 1.4 Auto-CoT + +![图1.4 Auto-CoT](/assets/images/prompt/cot4.png "图1.4 Auto-CoT" =400x) + +如何将人工设计样例的过程自动化？步骤如下： +（1）通过多样性选择有代表性的问题 +（2）对于每一个采样的问题，接上 `Let's think step by step.`，直接丢给语言模型，让它帮我们生成中间推理步骤和答案。然后把所有采样的问题和模型自动生成的推理步骤和答案全部拼接在一起来构成 `Few-Shot-Learning` 所需要的样例，最后跟上下面需要求解的问题，一起丢给语言模型，让其帮我们续写。 + + +## 2 思路 + +结合 `in-context`, `few-shot prompting` 以及多步中间推理，通过大模型来改善数学计算、常识推理的效果 + +![图2.1 CoT](/assets/images/prompt/cot5.png "图2.1 CoT" =600x) + +`CoT` 思维链的灵感来源于人做推理的过程，作者借鉴了这个过程，通过设计类似于思维链来激发大模型，使之拥有推理能力，并且能由于这个有逻辑性的思维链的存在，多步的中间推到可以得到最终的正确答案。 + +![图2.2 CoT Examplars](/assets/images/prompt/cot6.png "图2.2 CoT Examplars" =600x) + +## 3 实验结果 + +![图3.1 不同模型实验结果](/assets/images/prompt/cot7.png "图3.1 不同模型实验结果" =480x) + +100B（1000亿参数）参数量以下的模型效果不好，侧面反映了他们的instruct fine-tune不够，COT很难激发他的in-context 推理能力。而在100B以上模型效果很好，甚至超过了之前基于监督训练的SOTA模型。 + + +## 4 参考 + + diff --git a/src/zh/posts/prompt/GoT.md b/src/zh/posts/reasoning/GoT.md similarity index 100% rename from src/zh/posts/prompt/GoT.md rename to src/zh/posts/reasoning/GoT.md diff --git a/src/zh/posts/prompt/MathPrompter.md b/src/zh/posts/reasoning/MathPrompter.md similarity index 98% rename from src/zh/posts/prompt/MathPrompter.md rename to src/zh/posts/reasoning/MathPrompter.md index 74c7253087..ebfb64053a 100644 --- a/src/zh/posts/prompt/MathPrompter.md +++ b/src/zh/posts/reasoning/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 - -为了在一定程度上解决上述差距，从人类解决数学题的方式中得到启发，将复杂问题分解为更简单的多步程序，并利用多种方式在每一个步骤中对方法进行验证。 - -![图2.1 MathPrompter 工作流](/assets/images/prompt/MathPrompter1.png =550x) - -由于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` 进行评估，其中的数学问题专门用来测试机器学习模型进行复杂算术运算和推理的能力，要求应用多种算术运算和逻辑推理才能成功地解决。 - -![图3.1 MultiArith实验结果](/assets/images/prompt/MathPrompter2.png =550x) - -在 `MultiArith` 数据集上的准确率结果显示，`MathPrompter`的表现优于所有的 `Zero-shot` 和 `Zero-shot-CoT` 基线，将准确率从 $78.7\%$ 提升到 $92.5\%$ - -可以看到，基于 $175B$ 参数 `GPT3 DaVinci` 的 `MathPrompter` 模型的性能与 $540B$ 参数模型以及 `SOTA` 的 `Few-shot-CoT` 方法相当。 - -![图3.2 效果比较](/assets/images/prompt/MathPrompter3.png =550x) - -从上表可以看到，`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 + +为了在一定程度上解决上述差距，从人类解决数学题的方式中得到启发，将复杂问题分解为更简单的多步程序，并利用多种方式在每一个步骤中对方法进行验证。 + +![图2.1 MathPrompter 工作流](/assets/images/prompt/MathPrompter1.png =550x) + +由于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` 进行评估，其中的数学问题专门用来测试机器学习模型进行复杂算术运算和推理的能力，要求应用多种算术运算和逻辑推理才能成功地解决。 + +![图3.1 MultiArith实验结果](/assets/images/prompt/MathPrompter2.png =550x) + +在 `MultiArith` 数据集上的准确率结果显示，`MathPrompter`的表现优于所有的 `Zero-shot` 和 `Zero-shot-CoT` 基线，将准确率从 $78.7\%$ 提升到 $92.5\%$ + +可以看到，基于 $175B$ 参数 `GPT3 DaVinci` 的 `MathPrompter` 模型的性能与 $540B$ 参数模型以及 `SOTA` 的 `Few-shot-CoT` 方法相当。 + +![图3.2 效果比较](/assets/images/prompt/MathPrompter3.png =550x) + +从上表可以看到，`MathPrompter`的设计可以弥补生成的答案有时会有一步之差的问题，可以通过多次运行模型并报告共识结果来避免。 + +此外，推理步骤可能过于冗长的问题，可以由 `Pythonic` 或`Algebraic` 方法可以解决这个问题，通常需要较少的 `token`。 + +此外，推理步骤可能是正确的，但最终的计算结果却不正确，`MathPrompter` 通过使用 `Python` 的 `eval()` 方法函数来解决这个问题。 + +在大部分情况下，`MathPrompter` 都能生成正确的中间和最终答案，不过也有少数情况，如表中的最后一个问题，代数和 `Pythonic` 的输出都是一致的，但却有错误。 diff --git a/src/zh/posts/prompt/SoT.md b/src/zh/posts/reasoning/SoT.md similarity index 98% rename from src/zh/posts/prompt/SoT.md rename to src/zh/posts/reasoning/SoT.md index f0bea53da8..312dceed07 100644 --- a/src/zh/posts/prompt/SoT.md +++ b/src/zh/posts/reasoning/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.1 SoT框架](/assets/images/prompt/SoT1.png =650x) - -（1）引导LLM首先自己推导出一个骨架。 -（2）在骨架的基础上，LLM可以并行地完成每个点，从而提高速度。SoT既可用于加速分批解码的开源模型，也可用于加速并行API调用的闭源模型。 -（3）最后，研究人员在最近发布的11个LLM上测试SoT。结果显示，SoT不仅提供了相当大的加速度（最高可达2.39倍） ，而且它还可以在多样性和相关性方面提高几个问题类别的答案质量。 - -![图1.2 SoT效果](/assets/images/prompt/SoT2.png =680x) - -### 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显示了，研究人员当前实现使用的骨架提示模板图片和点扩展提示模板图片。 - -![图1.3 使用的骨架提示模板](/assets/images/prompt/SoT3.png =600x) - -![图1.4 使用的点扩展提示模板](/assets/images/prompt/SoT4.png =600x) - -（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 评估模型](/assets/images/prompt/SoT5.png =680x) - -### 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.2 不同模型加速效果](/assets/images/prompt/SoT6.png =720x) - -（2）SoT减少不同类别问题的端到端延迟 - -下图显示了每个问题类别在所有模型中的平均速度提升。那些SoT能够提供高质量答案的问题类别标记为绿色，不能的其他问题类别标记为红色。当前的SoT已经可以提升所有类别问题的速度。但对于那些SoT可以提供高质量答案的5个问题类别（即知识、常识、通用、角色扮演、虚拟情景），SoT可以将整体答案生成过程加速1.95倍-2.27倍。 - -![图2.3 不同问题类别加速效果](/assets/images/prompt/SoT7.png =680x) - -（3） SoT和正常生成的延迟对比 - -下图显示了模型正常生成和SoT生成的绝对延迟的比较。与正常生成相比，应用SoT的模型生成的速度提升是显而易见的。而**解码阶段**是内容生成端到端延迟的主要原因。因此，尽管SoT在骨架阶段比正常生成具有较高的预填充延迟，但这对总体延迟和总体速度提升几乎没有影响。 - -![图2.4 不同方法加速效果](/assets/images/prompt/SoT8.png =720x) - -### 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.5 生成答案质量比较](/assets/images/prompt/SoT9.png =680x) - -（2）SOT在不同类别问题上的表现 - -下图计算了所有问题类别的净胜率（胜率-败率）。LLMZoo指标下SoT的质量比FastChat的更好。但不论在哪个框架指标下，SoT在泛型、常识、知识、角色扮演和反事实方面的表现都相对较好，而在写作、费米问题、数学和编码方面表现相对较差。 - -![图2.6 生成答案分类比较](/assets/images/prompt/SoT10.png =720x) - -## 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.1 SoT框架](/assets/images/prompt/SoT1.png =650x) + +（1）引导LLM首先自己推导出一个骨架。 +（2）在骨架的基础上，LLM可以并行地完成每个点，从而提高速度。SoT既可用于加速分批解码的开源模型，也可用于加速并行API调用的闭源模型。 +（3）最后，研究人员在最近发布的11个LLM上测试SoT。结果显示，SoT不仅提供了相当大的加速度（最高可达2.39倍） ，而且它还可以在多样性和相关性方面提高几个问题类别的答案质量。 + +![图1.2 SoT效果](/assets/images/prompt/SoT2.png =680x) + +### 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显示了，研究人员当前实现使用的骨架提示模板图片和点扩展提示模板图片。 + +![图1.3 使用的骨架提示模板](/assets/images/prompt/SoT3.png =600x) + +![图1.4 使用的点扩展提示模板](/assets/images/prompt/SoT4.png =600x) + +（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 评估模型](/assets/images/prompt/SoT5.png =680x) + +### 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.2 不同模型加速效果](/assets/images/prompt/SoT6.png =720x) + +（2）SoT减少不同类别问题的端到端延迟 + +下图显示了每个问题类别在所有模型中的平均速度提升。那些SoT能够提供高质量答案的问题类别标记为绿色，不能的其他问题类别标记为红色。当前的SoT已经可以提升所有类别问题的速度。但对于那些SoT可以提供高质量答案的5个问题类别（即知识、常识、通用、角色扮演、虚拟情景），SoT可以将整体答案生成过程加速1.95倍-2.27倍。 + +![图2.3 不同问题类别加速效果](/assets/images/prompt/SoT7.png =680x) + +（3） SoT和正常生成的延迟对比 + +下图显示了模型正常生成和SoT生成的绝对延迟的比较。与正常生成相比，应用SoT的模型生成的速度提升是显而易见的。而**解码阶段**是内容生成端到端延迟的主要原因。因此，尽管SoT在骨架阶段比正常生成具有较高的预填充延迟，但这对总体延迟和总体速度提升几乎没有影响。 + +![图2.4 不同方法加速效果](/assets/images/prompt/SoT8.png =720x) + +### 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.5 生成答案质量比较](/assets/images/prompt/SoT9.png =680x) + +（2）SOT在不同类别问题上的表现 + +下图计算了所有问题类别的净胜率（胜率-败率）。LLMZoo指标下SoT的质量比FastChat的更好。但不论在哪个框架指标下，SoT在泛型、常识、知识、角色扮演和反事实方面的表现都相对较好，而在写作、费米问题、数学和编码方面表现相对较差。 + +![图2.6 生成答案分类比较](/assets/images/prompt/SoT10.png =720x) + +## 3 局限性 + +由于提示集的限制、现有LLM判断的偏差，以及LLM属性评价的内在困难，研究人员目前对LLM问题的答案质量的评价还远不全面。 + +对更可靠的质量评价而言，扩展提示集，以及用人工评价补充基于LLM的评价非常重要。 + +然而，目前的研究主要集中在揭示潜在的效率效益上，即通过重新思考现有LLM「全序列解码」的必要性，可以实现相当大的加速。 + +因此，研究人员在最后将对答案质量的更彻底的评估留给了未来的工作。 + +## 4 参考 diff --git a/src/zh/posts/prompt/ToT.md b/src/zh/posts/reasoning/ToT.md similarity index 98% rename from src/zh/posts/prompt/ToT.md rename to src/zh/posts/reasoning/ToT.md index 7252ac9e3d..c53ed86d11 100644 --- a/src/zh/posts/prompt/ToT.md +++ b/src/zh/posts/reasoning/ToT.md @@ -1,108 +1,108 @@ ---- -author: lx -icon: wand-magic-sparkles -date: 2023-06-05 -shortTitle: "Tree-of-Thought: 思维树" -category: - - 提示技术 -tag: - - 推理 - - LLM - - CoT - - ToT ---- - -# Tree-of-Thought: 思维树 - -[该文](https://mp.weixin.qq.com/s/aI4Ltwmm-YXcpT9aiJDdRQ)介绍了 `Tree-of-Thought: 思维树` 框架，由普林斯顿和谷歌DeepMind联合提出的全新「思维树」框架，让GPT-4可以自己提案、评估和决策，推理能力最高可提升1750%。 - - - - - -::: tip -项目地址：https://github.com/kyegomez/tree-of-thoughts -::: - -思维树可以让 `LLM`： -（1）自己给出**多条不同的推理路径** -（2）分别进行评估后，决定下一步的行动方案 -（3）在必要时向前或向后**追溯**，以便实现进行**全局**的决策 -论文实验结果显示，`ToT` 显著提高了 `LLM` 在三个新任务（24点游戏，创意写作，迷你填字游戏）中的问题解决能力。比如，在24点游戏中，`GPT-4` 只解决了 $4\%$ 的任务，但 `ToT` 方法的成功率达到了 $74\%$。 - ---- - -## 1 让LLM反复思考 - -用于生成文本的大语言模型 `GPT`、`PaLM`，现已经证明能够执行各种广泛的任务。所有这些模型取得进步的基础仍是最初用于生成文本的 **自回归机制**，以从左到右的方式一个接一个地进行 `token`级的决策。 - -这样一个简单的机制能否足以建立一个通向**解决通用问题的语言模型**？如果不是，哪些问题会挑战当前的范式，真正的替代机制应该是什么？ - -关于**人类认知**的文献中对于**双重过程**模型的研究表明，人类有两种决策模式： -（1）系统1 - 快速、自动、无意识模式。 -（2）系统2 - 缓慢、深思熟虑、有意识模式。 - -语言模型简单关联 `token` 级选择可以让人联想到系统1，因此这种能力可能会从系统2规划过程中增强。系统1可以让 `LLM` 保持和探索当前选择的多种替代方案，而不仅仅是选择一个，而系统2评估其当前状态，并积极地预见、回溯以做出更全局的决策。 - -这个观点突出了现有使用LLM解决通用问题方法的2个主要缺点： -（1）局部来看，`LLM` 没有探索思维过程中的不同延续——树的分支。 -（2）总体来看，`LLM` 不包含任何类型的计划、前瞻或回溯，来帮助评估这些不同的选择。 -为了解决这些问题，研究者提出了用语言模型解决通用问题的思维树框架（ToT），让 `LLM` 可以探索多种思维推理路径。 - -## 2 ToT四步法 - -现有的方法，如 `IO`、`CoT`、`CoT-SC`，通过采样连续的语言序列进行问题解决。而 `ToT` 主动维护了一个思维树。每个矩形框代表一个思维，并且每个思维都是一个连贯的语言序列，作为解决问题的中间步骤。 - -![图2.1 推理框架比较](/assets/images/prompt/ToT1.png =550x) - -`ToT` 将任何问题定义为在树上进行搜索，其中每个节点都是一个状态 $s=\left[x, z_{1 \cdots i}\right]$，表示到目前为止输入和思维序列的部分解。`ToT` 执行一个具体任务时需要回答4个问题: -（1）如何将中间过程分解为思维步骤； -（2）如何从每个状态生成潜在的想法； -（3）如何启发性地评估状态； -（4）使用什么搜索算法。 - -### 2.1 思维分解 - -`CoT` 在没有明确分解的情况下连贯抽样思维，而 `ToT` 利用问题的属性来设计和分解中间的思维步骤。 - -根据不同的问题，一个想法可以是几个单词（填字游戏） ，一条方程式（24点） ，或者一整段写作计划（创意写作）。 - -一个想法应该足够小，以便 `LLM` 能够产生有意义、多样化的样本。但一个想法也应该大，足以让 `LLM` 能够评估其解决问题的前景。 - -### 2.2 思维生成器 - -给定树状态 $s=\left[x, z_{1 \cdots i}\right]$，通过2种策略来为下一个思维步骤生成 $k$ 个候选者。 - -（1）从一个CoT提示采样思维，$z^{(j)} \sim p_{\theta}^{C o T}\left(z_{i+1} \mid s\right)=p_{\theta}^{C o T}\left(z_{i+1} \mid x, z_{1\cdots i}\right)(j=1\cdots k)$，在思维空间丰富（比如每个想法都是一个段落），并且导致多样性时，效果更好。 - -（2）使用 `proposal prompt` 按顺序提出想法，$z^{(j)} \sim p_{\theta}^{C o T}\left(z_{i+1} \mid s\right)=p_{\theta}^{C o T}\left(z_{i+1} \mid x, z_{1\cdots i}\right)(j=1\cdots k)$，这在思维空间受限制（比如每个思维只是一个词或一行）时效果更好，因此在同一上下文中提出不同的想法可以避免重复。 - -### 2.3 状态求值器 - -给定不同状态的前沿，状态评估器评估它们解决问题的进展，作为搜索算法的启发式算法，以确定哪些状态需要继续探索，以及以何种顺序探索。 - -虽然启发式算法是解决搜索问题的标准方法，但它们通常是编程的（DeepBlue）或学习的（AlphaGo）。这里，研究者提出了第三种选择，通过LLM有意识地推理状态。 - -在适用的情况下，这种深思熟虑的启发式方法可以比程序规则更灵活，比学习模型更有效率。与思维生成器，研究人员也考虑2种策略来独立或一起评估状态：对每个状态独立赋值；跨状态投票。 - -### 2.4 搜索算法 - -最后根据树的结构，使用插件化的方式使用不同的搜索算法。 - -（1） 算法1——广度优先搜索（`BFS`），每一步维护一组最有希望的状态。 -（2） 算法2——深度优先搜索（`DFS`），首先探索最有希望的状态，直到达到最终的输出 $t > T$，或者状态评估器认为不可能从当前的$s\left(V\left(p_{\theta},\{s\}\right)(s) \leq v_{t h}\right)$为阈值$v_{th}$解决问题。在这两种情况下，`DFS`都会回溯到 $s$ 的父状态以继续探索。 - -![图2.2 搜索算法](/assets/images/prompt/ToT2.png =700x) - -由上，LLM通过自我评估和有意识的决策，来实现启发式搜索的方法是新颖的。 - -## 3 实验 - -![图3.1 实验设置](/assets/images/prompt/ToT3.png =550x) - -为此，团队提出了三个任务用于测试——即使是最先进的语言模型GPT-4，在标准的IO提示或思维链（CoT）提示下，都是非常富有挑战的。 - -![图3.2 实验结果](/assets/images/prompt/ToT4.png =7000x) - -`IO`，`CoT`和`CoT-SC`提示方法在这几项任务上的表现不佳，成功率仅为 $7.3\%$，$4.0\%$和$9.0\%$。相比之下，`ToT`在广度为 `b = 1` 时已经达到了 $45\%$ 的成功率，而在 `b = 5` 时达到了 $74\%$。同时还考虑了 `IO/CoT` 的预测设置，通过使用最佳的 $k$ 个样本（$1 \le k \le 100$）来计算成功率，`CoT`比`IO`扩展得更好，最佳的100个`CoT`样本达到了$49\%$的成功率，但仍然比在`ToT`中探索更多节点（$b>1$）要差。 - +--- +author: lx +icon: wand-magic-sparkles +date: 2023-06-05 +shortTitle: "Tree-of-Thought: 思维树" +category: + - 提示技术 +tag: + - 推理 + - LLM + - CoT + - ToT +--- + +# Tree-of-Thought: 思维树 + +[该文](https://mp.weixin.qq.com/s/aI4Ltwmm-YXcpT9aiJDdRQ)介绍了 `Tree-of-Thought: 思维树` 框架，由普林斯顿和谷歌DeepMind联合提出的全新「思维树」框架，让GPT-4可以自己提案、评估和决策，推理能力最高可提升1750%。 + + + + + +::: tip +项目地址：https://github.com/kyegomez/tree-of-thoughts +::: + +思维树可以让 `LLM`： +（1）自己给出**多条不同的推理路径** +（2）分别进行评估后，决定下一步的行动方案 +（3）在必要时向前或向后**追溯**，以便实现进行**全局**的决策 +论文实验结果显示，`ToT` 显著提高了 `LLM` 在三个新任务（24点游戏，创意写作，迷你填字游戏）中的问题解决能力。比如，在24点游戏中，`GPT-4` 只解决了 $4\%$ 的任务，但 `ToT` 方法的成功率达到了 $74\%$。 + +--- + +## 1 让LLM反复思考 + +用于生成文本的大语言模型 `GPT`、`PaLM`，现已经证明能够执行各种广泛的任务。所有这些模型取得进步的基础仍是最初用于生成文本的 **自回归机制**，以从左到右的方式一个接一个地进行 `token`级的决策。 + +这样一个简单的机制能否足以建立一个通向**解决通用问题的语言模型**？如果不是，哪些问题会挑战当前的范式，真正的替代机制应该是什么？ + +关于**人类认知**的文献中对于**双重过程**模型的研究表明，人类有两种决策模式： +（1）系统1 - 快速、自动、无意识模式。 +（2）系统2 - 缓慢、深思熟虑、有意识模式。 + +语言模型简单关联 `token` 级选择可以让人联想到系统1，因此这种能力可能会从系统2规划过程中增强。系统1可以让 `LLM` 保持和探索当前选择的多种替代方案，而不仅仅是选择一个，而系统2评估其当前状态，并积极地预见、回溯以做出更全局的决策。 + +这个观点突出了现有使用LLM解决通用问题方法的2个主要缺点： +（1）局部来看，`LLM` 没有探索思维过程中的不同延续——树的分支。 +（2）总体来看，`LLM` 不包含任何类型的计划、前瞻或回溯，来帮助评估这些不同的选择。 +为了解决这些问题，研究者提出了用语言模型解决通用问题的思维树框架（ToT），让 `LLM` 可以探索多种思维推理路径。 + +## 2 ToT四步法 + +现有的方法，如 `IO`、`CoT`、`CoT-SC`，通过采样连续的语言序列进行问题解决。而 `ToT` 主动维护了一个思维树。每个矩形框代表一个思维，并且每个思维都是一个连贯的语言序列，作为解决问题的中间步骤。 + +![图2.1 推理框架比较](/assets/images/prompt/ToT1.png =550x) + +`ToT` 将任何问题定义为在树上进行搜索，其中每个节点都是一个状态 $s=\left[x, z_{1 \cdots i}\right]$，表示到目前为止输入和思维序列的部分解。`ToT` 执行一个具体任务时需要回答4个问题: +（1）如何将中间过程分解为思维步骤； +（2）如何从每个状态生成潜在的想法； +（3）如何启发性地评估状态； +（4）使用什么搜索算法。 + +### 2.1 思维分解 + +`CoT` 在没有明确分解的情况下连贯抽样思维，而 `ToT` 利用问题的属性来设计和分解中间的思维步骤。 + +根据不同的问题，一个想法可以是几个单词（填字游戏） ，一条方程式（24点） ，或者一整段写作计划（创意写作）。 + +一个想法应该足够小，以便 `LLM` 能够产生有意义、多样化的样本。但一个想法也应该大，足以让 `LLM` 能够评估其解决问题的前景。 + +### 2.2 思维生成器 + +给定树状态 $s=\left[x, z_{1 \cdots i}\right]$，通过2种策略来为下一个思维步骤生成 $k$ 个候选者。 + +（1）从一个CoT提示采样思维，$z^{(j)} \sim p_{\theta}^{C o T}\left(z_{i+1} \mid s\right)=p_{\theta}^{C o T}\left(z_{i+1} \mid x, z_{1\cdots i}\right)(j=1\cdots k)$，在思维空间丰富（比如每个想法都是一个段落），并且导致多样性时，效果更好。 + +（2）使用 `proposal prompt` 按顺序提出想法，$z^{(j)} \sim p_{\theta}^{C o T}\left(z_{i+1} \mid s\right)=p_{\theta}^{C o T}\left(z_{i+1} \mid x, z_{1\cdots i}\right)(j=1\cdots k)$，这在思维空间受限制（比如每个思维只是一个词或一行）时效果更好，因此在同一上下文中提出不同的想法可以避免重复。 + +### 2.3 状态求值器 + +给定不同状态的前沿，状态评估器评估它们解决问题的进展，作为搜索算法的启发式算法，以确定哪些状态需要继续探索，以及以何种顺序探索。 + +虽然启发式算法是解决搜索问题的标准方法，但它们通常是编程的（DeepBlue）或学习的（AlphaGo）。这里，研究者提出了第三种选择，通过LLM有意识地推理状态。 + +在适用的情况下，这种深思熟虑的启发式方法可以比程序规则更灵活，比学习模型更有效率。与思维生成器，研究人员也考虑2种策略来独立或一起评估状态：对每个状态独立赋值；跨状态投票。 + +### 2.4 搜索算法 + +最后根据树的结构，使用插件化的方式使用不同的搜索算法。 + +（1） 算法1——广度优先搜索（`BFS`），每一步维护一组最有希望的状态。 +（2） 算法2——深度优先搜索（`DFS`），首先探索最有希望的状态，直到达到最终的输出 $t > T$，或者状态评估器认为不可能从当前的$s\left(V\left(p_{\theta},\{s\}\right)(s) \leq v_{t h}\right)$为阈值$v_{th}$解决问题。在这两种情况下，`DFS`都会回溯到 $s$ 的父状态以继续探索。 + +![图2.2 搜索算法](/assets/images/prompt/ToT2.png =700x) + +由上，LLM通过自我评估和有意识的决策，来实现启发式搜索的方法是新颖的。 + +## 3 实验 + +![图3.1 实验设置](/assets/images/prompt/ToT3.png =550x) + +为此，团队提出了三个任务用于测试——即使是最先进的语言模型GPT-4，在标准的IO提示或思维链（CoT）提示下，都是非常富有挑战的。 + +![图3.2 实验结果](/assets/images/prompt/ToT4.png =7000x) + +`IO`，`CoT`和`CoT-SC`提示方法在这几项任务上的表现不佳，成功率仅为 $7.3\%$，$4.0\%$和$9.0\%$。相比之下，`ToT`在广度为 `b = 1` 时已经达到了 $45\%$ 的成功率，而在 `b = 5` 时达到了 $74\%$。同时还考虑了 `IO/CoT` 的预测设置，通过使用最佳的 $k$ 个样本（$1 \le k \le 100$）来计算成功率，`CoT`比`IO`扩展得更好，最佳的100个`CoT`样本达到了$49\%$的成功率，但仍然比在`ToT`中探索更多节点（$b>1$）要差。 + diff --git a/src/zh/posts/prompt/thor.md b/src/zh/posts/reasoning/thor.md similarity index 100% rename from src/zh/posts/prompt/thor.md rename to src/zh/posts/reasoning/thor.md diff --git a/src/zh/posts/token/README.md b/src/zh/posts/token/README.md index 0474cb9505..c47ca698ad 100644 --- a/src/zh/posts/token/README.md +++ b/src/zh/posts/token/README.md @@ -1,5 +1,5 @@ --- -title: Token +title: Token、分词 icon: puzzle-piece index: false article: false