In der Diskussion um KI-Agenten wird „Streaming“ auf zwei unterschiedliche Arten verwendet, und die meisten Tutorials behandeln nur eine davon. In der Ausgangsquelle wird dies von einem technischen Spezialisten erklärt.
In der Welt der KI-Agenten wird der Begriff „Streaming“ auf zwei verschiedene Weisen verwendet. Manchmal bezieht es sich darauf, dass der Agent einen Live-Stream von Ereignissen konsumiert, anstatt darauf zu warten, dass jemand eine Nachricht eingibt. In anderen Fällen bedeutet es, dass die Ausgaben des Agenten tokenweise gestreamt werden, anstatt nach einer langen Pause auf einmal zu erscheinen. Diese Entwicklung verfolgt bewusst beide Ansätze, da sie zwei unterschiedliche Probleme lösen und ein wirklich nützlicher, immer aktiver Agent beide Herausforderungen meistern muss.
Voraussetzungen für die Entwicklung
Die grundlegenden Voraussetzungen für die Implementierung sind:
- Python 3.11 oder neuer
- Ollama lokal installiert, mit einem heruntergeladenen Modell (z. B. ollama pull llama3.1:8b oder ein beliebiges Modell, das strukturierten JSON-Ausgang unterstützt)
- Installation der benötigten Pakete:
pip install fastapi uvicorn httpx pydantic ollama sse-starlette
Es sind keine API-Schlüssel, kein Cloud-Konto und keine Kosten über den eigenen Stromverbrauch hinaus erforderlich. Die einzige ausgehende Netzwerkverbindung, die dieser Dienst herstellt, ist zu Wikipedias öffentlichem EventStreams-Endpunkt, der keine Authentifizierung erfordert.
Wichtige Designentscheidung
Der Edit-Stream von Wikipedia ist kein trickle. An einem aktiven Tag werden mehrere Bearbeitungen pro Sekunde über alle Sprachversionen hinweg übertragen. Wenn man jede einzelne dieser Bearbeitungen einem Sprachmodell übergibt, führt dies zu zwei Problemen: Es werden die Rechenressourcen des Geräts für Bearbeitungen verbraucht, die von vornherein nicht interessant sind, und der Agent kann nicht mit dem Live-Stream Schritt halten, was das gesamte Ziel eines „immer aktiven“ Systems untergräbt.
Die Lösung besteht aus einem zweistufigen Filter, der das wichtigste Konzept dieser Entwicklung darstellt:
- Die erste Stufe ist eine kostengünstige, einfache Python-Mathematik, die bei jedem Ereignis ohne Modell läuft: Wie viele Bytes wurden bei dieser Bearbeitung entfernt? Wie viele Bearbeitungen hat dieser Benutzer in den letzten Minuten vorgenommen? Die überwiegende Mehrheit der Bearbeitungen ist uninteressant, und uninteressant ist einfach zu erkennen.
- Die zweite Stufe, das lokale LLM, wird nur für den kleinen Bruchteil von Ereignissen aktiviert, die in der ersten Stufe einen Schwellenwert überschreiten. Dies folgt dem gleichen Prinzip wie jedes gute Überwachungssystem: kostengünstige Filter im Vorfeld, teure Überlegungen nur für die Kandidaten, die bestehen bleiben.
Ordnerstruktur der Anwendung
Die Struktur der Anwendung ist wie folgt:
streaming-local-agent/
├── src/
│ ├── __init__.py
│ ├── config.py
│ ├── schemas.py
│ ├── stream_source.py
│ ├── filters.py
│ ├── agent.py
│ ├── broadcaster.py
│ └── main.py
├── tests/
│ └── test_filters.py
├── requirements.txt
└── .env.example
Jede Datei entspricht genau einer Stufe der oben beschriebenen Pipeline, was die gesamte Anwendung einfach nachvollziehbar und leicht isoliert testbar macht.
Erster Abschnitt: Der Event-Stream-Konsument
Der EventStreams-Dienst von Wikipedia überträgt Bearbeitungen als Server-Sent Events über einfaches HTTP. Es sind keine Schlüssel oder Handshakes erforderlich, abgesehen von einer gewöhnlichen GET-Anfrage, die offen bleibt.
Die Anonymitätserkennung ist hier besonders erwähnenswert, da der naive Ansatz (Überprüfung eines expliziten „ist dieser Benutzer anonym“-Feldes) in diesem Feed nicht existiert. Wikipedia schreibt anonyme Bearbeitungen der IP-Adresse des Editors zu, sodass die Funktion is_anonymous_user überprüft, ob der Benutzername wie eine IPv4- oder IPv6-Adresse aussieht.
Zweiter Abschnitt: Der kostengünstige Filter, Stufe Eins
Die Klasse EditVelocityTracker verfolgt die letzten Bearbeitungszeitstempel pro Benutzer in einem gleitenden Fenster, sodass der Filter auch schnelle Bearbeitungsserien erfassen kann, nicht nur einzelne große Löschungen. Die Speicherkapazität ist begrenzt: alte Benutzer werden entfernt, anstatt für immer gespeichert zu werden.
Dritter Abschnitt: Der lokale Denker, Stufe Zwei
Nur Signale, die die erste Stufe überstehen, gelangen hierher. Dies ist der Punkt, an dem ein strenges Schema und das Token-Streaming von Bedeutung sind.
Vierter Abschnitt: Live-Übertragung der Ergebnisse an die Clients
Jeder verbundene Client erhält seine eigene asyncio.Queue, und die Funktion publish verteilt eine Nachricht an jede Warteschlange unabhängig. Dies stellt sicher, dass ein langsamer oder gestoppter Abonnent die Verarbeitung des Live-Streams nicht blockiert.
Zusammenfassung und Ausblick
Die tatsächliche Lektion hinter all diesem Code ist nicht spezifisch für Wikipedia, Ollama oder FastAPI, sondern dass Effizienz kein nachträglicher Optimierungsansatz ist, sobald ein Agent von „antwortet, wenn gefragt“ zu „immer aktiv“ wechselt. Ein Chat-Agent, der untätig bleibt, verursacht keine Kosten. Ein Streaming-Agent hingegen verbraucht ständig Ressourcen, und jede Designentscheidung in dieser Entwicklung, vom zweistufigen Filter über die begrenzte Speicherkapazität bis hin zur automatischen Wiederverbindung bei einer unterbrochenen Verbindung, ist darauf ausgelegt, ein System zu schaffen, das sich selbstständig aufrechterhalten kann. Weitere Informationen zu AI-Agenten Orchestrierung und wie man ein Echtzeit-Sprachmodell lokal ausführt finden Sie in den entsprechenden Artikeln.
„`
Quellen: kdnuggets
Bildquelle: KI generiert
Dieser Text wurde mit Hilfe von künstlicher Intelligenz in Zusammenarbeit mit unserer Redaktion erstellt.
🚀