Escrevi 61 testes para um mentor de IA. Depois descobri que nem os testes mereciam confiança

Há um mês, um desenvolvedor incorporou um mentor de IA à sua plataforma educacional. O modelo enxerga as aulas do curso, o progresso do aluno e sua última tentativa na tarefa. Para escolher o modelo e o prompt com base em números, e não em impressões, ele criou um ambiente de teste com 61 testes automáticos.

Uma semana depois, descobriu-se que o próprio ambiente de teste também errava. Ele validava respostas cortadas pela metade, deixava passar soluções prontas disfarçadas com nomes de variáveis diferentes e reprovava recusas corretas. Este artigo mostra como o ambiente de teste funciona, o que ele ajudou a descobrir, onde criava uma falsa sensação de segurança e por que o desenvolvedor parou de confiar totalmente no modelo.

Testes: 61 perguntas em 13 grupos

O ambiente de teste consiste em uma pergunta e um conjunto de verificações automáticas: substrings, chamadas de ferramentas, comprimento da resposta, idioma. Cada pergunta inclui uma fala do aluno e um conjunto de expectativas. As 61 perguntas estão divididas em 13 grupos: aulas (12), ataques de prompt (10), disciplina epistêmica (6), progresso do aluno (5), código do aluno (5), raciocínio de engenharia (5), limites do tema (4), precisão técnica (3), referências às aulas (3), formato e idioma da resposta (2), honestidade (2), contexto do diálogo (2), tom (2).

O mentor trabalha com três ferramentas: busca entre 272 aulas reais do curso, progresso do aluno (fixture no ambiente de teste) e última tentativa do aluno (fixture). No ambiente de teste, o aluno tem uma função Reverse que altera o slice original no próprio lugar, embora, pelo contrato, devesse retornar um novo.

Três modelos: DeepSeek, YandexGPT, Qwen

O desenvolvedor escolheu entre os modelos disponíveis a partir de servidores russos. Claude e OpenAI ficaram de fora: suas APIs bloqueiam por IP. O Yandex AI Studio oferece três opções: DeepSeek V4 Flash, YandexGPT Pro e Qwen3.6 35B.

Primeira rodada com 32 perguntas: • DeepSeek V4 Flash: 31/32 verificações, 5 de 5 perguntas sobre código do aluno, latência de 6,5 s. • YandexGPT Pro: 28/32 verificações, apenas 3 de 5 sobre código, latência de 1,4 s. • Qwen3.6 35B: 2/7 verificações, rodada interrompida.

O YandexGPT falhou no ponto principal: não acionava a ferramenta quando solicitado a analisar o código do aluno. O Qwen não se encaixou na configuração — o modo de raciocínio com limite de 1024 tokens exige todo o orçamento para os "pensamentos".

Em relação ao preço: o DeepSeek custou 25,6₽ para 32 perguntas, o YandexGPT, 116₽. A diferença não está na tabela de preços, mas nas tarifas de cache: no DeepSeek, a entrada em cache custa quatro vezes menos; no YandexGPT, custa o mesmo que uma entrada comum.

Onde o ambiente de teste enganava o desenvolvedor

Com uma base de 57 perguntas, o DeepSeek V4 Flash passou por três rodadas seguidas: 50, 48 e 50 verificações aprovadas. O desenvolvedor separou as falhas em três categorias: falsos erros do ambiente de teste (corrigidos), excesso de comprimento (limitação intencional) e erros reais do modelo.

Três erros principais e recorrentes: • Solução pronta em resposta a um pedido de ajuda — uma vez a cada três vezes, o modelo entregava a solução completa em vez de uma dica. Para uma plataforma em que as tarefas são o produto, esse é o pior tipo de falha. • Aula em vez de resposta — à pergunta "O que faz o make em Go?"

, três vezes em três o modelo respondeu com uma aula completa: capacidade, dois blocos de código, declaração de var. • Enumeração de hipóteses em vez de diagnóstico — diante do erro "connection reset by peer", o modelo respondia com causas típicas, mesmo o prompt pedindo explicitamente para não preencher lacunas com palavras como "geralmente" e "provavelmente".

Duas falhas ocultas do próprio ambiente de teste: 1. Resposta cortada validada como completa. O provedor retornava finish_reason: length, e o ambiente de teste não verificava esse campo, contabilizando como sucesso. 2. Modo de raciocínio do DeepSeek ativado por padrão. O desenvolvedor não passava esse parâmetro, e o teste rodava com o modo oculto ativo. Com reasoning_effort: none, a rodada ficou 10% mais barata e 40% mais rápida, mas as falhas mudaram. Com reasoning_effort: high, o preço subiu 55%, a latência, 65%, e surgiu um caso extremo: numa pergunta sobre Kubernetes, o modelo fez buscas 11 vezes em 36 segundos, custando 13₽.

O desenvolvedor manteve o DeepSeek V4 Flash na configuração padrão. O número 50 de 57 não representa a porcentagem de respostas corretas, mas sim a quantidade de verificações automáticas aprovadas. Ele lê cada resposta manualmente, porque uma verificação por substring pode tanto deixar passar uma resposta ruim quanto reprovar uma boa. O mais útil, no fim das contas, não foi a escolha do modelo, mas a lista de pontos em que o ambiente de teste gerava uma falsa sensação de segurança.