技术摘要：在多语言场景中利用语言模型生成日志语句

问题陈述

日志语句对于软件测试、调试和故障分析等软件维护活动至关重要。然而，设计有效的日志语句需要开发人员投入大量手动精力，以确定最佳插入位置、分配适当的严重级别，并构建富含上下文的消息。尽管大型语言模型（LLM）的最新进展已实现了端到端的自动化日志语句生成，但现有研究主要在单一语言环境（具体为 Java）中评估了这些方法。因此，这些方法在现代多语言软件开发环境中的有效性仍未得到充分探索。此外，尚不清楚训练策略（例如单语言与多语言适应）以及特定于语言的日志记录特征如何影响不同编程语言的性能。

方法论

为了填补这些空白，作者进行了一项大规模实证研究，涉及构建多语言基准测试以及对各种生成方法的比较评估。

基准测试构建

作者构建了一个全面的多语言基准测试，包含来自五种编程语言（Java、Python、JavaScript、TypeScript 和 C#）的 150,000 个实例。该数据集从公共 GitHub 仓库中挖掘，并针对质量（例如最小提交数、贡献者数量和星标数）以及特定日志库的使用（例如 Java 的 Log4j、Python 的标准日志库）进行了筛选。

• 数据处理：提取方法，使用特定于语言的工具（例如 Python 的 Black、JS/TS 的 Prettier）进行格式化，并划分为训练集、验证集和测试集（比例为 8:1:1）。
• 实例生成：采用“留一法”策略，对于包含多个日志语句的方法，移除其中一个语句作为目标输出，而保留其他语句在输入中以提供上下文。
• 平衡：为确保公平比较，数据集被平衡为每种语言恰好包含 30,000 个实例（24k 训练，3k 验证，3k 测试）。

评估方法

本研究评估了三种代表性的端到端方法和五种大型语言模型（LLM）：

1. 现有方法：
   • LANCE：一种基于 PLM 的方法（T5 架构），使用微调。
   • FastLog：一种两阶段 PLM 方法，依次预测插入位置并生成消息。
   • UniLog：一种基于 LLM 的方法，结合基于检索的少样本提示与轻量级“预热”（参数调整）策略。
2. 大型语言模型：
   • 自托管：Llama3.1-8B-Instruct、Qwen2.5-Coder-7B 和 Mistral-7B-Instruct-v0.3。
   • 基于 API：GPT-4.1 mini 和 DeepSeek-V3。

实验设计

本研究解决了三个研究问题（RQs）：

• RQ1（性能）：使用包括位置准确率、级别准确率、消息准确率、全准确率（三个元素的精确匹配）、BLEU 和 ROUGE 在内的指标，评估了所有方法在五种语言上的表现。
• RQ2（训练策略）：利用 LoRA 微调研究了训练策略的影响。比较包括单语言 LoRA（每种语言单独的适配器）与多语言 LoRA（共享适配器），以及不同的数据规模（例如 24k 与 120k 总实例）。
• RQ3（语言特征）：分析了特定于语言的因素（插入位置类别、日志级别分布和消息多样性）如何导致性能差异。这涉及将日志位置分类为六个类别（例如 Try-Catch、循环块），并使用“LLM 作为裁判”进行语义消息评估。

主要结果

RQ1：多语言环境中的性能

• 最佳整体方法：UniLog 在所有评估方法中取得了最高的整体性能，在五种语言上的平均全准确率为 20.35%。它优于最佳 LLM（DeepSeek-V3，全准确率 10.96%），且优势具有统计学显著性。
• 语言差异：观察到不同语言之间存在显著的性能差异。JavaScript consistently 产生了最高的性能（UniLog 全准确率：44.83%），而 Python 表现最低（UniLog 全准确率：8.30%）。
• LLM 性能：在 LLM 中，DeepSeek-V3 表现最佳，但自托管模型（例如 Llama3、Qwen2.5-Coder）在特定子任务（例如级别准确率）上表现出具有竞争力的性能，尽管其端到端准确率较低。

RQ2：训练策略的影响

• 单语言与多语言：当控制总训练预算时，单语言训练 consistently 优于多语言联合训练。例如，Mono-LoRA（每种语言 24k 实例）实现了 15.13% 的全准确率，而 Multi-LoRA-24k（每种语言 4.8k 实例）仅实现了 13.10%。
• 数据效率：UniLog 展现了卓越的数据效率。Mono-UniLog-L 变体仅使用每种语言 500 个实例（预热）进行训练，就实现了 16.24% 的全准确率，优于使用每种语言 24,000 个实例的 Mono-LoRA（15.13%）。
• 指标敏感性：增加训练数据规模对位置准确率的影响最为显著，而级别准确率和消息准确率则更多地受到特定方法设计和适应策略的影响。

RQ3：特定于语言的特征

• 位置难度：预测难度因结构上下文而异。循环块（类别 3） 是最难预测的（准确率 26.3%）。与 JavaScript 相比，Python 具有更高密度的循环，这与其较低的位置预测准确率相关。
• 级别和消息：日志级别分布和消息内容因语言而异。Python 表现出更高的消息多样性（distinct2），使得精确匹配更加困难，而 JavaScript 消息在某些类别中更具公式化，有助于生成。
• 语义质量：“LLM 作为裁判”分析显示，UniLog 的语义能力被精确匹配指标低估了。虽然消息准确率为 22.74%，但39.9% 的生成消息在语义上与目标等价（“相同信息”），这表明严格的精确匹配指标会对有效的变体产生惩罚。

主要贡献

1. 多语言基准测试：发布了一个大规模、平衡的基准测试，包含五种编程语言（Java、Python、JavaScript、TypeScript、C#）的 150,000 个日志语句实例。
2. 实证评估：在统一的实验条件下，全面比较了三种最先进的端到端方法和五种 LLM，揭示了显著的跨语言性能差距。
3. 训练策略分析：证明了在有限的数据预算下，特定于语言的适应（单语言训练）优于联合多语言训练，并且轻量级预热策略（UniLog）可以超越大规模微调。
4. 特征分析：识别了驱动性能差异的具体因素，包括循环密度、日志级别分布和消息多样性，为未来针对特定语言的方法提供了基础。
5. 可复现性：公开发布了数据集、实验代码和结果。

意义与主张

该论文主张，简单地扩大模型规模或增加训练数据量不足以实现稳健的多语言日志语句生成。相反，研究结果表明，设计针对目标语言特定特征的方法至关重要。

该研究强调：

• UniLog 结合基于检索的提示和轻量级预热，目前是多语言设置中最有效的策略。
• 当数据有限时，特定于语言的适应比通用的多语言训练产生更好的结果。
• 跨语言性能差距并非均匀分布；它们源于结构差异（例如循环密度）和日志记录习惯（例如消息多样性）。
• 仅依赖精确字符串匹配（消息准确率）的评估指标可能会显著低估生成日志的实际效用，因为即使措辞不同，语义等价性通常也能得到保持。

作者得出结论，未来的自动化日志技术必须明确考虑特定于语言的日志记录特征和插入类别分布，以在多语言软件开发环境中实现稳健的性能。