Ich möchte die Datei `C:\Windows\Logs\CBS\CBS.log` nicht selbst durchlesen. ChatGPT sagt > Es scheint, dass ich momentan keine fortgeschrittene Datenanalyse > durchführen kann. Bitte versuche es später noch einmal Gibt es eine kostenlose Alternative zu ChatGPT die das kann?
:
Bearbeitet durch User
In der Zeit, in der du versuchst, ein Tool zu finden, hättest du sie schon längst manuell durchgeschaut.
Alexander schrieb: > Ich möchte die Datei `C:\Windows\Logs\CBS\CBS.log` nicht selbst > durchlesen. Dann steht offensichtlich auch nichts für dich Interessantes drin. -> Problem gelöst :)
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. Also letztendlich nicht viel neues.
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...
:
Bearbeitet durch User
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.
Alexander schrieb: > wo ist KI wenn man sie mal braucht 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?
Frank E. schrieb: > Installiere dir doch eine eigene lokale KI Und die macht dann die intelligente Arbeit (log Daten auswerten) von ganz alleine, oder wie muss man sich das vorstellen?
Monk schrieb: > Frank E. schrieb: >> Installiere dir doch eine eigene lokale KI > > Und die macht dann die intelligente Arbeit (log Daten auswerten) von > ganz alleine, oder wie muss man sich das vorstellen? Die macht das genau so alleine oder nicht alleine wie ChatGPT. Auf den richtigen Prompt (Arbeitsanweisung) kommt es an ... Aber eine lokale KI hat den Vorteil, dass sie immer verfügbar ist (war ja ein Problem des TO) und dass private Daten nicht im Nez herumschwirren.
:
Bearbeitet durch User
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... Εrnst B. schrieb: > 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.
Ein T. schrieb: > 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...
Wenn System File Checker (Sfc.exe) nicht helfen kann, steht das irgendwo im cbs.log. https://learn.microsoft.com/de-de/troubleshoot/windows-server/installing-updates-features-roles/cbs-log-file-record-entries-not-repaired-run-sfc Ob der Fragesteller diese Fehler dann beheben kann, wenn KI ihm den Eintrag zeigt, habe ich noch Zweifel. Wahrscheinlich hat er 3x schnelller ein Backup eingespielt.
:
Bearbeitet durch User
Ob S. schrieb: > 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 ...
Ob S. schrieb: > Ein T. schrieb: >> 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.
Jens G. schrieb: > Ob S. schrieb: >> 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.
Rene K. schrieb: > 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. Rene K. schrieb: > 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. Wo Du recht hast, hast Du recht. Genauso isses.
In der Datei wird aller möglicher Unfung auch abgelegt und wächst. https://learn.microsoft.com/de-de/troubleshoot/windows-server/installing-updates-features-roles/cbs-log-file-record-entries-not-repaired-run-sfc https://www.doktorlatte.de/windows-cbs-log-datei-waechst-unaufhaltsam-cbs-log-dateien-loeschen-und-freien-speicherplatz-schaffen/ Prüft erst mal, ob das Fehlerbild mit dem unteren Link in Verbindung stehen könnte.
Dieter D. schrieb: > Prüft erst mal, ob das Fehlerbild mit dem unteren Link in Verbindung > stehen könnte. Welches Fehlerbild?
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.
:
Bearbeitet durch User
Lu schrieb: > 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.
Rene K. schrieb: > 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. [1] https://vector.dev/ [2] https://www.elastic.co/guide/en/beats/journalbeat/current/journalbeat-installation-configuration.html [3] https://www.elastic.co/de/beats/filebeat > 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.
Ein T. schrieb: > 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.
Ein T. schrieb: > Warum sollte man denn bei der Loganalyse auf leistungsfähige Werkzeuge > und Helfer wie grep(1) und Co verzichten? Diese "leistungsfähigen" Werkzeuge nützen gar nix, solange man nicht weiß, wonach man überhaupt suchen soll ...
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.
:
Bearbeitet durch User
> Sagst Du der KI wenigstens noch, warum sie das machen soll, oder > behältst Du auch da Dein Problem für Dich? Die Jugend von heute ist soooo überbehütet, die kennt keine Probleme ... > Irgendeinen Grund wirst Du ja haben, in dieser Datei nach /irgendwas/ > suchen zu wollen, einfach nur so, weil Freitag ist, Es gibt Berichte, wonach KI zum hacken benutzt wird. Sach doch der KI, sie soll ein secutity hole im log finden. https://www.security-insider.de/chatgpt-analyse-protokolle-firewall-logs-a-3d18cc58ae05959b390040d197f34c59/
Harald K. schrieb: > Ein T. schrieb: >> 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. :-)
Jens G. schrieb: > Ein T. schrieb: >> Warum sollte man denn bei der Loganalyse auf leistungsfähige Werkzeuge >> und Helfer wie grep(1) und Co verzichten? > > Diese "leistungsfähigen" Werkzeuge nützen gar nix, solange man nicht > weiß, wonach man überhaupt suchen soll ... Herzlichen Dank für Deinen Hinweis.. auf den ich allerdings in diesem Thread schon mindestens dreimal hingewiesen habe. Nichtsdestotrotz kann es, wie ich auch schon geschrieben hatte, mitunter sehr hilfreich sein, das Problem andersherum anzugehen: mit
1 | 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.
Ein T. schrieb: > 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)
Harald K. schrieb: > 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... Alexander schrieb: > Ich wollte wissen welche Systemdateien vom DLLCache oder wie auch immer > Systemschutz nicht wiederhergestellt werden können. Das wiederum ist per grep&co ganz leicht zu finden. Und: Die KI kann dir die Kommandozeile dazu sogar vorkauen. Also: Nutz die KI um die Werkzeuge zu bauen die du brauchst um dein Problem zu lösen.
Bis jetzt war ChatGPT nur nützlich bei Übersetzungen oder irgendwelchen Filmfragen; wobei auch da nur, wenn der Film sehr bekannt ist.
Alexander schrieb: > Gibt es eine kostenlose Alternative zu ChatGPT die das kann? Mal die KI fragen welche KI man das fragen kann.
Alexander schrieb: > 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.
Alexander schrieb: > 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. [1] https://www.amazon.de/Praxiseinstieg-Machine-Learning-Scikit-Learn-TensorFlow/dp/3960092121 [2] https://www.nltk.org/ [3] https://spacy.io/
Ein T. schrieb: > Aufgrund des KI-Hypes der letzten Jahre scheinen manche Menschen zu > glauben, daß die KI uns die Arbeit und das Denken abnehmen könnten. Jaa! Ich bitte darum! Wozu soll die sonst gut sein..
Alexander schrieb: > Jaa! 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.
Ein T. schrieb: > 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.
Johnny B. schrieb: > 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.
Εrnst B. schrieb: > Wenn der TE sich aber mit LLM-Hilfe eine passende > "findstr/grep"-Kommandozeile bauen lässt, hat er das Problem nicht. Dazu brauche ich aber keine KI.
Alexander schrieb: > Dazu brauche ich aber keine KI. Warum willst du dann unbedingt eine KI verwenden? Um dein Problem möglichst langsam, teuer und schlecht zu lösen? Seltsames Optimierungsziel...
Weil ich keine Lust habe die Logdatei selbst zu durchsuchen, hab ich doch geschrieben..
Michael schrieb: > 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.
Alexander schrieb: > 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?
Wo ist denn ein grep bitte eine Automatisation? Hast Du überhaupt schon mal grep benutzt? Ich will überhaupt keinen Aufwand betreiben, ich wollte nur wissen ob wer ne alternative Webseite kennt zu chat.openai.com die kostenlos ist.
:
Bearbeitet durch User
Alexander schrieb: > Wo ist denn ein grep bitte eine Automatisation? Ach. Wenn du in einem 100Mio-Zeilen Logfile was suchst, kann dein Grep ein Suchmuster nicht automatisch auf alle Zeilen anwenden? Hast du deinen Endlospapier-Nadeldrucker "grep" getauft, und sitzt mit dem Textmarker vor dem Ausdruck, wenn das bei dir nicht automatisch geht? Alexander schrieb: > Ich will überhaupt keinen Aufwand betreiben Warum bestehst du dann so vehement darauf, dass du gerne mehr Aufwand betreiben willst? Alexander schrieb: > ich wollte nur wissen ob > wer ne alternative Webseite kennt zu chat.openai.com die kostenlos ist. Wurde dir genannt. Warum du dann aber diese komische Rahmenstory vom CBS.log dazuerfunden hast, erschließt sich mir nicht.
> Ich will überhaupt keinen Aufwand betreiben, ich wollte nur wissen ob > wer ne alternative Webseite kennt zu chat.openai.com die kostenlos ist. Konnt doch mal raus aus deiner virtuellen AI/Foren-Welt und sprich face2face mit einem Menschen über Deine (Computer-) Probleme.
Um die geht es aber hier nicht. 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?
:
Bearbeitet durch User
> 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 ? "
:
Bearbeitet durch User
Alexander schrieb: > Dazu waren vier Iterationen meines Gehirns notwendig. Und warum hast du keine KI genutzt um dein armes Gehirn zu entlasten? Ganz kostenlos und ohne Anmeldung:
1 | # Pfad zur CBS.log-Datei |
2 | $logPath = "C:\Windows\Logs\CBS\CBS.log" |
3 | |
4 | # Funktion zum Durchsuchen der CBS.log-Datei nach nicht reparierbaren DLL-Dateien |
5 | function Get-UnrepairableDLLs { |
6 | param ( |
7 | [string]$logPath |
8 | ) |
9 | $pattern = "\[SR\] Cannot repair member file \[l:\d+ \{[^\}]+\}\]\"([^\"]+\.dll)\"" |
10 | $content = Get-Content -Path $logPath |
11 | $dlls = @() |
12 | foreach ($line in $content) { |
13 | if ($line -match $pattern) { |
14 | $dlls += $matches[1] |
15 | } |
16 | } |
17 | return $dlls |
18 | } |
19 | |
20 | # Funktion zum Durchführen einer Websuche nach Reparaturoptionen |
21 | function Search-WebForRepairOptions { |
22 | param ( |
23 | [string]$dll |
24 | ) |
25 | $searchQuery = "Reparaturoptionen für $dll" |
26 | Start-Process "https://www.bing.com/search?q=$searchQuery" |
27 | } |
28 | |
29 | # Hauptskript |
30 | $dlls = Get-UnrepairableDLLs -logPath $logPath |
31 | foreach ($dll in $dlls) { |
32 | Search-WebForRepairOptions -dll $dll |
33 | } |
... Soweit der Vorschlag von Copilot zur Lösung deines Problems. (Deswegen auch "Bing" statt "Google"...) Alexander schrieb: > Die KI soll die Arbeit machen, nicht ich. Jetzt verstanden? Tut sie. Sofort und kostenlos. Du musst nur die richtigen Fragen stellen, und verstehen wo die Grenzen von so einem LLM sind.
:
Bearbeitet durch User
Ich wollte kein PowerShell Script. Ich habe nicht mal PowerShell. Ich wollte eine Analyse der Datei, keine Hilfe bei der Analyse der Datei.
Alexander schrieb: > 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? Alexander schrieb: > 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...
Wie gesagt ich brauche keine Hilfe dabei es selbst zu machen. Da kann ich auch dankend auf KI verzichten.
Alexander schrieb: > Da kann > ich auch dankend auf KI verzichten. Solltest du auch. Besser wäre: Minimale Grundkenntnisse über LLMs aneignen, damit du von vornherein garnicht erst auf so eine abstruse Idee kommst.
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.
Alexander schrieb: > Der Gedanke lag nahe 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.
Jetzt wird's aber absurd. Wo bin ich wütend? :D 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.
Michael schrieb: > Alexander schrieb: >> Der Gedanke lag nahe > > Für niemanden der weiß was KI kann und was nicht. Auch Laien sollten leicht verstehen, daß dieser Gedanke völlig abstrus ist.
Dass ChatGPT Texte zusammenfassen kann? Ja, das ist völlig abstrus!!11
Alexander schrieb: > 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. https://learn.microsoft.com/de-de/troubleshoot/windows-client/installing-updates-features-roles/analyze-sfc-program-log-file-entries
:
Bearbeitet durch User
Klar, cryptischer Quellcode in jeder x-beliebigen Programmiersprache ist kein Hindernis, aber ein Logfile im Klartext ist kein lesbarer Text mehr ;)
Alexander schrieb: > Klar, cryptischer Quellcode in jeder x-beliebigen Programmiersprache Wenn für Dich Quellcode "ein Buch mit Sieben Siegeln" aka "cryptisch" ist, dann biste für mikrocontroller.net auf ziemlichen DAU-Level. https://de.wikipedia.org/wiki/D%C3%BCmmster_anzunehmender_User 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.
:
Bearbeitet durch User
Alexander schrieb: > Dass ChatGPT Texte zusammenfassen kann? Ja, das ist völlig abstrus!!11 Never argue with an idiot. They will drag you down to their level and beat you with experience. (Mark Twain)
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. Bradward B. schrieb: > Wenn für Dich Quellcode "ein Buch mit Sieben Siegeln" aka "cryptisch" > ist, dann biste für mikrocontroller.net auf ziemlichen DAU-Level. dann bin ich ja hier gut aufgehoben Beitrag "Re: Buttons an ESP32 entstören"
Alexander schrieb: > 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...
Ich hab mich mit Notepad++ auf die gute alte von Error zu Error durchgehangelt und die Probleme Stück für Stück behoben. ChatGPT ist erst morgen Mittag wieder bereit eine Logdatei zu lesen.
Εrnst B. schrieb: > 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?
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.