EKO – Chatbot IA Místico & Jogo Narrativo Ambiental

EKO é um projeto de IA em duas fases construído por Clayton Borges e Raphael Palmer como parte da EKO – Residência Artística, uma residência cultural financiada pelo FAC – Fundo de Apoio à Cultura do Distrito Federal, Secretaria de Cultura e Economia Criativa / GDF. A residência reuniu artistas, tecnólogos e instituições ambientais — incluindo ICMBio/Parque Nacional de Brasília, SesiLab, Ateliê Ecoarte e Centro Tradicional de Invenção Cultural — para explorar a interseção entre IA, ecologia e cultura em Brasília. A Fase 1 é um chatbot em produção: usuários interagem com EKO — um personagem oracular místico e sarcástico — via uma UI web Streamlit com estética mística total. EKO responde perguntas, detecta categorias de tópico para mudar o tom e sorteia de um baralho completo de 78 cartas de Tarô quando solicitado. O LLM é uma instância Ollama local (llama3.1:8b), sem chaves de API externas. A Fase 2 é o Ekonsulta, um jogo narrativo satírico sobre comportamento ambiental: jogadores fazem escolhas binárias em 50 dilemas abrangendo alimentação, moda, transporte, água e tecnologia. Uma pontuação oculta mapeia cada escolha para um de 6 arquétipos comportamentais — EKO entrega o veredicto final com precisão sarcástica.

Campanhas de conscientização ambiental tipicamente abordam usuários de forma didática — apresentando fatos e esperando mudança de comportamento. Essa abordagem falha em atingir pessoas que já sabem o que deveriam fazer, mas não agem. O Ekonsulta mira em um público específico: pessoas que praticam 'performance verde' — sinalizando virtude sobre sustentabilidade enquanto suas escolhas reais contradizem seus valores declarados. Sarcasmo e autorreconhecimento desconfortável são ferramentas mais eficazes do que informação para esse público.

Fase 1: implantar um chatbot de IA com persona de personagem forte, suporte completo a Tarô e conectividade confiável a um LLM auto-hospedado apesar de desafios de roteamento VPN. Fase 2: projetar e prototipar um jogo narrativo com 50 dilemas pesquisados em profundidade, 6 arquétipos comportamentais e um sistema de pontuação oculto que impede jogadores de otimizar para o resultado desejado.

• ◈Clayton Borges — UI, otimização mobile, ajuste de contexto/persona, ownership do projeto
• ◈Raphael Palmer — engenharia do bypass de VPN, integração do servidor Ollama, lógica central do backend

1. 01Sem dependência de LLM em nuvem — o sistema inteiro roda em uma instância Ollama auto-hospedada (llama3.1:8b). Sem chaves de API externas, sem custos por token, sem dados do usuário saindo da infraestrutura. Escolhido por controle de custo e privacidade; o tradeoff é que a velocidade de inferência depende do hardware local.
2. 02Monkey-patching de DNS no código de produção — socket.getaddrinfo é substituído no carregamento do módulo para forçar 'localhost' → '127.0.0.1'. Um workaround de produção para interceptação de DNS por VPN que impedia o app de resolver localhost para a interface de loopback no ambiente de deployment.
3. 03Estratégia dual de tunnel — a imagem Docker inclui ngrok para deployments em container (inicia ngrok dentro do container para criar um tunnel público para host.docker.internal:11434). O script de dev local usa Cloudflare Tunnel como endpoint público alternativo. Múltiplas topologias foram testadas para encontrar conectividade confiável através de VPN.
4. 04Dois caminhos de prompt separados — requisições de Tarô usam um prompt curto e focado para interpretação de cartas. Requisições de conversa usam o contexto completo da persona EKO + janela de histórico de conversa + instrução de tom injetada com base na detecção de categoria do tópico.
5. 05Pipeline de pós-processamento de resposta — o LLM (especialmente o llama3.1:8b) tende a incluir tags <think>, autoreferências do EKO, monólogo interno e nomes de cartas vazando fora do modo de Tarô. A função separate_thinking_and_response() limpa tudo isso com padrões regex direcionados.
6. 06Isolamento de sessão via UUID no TinyDB — cada sessão do navegador recebe um UUID armazenado em st.session_state; todas as queries ao banco são escopadas por esse UUID, habilitando uso multiusuário simultâneo em um único arquivo JSON do TinyDB sem contaminação entre sessões.
7. 07Sistema de pontuação oculto no Ekonsulta — o jogo deliberadamente esconde toda acumulação de pontos do jogador. Cada escolha nos 50 dilemas secretamente incrementa pesos para um ou mais dos 6 arquétipos comportamentais. Filosofia: jogadores não devem conseguir 'otimizar' para o arquétipo desejado — o veredicto deve parecer revelador.
8. 0850 dilemas com pesquisa profunda em 5 temas — cada tema tem um documento de pesquisa dedicado embasando a escrita dos cenários. Os cenários foram projetados para evitar 'respostas certas' óbvias, forçando jogadores a confrontar tensões genuínas entre conveniência, custo e impacto ambiental.

• →Engenharia de persona para um LLM local exige muito mais iteração do que para modelos em nuvem — o llama3.1:8b na temperatura 0.9 é criativo mas inconsistente, exigindo uma camada explícita de pós-processamento de resposta para manter consistência do personagem que um modelo maior manteria por conta própria.
• →O problema de conectividade VPN produziu a engenharia mais criativa do projeto: monkey-patching de DNS, estratégias duais de tunnel e preferência por 127.0.0.1 são cada um soluções incomuns que funcionaram precisamente porque diagnosticamos a causa raiz (interceptação de DNS) em vez de tratar sintomas.
• →Pontuação oculta é uma decisão de design de jogo, não apenas técnica — tornar as pontuações visíveis durante o Ekonsulta permitiria que jogadores engenharia reversa os arquétipos e escolhessem respostas estrategicamente, derrotando completamente o propósito do jogo. A estrutura de revelação no final é essencial para o efeito satírico.
• →TinyDB é adequado para um protótipo Streamlit com baixo uso simultâneo, mas não escalaria para deployment de produção multiusuário — a estrutura de arquivo único cria contenção de escrita sob qualquer concorrência significativa.
• →Construir uma persona de chatbot requer tanto engenharia de system prompt quanto pós-processamento de output — o prompt define como o modelo deve responder, mas uma camada de pós-processamento é necessária para capturar os casos em que o modelo quebra o personagem, especialmente para modelos menores.

Fase 1 implantada — Fase 2 (Ekonsulta) protótipo completo, jogo completo em design