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

Resumo Técnico: Coligo – Um Assistente de Geração Aumentada de Recuperação para Aconselhamento de Admissão de Engenharia via WhatsApp

Definição do Problema
O aconselhamento de admissão em engenharia em Tamil Nadu (TNEA) cria um gargalo para as secretarias das faculdades, que ficam inundadas com consultas repetitivas sobre procedimentos de admissão, taxas por ramo e classificações de corte (cutoff) específicas por comunidade (OC, BC, BCM, MBC, SC, SCA, ST). As soluções atuais dependem de intervenção manual de funcionários ou chatbots genéricos que carecem de compreensão semântica e acesso a dados institucionais verificados. Existe uma lacuna crítica em fornecer respostas que sejam:

1. Fundamentadas: Baseadas estritamente em documentos oficiais da faculdade, em vez de alucinações do modelo.
2. Conscientes de Comunidade: Distinguindo entre diferentes categorias de reserva e tipos de cutoff (notas vs. classificações).
3. Acessíveis: Disponíveis na plataforma que os estudantes já utilizam (WhatsApp) sem exigir a instalação de novos aplicativos.
4. Contextuais: Capazes de lidar com perguntas de acompanhamento (ex: "E quanto a ECE?") sem exigir que o usuário reestabeleça o contexto completo.

Metodologia e Arquitetura do Sistema
O Coligo é um sistema de Geração Aumentada de Recuperação (RAG) projetado como uma pilha Docker Compose de dois componentes (serviço FastAPI e banco de dados PostgreSQL). A arquitetura do sistema é a seguinte:

• Pipeline de Ingestão: PDFs oficiais da faculdade (mesclando procedimentos de admissão, acadêmicos e cutoffs) são processados via pypdf. O texto é extraído e dividido em blocos (chunks) sobrepostos (512 palavras com uma sobreposição de 50 palavras) para preservar o contexto através das fronteiras. Os blocos são transformados em hashes (SHA-256) para evitar a duplicação de embeddings durante a re-ingestão.
• Armazenamento Vetorial: Os blocos são transformados em vetores usando o modelo text-embedding-004 do Google (768 dimensões) e armazenados em um banco de dados PostgreSQL estendido com pgvector. Isso permite a busca de similaridade semântica usando distância de cosseno.
• Recuperação e Geração:
  • Reescrita de Consulta: Para lidar com perguntas de acompanhamento, o sistema utiliza uma memória baseada em sessão (chaveada pelo número de telefone do WhatsApp ou ID de sessão). Se uma consulta for dependente de contexto (ex: "E quanto a ECE?"), uma chamada de LLM separada reescreve a consulta para uma forma autônoma para fins de recuperação, enquanto a consulta original é mantida para a geração da resposta final.
  • Pipeline RAG: O sistema recupera os 5 blocos (RAG_TOP_K=5) mais relevantes. Eles são combinados com um prompt de sistema rigoroso que impõe regras de domínio: distinguir notas de cutoff de classificações, responder apenas a categorias de reserva específicas e recusar a resposta se o contexto for insuficiente.
  • Geração: O Google Gemini (LLM) gera a resposta final fundamentada apenas no contexto recuperado.
• Integração com WhatsApp: O sistema conecta-se via WhatsApp Cloud API. Ele implementa a verificação de assinatura de webhook (X-Hub-Signature-256) e roteia mensagens com base na identidade do remetente: consultas de estudantes vão para o pipeline RAG, enquanto consultas de administradores são roteadas para processamento de comandos (embora a execução de comandos seja atualmente limitada).
• Implantação: A pilha é conteinerizada usando Docker Compose, com configurações específicas para lidar com problemas de resolução de DNS em ambientes conteinerizados (fixando resolvedores externos).

Principais Contribuições
O artigo distingue explicitamente o protótipo funcional da arquitetura originalmente planejada, destacando as seguintes contribuições implementadas:

1. Pipeline TNEA Conteinerizado: Um sistema RAG funcional implantado no WhatsApp que depende da ingestão de PDFs oficiais em vez da memória do modelo.
2. Prompt de Sistema Específico do Domínio: Um prompt projetado para lidar com a lógica específica da TNEA, incluindo a fórmula de cálculo de cutoff (Matemática/2 + Física/4 + Química/4) e a necessidade de respostas por comunidade.
3. Memória de Conversa Resiliente: Um design de memória com escopo de sessão que degrada graciosamente para respostas sem estado (stateless) se o acesso ao histórico do banco de dados falhar, em vez de travar.
4. Implantação Reprodutível: Uma configuração documentada de Docker Compose com PostgreSQL contendo pgvector e FastAPI, incluindo correções para a resolução de DNS do contêiner.
5. Relatório Transparente: Uma conta explícita e verificada por código de quais componentes arquiteturais (ex: cache Redis, workers Celery, roteamento de múltiplos provedores de LLM, execução de comandos de administrador) ainda não foram implementados, evitando a deturpação do protótipo como um sistema de produção completo.

Resultados e Verificação
Os autores verificaram o sistema reconstruindo a pilha a partir de um estado limpo e executando o código de ingestão contra um PDF de 9 páginas e 5.048 palavras do Sri Krishna College of Engineering and Technology (SKCET).

• Ingestão: O pipeline processou com sucesso o PDF em 11 blocos sobrepostos, sendo o primeiro bloco de 512 palavras e o último de 428 palavras, confirmando que a lógica de fragmentação funciona conforme pretendido.
• Implantação: A pilha Docker Compose iniciou com sucesso, com verificações de integridade (/health e /health/detailed) retornando HTTP 200 e confirmando a conectividade com o banco de dados.
• Limitações na Verificação: Devido à ausência de uma GEMINI_API_KEY configurada no ambiente de verificação, a latência em tempo real, a precisão da recuperação e as métricas de fundamentação da resposta não foram medidas numericamente. A fase de "recuperação e geração" foi validada via revisão de código, em vez de execução ao vivo.
• Roteamento de Administrador: Embora o sistema detecte e registre corretamente os comandos de administrador (ex: /ingest, /stats), a execução real desses comandos ainda não foi implementada.

Significância e Alegações
O artigo posiciona o Coligo não como um produto comercial finalizado, mas como um protótipo verificado que preenche a lacuna entre chatbots de LLM genéricos e sistemas baseados em palavras-chave rígidos. Sua principal significância reside em:

1. Honestidade na Engenharia: Os autores documentam explicitamente a "lacuna" entre a arquitetura projetada (que incluía Redis, Celery e roteamento de múltiplos LLMs) e a implementação atual. Eles argumentam que distinguir o protótipo funcional da arquitetura alvo é uma contribuição em si, garantindo que as partes interessadas não confundam o estado atual com o design final.
2. Acessibilidade Prática: Ao utilizar o WhatsApp, o sistema remove a barreira da instalação de aplicativos para estudantes e pais, encontrando-os em uma plataforma familiar.
3. Confiabilidade Fundamentada: O sistema prioriza a precisão factual sobre a fluência, sendo explicitamente programado para recusar a resposta se o documento de origem não contiver os dados específicos por comunidade, reduzindo assim o risco de alucinações de cutoffs de admissão.

O artigo conclui que, embora o núcleo do pipeline de ingestão e recuperação seja funcional e verificado, trabalhos futuros são necessários para implementar a execução de comandos de administrador, pontuação de confiança, escalonamento com intervenção humana e roteamento de múltiplos LLMs para realizar todo o escopo da arquitetura proposta.