Pascal Pfeiffer 谈检索、开放模型、Kaggle 与 H2O LLM Studio 微调

Matthew Berman 欢迎 Pascal Pfeiffer 参加访谈。Pfeiffer 当时是 H2O.ai 首席数据科学家，也是 Kaggle 竞赛 Grandmaster。在这场 2023 年 6 月的对话中，两人讨论了开放模型、检索、编程助手、竞赛，并演示 H2O LLM Studio。

Pfeiffer 说，H2O.ai 最初提供开源统计和数据科学工具，后来扩展到自动机器学习。产品包括开放工具，以及 Driverless AI 等企业产品；后者将部分模型构建和比较工作自动化。

他认为公司聚集的 Kaggle Grandmaster 和其他专家将实战竞赛经验带入了产品。Berman 问 H2O 是否主要面向企业客户；Pfeiffer 区分了企业级 AI Cloud 和面向更广泛用户的开放工具。

Pfeiffer 表示，发布的微调 Falcon 模型及相关工具可以在合适的本地或云端 GPU 上使用。硬件要求因模型规模和配置而异；能够在单个 GPU 上部署，不代表每个模型都能放进任何消费级 GPU。

Berman 问为什么 H2O 的 Falcon 服务比自己先前的尝试感觉更快。Pfeiffer 说，自回归生成会依次产生 token，随后将部署加速归功于 Hugging Face Text Generation Inference 和 FlashAttention，而没有把底层优化的功劳归于自己。

Pfeiffer 将 FlashAttention 描述为一种高效的注意力实现，它结合操作以减少开销。他说张量并行可以把矩阵运算分配到多个 GPU，但 Berman 试用的单 GPU 部署没有使用这种方法。

谈到本地使用时，Pfeiffer 表示 H2O 在 Hugging Face 上发布模型权重和模型卡。用户可以查看代码示例并选择兼容的服务软件；具体要求取决于每个模型及其许可。

Berman 问 H2O 聊天界面如何回答有关上传文档的问题。Pfeiffer 描述了一种流程，使用 LangChain 等工具连接文档处理、检索和语言模型。

由于长文档可能超过模型的上下文窗口，PDF 需要转换为文本并分成片段。为了寻找具体答案而让模型逐个处理所有片段，会增加成本和延迟，仍可能产生错误回答。

Pfeiffer 解释如何将文档片段嵌入向量空间，再与用户查询的嵌入进行比较。系统检索相关文本，将其与问题一起交给语言模型；检索是为回答提供依据的方法，并不能保证消除幻觉。

Berman 复述流程：将文档分块并索引，根据查询检索相关片段，然后把片段和问题传给模型。Pfeiffer 指出，可以提供多个片段，但更复杂的摘要或逐块处理会增加计算量。

Berman 提出早期编程智能体的一个实际限制：它们可以根据提示创建项目，却很难在已有的大型仓库上继续迭代。他问向量数据库能否为模型提供足够上下文，以可靠地修改相互依赖的代码。

Pfeiffer 认为这个问题很难，并表示 2023 年对整个仓库的理解仍未解决。语义检索能够找到相关文件，但依赖关系可能跨越超出提示容量的代码，而实际修改往往需要反复测试和调试。

他将更大的上下文窗口、多条候选推理路径和沙盒执行视为可能的方法。这些只是想法和预测，不能证明某一种技术能够解决所有代码库的问题。

Berman 提议生成仓库地图：文件摘要、函数签名、参数和预期输出，可以在查询与检索代码之间建立联系。他问这样的地图是否有助于为修改选择正确的上下文。

Pfeiffer 将这个想法与头文件和文档相比较。简洁地图可能连接结构清晰的代码，但真实项目更复杂，自动生成的文档字符串也可能出错。两人认为这值得测试，但尚不是完整解决方案。

Berman 说，持久上下文会让编程助手更适合迭代工作。Pfeiffer 设想一种能帮助开发者的初级结对编程助手，同时承认可靠地构建它非常困难。

话题转向 2023 年的开放与专有模型。Berman 问较小的开放模型是否真的与封闭模型一样擅长推理，还是主要模仿其回答。Pfeiffer 预计广泛的社区参与会随着时间推移帮助开放模型发展，同时认为 GPT-4 在当时是一款强大的通用模型。

Pfeiffer 说，较小模型可以处理许多常见的非编程问题，但指出一些模型是在类似更强模型输出的内容上训练的。模仿回答可能有用，却不能证明它们在所有任务上的能力相同。

他提醒人们谨慎看待某模型达到 GPT-4 或 GPT-3.5 固定百分比水平的标题式说法。结论取决于题目、评估流程、代码检查，以及人类或自动评判中的潜在偏差。

Berman 问中央模型能否像 HuggingGPT 的设想那样，将请求路由到专门模型。Pfeiffer 认为专业化可能有帮助，但对意料之外的请求进行路由需要强大的分类器，也会带来额外复杂度。

两人讨论了当时有关 GPT-4 内部架构的传闻。他们都没有第一手确认，所称组件模型的数量和规模仍未经证实；他们只是以该传闻为起点讨论可能的设计。

Pfeiffer 解释一种可能的集成方法：训练模型的多个版本，再在适当情况下通过平均或投票等方式合并预测。不同运行可能犯不同错误，因此组合可能改善平均表现，但也会提高推理成本。

他说，在 Kaggle 中，选手追求最后一点准确率时常用这种融合方法。生产系统则必须权衡性能提升与同时运行多个模型所产生的额外计算费用。

Pfeiffer 提出另一种可能的架构：由路由器把请求发送给不同的专门模型。他强调自己不知道 GPT-4 实际使用了何种架构，甚至无法确定是否使用了这些设计；讨论仍是假设性的。

Pfeiffer 解释，Kaggle 是数据科学竞赛和知识分享平台。组织者提供数据、任务和评估指标，参赛者开发模型，在公开及隐藏测试集上获得评分。

隐藏评估集很重要，因为参赛者不能直接针对最终答案调参。Berman 举了一个假设的企业推荐问题；Pfeiffer 说，竞赛数据可能是公开、匿名化、变换后或合成的数据，具体取决于组织者和任务。

Pfeiffer 在博士研究接近尾声时寻找实际机器学习问题，发现了 Kaggle。教科书示例并未展示真实数据的所有难点，因此他重视在看不到最终测试标签的情况下设计验证方式和处理流程。

他描述了一种分享文化：参与者讨论发现并发布 notebook。阅读别人的代码、使用同一数据集工作，加快了他的学习，也鼓励他继续参加竞赛。

在典型的图像分类竞赛中，参赛者会收到带标签的训练图片、目标指标和测试数据格式。他们构建训练和推理流程，可能从预训练图像模型出发，再添加分类器。

一些竞赛要求提交代码，针对未见过的测试数据运行预测并生成提交文件。每日提交次数限制减少了对公开排行榜的反复试探，但验证和过拟合仍是重要问题。

排行榜提供反馈，也让过程更有吸引力。Pfeiffer 说奖金差异很大：有些竞赛奖励异常丰厚，许多竞赛则在有限数量的获胜团队之间分配较小的奖金池。

什么方案最好取决于组织者的指标，例如分类问题中的 F1。Pfeiffer 回忆，不合适的指标可能引发社区讨论并促成更改；他警告，容易使用的分数并不总是与实际业务目标一致。

被问及 Grandmaster 的要求时，Pfeiffer 记得需要五枚金牌，其中一枚是个人参赛成绩，但他对具体奖牌分配规则不确定。这些规则适用于竞赛类别，也可能变化；他没有把自己的记忆当成权威结论。

对于初学者，他建议加入竞赛，逐行阅读共享 notebook 并关注讨论，而不只是复制代码。目标是识别有用信号、理解潜在偏差，并随着技术变化持续学习。

Berman 转向 H2O LLM Studio 以及观众经常提出的私有数据微调需求。他建议许多应用可以先考虑提示词和检索；他估计这些方法足以满足 99% 的用途，这是观点而非已确定的统计数据。

Pfeiffer 打开 2023 年的 LLM Studio 界面，解释它支持用用户数据集微调语言模型。聊天是常见用途，但训练示例也可以让模型产生结构化输出或遵循与 API 相关的格式。

他主要将微调描述为在预训练骨干模型之上教授输出风格和行为。这对演示中的指令微调是有用的描述，但根据数据和方法，微调也可能改变知识和其他能力。

演示使用 OpenAssistant 数据集，其中包含指令与回答示例。Pfeiffer 说其他任务可以采用不同映射，例如输入一段文本、输出类似 JSON 的记录；多轮对话可以使用父级标识符。

他通过选择数据集、因果语言建模任务和模型骨干创建实验。仅解码器语言模型根据前面的 token 预测下一个 token，所选的预训练骨干提供初始参数。

Pfeiffer 展示了个性化设置，可以替换训练示例中的机器人名称或作者。他随后讨论标记用户提示开始、助手回答开始和回答结束的特殊 token。

序列结束标记可以教会模型在哪里停止回答；没有合适的停止约定，基础模型可能继续生成。他还介绍了分词器设置和输入、输出长度限制。

界面提供多种数值精度和量化选项。Pfeiffer 解释，较低精度可以减少内存需求，但可能带来质量权衡。某个模型能否放进 8 GB GPU，取决于模型大小、上下文、方法和其他开销。

他解释 LoRA，即低秩适配：冻结预训练权重矩阵，用两个低秩矩阵表示一个小型可训练更新。与全量微调相比，这减少了可训练参数和相关优化器状态。

Pfeiffer 举例说明，一个大权重矩阵可以用中间秩小得多的因子来近似。结合 LoRA 和量化可以降低内存需求，但模型规模和训练配置仍决定所需硬件。

LLM Studio 提供困惑度、BLEU 和基于模型评分等评估选项，并支持跨多个 GPU 的分布式数据并行训练。每种指标衡量性能的不同方面；训练损失下降本身并不能证明实际使用可靠。

在展示的配置中，Pfeiffer 说 Falcon 7B 实验在三个 GPU 上运行约三小时，而一个 2.8B 模型运行预计约 30 分钟完成。这些时间只是他的硬件和设置下的例子，不能作为普遍性能保证。

他展示训练损失和日志，并表示项目开源且可配置。用户可以查看仓库和报告问题；训练数据、评估及部署仍需要各自谨慎决策。

Pfeiffer 尝试打开之前训练模型的聊天界面，但开发版出现错误。他解释，预期流程是与检查点聊天并比较验证指标；现场演示没有成功完成这一聊天步骤。

他补充说，LLM Studio 不仅有图形界面，还有命令行流程。关于安装和试验，他向观众介绍 H2O LLM Studio 的 GitHub 仓库和托管的 H2O GPT 界面。

Berman 感谢 Pfeiffer 讨论 Kaggle、开放模型、架构和微调。Pfeiffer 分享了观众可以在哪里找到他，访谈随之结束。