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

Technische Samenvatting: Coligo – Een Retrieval-Augmented Generation Assistent voor WhatsApp-gebaseerde TNEA Engineering Toelatingsbegeleiding

Probleemstelling
De toelatingsbegeleiding voor engineering in Tamil Nadu (TNEA) creëert een knelpunt voor de front offices van hogescholen, die worden overspoeld met repetitieve vragen over toelatingsprocedures, takspecifieke kosten en gemeenschapsspecifieke cutoff-rangnummers (OC, BC, BCM, MBC, SC, SCA, ST). Huidige oplossingen vertrouwen op handmatige interventie door personeel of generieke chatbots die een gebrek hebben aan semantisch begrip en toegang tot geverifieerde institutionele gegevens. Er bestaat een kritieke kloof in het bieden van antwoorden die:

1. Gegrond zijn: Gebaseerd op officiële documenten van de hogeschool in plaats van hallucinaties van het model.
2. Gemeenschapsbewust zijn: Het onderscheid maken tussen verschillende reservatiecategorieën en cutoff-typen (cijfers versus rangnummers).
3. Toegankelijk zijn: Beschikbaar op het platform dat studenten al gebruiken (WhatsApp) zonder dat er nieuwe applicaties geïnstalleerd hoeven te worden.
4. Contextueel zijn: In staat zijn om vervolgvragen te verwerken (bijv. "Wat betreft ECE?") zonder dat de gebruiker de volledige context opnieuw moet formuleren.

Methodologie en Systeemarchitectuur
Coligo is een Retrieval-Augmented Generation (RAG) systeem, ontworpen als een twee-componenten Docker Compose stack (FastAPI-service en PostgreSQL-database). De systeemarchitectuur is als volgt:

• Ingestie-pipeline: Officiële PDF's van de hogeschool (waarin toelatingsprocedures, academische zaken en cutoffs worden samengevoegd) worden verwerkt via pypdf. Tekst wordt geëxtraheerd en opgedeeld in overlappende chunks (512 woorden met een overlap van 50 woorden) om de context over grenzen heen te behouden. Chunks worden gehasht (SHA-256) om duplicaten in embeddings tijdens her-ingestie te voorkomen.
• Vectoropslag: Chunks worden geëmbed via Google's text-embedding-004 model (768 dimensies) en opgeslagen in een PostgreSQL-database uitgebreid met pgvector. Dit maakt semantische gelijkeniszoekopdrachten mogelijk via cosinusafstand.
• Retrieval en Generatie:
  • Query Herformulering: Om vervolgvragen af te handelen, gebruikt het systeem een sessie-gebaseerd geheugen (gekoppeld aan het WhatsApp-telefoonnummer of sessie-ID). Als een query contextafhankelijk is (bijv. "Wat betreft ECE?"), roept het systeem een aparte LLM aan om de query te herschrijven naar een zelfstandige vorm voor retrieval-doeleinden, terwijl de originele query behouden blijft voor de uiteindelijke antwoordgeneratie.
  • RAG-pipeline: Het systeem haalt de top 5 (RAG_TOP_K=5) relevante chunks op. Deze worden gecombineerd met een strikte systeem-prompt die domeinregels afdwingt: het onderscheid maken tussen cutoff-cijfers en rangnummers, alleen reageren op specifieke reservatiecategorieën, en weigeren te antwoorden als de context onvoldoende is.
  • Generatie: Google Gemini (LLM) genereert het uiteindelijke antwoord, uitsluitend gegrond in de opgehaalde context.
• WhatsApp Integratie: Het systeem maakt verbinding via de WhatsApp Cloud API. Het implementeert webhook signature verificatie (X-Hub-Signature-256) en routeert berichten op basis van de afzenderidentiteit: studenten-queries gaan naar de RAG-pipeline, terwijl admin-queries worden gerouteerd voor commando-verwerking (hoewel de uitvoering van commando's momenteel beperkt is).
• Deployment: De stack is gecontaineriseerd met behulp van Docker Compose, met specifieke configuraties om DNS-resolutieproblemen in gecontaineriseerde omgevingen af te handelen (door externe resolvers vast te leggen).

Belangrijkste Bijdragen
Het artikel maakt expliciet onderscheid tussen de werkende prototype en de oorspronkelijk geplande architectuur, waarbij de volgende geïmplementeerde bijdragen worden benadrukt:

1. Gecontaineriseerde TNEA-pipeline: Een werkend RAG-systeem dat op WhatsApp is uitgerold en dat vertrouwt op officiële PDF-ingestie in plaats van het geheugen van het model.
2. Domeinspecifieke Systeem-prompt: Een prompt die is ontworpen om TNEA-specifieke logica af te handelen, inclusief de formule voor de berekening van de cutoff (Wiskunde/2 + Natuurkunde/4 + Scheikunde/4) en de noodzaak van gemeenschapsspecifieke antwoorden.
3. Veerkrachtig Conversatiegeheugen: Een sessie-georiënteerd geheugendesign dat gracieus degradeert naar staatloze antwoorden als de toegang tot de databasegeschiedenis faalt, in plaats van vast te lopen.
4. Reproduceerbare Deployment: Een gedocumenteerde Docker Compose setup voor PostgreSQL met pgvector, inclusief fixes voor de DNS-resolutie van containers.
5. Transparante Rapportage: Een expliciet, via code geverifieerd verslag van welke architecturale componenten (zoals Redis-caching, Celery-workers, multi-provider LLM-routing, admin-commando uitvoering) nog niet zijn geïmplementeerd, om te voorkomen dat de prototype wordt aangezien voor een volledig productiesysteem.

Resultaten en Verificatie
De auteurs hebben het systeem geverifieerd door de stack vanuit een schone staat opnieuw op te bouwen en de ingestie-code te draaien tegen een 9-pagina tellende, 5.048 woorden tellende PDF van Sri Krishna College of Engineering and Technology (SKCET).

• Ingestie: De pipeline heeft de PDF succesvol verwerkt in 11 overlappende chunks, waarbij de eerste chunk 512 woorden bevat en de laatste 428 woorden, wat bevestigt dat de chunking-logica naar behoren werkt.
• Deployment: De Docker Compose stack startte succesvol op, waarbij health checks (/health en /health/detailed) een HTTP 200 retourneerden en de databaseconnectiviteit bevestigden.
• Beperkingen in Verificatie: Vanwege de afwezigheid van een geconfigureerde GEMINI_API_KEY in de verificatieomgeving, werden live latentie, retrieval-nauwkeurigheid en antwoord-gronding niet numeriek gemeten. De "retrieval en generatie"-fase werd gevalideerd via code-review in plaats van live uitvoering.
• Admin Routing: Hoewel het systeem admin-commando's (zoals /ingest, /stats) correct detecteert en logt, is de daadwerkelijke uitvoering van deze commando's nog niet geïmplementeerd.

Betekenis en Claims
Het artikel positioneert Coligo niet als een voltooid commercieel product, maar als een geverifieerd prototype dat de kloof overbrugt tussen generieke LLM-chatbots en rigide trefwoord-gebaseerde systemen. De primaire betekenis ligt in:

1. Eerlijkheid in Engineering: De auteurs documenteren expliciet de "kloof" tussen de ontworpen architectuur (die Redis, Celery en multi-LLM routing omvatte) en de huidige implementatie. Zij stellen dat het onderscheid maken tussen de werkende prototype en de doelarchitectuur op zichzelf een bijdrage is, om te voorkomen dat belanghebbenden de huidige staat aanzien voor het definitieve ontwerp.
2. Praktische Toegankelijkheid: Door gebruik te maken van WhatsApp, neemt het systeem de barrière van app-installatie weg voor studenten en ouders, en ontmoet het hen op een bekend platform.
3. Betrouwbare Gronding: Het systeem geeft prioriteit aan feitelijke nauwkeurigheid boven vloeiendheid, en is expliciet geprogrammeerd om te weigeren te antwoorden als het brondocument de specifieke gemeenschapsspecifieke gegevens niet bevat, waardoor het risico op gehallucineerde toelatingscijfers wordt verminderd.

Het artikel concludeert dat hoewel de kern van de ingestie- en retrieval-pipeline functioneel en geverifieerd is, toekomstig werk vereist is om admin-commando uitvoering, confidence scoring, human-in-the-loop escalatie en multi-LLM routing te implementeren om de volledige omvang van de voorgestelde architectuur te realiseren.