Coligo: A Retrieval-Augmented Generation Assistant for WhatsApp-Based TNEA Engineering Admission Counselling

Technisches Resümee: Coligo – Ein Retrieval-Augmented Generation Assistent für die WhatsApp-basierte TNEA-Ingenieurwesen-Zulassungsberatung

Problemstellung
Die Zulassung zur Zulassung für das Ingenieurwesen in Tamil Nadu (TNEA) schafft einen Engpass für die Front-Office-Abteilungen der Hochschulen, die mit repetitiven Anfragen zu Zulassungsverfahren, fachspezifischen Gebühren und gemeinschaftsspezifischen Cutoff-Rängen (OC, BC, BCM, MBC, SC, SCA, ST) überflutet werden. Aktuelle Lösungen verlassen sich auf manuelle Interventionen des Personals oder generische Chatbots, denen es an semantischem Verständnis und dem Zugriff auf verifizierte institutionelle Daten mangelt. Es besteht eine kritische Lücke bei der Bereitstellung von Antworten, die:

1. Fundiert sind: Basierend strikt auf offiziellen Hochschuldokumenten statt auf Modell-Halluzinationen.
2. Gemeinschaftsbewusst sind: Zwischen verschiedenen Reservierungskategorien und Cutoff-Typen (Marken vs. Ränge) unterscheiden.
3. Zugänglich sind: Auf der Plattform verfügbar, die Studierende bereits nutzen (WhatsApp), ohne dass neue App-Installationen erforderlich sind.
4. Kontextbezogen sind: In der Lage sind, Folgefragen zu behandeln (z. B. „Was ist mit ECE?“), ohne dass der Nutzer den vollständigen Kontext erneut angeben muss.

Methodik und Systemarchitektur
Coligo ist ein Retrieval-Augmented Generation (RAG) System, das als zweiteiliger Docker-Compose-Stack (FastAPI-Service und PostgreSQL-Datenbank) konzipiert ist. Die Systemarchitektur stellt sich wie folgt dar:

• Ingestion-Pipeline: Offizielle College-PDFs (die Zulassungsverfahren, Akademisches und Cutoffs zusammenführen) werden via pypdf verarbeitet. Der Text wird extrahiert und in überlappende Chunks (512 Wörter mit einem Überlapp von 50 Wörtern) aufgeteilt, um den Kontext über Grenzen hinweg zu bewahren. Die Chunks werden gehasht (SHA-256), um Duplikate bei der erneuten Ingestion zu vermeiden.
• Vektor-Speicher: Die Chunks werden mit dem Google-Modell text-embedding-004 (768 Dimensionen) eingebettet und in einer PostgreSQL-Datenbank gespeichert, die mit pgvector erweitert wurde. Dies ermöglicht die semantische Ähnlichkeitssuche mittels Cosinus-Distanz.
• Retrieval und Generierung:
  • Query Rewriting: Um Folgefragen zu handhaben, nutzt das System einen sitzungsbasierten Speicher (geschlüsselt nach WhatsApp-Telefonnummer oder Session-ID). Wenn eine Anfrage kontextabhängig ist (z. B. „Was ist mit ECE?“), schreibt ein separater LLM-Aufruf die Anfrage in eine eigenständige Form für den Retrieval-Zweck um, während die ursprüngliche Anfrage für die finale Antwortgenerierung beibehalten wird.
  • RAG-Pipeline: Das System ruft die obersten 5 relevanten Chunks ab (RAG_TOP_K=5). Diese werden mit einem strikten System-Prompt kombiniert, der domänenspezifische Regeln erzwingt: Unterscheidung zwischen Cutoff-Marken und Rängen, Beantwortung nur für spezifische Reservierungskategorien und die Weigerung zu antworten, wenn der Kontext unzureichend ist.
  • Generierung: Google Gemini (LLM) generiert die finale Antwort, die ausschließlich auf dem abgerufenen Kontext basiert.
• WhatsApp-Integration: Das System verbindet sich über die WhatsApp Cloud API. Es implementiert eine Webhook-Signaturverifizierung (X-Hub-Signature-256) und routet Nachrichten basierend auf der Absenderidentität: Studierenden-Anfragen gehen an die RAG-Pipeline, während Admin-Anfragen für die Befehlsprozessierung geroutet werden (obwohl die Befehlsausführung derzeit begrenzt ist).
• Deployment: Der Stack ist mit Docker Compose containerisiert, einschließlich spezifischer Konfigurationen zur Handhabung von DNS-Auflösungsproblemen in containerisierten Umgebungen (Festlegen externer Resolver).

Wesentliche Beiträge
Die Arbeit unterscheidet explizit zwischen dem Arbeits-Prototyp und der ursprünglich geplanten Architektur und hebt die folgenden implementierten Beiträge hervor:

1. Containerisierte TNEA-Pipeline: Ein funktionierendes RAG-System, das auf WhatsApp bereitgestellt wird und auf der Ingestion offizieller PDFs basiert, anstatt auf dem Modellgedächtnis.
2. Domänenspezifischer System-Prompt: Ein Prompt, der darauf ausgelegt ist, TNEA-spezifische Logik zu handhaben, einschließlich der Cutoff-Berechnungsformel (Math/2 + Physics/4 + Chemistry/4) und der Notwendigkeit gemeinschaftsweiser Antworten.
3. Resilientes Gesprächsgedächtnis: Ein sitzungsspezifisches Speicherdesign, das bei einem Fehler beim Zugriff auf die Datenbankhistorie nahtlos auf zustandslose Antworten zurückfällt, anstatt abzustürzen.
4. Reproduzierbares Deployment: Ein dokumentierter Docker-Compose-Setup für PostgreSQL mit pgvector und FastAPI, einschließlich Fixes für die Container-DNS-Auflösung.
5. Transparente Berichterstattung: Eine explizite, code-verifizierte Darstellung darüber, welche architektonischen Komponenten (z. B. Redis-Caching, Celery-Worker, Multi-Provider-LLM-Routing, Admin-Befehlsausführung) noch nicht implementiert sind, um eine Fehlinterpretation des Prototyps als fertiges Produktionssystem zu verhindern.

Ergebnisse und Verifizierung
Die Autoren verifizierten das System, indem sie den Stack aus einem sauberen Zustand neu aufbauten und den Ingestion-Code gegen ein 9-seitiges, 5.048 Wörter umfassendes PDF des Sri Krishna College of Engineering and Technology (SKCET) ausführten.

• Ingestion: Die Pipeline verarbeitete das PDF erfolgreich in 11 überlappende Chunks, wobei der erste Chunk 512 Wörter und der letzte 428 Wörter umfasste, was die Funktionalität der Chunking-Logik bestätigt.
• Deployment: Der Docker-Compose-Stack startete erfolgreich, wobei die Health-Checks (/health und /health/detailed) HTTP 200 zurückgaben und die Datenbankkonnektivität bestätigten.
• Einschränkungen bei der Verifizierung: Aufgrund der Abwesenheit eines konfigurierten GEMINI_API_KEY in der Verifizierungsumgebung konnten die Live-Latenz, die Retrieval-Genauigkeit und die Antwort-Fundierung nicht numerisch gemessen werden. Die „Retrieval- und Generierungsphase“ wurde mittels Code-Review validiert, nicht durch Live-Ausführung.
• Admin-Routing: Obwohl das System Admin-Befehle (z. B. /ingest, /stats) korrekt erkennt und protokolliert, ist die eigentliche Ausführung dieser Befehle noch nicht implementiert.

Bedeutung und Ansprüche
Die Arbeit positioniert Coligo nicht als fertiges kommerzielles Produkt, sondern als verifizierten Prototyp, der die Lücke zwischen generischen LLM-Chatbots und starren schlüsselwortbasierten Systemen schließt. Die primäre Bedeutung liegt in:

1. Ehrlichkeit im Engineering: Die Autoren dokumentieren explizit die „Lücke“ zwischen der entworfenen Architektur (die Redis, Celery und Multi-LLM-Routing vorsah) und der aktuellen Implementierung. Sie argumentieren, dass die Unterscheidung zwischen dem funktionierenden Prototyp und der Zielarchitektur einen Beitrag an sich darstellt, um sicherzustellen, dass Stakeholder den aktuellen Stand nicht als finales Design missverstehen.
2. Praktische Zugänglichkeit: Durch die Nutzung von WhatsApp entfernt das System die Barriere der App-Installation für Studierende und Eltern und trifft sie auf einer vertrauten Plattform.
3. Fundierte Zuverlässigkeit: Das System priorisiert faktische Genauigkeit vor Eloquenz und ist explizit so programmiert, dass es die Antwort verweigert, wenn das Quelldokument die spezifischen gemeinschaftsbasierten Daten nicht enthält, wodurch das Risiko halluzinierter Zulassungs-Cutoffs reduziert wird.

Die Arbeit schließt mit dem Hinweis, dass weitere Arbeiten erforderlich sind, um die Admin-Befehlsausführung, Confidence-Scoring, Human-in-the-Loop-Eskalation und Multi-LLM-Routing zu implementieren, um den vollen Umfang der vorgeschlagenen Architektur zu realisieren.