RAG für die vagen Fragen, ein deterministischer CLI für die exakten

Das operative Gedächtnis eines Telekommunikationsunternehmens lebt in seinem Ticketsystem. Unseres ist IBM Maximo: jedes Störungsticket, jeder Faserausfall, jeder Standortbesuch. Die Fragen, die die Leute daran stellen, lassen sich in zwei sehr unterschiedliche Formen einteilen – und die interessante technische Entscheidung war, sie mit zwei verschiedenen Werkzeugen zu beantworten.

Zwei Arten von Fragen

• "Gab es letzten Winter ähnliche Ausfälle auf dieser Strecke? Was verursacht normalerweise Flapping an diesem PoP?" — vage, semantische, urteilende Fragen.
• "Wie viele Störungstickets im März? Liste die offenen für das Gebiet der Ukraine." — exakte, zählbare Fragen.

Der Fehler wäre, beides an ein Sprachmodell zu werfen. Ein LLM ist großartig bei der ersten Art und schwach zuverlässig bei der zweiten – frage es nach einer Zählung, und es wird dir selbstbewusst eine Zahl nennen, die fast richtig ist. Daher trennt das Toolkit sie:

• RAG (Onyx). maximo_sync.py meldet sich bei Maximo an (nur Lesezugriff), parst die Ticketobjektstruktur, wandelt jedes Ticket in ein Textdokument plus zusammenfassende „Digest“-Dokumente um und speichert diese in einem lokalen Onyx Index. Nun können die vagen Fragen in natürlicher Sprache gestellt werden. Die Synchronisierung ist idempotent (Hash Manifest), sodass sie unter cron sicher ist.
• Ein deterministischer CLI. maximo_stats.py beantwortet die zählbaren Fragen, indem es direkt mit Maximo abfragt – --year, --month, --type, --status, --list, --json. Kein Modell in der Schleife, keine halluzinierten Gesamtsummen. Es ist das langweilige, korrekte Gegenstück zum RAG.

Diese Trennung – LLM für Bedeutung, Code für Arithmetik – ist die ganze Idee.

Am Rande

• Ein Status-Dashboard. Ein stündlicher Schnappschuss wird pro Land erstellt und auf einen Webhost synchronisiert; ein kleines PHP-Dashboard rendert ihn, einschließlich einer PoP Map (Leaflet) und eines heuristischen Analyseblocks – MTTR/SLA Proxys, Geräteerwähnungen, Faserausfall-Hotspots. Die Analysen sind absichtlich ungefähr und als solche gekennzeichnet.
• Ein Telegram Watcher. Er verfolgt aktive Störungstickets für einen Standort und benachrichtigt mich bei neuen/geschlossenen Ereignissen, zusammen mit einem stündlichen konsolidierten Digest, was noch offen ist.

Entwickelt für Sicherheit und Portabilität

Alles ist nur lesend gegenüber Maximo – nur GET-Anfragen, ein Lesezugriffskonto, nichts, was ein Ticket ändern kann. Die Python-Tools verwenden die Standardbibliothek allein, keine Drittanbieterpakete, sodass sie auf jedem Gerät mit Python laufen können. Und nichts Spezifisches für die Bereitstellung ist eingebaut: Endpunkte, Anmeldeinformationen und Umfang stammen alle aus Umgebungsvariablen (chmod 600, außerhalb des Repositories), während die im Repo enthaltenen Referenzdaten kleine synthetische Muster sind – echte Exporte, Anmeldedaten und Snapshots werden von gitignore ausgeschlossen.

Es ist ein kleines Toolkit, aber es fängt ein Prinzip ein, zu dem ich immer wieder zurückkehre: Ein Sprachmodell ist eine fantastische Schnittstelle zu Ihren Daten und eine schreckliche Quelle der Wahrheit. Lassen Sie es sich die Fragen über Bedeutung erarbeiten und behalten Sie einen deterministischen Pfad für alles, was korrekt sein muss.