Pith. sign in

REVIEW 5 major objections 6 minor 37 references

A Word is Worth 4-bit: Efficient Log Parsing with Binary Coded Decimal Recognition

T0 review · 5 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Pith's one-line read A 312k-parameter character-level log parser can match LLM-based parsing accuracy on template extraction.

desk verdict A genuinely new lightweight log-parsing architecture with a promising accuracy/efficiency tradeoff, but the headline comparison rests on a train/test split the paper asserts rather than demonstrates. read the letter →

arxiv 2506.01147 v1 pith:CKURW5MT submitted 2025-06-01 cs.CL cs.LG

classification cs.CLcs.LG
keywords logparsingtemplateextractioncharacter-levelmodelbinary-codeddecimalconditionalrandomfieldparametermaskLLM-basedLoghub-2k
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper claims that log-template extraction, normally done by large language models, can be done just as accurately by a small supervised character-level network. The proposed parser, 4bitparser, labels every character as static or variable, then packs the labels in groups of four into a binary-coded decimal, turning the problem into a compact sequence-tagging task with only 312k parameters. On the revised Loghub-2k benchmark and an industrial dataset, the authors report accuracy that matches the LLM-based parser LILAC (average PA 0.68 vs 0.62, FTA 0.62 vs 0.63, PMA 0.92 vs 0.93), while running up to 20 times faster with its parsing cache. The significance would be that organizations could deploy precise, fine-grained log parsing without paying for LLM inference, nondeterminism, or latency.

What carries the argument

The load-bearing identity is the BCD map $m_d(y_1,y_2,y_3,y_4) = y_1 2^3 + y_2 2^2 + y_3 2^1 + y_4 2^0$, which sends each 4-bit static/variable block to one of 16 decimal classes. This compression lets a character-level transformer, a 1D CNN with kernel and stride 4, a BiLSTM, and a CRF predict whole templates efficiently; the CNN aggregates four-character semantic features, and the CRF enforces coherent label transitions across the decimal sequence. The parsing cache, a fixed-depth tree invoked before and after prediction, avoids re-running the model on already-seen templates.

What would settle it

Run an exact or normalized line-hash comparison between the revised Loghub-2k test set and the Loghub-2.0 training sample; any substantial overlap would overturn the PA/FTA comparison with LILAC, and even zero exact matches should be checked with fuzzy near-duplicate matching on parameter values.

Watch

Extended reading notes

Core claim

4bitparser's central claim is that character-level parameter-mask prediction, compressed through BCD encoding and decoded by a CRF over 16 classes, recovers log templates granularly enough to rival LLM-based parsing. The model is a character-embedding transformer encoder whose hidden states are downsampled in non-overlapping groups of four by a 1D CNN, then passed through a BiLSTM and a CRF; the CRF predicts a decimal 0-15 per group, and the decimal sequence maps back to a binary mask in which 1s become the <*> placeholder. Trained on 50k diverse lines from Loghub-2.0 and tested on revised Loghub-2k, it reports template-level and granularity metrics on par with or better than LILAC on most sub-datasets, and top PMA (0.98) on the Idata industrial set. The paper presents this as evidence that a lightweight supervised model can replace LLM-based parsers for precise template extraction while being 20x more efficient with the cache (5x without it).

Load-bearing premise

The reported accuracy assumes the 28,000 test lines from Loghub-2k are truly absent from the 50,000 training lines drawn from Loghub-2.0; the paper asserts this but gives no mechanism, and both datasets come from the same raw Loghub logs, so any overlap would inflate the numbers.

Editorial extensions

If this is right

  • If accurate, 4bitparser removes the need for an LLM at inference time: template quality comparable to LILAC becomes available from a 4.2 MB model, cutting cost, latency, and nondeterminism.
  • The 20x speedup with the parsing cache (5x without it) puts character-granular parsing in the range of in-memory, real-time log pipelines, closer to syntactic parsers than to LLM-based ones.
  • Fine-grained character-level masks, as measured by PMA, make the extracted templates usable for tasks that need precise parameter/static distinctions, such as error-message clustering and audit-trail analysis.
  • Only 200 labeled lines from a new industrial system (Idata-FT) were enough to fine-tune the model to 0.98 PMA, suggesting small bespoke datasets can adapt the parser to new log formats.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • [editorial] Because BCD compresses the label sequence fourfold, a similar scheme with larger blocks (8-bit or 16-bit) or vocabulary-based dynamic grouping could cut inference cost further on long logs, though granularity at block boundaries would need testing.
  • [editorial] Assuming the train/test split is clean, the practical recipe is to pre-train on diverse Loghub templates and fine-tune on a few hundred lines per deployment; a testable prediction is that accuracy on a new system tracks template diversity, not log volume.
  • [editorial] The authors' stated limitation on fixed character vocabulary suggests byte-level or subword embeddings, or a vocabulary-free head, is the obvious next step; this architecture should transfer to such inputs with little change.
  • [editorial] Re-evaluating 4bitparser with group accuracy, the metric the authors leave out, would show whether its template coverage supports anomaly detection; the paper does not test this.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 6 minor

Summary. This paper introduces 4bitparser, a character-level log parser that predicts a sequence of 4-bit binary-coded decimal (BCD) labels over groups of four characters, from which a parameter mask and log template are derived. The architecture chains character embeddings, an 8-head transformer encoder, a 1D CNN with kernel and stride 4, a BiLSTM, and a CRF over 16 BCD classes, plus a fixed-depth parsing cache. The model is trained on 50k Loghub-2.0 lines and evaluated on the revised Loghub-2k benchmark and on an internal industrial dataset (Idata), using PA, FTA, and PMA metrics. The central claim is that the 312k-parameter model matches the LLM-based LILAC parser in template accuracy while being up to 20 times faster.

Significance. The claimed result is practically significant if reproducible: it would demonstrate that a compact supervised character-level model can replace an LLM-based parser for template extraction on public and industrial logs, with large inference-cost savings. The BCD grouping of the parameter mask is a clean output-compression idea, and the ablation study in Appendix C gives useful architecture guidance. The paper is also honest about several limitations, including vocabulary dependence and the lack of continual learning. However, the current evidence is provisional: there is no code release, no train/test split hash, no error bars or significance tests, and an important industrial data exclusion is not stress-tested. Strengths include a clear formalization (Eqs. 1-4), a detailed architecture table (Table 3), and direct comparisons against syntactic, semantic, and LLM baselines.

major comments (5)
  1. [Section 3, Appendix A.1] The train/test disjointness assertion is unsupported. The text says the 28k revised Loghub-2k test lines are all excluded from the training set, but no exclusion mechanism, line-hash deduplication, split script, or data identifiers are given. Because both the 50k training sample and Loghub-2k are drawn from the same raw Loghub collections (Table 2 lists up to 16.6M Loghub-2.0 lines per system), exact or near-duplicate lines between train and test are plausible. If any test lines are memorized by this character-level supervised model, Table 1's averages (PA 0.68, FTA 0.62, PMA 0.92) and the comparison to LILAC would be inflated. Please release the exact split, for example as hashes of train and test line IDs, and report the residual exact-match overlap per dataset.
  2. [Section 3 (LILAC baseline)] The demonstration-selection protocol is under-specified. The paper states that the authors sampled 128 candidate examples and selected three demonstrations, with the candidate set sampled separately for both test sets, but it does not state whether those 128 candidates come from the training split, whether they are disjoint from the test lines, which selection criterion picked the three demonstrations, how many random seeds were used, or how many GPT-3.5-turbo calls were averaged. Because LILAC is stochastic and the reported differences are small (e.g., average FTA 0.63 vs 0.62), a single demonstration draw could change several dataset-level comparisons. Please provide the prompt template, the candidate pool construction, the selection criterion, and variance over seeds.
  3. [Appendix A.2, Table 1] The Idata evaluation excludes the contested template without a sensitivity analysis. The appendix reports that one contested template covers 3,600 of the 6,000 annotated lines and that correctly identifying it could move Parsing Accuracy above 50 percent; the paper then evaluates only the remaining 2,400 lines and 35 templates. This makes the Idata numbers in Table 1 (4bitparser PA 0.93, PMA 0.98 vs LILAC PA 0.90) dependent on a single annotation decision. Please report PA, FTA, and PMA on the full set under both possible labels for the contested template, or justify the exclusion with a robustness analysis.
  4. [Section 4.2, Figure 2] The efficiency claim is not sufficiently controlled. The 20-times-more-efficient headline depends on the parsing cache comparison between 4bitparser and LILAC, but the figure and text do not report whether LILAC's throughput includes GPT-3.5-turbo API latency and network time, what batch sizes and hardware settings were used for each parser, or the cache hit rates. Without these details, the speedup ratio is not reproducible. Please specify the measurement protocol, report cache hit rates per dataset, and give throughput for Cacheless-4bitparser, 4bitparser, and LILAC under matched conditions.
  5. [Section 4.1, Table 1] All results are single point estimates with no variance or significance testing. For example, the average PA difference between 4bitparser and LILAC is 0.06 (0.68 vs 0.62), while average FTA is slightly lower for 4bitparser (0.62 vs 0.63); dataset-level PA differences are often 0.01 to 0.08. Without multiple seeds for model training, LILAC sampling, and LogPPT training, it is not possible to determine whether these differences are meaningful. Please report means and standard deviations over at least three runs and a paired significance test for the main comparisons.
minor comments (6)
  1. [Equations (2)-(3)] The index range n in [0, (|ti|/4)-1] uses |ti| where the sequence length is |t|, and the padding rule should specify that padding is appended at the end; please clarify whether the mask for padding positions is always 0.
  2. [Section 4.1 vs Appendix B] The parameter count is inconsistent: Section 4.1 says 314k parameters while Appendix B and the abstract say 312k; please reconcile the number.
  3. [Appendix A.1, Table 2] The dataset statistics are internally inconsistent: the text says Loghub contains 16 software systems but Table 2 lists 14; Section 3 says the revised Loghub-2k has 1,139 unique templates while Table 2 totals 1,147, and the difference equals the 8 Proxifier templates that are absent from Table 1. Please clarify the exact test set composition and whether Proxifier is part of the benchmark.
  4. [Abstract, Section 2.2] Calling the architecture novel is overstated because the transformer-BiLSTM-CRF combination is standard; the genuinely new elements are the BCD output encoding and the cache. Please rephrase to avoid overclaiming.
  5. [Figure 2] The y-axis label does not state the unit (lines per second), and the figure does not indicate whether the cache is warm; adding this information would make the efficiency comparison interpretable.
  6. [Section 4.1] The phrase that Drain identifies more templates than the other parsers is confusing because Drain has the highest FTA of 0.67 but a lower PA of 0.56 on Idata; please specify that this refers to FTA.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: 4bitparser is trained on external ground-truth labels and evaluated on held-out benchmarks; the BCD encoding is a deterministic label re-encoding, not an input-derived prediction.

full rationale

The paper's derivation chain is a standard supervised sequence-labeling setup. The model predicts a binary parameter mask per character (Eq. 1), which is deterministically re-encoded as 4-bit BCD decimals (Eqs. 2-3) and trained with negative log-likelihood (Eq. 4). The BCD mapping is a fixed bijective transformation of the target labels, not a parameter fitted to the test output, so the prediction is not equivalent to its input by construction. Training uses 50k lines from Loghub-2.0 with external ground-truth templates, and evaluation is on revised Loghub-2k and a manually annotated industrial set. The headline comparison against LILAC, Drain, Brain, and LogPPT is an external benchmark comparison, not a fitted quantity. No load-bearing self-citations appear: the cited prior works (Thaler et al., Hashemi et al., Jiang et al., Zhu et al.) are external sources for architecture inspiration, metrics, and datasets. The ablations in Appendix C are ordinary model selection. The asserted exclusion of Loghub-2k test lines from the training set is a data-hygiene concern that could affect validity if unverified, but it is not a circularity: even a leak would be test-set contamination, not a definitional reduction of the reported accuracy to the model's training objective. Similarly, the exclusion of the contested Idata template is an annotation-quality decision, not a circular derivation. Accordingly, no circular step can be quoted and exhibited under the required standard.

Assumptions & free parameters 6 free parameters · 4 assumptions · 0 invented entities

The central results rest on several hand-chosen hyperparameters and dataset assumptions. The most consequential are the fixed 4-bit grouping, the 50k-line cap with 50 lines per template, and the untested assumption that character-level parameter masks are a complete representation of log templates.

free parameters (6)
  • BCD group size = 4
    The encoding packs 4 binary labels per decimal, chosen via ablation and justified only by the empirical claim in Appendix C that variable/static sub-tokens average four characters.
  • CNN kernel and stride = 4
    Downsampling factor matches BCD grouping; alternative kernel sizes (2, 3, 5) reported drops in performance in Appendix C.
  • Training set size = 50,000 log lines
    Selected from Loghub-2.0 with a 50-line-per-template cap to balance diversity and compute; the sampling procedure is not fully specified.
  • Learning rate = 1e-3
    Adam optimizer default except learning rate; not justified beyond the appendix.
  • Dropout rate = 0.4
    Applied after CNN and BiLSTM to prevent overfitting; no tuning analysis reported.
  • Embedding dimension, attention heads, BiLSTM hidden size = 128, 8, 64
    Architecture dimensions from ablations; they determine the 312k parameter count central to the low-resource claim.
assumptions (4)
  • domain assumption Character-level parameter masks fully represent log templates
    The paper assumes every template can be recovered by binary classification of each character as static or variable, following Hashemi et al. (2024). This ignores potential multi-token variable boundaries that are not character-disjoint, though the mask definition handles it.
  • ad hoc to paper Static and variable sub-tokens typically average four characters
    Appendix C justifies the fixed 4-gram downsampling with this claim, but no evidence or citation is provided; it is an empirical assumption specific to this work.
  • domain assumption Train and test sets are disjoint
    Section 3 asserts the 28k Loghub-2k test lines are excluded from the 50k Loghub-2.0 training lines, but no deduplication mechanism is described; the integrity of the benchmark depends on this.
  • domain assumption Ground truth annotations in revised Loghub-2k and Idata are correct and consistent
    The paper treats the revised Loghub-2k annotations and the consensus Idata labels as noise-free, and does not report inter-annotator agreement on the revised Loghub-2k.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Word is Worth 4-bit: Efficient Log Parsing with Binary Coded Decimal Recognition." pith.science (2026). https://pith.science/paper/CKURW5MT

@misc{pith2026250601147,
  author       = {Pith},
  title        = {Pith review of: A Word is Worth 4-bit: Efficient Log Parsing with Binary Coded Decimal Recognition},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CKURW5MT}},
  note         = {Machine review of arXiv:2506.01147}
}
read the original abstract

System-generated logs are typically converted into categorical log templates through parsing. These templates are crucial for generating actionable insights in various downstream tasks. However, existing parsers often fail to capture fine-grained template details, leading to suboptimal accuracy and reduced utility in downstream tasks requiring precise pattern identification. We propose a character-level log parser utilizing a novel neural architecture that aggregates character embeddings. Our approach estimates a sequence of binary-coded decimals to achieve highly granular log templates extraction. Our low-resource character-level parser, tested on revised Loghub-2k and a manually annotated industrial dataset, matches LLM-based parsers in accuracy while outperforming semantic parsers in efficiency.

Figures

Figures reproduced from arXiv: 2506.01147 by the authors.

Figure 1
Figure 1. Diagram of the proposed neural network architecture. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Throughput of log parsers on Loghub-2k. three demonstrations for the GPT-3.5-turbo lan￾guage model, with the candidate set for demonstra￾tion sampled separately for both test sets following the approach of Xu et al. (2024). 4 Experimental Results 4.1 Effectiveness of 4bitparser The results, presented in [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

37 extracted references · 26 canonical work pages

  1. [1]

    Merve Astekin, Max Hort, and Leon Moonen. 2024. An exploratory study on how non-determinism in large language models affects log parsing. In Proceedings of the ACM/IEEE 2nd International Workshop on Interpretability, Robustness, and Benchmarking in Neural Software Engineering, pages 13--18

  2. [2]

    Hetong Dai, Heng Li, Che-Shao Chen, Weiyi Shang, and Tse-Hsun Chen. 2020. Logram: Efficient log parsing using n n-gram dictionaries. IEEE Transactions on Software Engineering, 48(3):879--892

  3. [3]

    William A Falcon. 2019. Pytorch lightning. GitHub, 3

  4. [4]

    Shuzheng Gao, Xin-Cheng Wen, Cuiyun Gao, Wenxuan Wang, Hongyu Zhang, and Michael R Lyu. 2023. What makes good in-context demonstrations for code intelligence tasks with llms? In 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE), pages 761--773. IEEE

  5. [5]

    o l \"a , and Mika V M \

    Shayan Hashemi, Jesse Nyyss \"o l \"a , and Mika V M \"a ntyl \"a . 2024. Logpm: Character-based log parser benchmark. In 2024 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), pages 705--710. IEEE

  6. [6]

    Pinjia He, Jieming Zhu, Zibin Zheng, and Michael R Lyu. 2017. Drain: An online log parsing approach with fixed depth tree. In 2017 IEEE international conference on web services (ICWS), pages 33--40. IEEE

  7. [7]

    Yintong Huo, Yuxin Su, Cheryl Lee, and Michael R Lyu. 2023. Semparser: A semantic parser for log analytics. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE), pages 881--893. IEEE

  8. [8]

    Zhihan Jiang, Jinyang Liu, Zhuangbin Chen, Yichen Li, Junjie Huang, Yintong Huo, Pinjia He, Jiazhen Gu, and Michael R Lyu. 2024 a . Lilac: Log parsing using llms with adaptive parsing cache. Proceedings of the ACM on Software Engineering, 1(FSE):137--160

Show all 37 references
  1. [9]

    Zhihan Jiang, Jinyang Liu, Junjie Huang, Yichen Li, Yintong Huo, Jiazhen Gu, Zhuangbin Chen, Jieming Zhu, and Michael R. Lyu. 2024 b . https://doi.org/10.1145/3650212.3652123 A large-scale evaluation for log parsing techniques: How far are we? In Proceedings of the 33rd ACM SI...

  2. [10]

    Guolin Ke, Di He, and Tie-Yan Liu. 2021. https://openreview.net/forum?id=09-528y2Fgf Rethinking positional encoding in language pre-training . In International Conference on Learning Representations

  3. [11]

    Zanis Ali Khan, Donghwan Shin, Domenico Bianculli, and Lionel Briand. 2022. Guidelines for assessing the accuracy of log message template identification techniques. In Proceedings of the 44th International Conference on Software Engineering, pages 1095--1106

  4. [12]

    Diederik Kingma and Jimmy Ba. 2015. Adam: A method for stochastic optimization. In International Conference on Learning Representations (ICLR), San Diega, CA, USA

  5. [13]

    Van-Hoang Le and Hongyu Zhang. 2023. Log parsing with prompt-based few-shot learning. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE), pages 2438--2449. IEEE

  6. [14]

    Zhenhao Li, Chuan Luo, Tse-Hsun Chen, Weiyi Shang, Shilin He, Qingwei Lin, and Dongmei Zhang. 2023. Did we miss something important? studying and exploring variable-aware log abstraction. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE), pages 830-...

  7. [15]

    Yudong Liu, Xu Zhang, Shilin He, Hongyu Zhang, Liqun Li, Yu Kang, Yong Xu, Minghua Ma, Qingwei Lin, Yingnong Dang, et al. 2022. Uniparser: A unified log parser for heterogeneous log data. In Proceedings of the ACM Web Conference 2022, pages 1893--1901

  8. [16]

    Xuezhe Ma and Eduard Hovy. 2016. https://doi.org/10.18653/v1/P16-1101 End-to-end sequence labeling via bi-directional LSTM - CNN s- CRF . In Proceedings of the 54th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 1064--1074, Berli...

  9. [17]

    Sasho Nedelkoski, Jasmin Bogatinovski, Alexander Acker, Jorge Cardoso, and Odej Kao. 2021. Self-supervised log parsing. In Machine Learning and Knowledge Discovery in Databases: Applied Data Science Track: European Conference, ECML PKDD 2020, Ghent, Belgium, September 14--18, ...

  10. [18]

    Stefan Petrescu, Floris Den Hengst, Alexandru Uta, and Jan S Rellermeyer. 2023. Log parsing evaluation in the era of modern software systems. In 2023 IEEE 34th International Symposium on Software Reliability Engineering (ISSRE), pages 379--390. IEEE

  11. [19]

    Keiichi Shima. 2016. Length matters: Clustering system log messages using length of words. arXiv preprint arXiv:1611.03213

  12. [20]

    Monika Steidl, Marko Gattringer, Michael Felderer, Rudolf Ramler, and Mostafa Shahriari. 2022. Requirements for anomaly detection techniques for microservices. In International Conference on Product-Focused Software Process Improvement, pages 37--52. Springer

  13. [21]

    Charles Sutton, Andrew McCallum, et al. 2012. An introduction to conditional random fields. Foundations and Trends in Machine Learning , 4(4):267--373

  14. [22]

    Jan Svacina, Jackson Raffety, Connor Woodahl, Brooklynn Stone, Tomas Cerny, Miroslav Bures, Dongwan Shin, Karel Frajtak, and Pavel Tisnovsky. 2020. On vulnerability and security log analysis: A systematic literature review on recent trends. In Proceedings of the International ...

  15. [23]

    Stefan Thaler, Vlado Menkonvski, and Milan Petkovic. 2017. Towards a neural language model for signature extraction from forensic logs. In 2017 5th International Symposium on Digital Forensic and Security (ISDFS), pages 1--6. IEEE

  16. [24]

    Gido M Van de Ven and Andreas S Tolias. 2019. Three scenarios for continual learning. arXiv preprint arXiv:1904.07734

  17. [25]

    Danny TY Wu, Nikolas Smart, Elizabeth L Ciemins, Holly J Lanham, Curt Lindberg, and Kai Zheng. 2017. Using ehr audit trail logs to analyze clinical workflow: a case study from community-based ambulatory clinics. In AMIA Annual Symposium Proceedings, volume 2017, page 1820. Ame...

  18. [26]

    Yifan Wu, Bingxu Chai, Siyu Yu, Ying Li, Pinjia He, Wei Jiang, and Jianguo Li. 2024. Logptr: Variable-aware log parsing with pointer network. arXiv preprint arXiv:2401.05986

  19. [27]

    Yuchen Xia, Jiho Kim, Yuhan Chen, Haojie Ye, Souvik Kundu, Nishil Talati, et al. 2024. Understanding the performance and estimating the cost of llm fine-tuning. arXiv preprint arXiv:2408.04693

  20. [28]

    Yi Xiao, Van-Hoang Le, and Hongyu Zhang. 2024. Stronger, faster, and cheaper log parsing with llms. arXiv preprint arXiv:2406.06156

  21. [29]

    Junjielong Xu, Ruichun Yang, Yintong Huo, Chengyu Zhang, and Pinjia He. 2024. Divlog: Log parsing with prompt enhanced in-context learning. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, pages 1--12

  22. [30]

    Hang Yan, Bocao Deng, Xiaonan Li, and Xipeng Qiu. 2019. Tener: adapting transformer encoder for named entity recognition. arXiv preprint arXiv:1911.04474

  23. [31]

    Siyu Yu, Pinjia He, Ningjiang Chen, and Yifan Wu. 2023. Brain: Log parsing with bidirectional parallel tree. IEEE Transactions on Services Computing, 16(5):3224--3237

  24. [32]

    Zihao Zhao, Eric Wallace, Shi Feng, Dan Klein, and Sameer Singh. 2021. Calibrate before use: Improving few-shot performance of language models. In International conference on machine learning, pages 12697--12706. PMLR

  25. [33]

    Aoxiao Zhong, Dengyao Mo, Guiyang Liu, Jinbu Liu, Qingda Lu, Qi Zhou, Jiesheng Wu, Quanzheng Li, and Qingsong Wen. 2024. Logparser-llm: Advancing efficient log parsing with large language models. In Proceedings of the 30th ACM SIGKDD Conference on Knowledge Discovery and Data ...

  26. [34]

    Jieming Zhu, Shilin He, Pinjia He, Jinyang Liu, and Michael R Lyu. 2023. Loghub: A large collection of system log datasets for ai-driven log analytics. In 2023 IEEE 34th International Symposium on Software Reliability Engineering (ISSRE), pages 355--366. IEEE

  27. [35]

    Jieming Zhu, Shilin He, Jinyang Liu, Pinjia He, Qi Xie, Zibin Zheng, and Michael R Lyu. 2019. Tools and benchmarks for automated log parsing. In 2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), pages 121--130. IEEE

  28. [36]

    online" 'onlinestring :=

    ENTRY address archivePrefix author booktitle chapter edition editor eid eprint eprinttype howpublished institution journal key month note number organization pages publisher school series title type volume year doi pubmed url lastchecked label extra.label sort.label short.list...

  29. [37]

    write newline

    " write newline "" before.all 'output.state := FUNCTION n.dashify 't := "" t empty not t #1 #1 substring "-" = t #1 #2 substring "--" = not "--" * t #2 global.max substring 't := t #1 #1 substring "-" = "-" * t #2 global.max substring 't := while if t #1 #1 substring * t #2 gl...

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.