Startseite / Artikel / Ihre RAG-Pipeline beginnt vor der ersten Einbettung.

Ihre RAG-Pipeline beginnt vor der ersten Einbettung.

Erstellen Sie ein Quellinventar, das nutzbare Beweismittel von fehlendem Text, fehlerhaften Angaben zur Herkunft sowie unvollständigen Extraktionen unterscheidet.

553 Wörter

Ein Suchsystem kann eine flüssige Antwort aus einem Dokument liefern, das eigentlich niemals in seinen Beweispool aufgenommen werden sollte. Der Titel kann einer Seite gehören, während die URL auf eine andere verweist. Eine gespeicherte Seite kann nur einen Vorschauinhalt enthalten. Eine Tabelle kann bei der Extraktion als Liste von Zahlen ohne ihre Beschriftungen übrig bleiben.

Durch Einbetten dieser Eingaben werden sie suchbar – doch das macht sie nicht zuverlässig.

Für eine Wissensanwendung würde ich mit einem Quellenverzeichnis beginnen: einer Aufstellung darüber, was gesammelt wurde, was tatsächlich extrahiert wurde und was sicherlich eine Antwort stützen kann. Dieses Verzeichnis erleichtert außerdem die Überprüfung eines auf Artikeln basierenden Veröffentlichungsworkflows, denn jeder Entwurf kann auf eine bestimmte Version seiner Beweise verweisen.

Trennung von Suche und Beweisen

Ein Titel, der Autor und eine kurze Beschreibung sind nützliche Metadaten zur Suche. Sie helfen Ihnen dabei, zu entscheiden, welchen Artikel Sie als Nächstes lesen sollen. Sie reichen jedoch nicht aus, um die Argumentation des Artikels wiederzugeben, seine Beispiele zu überprüfen oder mitzuteilen, zu welchen Schlussfolgerungen der Autor gelangt ist.

Speichern Sie die Verfügbarkeit explizit. Nützliche Zustände umfassen ausschließlich Metadaten, extrahierter Text mit unbekannter Vollständigkeit, überprüfter vollständiger Text sowie Identitätskonflikte. Vermeiden Sie ein einzelnes indexed: true-Flag, das alle vier Situationen verdeckt.

Ein minimales Datensatz könnte wie folgt aussehen:

{
  "source_id": "article-42",
  "canonical_url": "https://example.com/article-42",
  "content_status": "extracted_text",
  "completeness": "unverified",
  "content_hash": "sha256-of-extracted-text",
  "retrieved_at": "2026-09-17T12:00:00Z"
}

Der Hash identifiziert die Textversion. Er ist kein Maß für Richtigkeit. Ebenso ist eine lange Extraktion ein Indiz auf verfügbaren Text, aber kein Beweis dafür, dass weder eine Paywall, ein Parserfehler noch ein Navigationssperre ihn verändert haben.

Bewahren Sie die bedeutungstragenden Beziehungen bei

Dokumentenparsing und -in Teilblöcke aufteilen lösen unterschiedliche Probleme. Das Parsing muss die Struktur rekonstruieren; das Aufteilen bestimmt, wie diese Struktur aufgeteilt wird. Wenn die Extraktion einen Tabellenwert von seinem Spaltenkopf trennt, kann ein späterer Trenner die fehlende Beziehung nicht zuverlässig wiederherstellen.

Betrachten Sie ein Wartungshandbuch, das einen Komponenten, seinen Inspektionsintervall sowie die Bedingungen auflistet, unter denen sich das Intervall ändert. Wenn nur das Intervall gespeichert wird, ergibt sich eine überzeugende, aber unvollständige Antwort. Bewahren Sie die Bezeichnungen sowie Ausnahmen zusammen auf, bevor Sie eine Vektorähnlichkeit berücksichtigen.

Deshalb brauchen die Grenzen der Teilblöcke eine explizite Gestaltung. Ein Trenner kann keine Beweise ausgleichen, die bereits zuvor verschwunden sind.

Fehler sichtbar machen, ohne das Inventar zu vernachlässigen

Halten Sie problematische Datensätze für Wartungszwecke suchbar, schließen Sie sie aber aus dem Beweismittelpool aus, der zur Erstellung von Antworten oder Veröffentlichungen verwendet wird. Notieren Sie den Grund: nicht übereinstimmender Identifikator, fehlender Textinhalt, unklare Sprache oder Extraktionsfehler.

Diese Unterscheidung ermöglicht zwei Arbeitsabläufe. Eine Wartungssuche fragt, was repariert werden muss. Eine Antwortssuche fragt, welche Quellen zur Untermauerung einer Behauptung geeignet sind. Sie sollten nicht stillschweigend dieselben Datensätze zurückgeben.

Für Veröffentlichungen fügen Sie eine weitere Überprüfung hinzu: Lesen Sie die Abschnitte, die Sie verwenden möchten. Eine Quelle kann zum Thema relevant sein, aber nicht zur Unterstützung der spezifischen Schlussfolgerung in Ihrem Entwurf ausreichen.

Prüfen Sie die Qualität der Quellen als Bestandteil des Produkts

Erstellen Sie eine kleine Sammlung absichtlich unpraktischer Eingaben: einen Artikelvorschau-Text, eine umgeleitete URL, eine zweispaltige Seite, eine Tabelle mit Fußnoten sowie zwei Versionen desselben Dokuments. Überprüfen Sie das extrahierte Ergebnis, bevor Sie die Suchrelevanz messen.

Der umfassendere Bewertungsworkflow sollte fehlende Belege von schlechten Ranking-Ergebnissen sowie ununterstützter Generierung unterscheiden. Andernfalls könnte ein Retrieval-Problem Sie zum ursprünglichen Prompt zurückführen, während das eigentliche Problem weiterhin im Quellbestand liegt.

Das erste nützliche Meilenstein ist einfach: Jeder Eintrag erklärt, was verfügbar ist und woher es stammt. Wenn das gewährleistet ist, werden spätere Verbesserungen leichter interpretierbar.