LILAC采样算法

3.2 ICL-enhanced parser
图2显示了LILAC 采用的ICL增强型解析器的总体设计,
调采用了ICL 范式使大模型适应日志解析任务, 不需要进行资源密集型模型调优。
此外，它利用演示中的系统特定功能来促进更加准确的日志解析
特别的, 我们提出了一种高效的候选采样算法, 得到搞质量的示例用于有效的ICL
具体来说，LILAC 首先执行分层候选采样算法, 采样一小部分不同的且具有代表性的候选日志消息。
在在线解析过程中,对于每个查询日志, LILAC使用基于KNN示例选择算法来选择相似的演示示例。
这些示例被整合到提示遵循设计格式。 最后， ICL增强型解析器输入提示让大模型得到生成的模版
3.2.1 Candidate Sampling. 候选采样
一个典型的ICL范式应用是涉及最初的采样一小组候选日志消息从生产日志数据
确保候选集的多样性来降低 归纳偏见的潜在风险至关重要
因为不成比例的示例可能会导致大模型对特定示例过度拟合
此外，这些候选者应该具有代表性，即他们应该有能力代表更多的日志数据 提供给大模型更多的系统特殊特征
在实际应用中, 该采样的过程最初可以在历史日志数据上执行, 并定期执行以维护动态候选集
在ICL增强型解析器中，我们退出了一种分层采样算法来提取一个小的,多样化的，从大量日志数据提取具有代表性的
该算法分为两个阶段, 分层聚类和分层配额分布。
它首选根据日志消息的特征将整个日志数据分组到分层集群中
每个集群都包含具有高度相似特征的日志消息, 而不同集群内的日志消息表现出不同的特征。
然后，一个分层配额分配方法, 从不同的集群中选择候选者，同时根据每个集群的日志消息数量为其分配不同的优先级。
Hierarchical clustering: 分层聚类
受先前研究的启发, 我们首先使用top-K频率标记来分组日志消息。
直觉是, 日志消息共享相同的频繁标记更有可能具有相同的模版。
具体来说, 我们首先对每条日志消息进行标记,然后计算浓缩铀的标记频率。
在上述过程中, stop words in the Scipy library 是被排除掉来消除不相关的标记。
对于每条日志消息, 选择具有top-K频率标记是被选择，这些标记形成了分类到不同的粗粒度集群。
换句话说, 在同一粗粒度集群内的所有消息贡献相同的top-K频繁标记
LineId,Content,EventId,EventTemplate
1, LDAP: Built with 111 OpenLDAP: @ ::::: == LDAP / SDK, E20, LDAP: Built with OpenLDAP LDAP SDK
2, LDAP : SSL support 222 unavailable, E23, LDAP: SSL support unavailable
3, suEXEC mechanism enabled 333 lili (wrapper: /usr/sbin/suexec), E18, suEXEC mechanism enabled (wrapper: <*>)
4, Digest: generating 444 secret for digest authentication ..., E4, Digest: generating secret for digest authentication ...
5, Digest: done, E29 555, Digest: done
6, LDAP: Built with OpenLDAP 666 LDAP SDK, E20, LDAP: Built with OpenLDAP LDAP SDK
7, LDAP: SSL support unavailable 777, E23, LDAP: SSL support unavailable
8,"env.createBean2(): Factory error creating channel.jni:jni ( channel.jni, jni)",E10,"env.createBean2(): Factory error creating <*> (<*>, <*>)"
9,config.update(): Can't create 999 channel.jni:jni, E21, config.update(): Can't create <*>
10, LDAP: Built with 111 OpenLDAP LDAP SDK, E20, LDAP: Built with OpenLDAP LDAP SDK
hierichical_clusters.items())：内容
dict_items(( ( 'LDAP', 'SDK', 'with'), {'size': 2, 'cluster': {'/:=@': \[0, ':': 5}}),
(('LDAP', 'SSL', 'support'), {'size': 2, 'cluster': {':': 1, 6}}),
(('enabled', 'suEXEC', 'wrapper'), {'size': 1, 'cluster': {'()/:': 2}}),
(('Digest', 'authentication', 'digest'), {'size': 1, 'cluster': {'.:': 3}}),
(('Digest', 'done'), {'size': 1, 'cluster': {':': 4}}),
(('Factory', 'channel.jni', 'jni'), {'size': 1, 'cluster': {'().:': 7}}),
(('channel.jni', 'config.update', 'jni'), {'size': 1, 'cluster': {"'().:": 8}})])
然而，仅使用频繁标记是不足以区分不同特征的日志消息,
即工相同的频繁标记肯呢个对应于不同的日志模版,
因此，我们利用了特殊字符(即不是字母，数字或空格)以反映日志消息的特征
定义日志消息里的特殊字符作为它的特殊格式,
来自同一模版的日志消息通常共享相同的特殊格式。这是因为日志消息的常量部分(即模版)中的特殊字符总是相同的,
而动态部分中的那些(即参数) 通常是全等的。
例如, 特殊格式
"Received block: blk_358 of size 6710 from /127.0.0.1" is {':','_','.','/'}
对于共享相同模版的其他消息
"Received block: blk_729 of size 8199 from /127.0.0.2"
它们将具有相同的特殊格式。因此，我们使用日志消息的特殊格式来执行细粒度聚类。
详细地说，每个粗粒度集群中的日志消息更进一步根据其特殊格式进行划分，构成细粒度集群,
其中所有日志消息不仅具有相同的top-K频繁标记,而且共享相同的日志格式
Hierarchical quota distribution，分级配额分配
在这个阶段，我们的目标是选择多样化和有代表性的日志消息作为候选从细粒度集群
核心思想是分层分配候选的配额到所有的细粒度集群来提高多样性
此外,我们假设日志消息数量较多的集群更具代表性
因此，在无法实现公平分配的情况下，优先考虑具有更多日志消息的细粒度集群。