Escolher um modelo de fundação

O domínio anterior já ensinou como escolher um modelo: elimine pelas restrições duras, avalie os sobreviventes na sua própria tarefa e otimize os que passam por custo e latência. Esse método é a ordem das operações. Esta lição é a lista de verificação sobre a qual ele opera.

O guia do exame, na Task Statement 3.1, nomeia um conjunto específico de critérios para escolher um modelo de fundação pré-treinado: custo, modalidade, latência, suporte multilíngue, tamanho do modelo, complexidade do modelo, customização e comprimento de entrada e saída. Cada um é um tipo diferente de pergunta, e cada um carrega uma consequência de design que você sente depois se pular. Uma questão sobre este tema costuma esconder um desses critérios na redação do cenário e tornar tentadora a resposta que ganharia se aquela frase não estivesse ali. Então a habilidade útil é reconhecer qual critério um cenário está de fato cobrando.

Vamos percorrê-los na ordem em que costumam morder, não na ordem em que o guia lista.

Modalidade: o que entra, o que sai

A modalidade é o tipo de dado que um modelo aceita e produz. Um modelo de texto lê e escreve texto. Um modelo multimodal aceita imagens, áudio ou vídeo junto com texto. Um modelo de embedding devolve vetores em vez de prosa. Um modelo de geração de imagem produz figuras a partir de uma descrição.

Esses tipos não são intercambiáveis, e nenhum outro critério resgata uma incompatibilidade de modalidade. Um modelo só de texto não lê uma nota fiscal digitalizada, não transcreve uma chamada e não descreve uma foto, e fine-tuning não adiciona um tipo de entrada. É por isso que a modalidade é a primeira coisa a checar: ela elimina candidatos de saída, antes mesmo de a qualidade entrar em jogo.

É também o critério que o exame disfarça com mais frequência. Um cenário menciona documentos digitalizados, fotos de produto ou gravações de áudio, e então oferece um modelo só de texto como a opção com os melhores benchmarks. As pontuações são um distrator. Leia o cenário para saber qual é a entrada de verdade antes de ler as capacidades do modelo.

Comprimento de entrada e saída: dois limites, não um

Todo modelo publica dois limites de comprimento, e confundir os dois é um jeito confiável de publicar um recurso quebrado.

A janela de contexto é o número máximo de tokens que o modelo consegue receber em uma única requisição. Tudo conta contra ela: as suas instruções, qualquer documento recuperado, a conversa até aqui e a pergunta do usuário. O comprimento máximo de saída é um limite separado sobre quantos tokens o modelo consegue gerar em uma resposta, e costuma ser bem menor que a janela de contexto.

A distância entre os dois é maior do que a maioria espera. Um modelo pode publicar uma janela de contexto de 200.000 tokens com uma saída máxima de apenas alguns milhares. Essa combinação lê um documento muito longo com folga, mas não escreve um documento muito longo. Um time que lê "200.000 tokens" e planeja gerar um relatório inteiro em uma chamada recebe uma resposta que para no meio, e nada no erro explica por quê.

Então a pergunta de design se divide em duas. Quanto uma única requisição precisa receber, o que define o piso da janela de contexto, e quão longa a resposta precisa ser, o que define o piso do comprimento de saída. Um recurso de resumo é pesado na entrada e leve na saída. Um recurso de redação de textos longos é o inverso. Case o modelo com a direção para a qual a sua carga pende.

Suporte multilíngue

Um modelo treinado sobretudo em inglês ainda produz espanhol ou árabe quando pedido, mas muitas vezes com gramática mais fraca, vocabulário mais raso e mais erros do que comete em inglês. A capacidade geral não se transfere de forma uniforme entre idiomas, e é por isso que o guia lista o suporte multilíngue como critério próprio em vez de dobrá-lo dentro da exatidão.

A consequência é prática. Se os seus usuários escrevem em português e leem respostas em português, um modelo que lidera benchmarks em inglês mas tropeça em português é a escolha errada, e você só vê o problema testando no idioma que os seus usuários usam de fato. Quando um cenário nomeia um público não anglófono ou uma exigência multi-idioma, esse critério vai para a frente.

Tamanho do modelo e complexidade do modelo

O guia lista tamanho do modelo e complexidade do modelo como dois critérios, e eles apontam para o mesmo trade-off por dois ângulos. Tamanho se refere ao número de parâmetros. Complexidade se refere a quanta capacidade isso compra e ao que custa rodar.

O instinto que quase todo mundo traz é que um modelo maior é a escolha mais segura. Não é, e o exame recompensa quem sabe por quê. Um modelo maior custa mais por token, gera mais devagar porque faz mais trabalho por token e muitas vezes não mostra nenhuma melhora mensurável em uma tarefa estreita e bem especificada. Um classificador que separa tickets de suporte em oito categorias não precisa de raciocínio de fronteira. Pagar por capacidade que a tarefa nunca exerce é desperdício que se repete em cada requisição, para sempre.

O padrão que se sustenta na prática é começar com um modelo menor e subir só quando a sua avaliação mostra uma lacuna real. Times que começam no topo raramente descem, porque ninguém se voluntaria para deixar o assistente um pouco pior para economizar, então o gasto a mais vira permanente. Quando um cenário te dá um orçamento apertado de latência ou uma tarefa simples e delimitada e oferece um modelo grande como opção, o modelo menor que ainda passa costuma ser a resposta pretendida.

Suporte a customização

Se o seu plano depende de adaptar o modelo, seja por fine-tuning nos seus exemplos, seja por fundamentá-lo nos seus dados, você tem que confirmar que o modelo oferece suporte a esse caminho antes de se comprometer com ele. Nem todo modelo pode passar por fine-tuning, e os que podem diferem em quais métodos aceitam e em que formato de dados esperam.

Este é um critério de seleção justamente porque descobrir o limite tarde é caro. Um time que escolhe um modelo só pela qualidade, constrói em volta dele e então descobre que não dá para fazer fine-tuning do jeito que o caso de uso precisa tem que refazer a seleção do zero. Os trade-offs de customização em si são uma lição posterior deste tema. Aqui o ponto é mais estreito: se a customização faz parte do plano, ela faz parte da seleção.

Latência e custo

Estes são os dois critérios que você otimiza depois que um modelo passou por tudo o que está acima, e as lições anteriores cobriram os dois a fundo, então vamos ser breves.

A latência é a rapidez com que o modelo responde. Modelos maiores são mais lentos, e a geração é sequencial, então uma resposta longa de um modelo grande pode levar vários segundos. Uma experiência de chat ao vivo tem um orçamento de latência; um job em lote noturno normalmente não tem. Verifique que um modelo atende ao orçamento antes de construir um recurso em tempo real sobre ele, em vez de esperar fechar a lacuna depois.

O custo é movido sobretudo pela escolha do modelo, mais do que por qualquer otimização de prompt. A mesma carga pode diferir por ordens de grandeza entre dois modelos da mesma família. Entre os modelos que passam por todas as outras barreiras, o mais barato e rápido que ainda atinge o seu padrão de qualidade é a escolha certa.

Os critérios de uma vez

Dicas para o exame

• Memorize a lista nomeada: custo, modalidade, latência, multilíngue, tamanho do modelo, complexidade do modelo, customização, comprimento de entrada e saída. Depois, para qualquer cenário, ache qual deles está decidindo.
• Modalidade é o filtro escondido mais comum. Entrada não textual no cenário mais um modelo só de texto nas opções significa que aquela opção está errada, quaisquer que sejam as pontuações.
• Comprimento de entrada e comprimento de saída são limites separados. Uma janela de contexto grande não promete uma resposta longa. Fique atento a um cenário que precisa de geração longa e um modelo com teto de saída pequeno.
• Suporte multilíngue aparece quando o público é nomeado como não anglófono. Pontuações gerais de benchmark não resolvem isso.
• Complexidade do modelo é uma troca, não uma meta. Latência apertada ou tarefa estreita apontam para o modelo menor que ainda passa.
• Suporte a customização é checado antes da seleção, não depois. Se o plano diz fine-tuning, confirme que dá para fazer fine-tuning do modelo.

A regra para levar a uma questão: leia primeiro em busca da restrição, depois case ela com um dos oito critérios. A maioria dos cenários de escolha de modelo gira em torno de uma única frase. A próxima lição sai de escolher o modelo para controlar como ele responde, usando os parâmetros de inferência que você define em toda requisição.