idea_world_labDEV JOURNAL
Sonntag, 28. Juni 2026

Retriever‑Suche‑Alternative‑Zerlegungsdokument

Erstellungsdatum: 28. Juni 2026

Dieses Verzeichnis ist eine übersichtlich aufgeteilte Sammlung von Dokumenten, die den Retriever‑Suche‑Alternative‑ChatGPT‑Original‑Memo leichter zugänglich machen.

Das Original‑Memo bleibt unverändert erhalten. Dieses README fasst den gemeinsamen Kontext, die aktuelle Vorgehensweise, Modellkandidaten und Auswahlleitfaden zusammen. Untergeordnete Dokumente enthalten nur die jeweiligen Alternativ‑Dokumente.

Gesamter Vergleichstabelle

Diese Tabellen stellen noch keine endgültige Auswahl dar, sondern Beobachtungstabellen, um am 28. Juni die zu vergleichenden Suchalternativen auf einen Blick beurteilen zu können. Maßstab ist: „Welcher JSONL‑Kandidat erscheint, wenn man den Code‑Chunk unverändert in den Retriever eingibt, und kann dieser Kandidat im Qwen‑Validierungsschritt direkt als Beweis anerkannt werden?“

Auf einen Blick: Fazit

Alternative Ort Erwartete Rolle Sofort einsetzbarer Grad Hauptvorteil Hauptrisiko Aktuelle Bewertung
A. PostgreSQL‑Volltext‑Beibehaltung Aktuell /api/retrieve Basislinie Prüfen, wie weit die derzeit implementierte Suche reicht Hoch Ist bereits integriert und Logs sind sofort einsehbar Lange Code‑Chunks können als Query zu fehlenden Dokumenten führen Als Basislinie behalten, aber nicht als endgültige Suchmethode festlegen
B. Nur BM25 1. Suchkandidat Dokumente finden, in denen Code/API‑Zeichenketten direkt vorkommen Mittel Starke Leistung bei direkten Zeichenketten wie KinematicBody2D, move_and_slide, AnimatedSprite2D Bei breiten Begriffen wie 2D/3D entstehen False Positives Als erster PoC am einfachsten zu beobachten
C. Nur Embedding Bedeutungsbasierte Recall‑Erweiterung Verwandte Dokumente finden, auch wenn die Zeichenkette nicht exakt übereinstimmt Mittel Erfasst Satzbedeutungen, Tutorial‑Erklärungen, ähnliche Nutzungskontexte breit Gefahr, allein für Versions‑/API‑Genauigkeit verwendet zu werden Als Hilfs‑Recall, nicht als alleinige Lösung
D. BM25 + Embedding Realistischer Mittelweg Sowohl Zeichenketten‑ als auch Bedeutungsbeweise kombinieren Mittel Vereint BM25‑Präzision und Embedding‑Recall Erfordert Score‑Kombination, Duplikat‑Entfernung, Ober‑Kandidaten‑Kriterien Näher an einer minimalen Produktionslösung
E. Qwen‑Query‑Profil Experimentelle Suchunterstützung Aus Code‑Chunk ein JSON‑Suchintent erzeugen Niedrig Das vom Menschen lesbare Query‑Profil ist leicht verständlich LLM könnte vor der Suche nicht vorhandene API/Intentionen erfinden Besser als Experiment/Hilfsmittel denn als Kern‑Erste‑Suche
F. BM25 + Embedding + Reranker + Validator Endgültige Kandidatenstruktur Kandidatengenerierung, Neu‑Ranking, direkte Beweis‑Validierung Niedrig Beste Qualität und Beobachtbarkeit Kosten, Latenz, viele Stufen Als Endziel‑Kandidat festlegen

Vergleich der PoC‑Simulationsergebnisse

Alternative Eingabe‑Chunk Wie Suchkandidaten entstehen Wahrscheinlichkeit, dass zugehöriges JSONL erscheint Wahrscheinlichkeit, dass irrelevantes JSONL gemischt wird Erwarteter Zustand vor Qwen‑Validierung Erwarteter Zustand nach Qwen‑Validierung
A Gesamter chunkText Lange Query mit plainto_tsquery('simple', chunkText) erzeugen Niedrig oder instabil Kann niedrig sein, aber bei 0 Ergebnissen gibt es keine zu beobachtenden Kandidaten Keine oder nur teilweise Kandidaten zurück Kann vor direkter Beweis‑Validierung fehlen
B Gesamter chunkText Dokumente nach Token‑BM25‑Score ranken Hoch Mittel Dokumente wie Input.is_action_pressed, AnimatedSprite2D, clamp können erscheinen Fehlt die exakte Zeichenkette, wird verworfen
C Gesamter chunkText Ähnlichkeit von Code/Document‑Embedding Mittel Hoch Dokumente zu „movement“, „2D“, „player“ erscheinen breit Ohne direkte Zeichenkette im JSONL wird verworfen
D Gesamter chunkText BM25‑ und Embedding‑Kandidaten zusammenführen Hoch Mittel Zeichenketten‑ und Bedeutungs‑Kandidaten gemeinsam sichtbar Nur Kandidaten mit direktem Beweis bleiben
E Gesamter chunkText von Qwen interpretiert Suche mit vom Qwen erstelltem Such‑Profil Mittel, wenn Profil passt Hoch APIs, die nicht im Profil stehen, können gemischt werden Das Profil muss auf tatsächlichen Code geprüft werden
F Gesamter chunkText BM25‑ + Embedding‑Kandidaten werden vom Reranker neu sortiert Hoch Niedrig Viele Kandidaten, aber die besten werden gefiltert Qwen lässt nur „Ja/Nein“‑Beweise mit direktem Beweis stehen

Unterschiede, die im Demo‑Urteil sichtbar wurden

Beobachtungssituation Erster einfacher Prompt Verbesserter Direkt‑Beweis‑Prompt Bedeutung für die Suchstruktur
Godot 3‑Code + zugehöriges JSONL „Ja“ kann erscheinen „Ja“ muss erscheinen Besteht direkter Beweis, wird bestanden
Godot 3‑Code + irrelevantes JSONL Durch breites Godot‑Vokabular kann „Ja“ erscheinen „Nein“ muss erscheinen Ohne Direkt‑Beweis‑Validierung ist das Risiko hoch
KinematicBody2D‑Code + 3D‑Spatial‑Mapping Könnte als breites „Godot‑Migration“‑Thema gelten „Nein“ ist korrekt Nur Embedding oder lockere LLM‑Entscheidungen erzeugen False Positives
yield(...)‑Code + await‑Prototyp Bei direktem Muster „Ja“ „Ja“ label_prototypes kann als Beweis für Musteränderungen dienen
AnimatedSprite2D.play()‑Code + allgemeine Animations‑Docs Könnte semantisch passen Ohne direkte Zeichenkette/Pattern im JSONL „Nein“ Auch Docs‑Chunks benötigen Direkt‑Beweis‑Prüfung im Endergebnis

Vergleich des Kandidaten‑Rückgabe‑Verhaltens

Alternative Kandidaten, die häufig oben erscheinen Kandidaten, die leicht übersehen werden Kandidaten, die leicht vermischt werden Punkte, die man visuell prüfen sollte
A Dokumente mit vielen Query‑Tokens in einer Zeile Wenn relevante Tokens auf mehrere Dokumente verteilt sind Bei zu strenger Query fast nichts Warum 0 Ergebnisse? Welche Tokens haben das Matching verhindert?
B Zeilen, in denen API‑Name, Funktions‑ oder Node‑Name direkt vorkommen Umformulierte erklärende Dokumente Dokumente anderer Systeme mit gleichen Begriffen Übereinstimmung von match_terms mit dem tatsächlichen Quell‑Chunk‑String
C Tutorials/Erklärungen mit ähnlicher Bedeutung Kurze exakte API‑Mappings Dokumente mit anderer Godot‑Version oder 2D/3D‑Kontext Gibt es neben dem Cosine‑Score einen direkten Zeichenketten‑Beweis?
D Exakte Kandidaten + semantische Kandidaten Kandidaten, die durch Score‑Kombination verloren gehen Kandidaten, die von beiden Suchen nur schwach getroffen werden Herkunft des Kandidaten: BM25 oder Embedding?
E Kandidaten, die zum von Qwen gewählten Intent passen Tatsächliche Code‑Hinweise, die Qwen nicht ins Profil aufgenommen hat Von Qwen erfundene API/Intent‑Kandidaten Existieren die Felder des Profils tatsächlich im Chunk?
F Kandidaten, die der Reranker als passend zum Chunk ansieht Godot‑Spezialfälle, die dem Reranker unbekannt sind Hohe Reranker‑Score, aber kein direkter JSONL‑Beweis Wo divergieren Reranker‑Score und Validator‑Entscheidung?

Vergleich von False Positive / False Negative

Alternative Beispiel für False Positive Beispiel für False Negative Reduzierungsmethode
A Selten, aber wenn die Abfrage zu breit ist, mischen sich allgemeine Bewegungs‑Dokumente darunter Wenn zugehörige Dokumente auf mehrere Zeilen verteilt sind, gibt es 0 Treffer Abfragemethode ändern oder BM25‑Kandidaten hinzufügen
B Durch movement, player, 2d mischen sich andere Bewegungs‑Dokumente Wenn der API‑Name im Dokument nur beschreibend vorkommt, wird er übersehen Stop‑Wörter/ schwache Token trennen, API‑Token direkt gewichten
C Dokumente mit ähnlicher Bedeutung (3D/andere Versionen) mischen sich Kurze API‑Rename‑Zeilen werden nicht erfasst Parallel zu BM25 verwenden und Validator anhängen
D Schwach passende Kandidaten aus BM25 und Embedding mischen sich Wenn die Fusion‑Regel fehlerhaft ist, wird ein Kandidat verdrängt Union‑Source‑Flag und Direct‑Evidence‑Log hinterlegen
E Qwen erzeugt ein migration_intent ohne passende Daten und verunreinigt die Kandidaten Qwen lässt echte Code‑Hinweise im Profil weg Profil nur als Hilfsmittel, nicht als vertrauenswürdige Quelle, verwenden
F Der Reranker überschätzt plausible Erklärungen Dokumente, die im Kandidatengenerierungs‑Schritt nie erreicht wurden Ausreichend Kandidaten sichern und Qwen‑Validierung zuletzt einsetzen

Eignung je Tabelle

Alternative docs_chunks api_mapping label_prototypes Anmerkungen
A Instabil bei langen Beschreibungs‑Dokumenten Wenn die exakte Mapping‑Zeile kurz ist, kann sie übersehen werden Wenn die Pattern‑Zeile kurz ist, kann sie übersehen werden Basislinie zur Bestimmung der Grenzen des aktuellen Ansatzes
B Gut für API/Heading/Token‑Suche Gut für exakte Suche nach Quell‑/Ziel‑API Gut für Suche nach Quell‑/Ziel‑Pattern Alle drei Tabellen eignen sich gut als erste Kandidaten‑Beobachtung
C Gut für Recall von beschreibenden Dokumenten Schwach bei kurzen Zeilen wie API‑Rename Kann ergänzend genutzt werden, wenn Nutzungsmuster ähnlich sind docs_chunks ist die natürlichste Ergänzung
D Sichert sowohl Beschreibungs‑ als auch String‑Kandidaten Sichert sowohl exakte Mapping‑ als auch semantische Kandidaten Erweitert die Nutzungsmuster‑Kandidaten breit Einheitliche Struktur über alle drei Tabellen hinweg – am robustesten
E Wenn das Abfrage‑Profil gut ist, können Beschreibungs‑Dokumente gefunden werden Gefahr bei halluzinierten APIs Kann Prototyp‑Intentionen erzeugen, aber auch verunreinigen Mehr ein Beobachtungs‑/Ergänzungsexperiment als Kern‑Suche
F Gut zur End‑Verfeinerung von Erklärungs‑Begründungen Gut zur End‑Verfeinerung von Migrations‑Begründungen Gut zur End‑Verfeinerung von Änderungen im Nutzungs‑Modus Alle drei Tabellen lassen sich gut in einer gemeinsamen Pipeline verarbeiten

Was unbedingt in den Logs zu sehen ist

Alternative Log vor der Suche Log während der Suche Log nach der Suche Punkte zur Fehlersuche
A roher chunkText, erzeugtes tsquery Anzahl der Treffer von search_tsv @@ query, ts_rank_cd zurückgegebene Zeile, Score Ist die Abfrage zu lang geworden? Welche Token fehlen in den Zeilen?
B roher chunkText, Token‑Liste Term‑Frequenz, gematchte Terme, BM25‑Score Top‑k pro Tabelle Werden starke und schwache Token unterschieden?
C roher chunkText, Embedding‑Modell Vektor‑Distanz / Cosine‑Score Semantic Top‑k Handelt es sich um Kandidaten, die nur semantisch passen, ohne echten String?
D BM25 Top‑k, Embedding Top‑k Union, Duplikat‑Merge, Score‑Fusion Kandidatenliste mit Source‑Flags Warum überlebt ein Kandidat, der nur aus einem Suchpfad stammt?
E Roh‑Chunk, das an Qwen gesendet wurde Qwen‑Abfrage‑Profil‑JSON Ergebnisse basierend auf dem Profil Existiert das Profil‑Feld tatsächlich in der Quelle?
F Gesamte BM25/Embedding‑Kandidaten Rerank‑Score, Rerank‑Reihenfolge Qwen Ja/Nein, Ablehnungsgrund Warum scheiterten Kandidaten, die den Reranker passiert haben, beim direkten Beweis‑Check?

Implementationsaufwand und Betriebskosten

Alternative Implementierungsaufwand DB‑Änderungen Kosten für externe Modelle Latenz Debug‑Schwierigkeit Wie leicht lässt sich ein Fehlschlag beheben?
A gering kaum vorhanden keine gering gering gering. Performance‑Grenzen können jedoch strukturell sein
B mittel BM25‑Suchmaschine/Index‑Auswahl nötig keine oder gering gering gering hoch. Token‑/Gewichtsanpassungen sind möglich
C mittel Embedding‑Spalte/Index nötig vorhanden mittel mittel mittel. Modell‑/Dimensions‑/Threshold‑Anpassungen nötig
D mittel‑bis‑hoch Sowohl BM25‑ als auch Vektor‑Index nötig vorhanden mittel mittel hoch. Man kann genau sehen, welcher Suchpfad versagt hat
E mittel Profil‑Speicherung optional vorhanden hoch hoch gering. Es kann schwer sein, nachzuvollziehen, warum das LLM‑Profil falsch war
F hoch BM25 + Vector + Rerank‑Log nötig vorhanden hoch hoch hoch. Mit schrittweisen Logs lässt sich der Fehlerpunkt gut lokalisieren

Vergleich, wo Qwen eingesetzt werden soll

Position Vorteile Risiken Aktuell passendste Nutzung
Abfrage‑Generierung vor der Suche Kann Suchintention ohne Hard‑Coding erzeugen Kann falsche Hinweise erzeugen und die Suche verunreinigen Nur für Experimente verwenden
Direkter Beweis‑Check nach Kandidatengenerierung Filtert, ob Suchergebnisse zum echten Code passen Verursacht Aufruf‑Kosten Wichtigster Schritt
Endgültige Antwort‑Generierung Kann Code‑Erklärungen / Migrations‑Antworten erzeugen Wenn die Begründung falsch ist, ist die Antwort ebenfalls falsch Nach validierten JSONL‑Kandidaten einsetzen
Gesamte Entscheidungs‑Integration Liefert ein lesbares Gesamtergebnis für Menschen Kann Zwischenergebnisse verbergen Nach ausreichender Log‑Ansammlung prüfen

Priorisierung der Auswahl

Priorität Option Grund Fragen, die in diesem Schritt geklärt werden müssen
1 A als Basislinie messen Wir müssen wissen, wo die aktuelle Implementierung scheitert Wie viele Treffer liefert die aktuelle Methode tatsächlich?
2 B als separates PoC anhängen Code‑/API‑String‑Suche ist am erklärbarsten Finden KinematicBody2D, yield, move_and_slide die richtigen Zeilen?
3 C als ergänzenden Recall vergleichen Kann beschreibende docs_chunks‑Kandidaten erweitern Wie viele semantische Kandidaten fallen beim direkten Beweis‑Check aus?
4 D für parallele Kandidatengenerierung Praktisch minimale Struktur Verbessert die Qualität, wenn BM25‑ und Embedding‑Kandidaten kombiniert werden?
5 F für Reranker/Validator hinzufügen Endgültige Qualitätsprüfung Verwirft Qwen‑Beweis‑Entscheidungen zuverlässig nicht‑JSONL‑Kandidaten?
Auf Eis E LLM vor der Suche birgt hohes Verunreinigungs‑Risiko Wird das Profil ausschließlich aus echten Code‑Strings erstellt?

PoC-Checkliste

Prüfpunkt Zu prüfender Bildschirm/Log Erfolgskriterium
Gleichen chunkText in mehrere Alternativen einfügen Chunk-Eingabebereich des Web-Debuggers Die Eingabe ändert sich nicht je nach Alternative
Such‑Button pro Tabelle Buttons docs_chunks, api_mapping, label_prototypes Für denselben Chunk zeigen die Tabellen unterschiedliche Kandidaten
Roh‑Kandidaten prüfen Zurückgeladene JSONL‑Payload Das Feld entspricht dem tatsächlichen String im Quell‑Chunk
Qwen‑Validierung prüfen Debug‑Bereich prompt + chunk + jsonl Relevante Kandidaten erhalten „Ja“, irrelevante „Nein“
Ablehnungsgrund prüfen Log des Validators Kandidaten, die nur breite Begriffe wie Godot, migration, 2D enthalten, werden verworfen
False‑Positives sammeln Liste verworfener Kandidaten Kann später zur Verbesserung von Abfrage/Token/Validator‑Regeln verwendet werden
Vergleich pro Alternative speichern Beobachtungsprotokoll oder Ergebnis‑JSON Unterschiede von A‑F bei gleicher Eingabe bleiben erhalten

Alternativdokumente

Aktuelle Annahme

Die aktuelle Basis ist wie folgt.

1. Im ZIP‑Archiv befinden sich das ursprüngliche Markdown, das Schema, der Debugger und das Designdokument.  
2. Auf dem lokalen System ist bereits die konvertierte Version Markdown → JSONL → DB vorhanden.  
3. Was derzeit einsehbar ist, sind das unverarbeitete Markdown sowie das DB‑Schema/der Suchablauf.  
4. Der PoC muss das Markdown im ZIP‑Archiv wie JSONL‑Chunks aufteilen und die Suchobjekte simulieren, die in die lokale DB hätten gelangen können.  
5. Gesucht wird nicht der Code‑Rahmen, sondern die Nachverfolgung, wie jede Suchmethode Punkte erzeugt und warum sie erfolgreich bzw. fehlgeschlagen ist, wenn ein Chunk eingefügt wird.

JSONL/DB Kriterien

Die dokumentenbezogenen Ergebnisse sind wie folgt.

work/godot_rag/jsonl/docs_chunks.jsonl
work/godot_rag/jsonl/api_mapping.jsonl
work/godot_rag/jsonl/label_prototypes.jsonl
work/godot_rag/jsonl/ingest_report.jsonl

Die DB speichert nicht eine ganze JSONL‑Zeile als payload jsonb, sondern versteht die JSONL‑Felder als einzelne Tabellenspalten.

docs_chunks

chunk_id
doc_version
source_url
source_file
source_sha256
doc_type
symbol
section_path
heading
content
code_blocks
language_tags
godot_version_tags
api_symbols
token_count
metadata
embedding
search_tsv

api_mapping

mapping_id
source_api
target_api
change_type
godot_from
godot_to
confidence
evidence_chunk_ids
match_terms
notes
negative_patterns

label_prototypes

prototype_id
label
task_type
input_pattern
expected_finding
recommended_action
evidence_mapping_ids
evidence_chunk_ids
severity
validator_rules
embedding
search_tsv

Basis‑Chunk

Der als Basis für den Vergleich der Alternativen herangezogene Chunk ist der folgende Godot‑Code.

func _process(delta):
	var velocity = Vector2.ZERO
	if Input.is_action_pressed(&"move_right"):
		velocity.x += 1
	if Input.is_action_pressed(&"move_left"):
		velocity.x -= 1

	if velocity.length() > 0:
		velocity = velocity.normalized() * speed
		$AnimatedSprite2D.play()
	else:
		$AnimatedSprite2D.stop()

	position += velocity * delta
	position = position.clamp(Vector2.ZERO, screen_size)

Starke Token:

animatedsprite2d
is_action_pressed
move_left
move_right
normalized
clamp
screen_size
vector2
zero

Schwaches Token:

func
var
if
else
velocity
position
delta
x
0
1

Die Sucheingabe bleibt weiterhin exakt chunkText. Das Vorab‑Extrahieren von Godot‑API‑Signals zu einer separaten Abfrage wird nicht als Kern des Grunddesigns betrachtet. Falls nötig, wird dies später lediglich als ergänzender Score geprüft.

Aktuelle /api/retrieve‑Methode

Die aktuelle /api/retrieve‑Implementierung des Projekts verwendet kein BM25.

Der Ablauf ist dem Folgenden ähnlich.

chunkText
  -> plainto_tsquery('simple', chunkText)
  -> search_tsv @@ query
  -> ts_rank_cd(...)

PostgreSQLs ts_rank_cd ist eine Full‑Text‑Ranking‑Funktion. Im Gegensatz zu dem eigentlichen BM25‑Algorithmus, der Term‑Frequency, Inverse‑Document‑Frequency und Feldlängen‑Normalisierung kombiniert, muss man es hier anders betrachten.

plainto_tsquery(raw_chunk) extrahiert Token aus dem Eingabe‑Chunk und erzeugt daraus eine Query. Der Basis‑Chunk kann dabei, wie unten gezeigt, zu einer sehr langen Query werden.

func & process & delta & var & velocity & vector2 & zero
& input & is_action_pressed & move_right & move_left
& length & normalized & speed & animatedsprite2d
& play & stop & position & clamp & screen_size

Diese Methode kann zu viele Token in einer Zeile erfordern.

Wenn das offizielle Dokumenten‑Chunk wie folgt aufgeteilt ist, entsteht ein Problem.

chunk A:
  Input.is_action_pressed
  velocity.normalized
  AnimatedSprite2D.play/stop

chunk B:
  AnimatedSprite2D Beschreibung
  position.clamp
  screen_size

Beide sind relevant, aber es kann sein, dass nicht alle Tokens gleichzeitig in einer Zeile enthalten sind.

Im Originalnotiz wird angenommen, dass eine strikte Roh‑AND‑Suche wie folgt fehlschlagen kann.

strict raw AND hits: 0

Die aktuelle Methode kann zwar als Basislinie für den PoC betrachtet werden, ist jedoch zu schwach, um als endgültige Suchstrategie beibehalten zu werden. Im nächsten Schritt muss die aktuelle Methode von BM25 getrennt und verglichen werden.

Modellkandidaten

voyage-code-3

Wurde als der am besten zum aktuellen Projekt passende Embedding‑Kandidat genannt.

Grund:

query ist kein natürlicher Sprachfrage, sondern ein GDScript‑Code‑Chunk.  
Die zu durchsuchenden JSONL‑Einträge enthalten ebenfalls Code‑Blöcke, API‑Namen und Dokumentationsbeschreibungen.

Vorteile:

  • Stark im Code‑Retrieval.
  • Vorteilhaft für die Verarbeitung langer Chunks.
  • Geeignet für die Suche von Code → Docs.

Nachteile:

  • Abhängig von externen APIs.
  • Kostenintensiv.
  • Kein auf Godot spezialisierter Modell.

Empfehlung nach Notizen:

voyage-code-3 1024 float

OpenAI text-embedding-3-large

Allgemeiner hochwertiger Embedding-Kandidat.

Vorteile:

  • Stark bei allgemeiner semantischer Suche.
  • Zuverlässig für die Suche nach Dokumentenbeschreibungen.
  • Einfach in das OpenAI‑Ökosystem zu integrieren.

Nachteile:

  • Nicht ausschließlich für Code‑Suche gedacht.
  • Die Grunddimension ist groß, wodurch Speicher‑/Indexkosten steigen können.
  • Für GDScript‑Chunks → JSONL‑Suche kann es weniger direkt sein als voyage-code-3.

Empfehlung basierend auf dem Speicherbedarf:

Zweite Priorität

Gemini Embedding

Allgemeine/mehrsprachige semantische Retrieval‑Kandidaten.

Vorteile:

  • Gut für dokumentenbasierte beschreibende Retrieval‑Aufgaben.
  • Es gibt Optionen zur Dimensionsreduktion.
  • Kann bei der Suche nach mehrsprachigen Dokumenten Vorteile bieten.

Nachteile:

  • Keine reine Auswahl für Code‑Retrieval.
  • Liegt näher an semantischer Ähnlichkeit als an der Genauigkeit von API‑Code.
  • Die alleinige Verwendung kann bei genauen Godot‑Migrationsentscheidungen riskant sein.

Jina embeddings v4

Ein Kandidat mit Stärken bei komplexen Dokumenten, multimodalen und visuell reichen Dokumenten‑Retrieval.

Vorteile:

  • Breite Abdeckung bei der Dokumentensuche.
  • Stark bei multimodalen/komplexen Dokumenten.
  • Auch Adapter‑Reihen für Code können geprüft werden.

Nachteile:

  • Das aktuelle Projekt fokussiert sich auf Markdown/Code.
  • Bild‑ und Tabellensuche ist nicht der Kern.
  • In der jetzigen Phase könnte es eine überdimensionierte Wahl sein.

Empfehlung basierend auf Notizen:

Im Moment ist die Priorität niedrig.

rerank-2.5

Als Kandidat für den Re‑Ranker erwähnt.

Rolle:

BM25 und Embedding erzeugte Kandidaten werden erneut zusammen mit dem Roh‑Chunk verglichen.  
Die Kandidaten werden anhand des Relevanzscores neu sortiert.

Dieses Projekt erwartet folgende Effekte:

  • Reduziert falsche Positive bei 2D‑Bewegung und 3D‑Bewegung.
  • Reflektiert Kontext wie AnimatedSprite2D, Vector2, screen_size, position.clamp besser.
  • Fasst die von BM25 bzw. Embedding vorgeschlagenen Kandidaten zu endgültigen Kandidaten zusammen.

Hinweis:

  • Der Reranker ist kein Validator.
  • Direkte Beweisprüfung muss erneut vom Qwen direct‑evidence Validator durchgeführt werden.

Zusammenfassung der Optionen

Alternative Ablauf Vorteile Risiken
A PostgreSQL Full‑Text beibehalten Bereits implementiert Bei langen Chunks möglich 0 Treffer, nicht BM25
B Nur BM25 Transparenz, stark bei Zeichenketten/API Falsche Positive wie bei 3D‑Bewegung
C Nur Embedding Semantische Suche möglich API/Versionsgenauigkeit schwach
D BM25 + Embedding Realistisches Gleichgewicht Abstimmung der Score‑Kombination nötig
E Qwen‑Abfrageprofil Reduziert Hard‑Coding, ermöglicht Intent‑Zusammenfassung Halluzinationen, Kosten, Vorab‑Kontamination der Suche
F BM25 + Embedding + Reranker + Validator Qualität hat oberste Priorität Kosten, Latenz, viele Schritte

Aktuelle vorläufige Einschätzung

Die Schlussfolgerung der Originalnotiz liegt nahe bei folgendem.

Nur ein chunkText wird beibehalten.

1 . Stufe Suche wird mit BM25 durchgeführt.  
   Grund: Es ist transparent und stark bei der Suche nach Code/API‑Zeichenketten.

2 . Stufe Suche wird mit voyage‑code‑3 Embedding durchgeführt.  
   Grund: Da die Abfrage ein Code‑Chunk ist, passt ein Code‑Retrieval‑Modell.

3 . Stufe Sortierung erfolgt mit rerank‑2.5.  
   Grund: Um das echte Chunk und das passende JSONL unter den ähnlichen Kandidaten, die von BM25 und Embedding geliefert wurden, nach oben zu bringen.

Abschließende Validierung erfolgt mit dem Qwen direct‑evidence validator.  
   Grund: Wenn im JSONL kein direkter String/Pattern‑Beweis für das Chunk vorhanden ist, muss es verworfen werden.

Einzeilige Zusammenfassung:

raw chunk unverändert eingeben  
  -> BM25 + Code-Embedding parallele Kandidatengenerierung  
  -> Reranker-Neusortierung  
  -> Qwen direkte Beweisprüfung

Nächstes, das tatsächlich verglichen werden soll

  • Wie viele Einträge die aktuelle PostgreSQL-Volltextmethode im Referenz‑Chunk zurückgibt
  • Ob BM25 first_2d_game tatsächlich nach oben verschiebt
  • Wie stark sich falsche Positive bei 3D‑Bewegungen im reinen BM25‑Modus vermischen
  • Welche erklärenden Dokumente das reine Embedding zusätzlich abruft
  • Wie Duplikate und Scores im BM25 + Embedding‑Union kombiniert werden sollen
  • Ob der Reranker die 2D/3D‑Kandidaten korrekt neu ordnet
  • Ob der Qwen‑Direct‑Evidence‑Validator irrelevante JSONL‑Einträge tatsächlich mit Nein verwirft