Dreiecke der Top-Internetunternehmen treffen aufeinander. Ist die beobachtbare Grenze in der Ära der Künstlichen Intelligenz sichtbar geworden?

Die Inferenzfähigkeit von Large Language Models (LLMs) und die Datenverstehensfähigkeit von generativen KI-Systemen bieten neue Ideen für die Weiterentwicklung der Observability-Technologie. Andererseits stärkt die Observability-Technologie auch den KI-Bereich. Wie unterstützen sich KI und Observability-Technologie gegenseitig? Welcher Handlungspfad führt von der Experimentierphase bis zur Produktion und von der bloßen Aussage bis zur Umsetzung bei AIOps?

Kürzlich hat die Live-Show Geek Meeting von InfoQ in Zusammenarbeit mit AICon speziell Zhang Cheng, Leiter der Observability-Technologiearchitektur und hochspezialisierter Technologieexperte von Alibaba Cloud als Moderator eingeladen. Gemeinsam mit Dr. Li Ye, Algorithmusexperte von Alibaba Cloud, Dr. Dong Shandong, Leiter des Algorithmus-Teams für die Observationsplattform von ByteDance's Dev-Infra und Wang Yapu, Leiter des Observability-Teams von Xiaohongshu werden sie kurz vor der bevorstehenden QCon Global Software Development Conference 2025 in Shanghai die neuen Grenzen der Observability in der KI-Zeit diskutieren.

Einige Highlights sind wie folgt:

• Die traditionelle Observability konzentriert sich hauptsächlich auf das "Sehen", während das zukünftige neue Betriebsmanagementparadigma möglicherweise einen vollständigen Zyklus von "Entdeckung - Analyse - Lösung - Nachbereitung" realisieren kann. In diesem Prozess wandelt sich das Observability-System von einer bloßen "Auge" zu einem System, das sowohl "Gehirn" als auch "Hände" hat.
• Wir können erst dann ein Vertrauensgefühl gegenüber KI aufbauen, wenn wir Bewertungsstandards haben, die der realen Situation nahekommen, und die Leistung des Modells anhand einer großen Anzahl realer Fälle validieren. Dabei muss sichergestellt sein, dass das Modell ehrlich sagt "ich weiß nicht", wenn es keine Antwort hat, und keine Unsinnigkeiten erfindet oder Halluzinationen hat.
• Das Gesetz von "Schrott rein, Schrott raus" gilt in der KI-Zeit nicht nur weiterhin, sondern wird aufgrund der hohen Abhängigkeit von LLMs von Datenmenge und -qualität sogar noch deutlicher.
• Es ist realistisch, innerhalb von drei bis fünf Jahren ein "halbautonomes" Betriebsmanagement zu erreichen. In einigen Szenarien kann sogar eine geschlossene Schleife der Automatisierung realisiert werden. Doch es ist noch ein langer Weg, bis ein vollkommen autonomes Betriebsmanagement, das sogenannte "Kaffee-Betriebsmanagement", erreicht wird.

Der folgende Text basiert auf der Live-Transkription und wurde von InfoQ gekürzt.

Die vollständige Live-Aufzeichnung kann hier eingesehen werden: https://www.infoq.cn/video/YOTeVHta0A3Xqq2l4Bbp

Zhang Cheng: Welche grundlegenden und bisher unbekannten Veränderungen bringt KI für die Observability?

Li Ye: Erstens "KI für Observability". In der Vergangenheit mussten wir manuell SQL schreiben, um Daten zu extrahieren und zu analysieren. Jetzt kann ein Large Language Model (LLM) automatisch SQL generieren, Dashboards konfigurieren und Zeitaufträge planen, wenn ihm ein klarer Kontext und das Datenformat zur Verfügung gestellt werden. Unsere internen Tests zeigen, dass das LLM bei ausreichendem Kontext in solchen Aufgaben eine Genauigkeit von 80 % - 90 % erreichen kann, was sogar besser ist als bei Ingenieuren, die mit SQL nicht vertraut sind. Dies bedeutet, dass die Art der Datenextraktion grundlegend verändert wurde.

Bei komplexeren explorativen und relationalen Analysen kann KI ebenfalls helfen. Beispielsweise kann ein LLM die Analyse eines komplexen System-Screenshots manchmal besser durchführen als ein junger Ingenieur. Obwohl es derzeit noch nicht in der Lage ist, Experten bei der Root-Cause-Analyse zu ersetzen, kann es die Arbeitsleistung aller Ingenieure deutlich verbessern. Es geht von "für Menschen sichtbar" zu "für KI verständlich". In Zukunft wird es nicht nur um ansprechende Visualisierungen gehen, sondern darum, wie Daten strukturiert organisiert werden können, damit sie effizient von LLMs verstanden und genutzt werden können.

Zweitens "Observability für KI". Die Einführung von KI-Systemen hat neue Observability-Anforderungen geschaffen. Jeder Aufruf eines LLMs verursacht Kosten, daher werden alle erzeugten Trace-Daten gespeichert, was die Speicheranforderungen erheblich erhöht. Gleichzeitig sind die Analyse und Diagnose von KI-Systemen komplexer. Wenn ein LLM in einem Workflow oder Agent einen Fehler aufweist, müssen wir in der Lage sein, die Ursache zu diagnostizieren und die Leistung zu bewerten. Beispielsweise hat es in der RAG-Phase die richtigen Dokumente abgerufen? In welchem Stadium sind Halluzinationen entstanden? Dies stellt höhere Anforderungen an die neue Generation von Observability-Systemen. Ein weiteres Beispiel ist die effiziente Observability und die Selbstheilung von Fehlern in großen GPU-Clustern, was ebenfalls eine neue Herausforderung darstellt.

Dong Shandong: LLMs bieten für den Observability-Bereich ein allgemeines "Gehirn-Grundgerüst", das die Implementierung von traditionellem AIOps erheblich verändert.

In der Vergangenheit mussten wir AIOps-Algorithmen von Grund auf entwickeln: Wir mussten die Ziele des Szenarios festlegen, Daten sammeln und bereinigen, ein Modell trainieren und optimieren. Die Einführung von LLMs bietet uns jedoch eine natürliche Basisleistung von etwa "60 - 70 Punkten", sodass wir schneller und besser in konkreten Observationsszenarien funktionierende Prototypen erstellen können. Wie viele Experten sagen, ist ein LLM wie ein Student mit allgemeinen Fähigkeiten, der in allen Branchen eingesetzt werden kann. Die anschließende Vertiefung und Optimierung in einem bestimmten Bereich muss jedoch von der Branche selbst erfolgen.

LLMs zeichnen sich durch eine hervorragende Fähigkeit zur multimodalen Datenverarbeitung und -fusion aus, und ihre Effektivitätssteigerung und Feedback-Mechanismen sind effizienter. Ein Schlüsselpunkt ist die Anwendung des multimodalen Kontexts: Unsere Aufgabe besteht darin, dem LLM einen umfassenderen und höherwertigen Kontext bereitzustellen. Der schwierigste Teil, die Fusion und das Verständnis von Daten aus verschiedenen Quellen, wird vom LLM übernommen. Bei der Anomalieerkennung beispielsweise beschränken sich traditionelle Methoden oft auf einzelne Indikatoren, während ein LLM Indikatoren, Logs, Traces und andere Daten kombinieren kann, um eine umfassendere Anomaliebeurteilung vorzunehmen. Ein besserer Kontext führt zu besseren Detektionsergebnissen.

Darüber hinaus erfordert die Einbeziehung von manuellen Feedback in traditionellen Methoden normalerweise eine Neustrukturierung des Modells. Ein LLM kann jedoch dank seiner starken Textverstehensfähigkeit schnell und einfach manuelle Feedback in die nächste Detektionsaufgabe einbeziehen.

Im Gegensatz zu traditionellem AIOps, das oft auf einzelne Szenarien optimiert ist, ermöglicht die Einführung von LLMs die Optimierung des gesamten Warnzyklus - von der Entdeckung von Problemen, der Analyse, der Bearbeitung, der Nachbereitung, der Prävention bis hin zur Selbstheilung des Systems. Wir können auf der Grundlage der vorhandenen Observationsdatenplattform und verschiedener kleiner Modelle durch eine Agent-Architektur den gesamten Prozess effektiv verbinden: Das LLM und das Fachwissen bilden zusammen das Entscheidungs-"Gehirn", während die Observationsdaten und die kleinen Modelle als "Werkzeug-Hände" fungieren. Dies ermöglicht es dem Agent, Warnungen nacheinander zu bearbeiten und mit Menschen zusammenzuarbeiten. In Zukunft könnte es sogar wie ein digitales Lebewesen die Rolle des SRE übernehmen.

Wang Yapu: Wenn während des KI-Trainingsprozesses Probleme auftreten, zeigt sich dies oft in einem Gesamtstau, was die Systemstabilität und -komplexität erheblich erhöht. In der Vergangenheit basierte die Observability hauptsächlich auf Regeln und Schwellenwerten für Warnungen und zielte auf bekannte Probleme ab. Mit der Einführung von KI kann das System jedoch eine gewisse semantische Verstehens- und Inferenzfähigkeit entwickeln und unbekannte Probleme aufklärbar und verifizierbar analysieren. In der Vergangenheit haben wir möglicherweise Stunden benötigt, um Leistungseinbußen manuell zu untersuchen. Mit KI können wir jedoch automatisch die Beziehungen zwischen Indikatoren, Links und Änderungen analysieren und von einer passiven Reaktion zu einer aktiven Observability übergehen, um sogar Inferenz- und Erkenntnisfähigkeiten zu entwickeln.

In der Vergangenheit mussten Betriebs- oder Entwicklungsmitarbeiter komplexe Abfragesprachen beherrschen und die Konzepte der Überwachungsplattform verstehen. Jetzt macht KI die Observability zu einer dialogförmigen Tätigkeit. Ingenieure können einfach eine natürliche Spracheingabe wie "Suche mir die Protokollerfolgsrate" tätigen, und das LLM wird die Analyse durchführen. In der Vergangenheit waren Observability-Plattformen oft unterstützende Systeme, die es schwierig machten, die individuellen Anforderungen verschiedener Geschäftsbereiche zu erfüllen. Mit KI ist jedoch eine selbstständige Servicebereitstellung und individuelle Orchestrierung möglich. Die Observability-Plattform kann sich auf die untersten Ebenen der Fähigkeiten und die abstrakte Ausgabe konzentrieren, während die Geschäftsteams die Werkzeuge frei kombinieren können, um ein "individuelles" Betriebserlebnis zu erzielen.

Der dritte Aspekt ist die Bildung eines intelligenten Entscheidungszyklus. Die traditionelle Observability konzentriert sich hauptsächlich auf das "Sehen", während das zukünftige neue Betriebsmanagementparadigma möglicherweise einen vollständigen Zyklus von "Entdeckung - Analyse - Lösung - Nachbereitung" realisieren kann. In diesem Prozess wandelt sich das Observability-System von einer bloßen "Auge" zu einem System, das sowohl "Gehirn" als auch "Hände" hat.

Zhang Cheng: Wie sollen wir die "Intelligenz" eines KI-Agents messen? Ist die Punktzahl in Labor-Tests wichtiger oder seine Fähigkeit, reale Probleme in komplexen Online-Umgebungen zu lösen?

Dong Shandong: Um die Intelligenz eines KI-Agents zu messen, sollten wir die allgemeinen Fähigkeiten und die spezifischen Fähigkeiten getrennt betrachten.

Für die allgemeinen Fähigkeiten gibt es derzeit gute Referenzen, wie die Benchmarks für LLMs wie MMLU, MATH oder die Bewertungen für Agent-Fähigkeiten wie AgentBench, SWE-bench. Diese messen die allgemeinen Verstehens-, Inferenz- und Planungsfähigkeiten von LLMs.

Für die spezifischen Fähigkeiten hingegen ist es wichtig, seine Fähigkeit, reale Probleme zu lösen, zu berücksichtigen. Dies ist besonders im Observability-Bereich deutlich. Natürlich hat die AIOps-Community einige Demos und entsprechende Datensätze für die Observability und Fehlerbehebung erstellt, die als Referenz dienen können. In verschiedenen Unternehmen gibt es jedoch viele komplexere Probleme, deren Anforderungen möglicherweise nicht standardisiert sind. Dies stellt höhere Anforderungen an die Fähigkeit des KI-Agents, reale Probleme zu lösen.

Nehmen wir das Beispiel der Root-Cause-Analyse (RCA) im Observability-Bereich. Ich möchte Ihnen eine einfache Einteilung der KI-Agentenstufen geben, die Sie als Referenz nutzen können:

L1 +: Punktuelle Verstärkung: Bei einem bestimmten Problem bleibt der Analyseprozess der gleiche wie zuvor, aber der KI-Agent kann einige Schritte der Analyse verbessern.

L2: Autonomes Problem lösen. Die RCA wird vollständig vom Agent übernommen. Wenn ein benutzerdefinierter Indikator ein Problem aufweist, kann der KI-Agent auf der Grundlage der vordefinierten Standard Operating Procedures (SOPs) und der tatsächlichen Situation planen und ausführen, bis das Problem gelöst ist.

L3: Lernen. Auf der Grundlage eines von Menschen festgelegten Überwachungsziels und -auftrags kann der Agent die internen Dokumente und Daten des Teams lesen, Wissen extrahieren und lernen. Wenn ein Benutzer nach einem allgemeinen Fehlerbehebungsverfahren fragt, kann der Agent auch prüfen, ob er es korrekt ausführen kann. Wenn einige Werkzeuge fehlen, kann er diese selbst gemäß einem bestimmten Protokoll und Format erstellen und schließlich das Fehlerbehebungsverfahren korrekt ausführen und ausgeben.

Li Ye: Die Fähigkeit, reale Probleme zu lösen, ist wichtiger. Labor-Tests sollten so nah wie möglich an der realen Situation sein. Derzeit gibt es in einigen Ranglisten von LLMs das Problem des "Rankings". Nehmen wir das Beispiel von SWE Bench Verified, das nur etwa 500 Aufgaben enthält. Wenn ein Algorithmusingenieur jeden Tag einen fehlerhaften Fall korrigiert, kann er innerhalb eines Jahres fast den gesamten Datensatz auswendig lernen und durch künstliche Überanpassung eine hohe Punktzahl erzielen. Dies führt dazu, dass die Laborpunktzahl oft nicht die reale Leistung des Modells widerspiegelt.

Ahnliche Probleme gibt es auch in anderen Bereichen. Beispielsweise beinhaltet ein Labor-Test in einem Microservice-Szenario normalerweise nur ein Dutzend Dienste, während ein reales Produktionssystem hunderte von Diensten haben kann, und jeder Dienst viele Aktionen umfasst. Die Komplexität ist nicht vergleichbar. Die Arten von Fehlern, die in einem Labor durch Chaos-Engineering eingeführt werden, sind begrenzt, während die realen Fehler vielfältig sind. Wenn wir nur bekannte Probleme zur Validierung nutzen, kann die Leistung des Algorithmus möglicherweise nicht besser sein als die eines Regelsystems und die Generalisierungsfähigkeit des LLMs in unbekannten Szenarien wird nicht gezeigt.

Die Bewertung der Fähigkeit, reale Probleme zu lösen, erfordert eine angemessene Einteilung der Schwierigkeitsgrade der Aufgaben. Wir können nicht erwarten, dass "Schüler der ersten Klasse an einem Hochschulzugangsprüfung teilnehmen". Ebenso kann ein aktuelles LLM möglicherweise nicht in der Lage sein, L3-komplexe Aufgaben zu lösen, aber dies bedeutet nicht, dass KI nutzlos ist, sondern dass es derzeit nicht für solche hochgradigen Szenarien geeignet ist. Im Gegensatz dazu hat das LLM in Aufgaben wie der Umwandlung von natürlicher Sprache in SQL oder PromQL bereits eine zuverlässige Leistung gezeigt. Solche Tests, die der Realität nahekommen, können unser Vertrauen in die Umsetzung von KI stärken.

Zhang Cheng: Bedeutet die Einführung von LLMs, dass die traditionellen Algorithmen, auf die wir uns in der Vergangenheit verlassen haben, an ihre Grenzen stoßen? Was bringt es für "qualitative" Unterschiede bei der Verarbeitung von Observability-Daten?

Wang Yapu: Die traditionellen Algorithmen haben noch nicht an ihre Grenzen gestoßen. Ihr größter Vorteil liegt in ihrer Bestimmtheit. In vielen Szenarien sind traditionelle Algorithmen immer noch unverzichtbar. Nehmen wir die Zeitreihenanomalieerkennung als Beispiel. Die meisten Produktionssysteme nutzen derzeit noch diese Algorithmen in großem Maßstab. Sie zeichnen sich durch eine schnelle Reaktion, einen geringen Ressourcenverbrauch, eine hohe Kontrollierbarkeit und eine gute Stabilität aus. Bei einigen etablierten kleinen Modellen kann die Genauigkeit sehr hoch sein, wenn das Szenario klar definiert ist. Die Latenz kann sogar auf Millisekunden reduziert werden, was derzeit von LLMs nicht erreicht werden kann.

Die Einführung von LLMs bringt jedoch qualitative Veränderungen, insbesondere in Bezug auf die Lern- und Effizienzsteigerungsfähigkeit. Traditionelle Algorithmen sind bei der Verarbeitung von einzelnen Datenquellen sehr effizient, aber bei komplexen multimodalen und transdisziplinären Problemen an ihre Grenzen gestoßen. Ein LLM kann jedoch verschiedene Informationen gleichzeitig verstehen, einschließlich Indikatorkurven, Protokolltexten, Benutzerfeedback und Codeänderungen, und Beziehungen zwischen ihnen herstellen. Diese "verbindende" Fähigkeit ist für traditionelle Algorithmen schwer zu erreichen.

Der zweite Vorteil ist die Programmierbarkeit und Nachvollziehbarkeit. Traditionelle Algorithmen erfordern normalerweise die Datensammlung, manuelle Annotation und Parameteroptimierung, was einen großen Arbeitsaufwand bedeutet. Ein LLM kann jedoch durch Inferenzketten und Werkzeugaufrufe den Fehlerdiagnoseprozess automatisch zusammenstellen. Beispielsweise kann es ents