注
由于其公司的保密政策，本文没有公开源代码，数据是公开的。

---

摘要

问题

• 许多自动日志工具被设计用来帮助开发人员完成日志任务之一。这些工具在某些情况下很有用，但通常不能提供全面的日志解决方案。
• 尽管最近的研究已经开始探索端到端日志，但它仍然在很大程度上受到微调的高成本的限制，阻碍了它在软件开发中的实际用途。

创新点

• UniLog是一个基于大型语言模型(llm)的上下文学习(ICL)范式的自动日志框架。
• UniLog可以生成一个适当的日志记录语句，该语句只包含一个提示符，其中包含五个演示示例，而不需要任何模型调优。
• UniLog在预热后只需要几百个随机样本，就可以进一步增强其记录能力。

效果

• 测井位置选择准确率76.9%
• 预测冗余程度准确率72.3%
• 在生成日志消息时BLEU-4评分27.1
• UniLog所需的参数调优时间不到调优相同LLM所需参数调优时间的4%

---

一、介绍

  随着软件规模和复杂性的快速增长，日志记录越来越成为软件可靠性保证不可或缺的实践。目前构建日志记录的研究主要聚焦于三个子任务上：

• 确定日志记录位置
• 设置详细级别（Verbosity level）
• 生成日志消息

  虽然以前的日志记录方法在不同的子任务上得到了较好的结果，但它们并没有将日志记录任务作为一个整体来考虑。目前一种用于日志记录的一体化解决方案LANCE能够从整体的角度来考虑这三个子任务，但是在涉及模型调优的两个阶段–多任务预训练和微调时需要大量的时间和计算资源。
  因此本文认为现有方法的实际意义有限，对端到端、轻量级和与代码相关的日志解决方案的需求很大。

---

二、背景和动机

2.1、日志语句生成

  长期以来，对该方面的三个子问题都没有作为一个整体来解决，因此在实际场景中实用性较差。最近提出的LANCE，试图通过使用LLM以端到端方式解决日志问题。然而，由于训练成本较大。从实践的角度看仍然具有局限性。

2.2、大语言模型

  自LLM出现以来，NLP已经发展成为一种新的学习范式，即预训练和微调。在这种范例中，人们选择在不同的下游场景中使用特定任务的数据对预训练的LLM进行微调，而不是以一种非常昂贵的方式从头开始训练LLM。相比预训练，微调所需的计算资源要少得多，因此更节省成本。
  具体来说，在软件工程领域，LLM与微调技术一起，在代码评审生成、模糊测试用例生成、自动程序修复和根本原因分析等任务中取得了巨大的成就。

2.3、上下文学习（In-Context Learning，ICL)

  ICL的优势在于：

• ICL不需要进行架构工程和目标工程
• 所有的指令和描述都是自然语言，便于用户理解
• 直接利用了预训练和提示演示的信息，避免了由于过度依赖下游特定任务数据而导致的微调过拟合问题。

  由此提出了UniLog。具体来说，UniLog不再需要从消耗大量日志数据的训练过程中显式地学习日志记录。相反，它利用llm的类比推理能力，从提示词中提供的代码示例直接推断出预期的日志记录语句

---

三、UNILOG

  UniLog建立在大型语言模型Codex的上下文学习范式（ICL）之上，本章主要介绍了骨干(3.1)、提示(3.2)和可选预热(3.3)的设计细节，以下为整个模型的流程图

3.1、模型骨干

  本文选择Codex作为UniLog的支柱，Codex是基于GPT-3的LLM，它利用GitHub上的大量存储库来增强代码生成能力。通过采用Codex作为主干，UniLog可以充分利用Codex模型的知识，减轻由于这种差异而导致的性能下降。此外，由于Codex的参数规模很大，预训练中使用的数据量很大，UniLog可以直接从提示中推断答案，而不需要对模型进行微调。
  UniLog以黑盒方式使用LLM，因此可以随意替换主干。但是当使用不提供微调api的闭源模型(例如GPT-4)时，UniLog不能执行模型预热，这可能会影响性能。

3.2、提示策略

3.2.1、提示格式

  尽管大多数LLM的预训练目标包括文本生成任务，但它们并没有明确考虑生成的文本应该插入到哪里。为了使llm能够完成“记录到哪里”的任务，一种直观的解决方案是将日志任务转换为代码完成任务:预测每行代码之后是否应该生成日志语句。然而，如果这种范式在目标代码片段有二进制的行，模型将需要执行二进制的推断，从而导致效率低下。此外，在日志和非日志语句之间的代码行比例上存在明显的不平衡，日志语句的数量远远少于非日志语句。例如，马斯特罗帕罗等人指出，几乎96%的Java方法不包含日志记录语句。这些样本中的不平衡可能导致低召回率，这意味着几乎每一行都更有可能被预测为不需要日志记录语句，这可能严重损害我们的日志记录性能。

  所以，本文的做法为在每个换行符位置添加一个特殊的标记来表示行ID，然后将代码片段平展为序列格式。

  在指令中，UniLog要求模型提供生成的日志语句和要插入的目标行ID。

3.2.1、提示样例

  在UniLog中，我们选择了KATE，一种简单的kNN-based采样算法，在实践中不会涉及太多的计算开销，用于上下文示例扩增。具体地说，我们首先将训练数据中的所有候选代码段纳入向量表示$v$。然后，对于每个向量化查询$v_q$，我们计算它与所有候选查询之间的相似度指标$d(v_q,v)$，输出前5个结果作为示例。

3.3、预热策略

  预热与微调有着截然不同的目的与做法:

• 微调通过使用相关样本进行训练来提高llm在特定任务上的性能，使用不记录语句(即完整提示中的查询)的代码片段进行训练。
• 预热则增强了llm的一般类比能力，即根据提示中的每条指令找到有限上下文示例的共同特征。使用完整提示作为输入，每个提示包括一条指令、几个演示示例和一个查询。

  在UNILOG的实现中，我们将所有预热样例的指令设置为相同的目标(即，日志语句生成)，并将标记的代码片段设置为提示示例，以特定于任务的方式提高ICL能力。因此，整个预热过程如下:

• 默认情况下，UniLog首先从验证集中随机选择500个样本作为预热提示的查询。
• 然后，对于每个查询，UniLog采用KNN算法在训练集中再搜索5个最相似的样本作为提示例，附加它们的groundtruth标签，并与固定的指令一起打包成一个完整的提示。
• 之后，所有的提示将被提交给Codex进行批量参数调整。

---

四、评估

  本文设置了以下三个研究问题:

• UniLog与现有的基于llm的日志方法相比如何?
• 与 微调相比，ICL能给日志记录带来多少改进?
• 不同的ICL策略如何影响日志记录的有效性?

4.1、UniLog与现有的基于LLM的日志方法相比如何

  为了证明UniLog在日志语句生成任务中的有效性，我们采用了带和不带预热的两个版本的UniLog(即，UniLog-w/ warm和UniLog-w/o warm)来与专门为日志任务设计的其他日志方法进行比较。考虑到重现基于LLM的方法需要微调的难度，所以直接使用了LANCE原论文中报告的评估结果，而不是再次对其进行重新训练。由于原论文没有采用BLEU进行评价，因此在结果表中用N/A代替了该指标。

  在没有模型调优的情况下，UniLog在所有指标中都优于LANCE。

4.2、与微调相比，ICL能给日志记录带来多少改进

  实验结果如表2所示，表明Codex-ICL优于Codex-FT, MA优势14.3%，BLEU优势16.3。这些结果清楚地表明了Codex-ICL在日志消息生成方面的优越性。

然而，我们观察到Codex-ICL在较简单的任务中没有取得显着优势，即位置预测和水平预测。
日志位置预测分析
  尽管CodexFT显示出10%的高PA，但该度量本身的实际指导作用有限，因为在大多数实际场景中，将日志语句移动几行并不会产生显著差异。因此，我们利用位置距离来进一步评估预测与实际情况之间的行间隔。例如，如果预测行ID为<line4>，真实线ID为<line3>，则位置距离为1。

  如图6所示，误差预测在位置(即非零位置距离)上的位置距离分布用累积分布函数(CDF)表示。这说明在Codex-ICL和Codex-FT之间的分布没有显著差异。

详细级别（Verbosity level）预测分析
  详细级别预测分析数据集中有五个日志详细级别:致命(fatal)、错误(error)、警告(warn)、信息(info)和调试(debug)。
  这些级别服务于不同的目的。例如，Fatal和Error处理严重问题并生成错误消息，而Info和Debug在大多数情况下提供可忽略或琐碎的信息。
  然而，对于级别评估来说，LA是不够的，因为将Debug预测为Info或Fatal在实践中可能会产生截然不同的影响。因此，我们引入水平距离来细粒度量化预测水平与真实水平之间的差距。例如，如果预测结果为Debug，真值也为Debug，则距离为0；如果预测结果为Debug，而真实值为Error，则级别距离为3，因为它们之间有三个级别。如图6所示，Codex-ICL和Codex-FT之间的能级距离分布相似。例如，这两个主要预测与基本事实(约90.0%)仅相差一个水平。然而，Codex-ICL仍然产生更高比例的精确匹配预测(即LA)。因此，我们认为基于ICL的方法在水平预测方面有轻微的优势。

4.3、不同的ICL策略如何影响日志记录的有效性

  本节将分析不同配置对日志记录有效性的四个方面的影响:(1)模型主干的类型，(2)提示示例的数量，(3)提示示例的排列方法，(4)预热示例的数量。

模型主干的类型

  为了确保ICL范式能够被利用，LLM的大小必须保证足够大。因此，在实验中，我们将不考虑规模相对较小的LLM。为了确保规模(即>100M)和结构(即仅解码器)的公平性，我们选择了GPT-3系列中的型号作为骨干，即GPT-3- a、GPT-3- b、GPT-3- c和Codex。

  实验结果如表4所示。可以看出，与其他llm相比，UniLog在使用Codex作为主干时具有相对较大的精度优势。例如，在测井位置方面，Codex的精度比GPT-3系列高30%左右，而BLEU的精度甚至是其他系列的两倍以上。结果表明，使用与代码相关的模型作为主干极大地影响了UniLog的性能，而简单地增加通用LLM的参数并不能有效地提高日志记录能力。

提示示例的数量

  为了研究提示示例数的影响，我们考虑了比较实验中示例数的五个层次:1、3、5、10和15。特别是，我们观察到，当示例数量超过15时，有效性指标没有显着改善。因此，我们选择不将这些结果包含在表中。

  实验结果如表5所示。随着提示示例数量的增加，所有指标都会逐渐改善。但随着提示示例数量超过5个，指标的增长速度逐渐放缓，出现饱和趋势。例如，当提示示例数从5个增加到10个时，BLEU略有下降;当数字增加到15时，其BLEU与数字为5时保持相同。此外，更多的提示示例可能导致更重的模型计算消耗和更慢的推理速度，从而导致实际效率低下。因此，我们最终设计的UniLog只有5个提示示例。

提示示例的排列方法
文中主要选择三种方法进行对比实验

• (1)随机选择然后随机排序(即随机)
• (2)根据KNN相似度选择然后升序排序(即𝑘NN-ascend)
• (3)根据KNN相似度选择然后降序排序(即𝑘NN-descend)。

  实验结果如表6所示。我们发现𝑘NN-ascend在所有指标中都优于其他两种选择策略，这表明它在UniLog提示符中起着不可或缺的作用。

预热示例的数量
  本文考虑了五个层次的样本数进行比较实验:100、300、500、700和900。特别是，我们观察到，当样本数量超过900时，有效性指标没有显着改善。因此，我们选择不将这些结果包含在表中。

  实验结果如表7所示。当样本数量大于500时，总体指标不再有明显改善，有些指标甚至出现下降，这表明UniLog通过热身提高的有效性是有限的，趋于饱和。例如，当样品数量从500个增加到700个时，MA没有增加，CMA和BLEU都略有下降。此外，随着样本数量的增加，训练开销逐渐增加，不再满足第1节所示的快速部署需求。因此，考虑到计算成本，我们最终只设计了500个样本的UniLog

---

五、讨论

5.1、有效性威胁

• 数据泄露
  CodeX是使用2020年5月前的数据进行预训练，而本文的数据用的是2022年收集的，如果在此期间数据库中有些代码没有变动的话，则会导致数据泄露
• 随机性
  随机性可能在两个方面影响性能:(1)llm推理中的随机性;(2)RQ3中随机选择提示演示和预热样本所引入的随机性。

5.2、道德问题

  UniLog可能会遇到与LLM使用相关的道德问题，即

• (1)使用第三方LLM模型作为骨干可能会导致代码或日志的隐私泄露。
• (2)使用包含刻板印象或种族偏见的代码作为候选人可能会产生有害的日志信息。

5.3、误差分析

  本文将错误消息分为以下三种情况:(1)具有相似语义的消息，(2)具有不同记录的消息，以及(3)具有无意义信息的消息。

具有相似语义的消息
  基于精确匹配标准，由于同义词替换、词序变化或包含更简洁或详细的描述，这些语义相同的消息被认为是错误的。尽管表达式并不完全相同，但它们具有相似的语义。因此，我们认为它在开发过程中可能不会产生重大影响

具有不同记录的消息
  在我们提取的错误日志消息中，116条(23.2%)错误消息涉及错误的位置预测，导致记录的变量或描述与真实情况完全不同。然而，我们发现这些信息可能仍然有用。为了进一步提高LLM在正确位置插入日志的能力，我们建议引入更多不同日志位置的预热样例，从而提高LLM对日志位置的敏感性

具有无意义信息的消息
  我们发现167条错误消息(33.4%)重新编码了无用的变量或提供了完全无意义的描述。在分析它们的提示输入后，我们发现这是由于演示和查询之间编码风格的显著差异。编码风格的差异会阻碍UniLog通过ICL推理和与演示的类比来有效地学习日志。为了缓解这些问题，我们建议增加候选集的多样性，合并更多具有不同编码风格的代码片段，以提高对各种查询的提示演示的质量v

---

六、总结

• 本文介绍了UniLog，这是一种采用大型语言模型(llm)的上下文学习(ICL)范式的新型日志框架。UniLog以端到端方式执行自动日志记录，包括选择日志记录位置、预测详细级别和生成日志消息。

• UniLog不需要在每次使用之前对目标代码样式进行微调。UniLog已经对从1,465个GitHub存储库中提取的12,012个代码片段进行了评估，并在所有日志任务中实现了SOTA精度。

• UniLog所需的参数调优时间不到SOTA方法所需的4%。作为第一个在日志记录中采用ICL范式的工作，我们相信UniLog可以促进更好的日志记录实践，并启发在一般日志分析研究中设计有效的框架。

---