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

Sintesi Tecnica: Coligo – Un Assistente di Generazione con Recupero Aumentato (RAG) per l'Orientamento all'Ammissione Ingegneristica TNEA basato su WhatsApp

Problema
L'orientamento per l'ammissione all'ingegneria nel Tamil Nadu (TNEA) crea un collo di bottiglia per gli uffici front-office dei college, che si trovano sommersi da query ripetitive riguardanti le procedure di ammissione, le tasse per branca e i punteggi di distacco (cutoff rank) specifici per comunità (OC, BC, BCM, MBC, SC, SCA, ST). Le soluzioni attuali si affidano all'intervento manuale del personale o a chatbot generici che mancano di comprensione semantica e di accesso a dati istituzionali verificati. Esiste una lacuna critica nel fornire risposte che siano:

1. Fondate: Basate strettamente sui documenti ufficiali del college piuttosto che sulle allucinazioni del modello.
2. Consapevoli delle Comunità: Distinguendo tra diverse categorie di prenotazione e tipi di cutoff (punteggi rispetto a ranghi).
3. Accessibili: Disponibili sulla piattaforma che gli studenti già utilizzano (WhatsApp) senza richiedere l'installazione di nuove app.
4. Contestuali: Capaci di gestire domande di follow-up (ad esempio, "E per quanto riguarda ECE?") senza richiedere all'utente di ripetere l'intero contesto.

Metodologia e Architettura del Sistema
Coligo è un sistema di Generazione con Recupero Aumentato (RAG) progettato come uno stack a due componenti Docker Compose (servizio FastAPI e database PostgreSQL). L'architettura del sistema è la seguente:

• Pipeline di Ingestione: I PDF ufficiali del college (che fondono procedure di ammissione, accademia e cutoff) vengono elaborati tramite pypdf. Il testo viene estratto e suddiviso in frammenti sovrapposti (512 parole con una sovrapposizione di 50 parole) per preservare il contesto attraverso i confini. I frammenti sono sottoposti a hashing (SHA-256) per prevenire l'embedding duplicato durante la ri-ingestione.
• Archiviazione Vettoriale: I frammenti vengono trasformati in vettori (embedding) utilizzando il modello text-embedding-004 di Google (768 dimensioni) e memorizzati in un database PostgreSQL esteso con pgvector. Ciò consente la ricerca di similarità semantica tramite distanza del coseno.
• Recupero e Generazione:
  • Riscrittura della Query: Per gestire le domande di follow-up, il sistema utilizza una memoria basata sulla sessione (identificata dal numero di telefono WhatsApp o dall'ID sessione). Se una query è dipendente dal contesto (ad esempio, "E per quanto riguarda ECE?"), una chiamata separata all'LLM riscrive la query in una forma autonoma ai fini del recupero, mentre la query originale viene mantenuta per la generazione della risposta finale.
  • Pipeline RAG: Il sistema recupera i 5 frammenti (RAG_TOP_K=5) più rilevanti. Questi vengono combinati con un system prompt rigoroso che impone regole di dominio: distinguere tra punteggi di cutoff e ranghi, rispondere solo a specifiche categorie di prenotazione e rifiutarsi di rispondere se il contesto è insufficiente.
  • Generazione: Google Gemini (LLM) genera la risposta finale basata esclusivamente sul contesto recuperato.
• Integrazione WhatsApp: Il sistema si connette tramite l'API WhatsApp Cloud. Implementa la verifica della firma del webhook (X-Hub-Signature-256) e instrada i messaggi in base all'identità del mittente: le query degli studenti vanno alla pipeline RAG, mentre le query degli amministratori vengono indirizzate per l'elaborazione dei comandi (sebbene l'esecuzione dei comandi sia attualmente limitata).
• Deployment: Lo stack è containerizzato usando Docker Compose, con configurazioni specifiche per gestire i problemi di risoluzione DNS negli ambienti containerizzati (fissando i resolver esterni).

Contributi Chiave
Il documento distingue esplicitamente il prototipo funzionante dall'architettura originariamente pianificata, evidenziando i seguenti contributi implementati:

1. Pipeline TNEA Containerizzata: Un sistema RAG funzionante distribuito su WhatsApp che si affida all'ingestione di PDF ufficiali invece che alla memoria del modello.
2. System Prompt Specifico del Dominio: Un prompt ingegnerizzato per gestire la logica specifica TNEA, inclusa la formula di calcolo del cutoff (Matematica/2 + Fisica/4 + Chimica/4) e la necessità di risposte per comunità.
3. Memoria di Conversazione Resiliente: Un design della memoria basato sulla sessione che degrada con grazia verso risposte stateless se l'accesso alla cronologia del database fallisce, invece di crashare.
4. Deployment Riproducibile: Una configurazione Docker Compose documentata per PostgreSQL con pgvector e FastAPI, inclusi i fix per la risoluzione DNS dei container.
5. Reporting Trasparente: Un resoconto esplicito e verificato dal codice di quali componenti architettonici (ad esempio, caching Redis, worker Celery, routing multi-provider LLM, esecuzione di comandi admin) non sono ancora stati implementati, evitando di presentare il prototipo come un sistema di produzione completo.

Risultati e Verifica
Gli autori hanno verificato il sistema ricostruendo lo stack da uno stato pulito ed eseguendo il codice di ingestione contro un PDF di 9 pagine e 5.048 parole del Sri Krishna College of Engineering and Technology (SKCET).

• Ingestione: La pipeline ha elaborato con successo il PDF in 11 frammenti sovrapposti, con il primo frammento di 512 parole e l'ultimo di 428 parole, confermando che la logica di chunking funziona come previsto.
• Deployment: Lo stack Docker Compose è partito con successo, con i controlli di salute (/health e /health/detailed) che restituiscono HTTP 200 e confermano la connettività al database.
• Limitazioni nella Verifica: A causa dell'assenza di una GEMINI_API_KEY configurata nell'ambiente di verifica, la latenza live, l'accuratezza del recupero e le metriche di grounding della risposta non sono state misurate numericamente. La fase di "recupero e generazione" è stata validata tramite revisione del codice piuttosto che tramite esecuzione live.
• Routing Admin: Sebbene il sistema rilevi e registri correttamente i comandi admin (ad esempio, /ingest, /stats), l'esecuzione effettiva di tali comandi non è ancora implementata.

Significatività e Rivendicazioni
Il documento posiziona Coligo non come un prodotto commerciale finito, ma come un prototipo verificato che colma il divario tra chatbot generici e sistemi basati su parole chiave rigidi. La sua principale significatività risiede in:

1. Onestà nell'Ingegneria: Gli autori documentano esplicitamente il "gap" tra l'architettura progettata (che includeva Redis, Celery e routing multi-LLM) e l'implementazione attuale. Sostengono che distinguere il prototipo funzionante dall'architettura target sia un contributo in sé, garantendo che gli stakeholder non scambino lo stato attuale per il design finale.
2. Accessibilità Pratica: Utilizzando WhatsApp, il sistema rimuove la barriera dell'installazione di app per studenti e genitori, incontrandoli su una piattaforma familiare.
3. Affidabilità Fondata: Il sistema privilegia l'accuratezza dei fatti rispetto alla fluidità, essendo programmato esplicitamente per rifiutarsi di rispondere se il documento sorgente non contiene i dati specifici per comunità, riducendo così il rischio di allucinazioni sui cutoff di ammissione.

Il documento conclude che, sebbene la pipeline centrale di ingestione e recupero sia funzionale e verificata, è necessario un lavoro futuro per implementare l'esecuzione dei comandi admin, il punteggio di confidenza, l'escalation human-in-the-loop e il routing multi-LLM per realizzare l'intero ambito dell'architettura proposta.