SingleVector-Retrieval (qwen3-Embedding) VS MultiVector-Retrieval (ColBERTv2)

[WoisthierdasKlo]

Moin,

kurzes Disclaimer vorweg: Ich bin ein Laie und bitte berücksichtigt das bei euren Antworten und haut mir nicht zu viele Fachbegriffe auf einmal um die Ohren, das wäre sehr nett. Ich muss ChatGPT schon immer darauf hinweisen, explizit zu erklären, was es genau meint... 🙈

Ich habe die letzte Woche sehr viel Zeit mit ChatGPT Plus, als mein Programmier-Sklave, und einigen lokalen KI-Modellen verbracht. Meine RTX 2060 Super konnte einigermaßen sinnvoll bis zu qwen3.5:27b, also einem LLM-Chatmodell mit 27 Mrd. Parametern, umgehen. Einen Benchmark, der Ambiguität in Frage-Items abfragte, konnte zudem erst das 27b-Modell zu 100% korrekt beantworten, 14b, 8b, 4b usw. versagten alle. Ohne OT zu werden könnt ihr hierzu gerne etwas schreiben, würd mich mal interessieren, was ihr dazu denkt bzw. was ihr so an Erfahrungen gemacht habt.

Zum Thema: Ich habe auch LLMs heruntergeladen, die nicht zum Chatten geeignet sind, sondern zum Embedding. Insbesondere qwen3:0.6b-embedder und qwen3:4b-embedder habe ich dann genutzt. Die 0.6b-Variante lief bei mir bedeutend schneller und schien die selbe Qualität zu haben. Gearbeitet habe ich dann mit dem 0.6b-Embedding an einem Ordner mit ca. 360 deutschsprachigen OCR-ten PDFs. Die queries habe ich dann mit 4b embedden lassen. Die Suche lief innerhalb weniger Sekunden. Das Embedden hat schon ein paar Stunden gedauert. (Bei der 4b-Variante eher über 10 Stunden...)

Anschließend habe ich, nach ChatGPTs Empfehlungen, noch ein paar reranker installiert und diese über die Top-80-Ergebnisse laufen lassen, was mit dem kleinsten Modell ca. 30 Sekunden gedauert hat, mit dem größten deutlich länger und ich irgendwie unnötig fand, weil es ja keine neuen Ergebnisse hervorbrachte, sondern die vom Query-Embedder/FAISS gefundenen lediglich umsortierte.

Jedoch fiel mir auf, dass die Suche schon eher nach Semantik als nach gesamter abstrakter Satzbedeutung geht. Wenn ich nach einem Inhalt in den PDFs suche, wo ich durch einigermaßen synonyme Wörter umschreiben kann, worum es geht, findet mein Programm die Textstelle gut. Aber wenn ich dann ein Wort verwende, z.B. "Menschheitsentwicklung", weil ich nach einem Ereignis "in der Menschheitsentwicklung" suche, dann hängt er sich sehr fest am Wort "Menschheitsentwicklung" und zeigt mir fast nur Ergebnisse an, wo exakt das Wort "Menschheitsentwicklung" vorkommt.

Daher dachte ich, ich brauche ein Verfahren, das noch mehr die abstrakte Bedeutung meiner query erfasst. ChatGPT empfahl mir daher das ColBERTv2-Verfahren. Doch dieses sei um Größenordnungen aufwendiger, da nicht ein Vektor pro Chunk und ein Vektor pro query erzeugt würde, sondern mehrere Vektoren pro Token und mehrere Vektoren pro query.

Ich stellte dann aber überraschenderweise fest, dass ColBERTv2 vieeel schneller ging. Die Indexierung dauerte nicht einige Stunden, sondern unter 30 Minuten. Der Index-Ordner war, wie zu erwarten (da eine besonders schlaue Kompression der Vektoren verwendet wird), ähnlich groß TROTZ Größenordnungen mehr an Vektoren (ca. 2 GB statt ca. 1.7 bzw 3 GB bei 0.6b bzw 4b) und die Suche ging auch total flott. Allerdings konnte ich es noch nicht so richtig gut am selben Ordner testen, da ColBERTv2 am besten mit dem Stanford-Modell funktioniert und dieses ist nur auf englischer Sprache trainiert. Dagegen ist das Jina-Mehrsprachen-Modell sehr schlecht, meiner Erfahrung nach.

ChatGPT empfahl mir, noch eine LLM zu nutzen, um zu prüfen, ob die Ergebnisse WIRKLICH einen inneren Sinnzusammenhang mit dem Suchquery haben.

Frage an euch:

• Habt ihr Erfahrungen mit LLMs und insbesondere SingleVector und MultiVector gemacht?
• Was für Anwendungsgebiete gibt es außerhalb des Durchsuchens großer Dokumentenordner nach Textstellen?
• Was ist eure Meinung zu rerankern? Unnötig oder nützlich?
• Wie erklärt ihr euch, dass die Indexerstellung bei ColBERTv2 sooo viel schneller ging als bei SingleVector, obwohl es angeblich viel rechenaufwendiger ist?
• Haltet ihr es beim aktuellen Stand für möglich, dass die abstrakte Bedeutung im Such-Query wirklich "erfasst" werden kann?
• Was haltet ihr von ChatGPTs Vorschlag, eine LLM dazu zu bauen, auch ausgehend von meiner initialen Erzählung oben? Ich könnte mir vorstellen, dass meine Grafikkarte das nicht (in sinnvoller Zeit, d.h. unter 2 Minuten) packt, 80 Absätze mit 1 Suchquery zu vergleichen... hängt natürlich vom Modell ab, aber es scheint ja mindestens das 27b-Modell nötig zu sein....

Ich bin gespannt.... :-)

 

[chr1zZo]

Das ist eben das Problem mit den kleinen Modellen. Ein Pro/Max Abo von entsprechenden Modellen hätte deine Arbeit schon Easy erledigt. Für LLM Modelle mit mehr Speed und korrekter Logik bedarf es eben mehr Hardware Power.

 

[WoisthierdasKlo]

Welches Problem genau sprichst du an? Dass das Programm nicht so gut mit der wirklichen Satzbedeutung meines Suchquerys klar kommt? Oder redest du von meinem ChatGPT Plus?

 

[AAS]

Hi, cooles Experiment — du bist für einen "Laien" eigentlich schon ziemlich weit. Ich versuch's ohne Fachchinesisch und gehe deine Fragen der Reihe nach durch. Vorweg aber das, was dir vermutlich am meisten bringt:

Das Wichtigste zuerst: Dokumente und Suchanfrage MÜSSEN mit demselben Modell embedded werden. Du schreibst, du hast die PDFs mit qwen3:0.6b und die Queries mit 4b embedden lassen. Falls das wörtlich gemeint ist, ist das der wahrscheinlichste Grund für deine "komischen" Ergebnisse. Ein Embedding-Modell legt jeden Text als Punkt in einen Vektorraum. Zwei verschiedene Modelle bauen zwei verschiedene, nicht vergleichbare Räume — sie haben sogar unterschiedlich viele Dimensionen (0.6B = 1024, 4B = 2560). FAISS kann Vektoren unterschiedlicher Länge gar nicht vergleichen; wenn es trotzdem "lief", ist irgendwo still etwas schiefgegangen. Faustregel: gleiches Modell für Index UND Query. Das 0.6B ist übrigens überraschend gut — ruhig für beides nehmen, spart dir die 10 Stunden.

Warum ColBERTv2 beim Indexieren so viel schneller war (Frage 4): "Aufwendiger" ist ColBERT beim Suchen/Scoren, nicht beim Indexieren. Der Flaschenhals beim Indexieren ist fast immer, wie groß das Embedding-Modell ist — also wie lange ein Textstück durch das neuronale Netz braucht. Dein Single-Vector lief mit einem 0,6-Mrd.- bzw. 4-Mrd.-Parameter-Modell. ColBERTv2 benutzt im Kern ein winziges BERT-base (~110 Mio. Parameter) und macht pro Token nur einen 128-dimensionalen Mini-Vektor. Das ColBERT-Modell ist also ein Vielfaches kleiner, der Durchlauf pro PDF-Stück drastisch schneller. Dass viel mehr Vektoren entstehen (einer pro Token statt einer pro Chunk), wird durch das kleine Modell und eine clevere Kompression (Residual-/Centroid-Kompression, ~1-2 Bit pro Dimension) aufgefangen. Deshalb: viel mehr Vektoren, aber ähnlich große Index-Datei und trotzdem flotte Suche. Also nicht "Multi-Vector ist magisch schneller", sondern "ein 110M-Modell ist eben viel schneller als ein 4B-Modell".

Dein "Menschheitsentwicklung"-Problem ist eigentlich der Kern. Zwei Dinge helfen, und beide haben nichts mit ColBERT zu tun (ColBERT ist auf Wortebene sogar eher präziser, nicht abstrakter): (1) Qwen3-Embedding ist instruction-aware. Du sollst der Query einen kurzen Auftrag voranstellen, z. B. "Instruct: Finde Textstellen, die ein Ereignis in der Menschheitsentwicklung beschreiben". Das schiebt das Modell weg vom reinen Stichwort-Matching hin zur Bedeutung. Viele lokale Setups vergessen diesen Instruktions-Teil, dann klebt das Modell am seltenen Wort. (2) Query-Umschreibung / HyDE: Lass ein kleines LLM aus deiner Frage erst eine hypothetische Antwort (1-2 Sätze) schreiben und embedde DIE. Klingt schräg, funktioniert aber super, weil die hypothetische Antwort die Bedeutung breiter abbildet als ein einzelnes Stichwort.

Reranker — nützlich oder unnötig (Frage 3)? Nützlich, und deine Beobachtung ist genau richtig: ein Reranker bringt keine neuen Treffer, er sortiert die Top-Kandidaten neu. Genau das ist sein Job. Die erste Suche (Vektoren) ist schnell, aber grob; der Reranker ist ein langsameres, genaueres Modell, das Frage und Textstelle zusammen liest und dadurch die Reihenfolge verbessert. Tipps: Top-80 ist Overkill, Top-20 bis 30 reicht meist und ist schneller. Und nimm für Deutsch einen mehrsprachigen Reranker (z. B. bge-reranker-v2-m3 oder Qwen3-Reranker), kein rein englisches Modell.

Single- vs. Multi-Vector kurz (Frage 1): Single-Vector (ein Vektor pro Chunk) ist schnell, sparsam, super für "grobe Bedeutung", skaliert gut, aber schwächer bei exakten Begriffen / langen Texten. Multi-Vector / ColBERT (viele Vektoren pro Chunk, "late interaction") ist genauer auf Wort-/Token-Ebene, größerer Index (aber komprimierbar), mehr Rechenaufwand beim Suchen. In der Praxis fährt man oft hybrid am besten: klassische Stichwortsuche (BM25) + Vektorsuche + Reranker.

Anwendungsgebiete außerhalb Dokumentensuche (Frage 2): Code-Suche, Duplikat-/Plagiatserkennung, Empfehlungen ("ähnliche finden"), Clustering/Themen-Gruppierung, Klassifikation per Nächste-Nachbarn, Entity-/Adressabgleich, mehrsprachige Suche und das Langzeitgedächtnis von KI-Agenten (RAG). Embeddings sind im Grunde "Ähnlichkeit als Zahl" — überall einsetzbar, wo man fragt "was ist sich ähnlich".

Kann die abstrakte Bedeutung wirklich "erfasst" werden (Frage 5)? Ehrlich: jein. Embeddings fangen statistische Bedeutung sehr gut ein (was in ähnlichen Kontexten vorkommt), aber "verstehen" im menschlichen Sinn tun sie nicht. Mit den richtigen Hebeln (Instruktion + Query-Umschreibung + Reranker + ggf. ein LLM-Check) kommst du aber erstaunlich nah dran.

ChatGPTs Vorschlag, ein LLM als Schluss-Check (Frage 6)? Im Prinzip gute Idee (nennt sich "LLM-as-Judge"), aber nicht so, wie skizziert. 80 Absätze einzeln mit einem 27B-Modell zu prüfen sprengt deine 2060 Super (8 GB) — ein 27B passt da nicht rein, das müsste ständig auslagern und wird quälend langsam. Besser: erst Reranker, dann nur die Top-5 bis 10 prüfen (der Reranker ist im Grunde schon ein schlanker Relevanz-Richter). Und nicht 10 Einzelaufrufe, sondern EIN Prompt: "Hier ist meine Frage und 8 Textstellen, welche beantworten sie wirklich?" Ein 7-8B-Modell (Q4-quantisiert) passt in 8 GB und erledigt das in Sekunden.

Kurz zur Hardware-Beobachtung am Anfang: dass erst das 27B deinen Ambiguitäts-Benchmark zu 100 % schaffte, ist normal — Logik/Disambiguierung skaliert stark mit der Modellgröße. Für den Embedding- und Rerank-Teil brauchst du aber gar keine großen Modelle, da reichen die kleinen locker. Die großen brauchst du nur für den finalen "Versteht-er-die-Frage"-Schritt, und den hältst du klein.

Wie ich genau das produktiv nutze (Programmieren mit KI-Agenten): Bei mir steckt diese Technik nicht in einer Dokumentensuche, sondern als Langzeitgedächtnis einer ganzen Flotte von KI-Coding-Agenten. Ein Orchestrator (Claude Code / Claude Opus) zerlegt eine Programmieraufgabe in kleine Pakete und verteilt sie an spezialisierte Worker-Modelle (lokale + freie + Abo-Modelle); der Orchestrator schreibt selbst keinen Code, er koordiniert nur und führt am Ende zusammen. Alles, was dabei gelernt wird (Fixes, Entscheidungen, Konventionen), wird als kurze Markdown-Notiz gespeichert und automatisch in genau so einen Vektor-Store embedded (bei mir nomic-embed-text bzw. bge-m3, 768/1024 Dim) — das ist der RAG-Teil, denselben den du gerade baust. Die Suche darüber ist hybrid: erst Stichwortsuche (BM25/Volltext), parallel die Vektorsuche, dann ein Reranker — also genau deine Kette, nur eine Stufe weitergedacht. Vor jeder neuen Aufgabe zieht sich jeder Agent automatisch die relevanten Notizen aus dem Store ("context packing"), so fängt keiner bei null an und alle (Claude, lokale oder Cloud-Modelle) haben denselben Wissensstand. Damit das Gedächtnis nicht zumüllt: Salience/Decay (oft genutzte Notizen steigen, alte verblassen) und ein Secret-Scan, der Passwörter/Keys vor dem Speichern blockt. Der Punkt für dich: deine PDF-Suche ist exakt der Kern davon. Instruktions-Prompt + hybride Suche (BM25 + Vektor) + Reranker, und du hast im Kleinen dasselbe, was bei mir die Coding-Agenten "schlau" macht. Fürs Programmieren ist der Nutzen riesig: der Agent findet die passende Code-Stelle oder eine frühere Lösung in Sekunden, statt das halbe Repo neu zu lesen.

Viel Erfolg, klingt nach einem richtig guten Projekt. :-)

 

[WoisthierdasKlo]

Wow, vielen Dank für die ausführliche Antwort!!

Das Wichtigste zuerst: Dokumente und Suchanfrage MÜSSEN mit demselben Modell embedded werden. Du schreibst, du hast die PDFs mit qwen3:0.6b und die Queries mit 4b embedden lassen.

Ups, ich komm da manchmal durcheinander.... ich habe einen 4b-reranker benutzt. Mein Programm meckert rum, wenn ich einen anderen Embedder zum Suchen nutze. Sorry für die Verwirrung.

Das 0.6B ist übrigens überraschend gut — ruhig für beides nehmen, spart dir die 10 Stunden.

Okay, danke für die Bestätigung, dann nehme ich das. :-)

Warum ColBERTv2 beim Indexieren so viel schneller war (Frage 4): "Aufwendiger" ist ColBERT beim Suchen/Scoren, nicht beim Indexieren. Der Flaschenhals beim Indexieren ist fast immer, wie groß das Embedding-Modell ist — also wie lange ein Textstück durch das neuronale Netz braucht. Dein Single-Vector lief mit einem 0,6-Mrd.- bzw. 4-Mrd.-Parameter-Modell. ColBERTv2 benutzt im Kern ein winziges BERT-base (~110 Mio. Parameter) und macht pro Token nur einen 128-dimensionalen Mini-Vektor. Das ColBERT-Modell ist also ein Vielfaches kleiner, der Durchlauf pro PDF-Stück drastisch schneller. Dass viel mehr Vektoren entstehen (einer pro Token statt einer pro Chunk), wird durch das kleine Modell und eine clevere Kompression (Residual-/Centroid-Kompression, ~1-2 Bit pro Dimension) aufgefangen. Deshalb: viel mehr Vektoren, aber ähnlich große Index-Datei und trotzdem flotte Suche. Also nicht "Multi-Vector ist magisch schneller", sondern "ein 110M-Modell ist eben viel schneller als ein 4B-Modell".

Ooooh okay, sehr spannend! Vielen Dank! Besser erklärt als ChatGPT! Ich hab zwar zig Prompts gemacht, dass mir die Technik dahinter erklärt werden soll, aber dass z.B. nur ein kleines Modell dahinter steckt wurde mir nicht gesagt.

(1) Qwen3-Embedding ist instruction-aware. Du sollst der Query einen kurzen Auftrag voranstellen, z. B. "Instruct: Finde Textstellen, die ein Ereignis in der Menschheitsentwicklung beschreiben". Das schiebt das Modell weg vom reinen Stichwort-Matching hin zur Bedeutung. Viele lokale Setups vergessen diesen Instruktions-Teil, dann klebt das Modell am seltenen Wort.

Oh, okay! Ich hatte ChatGPT sogar extra gefragt, wie ich das formulieren soll und bekam diese Antwort:

Eher nicht mit „Ich denke, dass …“ anfangen. Das ist für die Suche meistens Rauschen.

Für die KI-Suche ist am besten:

kurz, inhaltlich, mit den wichtigsten Erinnerungsstücken

Also besser:

Stelle über Tiere, Hund, Mensch
oder:

Ich erinnere mich an eine Stelle mit einem Hund und Bush
als:

Ich denke, dass es da irgendwie um etwas ging, wo vielleicht ein Hund vorkam
Der Unterschied zwischen Frage und Befehl ist weniger wichtig:

Wo finde ich eine Stelle über Tiere?
und

Suche eine Stelle über Tiere.
sind für Embedding ungefähr ähnlich. Aber noch besser ist oft:

Tiere, Hund, Tierreich, Mensch
oder:

Stelle, in der ein Hund erwähnt wird

Faustregel​

Für unscharfe Erinnerung:

Stelle über Tiere und Mensch
Steiner über Tiere, Opfer, Mensch
irgendwas mit Hund und Präsident
Für bekannte Stichwörter:

Hund Bush Bello
Tiere Mensch Opfer
Schiller Goethe Lessing geistige Welt
Für exakte Suche lieber nicht KI-Suche, sondern klassische Suche:

hund UND bush

„Ich denke, dass …“?​

Meist schlechter, weil das Modell dann auch Wörter wie „ich“, „denke“, „dass“, „irgendwie“ mit einbettet. Gute Embedding-Modelle ignorieren manches davon, aber kleine Modelle wie all-minilm können dadurch eher verwässert werden.

Besser:

Hund, Bush, Präsident USA
statt:

Ich denke, dass es da irgendwie um Bush ging und vielleicht um einen Hund.

„Wo finde ich …?“ vs. „Suche mir …“​

Fast egal. Beide sind Suchhüllen. Inhaltlich wichtiger sind die Begriffe danach.

Etwas besser:

Wo geht es um Tiere und Menschen?
als:

Suche mir eine Stelle, wo es um Tiere und Menschen geht.
Noch besser:

Tiere und Menschen, Verhältnis Tierreich Mensch

Für die App wäre sinnvoll​

Die App sollte vor dem Embedding automatisch solche Suchhüllen entfernen oder abschwächen:

wo finde ich
suche mir
ich denke dass
ich erinnere mich
irgendwie
vielleicht
stelle wo
und daraus eine bereinigte Suchfassung machen:

Original:
Ich erinnere mich daran, dass es da irgendwie um einen Hund ging.

Bereinigt:
Hund, Stelle mit Hund
Dann kann man natürlich schreiben, aber die Suche bekommt trotzdem einen sauberen semantischen Kern.

Ursprünglich wurde mir von ChatGPT ja extra Colbertv2 vorgeschlagen wegen der abstrakten Bedeutung. Ich habe eben nochmal in die Chatverläufe geschaut und dort hat ChatGPT aber auch gesagt:

ColBERT ist stark, aber kein echter LLM-Interpret. Es findet oft sehr gut, wenn in Query und Passage zumindest semantische/lexikalische Anker vorkommen. Bei „sinngemäß sehr abstrakt“ kann es danebenliegen.

Also das, was du meintest, AAS

Nützlich, und deine Beobachtung ist genau richtig: ein Reranker bringt keine neuen Treffer, er sortiert die Top-Kandidaten neu. Genau das ist sein Job. Die erste Suche (Vektoren) ist schnell, aber grob; der Reranker ist ein langsameres, genaueres Modell, das Frage und Textstelle zusammen liest und dadurch die Reihenfolge verbessert. Tipps: Top-80 ist Overkill, Top-20 bis 30 reicht meist und ist schneller. Und nimm für Deutsch einen mehrsprachigen Reranker (z. B. bge-reranker-v2-m3 oder Qwen3-Reranker), kein rein englisches Modell.

Ja, ich habe beide von dir genannten Reranker installiert und genutzt. Aber ich behaupte, dass ich die Ergebnisse durch Überfliegen schneller scanne als der Reranker auf meinem Rechner braucht.

In der Praxis fährt man oft hybrid am besten: klassische Stichwortsuche (BM25) + Vektorsuche + Reranker.

Für die klassische Stichwortsuche habe ich schon ein anderes Programm entwickelt. Dort kann man mehrere Suchwörter (auch mit Regex-Unterstützung) eingeben und sagen, Begriff A muss mit Begriff B und C etc. (bzw. A und (B oder C), also auch mit Suchlogik-Unterstützung) innerhalb von einem Suchfenster X vorkommen. Zusätzlich wird ein spezifizierter Kontext drumherum angegeben. Habe das sogar schon als GrapheneOS-App entwickelt fürs Handy.
[Spannende Beobachtung: Mein 6 Jahre alter Laptop mit Ryzen 5 3600 hat ziemlich genau gleich lang zum Indexieren gebraucht wie mein Google Pixel 9. Da sieht man mal den Fortschritt der Technik.... ist allerdings CPU-basiert bei diesem Programm.]

Anwendungsgebiete außerhalb Dokumentensuche (Frage 2): Code-Suche, Duplikat-/Plagiatserkennung, Empfehlungen ("ähnliche finden"), Clustering/Themen-Gruppierung, Klassifikation per Nächste-Nachbarn, Entity-/Adressabgleich, mehrsprachige Suche und das Langzeitgedächtnis von KI-Agenten (RAG). Embeddings sind im Grunde "Ähnlichkeit als Zahl" — überall einsetzbar, wo man fragt "was ist sich ähnlich".

Danke für die Ideen! Ich würde es halt gerne überall da einsetzen, wo ChatGPT mir nicht erlaubt, so große Datenmengen hochzuladen. Ich kann ja keine 100,000 Seiten PDF von ChatGPT analysieren lassen.

Ehrlich: jein. Embeddings fangen statistische Bedeutung sehr gut ein (was in ähnlichen Kontexten vorkommt), aber "verstehen" im menschlichen Sinn tun sie nicht. Mit den richtigen Hebeln (Instruktion + Query-Umschreibung + Reranker + ggf. ein LLM-Check) kommst du aber erstaunlich nah dran.

Ich könnte natürlich eine LLM einsetzen, um Query-Varianten zu erzeugen und den Reranker auf eine viel größere Ergebnisliste loslassen (1000 Stück oder so). Das wäre die einzige Anwendung für ne größere LLM und Reranker im Rahmen einer Suche, die ich mir vorstellen könnte... weil alles, was größer ist für die LLM, packt meine Grafikkarte nicht und alles, was kleiner ist für den Reranker, das ist eine Mühe, die ich mir selbst durch Überfliegen selbst machen kann.

Wie ich genau das produktiv nutze (Programmieren mit KI-Agenten): Bei mir steckt diese Technik nicht in einer Dokumentensuche, sondern als Langzeitgedächtnis einer ganzen Flotte von KI-Coding-Agenten. Ein Orchestrator (Claude Code / Claude Opus) zerlegt eine Programmieraufgabe in kleine Pakete und verteilt sie an spezialisierte Worker-Modelle (lokale + freie + Abo-Modelle); der Orchestrator schreibt selbst keinen Code, er koordiniert nur und führt am Ende zusammen. Alles, was dabei gelernt wird (Fixes, Entscheidungen, Konventionen), wird als kurze Markdown-Notiz gespeichert und automatisch in genau so einen Vektor-Store embedded (bei mir nomic-embed-text bzw. bge-m3, 768/1024 Dim) — das ist der RAG-Teil, denselben den du gerade baust. Die Suche darüber ist hybrid: erst Stichwortsuche (BM25/Volltext), parallel die Vektorsuche, dann ein Reranker — also genau deine Kette, nur eine Stufe weitergedacht. Vor jeder neuen Aufgabe zieht sich jeder Agent automatisch die relevanten Notizen aus dem Store ("context packing"), so fängt keiner bei null an und alle (Claude, lokale oder Cloud-Modelle) haben denselben Wissensstand. Damit das Gedächtnis nicht zumüllt: Salience/Decay (oft genutzte Notizen steigen, alte verblassen) und ein Secret-Scan, der Passwörter/Keys vor dem Speichern blockt. Der Punkt für dich: deine PDF-Suche ist exakt der Kern davon. Instruktions-Prompt + hybride Suche (BM25 + Vektor) + Reranker, und du hast im Kleinen dasselbe, was bei mir die Coding-Agenten "schlau" macht. Fürs Programmieren ist der Nutzen riesig: der Agent findet die passende Code-Stelle oder eine frühere Lösung in Sekunden, statt das halbe Repo neu zu lesen.

Okay, das ist eine seeeehr coole Anwendung! Ich könnte mir ja auch so eine Flotte bauen, die mir dann das Suchprogramm optimiert. Aber ich glaube, bisher ist mein Code seeehr überschaubar und ChatGPT kommt damit gut klar. Du hast bestimmt viel größere Coding-Projekte, wo du nicht einfach den Code bei ChatGPT oder Claude hochladen kannst....

Viel Erfolg, klingt nach einem richtig guten Projekt. :-)

Vielen Dank!! :-)

 

[zeaK]

Wow, vielen Dank für die ausführliche Antwort!!

Die Antwort ist KI generiert, hätte er vielleicht dazu schreiben können.

 

[Garmor]

können.

sollen.