Como escolher um modelo local de IA com as suas próprias tarefas

A pergunta útil não é qual modelo é melhor em geral

Se tem vários modelos locais candidatos, uma pontuação publicada ou uma demonstração convincente não basta para saber qual deles será útil no seu fluxo de trabalho. A decisão relevante é mais concreta: qual destes modelos executa de forma aceitável a tarefa que realmente pretende realizar, no equipamento e com a configuração que vai utilizar?

Um teste de aceitação responde a essa pergunta através de um conjunto reduzido de tarefas reais ou representativas, de critérios definidos antes de ver as respostas e de condições de execução comparáveis. Por exemplo, uma equipa que pretende classificar pedidos pode verificar se cada modelo atribui corretamente uma categoria e devolve um resultado que o seu sistema consegue processar. A avaliação não consiste em escolher a resposta que soa melhor, mas em verificar requisitos observáveis.

Este método não transforma uma pequena amostra numa classificação geral de modelos. Pode revelar incompatibilidades práticas — como o incumprimento de um formato ou erros num tipo frequente de entrada —, mas não demonstra que o candidato seja fiável noutras tarefas, com outros utilizadores ou noutro equipamento. A conclusão deve limitar-se ao que foi testado.

O objetivo também é diferente do de comparar quantizações: durante este teste, convém manter fixa a configuração relevante, em vez de decidir entre 4, 6 ou 8 bits. Também não é um teste de concorrência, que examina pedidos simultâneos, nem uma auditoria de privacidade, que investiga o tráfego de rede. Se uma destas questões for decisiva, precisa de uma avaliação própria.

Comece por definir a tarefa e o limiar de aceitação

Antes de descarregar candidatos, descreva o trabalho que pretende delegar. Evite objetivos vagos como «responder bem» ou «ser inteligente». Especifique o que o modelo recebe, que resultado espera e que erros impediriam a sua utilização. Quanto mais a descrição se aproximar de uma tarefa do fluxo de trabalho, mais fácil será criar exemplos que permitam distinguir os candidatos.

Defina também o que significa «aceitável». Um rascunho pode ser útil mesmo que precise de revisão; uma extração de dados incorporada automaticamente numa base de dados pode exigir campos completos e um formato válido em todos os casos críticos. Estas são decisões da equipa, não propriedades universais de um modelo. Registe-as antes de comparar as respostas para reduzir o risco de alterar a fasquia a favor de um candidato.

Separe os critérios que descrevem resultados diferentes. A correção do conteúdo, o cumprimento das instruções e a validade do formato não são equivalentes. Uma resposta pode estar correta e, ainda assim, não respeitar o esquema exigido; outra pode ter o formato perfeito e conter um dado errado. Se combinar estes aspetos sem explicação numa única nota, perde informação que pode alterar a decisão.

Se houver mais do que uma pessoa a avaliar, acordem antecipadamente como vão resolver os desacordos. Em tarefas subjetivas, é útil que duas pessoas avaliem separadamente pelo menos uma parte dos exemplos e comparem as respetivas razões. Se houver discordância, registem a regra que ficou ambígua e ajustem-na antes de interpretar diferenças pequenas entre modelos. Não é necessário fingir que uma preferência de estilo tem uma resposta objetiva.

Escolha os candidatos e fixe as condições

Compare candidatos que façam sentido para a mesma utilização. Registe o identificador exato e a versão disponível de cada modelo, juntamente com o ambiente de execução, o equipamento, o sistema utilizado e os parâmetros relevantes. Sem esses dados, uma diferença observada pode dever-se ao ambiente, e não ao modelo, e será mais difícil para outra pessoa repetir o teste.

Mantenha iguais as condições que puder controlar: equipamento, ambiente de execução e respetiva versão, texto das instruções, exemplos de entrada, limite de contexto, parâmetros de geração e tratamento do resultado. Se um modelo precisar de uma configuração diferente para arrancar, documente a exceção e considere se a comparação continua a responder à mesma pergunta. Não altere os parâmetros a meio do teste para melhorar as respostas de um favorito sem voltar a executar os restantes em condições equivalentes.

Nos geradores cujas respostas podem variar entre execuções, registe também os parâmetros que influenciam a geração e repita os casos selecionados. Uma repetição não elimina toda a incerteza, mas pode mostrar que o resultado dependeu de uma resposta particularmente favorável. A documentação do Ollama, por exemplo, descreve parâmetros de geração configuráveis no formato Modelfile; as opções concretas disponíveis e o seu significado devem ser confirmados na documentação atualizada do ambiente de execução utilizado.

O registo de memória e latência deve descrever o método, não apenas apresentar um número. Anote que operação mediu, que ferramenta utilizou, quantas repetições realizou e se o sistema estava a executar outras tarefas. Uma medição local pode ser útil para tomar uma decisão nesse equipamento, mas não se aplica automaticamente a outro dispositivo.

Crie um pequeno conjunto que represente o trabalho

Não escolha apenas exemplos fáceis nem casos de que se lembre por um candidato os ter resolvido bem. Reúna entradas típicas da utilização prevista e acrescente situações que costumam causar problemas. A amostra inicial pode ser pequena, desde que cada caso tenha um propósito explícito; o importante é não a apresentar como uma representação estatística de todo o trabalho.

Inclua pelo menos três tipos de entrada: casos comuns, casos-limite e casos em que o modelo deveria reconhecer que as informações disponíveis não são suficientes. Se a tarefa depender de instruções de formato, acrescente exemplos que permitam verificá-las. Se depender de conteúdo fornecido pelo utilizador, verifique se o modelo se limita a esse conteúdo, em vez de preencher lacunas com suposições.

Prepare uma resposta esperada ou um guia de avaliação para cada exemplo antes de executar os modelos. Nem sempre é necessário fixar uma única frase como resposta correta: para um resumo, pode ser mais adequado enumerar os factos que devem aparecer e as afirmações que não devem ser acrescentadas. Para uma extração estruturada, pelo contrário, pode haver valores concretos e um formato esperado.

Proteja a qualidade do conjunto. Evite incluir informações confidenciais se não forem necessárias, remova identificadores pessoais que não façam parte do caso e guarde as entradas de modo que os avaliadores saibam que dados estavam disponíveis. Se alterar um exemplo depois de ver os resultados, identifique-o como uma nova versão; não misture silenciosamente o teste original com uma versão revista.

Avalie dimensões separadas e registe as falhas

Uma grelha de avaliação prática distingue, no mínimo, a correção para a tarefa, o cumprimento das instruções, a utilidade do formato e os erros críticos. Defina o que constitui um erro crítico para a utilização prevista: por exemplo, uma extração incorreta que seria processada sem revisão pode ter um custo diferente de uma frase pouco elegante num rascunho. Não substitua a definição da equipa por uma lista genérica de riscos.

Além da qualidade da tarefa, meça separadamente a latência e a memória observada. Estas dimensões respondem a perguntas diferentes: se o resultado é útil, quanto tempo demora segundo o método escolhido e que recursos o sistema pareceu consumir durante essa execução. Evite reuni-las numa única nota, a menos que explique como foram ponderadas e por que razão esses pesos representam uma necessidade real. Muitas vezes, é mais útil apresentar uma tabela de resultados por dimensão e discutir os compromissos.

Registe cada falha com o caso, a resposta, o critério não cumprido e a gravidade atribuída. Agrupe as falhas por tipo — como omissão, dado inventado, formato inválido ou instrução ignorada — desde que essas categorias correspondam à tarefa. Assim, poderá distinguir um padrão repetido de um erro isolado. Não esconda uma falha crítica por trás de uma média elevada em casos simples.

As medições de desempenho precisam de uma nota metodológica. A ferramenta llama-bench do llama.cpp documenta repetições e estatísticas como a média e o desvio-padrão, além de medidas distintas para o processamento do prompt e para a geração. Também assinala limites do que é incluído na medição. Isto mostra por que razão convém descrever exatamente o que foi medido, em vez de tratar qualquer valor como uma medida universal de rapidez.

Execute, reveja e tome uma decisão com âmbito limitado

Execute cada caso com o mesmo prompt e nas condições registadas. Conserve os resultados originais, incluindo os defeituosos; editar ou descartar uma resposta antes de a avaliar torna o teste menos reproduzível. Se houver variabilidade, repita os casos selecionados segundo um procedimento definido e guarde cada resultado, não apenas aquele que parecer mais representativo.

Para reduzir os enviesamentos, avalie as respostas sem mostrar o nome do modelo, quando for viável. Se não for possível ocultá-lo, aplique pelo menos a mesma grelha a todos os candidatos e registe as divergências. Numa avaliação humana, critérios explícitos e avaliadores adicionais, sempre que possível, ajudam a identificar decisões subjetivas; se indicar a concordância entre avaliadores, explique o que foi comparado e como foram resolvidas as diferenças.

No final, decida se cada candidato será adotado para uma utilização limitada, ajustado e testado novamente, ou descartado. Um ajuste altera as condições do teste: guarde a versão anterior e repita a comparação de forma equivalente. A escolha pode depender de um requisito eliminatório — por exemplo, todos os campos obrigatórios terem de ser válidos — e não de quem obteve a melhor pontuação global.

Uma decisão responsável também pode ser «nenhum cumpre». Se as falhas afetarem requisitos essenciais, não precisa de escolher o menos mau para encerrar a comparação. Se um candidato parecer adequado, a conclusão continua a ser provisória e limitada aos exemplos, à configuração e ao equipamento testados.

Limites, manutenção e recursos relacionados

Um teste pequeno é suscetível a enviesamento na seleção: os exemplos podem favorecer uma forma de escrever, um domínio ou um tipo de entrada. Também depende do prompt e da configuração. Publique os casos utilizados, os critérios aplicados e as condições de execução; não extrapole o resultado para outras tarefas, versões, equipamentos ou grupos de utilizadores sem evidências adicionais.

Se a utilização mudar, reveja o teste. Acrescentar uma nova fonte de dados, alterar o formato de entrada ou automatizar uma resposta que antes era revista por uma pessoa pode mudar a importância relativa das falhas. Guarde versões do conjunto e da grelha de avaliação para conseguir interpretar comparações futuras. Uma pontuação antiga não garante que o comportamento continue a ser aceitável depois de o sistema ser alterado.

As ferramentas de avaliação podem ajudar a organizar tarefas e métricas, mas não decidem o que significa ter sucesso no seu caso. O projeto lm-evaluation-harness documenta tarefas, métricas, prompts personalizados e avaliação local. Pode servir de referência ou ferramenta quando se adequar à necessidade, mas uma pontuação produzida por uma tarefa padrão não substitui exemplos próprios nem demonstra que o modelo cumpre os seus requisitos.

Este guia centra-se em aceitar ou descartar candidatos para uma tarefa específica. Para aprofundar a pesquisa, consulte o guia de modelos locais, o comparador e a área de descoberta. Se a próxima questão for sobre quantização, concorrência ou privacidade, trate-a como uma decisão separada: mudar o foco sem mudar também o protocolo pode fazer com que a comparação deixe de responder à pergunta inicial.

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.