优化上下文学习：LLM的“黄金示例”

大语言模型（LLM）已成为各种应用的关键，而无需大量再训练即可引导其行为的关键技术是上下文学习（In-Context Learning，ICL）。这种方法涉及向LLM提供输入-输出对的示例，使其在处理新任务之前推断出所需的模式或格式。策略范围从“一次性”（一个示例）到“少样本”（多个示例）和“思维链”（演示逐步推理）。

考虑一个简单的查询：询问LLM，“什么动物发出‘哞’的声音，它属于什么类型？”如果没有指导，像ChatGPT这样的LLM可能会提供冗长的答案，包括其他动物类型的无关细节。然而，通过在查询前加上诸如“用户：什么动物发出‘汪汪’的声音，它属于什么类型？助手：狗，哺乳动物”和“用户：什么动物发出‘喵’的声音，它属于什么类型？助手：猫，哺乳动物”的示例，LLM学会生成简洁、所需的格式：“牛，哺乳动物。”这展示了ICL在引导LLM输出方面的强大能力，而无需进行资源密集型的模型微调过程。

尽管ICL在提升LLM性能和准确性方面非常有效，但它有一个显著的缺点：它的脆弱性。ICL的成功对所选的具体示例、它们的顺序，甚至微小的格式变化都异常敏感。这是因为ICL更多地通过表面模式匹配而非真正的概念理解来操作。对于代码修复或将自然语言转换为SQL查询等复杂任务，示例选择的微小改动都可能严重影响准确性。那么，核心挑战就变成了：如何系统地选择真正有助于LLM的示例，而不仅仅是任何示例？

为解决这一关键问题，Google DeepMind的研究论文《AuPair：代码修复的黄金示例对》介绍了一种系统性的示例选择方法，专门用于修复有缺陷的代码。与依赖随机选择或从预先整理的池中进行相似性搜索的传统方法不同，AuPair专注于生成和提取最有效的“黄金”示例对。

AuPair的方法论分为两个不同的阶段。第一阶段，示例对生成，旨在创建大量的候选“修复对”。它首先使用包含测试用例的编码问题数据集。LLM被提示生成一个初始解决方案（“猜测”）。如果这个猜测部分正确，它就被用作起点。关键步骤是要求LLM修复这段损坏的代码，使用由少量现有、随机选择的修复对提供的少样本提示。如果LLM生成的修复改进了原始猜测，那么这个“猜测 → 修复”就成为一个候选对。巧妙的是，如果修复仍然不完美，它会被重新送回流程作为新的“损坏”代码，创建一系列渐进式改进的链。这种迭代的、自我改进的循环重复数千次，构建了一个包含各种错误类型及其解决方案的丰富候选对池。

第二阶段，黄金对提取，侧重于从生成的池中识别最有影响力的对。这涉及一个两步过程：测量有效性，然后应用贪婪选择算法。为了测量有效性，AuPair创建了一个损坏代码问题的验证数据集。然后，每个候选修复对都作为一个一次性示例，用于为验证集中的每个问题生成修复。生成的修复会根据单元测试进行测试，从而产生一个分数。这个过程生成了一个全面的“质量矩阵”，映射了每个候选对在解决各种验证问题方面的表现。在量化有效性后，贪婪算法会选择“黄金”对。它选择在所有验证问题上产生最高平均分数的候选对。至关重要的是，这个被选中的对的贡献随后会从矩阵中所有剩余的对中“减去”。这确保了后续的选择是互补的，防止冗余，并优先选择处理不同类型问题或提供独特见解的对。这种迭代选择持续进行，直到边际改进低于设定的阈值，从而产生一个高度有效、非冗余的黄金对有序列表。

AuPair的有效性通过七个编码问题数据集和五种不同的LLM模型进行了严格测试。它在解决问题方面始终优于自反思和N中选优等替代方法。一个显著的发现是AuPair卓越的计算效率：仅12个黄金对就达到了32个随机选择对相同的性能，代表了2-3倍的提升。此外，在一个数据集（CodeForces）上生成的黄金对在完全不同的数据集（HackerEarth和AtCoder）上表现出强大的性能，这突显了它们在同一领域内的可迁移性。

尽管AuPair取得了可喜的成果，但它也有局限性。候选示例对的初始生成，以及其迭代修复过程和大量的LLM调用，需要大量的计算资源。此外，该方法严重依赖可量化的评估指标，例如代码的单元测试，这在所有领域可能并不容易获得。它还假设互补示例将持续带来更好的性能，这一假设虽然对编码问题有效，但可能不具有普遍性。最后，AuPair是根据结构化的竞赛问题进行基准测试的，其在更复杂、真实世界代码库上的性能仍是一个悬而未决的问题。

尽管如此，AuPair代表了在特定领域优化上下文学习的重大飞跃。通过超越任意示例选择，转向系统地识别真正有效模式的方法，它提升了LLM的性能和效率。虽然它需要相当大的前期计算投入和领域特定的评估指标，但其“黄金对”在不同数据集之间已证明的可迁移性表明了值得的回报。这项研究为将类似智能示例选择技术应用于其他复杂任务铺平了道路，例如文本到SQL的生成，在这些任务中，示例的有效性可以被系统地测量和管理。