返回列表

4th Place Solution

621. LLM 20 Questions | llm-20-questions

开始: 2024-05-15 结束: 2024-08-29 自然语言处理 AI大模型赛
第四名解决方案 - Oxford Kaggle Club

Oxford Kaggle Club 针对 LLM 20 个问题竞赛的解决方案

作者: Karam Al-Robaie (及团队成员 @vassiliph, @jasperbutcher, @devnirwal01)

发布时间: 2024 年 9 月 3 日

竞赛排名: 第 4 名

总结

首先,我要感谢组织者、竞争对手以及我的队友 @vassiliph, @jasperbutcher, @devnirwal01。很明显,第 4 名和第 11 名之间的差距纯粹是运气,所以我们谦卑地接受我们的奖品。在整个竞赛过程中,我们学到了很多关于使用小型 LLM 的知识(比观察我们在 leaderboard 上的机器人所显示的要多的多),并感谢所有组织这次竞赛的人。
我们首先概述我们的回答者(Answerer),然后是我们的提问者/猜测者(Questioner/Guesser),同时也包括了一些在每种策略中未能最终采用的想法。

回答者策略 (Answerer Strategy)

由于 LLM 通常在回答语言类型的问题上表现不佳,我们的回答者最初会针对一组正则表达式函数进行检查。如果这些函数都没有匹配,我们才会将其传递给我们的 LLM。

处理预定义类型的问题

最终,我们拥有 22 个正则表达式函数,尽管其中大多数几乎没用,之所以保留它们是因为我看不到包含它们有什么坏处。
在观察通过语言性问题获胜的主要流程时,主要有两个:(a) 字母二分法(事后看来这显然是最主导的)和 (b) 找到关键词的首字母然后列出可能的关键词。

能够编写尽可能通用但仍能捕捉上述两个流程的模式非常重要,因为许多团队提出这些问题的方式千差万别。在我们的最终解决方案中,func6, func20, func21 和 goofy_func 负责尽可能广泛地捕捉流程 (b),而 func19 负责流程 (a)。例如,func19 中的这两个模式将负责捕捉一些 Agent Alpha 的问题:

question_pattern = r".*(lexicographic|alphabetic|in the dictionary).*" 
before_pattern_b = r".*(?:smaller than|before|precede|precedes)\s+[\'\"]+([a-zA-Z\s]+)[\'\"]+.*" 

总的来说,我们作为回答者的 10 次胜利是通过流程 (a) 获得的,1.5 次是通过流程 (b) 获得的(0.5 次仅来自询问首字母,而非关键词)。其余的 7.5 次来自我们的 LLM……

使用 LLM

在确定使用哪一个之前,我们测试了许多 LLM,包括 Gemma2, Qwen2, Llama3, Llama3.1 和 Mistral。在基于约 1300 个问题的验证集测试每个 LLM 的准确性后,Llama 模型和 Mistral 表现最佳。我曾考虑在多个模型之间使用多数投票,但我假设这会违反内存限制;显然 @niwatori 的团队证明我错了。相反,我选择了 Mistral-7b。主要原因是 Mistral 倾向于回答“no"(即与错误的“yes"相比,它给出了许多错误的“no");这意味着在上面的流程 (b) 中,我不必捕捉问题是否属于“关键词是以下之一吗?……"的类型(我发现很难以通用方式做到这一点),而是只需捕捉关键词是否在问题中即可(这就是 goofy_func 的目的,名字 courtesy of @jasperbutcher :p)。

在提示工程方面,下面简要讨论了我如何尝试将关键词替换到猜测者的问题中,但失败了。然而,少样本学习(few-shot learning)似乎无论如何都起到了很好的作用。我还使用了 3 个不同的提示,并选择最常见的答案(如果 yes_count == no_count 则选'yes')。在选择这些提示时,我创建了约 10 个候选提示,然后在验证集上测试它们(这需要很长时间,因为 Mistral 每个响应需要约 15 秒)。许多候选提示的准确度为 85-88%,其中一个为 91%。这让我的工作变得非常简单,我可以直接选择 91% 准确度的提示,然后挑选另外两个“最不同”的提示;这是通过选择最小化 3 个答案向量点积之和来完成的('yes' -> 1 和 'no' -> -1)。事后看来,在实际上编写初始候选提示之前,我应该对提示工程进行更多的研究(即让 Mistral 在给出答案之前解释其思考过程)。

如上所述,我们作为回答者的 7.5 次胜利是通过 LLM 获得的(+ 在初始关键词重置之前的第一次胜利也是 LLM 回答者)。

无效的方法

当“地点”关键词重新启用时,我纠正了这些关键词(例如 iraq baghdad -> Baghdad, Iraq)并将这些关键词替换到发送给 LLM 之前的提问者提示中(例如 Is it… -> Is {keyword}…, …the keyword… -> …{keyword}...)。理论上,后者也可用于“事物”关键词,但语法处理变得更加复杂,且在验证集上测试时, naïve 实现显示没有差异。

还测试了在提示中使用维基百科文章作为上下文,看看是否会提高性能。不幸的是,我认为我方法中的一个致命缺陷是没有包含足够的文章内容。我尝试使用重排序器(re-rankers)提取最合适的块(基于问题和关键词),我也尝试只包含前几句话。这些都没有提高我的验证准确性。@isakatsuyoshi 在他的解决方案中精彩地解释了他对维基百科上下文的实现。

我尝试的另一件事是调整 logits,所以即使'yes' 标记的概率低于'no',只要'yes' 标记的概率不是低太多,我无论如何都会输出'yes'。这是基于 Mistral“默认”回答'no'的假设。不幸的是,我在这方面没有运气,事实上因此看到我的验证结果相当下降。

猜测者策略 (Guesser Strategy)

我们最初开发了一个带有关键词传播的提问树(详见下文),但很明显许多提交的 LLM 都不擅长回答问题。在此基础上,我们在截止日期前一天最后时刻 switched 到了 Agent Alpha 回答技术(因此,我们的最终提交仅在剩余 20 分钟时完成!)。我们创建了一组关键词(详见下文)以及每个关键词被选中的相关可能性。然后我们 simply 对这些关键词应用二分算法,对于猜测者,从列表中选择最可能的可能关键词。

另一个困境是是否包含握手("Is it Agent Alpha?")。最终我们选择了包含,因为我们认为失去一轮是小小的代价,以换取“解锁”100% 正确回答者的可能性,尽管再次强调,此类决定非常临期。

关键词

我们的解决方案使用预计算的可能关键词列表。
存在一个困境:是使用大关键词列表以最大化覆盖率(这将需要更多问题来猜测),还是使用可能包含在私有关键词列表中的较小关键词列表(这提供较小的覆盖率但需要较少的问题来猜测)。最初,我们考虑根据预期的元游戏选择一种方法,但后来我们发现可以通过为每个关键词添加到私有关键词列表的概率来结合这两种方法。因此,我们的关键词列表是一个包含两列的数据框:关键词和概率。

为了生成带有概率的关键词列表,我们做了以下操作:

  1. 将公共关键词列表 50/50 split 为训练集和验证集
  2. 将所有训练关键词分类为 12 个类别(例如,家居与生活、技术与电子、手工工具等)
  3. 将每个类别 split 为几个子类别(例如,家居与生活 -> 家具、电器、厨房用品、家居装饰等)
  4. 进一步将每个子类别 divide 为三级子子类别(例如,家具 -> 座椅、桌子、存储、床、户外家具),总共约 1700 个三级子子类别
  5. 使用 LLM 为每个子子类别生成 100 个可能的关键词,使用相关的训练关键词作为示例
  6. 将所有生成的关键词收集到一个大 CSV 文件中
  7. 重复步骤 #5-#6 五次
  8. 统计每个关键词生成的次数,假设较高的计数表示该关键词出现在私有关键词列表中的概率较高
  9. 添加最受欢迎的英语名词,计数取决于其频率
  10. 添加国家和城市列表,概率较低,以防万一

无效的方法:问题树方法

最初,我们开发了一种复杂的问题树方法,我们认为它比简单的二分法更有效。该方法涉及创建一个决策树结构,其中每个节点代表一个问题,关键词根据对这些问题的答案通过树传播。

我们的实现包括:

  1. 树结构:我们创建了一个节点类来表示决策树中的每个节点,包含有关问题、关键词和子节点的信息。
  2. 关键词传播:我们使用 LLM 回答每个关键词的问题,确定其通过树的路径。此过程允许批量处理关键词以提高效率。重要的是,如果 LLM 对这些问题的回答不一致(我们问了 LLM 几次),关键词会以相应的概率传播到两个子树中。
  3. 问题生成:我们实现了一个模块,使用 LLM 生成和评估每个节点的潜在问题。它将创建多个候选问题,根据关键词被此问题划分的平等程度(理想情况下我们想要 50/50 划分)以及答案的一致性来评估其划分关键词的有效性(信息增益)。然后选择最佳问题添加到树中。

在此过程结束时,我们将拥有一个关键词列表,以及基于 LLM 答案每个关键词位于相应子树中的概率。这种概率方法允许我们处理 LLM 响应中的不确定性,并 potentially 做出更明智的猜测。

这种方法在理论上的潜在优势是这些问题可以很容易被基于 LLM 的机器人回答。然而,我们最终决定不在最终提交中使用此方法,因为我们意识到许多其他机器人的 LLM 答案质量非常低,这将显著降低我们提问策略的有效性。

尽管未在最终提交中使用此方法,但开发该系统为使用 LLM 创建这些决策树提供了良好的见解,鉴于类似的不允许 Agent Alpha 类策略的竞赛,这是我们肯定会进一步探索的事情。

一些想法

再次,竞赛非常愉快;尽管公共关键词的包含对许多机器人来说肯定是不公平的。再次,我要感谢所有队友的工作以及所有使这次竞赛成为可能的人。在整个过程中以及查看所有其他顶级竞争对手的解决方案时,我学到了很多!

同比赛其他方案