Eine verteidigungsfähige Chunking-Strategie im Review

Von dem Fehler ausgehen, den Sie verhindern

Chunking hat genau zwei Fehlerrichtungen. Zu kleine Chunks verlieren den Kontext, der benötigt wird, um sie zu interpretieren, sodass der Retrieval-Schritt den richtigen Absatz findet und das Modell ihn falsch liest. Zu große Chunks verdünnen die Einbettung, sodass der Retrieval-Schritt den Absatz verpasst, weil ein Absatz irrelevanten Textes den Vektor dominiert.

Welche Richtung mehr schadet, hängt vom Dokumententyp ab, und das ist die gesamte Designentscheidung. Narrative Dokumente tolerieren größere Chunks, weil die Bedeutung verteilt ist. Referenzdokumente - Richtlinien, Verträge, Spezifikationstabellen - benötigen kleinere, weil jeder Absatz selbstständig ist und einzeln abgerufen werden muss.

Chunken Sie nach Struktur, bevor Sie nach Länge chunken

Längenbasiertes Splitten ist ein Fallback und keine Strategie. Dokumente haben bereits eine Struktur: Überschriften, Abschnitte, nummerierte Absätze, Tabellenzeilen. Das Splitten nach dieser Struktur ergibt Chunks, die Einheiten entsprechen, die ein Mensch zitieren würde, und Zitate sind das, was die Antwort benötigt, um glaubwürdig zu klingen.

• Teilen Sie zunächst an Überschriften und Absatzgrenzen. Verwenden Sie Länge als Einschränkung darüber hinaus, mit einer Überlappung, die groß genug ist, um einen Satz über die Grenze zu tragen.
• Behalten Sie kleine Tabellen ganze und teilen Sie sie bei größeren Tabellen zeilenweise mit wiederholtem Header auf. Ein Wert, der von seinem Spaltenheader getrennt ist, ist schlimmer als ein fehlender Wert.
• Teilen Sie nie eine Regel von ihrer Ausnahme. Wenn die Ausnahme ein folgender Satz oder ein Unterabsatz ist, gehören sie in denselben Chunk, auch wenn das bedeutet, dass er länger ist als das Ziel.
• Fügen Sie dem Pfad des Abschnitts jeden Chunk vor - Dokumenttitel, Abschnitt, Unterabschnitt. Ein Chunk wird aus dem Kontext abgerufen und muss lesbar sein, isoliert, im Kontextfenster des Modells, ohne den ursprünglichen Kontext.

Größe wählen, nicht Standard

Nehmen Sie eine repräsentative Stichprobe von realen Dokumenten, teilen Sie sie mit zwei oder drei Kandidatenkonfigurationen und untersuchen Sie die resultierenden Chunks, indem Sie sie lesen. Die Frage, die während des Lesens beantwortet werden soll, ist konkret: Könnte eine kompetente Person eine Frage aus diesem Chunk allein beantworten? Wenn die Antwort nein für einen bedeutenden Anteil der Chunks ist, ist die Konfiguration falsch, unabhängig von dem, was der Bewertungsscore sagt.

Überprüfen Sie dann die Interaktion mit dem Retrieval. Kurze Chunks verbessern die Präzision bei spezifischen Fragen und schaden Fragen, die umgebenden Kontext erfordern. Wenn der Korpus sowohl Arten von Fragen enthält, ist das der ehrliche Grund für strukturelles Chunking mit variabler Größe anstelle einer globalen Zahl.

Was aufschreiben, damit die Wahl überlebt

• Die Konfiguration, den Grund dafür und die Dokumentfamilien, für die sie gewählt wurde.
• Die zwei oder drei Fragen, die die Wahl motivierten, als Bewertungsartikel aufbewahrt, damit eine zukünftige Änderung an ihnen gemessen wird.
• Was für eine neue Dokumentfamilie zu tun ist, da die Konfiguration eine Entscheidung über den Inhalt und nicht eine globale Konstante ist.
• Das Datum und der Korpus, auf dem sie abgestimmt wurde, da Chunking, das gegen einen Korpus konfiguriert ist, nicht automatisch für einen anderen Korpus richtig ist.