多模型竞技场：用Python构建LLM谜语生成与解答评测系统

1. 项目概述与核心思路

最近在琢磨一个挺有意思的玩意儿：让几个不同的大语言模型（LLM）凑一块儿，自己出谜语，自己猜谜语，最后比比看谁更“聪明”。这个项目的名字叫RandomWalkOrg/RiddleGenerator，听起来就有点“随机漫步”的哲学味儿，但内核其实很直接——用代码搭建一个竞技场，让 OpenAI、Anthropic、Google 和 Groq 的模型同台竞技。

我自己是个喜欢折腾各种 AI 工具的人，平时用 Cursor 写代码比较多，所以这个项目用 Cursor.AI 作为开发环境来测试，感觉特别顺手。它的核心逻辑并不复杂：写一个 Python 脚本，轮流让每个 LLM 扮演“出题人”，生成一个谜语（包括文字谜和数学谜），然后其他几个模型作为“答题人”来尝试解答。最后，系统会比对答案，统计每个模型在“出题”和“解题”两个维度的表现。

这背后的想法其实挺实用的。现在各种 LLM 层出不穷，都说自己能力强，但具体到像“理解隐喻”、“逻辑推理”这类需要综合能力的任务上，差异到底有多大？光看厂商的基准测试报告不够直观，不如自己搭个“擂台”，让它们用同一种方式、同一套题目来比划比划。通过这个项目，你不仅能直观看到不同模型在创造性和计算准确性上的强弱，还能深入理解如何用代码协调多个外部 API，处理并发请求，以及设计一套公平的评估机制。无论你是想选型合适的模型用于自己的应用，还是单纯对多智能体协作感兴趣，这个项目都能给你提供一手、有趣的洞察。

2. 环境搭建与核心依赖解析

工欲善其事，必先利其器。这个项目的环境搭建非常典型，是现在 Python AI 项目的标准做法。核心就是管理好你的 Python 环境和那些关键的 API 密钥。

2.1 开发环境与工具链选择

项目明确提到了使用Cursor.AI作为开发环境。这是一个非常现代且高效的选择。Cursor 不仅仅是一个编辑器，它深度集成了 AI 辅助编程的能力，你可以在里面直接和 AI 对话来生成代码、解释代码、修复错误，对于快速原型开发特别有帮助。当然，你用 VS Code 加 Copilot，或者任何你熟悉的 IDE 都没问题，项目的代码本身是环境无关的。

Python 版本方面，项目没有特别说明，但考虑到它使用的依赖库，推荐使用Python 3.8 或更高版本。我个人的经验是，3.10 或 3.11 的兼容性和性能表现都很好，也是目前大多数云服务和教程的主流支持版本。

2.2 依赖库深度解读

运行pip install -r requirements.txt会安装一系列库。虽然原文没给出requirements.txt的具体内容，但我们可以根据项目目标（调用多个 LLM API）推断出其核心依赖。一个典型的文件可能长这样：

openai>=1.0.0 anthropic>=0.25.0 google-generativeai>=0.3.0 groq>=0.5.0 pandas>=2.0.0 python-dotenv>=1.0.0

我们来拆解一下每个库的作用和选型理由：

1. openai,anthropic,google-generativeai,groq：这是四个模型的官方或主流 Python SDK。直接使用官方库能保证最佳的兼容性和最新的功能支持。例如，openai>=1.0.0意味着使用 OpenAI 新的统一 API 接口，这与旧版的openai<1.0.0在用法上有较大区别，新版本更模块化、更清晰。
2. pandas：用于数据处理和分析。从示例输出最后的 CSV 保存功能来看，pandas被用来将每轮比赛的结果（哪个模型出的题、题目是什么、其他模型的答案、正确答案）整理成结构化的DataFrame，并轻松导出为riddle_competition_results.csv文件。用pandas而不用纯 CSV 模块，是因为它便于后续进行复杂的统计分析，比如计算各模型成功率、生成总结表格等。
3. python-dotenv：这是管理环境变量的黄金标准。它允许你将敏感的 API 密钥保存在一个名为.env的本地文件中（该文件被.gitignore排除，不会上传到公开仓库），然后在代码中安全地加载。这比直接在代码里写密钥，或者手动在终端设置环境变量要安全、方便得多。

注意：API 密钥的安全是头等大事。绝对不要将你的.env文件或任何包含真实密钥的代码提交到 Git 仓库。一个标准的.gitignore文件必须包含.env和*.env。我习惯在项目根目录创建一个.env.example文件，里面只写密钥的名称而不写值（如OPENAI_API_KEY=），作为模板供其他协作者参考。

2.3 API 密钥配置实操

原文给出了在环境变量中设置密钥的方法。但结合python-dotenv，更佳实践如下：

首先，在项目根目录创建.env文件：

# .env OPENAI_API_KEY=sk-your-openai-key-here ANTHROPIC_API_KEY=your-anthropic-key-here GROQ_API_KEY=gsk-your-groq-key-here GOOGLE_API_KEY=your-google-ai-studio-key-here

注意，Groq 和 Google 的密钥前缀可能不同，请以各自平台提供的为准。

然后，在你的主程序文件（如run_competition.py）开头，通过dotenv加载：

import os from dotenv import load_dotenv load_dotenv() # 加载 .env 文件中的所有变量到环境变量 OPENAI_API_KEY = os.getenv('OPENAI_API_KEY') ANTHROPIC_API_KEY = os.getenv('ANTHROPIC_API_KEY') # ... 其他密钥同理

这样，你的代码就安全地获取到了密钥，并且便于在不同环境（开发、测试、生产）中切换配置。

3. 核心架构与多模型调度设计

这个项目的代码架构是其精髓所在。它不是一个简单的顺序脚本，而是一个模拟多智能体交互的微系统。我们来拆解它的设计思路。

3.1 模型抽象与统一接口

面对四个不同的 LLM 供应商，每个都有自己独特的 SDK 调用方式。最糟糕的写法是在业务逻辑里堆满if model_name == “openai”: ... elif model_name == “anthropic”: ...。好的设计应该将“与特定模型通信”的细节封装起来。

我通常会定义一个基础的LLMClient抽象类或协议，然后为每个模型创建具体的实现类。但在这个相对简单的项目中，一个更轻量化的方法是使用一个统一的函数，内部根据模型选择不同的调用路径。不过，为了更好的可扩展性（比如未来增加新的模型），采用类的方式更优。

假设我们有一个RiddleCompetition类，它内部维护一个模型客户端字典。每个客户端负责处理与自己模型API的对话。核心的generate_riddle和solve_riddle方法，在内部会调用相应客户端的特定方法。这样，主竞赛逻辑完全不用关心openai.ChatCompletion.create和anthropic.Anthropic.messages.create的区别。

3.2 竞赛流程的状态机

从输出日志看，竞赛流程是一个清晰的状态循环：

1. 确定出题方：按顺序（如[‘groq’， ‘openai’， ‘google’， ‘anthropic’]）选择一个模型作为本轮出题人。
2. 出题阶段：调用出题模型的generate_riddle方法。这里有个关键细节：示例中 Google 模型出题时出现了Attempt 1: Generated similar riddle, trying again...。这说明代码里内置了去重或质量检查机制。比如，可能检查新生成的谜语不能和已生成的列表太相似，或者必须包含“？”等格式要求。这是一个非常重要的实操点，能有效避免无效或重复的题目。
3. 答题阶段：将生成的谜语（和数学题）依次发送给其他三个模型，调用它们的solve_riddle方法。
4. 验证与计分：系统需要判断答案的对错。对于数学题，这很简单，直接比较数值或解析计算表达式即可。对于文字谜语，则复杂得多。示例中似乎系统自己知道“正确答案”（Correct Answer: A Star）。这意味着，在出题阶段，模型不仅生成了谜面，还必须以一种结构化的方式（比如 JSON）同时输出谜底。系统会记录这个“标准答案”，用于后续比对。答题模型的回答会被清洗（去除句号、大小写标准化等）后与标准答案比对。
5. 循环与记录：完成一轮（一个出题者为所有其他模型出一题）后，切换到下一个出题者。所有结果（出题者、谜面、各模型答案、标准答案、对错）被实时记录到一个列表或DataFrame中。
6. 总结与输出：所有轮次结束后，程序会分别计算文字谜和数学谜的得分，打印出美观的总结表格，并最终将详细数据保存到 CSV 文件。

3.3 提示词工程的设计

项目的成败很大程度上取决于给模型的提示词（Prompt）。出题和解题的提示词需要精心设计。

出题提示词需要引导模型生成格式正确、难度适中、答案明确的谜语。它可能包含以下要素：

• 角色设定：“你是一个谜语创作大师。”
• 任务说明：“请创作一个文字谜语。谜面应生动有趣，答案必须是单一、具体的名词或概念。”
• 格式要求：“请以以下 JSON 格式回复：{“riddle”: “你的谜面”, “answer”: “标准答案”}。不要输出任何其他内容。”
• 对于数学题：“请生成一个简单的算术谜题，包含不超过两步的运算（如加法、减法、乘法）。同样以 JSON 格式回复：{“riddle”: “算术题描述”, “answer”: 数字答案}。”

解题提示词则需要让模型专注于回答问题，避免多余的解释：

• “请直接回答以下谜语，只输出你认为最准确的答案，不要解释。谜语：[此处插入谜面]”
• 对于数学题，可以要求模型“只输出最终计算结果”。

实操心得：提示词的稳定性。在实际测试中，我发现不同模型对提示词的敏感度不同。有些模型（如 Claude）会严格遵守格式要求，有些则可能额外输出一些礼貌性语句。因此，在代码的答案解析部分，需要做鲁棒性处理，比如用正则表达式从回复中提取第一个可能匹配答案的片段，而不是简单地进行字符串完全匹配。这也是评估环节的一部分——一个“听话”、输出格式规范的模型，在自动化评测中会占优势。

4. 代码实现与关键环节剖析

现在，让我们深入到代码层面，看看如何实现上述架构。我会结合关键代码片段和实操中的注意事项来讲解。

4.1 模型客户端的封装

首先，我们封装一个多模型管理器。这里以类的方式实现，更具扩展性。

import os import json import re from abc import ABC, abstractmethod from typing import Dict, Any, Optional import openai from anthropic import Anthropic import google.generativeai as genai from groq import Groq import pandas as pd class BaseLLMClient(ABC): """LLM客户端的抽象基类""" def __init__(self, api_key: str, model_name: str): self.api_key = api_key self.model_name = model_name @abstractmethod def generate_text(self, prompt: str) -> str: """发送提示词并返回模型生成的文本""" pass class OpenAIClient(BaseLLMClient): def __init__(self, api_key: str, model_name: str = "gpt-4o-mini"): super().__init__(api_key, model_name) self.client = openai.OpenAI(api_key=api_key) def generate_text(self, prompt: str) -> str: try: response = self.client.chat.completions.create( model=self.model_name, messages=[{"role": "user", "content": prompt}], temperature=0.7, # 温度参数，控制创造性 max_tokens=150 ) return response.choices[0].message.content.strip() except Exception as e: print(f"OpenAI API 错误: {e}") return "" # 类似地，实现 AnthropicClient, GoogleClient, GroqClient... # Anthropic 可能需要指定 `max_tokens`；Google Gemini 的调用方式略有不同。

关键点解析：

• 错误处理：每个generate_text调用都应有try-except包裹。网络波动、API 限额、模型过载都可能导致请求失败。良好的错误处理能保证单次失败不会导致整个竞赛崩溃，可以记录错误并返回空字符串或默认值。
• 温度参数：temperature是控制生成随机性的关键。对于出题，可以设得稍高（如 0.8-1.0）以增加多样性；对于解题，可以设得较低（如 0.1-0.3）以获得更确定、更准确的答案。示例代码中可能对两者使用了不同的设置。
• Token 限制：max_tokens需要合理设置。谜语和答案通常很短，150-300 个 token 足够。设置过大浪费资源，过小可能导致答案被截断。

4.2 竞赛核心逻辑实现

下面是竞赛循环的核心简化代码，展示了如何组织一轮比赛。

class RiddleCompetition: def __init__(self, clients: Dict[str, BaseLLMClient]): self.clients = clients self.model_names = list(clients.keys()) self.results = [] # 用于存储每一轮结果的字典列表 def run_round(self, asker: str, riddle_type: str = "word"): """由某个模型出题，其他模型答题的一轮""" print(f"\n=== {asker} is asking {riddle_type} riddles ===") # 1. 出题 prompt = self._build_prompt_for_generation(riddle_type) raw_output = self.clients[asker].generate_text(prompt) # 解析模型输出的 JSON，获取谜面和标准答案 try: riddle_data = json.loads(raw_output) riddle_text = riddle_data.get("riddle", "").strip() correct_answer = str(riddle_data.get("answer", "")).strip().lower() except json.JSONDecodeError: # 如果模型没返回标准 JSON，尝试用正则提取 riddle_text, correct_answer = self._fallback_parse(raw_output) if not riddle_text: print(f"{asker} 生成谜语失败，跳过此轮。") return print(f"Riddle: {riddle_text}") print(f"Correct Answer: {correct_answer}") # 2. 其他模型依次答题 for answerer in self.model_names: if answerer == asker: continue answer_prompt = f"直接回答以下谜语，不要解释。谜语：{riddle_text}" if riddle_type == "math": answer_prompt = f"直接计算并输出以下算术题的答案，只输出数字。题目：{riddle_text}" model_answer_raw = self.clients[answerer].generate_text(answer_prompt) # 清洗答案：转小写，去除标点，提取核心部分 model_answer_clean = self._clean_answer(model_answer_raw) # 3. 判断对错 (简单字符串包含或数学求值比较) is_correct = self._evaluate_answer(model_answer_clean, correct_answer, riddle_type) print(f"{answerer} answered: {model_answer_raw}") # 4. 记录结果 self.results.append({ "round": len(self.results)//3 + 1, # 假设每轮3个答题者 "asker": asker, "answerer": answerer, "riddle_type": riddle_type, "riddle_text": riddle_text, "correct_answer": correct_answer, "model_answer_raw": model_answer_raw, "model_answer_clean": model_answer_clean, "is_correct": is_correct }) def _clean_answer(self, answer: str) -> str: """清洗答案字符串，便于比较""" answer = answer.lower().strip() # 移除常见的引号、句号、'answer:' 等前缀 answer = re.sub(r'^(answer:|答案：|a\.?\s*)', '', answer) answer = re.sub(r'[.,;!?]$', '', answer) # 提取可能是一个单词或数字的部分 match = re.search(r'([a-z]+|\d+)', answer) return match.group(1) if match else answer def _evaluate_answer(self, model_answer: str, correct_answer: str, riddle_type: str) -> bool: """评估答案是否正确""" if riddle_type == "math": # 尝试将答案转换为数字进行比较 try: # 处理模型可能输出的表达式，如 `51` 或 `The answer is 51.` model_num = float(re.search(r'[-+]?\d*\.?\d+', model_answer).group()) correct_num = float(correct_answer) # 允许微小的浮点数误差，或直接比较整数 return abs(model_num - correct_num) < 0.001 except: # 如果转换失败，回退到字符串模糊匹配 return model_answer == correct_answer else: # word riddle # 文字谜语采用模糊匹配：正确答案包含模型答案，或模型答案包含正确答案 # 例如，正确答案是 "a star"，模型回答 "star" 或 "a star." 都应算对 return (correct_answer in model_answer) or (model_answer in correct_answer) # ... 其他辅助方法，如 _build_prompt_for_generation, _fallback_parse 等

关键点解析：

• 答案清洗与评估：这是项目中最棘手也最有趣的部分。_clean_answer和_evaluate_answer函数决定了比赛的公平性。过于严格的匹配（如字符串完全相等）会导致大量“误判”，因为模型可能添加了冠词“a”或句点。过于宽松的匹配又可能让错误答案蒙混过关。这里展示的是一种实用主义的模糊匹配策略，在实际应用中可能需要根据多次测试结果反复调整正则表达式和逻辑。
• 数学题评估：对于数学题，直接比较数字是最可靠的。但模型有时会输出计算过程（如“6 x 9 = 54, 54 - 3 = 51”），所以需要用正则\d+提取出最后一个或最显眼的数字。更严谨的做法是使用eval（有安全风险需谨慎）或ast.literal_eval来评估模型输出的整个算术表达式，但这要求模型输出必须是纯表达式。
• 结果记录：使用字典列表self.results记录每一笔交互的详细信息。这种结构化的数据非常方便后续转换为pandas DataFrame进行分析和导出。

4.3 主程序与结果分析

主程序run_competition.py负责串联一切：

def main(): # 1. 初始化所有客户端 clients = { "openai": OpenAIClient(os.getenv("OPENAI_API_KEY")), "anthropic": AnthropicClient(os.getenv("ANTHROPIC_API_KEY")), "google": GoogleClient(os.getenv("GOOGLE_API_KEY")), "groq": GroqClient(os.getenv("GROQ_API_KEY")), } competition = RiddleCompetition(clients) # 2. 定义比赛轮次和类型 riddle_types = ["word", "math"] rounds_per_type = 2 # 每种谜语类型每个出题者出几题 # 3. 运行竞赛 for riddle_type in riddle_types: for asker in clients.keys(): for _ in range(rounds_per_type): competition.run_round(asker, riddle_type) # 4. 生成总结报告 df = pd.DataFrame(competition.results) print("\n" + "="*50) print("Word Riddles Summary:") word_df = df[df['riddle_type'] == 'word'] # 使用pandas的groupby和agg进行统计 word_summary = word_df.groupby('answerer').agg( total_questions=('is_correct', 'count'), correct_answers=('is_correct', 'sum') ) word_summary['success_rate'] = (word_summary['correct_answers'] / word_summary['total_questions'] * 100).round(2) print(word_summary.sort_values('success_rate', ascending=False).to_string()) # 同理生成数学谜语总结... # 5. 保存详细结果 df.to_csv('riddle_competition_results.csv', index=False, encoding='utf-8-sig') # 使用utf-8-sig支持Excel中文 print(f"\nDetailed results saved to riddle_competition_results.csv") if __name__ == "__main__": main()

关键点解析：

• 数据统计：使用pandas的groupby功能可以轻松地按答题者（answerer）分组，统计答题总数和正确数，并计算成功率。这比手动循环计数要简洁、高效得多。
• CSV 导出：to_csv方法将完整的DataFrame导出。index=False避免保存不必要的行索引。encoding=‘utf-8-sig’是一个重要技巧，确保包含非英文字符时，用 Excel 打开 CSV 文件不会出现乱码。
• 可扩展性：这个结构很容易扩展。你可以增加新的模型客户端类，修改clients字典即可。你也可以调整riddle_types或rounds_per_type来改变比赛规模和形式。

5. 常见问题、调试技巧与深度优化

在实际运行这个项目的过程中，你几乎一定会遇到各种问题。下面是我踩过的一些坑和总结的解决方案。

5.1 API 调用相关的问题

实操心得：稳健的 API 调用封装。我强烈建议将generate_text方法包装在一个带有错误处理和重试的逻辑里。下面是一个简单的示例：

import time from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type class RobustOpenAIClient(OpenAIClient): @retry( stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=2, max=10), retry=retry_if_exception_type((openai.APITimeoutError, openai.InternalServerError)) ) def generate_text(self, prompt: str) -> str: time.sleep(0.5) # 基础延迟，避免请求过快 return super().generate_text(prompt)

这样能极大提升脚本在非理想网络环境下的运行成功率。

5.2 模型行为与提示词调优

5.3 性能与成本考量

运行多轮、多模型的竞赛会产生可观的 API 调用费用和耗时。

• 成本控制：每个模型的定价不同（按输入/输出 Token 计费）。在测试阶段，可以限制每轮次数、使用更便宜的模型（如gpt-4o-mini而非gpt-4o），或设置max_tokens上限。
• 异步加速：目前的代码是顺序调用，一个模型答完再问下一个。实际上，答题阶段完全可以并行化。可以使用asyncio和支持异步的 SDK（如openai.AsyncOpenAI）来并发地向所有答题模型发送请求，能显著缩短总运行时间。
• 结果缓存：如果多次运行脚本进行测试，相同的提示词会产生相同的答案（在temperature=0时）。可以考虑将(模型, 提示词)作为键，将回复缓存到本地文件或数据库中，避免重复调用 API 产生费用。但注意，对于创造性任务（出题），temperature应大于0，不适合缓存。

5.4 结果分析与解读陷阱

拿到 CSV 结果和总结表格后，解读数据需要谨慎：

• 样本量小：示例中每个模型只回答了少量题目（6道文字谜+6道数学题）。这种小样本下的成功率（如 66.67% vs 100%）可能只是统计波动，不能武断地说一个模型比另一个好很多。要得出可靠结论，需要运行更多轮次（比如每个组合50-100题）。
• 任务特殊性：这个竞赛只测试了“谜语生成与解答”和“基础算术”。一个模型在这里表现好，不代表它在代码生成、逻辑推理、长文本理解等其他任务上也同样好。评估模型需要多维度、多任务的基准测试。
• 评估标准的主观性：文字谜语的“模糊匹配”评估标准本身可能存在偏差。也许模型 A 的答案“Hope”在人类看来比标准答案“A Star”更有诗意、更贴切，但系统判其为错。可以考虑引入人工评估，或者设计更精细的评估规则（如使用另一个 LLM 来评判答案的相关性）。

6. 项目扩展与更多玩法

这个基础框架的扩展潜力很大，你可以把它当作一个多智能体交互的“沙盒”：

1. 增加模型和任务：加入新的模型（如国内的大模型 API），增加新的任务类型，如“对联生成”、“短故事接龙”、“代码审查意见生成”等，比较不同模型的专长。
2. 设计淘汰赛制：不再是简单的循环赛，可以引入淘汰机制。例如，每轮答错者扣分，若干轮后淘汰得分最低的模型，增加竞赛的趣味性。
3. 引入裁判模型：不预设标准答案，而是引入一个“裁判”模型（例如，指定一个你认为最强的模型作为裁判），由它来评判其他模型生成的答案是否合理。这可以用于评估更开放、没有标准答案的问题。
4. 可视化仪表盘：使用matplotlib或plotly将 CSV 中的数据绘制成动态图表，实时展示各模型的得分变化，让竞赛过程更直观。
5. 本地模型集成：如果你有足够的显卡资源，可以集成像 Llama、Qwen 这样的开源模型（通过ollama、vLLM或Transformers库），让本地模型也参与竞赛，对比开源与闭源模型的性能成本比。

这个项目最吸引我的地方在于，它用一个轻量、有趣的形式，触及了当前 AI 应用开发中的几个核心问题：多模型 API 集成、提示词设计、自动化评估以及智能体间的交互。通过亲手实现和调试这个过程，你对这些概念的理解会比单纯阅读文档深刻得多。