Validação cruzada e avaliação de modelos

Se há algo que aprendi da maneira mais difícil, é que desenvolver um modelo de IA ou uma automação inteligente representa apenas metade do percurso. A outra parcela, muitas vezes negligenciada e considerada tediosa, consiste em assegurar que a solução funcione de fato e com excelência, de forma consistente. E quando menciono "funcionar bem", não me refiro a um mero "olhar por cima" dos resultados, presumindo que estão adequados. É nesse ponto que a validação cruzada e a avaliação de modelos se tornam cruciais, e, acredite, essa prática pode poupar-lhe muitos problemas (e tempo).

Recordo-me de uma ocasião em que estava criando uma automação em Apps Script para categorizar automaticamente e-mails de suporte que chegavam a uma conta do Gmail. O conceito era direto: extrair o conteúdo do e-mail, enviá-lo a uma API da OpenAI com um prompt cuidadosamente elaborado, e a IA determinaria se era um problema técnico, uma consulta comercial, um pedido de reembolso, entre outros. O resultado da classificação era registrado diretamente em uma planilha do Google Sheets, disparando outras automações para direcionar o e-mail à equipe apropriada. Parecia infalível, não é?

No meu ambiente de desenvolvimento, com cerca de 50 e-mails de teste que eu mesmo criei, tudo operava perfeitamente. Acertava todas as classificações! Senti-me bastante satisfeito, implementei a solução e fui descansar. No dia seguinte, o caos se instalou. Mensagens de clientes eram encaminhadas para equipes equivocadas, alguns e-mails de "problema técnico" eram direcionados ao grupo de "agendamento de demo", e a fila de suporte transformou-se em uma desordem. Onde eu havia errado? A IA parecia competente, o prompt estava "otimizado". O equívoco estava na minha abordagem de "avaliação", que foi praticamente inexistente. Não validei o modelo de maneira adequada, e o desfecho foi uma confusão que me custou horas de retrabalho e considerável estresse.

Desde então, validação e avaliação se tornaram um princípio fundamental na minha rotina. Elas representam a distinção entre um script que "funciona" apenas na teoria e um sistema robusto, capaz de resistir aos desafios do uso real.

Entendendo a Necessidade: Por Que a Validação de Modelos é Essencial

É natural apreciar quando as coisas funcionam impecavelmente logo de início. Essa sensação é muito gratificante. Contudo, a realidade é mais complexa, e os dados utilizados para "treinar" (ou, no contexto de prompts, "refinar") seus modelos raramente abrangem todas as eventualidades possíveis. Seria como testar um veículo apenas em asfalto impecável e esperar que ele se comporte igualmente bem em uma estrada de terra.

As Armadilhas do Overfitting e Underfitting

Esses conceitos são a raiz de muitos equívocos que cometi. Um modelo em overfitting é aquele que assimilou os dados de treinamento de forma tão profunda que memorizou inclusive o "ruído" inerente a eles. Ele demonstra excelente desempenho com os dados já apresentados, mas falha drasticamente diante de informações novas e desconhecidas. No meu cenário do e-mail, o modelo "decorou" os e-mails de teste que eu havia preparado, mas foi incapaz de generalizar para a verdadeira diversidade de e-mails de clientes.

Por outro lado, o underfitting representa o oposto: o modelo é excessivamente simplista, não conseguindo captar padrões nem mesmo nos dados de treinamento. É comparável a um estudante que sequer se dedicou ao estudo. Em aplicações de IA generativa, um prompt excessivamente abrangente pode gerar respostas inconsistentes e de pouca utilidade, independentemente da quantidade de exemplos fornecidos.

Para evitar essas armadilhas, são necessários métodos rigorosos para testar a capacidade do modelo de se adaptar a dados nunca antes vistos. É aqui que entram a divisão de dados e a validação cruzada.

Divisão dos Dados: Conjuntos de Treinamento, Validação e Teste

A premissa fundamental de qualquer avaliação bem-sucedida é jamais, em hipótese alguma, utilizar os mesmos dados para avaliar seu modelo que foram empregados em seu treinamento ou ajuste. Tal prática seria análoga a um professor que aplica uma prova com as mesmas questões do simulado, esperando que o aluno demonstre um aprendizado genuíno da matéria. Isso carece de lógica.

• Conjunto de Treinamento (Training Set): Constitui a porção majoritária dos seus dados. É o material que o modelo "assimila" para discernir padrões. Em se tratando de um prompt, são os exemplos utilizados para refiná-lo, testar diferentes palavras-chave, e assim por diante.
• Conjunto de Validação (Validation Set): Uma porção menor e distinta, empregada para ajustar os "hiperparâmetros" do modelo (ou, no caso de prompts, testar variações do prompt para identificar a mais eficaz) e selecionar o melhor modelo ou prompt dentre diversas tentativas. O modelo *não* é treinado diretamente com esses dados, mas os resultados obtidos são usados para orientar as decisões de ajuste.
• Conjunto de Teste (Test Set): Este conjunto é de suma importância. Trata-se de um conjunto de dados completamente intocado e independente, que o modelo nunca visualizou em nenhuma etapa prévia (nem durante o treinamento, nem na validação). Sua única finalidade é fornecer uma estimativa final e imparcial do desempenho do modelo no "mundo real". Se você utilizou o conjunto de validação para a avaliação final, parabéns, você está iludindo a si mesmo e pode estar à beira de um overfitting sorrateiro. Eu já cometi esse erro e me arrependi amargamente.

Na prática, ao manipular dados no Google Sheets, frequentemente os exporto para CSV e utilizo Python. Com `pandas` e `sklearn`, a divisão de dados torna-se bastante simples:

import pandas as pd
from sklearn.model_selection import train_test_split

df = pd.read_csv('meus_dados_rotulados.csv')

# Separa features (X) e target (y)
X = df['texto_do_email']
y = df['categoria_correta']

# Divide em Treino (80%) e Teste (20%)
X_treino_val, X_teste, y_treino_val, y_teste = train_test_split(X, y, test_size=0.2, random_state=42, stratify=y)

# Agora divide o Treino em Treino (80% do original) e Validação (20% do original, ou 25% de X_treino_val)
X_treino, X_val, y_treino, y_val = train_test_split(X_treino_val, y_treino_val, test_size=0.25, random_state=42, stratify=y_treino_val)

# Agora tenho 60% Treino, 20% Validação, 20% Teste
# E o stratify garante que a proporção de categorias seja mantida em cada split


Com o Apps Script, o processo é mais manual, embora passível de automação. Habitualmente, organizo minhas Sheets com abas distintas: "Dados Originais", "Treino", "Validação", "Teste". Posso desenvolver um script para embaralhar as linhas da aba "Dados Originais" e distribuí-las entre as demais. Não é tão elegante quanto a abordagem em Python, mas funciona e assegura a necessária separação.

Validação Cruzada (Cross-Validation): A Abordagem Robusta

A simples divisão em conjuntos de treinamento, validação e teste é um ponto de partida eficaz, mas apresenta uma limitação: o desempenho do modelo pode ser influenciado pela maneira como essa divisão foi realizada. Se, porventura, o conjunto de teste contiver predominantemente exemplos "fáceis" ou "difíceis", sua estimativa final pode resultar em distorções.

A validação cruzada, particularmente a técnica k-fold cross-validation, soluciona essa questão. O princípio é direto, mas altamente eficaz: em vez de realizar uma única divisão, você segmenta seus dados de treinamento (lembre-se, o conjunto de teste permanece intocado!) em 'k' subconjuntos, ou "folds". O modelo é então treinado 'k' vezes. Em cada iteração, um fold diferente é utilizado como conjunto de validação, enquanto os 'k-1' folds restantes são empregados para o treinamento.

Ao término do processo, você terá 'k' pontuações de desempenho. A média dessas pontuações oferece uma estimativa consideravelmente mais estável e fidedigna de como seu modelo se comportará diante de dados novos. Isso é especialmente valioso quando se trabalha com um dataset de tamanho reduzido ou quando se busca uma garantia inabalável da estabilidade do modelo.

A implementação de k-fold com Python é extremamente simples:

from sklearn.model_selection import KFold
from sklearn.linear_model import LogisticRegression
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.pipeline import Pipeline
from sklearn.metrics import accuracy_score

# ... (dados X_treino_val, y_treino_val do split anterior)

kf = KFold(n_splits=5, shuffle=True, random_state=42)

pipeline = Pipeline([
('tfidf', TfidfVectorizer()),
('logreg', LogisticRegression(max_iter=1000))
])

scores = []
for train_index, val_index in kf.split(X_treino_val):
X_train_fold, X_val_fold = X_treino_val.iloc[train_index], X_treino_val.iloc[val_index]
y_train_fold, y_val_fold = y_treino_val.iloc[train_index], y_treino_val.iloc[val_index]

pipeline.fit(X_train_fold, y_train_fold)
y_pred = pipeline.predict(X_val_fold)
scores.append(accuracy_score(y_val_fold, y_pred))

print(f"Média das acurácias na validação cruzada: {sum(scores) / len(scores):.2f}")
print(f"Desvio padrão: {pd.Series(scores).std():.2f}")


Métricas de Avaliação: Indo Além da Acurácia

Ah, a acurácia. A métrica preferida por muitos, mas que pode ser incrivelmente enganosa. A acurácia meramente indica a porcentagem de previsões corretas. Parece um bom indicador, certo? O problema surge quando os dados estão desbalanceados.

Imagine um modelo projetado para detectar fraudes. De 1000 transações, apenas 10 são fraudulentas (1%). Se o modelo simplesmente classificar todas as transações como "não fraude", ele alcançará uma acurácia de 99% (990/1000). Impressionante! No entanto, ele falhou em detectar qualquer fraude. Para a empresa, isso representa um desastre. Foi um erro que cometi no início, focando exclusivamente na acurácia para um classificador de "feedback negativo urgente" em minhas Sheets.

Para abordar essa questão, empregamos outras métricas:

• Matriz de Confusão: Esta é uma tabela que compara as previsões do modelo com a realidade. Nela, identificamos os Verdadeiros Positivos (VP), Verdadeiros Negativos (VN), Falsos Positivos (FP) e Falsos Negativos (FN). Compreender esses termos é essencial.
  • VP: O modelo previu Positivo e a realidade era Positivo (acerto)
  • VN: O modelo previu Negativo e a realidade era Negativo (acerto)
  • FP: O modelo previu Positivo e a realidade era Negativo (erro, alarme falso)
  • FN: O modelo previu Negativo e a realidade era Positivo (erro, falha na detecção)
• Precisão (Precision): Entre todas as instâncias que o modelo classificou como Positivas, quantas eram de fato Positivas? Calculada como `VP / (VP + FP)`. É uma métrica crucial quando se busca minimizar falsos positivos (por exemplo: evitar incomodar clientes legítimos com alertas de fraude).
• Recall (Sensibilidade): Das instâncias que eram genuinamente Positivas, quantas o modelo conseguiu identificar? Calculada como `VP / (VP + FN)`. Essencial quando a prioridade é garantir que nenhum positivo seja perdido (por exemplo: detectar todas as fraudes, mesmo que isso implique em alguns falsos positivos).
• F1-Score: Representa a média harmônica entre Precisão e Recall. É uma métrica mais equilibrada, útil em cenários onde tanto os Falsos Positivos quanto os Falsos Negativos possuem relevância.

Para modelos de IA generativa (LLMs) que utilizo para criar textos ou classificar com prompts, a avaliação difere um pouco, mas os princípios subjacentes permanecem. Crio um "golden dataset" contendo exemplos de entrada e as saídas *esperadas* (muitas vezes rotuladas manualmente em Sheets). Em seguida, executo o prompt da IA nesses dados de entrada e comparo sua saída com o resultado esperado. Não há um `accuracy_score` direto, mas posso empregar outra LLM para "julgar" a qualidade da resposta ou desenvolver regras baseadas em palavras-chave para verificar se a saída da IA inclui elementos esperados ou indesejados. Isso constitui uma forma de avaliação por "critérios", onde cada critério funciona como uma medida de "recall" ou "precisão" em si.

Exemplos Práticos da Minha Rotina

Sabe aquela tarefa de condensar centenas de avaliações de produtos em poucas frases para uma visão rápida? Ou categorizar o sentimento de cada uma? Recorro bastante à API do OpenAI para isso.

1. Preparação de Dados: Tenho uma planilha (Sheet) com as avaliações. Crio novas colunas "Sentimento Esperado" e "Resumo Esperado" para uma amostra de 100 a 200 avaliações, preenchendo-as manualmente. Este é o meu "golden dataset" de teste.

2. Prototipagem de Prompt (e validação inicial): Inicio no playground da OpenAI ou em um script Python que invoca a API, experimentando diferentes prompts. Se o prompt visa "Resumir e extrair sentimento", testo-o com 10 a 20 avaliações do meu golden dataset. Ajusto o prompt até que ele pareça eficaz para esses exemplos.

3. Execução e Avaliação: Posteriormente, executo a automação em Python (ou Apps Script, se for mais adequado) para processar as 100-200 avaliações do meu dataset de teste. O resultado (sentimento e resumo gerado) é retornado à planilha, em novas colunas "Sentimento IA" e "Resumo IA".

4. Análise Detalhada: Utilizando Apps Script ou Python, desenvolvo uma rotina para comparar "Sentimento Esperado" com "Sentimento IA". Para os resumos, a análise é mais subjetiva, mas posso empregar um script que verifica a presença de palavras-chave cruciais ou a ausência de "alucinações". Às vezes, realizo uma amostragem aleatória e reviso manualmente 10-20% dos resumos gerados pela IA. Isso me fornece uma métrica de "aceitação humana" para a qualidade do resumo.

5. Refinamento: Se as métricas (ou a revisão humana) não correspondem ao resultado desejado, retorno ao passo 2. Modifico o prompt, talvez incorporando mais exemplos (few-shot learning) ou ajustando os parâmetros da API. Em seguida, repito todo o ciclo de avaliação.

É um processo iterativo. A validação cruzada se torna pertinente quando disponho de diferentes prompts ou pequenas "otimizações" no modelo e desejo determinar qual deles demonstra um desempenho mais consistentemente superior, em vez de depender de uma única rodada de testes.

Validação Cruzada e Avaliação: O Caminho Eficaz x O Caminho Arriscado

Aspecto	Abordagem Manual/Demorada (e Suscetível a Erros)	Abordagem Automatizada (e Confiável)
Divisão de Dados	Copiar e colar linhas aleatórias em abas distintas do Sheets, sem controle sobre a proporção das classes.	Utilizar train_test_split (Python) ou script Apps Script para divisão aleatória estratificada, assegurando a manutenção das proporções de classes e a separação clara dos conjuntos (treino/validação/teste).
Teste de Modelos/Prompts	Testar o modelo ou prompt com os mesmos dados usados para seu ajuste. Exemplo: "Ah, parece que está funcionando!"	Empregar conjuntos de validação e teste *completamente independentes*. Aplicar validação cruzada para estimar o desempenho de maneira robusta e imparcial.
Métricas de Avaliação	Analisar apenas a acurácia geral do modelo. Exemplo: "90% de acerto, excelente!" Ignorar falsos positivos e negativos.	Calcular e interpretar a Matriz de Confusão, Precisão, Recall e F1-Score (Python: sklearn.metrics). Compreender o impacto de cada tipo de erro para o negócio.
Ajuste de Hiperparâmetros/Prompts	Ajustar de forma intuitiva, testando um prompt por vez, sem registrar os resultados ou o processo.	Utilizar GridSearchCV/RandomizedSearchCV (Python) com validação cruzada para identificar parâmetros ótimos. Alternativamente, executar múltiplos prompts em um conjunto de validação e comparar métricas registradas automaticamente.
Confiabilidade dos Resultados	Resultados excessivamente otimistas e que não refletem o desempenho real. O modelo "funciona" bem na sua máquina, mas falha em produção.	Estimativas de desempenho realistas e estáveis. Modelos mais confiáveis e resilientes em ambientes de produção.
Registro e Acompanhamento	Nenhum registro formal. Pergunta comum: "Qual foi a versão do prompt que utilizei na semana passada?"	Manter tabelas de resultados em Sheets ou bancos de dados, documentando versões de prompts, métricas obtidas e os datasets empregados em cada experimento.

Onde o Erro Acontece: Meus Maiores Fracassos na Avaliação

Já cometi todos os erros possíveis, e a maioria deles me custou tempo valioso e me rendeu algumas dores de cabeça consideráveis. É fundamental discutir essas experiências:

• Overfitting "silencioso": Isso ocorreu quando eu estava desenvolvendo um classificador de tipos de documentos (como notas fiscais, boletos, recibos) usando um modelo simples em Python. Dividi os dados, treinei o modelo, e a acurácia no meu "conjunto de teste" parecia ótima. Implementei a solução. Logo, o modelo começou a classificar incorretamente documentos novos. Ao investigar, descobri que meu "conjunto de teste" era, na verdade, o conjunto de validação que eu havia utilizado para ajustar os parâmetros do modelo. Essencialmente, eu havia "treinado" o modelo para ter um bom desempenho especificamente naquele conjunto de "teste", mas ele não representava um teste *genuinamente independente*. Senti-me bastante tolo.
• Focar somente na acurácia em dados desbalanceados: Já mencionei o caso da detecção de fraudes e do feedback urgente. Houve, ainda, uma situação com um classificador de e-mails para identificar "pedidos de cancelamento". De 1000 e-mails, talvez 20 eram solicitações de cancelamento. Meu modelo atingiu 98% de acurácia. Parece excelente, certo? No entanto, ele estava ignorando metade dos e-mails de cancelamento (apresentando baixo recall). Isso resultava em clientes insatisfeitos que não eram atendidos em tempo hábil. A acurácia, nesse contexto, era uma ilusão agradável.
• Rotulagem de dados inconsistente no Google Sheets: Este é um problema persistente, especialmente quando se depende de outras pessoas (ou da própria pessoa em dias diferentes) para rotular dados no Sheets para o treinamento. Eu tinha um dataset de títulos de notícias que seria usado para treinar um modelo de categorização. As categorias eram "Política", "Economia", "Esportes". A pessoa que me auxiliou na rotulagem, por vezes, empregava termos como "Política Nacional" ou "Esportes Locais", ou até mesmo "Politicagem". O modelo ficava confuso, e as métricas de avaliação resultavam em valores baixos. Eu desperdiçava horas depurando o código ou o prompt, quando a falha residia na própria "verdade" dos meus dados. Nenhuma validação pode corrigir dados sujos.
• Ausência de um "golden dataset" para IA generativa: Inicialmente, eu testava prompts de LLM com exemplos aleatórios. "Ah, este resumo ficou bom para este texto, vou usá-lo." Mas e para 500 textos? Nem sempre o que funciona para um exemplo é eficaz para outro. Sem um conjunto fixo de entradas e saídas esperadas (o meu golden dataset), eu me via em um ciclo vicioso, acreditando que um prompt era bom, alterando-o, e depois retornando à versão anterior sem saber qual era, de fato, a melhor. Era um cenário caótico.
• Ignorar o custo do erro: Em certas situações, um Falso Positivo é consideravelmente mais prejudicial que um Falso Negativo, ou vice-versa. Por exemplo, em um sistema que identifica informações sensíveis para censura antes de enviar um e-mail. Um Falso Negativo (permitir que informações sensíveis passem) seria um desastre. Já um Falso Positivo (censurar algo que não era sensível) é inconveniente, mas menos grave. A validação deve considerar o impacto real dos erros. Minhas métricas iniciais não refletiam essa distinção, e minhas prioridades de ajuste estavam equivocadas.

FAQ - Perguntas Técnicas Rápidas

1. Quando devo usar validação cruzada (k-fold) em vez de uma simples divisão treino/validação/teste?

Utilize k-fold quando você possui um dataset de menor porte (com menos de alguns milhares de exemplos) para obter uma estimativa de desempenho mais robusta e reduzir a variabilidade do resultado da avaliação. Essa técnica é excelente para comparar modelos ou ajustar hiperparâmetros. Se seu dataset é muito extenso (milhões de exemplos), uma única divisão em treino/validação/teste geralmente é suficiente e mais viável do ponto de vista computacional.

2. Como avalio um modelo de IA generativa (como um LLM) se não disponho de métricas numéricas tradicionais como acurácia?

Para LLMs, a avaliação é intrinsecamente mais complexa e frequentemente envolve uma combinação de abordagens:

• Avaliação Humana: Crie um "golden dataset" com entradas e registre as saídas da IA. Realize uma avaliação humana da qualidade, relevância, coerência e ausência de alucinações. Isso pode ser organizado em um Google Sheet, com colunas dedicadas a cada critério.
• Métricas Baseadas em Regras/Palavras-chave: Desenvolva scripts (em Python ou Apps Script) para verificar a presença ou ausência de termos específicos, a estrutura da frase ou o formato da saída. Por exemplo, se o LLM deve extrair nomes, verifique se a saída realmente contém nomes.
• Outras LLMs como Avaliadoras: Em alguns contextos, é possível empregar uma LLM maior e mais potente para "julgar" a qualidade da resposta de uma LLM menor ou de um prompt diferente, utilizando um prompt de avaliação específico.
• Métricas de Similaridade de Texto: Para tarefas como sumarização, métricas como ROUGE ou BLEU (em Python) podem ser utilizadas para comparar a saída gerada com um "resumo ideal" elaborado por humanos, embora essas métricas nem sempre capturem a totalidade das nuances.

3. Qual o erro mais comum que você observa (ou já cometeu) na avaliação de modelos?

O erro mais recorrente, sem dúvida, é a ausência de um conjunto de teste verdadeiramente independente, ou a contaminação desse conjunto pelo processo de ajuste do modelo/prompt. Frequentemente, ajustamos um modelo ou prompt, testamos no "conjunto de teste", percebemos que não está bom, ajustamos novamente e testamos no *mesmo* conjunto de teste. A cada ajuste, estamos, de forma inconsciente, "treinando" para aquele conjunto específico, o que faz com que a métrica final perca sua imparcialidade. O conjunto de teste deve ser utilizado apenas UMA VEZ, no final do processo, para a avaliação derradeira do modelo escolhido.

Conclusão

No fim das contas, a validação cruzada e a avaliação de modelos não são um luxo, mas uma necessidade inegável. Não se trata de parecer um "cientista de dados" ultra-sofisticado, mas de construir soluções que efetivamente funcionem no cotidiano. É sobre evitar retrabalho, prevenir falhas em sistemas e, francamente, conquistar tranquilidade. Já investi inúmeras horas tentando corrigir automações de IA que "pareciam boas", mas que não haviam sido devidamente validadas. Hoje, mesmo nos meus scripts mais simples, dedico um tempo considerável a essa etapa.

Pode parecer um processo monótono, pode dar a impressão de atrasar o projeto, mas a verdade é que se trata de um investimento essencial. Um modelo bem avaliado é um modelo no qual você pode depositar sua confiança. E para quem vive de automações, ter confiança naquilo que se constrói é absolutamente tudo.