当前位置：首页 > news >正文

大语言模型推理透明化：Verbalized-Sampling 原理与工程实践

news 2026/5/10 5:06:37

1. 项目概述：当大语言模型学会“自言自语”式推理

最近在GitHub上看到一个挺有意思的项目，叫verbalized-sampling，来自CHATS-lab。初看这个标题，你可能会有点摸不着头脑：“言语化采样”？这听起来像是语言学或者心理学实验里的术语。但如果你点进去，会发现它其实是一个关于如何让大语言模型（LLM）进行更可靠、更透明推理的开源工具包。简单来说，它提供了一套方法论和代码，让LLM在生成答案时，不是直接“憋”出最终结果，而是像人一样，把思考的“自言自语”过程也一步步写出来，然后基于这个“自言自语”的文本流，再采样出最终的答案。

这解决了什么痛点呢？相信用过ChatGPT、Claude这类模型的朋友都有体会：有时候它给出的答案看起来头头是道，但追问一句“为什么”，或者让它检查一下步骤，可能就会发现逻辑漏洞，甚至出现“一本正经地胡说八道”的情况。模型的推理过程像一个黑箱，我们不知道它到底是怎么得出那个结论的。verbalized-sampling的核心思想，就是把这个黑箱打开一条缝，让模型把内部的“思维链”用自然语言表达出来，然后我们基于这个更丰富、更结构化的“思维”文本，去生成或选择最终的答案。这不仅能提升答案的准确性，还能让我们对模型的决策过程有迹可循，对于构建高可靠性的AI应用（比如代码生成、数学解题、逻辑分析）至关重要。

这个项目适合谁呢？如果你是AI应用开发者、研究人员，或者是对提升LLM推理透明度和可靠性感兴趣的工程师，那么这个项目提供的思路和工具绝对值得你深入研究。它不是一个简单的API封装，而是一种思维框架和实现范例，能帮助你更好地驾驭大语言模型的能力。

2. 核心思路拆解：从“直接采样”到“言语化后采样”

要理解verbalized-sampling，我们得先看看主流的LLM使用方式存在什么问题，以及这个项目提出的解决方案是如何一步步构建的。

2.1 传统直接采样的局限与“思维链”的启示

通常情况下，我们使用LLM可以概括为“输入-输出”模式：我们给模型一个提示（Prompt），模型直接生成一个答案（Completion）。这个过程在技术上叫做“采样”（Sampling），模型根据概率分布，一个字一个字地生成最终的文本。这种方式的优点是直接、快速。但缺点也很明显：

过程不透明：我们只看到了最终输出，不知道模型在生成“因此答案是42”之前，是否真的正确计算了“6乘以7”。
错误难以追溯：如果答案错了，我们很难定位是理解错了问题，还是推理步骤出错，或是最后一步“口误”。
缺乏自我校正机会：模型一次性生成答案，没有给自己留下回顾和检查中间步骤的空间。

近年来，“思维链”（Chain-of-Thought, CoT）提示技术部分解决了这个问题。通过让模型在输出答案前，先输出“让我们一步步思考：...”这样的内容，可以显著提升其在复杂推理任务上的表现。verbalized-sampling可以看作是CoT思想的一种系统化、工程化的延伸。它不仅仅满足于让模型“显示”思考步骤，更关键的是，它要利用这个“显示”出来的、言语化的推理过程，作为后续更高质量采样的基础。

2.2 “言语化采样”的核心两步走策略

项目的核心方法论可以分解为两个关键阶段：

第一阶段：推理言语化（Verbalized Reasoning）这个阶段的目标不是得到最终答案，而是引导模型生成一个完整的、逐步的推理文本。这个文本应该包含模型对问题的理解、分解的子问题、引用的知识（或规则）、以及一步步的推导。提示词（Prompt）的设计在这里至关重要。它需要明确指令模型“展示你的工作”、“解释你的推理过程”，并为这种结构化的输出提供范例。

例如，对于一个数学问题，理想的言语化输出可能是：

“用户的问题是：一个篮子里有12个苹果，小明拿走了3个，小红又放进去5个，现在篮子里有多少个苹果？首先，我们需要理解初始状态：篮子里有12个苹果。然后，小明拿走了3个，这是一个减少操作，所以剩余苹果为 12 - 3 = 9个。接着，小红放进去5个，这是一个增加操作，所以最终数量为 9 + 5 = 14个。因此，逐步计算后，篮子里现在有14个苹果。”

这个文本包含了状态变化和算术运算，是一个完整的“自言自语”记录。

第二阶段：基于言语化内容的答案采样（Sampling from Verbalization）有了第一阶段的推理文本，我们现在拥有了一份比原始问题丰富得多的上下文材料。第二阶段，我们可以采取不同的策略从这个上下文中“采样”出最终答案：

提取式采样：最简单的方式，直接从言语化文本的末尾或明确标识结论的部分（如“因此...”、“所以答案是...”）提取答案。这通常需要设计好的输出格式或使用正则表达式匹配。
验证式采样：将整个言语化文本和原始问题，一起交给另一个LLM调用（或同一个模型的另一个前向过程），让其扮演“验证者”或“总结者”的角色，任务是：“基于以下的推理过程，给出最准确的最终答案。”这相当于让模型自己检查自己的作业。
集成式采样：运行多次“推理言语化”过程，生成多个可能略有不同的推理文本，然后通过投票、一致性检查或另一个模型来评估哪个推理过程最合理，并选择其对应的答案。这能有效降低单次推理的随机性错误。

verbalized-sampling项目提供了实现这些策略的框架和工具，让开发者可以方便地实验和集成这种两步走的推理模式。

2.3 为什么这样做更有效？——理论视角

从计算理论的角度看，这相当于增加了模型的“工作记忆”和“输出缓冲区”。直接采样要求模型在内部隐式地完成所有推理并压缩到最终答案的token中，这对模型的内部表示能力要求极高。而言语化采样将中间状态“外化”为显式的文本，这部分文本又作为新的输入上下文，辅助模型生成最终答案。这样做有几个好处：

降低单步生成难度：模型不需要在一步之内从问题跨越到复杂答案，而是可以先解决一系列更简单的子问题（生成言语化步骤），再基于这些结果合成答案。
提供自我监控锚点：生成的文本为模型（或后续验证步骤）提供了可检查的中间状态。如果发现“12-3=8”这样的错误，就可以在最终答案生成前被捕获或纠正。
改善概率校准：最终答案的生成是基于一个（希望是）正确的推理过程，这比基于原始问题直接猜测答案，在概率分布上往往更加集中和准确。

3. 项目架构与核心模块解析

CHATS-lab的verbalized-sampling通常不会是一个庞大的单体应用，而是一个轻量级、模块化的工具包。我们可以根据其核心思想，推演并构建一个典型的实现架构。理解这个架构，有助于我们将其思想应用到自己的项目中。

3.1 核心执行引擎：分阶段提示与采样管道

项目的核心是一个可配置的管道（Pipeline）。这个管道管理着从原始输入到最终输出的完整流程。

输入问题 -> [言语化提示模板] -> LLM调用 -> 得到推理文本 -> [答案提取/验证策略] -> 最终答案

每个环节都是可插拔的：

言语化提示模板：这是一个文本模板，定义了如何将用户问题包装成要求模型展示推理过程的提示。一个强大的模板可能包含任务描述、输出格式示例（Few-shot Examples）以及明确的指令。
LLM调用接口：项目会抽象化与不同LLM（如OpenAI API、Anthropic Claude、本地部署的Llama等）的交互，提供统一的生成接口，支持调整温度（temperature）、最大token数等参数。对于言语化阶段，温度可能设置得稍高一些，以鼓励探索不同的推理路径；而对于最终的答案采样，温度可能设置得更低，以确保确定性。
后处理策略模块：这是实现不同“采样”策略的地方。模块接收原始的言语化文本，按照既定策略（如正则提取、验证调用、集成投票）产出最终答案。

3.2 提示工程模板库

这是项目的“灵魂”所在。verbalized-sampling的成功很大程度上依赖于精心设计的提示模板。项目可能会提供一个模板库，针对不同类型的任务（数学推理、代码生成、常识问答、逻辑谜题）预置了经过优化的提示模板。

例如，一个用于数学单词题的模板可能长这样：

你是一个仔细的数学助手。请解决以下问题，并一步一步地展示你的所有计算和推理过程。 问题：{user_question} 请按以下格式输出： 推理：<你的逐步推理过程，包含所有中间步骤> 答案：<最终的数字答案>

而对于代码调试任务，模板可能完全不同：

你是一个资深程序员。请分析以下代码片段的问题，并解释如何修复它。请一步步思考，先指出错误类型，再说明原因，最后给出修正后的代码。 代码：{user_code} 请按以下格式输出： 分析：<逐步的错误分析和推理> 修正后的代码：<完整的正确代码>

项目需要提供方便的方式来管理、选择和应用这些模板。

3.3 答案提取与验证策略实现

这是将“言语化”文本转化为可靠答案的关键技术模块。

基于规则的提取器：对于格式规整的输出，可以使用正则表达式或简单的字符串查找（如查找“答案：”后面的内容）来提取。这是最快、最廉价的方法，但依赖于模型严格遵守输出格式。
```
# 伪代码示例 import re def extract_answer_by_regex(verbalization): pattern = r"答案：\s*(.+?)(?:\n|$)" match = re.search(pattern, verbalization) return match.group(1) if match else None
```
基于LLM的验证器/总结器：这是一个独立的LLM调用步骤。提示词可能是：“以下是一个AI助手对问题的推理过程。请严格检查其推理逻辑和计算是否正确。如果正确，请直接输出最终答案；如果发现错误，请输出‘推理中存在错误’，并简要说明。\n推理过程：{verbalization}”。这种方式更灵活，能处理非结构化的输出，并能进行简单的逻辑校验，但成本更高（多一次API调用）。
自洽性采样（Self-Consistency Sampling）：这是集成采样的一种高级形式。项目可能会实现这个功能：对同一个问题，独立运行多次（例如5次）“推理言语化”过程，得到多个推理路径和候选答案。然后选择出现频率最高的那个答案作为最终输出。其背后的假设是：正确的推理路径在随机的模型采样中更可能被多次发现。这能显著提升在复杂任务上的表现。

3.4 评估与日志模块

一个好的工具包必须包含评估其自身效果的能力。这个模块可能提供：

基准测试集：集成一些公开的推理基准测试数据集（如GSM8K用于数学，HumanEval用于代码），方便用户评估自己应用verbalized-sampling后的效果提升。
自动化评估指标：除了最终答案的准确率，还可以设计对“推理文本质量”的评估，例如步骤的完整性、逻辑的连贯性等（这可能也需要借助LLM进行评分）。
详细的运行日志：记录每一次调用的输入提示、生成的言语化文本、应用的提取策略、最终答案以及耗时、token用量等信息。这对于调试提示模板、分析错误案例至关重要。

实操心得：在构建这样的管道时，错误处理和重试机制必须作为一等公民来设计。LLM API调用可能失败，生成的文本可能完全不符合格式，答案提取可能为空。管道需要在每个环节设置超时、重试和降级策略（例如，规则提取失败时，自动降级为使用LLM验证器来提取）。

4. 实战应用：构建一个数学解题服务

让我们通过一个具体的例子，看看如何利用verbalized-sampling的思想，从零开始构建一个更可靠的数学解题服务。我们将使用Python和OpenAI API（或兼容的开源模型）进行演示。

4.1 环境准备与基础配置

首先，确保你的开发环境已就绪。

# 创建项目目录并初始化虚拟环境 mkdir math_solver_with_verbalization cd math_solver_with_verbalization python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate # 安装核心依赖 pip install openai # 如果使用OpenAI API # 或者，如果你使用本地模型，例如通过vLLM或Ollama # pip install vllm # pip install ollama

接下来，我们创建一个配置文件config.py来管理关键参数：

# config.py import os from dotenv import load_dotenv load_dotenv() # 从.env文件加载环境变量 class Config: # LLM 配置 LLM_API_TYPE = "openai" # 可选： "openai", "anthropic", "local_vllm" OPENAI_API_KEY = os.getenv("OPENAI_API_KEY") OPENAI_MODEL = "gpt-4o-mini" # 对于测试，性价比高。生产可考虑 "gpt-4-turbo" OPENAI_BASE_URL = os.getenv("OPENAI_BASE_URL", "https://api.openai.com/v1") # 支持自定义端点 # 言语化阶段参数 VERBALIZE_TEMPERATURE = 0.7 # 稍高的温度，鼓励推理多样性 VERBALIZE_MAX_TOKENS = 1024 # 答案采样阶段参数（如果使用验证器） ANSWER_TEMPERATURE = 0.1 # 低温度，确保答案稳定 ANSWER_MAX_TOKENS = 128 # 自洽性采样参数 SELF_CONSISTENCY_N = 5 # 采样次数 # 提示模板路径 PROMPT_TEMPLATES_DIR = "./prompt_templates"

4.2 实现核心的言语化采样管道

我们创建一个solver.py文件，实现核心逻辑。

# solver.py import re import json from typing import List, Optional, Tuple from openai import OpenAI # 示例使用OpenAI from config import Config class MathVerbalizedSolver: def __init__(self, config: Config): self.config = config self.client = OpenAI(api_key=config.OPENAI_API_KEY, base_url=config.OPENAI_BASE_URL) # 加载提示模板 self.verbalize_prompt = self._load_template("math_verbalize.txt") def _load_template(self, filename: str) -> str: """从文件加载提示模板""" path = os.path.join(self.config.PROMPT_TEMPLATES_DIR, filename) with open(path, 'r', encoding='utf-8') as f: return f.read() def _call_llm(self, prompt: str, temperature: float, max_tokens: int) -> str: """统一的LLM调用函数""" try: response = self.client.chat.completions.create( model=self.config.OPENAI_MODEL, messages=[{"role": "user", "content": prompt}], temperature=temperature, max_tokens=max_tokens, stream=False ) return response.choices[0].message.content.strip() except Exception as e: print(f"LLM调用失败: {e}") return "" def generate_verbalization(self, question: str) -> Tuple[str, str]: """ 生成推理言语化文本。 返回: (verbalization_text, raw_response) """ prompt = self.verbalize_prompt.format(question=question) raw_response = self._call_llm( prompt, self.config.VERBALIZE_TEMPERATURE, self.config.VERBALIZE_MAX_TOKENS ) # 这里我们假设模型返回的整个内容就是言语化文本 return raw_response, raw_response def extract_answer_by_rule(self, verbalization: str) -> Optional[str]: """ 使用规则（正则）从言语化文本中提取答案。 这是最简单快速的策略。 """ # 尝试多种常见模式 patterns = [ r"答案[：:]\s*([^\n]+)", # 中文冒号 r"Answer[：:]\s*([^\n]+)", # 英文冒号 r"最终结果[：:]\s*([^\n]+)", r"因此，?是\s*([^\n]+)", # 匹配“因此，是14个” r"所以，?有\s*([^\n]+)", # 匹配“所以，有14个” ] for pattern in patterns: match = re.search(pattern, verbalization, re.IGNORECASE) if match: answer = match.group(1).strip().rstrip('.。!！?？') # 清理尾部标点 # 进一步提取数字（针对数学问题） num_match = re.search(r'(\d+(\.\d+)?)', answer) if num_match: return num_match.group(1) return answer return None def extract_answer_by_verifier(self, question: str, verbalization: str) -> Optional[str]: """ 使用另一个LLM调用作为验证器来提取答案。 成本更高，但更鲁棒。 """ verifier_prompt = f""" 你是一个严格的数学答案验证员。 原始问题：{question} 一个AI助手给出了以下推理过程： ``` {verbalization} ``` 请执行以下操作： 1. 检查推理过程在逻辑和计算上是否正确。 2. 如果完全正确，请直接输出最终答案的数值，不要任何额外文字。 3. 如果发现任何错误，请只输出单词“ERROR”。 你的输出： """ answer = self._call_llm( verifier_prompt, self.config.ANSWER_TEMPERATURE, self.config.ANSWER_MAX_TOKENS ) if answer and answer.upper() != "ERROR": return answer.strip() return None def solve_with_self_consistency(self, question: str) -> Optional[str]: """ 使用自洽性采样策略：生成多个推理路径，投票决定最终答案。 """ answers = [] for i in range(self.config.SELF_CONSISTENCY_N): verbalization, _ = self.generate_verbalization(question) answer = self.extract_answer_by_rule(verbalization) if answer: answers.append(answer) # 可以添加一点延迟，避免速率限制 # time.sleep(0.1) if not answers: return None # 简单投票：选择出现次数最多的答案 from collections import Counter answer_counts = Counter(answers) most_common_answer, count = answer_counts.most_common(1)[0] # 可选：可以设置一个最低票数阈值，例如需要至少2票 if count >= 2: return most_common_answer else: # 如果票数太分散，可以退回使用验证器策略 print(f"自洽性投票分散，退回验证器策略。票数分布：{answer_counts}") # 这里可以取第一个生成的言语化文本来做验证 return None # 实际代码中这里应调用其他策略 def solve(self, question: str, strategy: str = "rule") -> dict: """ 主解决函数。 strategy: 可选 "rule", "verifier", "self_consistency" """ result = { "question": question, "strategy": strategy, "verbalization": None, "final_answer": None, "error": None } try: if strategy == "self_consistency": final_answer = self.solve_with_self_consistency(question) result["final_answer"] = final_answer # 自洽性下没有单一的言语化文本 result["verbalization"] = "Multiple paths generated." else: # 生成言语化文本 verbalization, raw_resp = self.generate_verbalization(question) result["verbalization"] = verbalization if not verbalization: result["error"] = "生成言语化文本失败" return result # 根据策略提取答案 if strategy == "rule": final_answer = self.extract_answer_by_rule(verbalization) elif strategy == "verifier": final_answer = self.extract_answer_by_verifier(question, verbalization) else: result["error"] = f"未知策略: {strategy}" return result result["final_answer"] = final_answer except Exception as e: result["error"] = str(e) return result

4.3 设计高效的提示模板

在prompt_templates/math_verbalize.txt中，我们放入精心设计的提示词：

你是一个专业的数学问题解决助手。你的任务是仔细、逐步地解决用户提出的数学问题，并清晰地展示你所有的思考步骤和计算过程。 请严格遵循以下格式输出： **问题理解**：用一句话复述问题，并明确已知条件和求解目标。 **分步推理**： 1. 第一步：... 2. 第二步：... ... **计算过程**：列出所有必要的算式。 **最终答案**：在完成所有推理后，给出简洁的最终答案。 现在，请解决以下问题： 问题：{question}

这个模板通过结构化指令，极大地提高了模型输出格式的规范性，使得后续的规则提取变得可行。

4.4 运行测试与效果对比

创建一个test.py来测试我们的服务：

# test.py from config import Config from solver import MathVerbalizedSolver def main(): config = Config() solver = MathVerbalizedSolver(config) test_questions = [ "一个篮子里有12个苹果，小明拿走了3个，小红又放进去5个，现在篮子里有多少个苹果？", "火车以每小时80公里的速度行驶，3小时能走多远？", "一个长方形的长是10厘米，宽是长的一半，它的面积是多少平方厘米？", # 可以加入更复杂的、容易让模型直接回答出错的问题 "如果3个人3天能喝3桶水，那么9个人9天能喝多少桶水？" ] for q in test_questions: print(f"\n{'='*50}") print(f"问题: {q}") # 测试不同策略 for strategy in ["rule", "verifier"]: print(f"\n--- 策略: {strategy} ---") result = solver.solve(q, strategy=strategy) if result['error']: print(f"错误: {result['error']}") else: print(f"推理过程:\n{result['verbalization'][:500]}...") # 只打印前500字符 print(f"最终答案: {result['final_answer']}") # 测试自洽性（较慢） print(f"\n--- 策略: self_consistency ---") result = solver.solve(q, strategy="self_consistency") print(f"最终答案: {result['final_answer']}") if __name__ == "__main__": main()

运行这个测试，你可以直观地比较不同策略的效果、消耗的时间（Token）以及答案的可靠性。通常，rule策略最快最便宜，但依赖于完美的格式输出；verifier更鲁棒，能纠正一些推理中的小错误，但成本翻倍；self_consistency在复杂问题上通常最准确，但成本是N倍（N为采样次数）。

实操心得：提示模板的质量是成败的关键。在真实项目中，你需要准备一个“开发集”，包含几十到上百个典型问题，反复迭代优化你的提示模板，直到模型能稳定输出结构良好的言语化文本。一个常见的技巧是在模板中提供2-3个高质量的示例（Few-shot Learning），这比纯指令（Zero-shot）效果要好得多。

5. 高级技巧与性能优化

当你掌握了基础实现后，下面这些高级技巧和优化点能帮助你构建一个生产级的系统。

5.1 动态提示选择与任务路由

不是所有问题都需要复杂的言语化推理。对于简单的事实性问题（如“中国的首都是哪里？”），直接问答可能更高效。因此，一个成熟的系统应该包含一个“任务分类器”或“路由层”。

实现思路：可以用一个轻量级模型（甚至是一组规则或关键词）对输入问题进行分类：简单事实类、数学计算类、逻辑推理类、代码类等。
动态模板选择：根据分类结果，选择最合适的言语化提示模板。例如，数学问题用数学模板，代码调试用代码模板。
策略选择：对于简单问题，可以跳过言语化步骤，直接使用基础问答；对于中等难度问题，使用“规则提取”策略；对于高难度或高价值问题，启用“自洽性采样”或“验证器”策略。这实现了精度与成本的平衡。

5.2 言语化文本的缓存与复用

对于许多应用场景，用户可能会反复询问相同或类似的问题。每次都对相同问题进行完整的言语化生成是巨大的资源浪费。

缓存设计：可以设计一个缓存系统，以问题的哈希值（或经过归一化处理的问题文本）为键，存储生成的言语化文本。
缓存失效：需要考虑缓存的有效期。如果底层LLM模型更新了（例如从GPT-4升级到GPT-4 Turbo），或者你的提示模板发生了重大修改，缓存需要被清空或标记为过期。
语义缓存：更高级的实现可以使用向量数据库（如ChromaDB, Pinecone）来构建语义缓存。当新问题与缓存中的某个问题语义相似度超过阈值时，可以直接复用其言语化文本，或以其为参考进行快速生成，这能显著提升响应速度并降低成本。

5.3 流式输出与用户体验

在Web应用或聊天机器人中，让用户等待模型先生成一大段推理文本，再看到答案，体验并不好。我们可以利用流式API进行优化。

两阶段流式：
1. 第一阶段流式输出言语化文本。让用户实时看到模型的“思考过程”，这本身具有很高的透明度和教育价值。
2. 在言语化文本生成完毕后（或即将完毕时），立即启动第二阶段，流式输出最终答案。
技术实现：利用OpenAI API的stream=True参数。前端需要处理两个独立的流式响应，并合理地展示它们（例如，将推理过程显示在灰色背景的“思考区”，答案高亮显示）。

5.4 成本监控与预算控制

使用言语化采样，尤其是自洽性采样和验证器策略，API调用次数和Token消耗会成倍增加。必须建立成本监控。

Token计数：在每次LLM调用后，记录请求和响应的Token数量。OpenAI的响应头中通常包含这些信息。
预算与限流：为每个用户或每个API密钥设置每日/每月的Token预算。当接近预算时，可以自动降级策略（例如，从“自洽性”降级到“规则提取”，甚至关闭言语化，使用直接问答）。
异步处理：对于非实时性要求高的任务（如批量处理文档），可以将任务放入队列异步执行，避免对实时API造成压力，也便于统一进行成本核算和资源调度。

6. 避坑指南与常见问题排查

在实际开发和部署verbalized-sampling模式的应用时，你会遇到一些典型问题。以下是我在实践中总结的“坑”和解决方案。

6.1 言语化文本格式失控

问题：模型不按提示模板的格式输出，导致规则提取器失效。例如，它可能把答案写在开头，或者混在长篇大论的中间。排查与解决：

检查提示模板：确保指令清晰、无歧义。使用分隔符（如"""）明确区分指令和问题。在指令中明确要求“必须严格遵循以下格式”。
引入Few-shot示例：在提示中提供1-3个完美的输入输出示例，这是引导模型格式最有效的方法之一。
降低Temperature：在言语化生成阶段，过高的温度会增加创造性，但也可能导致格式偏离。尝试将温度从0.7降至0.3或0.1。
使用JSON格式：对于机器解析，最可靠的方式是要求模型输出JSON。例如，提示词结尾可以是：“请以以下JSON格式输出：{\"reasoning\": \"...\", \"final_answer\": \"...\"}”。现代LLM对JSON格式的支持已经非常好。
后处理纠错：编写一个“格式清洗”函数，尝试从混乱的输出中通过多种模式匹配来提取结构。如果清洗失败，则触发重试或降级到验证器策略。

6.2 答案提取错误或为空

问题：extract_answer_by_rule函数返回None，或者提取到了错误的内容（如提取了“14个苹果”而不是数字“14”）。排查与解决：

增强正则表达式：不要依赖单一模式。像前面示例一样，编写一个模式列表，按顺序尝试。模式应覆盖中文/英文、全角/半角标点等变体。
输出标准化：在提取后，对答案字符串进行清洗。去除首尾空白和标点，尝试提取其中的数字或特定关键词。
设置置信度阈值与回退：如果规则提取失败或提取结果看起来不合理（例如，数学问题中提取到了非数字字符），应立即回退到验证器策略。在代码中，这应该是一个自动化的降级流程。
记录与审计：将所有提取失败的案例连同其言语化文本记录下来。定期分析这些日志，你会发现是某些特定类型的问题容易导致失败，从而有针对性地优化你的提示或提取逻辑。

6.3 性能瓶颈与延迟过高

问题：自洽性采样需要调用N次模型，导致响应时间很长，用户体验差。排查与解决：

并行化调用：如果API允许（注意速率限制），可以将N次言语化生成请求并行发出，而不是串行。使用asyncio或线程池可以大幅减少总耗时。
减少采样次数N：对于大多数问题，N=3或N=5已经能带来显著提升。通过A/B测试，在准确率和延迟之间找到业务可接受的平衡点。
选择性使用：不要对所有问题都用自洽性。如5.1所述，通过路由层，只对高难度、高价值问题启用该策略。
使用更快的模型：言语化阶段不一定需要使用最强大、最慢的模型。可以尝试用速度快、成本低的模型（如GPT-3.5-Turbo）进行言语化，然后用更强大的模型（如GPT-4）做验证或最终答案的精炼。这种“混合模型”策略性价比很高。

6.4 幻觉与错误在言语化中被“合理化”

问题：这是最棘手的问题之一。模型可能在言语化阶段就开始了“幻觉”（编造事实或逻辑），并且在其生成的文本中，这个错误被一系列看似合理的步骤所“合理化”。后续的验证器如果只是检查内部一致性，可能无法发现这个根本性错误。排查与解决：

引入外部知识验证：对于涉及事实的问题，在验证阶段，可以尝试将关键事实点提取出来，通过检索增强生成（RAG）的方式，从可信知识库中检索证据进行交叉验证。
多角度提问：用不同方式询问同一个事实，比较答案是否一致。
人类反馈循环（HFL）：在关键业务场景，将低置信度的答案（例如，自洽性投票票数低，或验证器返回“ERROR”）标记出来，交由人工审核。这些人工审核的结果又可以作为反馈数据，用于微调模型或优化提示。
承认不确定性：教导模型在言语化中表达不确定性。在提示词中加入：“如果你对某一步骤不确定，请明确标注‘此处我不确定’”。一个诚实的“我不知道”比一个自信的错误答案更有价值。

verbalized-sampling不是一个银弹，但它为我们提供了一套强大的工具和框架，将大语言模型从“神秘的诗人口中”变成了一个“愿意展示草稿的思考者”。通过强制模型将推理过程外化，我们获得了干预、验证和优化的机会。实现这样一个系统的过程，本身也是对提示工程、LLM行为模式和软件架构的深度历练。从简单的规则提取到复杂的自洽性采样，每一步的演进都伴随着对可靠性、成本和延迟的权衡。我的体会是，最重要的不是追求最复杂的策略，而是根据你的具体应用场景，构建一个从简单到复杂、具备优雅降级能力的弹性系统。先从写好一个提示模板、实现一个可靠的规则提取器开始，让它跑起来，然后再根据实际遇到的具体问题，逐步引入更高级的策略，这样迭代出来的系统才是最健壮、最实用的。

查看全文

http://www.jsqmd.com/news/787383/