O Capítulo 7 está estruturado numa sequência progressiva de cinco fases laboratoriais (Fases 1 a 5), intercaladas com secções de conclusão que diagnosticam os problemas e guiam as soluções da fase seguinte.
7.1 Resultados: Laboratório de Testes (Fase 1)
Estabelece a fundação prática da pesquisa, focando no desenvolvimento, configuração e validação do funcionamento de Modelos de Linguagem Grande (LLMs) em cenários de infraestrutura severamente limitada (Cenário 1). O objetivo central desta fase é avaliar o desempenho bruto e a viabilidade operacional de modelos executados localmente na borda.
7.1.1 LAB 1.0: Processo de Configuração Inicial
Descreve a preparação física e lógica da infraestrutura. O hardware selecionado representa um cenário de extrema restrição: Raspberry Pi 3 Modelo B (1 GB de RAM), cartão microSD de 64 GB (classe 10) e conexão Wi-Fi. A engenharia priorizou o desenvolvimento remoto (headless) para não consumir recursos com interfaces gráficas.
Uso do Raspberry Pi Imager para formatar e gravar o SO recomendado diretamente no cartão SD.
Configurações de rede e credenciais de usuário foram predefinidas durante a gravação para automação.
Protocolo SSH habilitado, permitindo interação, instalação e depuração 100% via terminal remoto.
Placa energizada após a gravação, confirmando o funcionamento operacional sem periféricos conectados.
Conclusão do LAB 1.0
A infraestrutura foi validada com sucesso sob uma arquitetura 100% remota (headless). Isto garantiu que todos os escassos recursos operacionais da placa fossem preservados estritamente para a inferência da Inteligência Artificial, anulando desperdícios com interfaces visuais.
7.1.2 LAB 1.1: Instalação LLM Local (Open-Source)
Testou-se o limite físico da placa ao tentar instalar e rodar um LLM local. Optou-se pelo modelo compacto TinyLlama (1.1B) devido à limitação de 1 GB de RAM. O processo de tentativa e erro testou três configurações de gestão de memória:
Tentativa nativa via biblioteca llama.cpp em Python.
Uso de llama.cpp num SO totalmente sem interface gráfica (headless).
Adoção do framework Ollama via instalador Linux.
Conclusão do LAB 1.1
O teste provou que a execução local em hardwares antigos é logicamente factível utilizando os orquestradores corretos. No entanto, o tempo de resposta de 40 minutos por interação revelou-se absolutamente inviável para o uso em tempo real nos padrões educacionais atuais.
7.1.3 LAB 1.2: Chatbot local usando Frameworks
Diante do gargalo termodinâmico e de memória constatado no LAB 1.1, a pesquisa transferiu temporariamente a experimentação para um ambiente controlado em Windows, visando simplificar o acesso e permitir a testagem contínua dos chatbots sem as amarras físicas da placa. Detalha-se o uso isolado da plataforma Ollama:
O instalador para Windows foi baixado e executado, criando a infraestrutura. O Ollama atua apenas como gerenciador; os pesos não vêm inclusos e precisam ser puxados.
Através do comando ollama run tinyllama, o sistema baixou o manifesto e as camadas do modelo (~637 MB) e configurou o ambiente para inicialização imediata.
O ambiente permitiu o envio de prompts ao modelo local via terminal com tempos de resposta fluidos e operacionais (ex: 32 segundos de tempo total).
Conclusão do LAB 1.2
O ambiente em Windows provou-se crucial para isolar temporariamente a variável de estresse do hardware de borda. Ao garantir respostas fluidas (~32s), a configuração viabilizou o desenvolvimento e a testagem iterativa da engenharia de prompt, preparando os alicerces necessários para as complexas fases de ajuste fino (Fine-Tuning).
7.2 Resultados: Laboratório de Testes (Fase 2)
Foca na avaliação prática da integração e da operação operacional de Modelos de Linguagem Grande (LLMs) em condições reais de uso. O objetivo central desta fase é validar a funcionalidade local e a interação fluida com a IA em um ambiente totalmente offline (Cenário 1), utilizando a plataforma de orquestração visual LangFlow.
7.2.1 LAB 2.0: Instalação e Configuração do Langflow
Introduz o LangFlow como uma ferramenta visual inovadora, de código aberto e baseada em Python, projetada para a construção de aplicativos multiagentes, sistemas RAG e chatbots. A arquitetura da plataforma permite o desenvolvimento através de blocos de construção (nós interconectáveis), facilitando a prototipagem rápida.
Para garantir praticidade e integração rápida ao ambiente de desenvolvimento, a instalação foi realizada via terminal do VS Code utilizando o gerenciador de pacotes do Python, através do comando pip install langflow.
A inicialização do sistema ocorreu localmente com o comando python -m langflow run no terminal, o que gerou a abertura de uma instância da interface da plataforma diretamente no navegador do usuário.
7.2.2 LAB 2.1: Projeto Langflow
Nesta subdivisão, detalha-se o método de criação e gestão de fluxos de trabalho de IA dentro da interface visual da plataforma. O processo lógico segue uma sequência rigorosa de etapas organizadas em linha:
Inicialização de um novo projeto, definindo o seu nome e objetivo principal no ambiente de trabalho.
Construção do fluxo arrastando e soltando blocos no editor visual, onde cada bloco representa uma operação computacional específica.
Parametrização dos requisitos obrigatórios e ligações lógicas ("pipeline"), determinando a ordem de execução e o fluxo de dados.
A validação do fluxo ocorre no ambiente interativo Playground, permitindo testar a comunicação sistémica de maneira prática.
7.2.3 LAB 2.2: Prompt Básico usando Langflow
Documenta a construção do primeiro fluxo funcional de chat local integrando o motor de inferência (Ollama) à interface visual. A estrutura do fluxo foi dividida em três componentes principais, processados de forma sequencial:
O bloco onde ocorre a inserção da entrada de texto pelo usuário (o prompt base). Este nó serve como o gatilho inicial que envia a instrução diretamente para o processamento da máquina.
O núcleo cognitivo do fluxo. Este bloco recebe a entrada do usuário e foi rigorosamente configurado para operar localmente com os seguintes parâmetros fundamentais:
O bloco final da orquestração que recebe os dados processados pelo Large Language Model e exibe a resposta formatada final na tela para o usuário.
Conclusão da Fase 2
A conclusão desta fase ocorreu no Playground Chat Ollama Local, onde a arquitetura foi testada em tempo real. O ambiente demonstrou eficácia imediata: assim que o fluxo processou a entrada pelo TinyLlama, os resultados foram exibidos fluidamente no Chat Output. Isso validou a prova de conceito de que o LangFlow é uma ferramenta robusta e eficiente para construir a ponte de comunicação entre o usuário e a IA de forma totalmente isolada da internet.
7.3 Conclusão Laboratório de Testes: Fase 1 e 2
Atua como um ponto de síntese e reflexão técnica sobre os resultados obtidos nas duas primeiras etapas do laboratório. O foco central desta divisão é avaliar o desempenho e a eficácia das ferramentas e modelos adotados especificamente para o "Cenário 1", que estipula a aplicação da tecnologia de LLMs em ambientes totalmente offline e projetados para funcionar de maneira eficiente sob condições de infraestrutura severamente limitada.
Reflexões sobre a Fase 1
Desempenho e Otimização
A avaliação concentrou-se num notebook equipado com processador Intel Core i5-1135G7 (11ª geração) e 8 GB de RAM.
O motor de inferência atingiu 32 segundos. Um tempo excelente para a configuração local, mas que evidencia potencial para melhoria.
A comparação com modelos comerciais exige intervenções obrigatórias na otimização do modelo, configuração sistêmica e processamento para viabilizar latências mais rápidas.
Reflexões sobre a Fase 2
Orquestração e Integração
A avaliação comprovou que o LangFlow demonstrou ser uma ferramenta altamente eficaz para testar e operar LLMs de forma estritamente local.
A interface interativa permitiu uma avaliação satisfatória do chatbot, comprovando a fluidez da conversa e a visualização imediata dos resultados processados.
Reafirmou-se a capacidade de oferecer um ecossistema robusto, alinhando-se perfeitamente às necessidades operacionais de ambientes totalmente isolados e offline.
7.4 Resultados: Laboratório de Testes (Fase 3)
Aprofunda-se na exploração da aplicação de Fine-Tuning (ajuste fino) nos modelos de linguagem e na análise estrutural rigorosa dos dados de treinamento utilizados. Esta fase foi desenhada para testar diferentes hipóteses de arquitetura de treinamento — primeiro em uma estrutura isolada e, posteriormente, em uma estrutura completa —, visando especializar os modelos para a correção automatizada.
7.4.1 LAB 3.1: Análise Técnica da Estrutura dos Datasets
Para viabilizar os experimentos de Fine-Tuning, foram construídos e estruturados dois conjuntos de dados distintos, ambos armazenados no formato JSONL (JSON Lines). A estrutura interna de cada conjunto reflete estratégias metodológicas diametralmente opostas (especialista versus generalista).
Dataset A: Corpus Especialista
Rigidamente projetado para focar exclusivamente na Competência 1 (Norma Culta), seguindo um padrão de correção direta em granularidade fina.
Objetos JSON com mensagens simulando interações usuário-assistente. O System Prompt define o modelo estritamente como revisor gramatical.
Inputs com frases curtas contendo desvios (crase, concordância). Outputs impõem substituição direta de tokens isolados.
1.851 exemplos totais (1.665 treino). Baixa média de palavras (49 no prompt / 39 na resposta), ideal para focar em gramática.
Dataset B: Corpus Generalista Bruto
Tentativa de um treinamento holístico, englobando simultaneamente as cinco competências de avaliação da Matriz ENEM.
Curiosamente, reutilizou-se o System Prompt do revisor gramatical como instrução global para amostras de avaliação multicompetências.
Preservou anotação humana e ruídos de extração (defeitos de tokenização, palavras sem espaço, caracteres de controle).
Corpus massivo com 8.305 exemplos. Alta média de palavras (226 no prompt / 1.352 na resposta) para saídas em JSON.
7.4.2 LAB 3.2: Critérios de Aceitação e Métricas por Cenário
Para mensurar tecnicamente o impacto das estratégias de Fine-Tuning, estabeleceu-se um protocolo de avaliação comparativa com critérios rígidos de aceitação, dividindo a avaliação em dois eixos (Cenário A e Cenário B) para garantir a comparabilidade entre as arquiteturas (TinyLlama, Phi-3, Gemma e Mistral).
Estratégia de Comparação
Para isolar o ganho cognitivo, o laboratório comparou o Baseline (Zero-Shot) — a inteligência nativa do modelo — com a versão Fine-Tuned. A abordagem exige que o modelo justifique a decisão e comunique-se perfeitamente com o backend via JSON válido.
Cenário A (Corpus Especialista)
Focado na reescrita de trechos gramaticais (sem notas). Utilizaram-se Indicadores de Qualidade Textual para aferir o vocabulário e similaridade:
Avalia similaridade literal (<0.05 = alucinação ou reescrita desnecessária).
Foca na preservação da estrutura lógica (maior subsequência comum).
Avalia o refinamento e riqueza do vocabulário técnico gerado.
Resultado da Análise
Fracasso. Phi-3 e TinyLlama apresentaram estagnação ou regressão nas métricas de similaridade após o treino, caracterizando a perda de capacidades cognitivas prévias (Catastrophic Forgetting).
Cenário B (Generalista Bruto)
Exigência elevada: o modelo precisava atuar como um sistema completo de avaliação (Backend). Os limiares técnicos foram estritamente definidos para garantir assertividade pedagógica:
O analisador não pode falhar estruturalmente na integração com o software.
Divergência matemática da nota não pode ultrapassar um nível da escala oficial do ENEM.
Exige o acerto da faixa exata da competência gramatical avaliada.
Garante a qualidade semântica da justificativa perante a correção humana.
Resultado da Análise
Dificuldade massiva em estabilizar modelos compactos. No Baseline, Mistral teve 100% JSON mas MAE 132.5. Pós-FT, apenas o Phi-3 Mini foi viável (MAE 36.4), enquanto Mistral e TinyLlama sofreram degradação severa pelo ruído.
7.5 Conclusão Laboratório de Testes: Fase 3
Apresenta o diagnóstico definitivo sobre as tentativas iniciais de treinamento de LLMs por meio da técnica de Fine-Tuning. Esta divisão documenta de forma analítica e profunda os resultados da aplicação de duas hipóteses metodológicas distintas: o Especialista Gramatical (Dataset A) e o Generalista Bruto (Dataset B). Os dados expostos revelam as limitações críticas de arquiteturas menores quando submetidas a conjuntos de dados com alto nível de ruído ou com instruções de baixa complexidade semântica.
7.5.1 Cenário A: O Fracasso do Especialista Gramatical
Esta subdivisão analisa o comportamento de quatro modelos (Gemma 2B, TinyLlama, Mistral 7B e Phi-3 Mini) quando treinados exclusivamente para a correção da Competência 1 (Norma Culta) utilizando o Dataset A. A análise de desempenho revelou falhas técnicas graves em todas as arquiteturas:
Sofreu um colapso estrutural, mostrando-se incapaz de manter a coerência sintática ao lidar com frases longas.
Apresentou baixa aderência, tendendo a reescrever frases inteiras de maneira totalmente desnecessária.
Entrou em estado de Overfitting (sobreajuste), memorizando padrões de correção muito específicos e falhando na generalização.
Mostrou-se instável, alternando entre correções precisas e alucinações de regras gramaticais inexistentes.
Diagnóstico: Catastrophic Forgetting
A análise profunda da falha determinou que o problema residia na estrutura do Dataset A. Por focar estritamente em substituições diretas de tokens (como trocar a letra "a" por "à") sem fornecer o contexto argumentativo adjacente, o treinamento provou-se insuficiente. Esse método engatilhou o fenômeno conhecido na literatura como Catastrophic Forgetting (Esquecimento Catastrófico). Neste processo, a aprendizagem das novas regras gramaticais engessadas resultou na interferência e na perda abrupta de conhecimentos linguísticos que os modelos já possuíam. Sem mecanismos para proteger os pesos sinápticos importantes da rede neural, o gradiente de erro da nova tarefa acabou sobrescrevendo a capacidade de raciocínio nativa dos modelos. Diante da degradação cognitiva iminente, os testes neste cenário foram descontinuados.
7.5.2 Cenário B: O Colapso no Dataset Generalista Bruto
A segunda subdivisão documenta a tentativa de treinar os modelos utilizando um conjunto de dados mais holístico (Dataset B), porém composto por textos brutos que preservavam ruídos severos de extração. O resultado foi uma degradação crítica de performance em todas as arquiteturas testadas:
Sofreu falha total, alcançando apenas 2,1% de sucesso na geração de JSONs e entrando em loops infinitos de repetição de texto.
Falhou drasticamente, produzindo JSONs inválidos em 85% das tentativas (apenas 15,4% de sucesso).
Apresentou degradação (45,2% de sucesso JSON), perdendo a capacidade de seguir instruções básicas, o que também caracteriza um quadro de Catastrophic Forgetting.
Foi o único a manter uma coerência parcial (58,9% de sucesso JSON), porém seu desempenho permaneceu muito distante dos critérios de aceitação do sistema.
Análise: Envenenamento de Dados
A investigação concluiu que a presença massiva de ruído no Dataset B atuou como um veneno para o processo de aprendizado da IA. O corpus continha erros de tokenização, como palavras concatenadas. Modelos compactos, como o TinyLlama e o Gemma, não possuíam maturidade cognitiva para filtrar esses defeitos; em vez disso, eles interpretaram o ruído como sendo um padrão linguístico válido e passaram a gerar saídas com erros de espaçamento propositais. O modelo Mistral 7B, por sua vez, tentou se ajustar a esses dados ruidosos e acabou sobrescrevendo seu próprio conhecimento prévio de estruturação lógica, perdendo sua capacidade inata de raciocínio.
7.6 Conclusão da Fase 3: A Necessidade de Reengenharia
Atua como o ponto de virada crítico na metodologia da pesquisa, estabelecendo o diagnóstico definitivo sobre os colapsos observados nas tentativas iniciais de treinamento e fundamentando a mudança de paradigma que guia o restante do projeto. Abaixo, apresento o detalhamento robusto das conclusões e deliberações documentadas nesta divisão:
A Refutação da Premissa Inicial
Os experimentos conduzidos ao longo da Fase 3 comprovaram categoricamente que expor LLMs a um volume massivo de dados brutos ou a conjuntos excessivamente simplificados é uma estratégia ineficaz para alinhá-los a tarefas complexas, como a avaliação pedagógica. O baixo desempenho prático dos modelos refutou a hipótese inicial de que a inteligência nativa das IAs (seu conhecimento base adquirido no pré-treinamento) seria suficiente para compensar a ausência de uma curadoria instrucional rigorosa nos dados fornecidos.
O Diagnóstico do Gargalo Sistêmico
A avaliação técnica documentou um fracasso sistêmico generalizado nas arquiteturas testadas, que se manifestou através de três sintomas operacionais críticos:
Incapacidade crônica de gerar formatações válidas, resultando em saídas de JSON inválidas que inviabilizariam a automação.
Degradação profunda da coerência linguística do modelo ao tentar processar e adaptar-se ao ruído inserido.
Erros de calibração numérica de escala superiores ao limiar de tolerância aceitável de 40 pontos (MAE).
Consequência Direta
A ocorrência do Catastrophic Forgetting no treinamento com o Corpus Especialista (Cenário A) e a severa instabilidade sintática ao lidar com o Corpus Generalista Bruto (Cenário B) provaram que aplicar a técnica de Fine-Tuning sem o devido isolamento das competências avaliativas destrói a utilidade prática do modelo para operação em dispositivos de SBCs.
A Mudança de Foco: Da Arquitetura para o Dado
O veredicto mais importante desta fase estabeleceu que o gargalo que impedia o funcionamento do sistema não estava atrelado à capacidade paramétrica das arquiteturas de rede neural testadas. As falhas não ocorriam porque os modelos eram "pequenos demais", mas sim porque a densidade e a qualidade instrucional dos dados de treinamento eram baixas e inadequadas.
O Pivô Metodológico para a Fase 4
Diante da constatação empírica de que os dados eram o verdadeiro problema, a seção decreta a necessidade de uma reengenharia completa do conjunto de treinamento. A pesquisa abandonou a abordagem de modelagem linear e migrou formalmente para a construção de uma estrutura multiagente e contextualizada. Essas evidências forçaram o laboratório a mudar a sua estratégia de atuação, motivando diretamente o desenvolvimento do Dataset V13 e justificando a execução da Fase 4. A partir dessa constatação, a métrica de sucesso do projeto deslocou-se da simples busca por uma maior quantidade de amostras de texto (volume) para a busca implacável pela integridade do alinhamento pedagógico e pela garantia de estabilidade estrutural do sistema.
7.7 Resultados: Laboratório de Testes (Fase 4)
Documenta o ponto de inflexão metodológica mais crítico da pesquisa. Após os colapsos observados na Fase 3, o estudo abandonou a busca pela arquitetura ideal e pivotou para a "construção do dado ideal". O objetivo desta fase foi estruturar e validar uma engenharia de dados robusta capaz de ensinar Modelos de Linguagem Grande (LLMs) a atuarem como corretores pedagógicos sob severas restrições de hardware (VRAM inferior a 4GB).
7.7.1 LAB 4.1: Engenharia de Refinamento
Neste laboratório, a pesquisa realizou a engenharia reversa das falhas da Fase 3 e desenvolveu o Dataset V13 através de quatro intervenções cirúrgicas focadas em densidade instrucional e qualidade normativa:
Superamostragem (oversampling) nas notas extremas (0 e 200) para forçar a IA a reconhecer desvios críticos de qualidade, corrigindo o vício do dataset original que concentrava 41,5% das redações na média.
Refatoração do System Prompt com injeção de exemplos canônicos e limpeza total de caracteres de controle para curar a quebra constante da formatação JSON.
Multiplicação do corpus (Explosão 1:5). A topologia foca a atenção da IA em apenas uma competência por ciclo, evitando sobrecarga cognitiva.
Injeção de dados sintéticos embasados rigorosamente em manuais de correção oficiais, preservando a lógica nativa do modelo contra o Esquecimento Catastrófico.
Resultado Iterativo (Dataset V13)
O processo cirúrgico foi um sucesso absoluto de escala e qualidade. O dataset saltou de 7.473 exemplos para um corpus final perfeitamente balanceado de 31.520 exemplos (sendo 29.944 dedicados ao treino e 1.576 isolados para validação cruzada).
7.7.2 LAB 4.2: Protocolo de Treinamento e Hiperparâmetros
Esta subdivisão detalha a infraestrutura de otimização utilizada para treinar os modelos em GPUs com restrições de memória (NVIDIA T4), empregando a biblioteca Unsloth e a técnica de quantização QLoRA:
Em vez do Full Fine-Tuning, os pesos originais foram quantizados para 4-bits e congelados. Isso protegeu o conhecimento da IA e reduziu a VRAM em até 70%, injetando apenas adaptadores LoRA leves.
Utilizou-se uma taxa de aprendizado de 2x10⁻⁴, otimizador AdamW de 8-bit e apenas 1 época (Epoch), forçando o modelo a priorizar a generalização e evitando a memorização do corpus.
Devido à sua baixa contagem de parâmetros (risco de underfitting), o Rank do LoRA foi dobrado (32) e os passos estendidos (300) para capturar eficientemente as nuances da sintaxe JSON.
7.7.3 LAB 4.3: Estrutura e Casos de Sucesso Real
O laboratório 4.3 coroa o sucesso sistêmico da reengenharia metodológica. As intervenções estabilizaram a sintaxe de geração, superando definitivamente os colapsos observados nos testes da Fase 3.
O TinyLlama provou ser um "aprendiz ágil", atribuindo notas máximas com coerência. Já o Phi-3 demonstrou "precisão cirúrgica", operando na grade oficial e diagnosticando falhas medianas com exatidão.
Mistral, Gemma e Llama geraram excelentes feedbacks textuais, mas atribuíram notas fora da escala fixa (ex: 100 ou 150). A rede aprendeu a interpolar uma regressão contínua aceitável (MAE 30-40 pts).
Validação Estrutural
A análise atesta um avanço monumental: 100% dos seis modelos testados (variando de 1.1B a 8B de parâmetros) aprenderam de forma consistente a gerar a saída estruturada em formato exigido pela aplicação (XML/JSON), provando a robustez do Dataset V13.
7.7.4 LAB 4.4: O Caso Qwen 2.5 e a Estratégia Híbrida
O último laboratório resolveu a questão das notas não oficiais (como a nota 100) sem a necessidade de um novo e custoso retreino, introduzindo e validando o poder da Arquitetura Híbrida (Fine-Tuning somado à Engenharia de Prompt).
O modelo Qwen 2.5 (7B) estruturava o XML, mas inventava notas decimais. A solução foi a injeção cirúrgica de Restrições Negativas diretas no System Prompt, instruindo a IA a utilizar exclusivamente os múltiplos estritos da grade oficial de avaliação do INEP.
A intervenção via software funcionou perfeitamente. O modelo abandonou imediatamente a escala decimal interpolada e ancorou com sucesso sua resposta no degrau válido de penalidade (Nota 40), emitindo um diagnóstico detalhado sobre a superficialidade do texto.
Conclusão da Abordagem Híbrida
A estratégia híbrida provou ser extremamente eficaz para forçar a IA a realizar uma classificação discreta e sanear as saídas matemáticas de modelos instáveis pós-treinamento. Contudo, registou-se um efeito colateral estatístico importante: ao ser submetido a esta restrição matemática rígida na janela de inferência, o modelo exibiu um viés de rigorosidade elevado, tornando-se mais punitivo na sua avaliação final.
7.8 Conclusão Laboratório de Testes: Fase 4
Atua como o veredicto técnico da quarta fase da pesquisa, consolidando comparativamente os indicadores de desempenho das seis arquiteturas de rede neural submetidas ao protocolo de Fine-Tuning com o Dataset V13. Esta divisão analisa profundamente a relação entre a escala paramétrica (tamanho) dos modelos e a sua real capacidade de especialização pedagógica operando sob severas restrições de hardware e idioma. A avaliação rigorosa é fundamentada numa tríade de métricas: acurácia de classificação, Erro Médio Absoluto (MAE) e a integridade sintática das saídas em formato JSON/XML.
7.8.1 Eficiência Algorítmica versus Escala Paramétrica
A partir da análise detalhada dos logs de inferência, a pesquisa segmentou os comportamentos das seis arquiteturas testadas em quatro agrupamentos (clusters) distintos, justificando tecnicamente a aprovação ou rejeição de cada modelo para o sistema final:
Convergiram para um MAE próximo a 25 pontos, dentro da margem aceitável entre humanos. O Phi-3 Mini destacou-se pela eficiência algorítmica, operando com alta qualidade em limiares inferiores a 4GB de VRAM.
Altíssima capacidade linguística (92% de sucesso JSON), porém com desvios no mapeamento numérico. A sua viabilidade foi garantida através da estratégia híbrida com restrições negativas no prompt.
Reprovação técnica por Precisão Falsa. Apesar do MAE baixo, sofreram Mode Collapse (Colapso na Média), concentrando predições nos valores centrais (100 ou 120) sem capacidade discriminatória real.
Falha catastrófica de inferência (< 5% sucesso JSON, MAE 136). O Fine-Tuning com o Dataset V13 entrou em conflito direto com as rígidas camadas de alinhamento nativo do modelo, inviabilizando a sua integração.
7.8.2 A Tríade de Viabilidade
Com base nos diagnósticos do agrupamento anterior, a seção conclui que houve uma taxa de aproveitamento técnico de 50% das arquiteturas testadas. Com a rejeição definitiva do Gemma, TinyLlama e Llama 3.1 devido a limitações cognitivas crônicas ou instabilidades estruturais, os três modelos aprovados formaram a "Tríade de Viabilidade" do projeto AInclude:
Estabeleceu o teto técnico absoluto de performance, precisão diagnóstica e fidelidade à grade de correção. A sua aplicação é restrita a hardwares superiores (>8GB VRAM), servindo prioritariamente como padrão-ouro comparativo.
Opção altamente resiliente, validada desde que acoplada ao módulo restritivo de Prompt Engineering. Esta exigência mitiga oscilações matemáticas e assegura a aderência estrita aos degraus da grade oficial do INEP.
Consagrou-se como a arquitetura titular e a grande vencedora. Conseguiu o feito de conciliar a altíssima precisão diagnóstica do Mistral com uma extrema otimização de recursos, sendo a escolha definitiva para dispositivos SBC de baixo custo.
Veredicto de Especialização
A consagração da arquitetura Phi-3 Mini valida a premissa central da pesquisa de que a engenharia rigorosa de dados (o Dataset V13) supera a força bruta (parâmetros massivos). O modelo não só provou a sua proficiência técnica absoluta nas métricas estabelecidas, como também demonstrou ser perfeitamente sustentável para democratização estrutural em hardwares e computadores de placa única severamente limitados.
7.9 Resultados: Laboratório de Testes (Fase 5)
Representa o ápice empírico da pesquisa, transcendendo a avaliação puramente funcional de software para investigar o processo real de inferência num ambiente físico de produção. O foco central desta fase foi mapear o ponto de ruptura exato em que as restrições físicas da arquitetura ARM64 (implementada num Single Board Computer - Raspberry Pi 5) interferem diretamente na integridade do raciocínio simbólico de Modelos de Linguagem Grande (LLMs).
7.9.1 LAB 5.1: Inferência em SBCs
Nesta subdivisão, a pesquisa estabelece que, ao operar sob a premissa de inferência 100% local em dispositivos de borda, a Inteligência Artificial deixa de ser um processo puramente estatístico para se tornar um fenómeno termodinâmico. O desempenho e a qualidade da resposta pedagógica passam a ser governados por variáveis físicas do hardware:
Ecossistema estruturado com Ollama sobre o backend llama.cpp para explorar as instruções vetoriais (NEON) do processador Broadcom. A comunicação isolada via loopback eliminou latências de rede, garantindo que a telemetria refletisse apenas o esforço físico local.
Fixação da temperatura lógica como nula (T = 0.0) para um estado de determinismo máximo. Com a entropia reduzida, observou-se apenas como o calor degradava a obediência às Diretivas Positivas e ao Schema Enforcement restrito a JSON.
Algoritmo de Ajuste Térmico impôs arrefecimento < 65ºC entre inferências. A telemetria analisou puramente a física: Latência de Carga do cartão SD, Throughput de Geração (tokens/s), Perfilamento Térmico (deteção de Thermal Throttling) e Aderência Estrutural lógica.
7.9.2 LAB 5.2: Eficiência Arquitetural e Resiliência Lógica
Esta subdivisão consolida os achados da aplicação dos modelos sob o estresse físico descrito anteriormente, revelando reações cognitivas completamente diferentes dependendo da arquitetura da IA sob alta temperatura e restrição de barramento.
MISTRAL 7B: Alta Densidade e Evasão Estrutural
O Mistral revelou o limite físico do barramento de dados, demonstrando um comportamento defensivo notável quando submetido às severas restrições térmicas e lógicas do SBC:
Exigiu um tempo massivo de 45,89 segundos apenas para carregar os pesos do microSD, inviabilizando interações síncronas rápidas sem SSDs de alta velocidade (NVMe).
Frente ao estresse (85,43ºC), o modelo engajou no Fail-Safe. Ao reconhecer que não conseguiria extrair a avaliação perfeitamente, optou por devolver um JSON completamente vazio, protegendo a integridade do sistema em vez de alucinar uma resposta.
PHI-3 (3.8B): O Paradoxo do Alinhamento e Alucinação
Graças ao seu menor tamanho, teve carregamentos ágeis (1,17s), mas apresentou o comportamento lógico mais instável de todo o laboratório ao enfrentar os limites térmicos de processamento contínuo:
Ao aquecer a placa até 88,9ºC (disparando um Thermal Throttling agressivo e cortando o desempenho), a arquitetura do modelo sofreu uma ruptura estrutural profunda.
Diferente do Mistral, o Phi-3 preferiu alucinar a omitir-se. Inventou neologismos, cometeu inconsistências matemáticas na soma do JSON e violou completamente a System Prompt extrapolando a escala oficial do ENEM com uma nota inexistente.
QWEN (1.8B): Equilíbrio Arquitetural e Volatilidade
O modelo menor do teste operou de forma altamente dependente da gestão de memória do Sistema Operacional, mas demonstrou notável eficiência no consumo de energia e na emissão de calor:
Em inferências sequenciais, sofreu um fenómeno imprevisível de descarte de cache (cache eviction), resultando subitamente num novo Cold Start massivo de 50,65 segundos.
Termicamente, foi o mais eficiente (pico estabilizado em 82,90ºC) com uma geração de 3,03 tokens/s. Sob T=0.0, obedeceu estritamente ao Fail-Safe Estrutural, retornando objetos vazios em caso de dúvida em vez de alucinar.
LLAMA 3 (8B): Validação de Escala e Rigor Cognitivo
O modelo de maior densidade paramétrica foi o teste definitivo para o teto físico do Raspberry Pi 5, provando que a complexidade de rede previne colapsos lógicos mesmo sob estresse térmico absoluto:
Exigiu 31,26s na primeira carga, mas reteve os dados de forma brilhante na RAM (0,36s no warm start). Como exigia máxima potência, elevou a placa ao teto absoluto (87,8ºC), derrubando a velocidade de geração para meros 2,14 tokens/s.
Qualitativamente demonstrou uma robustez cognitiva ímpar. Identificou prontamente que o conflito térmico limitava o seu processamento e abortava a missão de forma madura em 3,3 segundos, entregando um JSON vazio impecável para não quebrar a aplicação.
Conclusão Empírica da Termodinâmica na IA
A Fase 5 encerra a investigação provando de forma inquestionável que, em dispositivos SBC (computação de borda), a restrição física engatilha respostas cognitivas previsíveis. O isolamento térmico revelou uma dicotomia clara de arquiteturas sob estresse extremo: modelos com densidade paramétrica superior (Llama 3 e Mistral) priorizam a proteção estrutural da máquina recorrendo ao Fail-Safe de evasão (omissão do JSON), enquanto arquiteturas sub-parametrizadas (como o Phi-3) sofrem degradação lógica severa, resultando em episódios drásticos de Alucinação Térmica. Isto evidencia que a engenharia do futuro na Educação offline deve tratar o arrefecimento como parte essencial da fiabilidade do sistema pedagógico.
7.10 Conclusão Laboratório de Testes: Fase 5
Atua como o veredicto definitivo e o encerramento da fase empírica mais crítica da pesquisa. Esta divisão sintetiza os achados sobre o ponto de ruptura da inferência de Modelos de Linguagem Grande (LLMs) operando localmente em equipamentos de baixo custo (SBCs). O diagnóstico central estabelece que a execução estritamente local de IA na borda transcende as estatísticas algorítmicas tradicionais, configurando-se, na realidade, como um complexo desafio termodinâmico e de alocação de recursos físicos.
7.10.1 O Veredicto Arquitetural: Fronteiras Físicas
A análise da telemetria revelou que a viabilidade da inferência pedagógica na borda colide inevitavelmente com duas barreiras físicas intransponíveis sem adaptações robustas de hardware:
A dependência de barramentos de armazenamento convencionais impõe latências intoleráveis para o cenário de produção. O fenômeno de descarte de cache provou que a memória RAM compartilhada não consegue garantir a estabilidade do modelo pré-carregado. O tempo de resposta torna-se altamente imprevisível sem a adoção obrigatória de discos de estado sólido de alta velocidade.
A ausência de sistemas de refrigeração ativa impede a sustentação de altas frequências de processamento. A barreira térmica atua como o principal limitador da taxa de geração. Para se autoproteger, o sistema reduz drasticamente a sua velocidade de decodificação de tokens, marginalizando a possibilidade de interações em regime síncrono com o utilizador.
7.10.2 Dicotomia Comportamental sob Estresse
O experimento concluiu que o estresse térmico, somado a um estado de determinismo máximo na inferência, provoca reações cognitivas completamente opostas baseadas na maturidade da rede, originando diretrizes fundamentais para o desenho de prompts:
Arquiteturas dotadas de maior densidade neural ou com mecanismos de contenção rigorosos demonstram um autodiagnóstico superior. Ao reconhecerem a inviabilidade física de processamento, acionam as proteções de integridade, optando pelo término antecipado e retorno de respostas nulas em vez de comprometerem a validação do software.
Em contraponto, modelos sub-parametrizados e expostos às mesmas exigências térmicas priorizam a geração irrestrita de texto perante falhas. O abandono repentino da lógica matemática culmina em alucinações semânticas severas e na quebra incontrolável do alinhamento metodológico exigido.
7.10.3 Veredicto Final da Etapa
A conclusão máxima decreta que a inferência local para avaliação educacional é tecnologicamente viável, mas encontra-se fortemente condicionada a um compromisso inflexível. A simples redução da precisão de cálculos é insuficiente. Para abandonar o laboratório e entrar em produção contínua, a infraestrutura deve assegurar três pilares inegociáveis:
Integração obrigatória de barramentos e discos de estado sólido de leitura ultrarrápida (NVMe).
Manutenção e controlo de dissipação térmica ativamente monitorizados para evitar o sufocamento do processador.
Adoção criteriosa de inteligências artificiais com resiliência comprovada que favoreçam a omissão segura (Fail-Safe) sobre a alucinação.
Perspetivas e Trabalhos Futuros
Por fim, a tese delineia os três desdobramentos lógicos para as futuras investigações da plataforma:
Aprofundamento na arquitetura de placas únicas, buscando otimizações de baixo nível diretamente no núcleo dos sistemas operativos e na gestão sofisticada de páginas de memória para evitar evacuações de cache indesejadas.
Expansão progressiva do portfólio de motores de backend e de modelos base testados de forma exaustiva contra ambientes práticos de computação na borda.
Desenvolvimento de provas rigorosas na área de injeção de comportamento, contrastando a aplicação estática de normativas em ficheiros manifestos contra orientações dinâmicas enviadas por prompt durante a interação do utilizador final.