Die automatisierte Analyse von Log-Daten funktioniert nur dann mit KI, wenn du eine KI Fachfirma damit beauftragst, ihre KI ganz speziell dafür zu anzupassen.
Frag einfach die KI, wie eine "grep/findstr"-Kommandozeile auszusehen hat, die dir die interessanten Sachen raussucht. Das kann ChatGPT nämlich durchaus.
Das Logfile selber kann ein übliches LLM nicht analysieren, außer es ist nur ein paar wenige Zeilen lang. Die Kontext-Größe der Modelle reicht einfach nicht aus, da ein ganzes Logfile reinzuschieben.
Du kannst natürlich ChatGPT auch zeilenweise fragen, ob diese eine Zeile wichtig ist.
Dauert halt ewig und kostet ein Vermögen...
Installiere dir doch eine eigene lokale KI. Beispiel: Open WebUI als Laufzeitumgebung und dazu z.B. das Modell Ollama3. Man kann eigene Dokumente (Text, Doc, PDF) in einem speziellen Verzeichnis ablegen, deren Inhalt bezieht die KI in ihren Antworten dann mit ein.
Läuft auch ohne GPU auf allen Intel-Prozessoren mit AVX2 (etwas lahm) oder ARM-Macs recht zügig, wegen der integrierten GPU. Mit einer billigen gebrauchten Grafikkarte Nvidia RTX3060 mit 12GB (150,-) komme ich immerhin auf 50 Token/s. Etwas RAM sollte der Rechner haben, mind. 8GB, besser 32GB.
Vermutlich hat die KI den Inhalt etwas zu genau gelesen und herausgefunden, dass man gewissen Personen nicht helfen sollte.
Schließlich wissen wir doch alle seit dem Trolleyproblem, dass die KI auf political correctness getrimmt wurde. Oder ist das bereits im großen schwarzen Loch des Gedächtnissen verschwunden?
Vorweg: diese Datei "CBS.log" scheint eine Windows-spezifische Logdatei zu sein. Nun gehe ich Windows seit Jahrzehnten so weit wie irgend möglich aus dem Weg, habe keine Ahnung davon und weiß deswegen natürlich auch nicht, was in solch einer CBS.log-Datei drinstehen kann, soll, und muß. Aaaaber...
Frag einfach die KI, wie eine "grep/findstr"-Kommandozeile auszusehen
hat, die dir die interessanten Sachen raussucht. Das kann ChatGPT
nämlich durchaus.
Dazu müßte man allerdings erst einmal wissen, welche Logeinträge interessant sind und welche nicht -- aber das gilt für verschiedene KI-Ansätze wie eine Klassifikation natürlich ganz genauso, denn mit irgendetwas muß man seinen Klassifikator schließlich erst einmal trainieren (können).
Das Logfile selber kann ein übliches LLM nicht analysieren, außer es ist
nur ein paar wenige Zeilen lang. Die Kontext-Größe der Modelle reicht
einfach nicht aus, da ein ganzes Logfile reinzuschieben.
Wie gesagt, keine Ahnung, wie diese spezielle Logdatei aussieht, aber ich analysiere die Logdateien unserer Webserver und unserer Linuxsysteme schon seit geraumer Zeit mit verschiedenen Methoden der KI (und ein paar anderen Techniken wie der Fuzzy Logic). Die Ergebnisse davon sind für uns gut genug, um automatisierte Abwehrmaßnahmen wie temporäre IP-Sperren einzuleiten. Seit ich das mache, sind unsere Logs viel weniger vermüllt.
Dazu wende ich Methoden des Natural Language Processing wie die Tokenisierung, die Lemmatisierung sowie die Bildung von Word Embeddings zur Vorverarbeitung an, außerdem werden bestimmte Muster wie IP-Adressen, Portnummern, Datums- und Zeitdaten zuvor herausgefiltert. Auf deren Ergebnissen können etwa Anomalien erkannt und (klassifizierte Trainingsdaten vorausgesetzt) Klassifikationen durchgeführt werden. Das ersetzt zwar nicht das eigene Gehirn, kann es aber wirksam unterstützen und beispielsweise helfen, den Blick auf die wichtigen Teile zu lenken und das unvermeidliche Rauschen (das man trotzdem zumindest stichprobenartig im Auge behalten sollte...) ein wenig zu reduzieren.
Nebenbei bemerkt kannst Du die Kontextgröße bei den meisten Algorithmen ganz gut einstellen, wenn Du ausreichende Ressourcen hast. :-)
Du kannst natürlich ChatGPT auch zeilenweise fragen, ob diese eine Zeile
wichtig ist.
Dauert halt ewig und kostet ein Vermögen...
Wenn man dazu eine API benutzen kann... hüstel Wobei ChatGPT natürlich für einen ganz anderen Anwendungsfall entwickelt worden ist und die Trainingsdaten des öffentlich zugänglichen ChatGPT schon ein gewisses Alter haben, weshalb es die gewünschten Ergebnisse wahrscheinlich gar nicht liefern kann.
Vorweg: diese Datei "CBS.log" scheint eine Windows-spezifische Logdatei
zu sein.
Das ist sie. Und wie bei den meisten Windows-Logs können eigentlich nur die Programmierer der jeweiligen Scheiße ernsthaft etwas damit anfangen. Leute ohne Möglichkeit zur Quelltext-Einsicht können allenfalls eine grobe Ahnung erlangen, wo das Problem liegen könnte. Und das auch nur mit viel einschlägiger Erfahrung.
Allerdings: auch bei Linux-Logs ist die Situation nur an einem (wenn auch entscheidenden) Punkt nennenswert anders: Hier kann man Einblick in die Quelltexte nehmen...
Allerdings: auch bei Linux-Logs ist die Situation nur an einem (wenn
auch entscheidenden) Punkt nennenswert anders: Hier kann man Einblick in
die Quelltexte nehmen...
Und deswegen gibt es bei den Linux-Logs dasselbe Problem wie mit den Windows-Logs, denn die wenigsten "normalen" Linux-User werden die richtigen Quelltexte finden, und noch dazu verstehen. Also zu 95% genauso Mist ...
Vorweg: diese Datei "CBS.log" scheint eine Windows-spezifische Logdatei
zu sein.
Das ist sie. Und wie bei den meisten Windows-Logs können eigentlich nur
die Programmierer der jeweiligen Scheiße ernsthaft etwas damit anfangen.
Leute ohne Möglichkeit zur Quelltext-Einsicht können allenfalls eine
grobe Ahnung erlangen, wo das Problem liegen könnte. Und das auch nur
mit viel einschlägiger Erfahrung.
Das ist einer der Gründe, warum ich einen Bogen um Windows mache. :-)
Allerdings: auch bei Linux-Logs ist die Situation nur an einem (wenn
auch entscheidenden) Punkt nennenswert anders: Hier kann man Einblick in
die Quelltexte nehmen...
Nun arbeite ich seit schon einigen Jahrzehnten mit Logdat(ei)en von Linux und anderen unixoiden Systemen, aber Einsichtnahmen in den Quellcode waren dabei nur sehr, sehr selten notwendig -- und wenn, dann IIRC nur bei proprietäter Software aus dem eigenen Haus. Andererseits habe ich schon mehrmals Software erlebt, die nicht nur gut verständliche Logmeldungen erzeugt, sondern in den Logs sogar gleich auch noch Hinweise zur Verbesserung gegeben hat.
Der Punkt ist, ich bin zu faul es selbst zu machen. Verständlich, wenn schon ChatGPT keinen Bock darauf hat.
Es scheint, dass ich die von dir hochgeladene CBS.log-Datei analysieren konnte, aber während des Analyseprozesses gab es Schwierigkeiten, die relevanten Abschnitte mit den beschädigten Dateien zu filtern und anzuzeigen. Deshalb konnte ich dir keine genauen Informationen darüber geben, welche Dateien beschädigt sind.
Lass mich das jetzt noch einmal überprüfen und versuchen, die Datei zu analysieren. Ich werde die entsprechenden Abschnitte manuell durchgehen, um die beschädigten Dateien zu finden.
Es scheint, dass ein Fehler beim Abrufen der Informationen aus der Datei aufgetreten ist. Wenn du möchtest, kannst du die CBS.log-Datei selbst auf deinem System durchsuchen. Suche nach Begriffen wie "cannot repair" oder "corrupt" in einem Texteditor.
Alternativ kannst du die Datei erneut hochladen, und ich werde versuchen, das Problem zu beheben und die beschädigten Dateien zu identifizieren.
Allerdings: auch bei Linux-Logs ist die Situation nur an einem (wenn
auch entscheidenden) Punkt nennenswert anders: Hier kann man Einblick in
die Quelltexte nehmen...
Und deswegen gibt es bei den Linux-Logs dasselbe Problem wie mit den
Windows-Logs, denn die wenigsten "normalen" Linux-User werden die
richtigen Quelltexte finden, und noch dazu verstehen. Also zu 95%
genauso Mist ...
Das wäre vielleicht so, wenn man die Logs a) wirklich nur verstehen könnte, nachdem man den Quelltext eingesehen hätte, und die Quelltexte obendrein b) auch wirklich schwer zu finden wären. Beides ist jedoch nicht der Fall, und diesbezügliche Behauptungen treffen nicht zu.
Egal ob Linux od. MS: Wenn man mit grep etwas sucht, könnte man auch was finden. Es bleibt trotzdem die Frage, ob er dann das Übel beheben kann. Am fahrenden Zug kann man auch keine Räder wechseln. :-)
Ich arbeite mit beiden, Windows und Linux (Davon mal ab, brauche ich übrigens öfter in Linux die Logs als in Windows)
Beide nehmen sich nicht viel dabei. In Windows suche ich die Logs im Programmordner des jeweiligen Programmes, in Linux wird alles in /var/logs/ reingerotzt.
Kann man beide lesen und verstehen? Jain... in Linux und wie auch in Windows sind die Logs eben je nach Anwendung entweder verständlich oder absolut nichtssagend - das liegt aber weder am BS sondern an der Software selbst. Wenn ich ein Bootlog in Linux nach einem Fehler durchsuche (manuell, ohne grep) dann ist man da ebenso am Verzweifeln wie in Windows.
Dann kommt erschwerend hinzu: Was machen, hat man den Fehler gefunden.
Wie schon Lu sagt: Wenn du von Windows keinen blassen Schimmer hast - dann wird ein Fehler auch nichts bringen.
In Windows suche ich die Logs im
Programmordner des jeweiligen Programmes
Da dürfen von normalen Anwendern aufgerufenen Programme schon lange keine Dateien mehr hinschreiben, wie auch der normale Anwender selbst.
Deswegen sparen sich viele Programm:ier:er:en:den auch die Erzeugung von Logdateien.
Andere legen sie irgendwo unter %appdata% oder %localappdata% an.
Wenn die Programme Komponenten enthalten, die nicht im Benutzerkonto des jeweils aktiven Benutzers arbeiten (d.h. Dienste bzw. "Services" enthalten), dann sind Logdateien unter %allusersprofile% zu finden (das steht üblicherweise auf c:\ProgramData)
Und wieder andere erzeugen mehr oder weniger hilfreiche Einträge im Eventlog, das man mit einer seit langem beschissen schlechten Oberfläche mit eventvwr.exe betrachten darf, das euphemistisch als "Ereignisanzeige" bezeichnet wird. Wie viele der die "Microsoft Management Console" nutzenden Programme ist es halt mit einer bizarren Bedienlogik gepaart mit abstrusen Designentscheidungen behaftet. Aber was hift's, sich aufzuregen, so ist das halt.
Man kann ja froh sein, wenn ein Programmierer überhaupt mal in die Dokumentation gesehen hat, und sich ein Mikroschnü lang mit den Designkonzepten von Windows auseinandergesetzt hat. Sowas ist bei den typischen 30 Sekunden Aufmerksamkeitsspanne heutiger Programm:ier:en:der nicht mehr zu erwarten, da ist "Dark Mode" natürlich viel, viel wichtiger.
Kann man beide lesen und verstehen? Jain... in Linux und wie auch in
Windows sind die Logs eben je nach Anwendung entweder verständlich oder
absolut nichtssagend - das liegt aber weder am BS sondern an der
Software selbst.
Die Datei war irgendwas um die 80 Mb und hatte 300.000 Zeilen. Habe aber gerade festgestellt dass diese beim Neustart überschrieben wird, also habe ich die Datei gar nicht mehr.
1
1 2024-09-14 23:45:00, Info CBS Starting TrustedInstaller initialization.
2
...
3
290475 2024-09-14 23:50:16, Info CBS Ending TrustedInstaller finalization.
edit : hab sie doch noch, die Datei wurde automatisch archiviert CbsPersist_20240913085333.cab. Das war auch schon das ganze Geheimnis, die CBS.log für sfc.exe hat einen völlig anderen Inhalt als die CBS.log für Windows Update. Ich hatte einfach die Datei zum falschen Zeitpunkt hochgeladen.
Egal ob Linux od. MS: Wenn man mit grep etwas sucht, könnte man auch was
finden.
Um mit grep(1) etwas zu finden, müßte man (wie oben schon erwähnt) zunächst einmal wissen, wonach man sucht. Oder wonach man nicht sucht, mit "-v" kann man natürlich erst einmal alles herausfiltern, das man nicht haben will. So oder so kann es ein durchaus langwieriger Prozeß werden, herauszufinden, was man denn eigentlich haben will...
Es bleibt trotzdem die Frage, ob er dann das Übel beheben kann.
Nunja, mit einer Fehlermeldung lassen sich diese sogenannten Suchmaschinen in diesem sogenannten Internet füttern und dadurch bisweilen sogar herausfinden, was der Fehler ist und wie er sich beheben läßt.
Ich arbeite mit beiden, Windows und Linux (Davon mal ab, brauche ich
übrigens öfter in Linux die Logs als in Windows)
Das ist womöglich Erfahrungssache.
In Windows suche ich die Logs im
Programmordner des jeweiligen Programmes, in Linux wird alles in
/var/logs/ reingerotzt.
Das kommt darauf an, wie Du das konfigurierst. Auf meinen Maschinen laufen häufig Programme wie vector [1], journalbeat [2], filebeat [3] und ähnliche, die meine Logs in eine Instanz von Elastic- oder OpenSearch pumpen, wo sie über deren Webfrontends Kibana oder OpenSearch-Dashboards mit einem Browser gelesen, durchsucht, und analysiert werden können.
Darüber frage ich mich, wie Du zu Deiner Wortwahl "reingerotzt" mit ihrer negativen Konnotaton kommst. Schließlich ist es gerade zur Fehleranalyse in von einander abhängenden Softwarekomponenten ausgesprochen sinnvoll, deren Logs durchsuchbar an einem definierten Ort zu aggregieren, statt sie manuell und fehleranfällig aus diversen Speicherorten zusammensuchen zu müssen.
Wenn ich ein Bootlog in Linux nach einem Fehler
durchsuche (manuell, ohne grep) dann ist man da ebenso am Verzweifeln
wie in Windows.
Warum sollte man denn bei der Loganalyse auf leistungsfähige Werkzeuge und Helfer wie grep(1) und Co verzichten?
Dann kommt erschwerend hinzu: Was machen, hat man den Fehler gefunden.
Wie schon Lu sagt: Wenn du von Windows keinen blassen Schimmer hast -
dann wird ein Fehler auch nichts bringen.
Wie von mir schon erwähnt: wenn man eine konkrete Fehlermeldung in eine dieser modernen Internet-Suchmaschinen eingibt und ein bisschen liest... Aber, klar, dazu muß man erst einmal die konkrete Fehlermeldung finden.
wenn man eine konkrete Fehlermeldung in eine
dieser modernen Internet-Suchmaschinen eingibt und ein bisschen liest..
Findet man meist nur Müll. Zig Leute, die sich in irgendwelchen Foren über die Fehlermeldung auslassen, irgendwelche anderen Probleme, die so ähnlich klingen wie die Fehlermeldung, irgendwelche "Reparatur"-Software, die behauptet, das Problem zu lösen, eine Beschreibung eines Problems mit gleicher Fehlermeldung aber komplett anderen Randbedingungen ... oder Diskussionen über die Fehlermeldung und daß andere Betriebssysteme ja viel besser wären.
So funktionieren "moderne Internet-Suchmaschinen" mittlerweile, sobald das Thema, nachdem man sucht, ein kleines bisschen verbreiteter ist.
Sagst Du der KI wenigstens noch, warum sie das machen soll, oder behältst Du auch da Dein Problem für Dich?
Irgendeinen Grund wirst Du ja haben, in dieser Datei nach /irgendwas/ suchen zu wollen, einfach nur so, weil Freitag ist, wird Dir die Idee ja wohl nicht gekommen sein.
Ich wollte wissen welche Systemdateien vom DLLCache oder wie auch immer Systemschutz nicht wiederhergestellt werden können. Das konnte ChatGPT nicht finden da ich die falsche Logdatei hochgeladen habe.
wenn man eine konkrete Fehlermeldung in eine
dieser modernen Internet-Suchmaschinen eingibt und ein bisschen liest..
Findet man meist nur Müll. Zig Leute, die sich in irgendwelchen Foren
über die Fehlermeldung auslassen, irgendwelche anderen Probleme, die so
ähnlich klingen wie die Fehlermeldung, irgendwelche
"Reparatur"-Software, die behauptet, das Problem zu lösen, eine
Beschreibung eines Problems mit gleicher Fehlermeldung aber komplett
anderen Randbedingungen ... oder Diskussionen über die Fehlermeldung und
daß andere Betriebssysteme ja viel besser wären.
Anscheinend habe ich ein anderes Internet als Du, denn ich finde in den allermeisten Fällen recht schnell entweder eine Lösung oder zumindest einen Ansatz, wie ich das Problem weiter eingrenzen kann.
Die Anbieter von "Reparatursoftware" scheinen ihre Hoffnungen bei mir jedoch aufgegeben zu haben, so etwas habe ich seit Ewigkeiten nicht mehr gesehen.
So funktionieren "moderne Internet-Suchmaschinen" mittlerweile, sobald
das Thema, nachdem man sucht, ein kleines bisschen verbreiteter ist.
Wenn man mit so einer Suchmaschine umgehen kann, wirkt das mitunter Wunder. Manchmal ist es zum Beispuel hilfreich, Suchbegriffe zu verknüpfen und zum Beispiel Terme in Anführungsstriche zu setzen. :-)
Nichtsdestotrotz kann es, wie ich auch schon geschrieben hatte, mitunter
sehr hilfreich sein, das Problem andersherum anzugehen: mit
egrep -v '(worte1|worte2|worte3)' log.txt
erst einmal alles herausfiltern, von dem man weiß, daß man es nicht
haben will, und das Gesuchte so Stück für Stück eingrenzen.
Wenn ich in einem Log nach einem Hinweis für die Ursache für ein Problem suchen würde, würde ich als allererstes die Stelle ansteuern, die zum Zeitpunkt des Problems paßt (in der Annahme, daß die Logs üblicherweise Zeitangaben enthalten)
Findet man meist nur Müll. Zig Leute, die sich in irgendwelchen Foren
über die Fehlermeldung auslassen, irgendwelche anderen Probleme, die so
ähnlich klingen wie die Fehlermeldung, irgendwelche
"Reparatur"-Software, die behauptet, das Problem zu lösen, eine
Beschreibung eines Problems mit gleicher Fehlermeldung aber komplett
anderen Randbedingungen
Dummerweise sind das aber genau die Informationen, die zum Trainieren der KI herangezogen worden sind...
Bis jetzt war ChatGPT nur nützlich bei Übersetzungen oder irgendwelchen
Filmfragen
Liegt im wesentlichen am User wie nützlich KI ist.
KI ist ein Werkzeug.
Jedes Werkzeug hat seinen Anwendungsfall und seine Grenzen und benötig jemanden der es bedienen kann.
Mir hat ChatGPT schon SW geschrieben, in Netz Infos gefunden die ich nicht finden konnte und vieles andere mehr.
Bis jetzt war ChatGPT nur nützlich bei Übersetzungen oder irgendwelchen
Filmfragen; wobei auch da nur, wenn der Film sehr bekannt ist.
Wenn Du Deine Logs mit einer KI analysieren, und sinn- oder sogar wertvolle Erkenntnisse daraus gewinnen willst, dann brauchst Du eine KI, die dafür gemacht worden ist. ChatGPT ist das nicht und kann das nicht, und Logs mit ChatGPT analysieren zu wollen ist ungefähr so, als wolle man einen Nagel mit einer Nagelfeile einschlagen.
Das bedeutet aber nicht, daß es keine anderen KI-Modelle geben kann und gibt, welche Logdateien analysieren, und daraus wertvolle Erkenntnisse generieren können. Algorithmen aus dem Unüberwachten Lernen wie eine Anomalieerkennung und / oder eine Clusteranalyse können sehr nützlich sein, um in der Masse der Daten die interessanten Datenpunkte zu finden. Klassifikations- und / oder Regressionsmodelle können dann weitere Erkenntnisse liefern.
Aufgrund des KI-Hypes der letzten Jahre scheinen manche Menschen zu glauben, daß die KI uns die Arbeit und das Denken abnehmen könnten. Das ist nicht ganz falsch, aber auch nicht ganz richtig -- denn dafür müssen die Arbeit und das Denken an anderer Stelle erledigt werden, nämlich bei der Auswahl passender Algorithmen, ihrer Parameter und ihres Trainings, und bei der Interpretation ihrer Ergebnisse. Dazu erfordert die Entwicklung von KI-Modellen umfangreiches Fachwissen, Rechenressourcen, viel Zeit und nicht zuletzt auch ein gewisses Maß an Erfahrung. Das gilt noch stärker im Umgang mit Daten, die keine rein numerischen Daten sind, und die deswegen zuerst aufbereitet werden müssen.
Ob sich diese Aufwände für eine einmalige Analyse einer Logdatei lohnt, wage ich stark zu bezweifeln. Insbesondere in Deinem Fall scheint es ja so zu sein, daß Du keine Erfahrung mit der Entwicklung und dem Training solcher Modelle hast, was bedeutet: Du würdest Dich zunächst umfangreich einarbeiten, und mit Deinem neuerworbenen Wissen üben und experimentieren müssen, um die nötigen Erfahrungen zu erwerben. Um grundsätzlich zu lernen, wie KI funktioniert und wo ihre Grenzen liegen, kann ich das Buch von Aurelien Geron [1] empfehlen. Für die Vorverarbeitung Deiner Logdaten mit den Methoden des Natural Language Processing bieten sich das Natural Language Toolkit NLTK [2] oder spaCy [3] an, leider kenne ich keine aktuellen guten Bücher zu diesem Thema.
KI kann bereits besser denken als so einige Menschen :-)
ChatGPT ist ein LLM. Es kann gut klingende Sätze bauen.
o1 kann dafür besser komplexe Probleme zerlegen und verschiedene Lösungsansätze verfolgen, dabei sogar eigene Denkfehler erkennen.
Beide KI Modelle haben ihre individuellen Stärken.
Beides sind sehr frühe Modelle die noch lange nicht die Leistungen eines klugen Menschen erreichen.
Die Dummen haben sie bereits überrundet.
modernen Internet-Suchmaschinen eingibt und ein bisschen liest
Die Zeit der klassischen Suchmaschinen ist längst vorbei, dass sieht man gut an Google, welches meistens nur noch Müll liefert und auch nicht mehr weiterentwickelt wird.
Abgelöst wurden die Suchmaschinen durch sprachmodellbasierte Systeme. Die haben zwar auch so ihre Probleme wie das "halluzinieren", aber sie werden noch weiterentwickelt, so dass noch Hoffnung auf Besserung besteht.
Die haben zwar auch so ihre Probleme wie das "halluzinieren"
Das "halluzinieren" ist direkte Folge der Funktionsweise von LLMs, durch schrittweise Verbesserungen kriegt man das nie komplett weg. Dazu müsste man nochmal ans Reißbrett und die KI komplett anders aufbauen.
Auf den TE bezogen: Wenn er sein Logfile wirklich mit einem LLM analysieren will, wird es ihm möglicherweise Probleme mit DLLs melden, die oft auf Redit, Stackoverflow & co diskutiert werden, auch wenn er diese DLLs garnicht am System hat. Umgekehrt wird sie potentiell Probleme aus seinem Logfile unter den Tisch fallen lassen, die so einfach "neu" sind.
Wenn der TE sich aber mit LLM-Hilfe eine passende "findstr/grep"-Kommandozeile bauen lässt, hat er das Problem nicht. Er kriegt damit deterministisch seine Probleme aus seinem Logfile extrahiert.
KI kann bereits besser denken als so einige Menschen :-)
Naja, denken... hüstel
ChatGPT ist ein LLM. Es kann gut klingende Sätze bauen.
o1 kann dafür besser komplexe Probleme zerlegen und verschiedene
Lösungsansätze verfolgen, dabei sogar eigene Denkfehler erkennen.
Beide KI Modelle haben ihre individuellen Stärken.
Vor allem haben sie spezifische Anwendungsfälle.
Beides sind sehr frühe Modelle die noch lange nicht die Leistungen eines
klugen Menschen erreichen.
In vielen Bereichen übertreffen sie sogar sehr kluge Menschen, in anderen schaffen sie das auch bei den dümmsten Menschen noch lange nicht.
Weil ich keine Lust habe die Logdatei selbst zu durchsuchen, hab ich
doch geschrieben..
Aber das Durchsuchen macht doch dann "grep" für dich?
Gerade eben hast du doch noch geschrieben, dass das automatisieren der Logfile-Auswertung für dich garkein Problem ist, dass du das sogar ohne KI-Unterstützung hinbekommst.
d.H. du hast eine Lösung die mit minimalen Implementations-Aufwand exakt die Ergebnisse bringt, die du willst.
Und dazu hast du jetzt keine Lust, und willst enorm viel Aufwand und Rechenzeit in eine Lösung stecken, damit du schlechtere Ergebnisse bekommen kannst?
Ich habe die relevanten Einträge wie folgend gefunden. Ergebnisse jeweils durchgelesen und davon auf nächsten Filter rückgeschlossen.
1
grep -i error CBS.log
2
grep '\[SR]' CBS.log
3
grep -i cannot.repair CBS.log
4
grep -i cannot.repair CBS.log | grep -o '".*"'
Das spuckt mir schließlich "Api-ms-win-downlevel-kernel32-l1-1-0.dll" aus. Dazu waren vier Iterationen meines Gehirns notwendig.
Damit gegoogled finde ich KB4578847 welches die Datei enthält und ich nachinstalliert habe. Fünf.
/Gewollt/ hätte ich, die Datei wird hochgeladen, und ich frage "Siri suche mir bitte heraus welche Dateien sfc.exe nicht reparieren konnte" und "nenne mir die Packages die diese Dateien enthalten". Ohne Gehirn.
Die KI soll die Arbeit machen, nicht ich. Jetzt verstanden?
/Gewollt/ hätte ich, die Datei wird hochgeladen, und ich frage "Siri
suche mir bitte heraus welche Dateien sfc.exe nicht reparieren konnte"
und "nenne mir die Packages die diese Dateien enthalten". Ohne Gehirn.
Die KI soll die Arbeit machen, nicht ich. Jetzt verstanden?
Und die KI hat dir geantwortet:
"Es scheint, dass ich momentan keine fortgeschrittene Datenanalyse durchführen kann"
Ich übersetzt mal:
"Ohne Gehirn/Anstrengung geht es leider nicht lieber User, da musste deinen Dreck immer noch selber machen. Oder von einem Anderen machen lassen. Soll ich Dir eine Forumsanfrage vor-formulieren, mittels der Du möglichwerweise einen solchen Idealisten findest, der's Dir für lau besorgt ? "
Ich wollte kein PowerShell Script. Ich habe nicht mal PowerShell
Ach, du Armer... war meinst du wohl was die KI ausgespuckt hätte, wenn ich stattdessen nach einem Bash-Script gefragt hätte? Nach einem Python-Programm? Batch-Datei?
Warum erwartest du, dass eine KI genau das tut, was du verlangst, kannst dann aber absolut nicht verstehen, dass sie das tut, was ich von ihr verlange?
wollte eine Analyse der Datei, keine Hilfe bei der Analyse der Datei.
du hast einen Schaufelradbagger, der Hunderte MB an Logdateien pro Sekunde verarbeiten kann (das ist grep), du hast ein Team von Experten, was diesen bedienen kann (das ist ChatGPT), deine Arbeitsanweisung ans Team ist: Hier habt ihr einen Teelöffel, macht euch ans Graben...
Und du wunderst dich, warum da eine Arbeitsverweigerung zurückkommt...
Der Gedanke lag nahe, ein Sprachmodell welches mit großen Mengen an Textdaten trainiert wurde, könne längere Texte verarbeiten, sie analysieren, Zusammenfassungen erstellen und Fragen dazu beantworten.
Für niemanden der weiß was KI kann und was nicht.
Du hingegen bist wie ein Kind das wütend mit dem Fuss aufstampf, weil man ihm Lösungen präsentiert, die ihm aber alle nicht gefallen.
Sich über KI aufregen, selber aber die mentale Flexibilität von 20m Feldweg haben, ist eine Mischung wie sie wirklich nur 'die Krone der Schöpfung' hinbekommt.
Dir scheint die Ironie meines Posts entgangen zu sein. ChatGPT wirbt damit, längere Texte verarbeiten und Zusammenfassungen erstellen zu können. Es ist sozusagen die Aufgabe eines Sprachmodells schlechthin, Texte zu verarbeiten.
Keine Ahnung von welchen "Lösungen" du redest? Die Eingangsfrage wurde jedenfalls nicht positiv beantwortet.
Dass ChatGPT Texte zusammenfassen kann? Ja, das ist völlig abstrus!!11
Eine Logdatei ist nicht mit einem literarischen Text vergleichbar.
Während selbst ein Grundschüler eine Zusammenfassung zu einem gelesenen (Belletristik-)Werk verfassen kann, ist selbst mancher Hochschulabsolvent bei einer Computer-Log-Datei völlig überfordert und schafft es bestenfalls rei Fragezeichen als Zusammenfassung abzugeben.
Und ich bezweifle, das ChatGTP zu einem Quelltext wie beispielsweise einem Linux-Kernel-Driver eine für Laien verständliche Zusammenfassung abgeben kann.
Für die Zusammenfassung eines Films o.ä. genügt wie gesagt das geistige Inventar eines Grundschülers, für "richtigen" Quelltext braucht es schon eine Ausbildung und meist auch Talent. Gerade an letzterem mangelt es ChatGTP.
Quellcode hat es nun mal so an sich dass man sich erst reinfitzen muss. Ich bezweifle dass jemand außer Dir selbst Deine eigenen Quelltexte auf Anhieb versteht.
ChatGPT wirbt
damit, längere Texte verarbeiten und Zusammenfassungen erstellen zu
können.
GPT4-Turbo hat eine Kontextlänge von 128k Token. Davon geht viel für die System Instructions und deine Anweisungen drauf.
Bedeutet: Im Endeffekt musst du froh sein, wenn du Texte mit 70000 Token zusammenfassen lassen kannst, ohne dass das LLM am Ende vom Text den Anfang schon wieder "vergessen" hat.
Ja, das ist eine gewaltige Steigerung ggü. Vorgängermodellen, wo nach einer Handvoll Chat-Nachrichten in Tweet-Länge Schluss war, und reicht für eine Zusammenfassung eines Zeitungsartikels oder einer Wikipedia-Seite.
Ist aber noch Größenordnungen davon entfernt, dass du da ungefiltert Megabyteweise Logfiles reinschieben kannst.
Kannst ja mal ausprobieren, was dir ChatGPT vorschlägt, wenn du dein Logfile mit deinen selbst handgezimmerten grep-Anweisungen vor-filterst...
GPT4-Turbo hat eine Kontextlänge von 128k Token. Davon geht viel für die
System Instructions und deine Anweisungen drauf.
Bedeutet: Im Endeffekt musst du froh sein, wenn du Texte mit 70000 Token
zusammenfassen lassen kannst, ohne dass das LLM am Ende vom Text den
Anfang schon wieder "vergessen" hat.
Das... also... der aktuelle Kontext hat da "nur" 128k Token, was schon eine ganze Menge ist. Dieser aktuelle Kontext wird aber lediglich dazu verwendet, um die Korrekturen an den Gewichten vorzunehmen, in denen die Informationen stecken. Diese Gewichte wurden aus den vorherigen Kontexten errechnet, und enthalten also eine Abbildung von deren Informationen.
Aber all das betrifft ja nur LLMs, und... sagen wir so: was sollte man denn damit bei Logdat(ei)en anfangen, plausible Logeinträge vorhersagen? Mir fällt irgendwie kein plausibler Anwendungsfall für ein LLMs bei Logdateien ein, hast Du da so ganz grundsätzlich eine Idee, wenn ja, wie sähe die aus, und welche Rolle würde der aktuelle Kontext dabei spielen?