Large Language Models (LLMs) entwickeln sich zur bevorzugten Technologie, wenn es darum geht, große Textmengen zu analysieren, zusammenzufassen und durchsuchbar zu machen. In der Praxis stoßen diese Systeme jedoch schnell an Grenzen: Kontextfenster sind beschränkt, Durchsatzprobleme bremsen die Verarbeitung und selbst moderne Retrieval-Methoden übersehen manchmal entscheidende Inhalte.
Im Folgenden werden drei zentrale Pain Points beim LLM-basierten Dokumenten-Processing vorgestellt – zusammen mit den wichtigsten Lessons Learned aus realen Projekten und den Strategien, die sich erfolgreich bewährt haben.
Pain Point 1: Kontextgröße bleibt ein Engpass
Selbst aktuelle Long-Context-Modelle mit Hunderttausenden Tokens können nicht alles gleichzeitig verarbeiten. Studien zeigen, dass LLMs relevante Informationen in sehr langen Eingaben oft nicht konsistent nutzen (das „Lost in the Middle²“-Phänomen). Wer versucht, 50 Dokumente gleichzeitig zu summarizen, wird zwangsläufig wichtige Details verlieren.
Strategie:
- Mehrstufige Orchestrierung mit Ansätzen wie Map-Reduce oder Refine.
- Beim Map-Reduce werden einzelne Dokumente oder größere Textblöcke separat verarbeitet und vorverdichtet (Map), bevor ein Konsolidierungsschritt (Reduce) die Ergebnisse zu einem Endoutput zusammenführt.
- Beim Refine-Ansatz entsteht zunächst ein Entwurf aus dem ersten Chunk. Danach wird dieser Entwurf iterativ mit weiteren Chunks verfeinert.
- Beide Methoden erhöhen zwar die Latenz, ermöglichen aber Skalierbarkeit und bessere Vollständigkeit.
Pain Point 2: Durchsatz & Latenz pro Anfrage
Eine einzelne Anfrage kann Sekunden oder sogar eine Minute dauern. Während dies oft akzeptabel ist, profitieren Nutzer stark von früher Rückmeldung, dass ihr Request verarbeitet wird. Kritischer ist jedoch der Durchsatz: Plattformen wie Azure OpenAI begrenzen die Anzahl der Tokens oder Requests pro Minute. Sobald diese Limits erreicht sind, warten Nutzer oft 30–90 Sekunden, bis die Verarbeitung startet.
Strategie:
- Streaming einsetzen, um auch bei längeren Latenzen frühe Rückmeldungen zu geben.
- Prompt Caching nutzen, um statische Instruktionen oder Kontexte nicht ständig neu berechnen zu müssen.
- Anfragevolumen gezielt steuern und Budgets für Tokens bzw. Requests pro Minute managen.
Pain Point 3: Mehr Dokumente = nicht automatisch bessere Ergebnisse
Die Verarbeitung zusätzlicher Dokumente erhöht nicht zwangsläufig die Genauigkeit. Auch mit Hybrid Search (semantisch + Keyword) können relevante Elemente durchrutschen. Daraus entsteht das klassische Top-k-Dilemma:
- Top 10 → schnell, aber Gefahr, die Hälfte der relevanten Infos zu verpassen.
- Top 20 → bessere Abdeckung, aber doppelte Latenz.
- Top 30 → noch vollständiger, aber dreimal langsamer und teurer.
Strategie:
- Klare Modi anbieten: Schnell (Top 10, niedrige Latenz, Streaming) vs. Gründlich (Top 20–30, Map-Reduce, langsamer).
- Domänenwissen der Nutzer einbeziehen: Filter und Auswahloptionen anbieten, um relevante Dokumente bewusst hinzuzufügen.
Lessons Learned aus Kundenprojekten
- Geschwindigkeit schlägt oft Vollständigkeit
Nutzer priorisieren in vielen Fällen die schnelle Antwort. Wenn dies der Standardmodus ist, sollte die Optimierung auf Time to First Token ausgerichtet sein.
- Transparenz schafft Vertrauen
Dauert der gründliche Modus länger, sollte dies klar in der UI angezeigt werden. Nutzer akzeptieren Trade-offs eher, wenn sie explizit kommuniziert werden.
- Modellgrößen kombinieren
Kleine, kostengünstige Modelle eignen sich ideal für Vorverarbeitung (Klassifikation, Ranking). Größere Modelle sollten für finale Antworten reserviert werden – dies spart Kosten und verbessert Qualität sowie Geschwindigkeit.
- Search bleibt essenziell
Nutzer sind mit Suchtools vertraut. Die Integration von Filter- und Auswahlmöglichkeiten erhöht die Relevanz und reduziert unnötige Verarbeitung.
Praktische Beispiele
- Customer Service Knowledge:
Agents erhalten sofort Antworten auf Basis der Top 10 Dokumente. Für komplexere Fälle schalten sie in den Thorough Mode, der per Map-Reduce über 30 Dokumente arbeitet.
- Legal & Compliance:
Hier ist Vollständigkeit entscheidend. Der Standardmodus ist Thorough, ergänzt durch Filter wie Zeiträume oder Dokumenttypen.
- Technische Dokumentation:
Kleinere Modelle clustern und taggen zunächst Abschnitte, bevor ein größeres Modell die finale Zusammenfassung erstellt. So wird verhindert, dass irrelevante Inhalte das Kontextfenster überfüllen.
Zentrale Erkenntnisse
- Kontextlimits bleiben der Flaschenhals – selbst mit langen Kontextfenstern ist strukturierte Retrieval-Logik unverzichtbar.
- Durchsatz ist die eigentliche Hürde – Streaming, Caching und Queue Management sind entscheidend.
- Mehr Dokumente bedeuten höhere Kosten und Latenzen – Transparenz über diesen Trade-off ist Pflicht.
- Nutzererwartungen priorisieren – die meisten schätzen Geschwindigkeit höher als Vollständigkeit.
²Quelle: https://arxiv.org/abs/2307.03172
