Da data de lançamento à métrica: como auditar o progresso real da IA

A armadilha da cronologia

Um modelo anunciado recentemente não é necessariamente melhor para o trabalho que importa. A data de lançamento ordena acontecimentos, mas não mede capacidades. Também não basta comparar o número de parâmetros, o comprimento máximo de contexto ou o nome de uma arquitetura: esses dados descrevem aspetos do sistema, mas não provam, por si só, que ele resolva melhor uma tarefa concreta.

A pergunta útil não é «que modelo foi lançado depois?», mas sim «o que mudou, em que condições foi medido e que consequências tem para o meu uso?». Para responder, é preciso comparar tarefas, configurações, dados de avaliação, custos e modos de falha. Se essas informações faltarem, a conclusão correta não é declarar uma melhoria nem descartá-la, mas registar que as evidências são insuficientes.

Avaliar também pode exigir olhar para além da exatidão. O artigo da Funcas sobre métricas de IA defende que o desempenho técnico, por si só, não capta dimensões como enviesamentos, sustentabilidade ou impacto social. Por sua vez, a AESIA apresenta guias práticos sobre exatidão, robustez, gestão de riscos e governação de dados para sistemas abrangidos pelo âmbito do Regulamento Europeu da Inteligência Artificial. São enquadramentos complementares: nenhum substitui uma comparação experimental entre duas versões de um modelo.

Três dimensões para avaliar a mudança

A primeira dimensão é a eficiência de inferência: quanto custa produzir uma resposta com determinada qualidade, com que latência e com que requisitos operacionais. O custo por token é uma peça da análise, não uma conclusão isolada. Também importam o tamanho dos pedidos, a utilização de cache, a simultaneidade, o hardware, a disponibilidade e o custo de corrigir respostas erradas. Uma melhoria de qualidade pode ter um preço operacional que não compense em todas as aplicações.

A segunda dimensão é a robustez em tarefas definidas. Uma média global pode esconder descidas de desempenho em certos idiomas, formatos, grupos de utilizadores ou casos pouco frequentes. Convém registar os resultados por subconjuntos, a dispersão entre execuções quando exista aleatoriedade e as falhas em situações-limite. Em produção, um sistema que acerta muitas vezes, mas falha de forma grave numa condição previsível, pode ser menos útil do que outro com uma média ligeiramente inferior e um comportamento mais estável.

A terceira dimensão é a mudança técnica e o seu efeito observado. Uma arquitetura densa, uma arquitetura de mistura de especialistas ou um mecanismo híbrido podem alterar a utilização de computação, a capacidade de escalar e as necessidades de serviço. No entanto, conhecer a arquitetura não permite deduzir automaticamente o desempenho nem a eficiência. É preciso medir o sistema completo sob cargas e condições comparáveis e distinguir os parâmetros totais dos parâmetros ativos, quando a documentação os discrimina.

Arquitetura, contexto e benchmarks: o que os exemplos permitem concluir

As arquiteturas de mistura de especialistas, ou MoE, são frequentemente descritas como uma forma de ativar apenas uma parte dos componentes para cada entrada. Essa descrição pode ajudar a formular uma hipótese sobre a computação por pedido, mas não prova que um modelo MoE seja automaticamente mais barato ou melhor do que um modelo denso. A comparação depende de pormenores do treino, do encaminhamento, do hardware e do serviço, além da qualidade nas tarefas avaliadas. As fontes verificadas disponíveis para este artigo não incluem resultados comparativos que permitam afirmar uma vantagem geral das arquiteturas MoE.

Uma janela de contexto maior também representa uma capacidade potencial, não uma garantia de retenção perfeita. Para a avaliar, é necessário testar tarefas longas e especificar onde aparece a informação relevante, quanto texto é introduzido e o que conta como resposta correta. Um resultado num teste sintético não basta para concluir que o modelo mantém o mesmo desempenho com documentos reais, instruções complexas ou conteúdo distribuído ao longo de uma conversa.

Os benchmarks podem perder capacidade para distinguir modelos quando muitos obtêm resultados semelhantes, mas não se deve falar em «estagnação» sem dados comparáveis e documentados. É necessário conhecer o conjunto de avaliação, a versão utilizada, o protocolo de pontuação e a possível exposição prévia aos exemplos. As fontes fornecidas não apresentam séries de resultados entre versões nem evidências sobre contaminação de benchmarks. Por isso, estas possibilidades devem ser tratadas como perguntas de auditoria, não como conclusões deste artigo.

Protocolo para auditar um anúncio de modelo

Comece por transformar a promessa numa hipótese verificável. «É mais inteligente» não define um teste. «Reduz as omissões na extração de datas de contratos sem aumentar o custo por pedido acima de um limite acordado» já permite conceber uma avaliação. Antes de testar o modelo, determine que tarefas são importantes, como serão pontuadas e que nível de erro é aceitável.

Depois, confirme se a comparação é válida. Utilize entradas equivalentes, configure os modelos de forma documentada e repita os testes quando houver variabilidade. Registe o fornecedor ou a versão, a data de acesso, os parâmetros de geração, as ferramentas ativadas, os limites de saída e as condições de serviço. Se os resultados vierem de avaliações diferentes, não os apresente como uma comparação direta sem justificar a equivalência.

Por fim, procure evidências sobre reprodutibilidade e riscos da avaliação. Pergunte se estão disponíveis o código, os dados de teste e as instruções necessárias para repetir a experiência; não presuma que os dados de treino serão públicos. Analise possíveis sobreposições entre os exemplos de avaliação e os materiais usados para treinar ou ajustar o sistema. Se não houver informações que permitam verificá-las, declare essa limitação em vez de afirmar que existe contaminação.

Da avaliação técnica à decisão de investimento

Uma auditoria útil não termina com uma classificação de modelos. Transforma as evidências numa decisão: adotar, testar num grupo limitado, aguardar informações adicionais ou melhorar o sistema existente. Se a nova capacidade resolver um verdadeiro estrangulamento e o custo total for aceitável, poderá justificar um teste controlado. Se a melhoria não se repetir nas tarefas próprias ou aumentar um risco importante, poderá ser preferível dar prioridade a otimizações, controlos ou alternativas.

Em utilizações com consequências relevantes, o enquadramento deve incluir dimensões que não se reduzem a uma pontuação de benchmark. A Funcas assinala a necessidade de considerar questões como os enviesamentos, a sustentabilidade e o impacto social. A AESIA descreve guias não vinculativos para apoiar a aplicação do Regulamento Europeu da Inteligência Artificial, incluindo materiais sobre gestão de riscos, governação de dados, exatidão e robustez para os sistemas abrangidos pelo seu âmbito. A aplicabilidade depende do sistema e do contexto: não é correto tratar esses guias como uma obrigação universal para qualquer ferramenta.

O critério final deve ser proporcional às evidências e ao risco. Um anúncio pode justificar a investigação de uma nova capacidade, mas não permite considerá-la comprovada. Enquanto não houver uma avaliação comparável, tão reprodutível quanto possível e representativa da utilização prevista, a conclusão mais rigorosa é manter a incerteza. Assim, a data de lançamento regressa ao seu devido lugar: é um dado cronológico, não um indicador autónomo de progresso.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.