FixItFlow: Automated Troubleshooting Guide Generation from Cloud Incidents

Drishti Goel; Jaskaran Singh Walia; Srihari Unnikrishnan; Supriyo Ghosh

REVIEW 4 major objections 6 minor 18 references

FixItFlow: Automated Troubleshooting Guide Generation from Cloud Incidents

T0 review · 4 major / 6 minor · reviewed 2026-08-02 · deepseek-v4-flash

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

Pith's one-line read FixItFlow generates troubleshooting guides directly from cloud incident comments, reporting 2.3x faster mitigation when guides are available.

desk verdict A concrete, honestly-described pipeline for generating troubleshooting guides, but the paper's headline results don't hold up: the 2.3x mitigation-time claim is never analyzed, and the survey shows the guides are not yet adoptable. read the letter →

arxiv 2607.13035 v1 pith:6CF5ARQ4 submitted 2026-05-03 cs.CL cs.AIcs.LGcs.SE

Srihari Unnikrishnan , Jaskaran Singh Walia , Drishti Goel , Supriyo Ghosh This is my paper

classification cs.CLcs.AIcs.LGcs.SE

keywords troubleshootingguidesincidentmanagementlargelanguagemodelscloudincidentshallucinationpreventionAIOpsdocumentationgenerationtimetomitigate

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

FixItFlow aims to show that high-quality troubleshooting guides (TSGs) for cloud incidents can be generated automatically from historical incident comment threads, without pre-existing documentation. The system's central bet is that engineers' own written comments contain enough diagnostic and mitigation detail to synthesize structured guides, provided every extracted command is copied character-for-character from the source to prevent hallucination. In an evaluation with 26 engineers, the generated guides received 61.5% positive ratings for clarity, and incidents with associated guides showed roughly 2.3x faster mitigation. The paper argues this makes automated guide generation a viable way to cut documentation burden and speed incident response, while acknowledging that completeness and factual accuracy remain the weakest quality dimensions.

What carries the argument

The key mechanism is the zero-hallucination verification protocol embedded in the LLM prompts. It transforms the model from a probabilistic text generator into a constrained retrieval system: before including any command or query, the exact text must be found in the incident comments; commands are copied character-by-character; and if engineers described an action without showing the command, the guide says so and includes no command. Around this protocol, the pipeline also uses incremental data ingestion (only resolved incidents with at least six comments), a three-stage cleaning pass (format stripping, content filtering, duplicate removal), parallel incident summarization, scenario aggrega

What would settle it

Run FixItFlow on incidents where a full terminal log or screen recording of the engineer's session is available, and compare each generated guide step against the actual executed commands. If a substantial fraction of executed commands never appeared in the comments, the grounding premise fails, and the guides will be incomplete by construction.

Watch

Extended reading notes

Core claim

The central claim is that a pipeline of incremental ingestion, three-pass cleaning, LLM-based summarization, and strict validation can turn raw incident comment threads into structured, trustworthy troubleshooting guides. The load-bearing innovation is the anti-hallucination protocol: every command, query, or procedural step in a generated guide must be an exact character-level match to text found in engineer comments, with no synthesis, paraphrase, or completion of partial commands. Guides are organized into a fixed three-section structure (Symptom, Diagnosis, Mitigation) and generated under a prompt that requires copy-paste verbatim commands with contextual labels. The paper reports that 2

Load-bearing premise

The load-bearing premise is that incident comment threads are a complete and accurate record of every diagnostic and mitigation action engineers took; if comments omit steps or contain sloppy/unfinished commands, the generated guides inherit those gaps.

Editorial extensions

If this is right

If FixItFlow's claims hold, engineering teams can automatically generate troubleshooting guides from their existing incident histories, removing the manual authoring bottleneck that leaves coverage incomplete and outdated.
Because every command is verified against source comments, teams can adopt generated guides with confidence that no fabricated instructions appear, a key safety property for high-stakes incident response.
The reported 2.3x reduction in mitigation time for incidents with guides implies that broad availability of such guides could produce large operational efficiency gains at cloud scale.
The system's low completeness and factual-accuracy scores indicate that even verified guides may need manual review or supplementary sources before full adoption.

Reading between the lines

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

The 2.3x mitigation-time figure is correlational: it compares incidents with and without associated guides, so unmeasured factors (e.g., incident complexity) may confound the relationship; a randomized trial or matching study would be needed to establish causation.
The character-level anti-hallucination rule likely trades completeness for safety: since it forbids inference, any step engineers performed but didn't type in comments will be missing from the guide, which may explain the low completeness score.
The same grounding protocol could be applied to other high-stakes documentation tasks (runbooks, on-call playbooks, compliance procedures) where hallucinated procedures are unacceptable.
A testable extension is to compare FixItFlow guides against human-authored TSGs for the same incidents on time-to-mitigate and error rates, using a crossover design to control for engineer familiarity.

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.

Desk Editor's Note

read the letter

The one thing you should know: this is a reasonable engineering description strung together with claims that outrun its evidence. The pipeline itself — incremental ingestion, three-stage cleaning, few-shot classification, LLM summarization, schema-constrained prompting, and a character-exact grounding rule — is concrete and clearly presented. The grounding rule (every command must appear verbatim in incident comments) is a sensible design choice, and the authors deserve credit for showing their validation checklist and prompt templates. The related work is cited appropriately, and the survey table is honestly tabulated; you can see exactly what engineers said.

The soft spots are substantial and load-bearing. The abstract and conclusion say generated guides demonstrated a 2.3x reduction in mitigation time, but nothing in the paper measures mitigation time for incidents that used FixItFlow-generated guides. The conclusion even says "TSG-linked cases" were faster, which sounds like the pre-existing correlation from Section 3, not a causal effect of the generated guides. That is a serious mismatch between claim and evidence. The paper also says FixItFlow "consistently produces higher-quality TSGs compared to basic GPT-4o" while Table 1 contains no GPT-4o row. And the "zero-hallucination" claim sits awkwardly next to the survey's 42.3% top-2 factual accuracy rating and 23.1% completeness; the paper never measures the validator's precision or recall.

The survey itself is the weak core: clarity at 61.5% is the best item, but factual accuracy and completeness are low, overall satisfaction is 19.2% top-2, adoption is 0/13, and NPS is -100. The interview excerpts confirm this — one engineer explicitly said mitigation steps were missing. So the paper is honest in reporting weak outcomes but then overstates them in the abstract.

The stress-test note is right. The 2.3x figure is the strongest advertised result and it is unsupported. The reader's concern about input quality (comments as a complete record) is also real, though secondary.

Who is this for? AIOps practitioners who want a detailed template for building similar systems, and researchers studying evaluation gaps in LLM-based incident management. As-is, it should not be accepted as a claim paper. I'd send it to peer review anyway because the engineering is real and the failure modes are instructive — but the expected revision is major: either provide the TTM analysis or remove the causal framing, add the GPT-4o baseline, and report validator performance.

If a colleague asked whether to engage: read it for the pipeline design, not for the numbers.

Referee Report

4 major / 6 minor

Summary. FixItFlow is a proposed pipeline that automatically generates troubleshooting guides (TSGs) from historical cloud incident comment threads using LLMs. The system incrementally ingests incidents, cleans comments, extracts engineer actions with character-level grounding, and synthesizes three-section guides (Symptom, Diagnosis, Mitigation) under prompt-based anti-hallucination constraints. The paper claims contributions in pipeline design, preprocessing, schema/validation to reduce hallucination, and an empirical evaluation with 26 engineers reporting 61.5% top-2 clarity and a 2.3x reduction in mitigation time for incidents with associated guides.

Significance. If the central claims held, FixItFlow would be a meaningful step toward reducing the manual burden of TSG creation and improving incident response consistency. The pipeline design is systematic, and the character-level grounding protocol is a defensible safety mechanism for command extraction. However, the evidence presented is insufficient to support the advertised impact: the only directly measured outcome is perceived clarity (61.5% top-2), while adoption is 0/13, NPS is -100, and overall satisfaction is 19.2% top-2. The headline 2.3x mitigation-time reduction is not supported by any experiment in the paper. The manuscript therefore currently reads as a well-structured system description with a weak, self-selected survey evaluation rather than a validated contribution.

major comments (4)

[Abstract and §3, §6] The abstract states that generated guides 'demonstrated a 2.3x reduction in mitigation time for incidents with associated guides,' but no analysis in §6 or elsewhere compares incidents with vs. without FixItFlow-generated guides. §3 presents only a qualitative motivation about pre-existing TSG linkage and TTM, with no statistics and no mention of the 2.3x figure. The conclusion repeats the '2.3 times faster mitigation' claim, yet it is not derived from any reported data. This is a load-bearing mismatch between the headline and the evidence; the claim must either be backed by a defined TTM analysis or removed and clearly relabeled as a prior correlation.
[§6, Tables 1–2] The survey results do not support the paper's characterization of 'usable automated troubleshooting guides' or the claim of superiority over 'basic GPT-4o.' Table 1 shows factual accuracy top-2 = 42.3%, completeness top-2 = 23.1%, overall satisfaction top-2 = 19.2%, adoption = 0/13, and NPS = -100. No baseline comparison to GPT-4o appears in any table; the sentence in §6 asserting 'consistently produces higher-quality TSGs compared to using basic GPT-4o' has no accompanying data. These figures instead indicate substantial gaps in exactly the dimensions (factual correctness, completeness, adoption) that the paper claims to solve.
[§4.3.2, §5.1.2, §5.3] The paper repeatedly claims that the anti-hallucination protocol 'eliminat[es] fabricated instructions' and achieves 'zero hallucination.' This is a design constraint (commands must match source text character-for-character) and is not empirically verified. Indeed, Table 1 shows factual accuracy top-2 at only 42.3%, and the validation is implemented as a prompt-based checklist (§5.3), not an automated post-generation verifier. The manuscript should distinguish between a mechanism intended to reduce hallucination and evidence that hallucination is actually absent. As written, the 'zero tolerance' language overstates what the evaluation demonstrates.
[§4.1.1, §4.2.1] The grounding protocol depends on the completeness of incident comment threads, yet the pipeline actively filters them: incidents must have at least six comments (§4.1.1) and comments shorter than 25 characters are deleted (§4.2.1, Step 2). Since §4.3.2 requires exact character-level extraction, any omitted or filtered step cannot appear in the generated guide. The survey's low completeness score (23.1% top-2) is consistent with this structural risk. The paper does not acknowledge or analyze how these thresholds affect the final guides' completeness, despite completeness being one of the weakest evaluated items.

minor comments (6)

[§3.2 header] Section heading reads 'MOTIV ATION' in the manuscript; should be 'MOTIVATION.'
[Table 1] The adoption item has N=13 while all other rows have N=26. Please explain why only 13 respondents answered this item and how missingness was handled.
[§4.4] The '100,000 token limit (roughly equivalent to 75,000 words)' is a confusing conversion; typical token-to-word ratios are often cited per language, not globally. Clarify the exact limit used by the LLM backend.
[§6] The sentence 'from which 26 completed the entire form' implies more were invited; report the total number of invited engineers and the response rate, since a low response rate would further bias the small sample.
[References] Reference formatting is inconsistent (e.g., some entries use 'ACM' as publisher, others 'IEEE'; arXiv identifiers are inconsistently punctuated). Also, some citations appear in brackets without page numbers; please adhere to the venue's style.
[General] The manuscript does not include a data/code availability statement, nor does it specify the exact LLM model and version (e.g., GPT-4o) used for the evaluation. This is important for reproducibility.

Circularity Check

1 steps flagged · score 4.0 of 10

Headline 2.3x mitigation-time claim is re-attributed from the paper's own unshown TSG-TTM motivation analysis rather than derived from any FixItFlow experiment.

fitted input called prediction [Abstract; §3 Motivation; §6 Evaluation (Table 1); §7 Conclusion]
"In our evaluation with 26 engineers, generated guides achieved 61.5% positive ratings for clarity and demonstrated a 2.3x reduction in mitigation time for incidents with associated guides. ... In our evaluation on production incidents, TSG-linked cases showed approximately 2.3 times faster mitigation. ... our analysis of the real-world production systems at Microsoft can offer statistical support to this intuition"

The only reported FixItFlow evaluation is the 26-engineer survey in §6, which measures perceived clarity, coherence, accuracy, completeness, and adoption; it contains no mitigation-time analysis. The 2.3x figure appears in the abstract and conclusion as a demonstrated outcome, but the only TTM evidence mentioned in the paper is §3's motivation study of 'TSG-linked cases,' whose statistical results are never reported. The abstract re-labels that input correlation ('incidents with associated guides') as if it were a measured effect of FixItFlow-generated guides. Thus the paper's strongest quantitative claim is an imported correlation renamed as an evaluation result, not a prediction derived from the system's outputs.

full rationale

FixItFlow's generation pipeline itself is not circular in the usual equation-reduces-to-input sense: there are no fitted model parameters, and the guide-synthesis procedure extracts and structures content from incident comments. The anti-hallucination protocol is definitional rather than circular as a derivation step: requiring character-level matching guarantees that commands originate from the source comments, but the paper does not claim this protocol alone proves factual accuracy; indeed, the survey shows factual accuracy at only 42.3% top-2. The central circularity concern is the 2.3x mitigation-time claim. The abstract asserts that generated guides 'demonstrated a 2.3x reduction in mitigation time for incidents with associated guides,' and the conclusion repeats this as 'TSG-linked cases showed approximately 2.3 times faster mitigation,' yet §6 contains no TTM experiment or observational analysis. The only source for such a number is the §3 motivation discussion of pre-existing TSG linkage and TTM, whose results are promised but never reported in this paper. That makes the headline efficacy figure a re-attributed input rather than a measured output of FixItFlow. Because the survey does provide independent evidence for clarity and some other quality dimensions, the paper retains partial independent content, so the score is 4 rather than higher.

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

The central claims rest on five input-quality and evaluation premises that the paper never measures: completeness of incident comments, reliability of the character-level validator, stability of LLM prompt-following, a causal reading of the TTM correlation, and representativeness of the 26 survey respondents. The design thresholds (six-comment eligibility, 100k-token cap, 25-character comment filter) are hand-chosen and interact directly with the completeness problem the survey exposes. No invented entities (new particles, forces, mediators, dimensions) are introduced; the three-tier TSG schema is an output document format, not an entity.

free parameters (4)

Incident eligibility threshold (minimum engineer comments) = >=6 comments
Hand-chosen filter (§4.1.1) deciding which incidents carry enough 'diagnostic signal'; directly controls what the LLM sees and hence guide completeness.
LLM context window limit = 100,000 tokens
Operational cap (§4.4) with a 'short comments first' prioritization heuristic; determines which comments survive and biases guides toward shorter text.
Comment length filter = >=25 characters
Noise filter (§4.2.1, Step 2); drops short comments that may contain commands, interacting with the completeness problem.
Cleaning volume reduction = 35-40%
Reported effect of the cleaning process (§4.2.1); asserted without measurement detail and used as an efficiency claim.

assumptions (5)

domain assumption Incident comment threads are a complete and accurate record of the engineers' actual troubleshooting actions
The entire grounding strategy (§4.3.2) copies commands character-by-character from comments; if comments omit steps or contain sloppy/incorrect commands, the guides inherit the gaps. The low completeness score (23.1% top-2) is consistent with this axiom failing.
domain assumption The character-level validation checker is itself correct (no false accepts/rejects)
The anti-hallucination protocol (§5.1.2) assumes the string-match verification is reliable, but no precision/recall for the validator is reported.
domain assumption The LLM (class: GPT-4o) follows the prompt constraints reliably enough that extraction is governed by the stated rules rather than by model drift
All of §5 rests on prompt-following; no consistency or error analysis across repeated runs is given.
domain assumption Correlation between TSG availability and faster TTM is interpreted causally
§3 frames faster mitigation as an effect of TSGs; confounds such as team maturity, incident severity mix, and monitoring quality are not addressed, and no regression or matching is reported.
domain assumption The 26 survey respondents are representative of on-call engineers
§6 recruitment ('sent a form to multiple on-call engineers, from which 26 completed') has no sampling frame; an NPS of -100 suggests a non-representative or genuinely dissatisfied cohort.

how reviews work

0 comments

Cite this review

Pith. "Pith review of FixItFlow: Automated Troubleshooting Guide Generation from Cloud Incidents." pith.science (2026). https://pith.science/paper/6CF5ARQ4

@misc{pith2026260713035,
  author       = {Pith},
  title        = {Pith review of: FixItFlow: Automated Troubleshooting Guide Generation from Cloud Incidents},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/6CF5ARQ4}},
  note         = {Machine review of arXiv:2607.13035}
}

read the original abstract

Cloud services experience frequent incidents that require rapid diagnosis and resolution. Troubleshooting guides help engineers respond consistently, but creating them manually is labor-intensive, resulting in incomplete coverage and outdated documentation. We present FixItFlow, an automated system that generates troubleshooting guides from historical incident data using large language models. The system extracts diagnostic patterns from engineer actions, synthesizes structured guides with verified commands, and enforces strict validation to prevent fabricated content. In our evaluation with 26 engineers, generated guides achieved 61.5\% positive ratings for clarity and demonstrated a 2.3x reduction in mitigation time for incidents with associated guides. These results indicate that automated guide generation can improve incident response while reducing documentation burden on engineering teams.

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

18 extracted references · 2 canonical work pages

[2]

Gereon Bondel, Ali Kaan Cerit, and Florian Matthes. 2022. Challenges of API Documentation from a Provider Perspective and Best Practices for Examples in Public Web API Documentation. InProceedings of the 24th International Conference on Enterprise Information Systems, ICEIS 2022, Online Streaming, April 25-27, 2022. SCITEPRESS, 359–367. doi:10.5220/001108...

work page doi:10.5220/0011089700003179 2022
[3]

Wenhu Chen, Xueguang Ma, Xinyi Wang, and William W. Cohen. 2023. Program of Thoughts Prompting: Disentangling Computation from Reasoning for Numerical Reasoning Tasks. arXiv:2211.12588 [cs.CL] doi:10.48550/arXiv.2211.12588

arXiv doi:10.48550/arxiv.2211.12588 2023
[4]

Yinfang Chen, Huaibing Xie, Minghua Ma, Yu Kang, Xin Gao, Liu Shi, Yunjie Cao, Xuedong Gao, Hao Fan, Ming Wen, Jun Zeng, Supriyo Ghosh, Xuchao Zhang, Chaoyun Zhang, Qingwei Lin, Saravan Ra- jmohan, Dongmei Zhang, and Tianyin Xu. 2024. Automatic Root Cause Analysis via Large Language Models for Cloud Incidents. In Proceedings of the Nineteenth European Con...

arXiv 2024
[5]

Long Cheng, Yanjun Wu, Peng Chen, Kaixin Sui, Tao Xu, and Dan Pei
[7]

Yunfan Gao, Yun Xiong, Xinyu Gao, Kangxiang Jia, Jinliu Pan, Yuxi Bi, Yi Dai, Jiawei Sun, Meng Wang, and Haofen Wang. 2023. Retrieval-Augmented Generation for Large Language Models: A Sur- vey. arXiv:2312.10997 [cs.CL] doi:10.48550/arXiv.2312.10997

arXiv doi:10.48550/arxiv.2312.10997 2023
[8]

Supriyo Ghosh, Manish Shetty, Chetan Bansal, and Suman Nath. 2022. How to Fight Production Incidents? An Empirical Study on a Large- scale Cloud Service. InProceedings of the ACM Symposium on Cloud Computing, SoCC 2022, San Francisco, CA, USA, November 7-11, 2022. ACM. doi:10.1145/3542929.3563482

arXiv 2022
[9]

Shilin He, Xu Zhang, Pinjia He, Yong Xu, Liqun Li, Yu Kang, Minghua Ma, Yining Wei, Yingnong Dang, Saravan Rajmohan, and Qingwei Lin
[10]

Hong, Kushal Wadhwani, Disha Arora, Rajiv Agarwal, Rahul Bhagwan, Chaoyun Zhang, Peng Huang, Pu Zhao, Qingwei Lin, Saravan Rajmohan, and Dongmei Zhang

Binsheng Jiang, Zixiao Zhu, Minghua Ma, Zhixing Ren, Zhe Wang, Hao Jiang, Chen Zhi, Yuchi Ma, Lingling Zheng, Yingnong Dang, Catherine B. Hong, Kushal Wadhwani, Disha Arora, Rajiv Agarwal, Rahul Bhagwan, Chaoyun Zhang, Peng Huang, Pu Zhao, Qingwei Lin, Saravan Rajmohan, and Dongmei Zhang. 2024. Xpert: Empower- ing Incident Management with Query Recommenda...

arXiv 2024

Show all 18 references

[11]

Jiajun Jiang, Weihai Lu, Junjie Chen, Qingwei Lin, Pu Zhao, Yu Kang, Hongyu Zhang, Yingfei Xiong, Feng Gao, Zhangwei Xu, Yingnong Dang, and Dongmei Zhang. 2020. How to Mitigate the Incident? An Effective Troubleshooting Guide Recommendation Technique for Online Service Systems...

2020
[12]

Pengxiang Jin, Shenglin Zhang, Minghua Ma, Haozhe Li, Yu Kang, Liqun Li, Yudong Liu, Bo Qiao, Chaoyun Zhang, Pu Zhao, Shilin He, Federica Sarro, Yingnong Dang, Saravan Rajmohan, Qingwei Lin, and Dongmei Zhang. 2023. Assess and Summarize: Improve Outage Under- standing with Lar...

2023
[13]

Zihao Liu, Yuxiao Ye, Yudong Liu, Zhixing Ren, Yichen Li, Liang- fan Zheng, Bo Qiao, Chaoyun Zhang, Ze Li, Pu Zhao, Shilin He, Yu Kang, Liqun Li, Xu Zhang, Qingwei Lin, Yingnong Dang, Saravanaku- mar Rajmohan, and Dongmei Zhang. 2023. iPACK: Incident-aware Duplicate Ticket Agg...

2023
[14]

Joy Saha and Steven C. H. Hoi. 2022. Mining Root Cause Knowledge for AIOps. arXiv:2204.11598 [cs.SE] doi:10.48550/arXiv.2204.11598

2022 doi arXiv
[15]

Manish Shetty, Chetan Bansal, Sai Pramod Upadhyayula, Arjun Rad- hakrishna, and Anurag Gupta. 2022. AutoTSG: Learning and Synthesis for Incident Troubleshooting. InProceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foun- dations of ...

2022
[16]

Chi, Quoc V

Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed H. Chi, Quoc V. Le, and Denny Zhou. 2022. Chain- of-Thought Prompting Elicits Reasoning in Large Language Models. arXiv:2201.11903 [cs.CL] doi:10.48550/arXiv.2201.11903

2022 doi arXiv
[17]

Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. 2022. ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629 [cs.CL] doi:10.48550/a rXiv.2210.03629

2022 doi arXiv
[18]

Xuchao Zhang, Haoyuan Li, Sourav Saha, Theo Culhane, Paarth Choksi, Chetan Bansal, and Saravan Rajmohan. 2024. Automated Root Causing of Cloud Incidents using In-Context Learning with GPT-

2024
[21]

ACM, 570–574

InCompanion Proceedings of the 32nd ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ESEC/FSE Companion 2024, Porto de Galinhas, Brazil, July 15-19, 2024. ACM, 570–574. doi:10.1145/3663529.3663846 7

2024
[2023]

arXiv:2304.04661 [cs.SE] doi:10.48550/arXiv.2304.04 661

AI for IT Operations on Cloud Platforms: Reviews, Opportunities and Challenges. arXiv:2304.04661 [cs.SE] doi:10.48550/arXiv.2304.04 661

doi arXiv

Pith tools

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

[1] [2]

Gereon Bondel, Ali Kaan Cerit, and Florian Matthes. 2022. Challenges of API Documentation from a Provider Perspective and Best Practices for Examples in Public Web API Documentation. InProceedings of the 24th International Conference on Enterprise Information Systems, ICEIS 2022, Online Streaming, April 25-27, 2022. SCITEPRESS, 359–367. doi:10.5220/001108...

work page doi:10.5220/0011089700003179 2022

[2] [3]

Wenhu Chen, Xueguang Ma, Xinyi Wang, and William W. Cohen. 2023. Program of Thoughts Prompting: Disentangling Computation from Reasoning for Numerical Reasoning Tasks. arXiv:2211.12588 [cs.CL] doi:10.48550/arXiv.2211.12588

arXiv doi:10.48550/arxiv.2211.12588 2023

[3] [4]

Yinfang Chen, Huaibing Xie, Minghua Ma, Yu Kang, Xin Gao, Liu Shi, Yunjie Cao, Xuedong Gao, Hao Fan, Ming Wen, Jun Zeng, Supriyo Ghosh, Xuchao Zhang, Chaoyun Zhang, Qingwei Lin, Saravan Ra- jmohan, Dongmei Zhang, and Tianyin Xu. 2024. Automatic Root Cause Analysis via Large Language Models for Cloud Incidents. In Proceedings of the Nineteenth European Con...

arXiv 2024

[4] [5]

Long Cheng, Yanjun Wu, Peng Chen, Kaixin Sui, Tao Xu, and Dan Pei

[5] [7]

Yunfan Gao, Yun Xiong, Xinyu Gao, Kangxiang Jia, Jinliu Pan, Yuxi Bi, Yi Dai, Jiawei Sun, Meng Wang, and Haofen Wang. 2023. Retrieval-Augmented Generation for Large Language Models: A Sur- vey. arXiv:2312.10997 [cs.CL] doi:10.48550/arXiv.2312.10997

arXiv doi:10.48550/arxiv.2312.10997 2023

[6] [8]

Supriyo Ghosh, Manish Shetty, Chetan Bansal, and Suman Nath. 2022. How to Fight Production Incidents? An Empirical Study on a Large- scale Cloud Service. InProceedings of the ACM Symposium on Cloud Computing, SoCC 2022, San Francisco, CA, USA, November 7-11, 2022. ACM. doi:10.1145/3542929.3563482

arXiv 2022

[7] [9]

Shilin He, Xu Zhang, Pinjia He, Yong Xu, Liqun Li, Yu Kang, Minghua Ma, Yining Wei, Yingnong Dang, Saravan Rajmohan, and Qingwei Lin

[8] [10]

Hong, Kushal Wadhwani, Disha Arora, Rajiv Agarwal, Rahul Bhagwan, Chaoyun Zhang, Peng Huang, Pu Zhao, Qingwei Lin, Saravan Rajmohan, and Dongmei Zhang

Binsheng Jiang, Zixiao Zhu, Minghua Ma, Zhixing Ren, Zhe Wang, Hao Jiang, Chen Zhi, Yuchi Ma, Lingling Zheng, Yingnong Dang, Catherine B. Hong, Kushal Wadhwani, Disha Arora, Rajiv Agarwal, Rahul Bhagwan, Chaoyun Zhang, Peng Huang, Pu Zhao, Qingwei Lin, Saravan Rajmohan, and Dongmei Zhang. 2024. Xpert: Empower- ing Incident Management with Query Recommenda...

arXiv 2024