Esta seção modela latência, acurácia, confiabilidade e viabilidade econômica do corretor. Latência (§8.1), acurácia (§8.2) e custo (§8.4.1) já têm uma primeira medição real — todas como piloto local, não como número fechado de regime de produção. Confiabilidade em regime real (taxa de sucesso, distribuição de falhas) ainda depende dos testes de stress em nuvem (ver Testes de Stress) e segue marcada como ⏳ a medir; a lógica de ROI segue como estimativa paramétrica com premissas explícitas.
8.1 Latência: tempo até a nota chegar
Ao contrário de um pipeline em lote, aqui a latência é sentida pelo aluno: ele mandou a foto e espera a correção. O tempo total decompõe-se em duas etapas assíncronas — cada uma disparada por um webhook (foto recebida; botão "Corrigir agora" clicado) — e só o processamento dentro de cada etapa é medido: o tempo que o aluno leva digitando o tema ou decidindo se confirma fica de fora por construção (src/flow/handlers.py, instrumentado com time.perf_counter() nos pontos de download/OCR/LLM).
Medido — piloto local (n=5, Telegram, DeepSeek V4 Flash, CORRECTION_EFFORT=max):
| Etapa | Natureza | Mín | Méd | Máx |
|---|
| Download da mídia (foto) | Rede (provedor de canal) | 1,49s | 2,21s | 3,03s |
| OCR (Mistral) | Rede (API de visão) | 1,38s | 1,70s | 1,97s |
| Overhead etapa foto (Redis + borda) | Local | ~0s | ~0s | ~0s |
| LLM (correção) | Rede (API de LLM) | 83,00s | 92,00s | 98,98s |
| Overhead etapa correção (Redis + borda + envio) | Local | 2,34s | 3,09s | 4,40s |
| Total combinado (foto + correção) | — | 89,02s | 99,00s | 105,16s |
A hipótese se confirma, com folga — e de forma mais extrema do que o previsto. O LLM sozinho responde por ~93% do tempo total. O overhead de infra é desprezível na etapa da foto (~0s) e pequeno mesmo na etapa da correção (2-4s, ~3% do total) — o "borda + Redis desprezível" está bem confirmado. Toda alavanca de latência real está, portanto, na camada de modelos — e dentro dela, CORRECTION_EFFORT (ver §8.2) já se mostrou uma variável de peso: os ~92s médios acima são específicos do effort max. Não medimos a latência com high/medium/low ainda — a comparação high feita até agora foi só de qualidade da correção (§8.2), não de tempo.
Nota de UX: o fluxo mascara a latência com sinais de progresso — mensagem de "processando", indicador de "digitando" e o preview do OCR (que já dá ao aluno algo para revisar enquanto ainda não há nota). A latência percebida é menor que a medida — mas quase 100 segundos de espera na correção é tempo real, não só percepção, e vale considerar ao escolher o effort de produção.
Em aberto. Amostra pequena (n=5) e ambiente local — não nuvem. O que já foi medido localmente (decomposição de latência, rajada na borda até 100 concorrentes, ganho do cache) está em Testes de Stress; o que falta é confirmar tudo em ambiente de nuvem (Azure). A rajada, aliás, mostrou que o edge não é o gargalo — ele escala a 100 requisições concorrentes; o limite é a contenção das tasks de background no worker único (ver Testes de Stress, seção Rajada).
8.2 Acurácia da nota estimada — medido contra o Essay-BR
Diferente do restante desta seção, a acurácia da nota já tem uma primeira medição real — não fica mais em aberto no sentido de "zero dados", ainda que a amostra atual seja um piloto, não uma medição definitiva.
Por que não dá para medir contra a nota oficial do INEP. O INEP publica a nota da redação de cada participante nos microdados oficiais, mas nunca o texto do manuscrito — por privacidade, a redação em si não é disponibilizada. Sem o texto, não há como alimentar o corretor: não existe caminho para medir "vs. nota oficial do INEP", nem para este projeto, nem para nenhum outro.
O proxy público mais próximo é o Essay-BR: ~6.500 redações reais de estudantes brasileiros, corrigidas por especialistas seguindo os critérios do ENEM — na mesma escala oficial (0/40/80/120/160/200 por competência, 0–1.000 no total), sem conversão necessária. Não é a nota oficial (o INEP usa dois corretores humanos, com um terceiro em caso de forte discordância — ver nota de contexto abaixo); é uma aproximação séria, com texto real e nota por competência.
Fonte: Essay-BR — github.com/lplnufpi/essay-br (licença MIT, Laboratório de Processamento de Linguagem Natural, UFPI).
Metodologia do piloto. 30 redações sorteadas aleatoriamente (seed fixa) do subconjunto do corpus com nota > 0 (exclui ~1,4% do corpus com todas as competências zeradas — provável triagem de nota zero, um teste diferente de "acurácia"). Cada uma passou pelo caminho de correção real (src/correction/factory.get_corrector) com o prompt de produção sem variantes (src/prompts.py) — só o texto de entrada muda: tema e proposta do Essay-BR no lugar da foto transcrita por OCR. Provedor: DeepSeek V4 Flash com CORRECTION_EFFORT=max, o mesmo já medido em custo (§8.4.1).
### ⚠️ A medição tem prazo de validade — e ele venceu uma vez
>
Os números desta seção foram medidos duas vezes, em duas versões diferentes do mesmo modelo. O id da API (deepseek-v4-flash) não mudou: a DeepSeek atualizou o modelo por trás dele (versão reportada pelo fornecedor como V4 Flash 0731; a API não expõe id datado, então não há como fixar a versão pelo código). O resultado do corretor mudou sem que uma linha deste repositório fosse alterada.
>
Isso é um achado de engenharia, não um detalhe: qualquer métrica de qualidade publicada aqui é válida para a versão do modelo que estava no ar no dia da medição. Um projeto que depende de LLM de terceiro não tem número de acurácia permanente — tem número datado.
Resultado com a versão atual (V4 Flash 0731), medido em duas amostras independentes:
| Métrica | Amostra A (n=30) | Amostra B, held-out (n=30) |
|---|
| MAE geral | 145,3 pontos | 148,0 pontos |
| Viés médio (estimado − corpus) | -28,0 | -38,7 |
| MAE por competência | C1 35,9 · C2 27,6 · C3 31,7 · C4 30,3 · C5 34,5 | C1 43,3 · C2 32,0 · C3 38,0 · C4 44,7 · C5 44,7 |
As duas amostras não têm nenhuma redação em comum, e os MAEs ficaram a 2,7 pontos um do outro — o número replica. A leitura honesta é MAE ≈ 145–150 pontos, não um valor único: medições em amostras diferentes de 30 redações variam, e citar "145,3" com uma casa decimal sugere uma precisão que o método não tem.
Comparação com a versão anterior do modelo (mesmas 30 redações, pareado):
| Métrica | Versão anterior | V4 Flash 0731 | Δ |
|---|
| MAE geral | 129,3 | 145,3 | +16,0 |
| Viés médio | -1,3 (neutro) | -28,0 (subestima) | -26,7 |
| MAE C5 | 45,7 | 34,3 | -11,4 |
| MAE C1 | 28,6 | 35,7 | +7,1 |
(as linhas por competência usam as 28 redações em que as duas versões produziram as cinco notas)
A atualização piorou a nota agregada e melhorou a competência mais difícil: C5 (proposta de intervenção), que era o maior erro do modelo antigo, caiu 11,4 pontos; C1 (norma culta) piorou 7,1. Não é uma degradação uniforme — é uma troca. Apenas 3 das 30 notas ficaram idênticas entre as versões, com mudança média de 80 pontos por redação: o comportamento mudou de forma ampla.
A afirmação anterior desta seção não vale mais. A versão anterior tinha viés de -1,3 e esta documentação destacava o "viés próximo de zero" como o achado mais importante — evidência a favor das regras anti-inflação do prompt. Com o modelo atual isso é falso: o viés é de -28 a -39. O prompt não mudou; o modelo mudou. O texto foi corrigido em vez de removido porque o erro de leitura é instrutivo — atribuímos ao prompt um mérito que era, ao menos em parte, do modelo.
A estrutura do erro importa mais que o MAE. Decompondo o erro da amostra B:
| Faixa da nota real | Viés do corretor |
|---|
| Baixa (≤ 440) | +91,4 — infla |
| Média (480–680) | -32,7 |
| Alta (≥ 720) | -120,0 — pune |
O erro é regressivo à média: o corretor puxa toda redação em direção ao centro da escala. Duas consequências práticas:
- Coeficiente angular de 0,47. Para cada 100 pontos de melhora real do aluno, a nota estimada sobe ~47. Metade do progresso fica invisível — relevante para um produto cujo propósito é o aluno perceber que evoluiu.
- Correlação de ordenação (Spearman) de 0,66. O corretor ordena redações da pior para a melhor razoavelmente bem, o que é o que mais importa em uso pedagógico — mas não perfeitamente.
Vale registrar que os defeitos apontados são reais mesmo quando a nota é dura: na redação mais penalizada da amostra B (corpus 880 → estimada 600), a justificativa cita desvios concretos e verificáveis do próprio texto (falta de espaço em "sejadifundido", crase ausente, erro de concordância, quebra de paralelismo). O modelo não inventa defeito para sustentar nota baixa — o diagnóstico continua válido mesmo onde o número erra.
Ponto de referência, não prova de equivalência. O próprio material do Essay-BR descreve que, no processo oficial do ENEM, dois corretores humanos podem divergir em até 80 pontos por competência antes de um terceiro avaliador ser acionado. As médias de erro por competência acima (28–45) ficam abaixo desse limiar — o que não significa que o corretor "iguala" um humano (a comparação aqui é contra um único avaliador do Essay-BR, não dois corretores do INEP em consenso), mas mostra que o erro medido está na mesma ordem de grandeza da variância que o próprio sistema oficial trata como aceitável.
Limitações — honestas, não descartáveis:
- Amostra pequena (n=30 por rodada). Suficiente para uma leitura de ordem de grandeza, não para confiança estatística apertada. Duas amostras independentes convergindo (145,3 e 148,0) reforçam o número, mas não o transformam em medição fechada.
- Variabilidade entre amostras é grande. Medido nesta rodada com um modelo de controle: o mesmo modelo e o mesmo prompt deram MAE 165,3 numa amostra e 189,3 em outra — 24 pontos de diferença só por trocar as redações. Comparações de MAE entre amostras diferentes não significam nada abaixo de ~25 pontos. Todas as comparações desta seção são pareadas (mesmas redações) exatamente por isso.
- Variância entre execuções nunca foi medida. Cada configuração rodou uma vez. Não sabemos quanto o mesmo modelo varia ao corrigir as mesmas redações duas vezes seguidas. Diferenças menores que ~15 pontos nesta seção devem ser lidas como possivelmente ruído.
- Risco de vazamento de dado. O Essay-BR é público desde 2021 — não há garantia de que o LLM nunca "viu" pares redação↔nota desse corpus durante o treino. Se houver, o MAE fica artificialmente bom. A ressalva aumenta a cada nova versão de modelo treinada com mais dado público, não diminui.
- Qualidade de dado da fonte, não do corretor. 12,2% do corpus (52 de 151 temas, concentrados num lote específico de ids) tem o texto do tema sem nenhuma acentuação — bug de origem no Essay-BR, não introduzido por este projeto. Não afeta o texto da redação em si, só o enunciado do tema em parte dos casos.
- Comparação contra um avaliador único, não o consenso de dois corretores do INEP — o Essay-BR é um proxy, nunca o gabarito oficial.
Sensibilidade ao CORRECTION_EFFORT: max vs. high, mesmas 30 redações. O piloto foi repetido inteiro com CORRECTION_EFFORT=high (era max), mesma seed — garantindo comparação pareada, essay a essay. Atenção: esta comparação foi feita na versão ANTERIOR do modelo (é a origem do 129,3 na tabela abaixo) e não foi refeita na 0731 — dado datado, mantido por valor histórico:
| Métrica | max | high | Δ |
|---|
| MAE geral | 129,3 | 162,7 | +33,4 |
| Viés médio | -1,3 (neutro) | -64,0 (subestima) | — |
| MAE C1 / C2 / C3 / C4 / C5 | 30,7 / 27,6 / 35,9 / 29,3 / 45,3 | 32,9 / 26,4 / 27,4 / 33,6 / 49,3 | misto |
Não é ruído: comparando as 30 redações par a par (mesmo texto, effort diferente), high deu nota em média 62,7 pontos mais baixa que max na mesma redação — e a diferença persiste em -61,4 pontos mesmo excluindo os dois maiores outliers, ou seja, é uma tendência ampla, não dois casos isolados puxando a média. Os dois outliers mais extremos foram triagens de nota zero que só aconteceram no high (as mesmas redações tinham nota normal — 240 e 400 — no max): uma por fuga total ao tema, outra por cópia de texto motivador, ambas com trechos do próprio texto citados corretamente na justificativa — não parecem alucinação, mas um julgamento mais rigoroso na aplicação da triagem.
Não dá para saber se high está mais certo ou mais errado. max estava melhor calibrado contra este proxy específico (viés ≈ 0); isso não prova que max é mais correto em termos absolutos, só que combinou melhor com as notas do Essay-BR nesta amostra. A mesma limitação epistêmica do restante desta seção se aplica: high pode estar sendo mais rigoroso do que um corretor humano exigente seria (o que aproximaria da realidade), ou superpunindo (o que afastaria) — sem um terceiro corretor de referência, não dá para desempatar. Na prática, CORRECTION_EFFORT se mostrou um eixo de calibração de comportamento tão relevante quanto a escolha de provedor, e também afeta a latência (ver §8.1) — vale documentar qual valor está em produção e por quê, não só qual é mais rápido.
Uma versão anterior desta documentação afirmava que outros provedores tinham sido descartados sem medição, por custo. Isso mudou: o Gemini 3.5 Flash Lite — a faixa mais barata da linha, onde o argumento de custo do Gemini 3 Flash não se aplica — foi avaliado nas mesmas redações.
| Configuração (mesmas 30 redações held-out) | MAE | Viés | Spearman | Slope |
|---|
DeepSeek V4 Flash 0731 (max) | 148,0 | -38,7 | 0,66 | 0,47 |
| Gemini 3.5 Flash Lite (prompt de produção) | 189,3 | -157,3 | 0,68 | 0,47 |
| Gemini 3.5 Flash Lite (prompt com âncora de escala) | 144,0 | -101,3 | 0,74 | 0,55 |
DeepSeek e Gemini-com-âncora empatam. 148,0 contra 144,0, com o Gemini melhor em 15 redações e o DeepSeek em 13 — teste de sinais p = 0,851, ou seja, indistinguível de acaso. Os 4 pontos de diferença não sustentam uma troca de provedor.
O achado que sobra é sobre a natureza do erro de cada um, e ele é oposto:
- O DeepSeek está bem calibrado (viés -38,7) e é disperso: zerando o viés restante, o erro só cai para 137,7. Não há erro sistemático a remover — uma calibração linear ótima, ajustada nos próprios dados, não melhora nada (129,3 → 132,9 na versão anterior).
- O Gemini está mal calibrado (viés -101,3) e é preciso: zerando o viés restante, cai para 114,5. O erro dele é quase todo um deslocamento de escala.
Ou seja: o Gemini tem ~23 pontos de folga que o DeepSeek não tem, atacáveis por prompt. Uma variante experimental que apenas ancora a escala (sem tocar em critérios da matriz) melhorou o Gemini de 189,3 para 144,0 — ganho real, p = 0,041 em amostra held-out — mas fechou só parte do viés: a faixa alta ainda sai 183 pontos abaixo. Essa variante não está em produção e é específica do Gemini.
Custo do Flash Lite não foi medido, só a acurácia. Um dado relevante apareceu no caminho: o cache de contexto do Gemini não funciona nesse modelo no free tier (a API recusa a criação de cache), então os ~6.400 tokens do bloco de sistema vão sem cache em toda chamada — o oposto dos 75% de cache-hit medidos no DeepSeek (§8.4.1). Qualquer comparação de custo teria de partir daí.
Decisão vigente: manter DeepSeek + CORRECTION_EFFORT=max. O empate não justifica a troca, e o Gemini ainda carrega a questão do cache. A decisão agora se apoia em dado de acurácia, não só em custo — o que é uma base melhor do que a anterior.
Por que a amostra fica em n=30 (decisão, não pendência). Ampliar para 100+ apertaria o intervalo de confiança, mas o MAE de ~145–150 pontos já é aceitável para o propósito do produto — a própria correção oficial do ENEM admite divergência entre dois avaliadores humanos, e uma nota estimada nunca prometeu equivalência exata (ver Análise e Limitações, §3.2). E não há effort intermediário a testar no DeepSeek: a API expõe só dois níveis efetivos, high e max (low/medium são mapeados para high internamente) — o espectro completo de effort já foi coberto, não é uma varredura pela metade. A pendência de medição mais relevante que resta não é ampliar a amostra, e sim repetir a mesma rodada duas vezes para saber quanta variação vem do próprio modelo (ver Limitação 3).
8.3 Confiabilidade
A correção só é bem-sucedida se as três etapas (download → OCR → LLM) concluírem. O sistema falha graciosamente: retry com backoff em OCR e LLM, devolução de crédito na falha técnica, e estado preservado para o aluno tentar de novo.
| Fator de risco | Mitigação | Efeito |
|---|
| Sobrecarga/cota do provedor (429/503) | Retry com backoff exponencial (OCR ×3, LLM ×4) | Absorve instabilidade transitória |
| Falha definitiva na correção | Devolução do crédito do dia + estado preservado | Aluno não perde a cota nem recomeça o fluxo |
| Webhook duplicado | Idempotência por message_id | Não processa (nem cobra) duas vezes |
| Foto ilegível | Piso de caracteres por foto + edição manual | Não manda lixo ao LLM |
| Exceção inesperada | Exception handler global → 200 + log | Não dispara retries da Meta |
Piloto informal. Ao longo do desenvolvimento, mais de 20 correções reais (Telegram, DeepSeek) rodaram de ponta a ponta sem nenhuma falha — as três etapas concluíram e a nota chegou em todas. É um sinal encorajador de que o caminho feliz é estável, mas não é uma taxa de confiabilidade: a amostra é pequena, sem controle sobre fatores externos (instabilidade momentânea de OCR/LLM, cota, rede) que só aparecem em regime de volume e ao longo do tempo. Os retries com backoff existem justamente para absorver esses eventos raros, que o piloto pequeno não teve a chance de provocar.
A medir: a taxa de sucesso por correção em regime real (concluídas ÷ tentativas, com N grande) e a distribuição de falhas por etapa (download × OCR × LLM) — dados que virão da observabilidade (§6.2) e dos testes de stress. Um piloto de 20+ correções sem falha não substitui isso.
8.4 Custo e ROI
8.4.1 Custo por correção (estrutura)
Diferente de um projeto 100% local, cada correção tem custo marginal — duas chamadas pagas:
Custo por correção ≈ custo_OCR(nº de fotos) + custo_LLM(tokens_entrada + tokens_saída)
tokens_entrada ≈ ~6.000 (bloco estático, CACHEÁVEL) + ~500–1.500 (tema + motivadores + redação)
tokens_saída ≈ a correção formatada (competências + feedback + reescrita)
As três alavancas que mantêm esse custo previsível:
- Cache de contexto no bloco estático (~6.000 tokens): cobrado uma vez por janela de cache, não a cada correção (explícito no Gemini/Claude, automático no OpenAI/DeepSeek). Medido: 75% dos tokens de entrada vieram do cache no uso real com DeepSeek (ver Testes de Stress) — a alavanca funciona; a ressalva é que o custo por correção acaba dominado pela saída, não pela entrada já cacheada.
- Rate-limit diário por aluno (
ESSAY_DAILY_LIMIT, default 2): teto de custo por usuário.
- Cota espiada antes do OCR: não gasta Mistral quando a correção não vai acontecer.
Custo de execução (OCR + LLM) — medido, não estimado
Diferente da seção anterior deste documento (que era projeção), os números abaixo vêm de uso real do projeto, e cobrem a parte do custo que independe de onde a aplicação roda (a chamada às APIs de OCR e LLM). O custo de hospedagem em nuvem (Azure Container Apps) está modelado logo abaixo (§ "Custo de hospedagem"); a medição de uma fatura de produção em regime ainda está pendente.
| Item | Observação | Valor |
|---|
| OCR (Mistral) — free tier | Em uso real de testes (múltiplas correções), consumiu ~1% da cota gratuita mensal | efetivamente US$ 0 dentro da cota |
| OCR (Mistral) — acima da cota | Preço de tabela | US$ 4,00 / 1.000 páginas → US$ 0,004 / foto |
| LLM (DeepSeek V4 Flash) | Medido em uso real: US$ 0,03 para 8 correções completas (bloco estático + dinâmico) | US$ 0,00375 / correção |
Nota de escopo: o valor do LLM foi medido com CORRECTION_PROVIDER=deepseek — que é também o provedor adotado como default do projeto, justamente por esse custo. A troca de provedor é uma variável de ambiente (ver Arquitetura, §2.5); os demais (Gemini, Claude, OpenAI, Maritaca) não foram medidos porque o custo do DeepSeek já resolve o requisito — o Gemini 3 Flash, por exemplo, sai a ~R$ 0,31/redação, ordens de grandeza acima.
Custo total por correção, somando OCR (acima da cota gratuita) + LLM (DeepSeek):
| Fotos da redação | Custo OCR | Custo LLM | Custo total / correção |
|---|
| 1 foto (caso comum) | US$ 0,004 | US$ 0,00375 | ≈ US$ 0,0078 |
| 2 fotos (máximo) | US$ 0,008 | US$ 0,00375 | ≈ US$ 0,0118 |
Ou seja: menos de 1 centavo de dólar por correção (caso comum, 1 foto) acima da cota gratuita do OCR — e, dentro da cota gratuita (como tem sido a operação até agora), o custo por correção cai para ≈ US$ 0,004 (só o LLM). Em escala, isso é ≈ US$ 7,80 por 1.000 correções (1 foto, fora da cota gratuita) — a referência útil para orçar qualquer volume, multiplicando pelo número de correções esperado.
O câmbio USD→BRL não está fixado aqui de propósito: Mistral e DeepSeek cobram em dólar, e a conversão exata depende da cotação no momento da compra de créditos — para orçamento, use a cotação comercial vigente.
Custo de hospedagem em nuvem (Azure Container Apps)
O projeto oferece dois modos de deploy (ver Robustez e Escalabilidade, §6.4), com perfis de custo bem diferentes:
Modo scale-to-zero (QUEUE_BACKEND=azure) — o compute tende a US$ 0. No plano Consumption, a Microsoft dá uma cota mensal gratuita por assinatura: 180.000 vCPU-s, 360.000 GiB-s e 2 milhões de requisições; e uma réplica escalada a zero não gera nenhuma cobrança de compute (doc oficial de billing). Como o contêiner só acorda para processar, o custo se resume ao tempo ativo. Usando a latência real medida (§8.1, ~99 s por correção) num contêiner de 0,5 vCPU / 1 GiB:
- Só o tempo ativo consome ~
99 × 0,5 = 49,5 vCPU-s por correção → a cota grátis cobriria ~3.600 correções/mês antes de qualquer cobrança de compute.
- Descontando o cooldown do KEDA (mantém a réplica viva alguns minutos após cada rajada antes de dormir), a folga cai, mas para volume pessoal ou de turma (dezenas a poucas centenas de correções/mês) o compute continua integralmente dentro da cota gratuita → US$ 0/mês.
- A fila em si (Azure Storage Queue) custa US$ 0,0004 por 10.000 operações — para esse volume, frações de centavo por mês.
- O Redis externo obrigatório nesse modo cabe no free tier do Upstash (US$ 0).
Modo simples (minReplicas=1) — uma réplica sempre ligada. Aqui o contêiner nunca dorme: roda 24/7 (a maior parte do tempo ocioso, cobrado a uma tarifa reduzida, parcialmente abatida pela mesma cota gratuita). O custo é baixo (ordem de poucos dólares por mês para um contêiner pequeno), mas não é zero como no scale-to-zero. É o modo indicado quando o cold-start não é aceitável (ex.: WhatsApp, com SLA de 200 ms).
Natureza do número. O tempo ativo (~99 s) é medido; a cota gratuita e a regra de "réplica a zero = US$ 0" são da doc oficial. A composição acima é, portanto, um modelo bem fundamentado — não uma fatura de produção em regime, que continua sendo o item a fechar. Mas a conclusão qualitativa é robusta: para o volume-alvo (pessoal a escola), a hospedagem no modo scale-to-zero é essencialmente gratuita.
Em aberto. Falta uma fatura de produção em regime para cravar o número de hospedagem (o modelo acima é o teto de confiança atual). A comparação custo × qualidade entre os demais provedores de LLM (Gemini, Claude, OpenAI, Maritaca) também segue em aberto.
Custo em escala: de um aluno a uma escola inteira
Com o custo de execução medido (§ anterior), dá para colocar em perspectiva o que ele significa em cenários reais de uso — de um projeto pessoal a uma escola inteira. Nem todo aluno de uma turma ou escola vai efetivamente usar a ferramenta (adoção parcial é a norma em qualquer produto opcional), o que reduz ainda mais o custo agregado frente a uma conta "todos os alunos, todos os dias". As premissas abaixo são ilustrativas e ajustáveis — o objetivo é mostrar a ordem de grandeza, não cravar um número exato.
| Cenário | Premissa (adoção + uso) | Correções estimadas | Custo total estimado |
|---|
| Aluno individual — uso típico | 1 aluno, ~3× por semana ao longo de 4 meses de preparação | ~50 correções | ≈ US$ 0,40 |
| Aluno individual — uso máximo | 1 aluno, no teto diário (ESSAY_DAILY_LIMIT=2) todo dia por 4 meses | ~240 correções | ≈ US$ 1,90 |
| Uma turma (30 alunos) | ~50% adotam o bot, ~20 correções/aluno ao longo do ano | ~300 correções | ≈ US$ 2,40 |
| Uma escola (400 alunos) | ~1/3 adotam o bot, ~20 correções/aluno ao longo do ano | ~2.660 correções | ≈ US$ 21,30 |
Isto é um teto, não uma média — dois fatores empurram o custo real para baixo:
1. A tabela acima IGNORA o free tier do OCR de propósito (assume que 100% das fotos são cobradas ao preço de tabela, US$ 0,004/foto). Na prática, a operação real consumiu só ~1% da cota gratuita mensal da Mistral em testes extensivos (§ anterior) — enquanto a cota durar, o custo de OCR é US$ 0, e a escola de 400 alunos cai de ≈ US$ 21,30/ano para ≈ US$ 10,00/ano (só o custo do LLM).
2. Uso menor que a premissa reduz o custo na mesma proporção. Se a adoção real for menor que 1/3, ou os alunos corrigirem menos que 20 redações/ano, o custo cai linearmente — os números acima são o teto de um cenário de uso relativamente intenso, não o piso.
>
Mesmo no cenário mais caro da tabela (escola inteira, ano letivo completo, adoção de 1/3, sem considerar o free tier), o custo de execução fica na casa de dezenas de dólares por ano — não milhares, não centenas. Isso muda a leitura da seção a seguir (§8.4.3): para uso pessoal, de turma ou de escola, o custo é baixo o bastante para ser bancado do próprio bolso por um aluno, professor ou desenvolvedor entusiasta, sem precisar de nenhum modelo de negócio. Só na escala de múltiplas escolas simultâneas — onde a soma de correções ultrapassa a cota gratuita de hospedagem (modelada em §8.4.1: ~US$ 0 no scale-to-zero até a cota, crescendo só nesse regime) e começa a pesar — um custeio institucional passaria a fazer sentido, e como viabilização de acesso, não como fim comercial.
8.4.2 Valor gerado (a lógica)
O valor não é "tempo de engenheiro economizado" (como num projeto de automação corporativa), e sim acesso a um recurso pedagógico escasso:
- Para o aluno: substitui uma correção particular (que custa por redação) ou supre a ausência de qualquer correção detalhada — a um custo marginal de centavos por correção. O ganho é a evolução da nota, que se traduz em acesso a cursos mais concorridos.
- Para o professor/escola: descarrega a correção repetitiva, liberando tempo docente para ensino e atendimento individual.
- Para a rede pública: aproxima o feedback de quem hoje depende só da escola, reduzindo a assimetria de acesso.
8.4.3 Por que isto não precisa ser um produto pago
Existe correção de redação por IA de graça — colar o texto num ChatGPT gratuito faz isso. Então "quem pagaria por isto?" é a pergunta errada: a resposta honesta é provavelmente ninguém, e tudo bem. O valor deste projeto não está em cobrar pelo que a IA genérica já faz de graça, e sim em entregar isso onde a IA genérica não chega:
- Sem app, sem login, sem digitar. Ferramentas de IA de uso geral raramente estão disponíveis no ambiente escolar; aqui o aluno usa o WhatsApp/Telegram que já tem, fotografa o manuscrito e não redigita nada — preservando o treino da letra à mão da prova real.
- Rigor da matriz, não "dar uma nota". A correção segue a Matriz do INEP transcrita em regras (triagem de zero, cinco competências, trecho citado), não um chute genérico de chatbot.
- Privacidade pensada para menor de idade. Foto descartada após o OCR, sem histórico, TTL curto — cuidado que uma conversa avulsa num chatbot genérico não oferece.
O enquadramento honesto é portfólio + acesso, não receita. Como o custo de execução é de centavos (§8.4.1) e fica em dezenas de dólares por ano mesmo para uma escola inteira, um projeto assim se sustenta do próprio bolso em escala pessoal, de turma ou de escola — não precisa de modelo de negócio para existir e cumprir seu propósito social e demonstrar competência técnica. Se um dia escalasse para muitas escolas ao mesmo tempo, aí a conta de nuvem (modelada em §8.4.1 — essencialmente gratuita no scale-to-zero até a cota da assinatura) passaria a pesar, e um custeio institucional — convênio com rede pública, patrocínio de edital — faria sentido como viabilização de acesso, não como fim comercial. Vender assinatura contra um ChatGPT gratuito não é a estratégia; fingir que seria só enfraqueceria a análise honesta que o resto desta seção construiu.
8.5 Roadmap Priorizado
Melhorias derivadas das limitações (aba Análise e Limitações) e das lacunas de medição.
Prioridade 1 — Medir para decidir
- Confirmar os pilotos locais em nuvem (aba Testes de Stress): latência, rajada na borda e cache já foram medidos localmente; falta repetir em produção (Azure) — inclusive testar o efeito de
uvicorn --workers na contenção de background que a rajada expôs.
- Instrumentar a observabilidade para a taxa de sucesso em regime real (§8.3) — o único número de confiabilidade que ainda falta, já que o piloto informal de 20+ correções sem falha não substitui uma medição com N grande.
Prioridade 2 — Escala e produto
- Externalizar o Redis para liberar réplicas quando o volume exigir (ver §6.4).
- Acompanhamento de evolução (opt-in, com base legal e retenção definida) — histórico por competência sem ferir a LGPD.
- Onboarding institucional (escola/cursinho) com painel de turma para o professor.
Fora do roadmap (decisões tomadas, não pendências): ampliar a amostra de acurácia além de n=30 foi avaliado e descartado; DeepSeek + CORRECTION_EFFORT=max é a configuração adotada por custo × qualidade (ver §8.2 e §8.4.1). Os efforts de DeepSeek (high e max, os dois únicos efetivos) já foram os dois comparados. O Gemini 3.5 Flash Lite foi medido e empatou com o DeepSeek (§8.2) — a decisão de provedor deixou de ser só de custo e passou a ter dado de acurácia. Claude/OpenAI/Maritaca seguem não medidos.
>
Pendência de medição que permanece aberta: ninguém rodou a mesma configuração duas vezes nas mesmas redações. Sem isso não há como separar diferença real de ruído do modelo abaixo de ~15 pontos de MAE (§8.2, Limitação 3). É a medição mais barata e de maior retorno que ainda falta.
Resumo executivo: o corretor troca "custo zero, latência de madrugada" (típico de automação em lote) por custo marginal por uso e latência sentida em tempo real — o que desloca o foco de otimização para a camada de modelos (provedor, modelo, effort, cache) e para a contenção de custo (rate-limit, cache de contexto). Custo, latência e acurácia da nota já têm uma primeira medição real (todas como piloto local); a mesma variável (CORRECTION_EFFORT) que domina a latência (§8.1) também muda o comportamento da nota (§8.2) — não é só um botão de "mais rápido". Taxa de sucesso em regime real e testes em nuvem seguem pendentes de medição.