Ihr 50-seitiges Rechtsdokument wird in Claude hochgeladen, und das Modell gibt eine Analyse basierend auf Seite 3 zurück. Der Rest existiert in einer Token-Leere. Das ist kein Halluzinationsproblem – es ist ein Kontextfensterproblem, und es legt mehr Produktionssysteme lahm als schlechte Prompts.
Das Kontextfenster ist wertvoller Platz. Jeder Token, den Sie verwenden – Prompt, Dokumente, Gesprächsverlauf, Systemanweisungen – belegt Platz, der für Ihre eigentliche Aufgabe verwendet werden könnte. Überschreiten Sie das Limit, und das Modell hört entweder auf zu antworten oder, schlimmer noch, beginnt, die ältesten Informationen zu ignorieren, um Platz für neue Eingaben zu schaffen. Zu verstehen, wie dieser Platz verwaltet wird, ist der Unterschied zwischen einem funktionierenden System und einem, das mysteriöserweise am Donnerstag ausfällt, wenn Ihr Dokument länger wurde.
Ihr Kontextbudget verstehen
Beginnen Sie damit, genau zu wissen, was Sie zur Verfügung haben.
Claude 3.5 Sonnet bietet Ihnen 200.000 Token. GPT-4o bietet Ihnen 128.000 Token (oder 4.096, wenn Sie das ältere Basismodell verwenden). Mistral Large bietet 32.000 Token. Diese Zahlen klingen groß, bis Sie beginnen, reale Inhalte zu messen.
Eine typische Seite mit Geschäftstexten umfasst etwa 250–350 Token. Ein 50-seitiges Dokument kostet Sie 12.500–17.500 Token, bevor Sie eine einzige Anweisung geschrieben haben. Eine lange Unterhaltung mit 20 Austauschen verbraucht 4.000–8.000 Token. Das lässt Ihnen tatsächlichen Arbeitsraum, gemessen an dem, was übrig bleibt – Ihr „Verarbeitungsbudget“.
Berechnen Sie Ihre genauen Token-Kosten vor dem Einsatz. Verwenden Sie den Tokenizer des Modellproviders:
# Python-Beispiel mit Anthropic's Tokenizer
import anthropic
client = anthropic.Anthropic()
with open('document.txt', 'r') as f:
doc_text = f.read()
response = client.messages.count_tokens(
model="claude-3-5-sonnet-20241022",
messages=[{"role": "user", "content": doc_text}]
)
print(f"Dokument-Token: {response.input_tokens}")
print(f"Verbleibendes Budget: {200000 - response.input_tokens}")
Das ist nicht optional. Raten kostet Sie fehlgeschlagene Abfragen und verschwendete API-Ausgaben.
Die drei Komprimierungstechniken, die wirklich funktionieren
Sie haben drei Hebel: Extrahieren Sie das Wesentliche, fassen Sie strategisch zusammen oder teilen Sie die Arbeit in Chunks auf. Die meisten Leute versuchen, direkt zur Zusammenfassung überzugehen, und scheitern, weil sie die falschen Teile zusammenfassen.
1. Extraktion vor Zusammenfassung
Fassen Sie nicht alles zusammen. Extrahieren Sie zuerst die Abschnitte, die für Ihre eigentliche Frage relevant sind.
Wenn Sie einen Vertrag auf Zahlungsbedingungen analysieren, benötigen Sie keine Zusammenfassungen der Unternehmensgeschichte oder Produktspezifikationen. Ziehen Sie die relevanten Klauseln heraus, übergeben Sie diese an das LLM und halten Sie 80 % Ihres Kontextfensters frei.
Schlechter Ansatz:
# Den gesamten 50-seitigen Dokument zusammenfassen
Prompt: "Fassen Sie dieses Rechtsdokument in 500 Wörtern zusammen."
[50-seitiges Dokument]
"Wie lauten die Zahlungsbedingungen?"
Guter Ansatz:
# Relevante Abschnitte extrahieren, dann antworten
Prompt: "Extrahieren Sie alle Abschnitte, die 'Zahlung', 'Rechnung', 'Fälligkeitsdatum' oder 'Bedingungen' erwähnen. Behalten Sie die exakte Formulierung bei."
[50-seitiges Dokument]
# Dann in einem zweiten Aufruf oder demselben Aufruf mit extrahiertem Text:
Prompt: "Basierend auf diesen Abschnitten, was sind die Zahlungsbedingungen und wann sind Rechnungen fällig?"
[Nur extrahierte Abschnitte – ca. 2000 Token statt 15000]
Verwenden Sie Keyword-Extraktion, Regex-Muster oder einen leichten Suchdurchlauf (Claude Mini bei kürzeren Dokumenten), um relevante Chunks zu identifizieren, bevor Sie sie an Ihr Hauptanalysemodell übergeben.
2. Hierarchische Zusammenfassung
Wenn die Extraktion nicht praktikabel ist – sagen wir, Sie benötigen den gesamten Kontext –, fassen Sie in Schichten zusammen. Fassen Sie nicht 50 Seiten in einem Durchgang auf 500 Wörter zusammen. Fassen Sie Chunks zu Zusammenfassungen zusammen, und fassen Sie dann diese Zusammenfassungen zusammen.
Teilen Sie das Dokument in 5–10 Seiten umfassende Chunks auf. Fassen Sie jeden auf 150–200 Token zusammen. Fassen Sie dann diese Zusammenfassungen zusammen. Sie komprimieren 15.000 Token auf 500–800, während Sie Struktur und Beziehungen beibehalten.
Dies bewahrt Nuancen besser als eine aggressive Einzelzusammenfassung, da das Modell niemals willkürlich Details verwirft – es verdichtet sich bei jeder Schicht proportional.
3. Sliding Window Processing für Konversationen
Lange Gespräche füllen den Kontext schnell. Behalten Sie nicht die gesamte Historie. Behalten Sie aktuelle Austausche (die letzten 5–10) bei, plus Zusammenfassungen älterer.
# Verwaltung des Gesprächskontexts
conversation = [
{"role": "user", "content": "Erzähl mir von AWS-Preisen"},
{"role": "assistant", "content": "AWS-Preise sind..."}
# ... 15 weitere Austausche ...
]
# Vor dem API-Aufruf, kürzen und zusammenfassen
if conversation_token_count > 100000:
# Letzte 5 Austausche beibehalten
recent = conversation[-10:] # 5 Benutzer/Assistent-Paare
# Alles davor zusammenfassen
older_summary = summarize_conversation(conversation[:-10])
# Rekonstruieren mit explizitem Verlaufsmarker
trimmed = [
{"role": "system",
"content": "Früher in diesem Gespräch: " + older_summary}
] + recent
Temperatur und Sampling: Versteckte Kontextprobleme
Sie können die Kontext-Effizienz auch durch das Modellverhalten steuern, nicht nur durch die Eingabegröße.
Eine niedrigere Temperatur (0,3–0,5) konzentriert das Modell auf das, was es bereits weiß – nützlich für die Extraktion von Fakten aus bereitgestelltem Kontext. Eine höhere Temperatur (0,7–1,0) erhöht die Zufälligkeit, was Token für weniger vorhersagbare Ausgaben verbrennt.
Für kontextintensive Aufgaben („nur aus diesem Dokument antworten“) führen Sie bei 0,3–0,4 aus. Die Aufmerksamkeit des Modells bleibt auf Ihrer Eingabe, nicht auf der Erkundung alternativer Formulierungen.
Der Parameter max_tokens ist ebenfalls wichtig. Stellen Sie ihn bewusst ein. Wenn Sie Zahlungsbedingungen extrahieren, benötigen Sie keine Ausgaben von 4.096 Token. Stellen Sie max_tokens=500 ein. Dies reserviert Budget für Ihre eigentliche Aufgabe, anstatt das Modell in leeren Raum schweifen zu lassen.
Das echte Setup: Ein Produktionsmuster
Hier ist, was im großen Maßstab wirklich funktioniert:
- Extraktionsschicht: Verwenden Sie Regex, Stichwortsuche oder ein schnelles Modell (Claude 3.5 Haiku), um relevante Abschnitte aus großen Dokumenten zu extrahieren. Kosten: minimal.
- Token-Budget-Prüfung: Zählen Sie die Token der extrahierten Abschnitte. Wenn weniger als 30.000 Token bei Claude Sonnet, fortfahren. Wenn nicht, zusammenfassen.
- Bei Bedarf zusammenfassen: Hierarchische Zusammenfassungen von Chunks, keine aggressive Einzelpass-Kompression.
- Mit Kontext abfragen: Übergeben Sie extrahiertes oder zusammengefasstes Material plus explizite Anweisungen: „Antworten Sie nur basierend auf diesen Abschnitten. Verwenden Sie kein externes Wissen.“
- Gesprächs-Kürzung: Nach 10 Benutzernachrichten einen Schnappschuss der Konversation erstellen, diese zusammenfassen und ein neues Fenster starten.
Der Engpass ist selten das Modell. Es ist die Vorarbeit vor dem API-Aufruf.
Beginnen Sie mit Token-Zählung, nicht mit Zusammenfassung
Heute: Messen Sie Ihre tatsächlichen Dokumente. Führen Sie sie durch den Tokenizer für das von Ihnen verwendete Modell. Berechnen Sie, wie viele Token nach dem Hochladen Ihres Dokuments übrig bleiben. Diese verbleibende Zahl ist Ihr tatsächliches Arbeitsbudget.
Wenn es unter 30.000 für Claude Sonnet oder unter 50.000 für Produktionsarbeiten liegt, müssen Sie extrahieren, nicht zusammenfassen. Wenn es negativ ist, benötigen Sie einen ganz anderen Ansatz – Dokumente aufteilen, Vektorsuche verwenden, um nur relevante Abschnitte abzurufen, oder ein Modell mit einem größeren Fenster verwenden.
Die meisten Kontextprobleme werden nicht durch bessere Prompts gelöst. Sie werden gelöst, indem man das Modell nicht bittet, mehr zu verarbeiten, als es benötigt.