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

Resumen Técnico: Coligo – Un Asistente de Generación Aumentada por Recuperación para el Asesoramiento de Admisiones de Ingeniería TNEA basado en WhatsApp

Planteamiento del Problema
El asesoramiento para las admisiones de ingeniería en Tamil Nadu (TNEA) crea un cuello de botella para las oficinas frontales de las facultades, las cuales se ven inundadas de consultas repetitivas sobre procedimientos de admisión, costos por rama y rangos de corte específicos por comunidad (OC, BC, BCM, MBC, SC, SCA, ST). Las soluciones actuales dependen de la intervención manual del personal o de chatbots genéricos que carecen de comprensión semántica y acceso a datos institucionales verificados. Existe una brecha crítica en proporcionar respuestas que sean:

1. Fundamentadas: Basadas estrictamente en documentos oficiales de la facultad en lugar de alucinaciones del modelo.
2. Conscientes de la Comunidad: Que distingan entre diferentes categorías de reserva y tipos de corte (puntos de corte frente a rangos).
3. Accesibles: Disponibles en la plataforma que los estudiantes ya utilizan (WhatsApp) sin requerir la instalación de nuevas aplicaciones.
4. Contextuales: Capaces de manejar preguntas de seguimiento (por ejemplo, "¿Qué hay de ECE?") sin requerir que el usuario vuelva a enunciar el contexto completo.

Metodología y Arquitectura del Sistema
Coligo es un sistema de Generación Aumentada por Recuperación (RAG) diseñado como una pila de Docker Compose de dos componentes (servicio FastAPI y base de datos PostgreSQL). La arquitectura del sistema es la siguiente:

• Pipeline de Ingestión: Los PDF oficiales de la facultad (que fusionan procedimientos de admisión, académicos y puntos de corte) se procesan mediante pypdf. El texto se extrae y se divide en fragmentos superpuestos (512 palabras con una superposición de 50 palabras) para preservar el contexto a través de los límites. Los fragmentos se procesan mediante un hash (SHA-256) para evitar la duplicidad de incrustaciones (embeddings) durante la re-ingestión.
• Almacenamiento de Vectores: Los fragmentos se incrustan utilizando el modelo text-embedding-004 de Google (768 dimensiones) y se almacenan en una base de datos PostgreSQL extendida con pgvector. Esto permite la búsqueda de similitud semántica mediante la distancia de coseno.
• Recuperación y Generación:
  • Reescritura de Consultas: Para manejar preguntas de seguimiento, el sistema utiliza una memoria basada en sesiones (identificada por el número de teléfono de WhatsApp o ID de sesión). Si una consulta depende del contexto (por ejemplo, "¿Qué hay de ECE?"), una llamada separada al LLM reescribe la consulta en una forma independiente para fines de recuperación, mientras que la consulta original se conserva para la generación de la respuesta final.
  • Pipeline RAG: El sistema recupera los 5 fragmentos (RAG_TOP_K=5) más relevantes. Estos se combinan con un prompt de sistema estricto que impone reglas de dominio: distinguir entre puntos de corte y rangos, responder solo a categorías de reserva específicas y negarse a responder si el contexto es insuficiente.
  • Generación: Google Gemini (LLM) genera la respuesta final fundamentada únicamente en el contexto recuperado.
• Integración con WhatsApp: El sistema se conecta a través de la API de WhatsApp Cloud. Implementa la verificación de firma de webhook (X-Hub-Signature-256) y enruta los mensajes según la identidad del remitente: las consultas de los estudiantes van al pipeline RAG, mientras que las consultas de los administradores se enrutan para el procesamiento de comandos (aunque la ejecución de comandos es actualmente limitada).
• Despliegue: La pila está contenedorizada usando Docker Compose, con configuraciones específicas para manejar problemas de resolución de DNS en entornos de contenedores (fijando resolutores externos).

Contribuciones Clave
El artículo distingue explícitamente entre el prototipo funcional y la arquitectura originalmente planeada, destacando las siguientes contribuciones implementadas:

1. Pipeline TNEA Contenedorizado: Un sistema RAG funcional desplegado en WhatsApp que depende de la ingestión de PDF oficiales en lugar de la memoria del modelo.
2. Prompt de Sistema Específico del Dominio: Un prompt diseñado para manejar la lógica específica de TNEA, incluyendo la fórmula de cálculo de puntos de corte (Matemáticas/2 + Física/4 + Química/4) y la necesidad de respuestas por comunidad.
3. Memoria de Conversación Resiliente: Un diseño de memoria con alcance de sesión que degrada de forma controlada a respuestas sin estado si el acceso al historial de la base de datos falla, en lugar de colapsar.
4. Despliegue Reproducible: Una configuración de Docker Compose documentada para PostgreSQL con pgvector y FastAPI, incluyendo correcciones para la resolución de DNS de los contenedores.
5. Reporte Transparente: Una cuenta explícita y verificada por código de qué componentes arquitectónicos (por ejemplo, caché de Redis, trabajadores Celery, enrutamiento de múltiples proveedores de LLM, ejecución de comandos de administrador) aún no se han implementado, evitando la tergiversación del prototipo como un sistema de producción completo.

Resultos y Verificación
Los autores verificaron el sistema reconstruyendo la pila desde un estado limpio y ejecutando el código de ingestión contra un PDF de 9 páginas y 5,048 palabras de la Sri Krishna College of Engineering and Technology (SKCET).

• Ingestión: El pipeline procesó con éxito el PDF en 11 fragmentos superpuestos, con el primer fragmento de 512 palabras y el último de 428 palabras, confirmando que la lógica de fragmentación funciona según lo previsto.
• Despliegue: La pila Docker Compose se inició correctamente, con verificaciones de salud (/health y /health/detailed) devolviendo HTTP 200 y confirmando la conectividad con la base de datos.
• Limitaciones en la Verificación: Debido a la ausencia de una GEMINI_API_KEY configurada en el entorno de verificación, no se midieron numéricamente la latencia en vivo, la precisión de la recuperación ni las métricas de fundamentación de respuestas. La fase de "recuperación y generación" se validó mediante revisión de código en lugar de ejecución en vivo.
• Enrutamiento de Administrador: Aunque el sistema detecta y registra correctamente los comandos de administrador (por ejemplo, /ingest, /stats), la ejecución real de dichos comandos aún no se ha implementado.

Significancia y Reivindicaciones
El artículo posiciona a Coligo no como un producto comercial terminado, sino como un prototipo verificado que cierra la brecha entre los chatbots de LLM genéricos y los sistemas basados en palabras clave rígidos. Su principal significancia radica en:

1. Honestidad en la Ingeniería: Los autores documentan explícamente la "brecha" entre la arquitectura diseñada (que incluía Redis, Celery y enrutamiento de múltiples LLM) y la implementación actual. Argumentan que distinguir el prototipo funcional de la arquitectura objetivo es una contribución en sí misma, asegurando que las partes interesadas no confundan el estado actual con el diseño final.
2. Accesibilidad Práctica: Al utilizar WhatsApp, el sistema elimina la barrera de la instalación de aplicaciones para estudiantes y padres, encontrándolos en una plataforma familiar.
3. Fiabilidad Fundamentada: El sistema prioriza la exactitud de los hechos sobre la fluidez, programado explícitamente para negarse a responder si el documento fuente no contiene los datos específicos por comunidad, reduciendo así el riesgo de alucinaciones en los puntos de corte de admisión.

El artículo concluye que, si bien el núcleo del pipeline de ingestión y recuperación es funcional y verificado, se requiere trabajo futuro para implementar la ejecución de comandos de administrador, la puntuación de confianza, la escalada de intervención humana y el enrutamiento de múltiples LLM para alcanzar todo el alcance de la arquitectura propuesta.