Pith. sign in

REVIEW 4 major objections 5 minor 26 references

Diagnosing and Resolving Cloud Platform Instability with Multi-modal RAG LLMs

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

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read A multimodal RAG LLM system, ARCA, triages cloud incidents with 92% accuracy and selects a correct mitigation plan with 72% accuracy, outperforming state-of-the-art alternatives.

desk verdict The log-clustering half of ARCA is solid and worth a look; the headline 92%/72% end-to-end numbers measure near-duplicate retrieval and should not be taken at face value. read the letter →

arxiv 2505.21419 v2 pith:YCWC3TZW submitted 2025-05-27 cs.AI cs.OS

Yifan Wang , Kenneth P. Birman This is my paper
classification cs.AIcs.OS
keywords rootcauseanalysisretrieval-augmentedgenerationAIOpscloudincidenttriageloganomalydetectiontelemetrytimeseriesmultimodalretrievalLLM-as-a-judge
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

The paper argues that cloud incident response can be automated beyond single-modality anomaly detectors by treating each incident as a multimodal signature and matching it against a knowledge base of past solved incidents. The system, ARCA, combines log embeddings, vectorized performance metrics, and natural-language bug descriptions in a retrieval-augmented generation pipeline. On a synthetic dataset of 800 microservice bug tickets, ARCA triages incidents with 92% accuracy and identifies the correct mitigation plan with 72% accuracy. The aim is to show that cross-modality retrieval plus LLM-based judgment is a viable path to root-cause analysis, even when individual modalities are noisy or incomplete.

What carries the argument

The mechanism that carries ARCA is a multimodal retrieval-augmented knowledge base. Past bug tickets are decomposed into three representations: log content is filtered by a feature-extraction LLM and embedded into 3072-dimensional vectors by an off-the-shelf text embedding model; performance-counter time series from seven container counters are normalized and compressed into 21-dimensional vectors by taking the normalized first-order gradient, mean, and standard deviation of each counter; and the original natural-language bug description, including its mitigation plan, is stored unmodified. During a query, approximate nearest-neighbor search first retrieves a few hundred candidate bugs by cosine similarity of their log embeddings, a second telemetric KNN step narrows the candidates, and an LLM judge using step-by-step prompting selects the best-matching prior bug, whose mitigation plan is then adapted by a generator LLM for the current incident. This makes triage a coarse routing decision over many candidates, diagnosis a focused selection by the judge, and plan synthesis a retrieval-grounded generation step, with a knowledge base that can be updated without retraining any model.

What would settle it

Reserve a held-out set of real incident tickets from a production cloud service (with logs, metrics, and text but without a pre-stated root cause), build the knowledge base from historical resolved tickets, and run ARCA's full pipeline; if the selected prior bugs and mitigation plans do not match SRE judgments at roughly the reported rates, the synthetic-data assumption is the culprit. A targeted variant would take the synthetic tickets and delete the sentence stating the root cause from each generation prompt, then measure how much triage and mitigation accuracy drop.

Watch

Extended reading notes

Core claim

ARCA's central claim is that a retrieval-augmented-generation pipeline operating across three data modalities — natural-language incident descriptions, semi-structured log files, and multivariate performance-counter time series — can perform incident triage and mitigation planning as well as or better than single-modality AI-Ops tools. The system builds a knowledge base of past solved bugs, retrieves candidate prior incidents by approximate nearest-neighbor search on log embeddings, filters them by telemetry similarity, and uses an LLM judge with chain-of-thought prompting to select the closest bug and adapt its mitigation plan. In end-to-end evaluation on 800 synthetic microservice bug tickets, ARCA achieves 92% triage accuracy and 72% accuracy in selecting the correct mitigation plan, and the log-clustering module matches or exceeds state-of-the-art anomaly-detection baselines on four public supercomputer log datasets.

Load-bearing premise

The reported 92% and 72% accuracies depend on the synthetic bug reports, which were generated by an LLM in an experiment where the root cause and mitigation plan were written directly into the generation prompt; the assumption is that these clean, self-consistent reports resemble the fuzzy, incomplete incident reports real users submit to a bug tracker.

Editorial extensions

If this is right

  • Incident response workflows could be reorganized around a single retrieval step that surfaces a family of similar past incidents spanning logs, metrics, and reports, rather than separate alarms for each signal.
  • A knowledge base updatable without retraining would let SRE teams incorporate newly resolved incidents continuously, preserving accuracy after hardware upgrades or log-format changes.
  • The context-window limit of the judge LLM creates a concrete trade-off between triage recall (more retrieved candidates) and system accuracy (judge overwhelmed by too many choices), so deployment would tune the candidate-set size to the model budget.
  • The same retrieval-plus-judge architecture could generalize to other multimodal diagnostic domains where historical cases with known resolutions exist, such as network fault management or hardware failure analysis.

Reading between the lines

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

  • The reported accuracy is likely an upper bound for real deployments, because the synthetic reports were generated with the root cause and mitigation plan already written into the prompt, making retrieval and judgment easier than with the vague, partial reports users actually file.
  • A stronger test would compare ARCA's proposed mitigation plans against plans actually adopted by SREs on a corpus of real resolved tickets, measuring plan adoption rather than exact-match accuracy.
  • The cost analysis shows the judge stage dominates expense, so a practical deployment would probably need to distill the judge into a smaller local model or accept higher latency to stay within budget.
  • The clean clustering of log embeddings by root-cause family suggests that the embedding space itself may carry enough signal for a lightweight classifier independent of the RAG and judge stages, which would be worth validating separately.
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

4 major / 5 minor

Summary. The paper introduces ARCA, a multi-modal retrieval-augmented generation (RAG) system for diagnosing cloud platform incidents. ARCA embeds logs and telemetric time-series into a knowledge base, performs two-stage approximate nearest-neighbor retrieval, and uses GPT-4o as an Evaluation LLM to select the closest prior bug and as a Generator LLM to produce a mitigation plan. The authors create a synthetic dataset of 800 bug tickets from DeathStar microservice applications with injected CPU, memory, network, and mixed faults, using GPT-4o to write reports with root causes and mitigations provided. They report 92% triage accuracy and 72% system accuracy on a 100-ticket held-out set, and they compare the log-clustering component against public supercomputer logs (BGL, Thunderbird, Spirit, Liberty), reporting F1-scores that exceed published baselines on most datasets.

Significance. If the end-to-end results were valid, ARCA would be a useful contribution to AIOps, showing that off-the-shelf embedding models and LLM judges can perform cross-modal incident retrieval. The component-level evaluation on established log datasets (Table 2) is a genuine strength: it uses public data, reports F1/precision/recall, and shows competitive or better numbers than the cited fine-tuned baselines, and the cost analysis (Figure 4) is practical. However, the end-to-end evaluation is not valid evidence for the central claims: the test tickets are exact or near-exact duplicates of training tickets, the bug reports are machine-generated with ground-truth answers embedded in the prompts, and the same model family is used as generator and judge. The paper also provides no end-to-end baseline, so the claim of outperforming state-of-the-art alternatives is unsupported at the system level. The net assessment is that the log-processing component has potential, but the main claims as stated are not established.

major comments (4)
  1. [§4.1 and §4.2] The end-to-end evaluation tests near-duplicate retrieval rather than generalization. The authors state in §4.1 that each experiment is run twice so that the closest bug is 'the run generated from the same experiment configuration'; with 4 fault categories × 100 configs × 2 runs, the 100 test tickets have exact duplicates (same config, same injected error) in the 700-ticket training KB. The accuracy definitions in §4.2 count success when this duplicate appears in the retrieved set and is selected by the Evaluation LLM. This makes the 92% and 72% figures a measure of copy detection, not of diagnosis of new incidents. To support the paper's central claim, the evaluation must use held-out configurations or a test set in which the correct answer is similar-but-not-identical to the query, and ideally real bug reports.
  2. [§4.1 and §3.2.2] The end-to-end evaluation is self-referential. GPT-4o generates the bug reports with root causes and mitigation plans provided in the generation prompt (§4.1); GPT-4o is also used as the Evaluation LLM and Generator LLM (§3.2.2). The judge may therefore be matching stylistic patterns of the generator rather than diagnostic content, and the reported system accuracy may not transfer to human-written reports. The paper provides no validation of the claim that these reports are 'typical Bugzilla incident reports,' nor a comparison with real incident-report distributions.
  3. [Abstract, §4.2, and §4.4] The abstract's claim that 'ARCA outperforms state-of-the-art alternatives' is only supported for the log-clustering component (§4.4, Table 2), not for triage or mitigation planning. No baseline is given for the end-to-end task, so the 92%/72% numbers have no comparison point. Table 2 also compares against numbers reported in other papers with different experimental protocols, and for Liberty no baseline is available; no variance or significance testing is reported.
  4. [§4.2] The evaluation does not include a control condition where the correct bug is absent from the knowledge base. In operation, SREs face incidents that are not exact repeats of past bugs. The current protocol—always having an exact duplicate in the KB—cannot reveal how ARCA behaves when no near-duplicate exists, which is precisely the regime in which retrieval-augmented diagnosis is needed. A baseline such as random retrieval, or retrieval with the duplicate removed, should be reported.
minor comments (5)
  1. [§3.1.3] t-SNE is cited as [8], but reference [8] is Johnson et al.'s FAISS paper; the t-SNE reference is [19] in the reference list.
  2. [Throughout] There are several typos: 'bug tacking tools' should be 'bug tracking tools'; 'lack of a significant lack of' is redundant; 'to to encompass' has a duplicated 'to'; 'privilage' should be 'privilege'; 'decibe' should be 'describe'; 'occuring' should be 'occurring'.
  3. [§2.1] The claims about HPC4 and COM2 cite references [15] and [18], which are the Oliner/Stearley and Schroeder/Gibson papers; these citations do not identify those datasets, and the reader cannot verify the claim.
  4. [§4.1] The description of the fourth error category is vague: 'a fourth category of error that causes both a memory leak and a long-running computation, resulting in two possible crash types.' It is unclear how this category differs from the first three and how the two crash types are labeled.
  5. [§3.2.1] The sentence 'With just a small number of approximate matches we might miss some relevant categories, but with hundreds of approximate machines, we have a high likelihood...' contains a typo: 'approximate machines' should be 'approximate matches.'

Circularity Check

2 steps flagged · score 8.0 of 10

End-to-end evaluation is self-referential: the 'closest bug' label is the same-configuration twin of the query, and mitigation ground truth is GPT-4o text generated from a prompt that supplied the root cause; the 92%/72% numbers measure near-duplicate retrieval and model self-consistency, not generalization.

  1. self definitional [Section 4.1 (Data Set) and Section 4.2 (End-to-end Evaluation)]
    "We run each experiment twice so that we can use the data set we can automatically label an experiment run with its closest bug, which is the run generated from the same experiment configuration, yielding 4*100*2=800 bug incidents. ... For a triage operation to be accurate, ARCA needs to include the closest bug in the output of the triage steps. For the whole system to be accurate, ARCA needs to pick the labeled closest bug as the output of the Evaluation LLM."

    The ground-truth 'closest bug' is defined as the other run of the same experiment configuration. Because the query and its label share the same application, injected fault, and configuration, their log embeddings and 21-dimensional telemetry summaries are near-identical by construction. Triage accuracy is scored by whether this twin appears in the top-K retrieved set, and system accuracy by whether the Evaluation LLM selects it. The 92%/72% numbers therefore measure near-duplicate copy detection (finding the query's own twin), not the ability to match a new incident to a similar-but-distinct historical bug. The central end-to-end result is an artifact of the label definition, not an independent prediction of generalization.

  2. self definitional [Section 4.1 (Data Set) and Section 3.2.2 (Generating Phase)]
    "For each bug, we use gpt-4o to generate a human readable bug report. In the generating prompt, we have provided the root causes like 'the issue is caused by a random delay in every invocation of the call back function X' to ensure that the bug report contains meaningful mitigation plans. ... To obtain recommendations with a natural tone and style, ARCA uses gpt-4o for both the evaluating and generation LLM stages."

    The benchmark's notion of a 'correct mitigation plan' is the plan GPT-4o produced when prompted with the root cause and asked to write a report containing meaningful mitigation plans. The Evaluation LLM and Generator LLM are also GPT-4o. Thus the 72% mitigation-accuracy number measures whether GPT-4o can retrieve and re-emit text that GPT-4o generated from a prompt that already contained the answer. The target is not independently validated against real incident outcomes or human SRE judgments, so the reported accuracy is a self-consistency score of a single model rather than a validated prediction of correct cloud mitigation.

full rationale

The headline end-to-end experiment does not test ARCA against genuinely new incidents. In Section 4.1, the 'closest bug' for each query is defined as the other run of the same experiment configuration; in Section 4.2, triage and system accuracy are defined as retrieving and then selecting that twin. Because the twin was produced by the same fault injection, its logs and telemetry signatures are near-identical to the query's, so the task reduces to near-duplicate detection. This is a direct by-construction reduction of the central accuracy claim, not a mere weakness in external validity. The mitigation target is also self-referential: GPT-4o generated the reports and plans with the root causes supplied in the prompt, and GPT-4o is used as both Evaluation LLM and Generator LLM. The 72% figure therefore reports the model's ability to select its own generated text, not an externally validated correct response. The paper does contain one non-circular evaluation: the log-clustering comparison on BGL, Thunderbird, Spirit, and Liberty uses external benchmarks with off-the-shelf embeddings (Table 2). This supports the similarity-search component, but it does not cover triage or mitigation, and the paper's claim that ARCA 'outperforms state-of-the-art alternatives' is only established for that component. No load-bearing self-citation chain was found. Overall score 8 because the central end-to-end result is forced by the definition of the label and by the self-generated ground truth.

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

The system depends on hand-selected feature encodings, tuned retrieval sizes, a set of domain assumptions about how incidents and bug tickets are structured, and the representativeness of an AI-generated synthetic data set. No new physical or theoretical entities are introduced.

free parameters (5)
  • Seven Docker performance counters = CPU, memory, network I/O, block device I/O, latency, socket errors
    Hand-selected set of counters in Sec. 3.1.4; determines the 21-dimensional telemetry vector and therefore retrieval quality.
  • Telemetric feature encoding = Normalized first-order gradient, average, standard deviation (21-dim)
    Chosen in Sec. 3.1.4 without comparison to alternatives; this encoding is the entire telemetry representation.
  • Triage output size K = 300 (tested from 100 to 400)
    Tuned on the evaluation set in Sec. 4.2; system accuracy peaks near 300 and drops at 400.
  • Telemetric filtering fraction = 20%
    Chosen in Sec. 4.2 to reduce candidate count; no sensitivity analysis is reported.
  • Candidate reduction factor = 1/10
    Chosen in Sec. 3.2.1 to limit OpenAI API cost; this filtering affects end-to-end accuracy.
assumptions (6)
  • domain assumption Recurrent incidents produce similar multimodal signatures across logs, telemetry, and descriptions.
    Core premise of the RAG approach, stated in Sec. 1 and used throughout; if false, retrieval cannot work.
  • domain assumption Bug tracking lifecycle always contains the four post types described (initial report, assignment, data collection, closing post).
    Sec. 3.1.1 assumes this structure to build the knowledge base from bug tickets.
  • domain assumption Cosine similarity in the 3072-dimensional log embedding space and the 21-dimensional telemetry space is a valid similarity measure for incident matching.
    Sec. 3.1.2 uses cosine similarity without validating against other similarity metrics.
  • domain assumption GPT-4o as the Evaluation LLM reliably selects the closest bug description among retrieved candidates.
    Sec. 3.2.2 relies on LLM-as-a-judge with no comparison to human judgments or to simpler matching methods.
  • ad hoc to paper The synthetic DeathStar bug reports with injected root causes are representative of real cloud incidents.
    Sec. 4.1 constructs the entire end-to-end test set on this assumption; real user reports are typically noisier and do not state root causes.
  • standard math FAISS approximate nearest neighbor search preserves enough recall for the two-tier retrieval.
    Sec. 3.2.1 uses FAISS as a standard library; assumed to behave according to its documentation.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Diagnosing and Resolving Cloud Platform Instability with Multi-modal RAG LLMs." pith.science (2026). https://pith.science/paper/YCWC3TZW

@misc{pith2026250521419,
  author       = {Pith},
  title        = {Pith review of: Diagnosing and Resolving Cloud Platform Instability with Multi-modal RAG LLMs},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/YCWC3TZW}},
  note         = {Machine review of arXiv:2505.21419}
}
read the original abstract

Today's cloud-hosted applications and services are complex systems, and a performance or functional instability can have dozens or hundreds of potential root causes. Our hypothesis is that by combining the pattern matching capabilities of modern AI tools with a natural multi-modal RAG LLM interface, problem identification and resolution can be simplified. ARCA is a new multi-modal RAG LLM system that targets this domain. Step-wise evaluations show that ARCA outperforms state-of-the-art alternatives.

Figures

Figures reproduced from arXiv: 2505.21419 by the authors.

Figure 1
Figure 1. ARCA workflow in its building and query phases. our attention to the following steps within the life cycle of a bug ticket: (1) The first post, which includes a textual description of the problem. (2) The ticket assignment post, which reflects the judgment of a human triage specialists and has a fixed format. (3) Data collection posts with attachments: these are often data collected by the SRE team using tools they … view at source ↗
Figure 2
Figure 2. t-SNE (t-distributed stochastic neighbor embedding) [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Accuracy of ARCA-PoC. The x-axis represents the [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Cost analysis of using ARCA-PoC. The x-axis repre [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: Prompt for LLM to process log file [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 8
Figure 8. Figure 8: Prompt for the Generator LLM [PITH_FULL_IMAGE:figures/full_fig_p008_8.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

26 extracted references · 9 canonical work pages

  1. [1]

    Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared Kaplan, Prafulla Dhariwal, and et al

    Tom B. Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared Kaplan, Prafulla Dhariwal, and et al. 2020. Language Models are Few-Shot Learners. arXiv:2005.14165 [cs.CL] https://arxiv.org/abs/2005.14165

    arXiv 2020

  2. [2]

    Qian Cheng, Doyen Sahoo, Amrita Saha, Wenzhuo Yang, Chenghao Liu, Gerald Woo, Manpreet Singh, Silvio Saverese, and Steven C. H. Hoi. 2023. AI for IT Operations (AIOps) on Cloud Platforms: Reviews, Opportunities and Challenges. arXiv:2304.04661 [cs.LG] https://arxiv.org/abs/2304.04661 Diagnosing and Resolving Cloud Platform Instability with Multi-modal RAG...

    arXiv 2023

  3. [3]

    Yu Gan, Yanqi Zhang, Dailun Cheng, Ankitha Shetty, Priyal Rathi, Christina Delimitrou, and et al. 2019. An Open-Source Benchmark Suite for Microservices and Their Hardware-Software Implications for Cloud & Edge Systems. In Pro- ceedings of the Twenty-Fourth International Conference on Architectural Support for Programming Languages and Operating Systems (...

    arXiv 2019

  4. [4]

    Jingkun Gao, Xiaomin Song, Qingsong Wen, Pichao Wang, Liang Sun, and Huan Xu. 2021. RobustTAD: Robust Time Series Anomaly Detection via Decomposition and Convolutional Neural Networks. arXiv:2002.09545 [cs.LG] https://arxiv.org/ abs/2002.09545

    arXiv 2021

  5. [5]

    Yunfan Gao, Yun Xiong, Xinyu Gao, Kangxiang Jia, Jinliu Pan, Yuxi Bi, and et al

    work page

  6. [6]

    Hongcheng Guo, Jian Yang, Jiaheng Liu, Jiaqi Bai, Boyang Wang, Zhoujun Li, Tieqiao Zheng, Bo Zhang, Junran peng, and Qi Tian. 2024. LogFormer: A Pre- train and Tuning Pipeline for Log Anomaly Detection. arXiv:2401.04749 [cs.LG] https://arxiv.org/abs/2401.04749

    work page Pith review arXiv 2024

  7. [7]

    Tao Huang, Pengfei Chen, and Ruipeng Li. 2022. A Semi-Supervised VAE Based Active Anomaly Detection Framework in Multivariate Time Series for Online Systems (WWW ’22). Association for Computing Machinery, New York, NY, USA, 10 pages. https://doi.org/10.1145/3485447.3511984

    arXiv 2022

  8. [8]

    Jeff Johnson, Matthijs Douze, and Hervé Jégou. 2017. Billion-scale similarity search with GPUs. arXiv:1702.08734 [cs.CV] https://arxiv.org/abs/1702.08734

    arXiv 2017

Show all 26 references
  1. [9]

    Vladimir Karpukhin, Barlas Oğuz, Sewon Min, Patrick Lewis, Ledell Wu, Wen tau Yih, and et al. 2020. Dense Passage Retrieval for Open-Domain Question Answering. arXiv:2004.04906 [cs.CL] https://arxiv.org/abs/2004.04906

    2020 arXiv

  2. [10]

    Fabbri, Caiming Xiong, and Chien-Sheng Wu

    Philippe Laban, Alexander R. Fabbri, Caiming Xiong, and Chien-Sheng Wu. 2024. Summary of a Haystack: A Challenge to Long-Context LLMs and RAG Systems. arXiv:2407.01370 [cs.CL] https://arxiv.org/abs/2407.01370

    2024 arXiv

  3. [11]

    Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, and et al. 2021. Retrieval-Augmented Generation for Knowledge- Intensive NLP Tasks. arXiv:2005.11401 [cs.CL] https://arxiv.org/abs/2005.11401

    2021 arXiv

  4. [12]

    Aodong Li, Yunhan Zhao, Chen Qiu, Marius Kloft, Padhraic Smyth, Maja Rudolph, and Stephan Mandt. 2024. Anomaly Detection of Tabular Data Using LLMs. arXiv:2406.16308 [cs.LG] https://arxiv.org/abs/2406.16308

    2024 arXiv

  5. [13]

    Qingwei Lin, Hongyu Zhang, Jian-Guang Lou, Yu Zhang, and Xuewei Chen

  6. [14]

    Lijun Sun Man Li, Ziyue Li and Fugee Tsung. 2024. Robust Self-Supervised Deep Tensor Decomposition for Corrupted Time Series Classification. In Anomaly Detection with Foundation Models . Jeju, South Korea. https://adfmw.github.io/ ijcai24/index.html

    2024

  7. [15]

    Adam Oliner and Jon Stearley. 2007. What Supercomputers Say: A Study of Five System Logs. In 37th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN’07) . 575–584. https://doi.org/10.1109/DSN.2007.103

    2007 doi

  8. [16]

    Parvez, Wasi U

    Md R. Parvez, Wasi U. Ahmad, Saikat Chakraborty, Baishakhi Ray, and Kai- Wei Chang. 2021. Retrieval Augmented Code Generation and Summarization. arXiv:2108.11601 [cs.SE] https://arxiv.org/abs/2108.11601

    2021 arXiv

  9. [17]

    Hansheng Ren, Bixiong Xu, Yujing Wang, Chao Yi, Congrui Huang, Xiaoyu Kou, Tony Xing, Mao Yang, Jie Tong, and Qi Zhang. 2019. Time-Series Anomaly De- tection Service at Microsoft. In Proceedings of the 25th ACM SIGKDD International Conference on Knowledge Discovery & Data Mini...

    2019

  10. [18]

    Bianca Schroeder and Garth A. Gibson. 2007. Disk Failures in the Real World: What Does an MTTF of 1,000,000 Hours Mean to You?. In 5th USENIX Confer- ence on File and Storage Technologies (FAST 07) . USENIX Association, San Jose, CA. https://www.usenix.org/conference/fast-07/d...

    2007

  11. [19]

    Laurens v. d. Maaten and Geoffrey Hinton. 2008. Visualizing Data using t- SNE. Journal of Machine Learning Research 9, 86 (2008), 2579–2605. http: //jmlr.org/papers/v9/vandermaaten08a.html

    2008

  12. [20]

    Mäntylä, Jesse Nyyssölä, Ke Ping, and Liqiang Wang

    Yuqing Wang, Mika V. Mäntylä, Jesse Nyyssölä, Ke Ping, and Liqiang Wang. 2025. Cross-System Software Log-based Anomaly Detection Using Meta-Learning. arXiv:2412.15445 [cs.SE] https://arxiv.org/abs/2412.15445

    2025 arXiv

  13. [21]

    Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Denny Zhou, and et al. 2023. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. arXiv:2201.11903 [cs.CL] https://arxiv.org/abs/2201.11903

    2023 arXiv

  14. [22]

    Lianmin Zheng, Wei-Lin Chiang, Ying Sheng, Siyuan Zhuang, Zhanghao Wu, Ion Stoica, and et al. 2024. Judging LLM-as-a-judge with MT-bench and Chatbot Arena. In Proceedings of the 37th International Conference on Neural Information Processing Systems (New Orleans, LA, USA) (NIPS...

    2024

  15. [23]

    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) . 355–366. https://doi.org/10.1109/ISS...

    2023

  16. [24]

    Yichen Zhu, Weibin Meng, Ying Liu, Shenglin Zhang, Tao Han, Shimin Tao, and Dan Pei. 2021. UniLog: Deploy One Model and Specialize it for All Log Analysis Tasks. arXiv:2112.03159 [cs.NI] https://arxiv.org/abs/2112.03159 EuroMLSys ’25, March 30–April 3, 2025, Rotterdam, Netherl...

    2021 arXiv

  17. [2016]

    In 2016 IEEE/ACM 38th International Conference on Software Engineering Companion (ICSE-C)

    Log Clustering Based Problem Identification for Online Service Systems. In 2016 IEEE/ACM 38th International Conference on Software Engineering Companion (ICSE-C). 102–111

    2016

  18. [2024]

    arXiv:2312.10997 [cs.CL] https://arxiv.org/abs/2312.10997

    Retrieval-Augmented Generation for Large Language Models: A Survey. arXiv:2312.10997 [cs.CL] https://arxiv.org/abs/2312.10997

    arXiv

Pith tools

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