Kontext-Tokens bei LLMs: Zuteilung und Konfiguration

Was ist Kontext?

Der Kontext eines LLM (Large Language Model) bezeichnet die Menge an Informationen, die das Modell bei der Textgenerierung berücksichtigen kann. Kontext fungiert als „Gedächtnis“ des Modells und ermöglicht es, die nächste Aktion auf Basis bereits gesehener oder generierter Inhalte zu bestimmen. Der Kontext kann einen einzelnen Satz, einen Absatz, ein Dokument oder eine Sammlung mehrerer Dokumente umfassen – abhängig von Architektur und Design des Modells.

Kontext ist für Sprachmodelle essenziell, da er dem Modell hilft, die aktuelle Aufgabe zu verstehen und auf Basis vorheriger Informationen kohärente und relevante Antworten zu generieren. In einem Gespräch umfasst der Kontext alle bisherigen Beiträge, sodass das Modell Antworten erzeugen kann, die zum Thema und Ton der Konversation passen.

Aufgrund von Rechenressourcen- und Speicherbeschränkungen verfügen Sprachmodelle jedoch in der Regel über eine feste Kontextlänge. Die Kontextlänge gängiger Modelle liegt derzeit zwischen etwa 128.000 und 1.000.000 Tokens. Mit der Weiterentwicklung von LLMs wird die Unterstützung längerer Kontexte Standard. Dennoch ist ein präzises und effizientes Kontextmanagement hinsichtlich Token-Kosten, Antwortqualität und Reaktionszeit in kommerziellen Szenarien entscheidend.

Ein Token kann ein Wort, ein Satzzeichen oder eine sonstige sprachliche Einheit sein.

Konfigurationsstrategie für LLM-Kontext-Tokens

Da der Kontext die „Informationsmenge ist, die ein LLM auf einmal verarbeiten kann“, ist die Ressourcenzuteilung innerhalb dieses begrenzten Informationsraums ein zentraler Aspekt beim Agenten-Design. GPTBots definiert den LLM-Kontext als: Langzeitgedächtnis, Kurzzeitgedächtnis, Identitäts-Prompts, Nutzer:innenfrage, Tools-Daten und Wissensdaten. Eine einzelne LLM-Interaktion kann all diese Kontexttypen enthalten, wobei jeder eine unterschiedliche Priorität besitzt.

Hinweis: Überschreitet die Gesamtlänge aller Kontexttypen bei einer LLM-Interaktion das LLM-Limit, kürzt GPTBots die Kontexttypen mit der niedrigsten Priorität, um die Erfolgsquote der LLM-Aufrufe zu gewährleisten.

Nutzer:innenfrage (Benutzereingabe)

Die aktuellste Eingabe der Nutzer:innen im Gespräch mit dem Agenten umfasst verschiedene Nachrichtentypen, die über das Eingabefeld gesendet werden:

• Manuell eingegebene Textnachrichten
• Per Audio aufgezeichnete Audionachrichten
• Hochgeladene Bildnachrichten, Videonachrichten, Dokumentnachrichten, Audionachrichten und Dateinachrichten als Anhang

Hinweis:
Ist die Option „Agent-Configuration-Input-Attachment“ auf Systemerkennung gesetzt, erkennt GPTBots alle hochgeladenen Anhänge als Textinhalt und behandelt sie als Nutzer:innenfrage.
Bei Dateitypen wandelt GPTBots die Datei in einen URL-Link um, der als Nutzer:innenfrage behandelt wird.

Identitäts-Prompts

Die in GPTBots Agent für das LLM festgelegten Identitätsinformationen dienen als wichtige Leitlinie für die Arbeit des KI-Agenten. GPTBots passt dies je nach Modellversion automatisch als System- oder Entwicklermitteilung an.

• Identitäts-Prompts sind besonders in Geschäftsszenarien entscheidend und sollten klar und präzise formuliert sein, um die Arbeit und Antworten der KI gezielt zu steuern.
• In der Regel muss man sich keine Sorgen um die Länge der Identitäts-Prompts machen. Die Qualität ist wichtiger als die Länge, daher lohnt es sich, hier mehr Tokens einzusetzen.
• Bei der Erstellung von Identitäts-Prompts sind eine klare Ausdrucksweise, korrekte Logik und präzise Anweisungen entscheidend. Ein guter Identitäts-Prompt sollte Ziele, Prinzipien, Kompetenzen und Arbeitslogik klar formulieren und mehrdeutige Vorgaben vermeiden.

Kurzzeitgedächtnis

Informationen aus den letzten X Gesprächsrunden zwischen Nutzer:in und Agent werden bei jeder LLM-Anfrage mitgeführt. Ist die Kurzzeitgedächtnis-Funktion deaktiviert oder das Gespräch gerade erst gestartet, bleibt dieser Bereich leer.

Bei der Konfiguration gilt:

• Wenn das Szenario des Agenten keinen Kontext benötigt oder sich Kontext negativ auf die Antwortqualität der KI auswirkt, kann das Kurzzeitgedächtnis deaktiviert werden, um Tokens zu sparen und die Performance zu verbessern.
• Wenn der Agent stark auf Kontext angewiesen ist (z. B. um Fragen zu beantworten), sollte die Anzahl der gespeicherten Gesprächsrunden möglichst hoch gewählt werden.

Wissensdaten

Basierend auf der Nutzer:innenfrage ruft der Agent Wissensschnipsel aus der zugehörigen Wissensdatenbank per Vektorsuche ab. Stehen keine Inhalte zur Verfügung oder können keine Ergebnisse gefunden werden, bleibt dieser Bereich leer.

Bei der Konfiguration gilt:

• Wenn der Agent keine Wissensdatenbank-Abfragen benötigt, kann das Abrufen von Wissen deaktiviert werden, um Tokens zu sparen.
• Wenn der Agent stark auf Wissensdatenbank-Ergebnisse angewiesen ist (z. B. bei Dokumenten-Q&A), sollten maximale Recall-Anzahl, Relevanzscore und weitere Parameter in der „Wissensdatenbank“ passend konfiguriert werden, um Quantität und Qualität des RAG (retrieval augmented generation) sicherzustellen.

Langzeitgedächtnis

Basierend auf der Nutzer:innenfrage werden historische Gesprächsaufzeichnungen aus allen Konversationen des Agenten per Vektorsuche abgerufen. Ist die Langzeitgedächtnis-Funktion deaktiviert oder das Gespräch gerade erst gestartet, bleibt dieser Bereich leer.

Bei der Konfiguration gilt:

• Wenn das Szenario des Agenten auf historischen Gesprächsinhalten basiert (z. B. virtuelle Charaktere), sollte die Langzeitgedächtnis-Funktion aktiviert werden.
• Wird der historische Kontext nicht benötigt, kann die Funktion deaktiviert werden, um Tokens zu sparen.

Tools-Daten

Wenn das System Anfragedaten an das LLM übermittelt, werden die vom Agenten ausgewählten Tools-Daten hinzugefügt, damit das LLM das passende Tool korrekt auswählen kann. Nach erfolgreichem Tool-Aufruf müssen die vom API-Service zurückgegebenen Ergebnisse erneut an das LLM übermittelt werden. Ist die Tools-Funktion deaktiviert, bleibt dieser Bereich leer.

Bei der Konfiguration gilt:

• Wenn das Szenario des Agenten keine Tools benötigt, kann auf die Integration von Tools verzichtet werden, um Tokens zu sparen.
• Enthält ein Tool mehrere APIs, können nicht benötigte APIs in der Tool-Konfiguration deaktiviert werden. Deaktivierte APIs werden nicht an das LLM übermittelt und sparen so Tokens.

LLM-Ausgabe

Die Tokenlänge der LLM-Ausgabedaten wird beim LLM-Request festgelegt und reserviert. GPTBots unterstützt bereits individuell einstellbare LLM-Antwortlängen; dieser Bereich wird nicht durch die Länge der oben genannten Eingabebereiche beeinflusst.

Praxisbeispiel

Die Zuteilung von Kontext-Tokens wird am besten anhand eines konkreten Beispiels verdeutlicht. Angenommen, wir nutzen ein LLM-Modell mit einem Kontextlimit von 8.000 Tokens:

Szenario: Kundenservice-Assistent:in

Ein:e Online-Kundenservice-Assistent:in muss:

• Die letzten Gesprächsinhalte der Nutzer:innen im Gedächtnis behalten
• Die Produkt-Wissensdatenbank abfragen
• Die Schnittstelle zur Bestellabfrage nutzen
• Ein professionelles Service-Image wahren

Token-Management-Plan

Optimierungsvorschläge

1. Dynamische Token-Anpassung
   • Bei kurzen Nutzer:innenfragen können eingesparte Tokens automatisch für Wissensdaten verwendet werden.
   • Werden keine Tools genutzt, kann der reservierte Platz für das Kurzzeitgedächtnis verwendet werden.
2. Priorisierte Token-Verwaltung
   • Überschreiten die Gesamttokens das Limit, wird nach Priorität gekürzt:
   • Beibehalten: Nutzer:innenfrage, Kurzzeitgedächtnis, Identitäts-Prompt, Wissensdaten, Tools-Daten
   • Komprimieren/Entfernen: Langzeitgedächtnis
3. Funktionssicherheit
   • Die Vollständigkeit der Kernfunktionen (z. B. Bestellabfrage) muss auch bei Tokenmangel gewährleistet sein.
   • Langzeitgedächtnis kann zugunsten der Antwortqualität geopfert werden.

Durch eine solche Planung im Kontextmanagement und der Tokenverwaltung können die Kernfunktionen des Kundenservice-Assistenten innerhalb des begrenzten Tokenraums umgesetzt werden, ohne dass Gesprächskohärenz oder Professionalität verloren gehen.