---

name: llm-aiops description: "LLM AIOps research reference: a curated map of LLM-based approaches to IT operations — incident management, root cause analysis (RCA), log parsing and anomaly detection, infrastructure-as-code and performance diagnosis, and AIOps Q&A. Use when triaging or designing LLM-driven incident response, fault localization, or log analysis, or when surveying the field's key systems, techniques, and benchmarks. Trigger phrases: AIOps, LLM for AIOps, incident management, incident diagnosis, root cause analysis, RCA, log parsing, log anomaly detection, logging statement generation, infrastructure-as-code, IaC diagnosis, AIOps benchmark, 智能运维, 根因分析, 故障定位, 日志解析, 日志异常检测, 运维问答."

LLM AIOps Reference

Purpose

A research reference library applying Large Language Models to AIOps, built on the awesome-LLM-AIOps taxonomy. It answers "which systems, techniques, and benchmarks exist for this operations problem, and which should I pick" — it does not run scans, parse logs, or execute anything.

When to Use

• Incidents: triaging, diagnosing, mitigating cloud incidents.
• RCA: root cause analysis of system failures.
• Logs: parsing, anomaly detection, logging statement generation.
• Infrastructure: IaC, performance diagnosis, LLM training platforms.
• AIOps QA: domain-specific question answering for operations.
• Trigger phrases: "LLM for AIOps", "AI for IT operations", "incident management", "root cause analysis", "log parsing", "log anomaly detection", "AIOps benchmark", 「智能运维」「根因分析」「故障定位」「日志解析」「日志异常检测」「运维问答」.

When NOT to Use

• The user wants an agent to actually perform triage, log parsing, or diagnosis on their live systems -> this library only names approaches; hand off to the relevant operational tool rather than pretending to execute.
• The task is generic LLM application design (prompting, RAG, fine-tuning) with no operations context -> this library adds nothing; answer directly.
• The user needs the current state of a specific product or vendor -> this is a research snapshot of papers through 2025; do not present it as a live product comparison.
• The question is about general software/agent engineering -> use the repository's coding skills instead.

Workflow

1. Classify the request into one of four topics: incident management, log analysis, infrastructure management, or technique/benchmark selection.
2. Load exactly one routing target from the Decision Rules table below. Do not preload the whole references/ directory.
3. Answer from the loaded file, naming the concrete systems and their venue labels as given (e.g. D-Bot (VLDB 2024)). Do not paraphrase a system's method beyond what the table states.
4. Check the pitfalls file (references/pitfalls-and-outlook.md) before recommending a design, so the recommendation does not repeat a known mistake.
5. State coverage limits when the answer is not in the library instead of improvising a system or benchmark.

Decision Rules

If the question is about...	Load
Incident triage, diagnosis, reporting, mitigation, postmortem, AIOps Q&A	references/incident-management.md
Log parsing, log anomaly detection, logging statement generation	references/log-analysis.md
Infrastructure-as-code, training-platform diagnosis, IaC benchmarks	references/infrastructure-management.md
Which technique to use, or which benchmark to evaluate against	references/techniques-and-benchmarks.md
Whether a design is a known anti-pattern, or what is deployed in production	references/pitfalls-and-outlook.md

• If the request spans two topics -> load both files, answer per topic, do not merge the taxonomies into one list.
• If the request names a system not in the library -> say it is outside this library's coverage; do not invent a venue or year for it.

Constraints

• Cite only what the library contains. Never invent a system name, venue, or year. If a publication venue is given as Preprint, keep it as Preprint.
• Preserve venue labels and dates verbatim — they are the credibility of the reference.
• Treat this as a research snapshot (papers through 2025), not a product guide. Flag that publication recency is not implementation readiness.
• Do not fabricate benchmark numbers or accuracy figures; the library records no metrics.
• Do not claim the library's systems are production-deployed beyond the one sentence in references/pitfalls-and-outlook.md.

Stop Conditions

• Stop once the classified topic has been answered from its one reference file.
• Do not browse the whole references/ directory, and do not expand into open-ended web research: this library is the scope.
• If two topic files disagree or leave a gap, state both and stop rather than reconciling by assumption.

Verification

• The answer names only systems present in the library, with their venue labels intact.
• Exactly the topic files needed were loaded — not the whole directory.
• Any design recommendation was checked against the pitfalls file.
• Out-of-scope requests were declined explicitly rather than answered speculatively.

Output

• Outcome: a grounded answer naming the relevant systems, techniques, and benchmarks for the user's operations problem.
• Done when: the question is classified, the matching reference file(s) were consulted, and every cited system traces to this library.
• Evidence: the named systems with venue labels, plus an explicit statement of any coverage gap.

References

Load only when needed:

• references/incident-management.md — read when the question concerns incident triage, diagnosis, reporting, mitigation, postmortem, RCA, or AIOps Q&A.
• references/log-analysis.md — read when the question concerns log parsing, log anomaly detection, or logging statement generation.
• references/infrastructure-management.md — read when the question concerns infrastructure-as-code, training-platform diagnosis, or IaC benchmarks.
• references/techniques-and-benchmarks.md — read when choosing a technique or deciding which benchmark to evaluate against.
• references/pitfalls-and-outlook.md — read before recommending a design, or when asked what is actually deployed and where the field is heading.