Mittlerweile gibt es ungefähr eine Zilion Programmier- und Agentenorchestratoren um verschiedene KI-Modelle zu bedienen. Es ist ziemlich schwierig, in dem ganzen Wust das richtige zu finden und auszuwählen, da ja im Moment noch alles im Fluss ist.
Gerade eben habe ich wieder 2 interessante entdeckt, was haltet ihr von denen?
Ich bin zu lange im Job, als dass ich auf die Idee kommen würde, meine Zeit mit solchen frisch geschlüpften Fliegen zu verschwenden. Ob das Eintagsfliegen sind, sieht man ja erst morgen.
Bei mir Claude Code in VSCode, zB mit Sonnet oder Opus. Absolut irre was da geht. Hab vorher über 30 Jahre klassisch Software entwickelt, die Erfahrung hilft, die KI in die gewünschte Richtung zu dirigieren.
Nachteile? Anthropic verdient. Code läuft durch deren Server. Abhängigkeit steigt. Und theoretisch kann er böse Skripte schreiben und ausführen.
Aktuell überwiegen für mich die Vorteile. Ideen in der Art "könnte man mal machen aber das ist sehr aufwändig" lassen sich nun ruckzuck umsetzen.
Bei mir Claude Code in VSCode, zB mit Sonnet oder Opus. Absolut irre was
da geht. Hab vorher über 30 Jahre klassisch Software entwickelt, die
Erfahrung hilft, die KI in die gewünschte Richtung zu dirigieren.
Mein Ziel ist, eine lokale KI zu verwenden. Im Moment habe ich https://pi.dev/ auf einem Raspi installiert, der mit einem qwen3.6 auf der DGX-Spark kommuniziert.
Immerhin hat es das Ding geschafft, eine Verbindung zu meinem Board hier herzustellen: Beitrag "altes Phytec MCB-51 Monitor/Basic Befehle?"
Es hatte aber Probleme zu verstehen, dass man nicht in den BASIC Modus gehen darf bevor man nicht "conf 0" abgesetzt hat, um die Print-Ausgabe auf die serielle Schnittstelle umzulenken.
Ich nutze meist Opencode. Bislang reichen mir die integrierten kostenlosen Modelle. Testweise nutze ich auch lokal Qwen3.6 27B, das ist aber doch recht langsam.
Ich mache aber auch nicht viel damit.
Ich hab vergleichsweise mal Pi mit dem lokalen Modell getestet. Irgendwie ist das für mich total unbrauchbar. Tool-calls schlagen ständig fehlt und es kommt nichts gescheites dabei rum. Mit nem fetteren Modell ist das vielleicht anders.
Wenn ich das richtig sehe, hat sich irgendwann der System-Prompt von Opencode von 10k auf ~8k tokens reduziert. Nur ~1k wie bei Pi zu haben, wäre schon nice. Das war der Hauptgrund, dass ich Pi probiert habe.
Im Moment habe ich
https://pi.dev/ auf einem Raspi installiert, der mit einem qwen3.6
auf der DGX-Spark kommuniziert.
Also ich hab da auch schon mal kurz drueber nachgedacht. SEHR KURZ. Weil auf einem normalen ueblichen StandardPC liegen die Antwortzeiten schon im Bereich 30s bis Minuten wenn das im Ram liegt.
Da willst du eigentlich sehr schnell eine coole Grafikkarte sonst verliert man den Spass dran.
Ich habe im letzten Jahr etwas mit RAG experimentiert. Die Ergebnisse
waren enttäuschend. Das liegt in erster Linie an der Vektorsuche.
Bei ganz kleinen Datenbanken mit wenigen Dokumenten oder bei
Datenbanken, die nur sehr unterschiedliche Dokumente enthalten, mag das
noch gehen. Wenn man aber z.B. Datenblätter per KI durchsuchen will,
ähneln sich die Inhalte dieser Dokumente sehr. Die reine Vektorsuche
findet dann die Chunks, die am besten zur Frage passen. Der Chunk
enthält aber keine Metadaten - d.h. die Vektorsuche berücksichtigt z.B.
das Bauteil, das ja nicht überall im Text neu erwähnt wird, nicht. Man
erhält also in vielen Fällen eine Antwort, die zwar zum Inhalt der Frage
passt, sich aber nicht auf das gewünschte Bauteil bezieht.
In dem verlinkten Artikel steht ganz unten ein Absatz, der mit "Der
nächste logische Ausbau" beginnt. Die Punkte, die darin erwähnt sind,
scheinen für eine nutzbare Anwendung unerlässlich zu sein. Und die sind
wesentlich aufwändiger als die Skripte für das einfache RAG.
Darin werden auch die Schwächen des LLM Wikis durchleuchtet. Für eine
Wissensdatenbank z.B. mit Datenblättern ist das m.E. derzeit nicht
geeignet.
Ich habe es auch noch nicht ausprobiert. Die im Video aufgezählten Schwächen wie Ungenauigkeiten durch Kompression lassen sich vielleicht ja durch Links im Wiki auf die echten Dokumente realisieren, die man bei Bedarf nach Genauigkeit dann aufruft und analysieren lässt.
Es gibt verschiedene Arten von Agentensystemen. Einerseits die Codingsysteme wie Claude-Code und ähnlich, andererseits aber die freien Agenten, die alles mögliche auf dem Computer installieren und kreieren können wie ClawBot oder HermesAgent.
Im Moment probiere ich gerade HermesAgent auf RasPi mit qwen3.6:35b auf externem Rechner. Grundsätzlich tut es schon mal, kämpft aber noch mit Microphon und Lautsprecher, damit ich mit dem Ding reden kann.
Hier eine Liste möglicher Agentensystemen, vielleicht kennt ja noch jemand andere:
Ich habe im letzten Jahr etwas mit RAG experimentiert. Die Ergebnisse
waren enttäuschend. Das liegt in erster Linie an der Vektorsuche.
Bei ganz kleinen Datenbanken mit wenigen Dokumenten oder bei
Datenbanken, die nur sehr unterschiedliche Dokumente enthalten, mag das
noch gehen. Wenn man aber z.B. Datenblätter per KI durchsuchen will,
ähneln sich die Inhalte dieser Dokumente sehr. Die reine Vektorsuche
findet dann die Chunks, die am besten zur Frage passen. Der Chunk
enthält aber keine Metadaten - d.h. die Vektorsuche berücksichtigt z.B.
das Bauteil, das ja nicht überall im Text neu erwähnt wird, nicht.
Vielleicht wäre im diesem Fall eine klassische Volltext-Suchmaschine wie
OpenSearch besser geeignet. Die kann auch Vektorsuche, bei Bedarf auch
kombiniert mit klassischen, bei Bedarf auch unscharfen Suchlgorithmen
über indizierte Daten und Tfidf zur Gewichtung von Worten anhand ihrer
Häufigkeiten. Bei Elastic- und OpenSearch lassen sich die PDFs auch
gleich über ein Plugin mit Apache Tika (iirc) einlesen.
Vielleicht geht sowas ja schon mit einem einfachen "tool call" auf der lokalen Festplatte die man nach vollständigen, abgelegten Datenblättern durchsucht.
Die reine Vektorsuche
findet dann die Chunks, die am besten zur Frage passen. Der Chunk
enthält aber keine Metadaten
Du kannst beim indizieren die Metadaten hinzufügen, als
"title","summary", "metadata":{"chip":"NE555","type":"datasheet"}...
Dann instruierst deine KI, dass bei Suche nach Datenblättern das
"chip"-Feld möglichst mit in die Suchanfrage soll, oder bei den
Antwort-Chunks kontrolliert werden soll, ob die Antwort auch zum
richtigen Datenblatt gehört.
Ist halt keine schlüsselfertige Lösung, wo du einfach einfach einen
Ordner an PDFs reinwerfen kannst. Aber jetzt auch nicht so der
Riesen-Aufwand ein kleines LLM in den Import-Prozess zu hängen, was dir
für jedes PDF einmalig die Metadaten im passenden Format extrahiert.
Mittlerweile glaube ich fast, dass man am besten sein eigens LLM-Harness schreibt, das diese Funktionen dann ausführt.
Ich habe im letzten Jahr etwas mit RAG experimentiert. Die Ergebnisse
waren enttäuschend. Das liegt in erster Linie an der Vektorsuche.
Bei ganz kleinen Datenbanken mit wenigen Dokumenten oder bei
Datenbanken, die nur sehr unterschiedliche Dokumente enthalten, mag das
noch gehen.
Mit wenigen Datenblättern wird das aber besonders schwierig, denn dann fehlt es an Daten für das Training von passenen Word Embeddings. Und genau die sind ja notwendig, um Ähnlichkeiten bei den Bedeutungen von Worten zu finden.
Wenn man aber z.B. Datenblätter per KI durchsuchen will,
ähneln sich die Inhalte dieser Dokumente sehr. Die reine Vektorsuche
findet dann die Chunks, die am besten zur Frage passen. Der Chunk
enthält aber keine Metadaten - d.h. die Vektorsuche berücksichtigt z.B.
das Bauteil, das ja nicht überall im Text neu erwähnt wird, nicht.
Vielleicht wäre im diesem Fall eine klassische Volltext-Suchmaschine wie
OpenSearch besser geeignet. Die kann auch Vektorsuche, bei Bedarf auch
kombiniert mit klassischen, bei Bedarf auch unscharfen Suchlgorithmen
über indizierte Daten und Tfidf zur Gewichtung von Worten anhand ihrer
Häufigkeiten. Bei Elastic- und OpenSearch lassen sich die PDFs auch
gleich über ein Plugin mit Apache Tika (iirc) einlesen.
Vielleicht geht sowas ja schon mit einem einfachen "tool call" auf der
lokalen Festplatte die man nach vollständigen, abgelegten Datenblättern
durchsucht.
Das mag für wenige Dokumente funktionieren, aber bei vielen Datenblättern wird sowas kein Vergnügen bereiten. Erstens, weil die handelsüblichen Tools jeweils die kompletten Dateien lesen und scannen müssen, das dürfte nicht allzu performant und insbesondere auch nicht ressourcenschonend werden, und womöglich viele Falschpositive provozieren. Zweitens aber auch weil sich in die lokalen Tools nur mit erheblichem Aufwand Funktionen wie ein anständiges Scoring (mit der Gewichtung von Ergebnisqualitäten), unscharfe Suche, Word Embeddings für die Vektorsuche, oder kombinierte Queries mit Gewichten einbauen lassen.
Klar, irgendwie könnte all das irgendwie gehen, wenn man einen entsprechenden Aufwand betreibt -- aber warum sollte man sowas tun, wenn all diese Funktionen bei einer Volltextsuchmaschine bereits zum Standardumfang gehören? Ja, OpenSearch und Elasticsearch sind ziemliche Monster, keine Frage, aber sie haben dafür eben auch sehr viel zu bieten. Und dabei sind sie ultraschnell, locker Faktor 10 bis Faktor 100 schneller als klassische SQL-Datenbanken und mit Sicherheit noch mehr im Vergleich mit den klassischen Tools auf der Kommandozeile wie grep(1), find(1), locate(1) und Co.
Ja, OpenSearch und Elasticsearch sind ziemliche
Monster, keine Frage, aber sie haben dafür eben auch sehr viel zu
bieten. Und dabei sind sie ultraschnell, locker Faktor 10 bis Faktor 100
schneller als klassische SQL-Datenbanken und mit Sicherheit noch mehr im
Vergleich mit den klassischen Tools auf der Kommandozeile wie grep(1),
find(1), locate(1) und Co.
Beides sind in der Tat zwei sehr gute Suchmaschinen, aber wie die meisten anderen Lösungen muss ein Agent auch hier iterativ sich an die Ergebnisse herantasten weil er schlichtweg ausprobieren muss, mit welchen Suchmustern er Ergebnisse bekommt die er dann validieren muss. Kostet sehr viele Loops & Toolcalls. Ob die nackte Suche Faktor 100 schneller ist spielt dann keine Rolle mehr, die Zeit & Tokens werden in der ReAct Loop verbraten.
Und zwei Tage später beginnt dasselbe Spiel von vorne weil euer Agent nicht lernen kann...
Ja, OpenSearch und Elasticsearch sind ziemliche
Monster, keine Frage, aber sie haben dafür eben auch sehr viel zu
bieten. Und dabei sind sie ultraschnell, locker Faktor 10 bis Faktor 100
schneller als klassische SQL-Datenbanken und mit Sicherheit noch mehr im
Vergleich mit den klassischen Tools auf der Kommandozeile wie grep(1),
find(1), locate(1) und Co.
Beides sind in der Tat zwei sehr gute Suchmaschinen, aber wie die
meisten anderen Lösungen muss ein Agent auch hier iterativ sich an die
Ergebnisse herantasten weil er schlichtweg ausprobieren muss, mit
welchen Suchmustern er Ergebnisse bekommt die er dann validieren muss.
Kostet sehr viele Loops & Toolcalls. Ob die nackte Suche Faktor 100
schneller ist spielt dann keine Rolle mehr, die Zeit & Tokens werden in
der ReAct Loop verbraten.
Bei anderen Lösungen müßten verschiedene Suchmuster ausprobiert werden, mit Open- und Elasticsearch hingegen nur wenige -- und zudem werden Ergebnisse dort nach Trefferqualität ausgegeben, so daß die Wahrscheinlichkeit, ohne weiteres Zutun in wenigen Schritten auf gute Ergebnisse zu kommen, deutlich höher sein dürfte. Letztlich müssen wir nicht mit dem Idealfall vergleichen, sondern mit den möglichen Alternativen, und die sehen aus meiner Perspektive allesamt sehr viel aufwändiger aus.
Bei anderen Lösungen müßten verschiedene Suchmuster ausprobiert werden,
mit Open- und Elasticsearch hingegen nur wenige -- und zudem werden
Ergebnisse dort nach Trefferqualität ausgegeben, so daß die
Wahrscheinlichkeit, ohne weiteres Zutun in wenigen Schritten auf gute
Ergebnisse zu kommen, deutlich höher sein dürfte. Letztlich müssen wir
nicht mit dem Idealfall vergleichen, sondern mit den möglichen
Alternativen, und die sehen aus meiner Perspektive allesamt sehr viel
aufwändiger aus.
Reranking BM25/Sparse/Dense ist in allen gängigen Lösungen mittlerweile Standard. Wo aber z.B. auch OS/ES scheitert sind so Banalitäten wie Einheiten/Skalen, z.B. mm/inch oder nA/mA wenn es um parametrische Suche geht. Auch Informationen aus eingebetteten Diagrammen gehen schnell verloren. Man kommt also auch hier nicht um einen deutlich verbesserten Ingest herum.
Wenn es simpel sein soll würde ich eher zu Cognee mit Custom Ingest raten.
