Nachdem Sie Ihre Testdokumente und -abfragen gesammelt und eine Dokumentanalyse in der Vorbereitungsphase durchgeführt haben, werden Sie in der nächsten Phase das Chunking durchführen. Das Aufteilen von Dokumenten in eine Sammlung von richtig dimensionierten Blöcken mit semantisch relevanten Inhalten ist ein wichtiger Faktor für den Erfolg Ihrer RAG-Implementierung (Retrieval-Augmented Generation). Die Übergabe ganzer Dokumente oder übergroßer Blöcke ist teuer, kann die Token-Grenzen des Modells sprengen und führt nicht zu den besten Ergebnissen. Das Übergeben von Informationen an ein großes Sprachmodell, die für die Abfrage irrelevant sind, kann zu Halluzinationen führen. Sie müssen den Prozess der Weitergabe relevanter Informationen und das Entfernen irrelevanter Informationen optimieren. Sie führen diese Optimierung durch, indem Sie effektive Chunking- und Suchstrategien verwenden, um False Positive und False Negative-Ergebnisse zu minimieren und True Positive und True Negative-Ergebnisse zu maximieren.
Das Übergeben von zu kleinen Blöcken und nicht genügend Kontext zum Adressieren der Abfrage führt ebenfalls zu schlechten Ergebnissen. Relevanter Kontext, der sich über mehrere Blöcke erstreckt, wird möglicherweise nicht erfasst. Die Kunst besteht darin, effektive Chunking-Ansätze für Ihre spezifischen Dokumenttypen und deren Strukturen und Inhalte zu implementieren. Es gibt verschiedene zu berücksichtigende Chunking-Ansätze, die jeweils ihre eigenen Kostenauswirkungen und Effektivität aufweisen, je nach Art und Struktur des Dokuments, auf das sie angewendet werden.
In diesem Artikel werden verschiedene Chunking-Strategien untersucht, um zu zeigen, wie sich die Struktur Ihrer Dokumente auf den gewählten Chunking-Ansatz auswirken kann.
Dieser Artikel ist Teil einer Serie. Die Einführung finden Sie hier.
Chunking-Ökonomie
Bei der Ermittlung der Chunking-Hauptstrategie müssen Sie Ihr Budget zusammen mit den Qualitäts- und Durchsatzanforderungen für Ihren Dokumentkorpus berücksichtigen. Es gibt technische Kosten für den Entwurf und die Implementierung jeder eindeutigen Chunking-Implementierung und Vearbeitungskosten pro Dokument, die je nach Ansatz variieren. Wenn Ihre Dokumente eingebettete oder verknüpfte Medien haben, müssen Sie die Wirtschaftlichkeit der Verarbeitung dieser Elemente berücksichtigen. Bei Blöcken verwendet diese Verarbeitung in der Regel Sprachmodelle, um Beschreibungen der Medien zu generieren, und diese Beschreibungen werden dann unterteilt. Ein alternativer Ansatz bei einigen Medien besteht darin, sie zum Zeitpunkt der Schlussfolgerung unverändert an ein multimodales Modell weiterzugeben, aber dieser Ansatz würde die Wirtschaftlichkeit des Chunking nicht beeinträchtigen.
In diesem Abschnitt wird die Wirtschaftlichkeit des Chunking von Bildern und der Gesamtlösung untersucht.
Wirtschaftlichkeit des Bild-Chunkings
Die Verwendung eines Sprachmodells zur Erstellung einer Bildbeschreibung, die dann in Blöcke unterteilt wird, ist mit Kosten verbunden. Cloudbasierte Dienste wie Azure OpenAI berechnen z. B. entweder pro Transaktion oder auf Prepaid-Bereitstellungsbasis. Größere Bilder verursachen größere Kosten. Durch Ihre Dokumentenanalyse sollten Sie feststellen, welche Bilder sich zum Chunking eignen und welche Bilder Sie ignorieren sollten. Von dort aus müssen Sie die Anzahl und Größe der Bilder in Ihrer Lösung verstehen und den Wert des Abschnitts der Bildbeschreibungen gegen die Kosten für die Generierung dieser Beschreibungen abwägen.
Eine Möglichkeit, zu bestimmen, welche Bilder verarbeitet werden sollen, ist die Verwendung eines Diensts wie Azure KI Vision zum Klassifizieren von Bildern, Tagging von Bildern oder zur Erkennung von Logos. Anschließend können Sie anhand der Ergebnisse und Konfidenzindikatoren ermitteln, ob das Bild einen aussagekräftigen, kontextbezogenen Wert liefert und verarbeitet werden soll. Aufrufe an Azure KI Vision sind möglicherweise weniger teuer als Aufrufe an Sprachmodelle, sodass dieser Ansatz zu Kosteneinsparungen führen könnte. Sie müssen experimentieren, um zu bestimmen, welche Konfidenzstufen und welche Klassifizierungen oder Tags die besten Ergebnisse für Ihre Daten liefern. Eine weitere Möglichkeit besteht darin, Ihr eigenes Klassifizierermodell zu erstellen. Sie müssen die Kosten für das Erstellen, Hosten und Verwalten Ihres eigenen Klassifizierermodells berücksichtigen.
Eine weitere Kostenoptimierung ist das Zwischenspeichern mithilfe des Cache-Aside-Musters. Sie können einen Schlüssel basierend auf dem Hash des Bilds generieren. Als erster Schritt können Sie überprüfen, ob ein zwischengespeichertes Ergebnis aus einer vorherigen Ausführung oder zuvor verarbeiteten Dokument vorhanden ist. Falls ja, können Sie dieses Ergebnis verwenden. Dieser Ansatz erspart Ihnen die Kosten für den Aufruf eines Klassifizierers oder eines Sprachmodells. Wenn kein Cache vorhanden ist, würden Sie beim Aufrufen des Klassifizierers oder des Sprachmodells das Ergebnis zwischenspeichern. Zukünftige Aufrufe für dieses Bild würden den Cache verwenden.
Ein einfacher Workflow, der alle diese Kostenoptimierungsprozesse integriert, wäre:
- Überprüfen, ob die Bildverarbeitung zwischengespeichert wurde. Falls ja, werden die zwischengespeicherten Ergebnisse verwendet.
- Führen Sie den Klassifizierer aus, um zu ermitteln, ob Sie das Image verarbeiten sollten. Zwischenspeichern Sie das Klassifizierungsergebnis. Fahren Sie nur fort, wenn Ihre Klassifizierungslogik Sie dazu auffordert.
- Generieren Sie die Beschreibung für Ihr Bild. Zwischenspeichern Sie das Ergebnis.
Wirtschaftlichkeit der Gesamtlösung
Es sind folgende Faktoren zu berücksichtigen, wenn Sie sich die Kosten Ihrer Gesamtlösung ansehen:
- Anzahl eindeutiger Chunking-Implementierungen – Jede eindeutige Implementierung hat sowohl technische als auch Wartungskosten. Sie müssen die Anzahl der eindeutigen Dokumenttypen in Ihrem Korpus und die jeweiligen Kosten im Vergleich zu Qualitätskonflikten eindeutiger Implementierungen berücksichtigen.
- Kosten pro Dokument für jede Implementierung – Einige Chunking-Ansätze können zu besseren Qualitätsblöcken führen, weisen jedoch höhere finanzielle und zeitliche Kosten auf, um diese Blöcke zu generieren. Beispielsweise hat die Verwendung eines vorgefertigten Modells in Azure KI Dokument Intelligenz wahrscheinlich höhere Kosten pro Dokument als eine reine Textanalyseimplementierung, kann aber zu besseren Blöcken führen.
- Anzahl der anfänglichen Dokumente – Die Anzahl der anfänglichen Dokumente, die Sie verarbeiten müssen, um die Lösung zu starten.
- Anzahl der inkrementellen Dokumente – Die Anzahl und Rate neuer Dokumente, die Sie für die laufende Wartung des Systems verarbeiten müssen.
Laden und Chunking
Logisch gesehen, müssen Sie das Dokument während des Chunkings zunächst in einen Speicher in einem bestimmten Format laden. Der Chunkingcode wird dann mit der Speicherdarstellung des Dokuments ausgeführt. Sie können den Ladecode mit Chunking kombinieren oder das Laden in eine eigene Phase auslagern. Der gewählte Ansatz sollte weitgehend auf den architektonischen Einschränkungen und Ihren Präferenzen basieren. In diesem Abschnitt werden beide Optionen kurz erläutert. Anschließend erhalten Sie einige allgemeine Empfehlungen.
Trennen der Lade- und Chunkingphasen
Es gibt mehrere Gründe, warum Sie die Lade- und Chunkingphasen trennen würden. Möglicherweise möchten Sie die Logik im Ladecode kapseln. Möglicherweise möchten Sie das Ergebnis des Ladecodes vor dem Chunking beibehalten, insbesondere beim Experimentieren mit verschiedenen Chunkingtransmutationen, um Verarbeitungszeit oder Kosten zu sparen. Schließlich sollten Sie den Lade- und Chunkingcode aus architektonischen Gründen in separaten Prozessen ausführen, z. B. aus Gründen der Verarbeitung von Bulkheading oder der Sicherheitssegmentierung, die das Entfernen von personenbezogenen Informationen umfasst.
Kapseln der Logik im Ladecode
Sie können die Vorverarbeitungslogik in der Ladephase kapseln. Dies vereinfacht den Chunkingcode, da er keine Vorverarbeitung durchführen muss. Die Vorverarbeitung kann so einfach sein wie das Entfernen oder Kommentieren von Teilen des Dokuments, die Sie bei der Dokumentenanalyse ignorieren möchten, wie z. B. Wasserzeichen, Kopf- und Fußzeilen, oder so komplex wie eine Neuformatierung des Dokuments. Im Folgenden finden Sie einige Beispiele für die Vorverarbeitung, die Sie möglicherweise in der Ladephase kapseln möchten:
- Entfernen oder kommentieren Sie Elemente, die Sie ignorieren möchten.
- Ersetzen Sie Bildverweise durch Bildbeschreibungen. In dieser Phase verwenden Sie eine LLM, um eine Beschreibung für das Bild zu generieren und das Dokument mit dieser Beschreibung zu aktualisieren. Wenn Sie in der Dokumentanalyse festgestellt haben, dass es umgebenden Text gibt, der wertvollen Kontext für das Bild bietet, übergeben Sie diesen Text zusammen mit dem Bild an die LLM.
- Laden Sie Bilder in den Dateispeicher wie Azure Data Lake herunter, oder kopieren Sie sie, um getrennt vom Dokumenttext verarbeitet zu werden. Wenn Sie in der Dokumentanalyse festgestellt haben, dass es umgebenden Text gibt, der wertvollen Kontext für das Bild bietet, müssen Sie diesen Text zusammen mit dem Bild im Dateispeicher speichern.
- Formatieren Sie Tabellen so, dass sie einfacher verarbeitet werden.
Speichern des Ergebnisses des Ladecodes
Es gibt mehrere Gründe, aus denen Sie das Ergebnis des Ladecodes beibehalten möchten. Ein Grund dafür ist, dass Sie die Option haben möchten, die Dokumente zu überprüfen, nachdem sie geladen und vorverarbeitet wurden, aber bevor die Chunkinglogik ausgeführt wird. Ein weiterer Grund ist, dass Sie während der Entwicklung oder in der Produktion möglicherweise unterschiedliche Chunkinglogik für denselben vorverarbeiteten Code ausführen möchten. Durch das Beibehalten des geladenen Codes wird dieser Prozess beschleunigt.
Ausführen von Lade- und Chunkingcode in separaten Prozessen
Durch das Trennen des Lade- und Chunkingcodes in separate Prozesse können mehrere Chunkingimplementierungen mit demselben vorverarbeiteten Code ausgeführt werden. Diese Trennung ermöglicht es Ihnen auch, Lade- und vcode in verschiedenen Computeumgebungen und auf unterschiedlicher Hardware auszuführen. Außerdem ermöglicht Ihnen dieses Design, die für das Laden und Chunking verwendete Rechenleistung unabhängig voneinander zu skalieren.
Kombinieren von Lade- und Chunkingphasen
Das Kombinieren des Lade- und Chunkingcodes ist in den meisten Fällen eine einfachere Implementierung. Viele der Vorgänge, die Sie in der Vorverarbeitung in einer separaten Ladephase in Betracht ziehen, können in der Chunkingphase durchgeführt werden. Anstatt z. B. Bild-URLs durch eine Beschreibung in der Ladephase zu ersetzen, kann die Chunkinglogik Aufrufe an die LLM ausführen, um eine Textbeschreibung abzurufen und sie zu segmentieren.
Wenn Sie Über Dokumentformate wie HTML verfügen, die Tags mit Verweisen auf Bilder enthalten, müssen Sie sicherstellen, dass der Leser oder Parser, den der Chunkingcode verwendet, die Tags nicht entfernt. Der Chunkingcode muss in der Lage sein, Bildverweise zu identifizieren.
Empfehlungen
Im Folgenden sind einige Empfehlungen aufgeführt, die Sie bei der Bestimmung berücksichtigen sollten, ob Sie Ihre Chunkinglogik kombinieren oder trennen.
- Beginnen Sie mit der Kombination von Lade- und Chunkinglogik. Trennen Sie sie, wenn Ihre Lösung dies benötigt.
- Vermeiden Sie das Konvertieren von Dokumenten in ein Zwischenformat, wenn Sie die Prozesse trennen möchten. Solche Vorgänge können zu Verlusten führen.
Chunking-Ansätze
In diesem Abschnitt erhalten Sie eine Übersicht über einige gängige Chunking-Ansätze. Diese Liste erhebt keinen Anspruch auf Vollständigkeit, sondern stellt vielmehr einige gemeinsame repräsentative Ansätze dar. Sie können bei der Implementierung mehrere Ansätze verwenden, z. B. die Kombination eines großen Sprachmodellss, um eine Textdarstellung eines Bilds mit vielen der aufgeführten Ansätze zu erhalten.
Jeder Ansatz wird von einer zusammengefassten Entscheidungsmatrix begleitet, die die Tools, damit verbundenen Kosten und vieles mehr hervorhebt. Der technische Aufwand und die Verarbeitungskosten sind subjektiv und werden im relativen Vergleich berücksichtigt.
Satzbasierte Analyse
Bei diesem einfachen Ansatz werden Textdokumente in Blöcke unterteilt, die aus vollständigen Sätzen bestehen. Die Vorteile dieses Ansatzes bestehen darin, dass er kostengünstig zu implementieren ist, niedrige Verarbeitungskosten hat und auf jedes textbasierte Dokument angewendet werden kann, das als Fließtext oder in vollständigen Sätzen geschrieben ist. Eine Herausforderung bei diesem Ansatz besteht darin, dass jeder Teil möglicherweise nicht den vollständigen Kontext eines Gedankens oder einer Bedeutung erfassen kann. Häufig müssen mehrere Sätze zusammengenommen betrachtet werden, um die semantische Bedeutung zu erfassen.
Tools: SpaCy Sentence Tokenizer, LangChain Recursive Text Splitter, NLTK Sentence Tokenizer
Technischer Aufwand: Niedrig
Verarbeitungskosten: Niedrig
Anwendungsfälle: Unstrukturierte Dokumente, die als Fließtext oder in vollständigen Sätzen geschrieben sind; Ihr Dokumentkorpus enthält eine untragbare Anzahl verschiedener Dokumenttypen, um einzelne Chunking-Sstrategien zu erstellen
Beispiele: Vom Benutzer generierte Inhalte wie offenes Feedback aus Umfragen, Forumbeiträgen, Rezensionen, E-Mail-Nachrichten, einem Roman oder einem Essay
Analyse mit fester Größe (mit Überlappung)
Bei diesem Ansatz wird ein Dokument basierend auf einer festen Anzahl von Zeichen oder Token in Blöcke unterteilt und ermöglicht eine Überschneidung von Zeichen zwischen Blöcken. Dieser Ansatz hat viele der gleichen Vor- und Nachteile wie die satzbasierte Analyse. Sein Vorteil gegenüber der satzbasierten Analyse besteht darin, dass es möglich ist, Blöcke mit semantischer Bedeutung abzurufen, die mehrere Sätze umfassen.
Sie müssen die feste Größe der Blöcke und die Überlappungsmenge auswählen. Da sich die Ergebnisse für unterschiedliche Dokumenttypen unterscheiden, ist es am besten, ein Tool wie die HuggingFace-Blockschnellansicht zu verwenden, um explorative Analysen durchzuführen. Mit Tools wie diesem können Sie visualisieren, wie Ihre Dokumente in Anbetracht Ihrer Entscheidungen segmentiert werden. BERT-Tokens anstelle von Zeichenzahlen zu verwenden, wenn man Parsing mit fester Größe verwendet. BERT-Token basieren auf aussagekräftigen Spracheinheiten, sodass sie mehr semantische Informationen erhalten als die Zeichenanzahl.
Tools: LangChain recursive text splitter, Hugging Face chunk visualizer
Technischer Aufwand: Niedrig
Verarbeitungskosten: Niedrig
Anwendungsfälle: Unstrukturierte Dokumente, die in Fließtext oder Nicht-Fließtext mit vollständigen oder unvollständigen Sätzen geschrieben wurden. Ihr Korpus von Dokumenten enthält eine untragbare Anzahl verschiedener Dokumenttypen, um einzelne Chunking-Strategien zu erstellen
Beispiele: Vom Benutzer generierte Inhalte wie offenes Feedback aus Umfragen, Forumbeiträgen, Rezensionen, E-Mail-Nachrichten, persönlichen oder Recherchenotizen oder Listen
Benutzerdefinierter Code
Bei diesem Ansatz werden Dokumente mithilfe von benutzerdefiniertem Code analysiert, um Blöcke zu erstellen. Dieser Ansatz eignet sich am besten für textbasierte Dokumente, bei denen die Struktur entweder bekannt ist oder abgeleitet werden kann und eine hohe Kontrolle über die Blockerstellung erforderlich ist. Sie können Textanalysetechniken wie reguläre Ausdrücke verwenden, um Blöcke basierend auf Mustern in der Struktur des Dokuments zu erstellen. Das Ziel ist es, Blöcke zu erstellen, die eine ähnliche Länge haben sowie Blöcke mit unterschiedlichem Inhalt. Viele Programmiersprachen bieten Unterstützung für reguläre Ausdrücke, und einige verfügen über Bibliotheken oder Pakete, die elegantere Zeichenfolgen-Manipulationsfeatures bieten.
Tools: Python (re, regex, BeautifulSoup, lxml, html5lib, marko), R (stringr, xml2), Julia (Gumbo.jl)
Technischer Aufwand: Mittel
Verarbeitungskosten: Niedrig
Anwendungsfälle: Halbstrukturierte Dokumente, deren Struktur abgeleitet werden kann
Beispiele: Patentanmeldungen, Forschungspapiere, Versicherungsrichtlinien, Skripts und Drehbücher
Large Language Model-Erweiterung
Large Language Models können zum Erstellen von Blöcken verwendet werden. Häufige Anwendungsfälle sind die Verwendung eines großen Sprachmodells, z. B. GPT-4, zum Generieren von Textdarstellungen von Bildern oder Zusammenfassungen von Tabellen, die als Blöcke verwendet werden können. Die Large Language Model-Erweiterung wird mit anderen Chunking-Ansätzen wie benutzerdefiniertem Code verwendet.
Wenn Sie im Bildbereich des Dokumentanalyseabschnitts festgestellt haben, dass der Text vor oder nach dem Bild erforderlich ist, um einige Fragen zu beantworten, müssen Sie diesen zusätzlichen Kontext an das große Sprachmodell übergeben. Es ist wichtig, zu experimentieren, ob dieser zusätzliche Kontext die Leistung Ihrer Lösung verbessert oder nicht verbessert.
Wenn die Chunkinglogik die Bildbeschreibung in mehrere Blöcke aufteilt, stellen Sie sicher, dass Sie die Bild-URL in jeden Block einschließen. Durch die Aufnahme der Bild-URL in jeden Datenblock wird sichergestellt, dass Metadaten für alle Abfragen zurückgegeben werden, die das Bild bedient, insbesondere für Szenarien, in denen der Endbenutzer die Möglichkeit benötigt, über diese URL auf das Quellbild zuzugreifen oder Rohbilder während der Inferenzzeit verwenden möchte.
Tools: Azure OpenAI, OpenAI
Technischer Aufwand: Mittel
Verarbeitungskosten: Hoch
Anwendungsfälle: Bilder, Tabellen
Beispiele: Generieren von Textdarstellungen von Tabellen und Bildern, Zusammenfassen von Transkriptionen aus Besprechungen, Reden, Interviews oder Podcasts
Dokumentlayoutanalyse
Dokumentlayoutanalysebibliotheken und -dienste kombinieren Funktionen zur optischen Zeichenerkennung (OCR) mit Deep Learning-Modellen, um sowohl die Struktur von Dokumenten als auch Text zu extrahieren. Strukturelemente können Kopf- und Fußzeilen, Titel, Abschnittsüberschriften, Tabellen und Abbildungen enthalten. Ziel ist es, den in den Dokumenten enthaltenen Inhalten eine bessere semantische Bedeutung zu verleihen.
Dokumentlayoutanalysebibliotheken und -dienste machen ein Modell verfügbar, das den Inhalt (Struktur und Text) des Dokuments darstellt. Sie müssen weiterhin Code schreiben, der mit dem Modell interagiert.
Hinweis
Azure KI Dokument Intelligenz ist ein cloudbasierter Dienst, der erfordert, dass Sie Ihr Dokument in den Dienst hochladen müssen. Sie müssen sicherstellen, dass Ihre Sicherheits- und Compliancebestimmungen es Ihnen ermöglichen, Dokumente in Dienste wie diese hochzuladen.
Tools: Azure KI Dokument Intelligenz-Dokumentanalysemodelle, Donut, Layout Parser
Technischer Aufwand: Mittel
Verarbeitungskosten: Mittel
Anwendungsfälle: Halbstrukturierte Dokumente
Beispiele: Newsartikel, Webseiten, Lebensläufe
Vordefiniertes Modell
Es gibt Dienste wie Anwendungsfälle, die vorgefertigte Modelle bieten, die Sie für verschiedene Dokumenttypen nutzen können. Einige Modelle werden für bestimmte Dokumenttypen trainiert, z. B. das Formular „US Tax W-2“, während andere auf ein breiteres Genre von Dokumenttypen wie z. B. eine Rechnung abzielen.
Tools: Vorgefertigte Anwendungsfälle-Modelle, Power Automate Intelligent Document Processing, LayoutLMv3
Technischer Aufwand: Niedrig
Verarbeitungskosten: Mittel/Hoch
Anwendungsfälle: Strukturierte Dokumente, bei denen ein vordefiniertes Modell vorhanden ist
Spezifische Beispiele: Rechnungen, Belege, Krankenversicherungskarte, W-2-Formular
Benutzerdefiniertes Modell
Für stark strukturierte Dokumente, bei denen kein vordefiniertes Modell vorhanden ist, müssen Sie möglicherweise ein benutzerdefiniertes Modell erstellen. Dieser Ansatz kann für Bilder oder Dokumente effektiv sein, die eine starke Struktur aufweisen, was die Verwendung von Textanalysetechniken erschwert.
Tools: Benutzerdefinierte Azure KI Dokument Intelligenz-Modelle,Tesseract
Technischer Aufwand: Hoch
Verarbeitungskosten: Mittel/Hoch
Anwendungsfälle: Strukturierte Dokumente, bei denen kein vordefiniertes Modell vorhanden ist
Beispiele: Reparatur- und Wartungspläne für Kraftfahrzeuge, akademische Zeugnisse und Unterlagen, technische Handbücher, Betriebsverfahren, Wartungsrichtlinien
Struktur des Dokuments
Die Dokumente sind unterschiedlich stark strukturiert. Einige Dokumente, z. B. Regierungsformulare, weisen eine komplexe und bekannte Struktur auf (Beispiel: W-2 U.S.-Steuerdokument). Am anderen Ende des Spektrums stehen unstrukturierte Dokumente wie Freiformnotizen. Der Grad der Struktur eines Dokumenttyps ist ein guter Ausgangspunkt für die Bestimmung eines effektiven Chunking-Ansatzes. Es gibt zwar keine festen Regeln, aber dieser Abschnitt enthält einige Leitlinien, die Sie beachten sollten.
Abbildung 1. Chunking-Ansatz passend zur Dokumentstruktur
Strukturierte Dokumente
Strukturierte Dokumente, die manchmal als Dokumente im festen Format bezeichnet werden, haben definierte Layouts. Die Daten in diesen Dokumenten befinden sich an festen Speicherorten. Beispielsweise steht das Datum oder der Nachname des Kunden an derselben Stelle in jedem Dokument desselben festen Formats. Beispielhaft für Dokumente im festen Format ist das Steuerdokument „W-2 U.S“.
Feste Formatdokumente können gescannte Bilder von Originaldokumenten sein, die manuell ausgefüllt wurden oder komplexe Layoutstrukturen aufweisen, wodurch sie mit einem einfachen Textanalyseansatz schwierig verarbeitet werden können. Ein gängiger Ansatz für die Verarbeitung komplexer Dokumentstrukturen besteht darin, Machine Learning-Modelle zu verwenden, um Daten zu extrahieren und die semantische Bedeutung auf diese Daten anzuwenden, sofern möglich.
Beispiele: W-2-Formular, Versicherungskarte
Gängige Ansätze: Vordefinierte Modelle, benutzerdefinierte Modelle
Halbstrukturierte Dokumente
Halbstrukturierte Dokumente verfügen nicht über ein festes Format oder Schema, wie das W-2-Formular, sind aber konsistent hinsichtlich Format oder Schema. Beispielsweise sind alle Rechnungen nicht gleich angelegt, aber im Allgemeinen verfügen sie über ein einheitliches Schema. Eine Rechnung hat in der Regel eine invoice number und eine Art bill to und ship to einen Namen und eine Adresse, unter all den anderen Daten. Eine Webseite hat vielleicht keine Schemakonsistenz, aber sie hat ähnliche Struktur- oder Layoutelemente, wie z. B. body, title, H1 und p, die verwendet werden können, um dem umgebenden Text semantische Bedeutung hinzuzufügen.
Wie strukturierte Dokumente sind auch halbstrukturierte Dokumente mit komplexen Layoutstrukturen mit Textanalyse nur schwer zu verarbeiten. Für diese Dokumenttypen sind Machine Learning-Modelle ein guter Ansatz. Für bestimmte Bereiche gibt es vordefinierte Modelle, die konsistente Schemas wie Rechnungen, Verträge oder Krankenversicherung aufweisen. Erwägen Sie das Erstellen von benutzerdefinierten Modellen für komplexe Strukturen, bei denen kein vordefiniertes Modell vorhanden ist.
Beispiele: Rechnungen, Belege, Webseiten, Markdowndateien
Allgemeine Ansätze: Dokumentanalysemodelle
Abgeleitete Struktur
Einige Dokumente weisen eine Struktur auf, werden aber nicht in Markup geschrieben. Für diese Dokumente muss die Struktur abgeleitet werden. Ein gutes Beispiel ist das folgende EU-Verordnungsdokument.
Abbildung 2. EU-Verordnung mit abgeleiteter Struktur
Da Sie die Struktur des Dokuments deutlich verstehen können und keine bekannten Modelle dafür vorhanden sind, können Sie bestimmen, dass Sie benutzerdefinierten Code schreiben können. Bei einem Dokumentformat wie diesem lohnt sich der Aufwand für die Erstellung eines benutzerdefinierten Modells möglicherweise nicht, je nachdem, wie viele verschiedene Dokumente dieses Typs Sie bearbeiten. Wenn Ihr Korpus beispielsweise aus allen EU-Vorschriften oder US-amerikanischen Staatsgesetzen besteht, kann ein benutzerdefiniertes Modell ein guter Ansatz sein. Wenn Sie mit einem einzelnen Dokument arbeiten, wie der EU-Verordnung im Beispiel, kann benutzerdefinierter Code kostengünstiger sein.
Beispiele: Rechtsdokumente, Skripts, Fertigungsspezifikationen
Allgemeine Ansätze: Benutzerdefinierter Code, benutzerdefinierte Modelle
Unstrukturierte Dokumente
Ein guter Ansatz für Dokumente mit wenig bis keiner Struktur sind satzbasierte oder feste Größe mit Überlappungsansätzen.
Beispiele: Vom Benutzer generierte Inhalte wie offenes Feedback aus Umfragen, Forumbeiträgen, Rezensionen, E-Mail-Nachrichten und persönlichen oder Recherchenotizen
Häufige Ansätze: Satzbasiert oder grenzbasiert mit Überlappung
Experimentieren
Obwohl die für jeden Abschnittsansatz am besten geeigneten Vorgehensweisen aufgeführt sind, sind in der Praxis alle Ansätze für jeden Dokumenttyp geeignet. Beispielsweise kann die satzbasierte Analyse für stark strukturierte Dokumente geeignet sein, oder ein benutzerdefiniertes Modell eignet sich für unstrukturierte Dokumente. Ein Teil der Optimierung Ihrer RAG-Lösung besteht darin, mit verschiedenen Chunking-Ansätzen zu experimentieren, wobei die Anzahl Ihrer Ressourcen, die technischen Fähigkeiten Ihrer Ressourcen und das Volumen der zu verarbeitenden Dokumente berücksichtigt werden müssen. Um eine optimale Chunking-Strategie zu erreichen, müssen Sie die Vorteile und Nachteile der einzelnen getesteten Ansätze beobachten, um sicherzustellen, dass Sie den geeigneten Ansatz für Ihren Anwendungsfall auswählen.