Seleção de modelo: o modelo certo para o trabalho certo

Ganhos:

• Pode comparar famílias de modelos (rápido/equilibrado/potente) em termos de capacidade, velocidade e custo
• Projeta seleção de modelos e estratégias de roteamento de acordo com a complexidade da tarefa
• Baseia a seleção do modelo em evidências com um pequeno conjunto de avaliações

A única decisão que determina o melhor retorno financeiro e a qualidade na integração LLM é qual modelo você usa. O reflexo comum é “escolher o modelo mais forte”; No entanto, isso muitas vezes significa custos e atrasos desnecessários. A abordagem correta é escolher o modelo mais leve que realize cada tarefa e basear essa escolha em medições, e não em suposições. Nesta unidade, você comparará a família de modelos no eixo capacidade/velocidade/custo, estabelecerá uma estratégia de roteamento de modelo de acordo com a complexidade da tarefa e evidenciará a seleção com um pequeno conjunto de avaliações.

Compreendendo a família modelo

Os provedores geralmente oferecem três classes: rápido/barato, estável e poderoso. A relação entre eles se resume em três eixos: capacidade (poder para resolver tarefas difíceis), velocidade (latência), custo (preço do token).

aula

exemplo

talento

velocidade

Custo

Tarefas disponíveis

rápido

Haiku 4.5

médio

muito alto

baixo

Classificação, rotulagem, breve resumo, orientação

equilibrado

soneto 5

alto

alto

médio

Uso geral, codificação, fluxo de várias etapas, a maior parte do trabalho do agente

forte

Opus 4.8

mais alto

médio

alto

Raciocínio complexo, tarefas autônomas de longo alcance, análise difícil

Insight crítico: o modelo mais poderoso não tem melhor desempenho em todos os trabalhos. Numa simples rotulagem “urgente ou não”, o modelo forte e o modelo rápido dão a mesma resposta correta; a única diferença é que o potente é 5 vezes mais caro e mais lento. Talento extra só produz valor quando a missão assim o exige.

Passo a passo: como escolher um modelo?

1. Classifique a tarefa. É rotineiro/padronizado (rotulagem, inferência) ou aberto/de múltiplas etapas (análise, planejamento, código)?
2. Comece com o candidato mais leve. Experimente com o modelo rápido. Se isso for suficiente, pare.
3. Se não for suficiente, passe para uma classe superior. Se a precisão for baixa, vá para o equilibrado, se não for suficiente, vá para o forte.
4. Meça, não adivinhe. Compare a precisão e o custo de cada candidato com um pequeno conjunto de avaliações (abaixo).
5. Configure o redirecionamento. Em vez de conectar-se a um único modelo, distribua a tarefa ao modelo certo com um “roteador”.

Roteamento de modelo

As cargas de trabalho reais são mistas: a maioria das solicitações recebidas são simples, algumas são difíceis. É um desperdício enviá-los todos para o modelo poderoso; Enviar todos para o modelo rápido reduz a qualidade. O roteamento resolve isso: um modelo barato (ou uma regra simples) classifica a tarefa primeiro e depois a tarefa vai para o modelo apropriado.

# Prompt do roteador (funciona com modelo barato) Classifique a solicitação recebida de acordo com sua dificuldade. Retorne apenas o seguinte JSON:{"difficulty": "simple|complex"}Simples: etapa única, fórmula, resposta curta.Complexo: requer raciocínio em várias etapas, análise ou geração longa.Solicitação: """{{request}}"""

• vá para modelo simples → rápido (barato, rápido).
• vá para modelo complexo → poderoso (caro, mas necessário).

Este padrão reduz significativamente o custo médio porque a maior parte do tráfego é geralmente simples.

Dica: Uma decisão de indicação nem sempre exige um LLM. Regras simples como “Vá para o modelo rápido se o texto tiver menos de 20 palavras” também são um guia e trazem zero custo adicional de token. Experimente a regra primeiro.

Vinculando a escolha às evidências: o pequeno grupo de avaliação

Não escolha um modelo baseado em “me parece melhor”. Eval (conjunto de avaliação) é um pequeno conjunto de amostras para as quais a resposta correta é conhecida; você executa cada modelo neste conjunto e mede a precisão, o custo e a latência.

# Modelo de configuração de avaliação1) Colete de 20 a 50 exemplos reais, escreva à mão a "resposta correta" em cada um.2) Execute cada modelo (rápido/equilibrado/forte) neste conjunto.3) Para cada modelo: número de acertos, tokens de rendimento médio, custo por solicitação, tempo médio.4) Escolha o modelo que "fornece precisão suficiente e mais barato".

# Tabela de comparação de avaliação (preenchimento)Modelo | Precisão | Custo por pedido | Duração médiaHaicai | ...% | ... $ | ... snSoneto | ...% | ... $ | ... snOpus | ...% | ... $ | ...seg

Alerta fraco / Alerta forte (decisão de seleção de modelo)

# FRACO (sem base para decisão)Vamos usar o melhor modelo, o orçamento não é importante.

# FORTE (decisão baseada na medição) Na avaliação de 50 amostras, o Haiku deu 96% de precisão, o Sonnet deu 97% de precisão; A diferença é estatisticamente insignificante. O Haiku foi escolhido porque é 5 vezes mais barato e 2 vezes mais rápido. Se a precisão cair abaixo de 95%, a decisão de atualizar para o Sonnet será tomada automaticamente.

Versão poderosa; vincula a seleção a um número, um limite e uma regra de escalonamento. Isto tanto defende a decisão de hoje como gere as mudanças futuras.

Três Mini Estojos

Caso 1 — Fuga do modelo avassalador. Uma central de atendimento produzia todos os resumos das conversas com a Opus; a conta mensal era alta. Na avaliação de 40 amostras, o Sonnet estava 1% atrás do Opus em precisão, mas custou um terço. Eles transferiram o trabalho resumido para o Soneto; o custo mensal caiu de US$ 9.000 para US$ 3.100, sem reclamações de qualidade.

Caso 2 — Tráfego misto com redirecionamento. 80% das solicitações de uma equipe de tecnologia jurídica eram simples etiquetas de documentos, 20% eram análises complexas de contratos. Eles estavam enviando todos para o modelo poderoso. Eles adicionaram um roteador barato e distribuíram trabalhos simples para o Haiku e trabalhos complexos para o Opus; o custo médio das solicitações caiu 64%, enquanto a qualidade da análise foi mantida.

Caso 3 — O custo do downsizing sem mensuração. Para reduzir custos, uma equipe reduziu a extração complexa de códigos médicos diretamente para o modelo rápido; Eles não avaliaram. Ao vivo, a precisão caiu de 92% para 78%, resultando no retorno de inferências incorretas. Eles tiveram que avaliar primeiro: essa tarefa exigia um modelo poderoso. Lição: tanto a redução quanto a elevação são feitas por medição.

Erros comuns

• O reflexo do “modelo mais forte”: Desperdício e atraso desnecessário em tarefas simples.
• Mudar o modelo sem medir: Tanto a redução como a ampliação são arriscadas sem avaliação.
• Fixar-se em um único modelo: o roteamento em tráfego misto costuma ser mais eficiente.
• Sempre confundindo o roteador com o LLM: regras simples podem funcionar a custo zero.
• Não definir um limite de aumento: o que acontece se as quedas de precisão devem ser definidas antecipadamente.
• Não corrigir a versão do modelo: Registre em qual modelo/versão você está trabalhando na produção; A mudança de versão pode mudar o comportamento.

Mais profundo: perpetuando avaliação e teste incremental

A seleção do modelo não é uma decisão única. Os fornecedores introduzem novos modelos, os preços mudam, a descrição do seu trabalho evolui. Portanto, configure o cluster de avaliação uma vez e não se esqueça; segure-o como um ser vivo. Quando um novo modelo é lançado, você executa as mesmas 20 a 50 amostras nele, atualiza a tabela e toma sua decisão novamente. Isso protege você da armadilha da “intuição de mudança de padrão”.

A segunda técnica avançada é o padrão fallback/cascata. Você atribui a tarefa primeiro ao modelo barato; Se a saída tiver baixa confiança ou a camada de verificação (unidade 11) a rejeitar, você escalará a mesma solicitação. Assim, a maior parte do tráfego é resolvida no modelo barato, com apenas a minoria restante indo para o modelo caro. Isto é mais barato e mais durável do que a abordagem de modelo único fixo.

O terceiro ponto é que a avaliação inclui não apenas precisão, mas também custo e latência. Se um modelo for 1% mais preciso, mas 3 vezes mais caro e 2 vezes mais lento, a compensação não vale a pena para a maioria dos trabalhos. Tome a decisão em três eixos (precisão, custo, latência) e defina um “limiar de suficiência”: “se a precisão estiver acima de 95%, escolha o mais barato”.

Por fim, registre qual modelo/versão você usou na produção. Se um dia a qualidade da saída mudar, a primeira coisa que você verificará é se a versão do modelo mudou. A rastreabilidade da versão torna mais rápido encontrar a causa raiz dos problemas de qualidade.

Mais uma advertência: o cluster eval deve representar sua carga de trabalho real. Uma avaliação que consiste apenas em exemplos fáceis esconde onde o modelo tropeça em casos difíceis e o induz a uma falsa confiança. Uma boa avaliação; Inclui exemplos fáceis comuns, bem como casos extremos que você encontra na realidade (entradas ambíguas, incompletas e contraditórias). Esta minoria difícil determina a escolha do seu modelo, porque, de qualquer maneira, todo modelo obtém sucesso na maioria fácil. Mantenha seu Eval atualizado e representativo, alimentando-o periodicamente com novos exemplos reais.

Em resumo

O modelo certo é o modelo mais leve que realiza o trabalho; Mais poderoso não é melhor em todos os trabalhos, é apenas mais caro e mais lento. Classificar a tarefa e partir do candidato mais leve, distribuir o tráfego misto com roteamento e fundamentar a seleção com um pequeno conjunto de avaliações reduz muitas vezes o custo, mantendo a qualidade.

Tarefa de aplicativo

Escolha uma carga de trabalho. (1) Classifique a tarefa como simples/complexa. (2) Projete um pequeno conjunto de avaliação de 20 exemplos reais (com suas respostas corretas). (3) Elabore um plano para preencher a tabela de comparação precisão/custo/tempo para as três classes de modelo. (4) Se você tiver tráfego misto, escreva uma regra de roteamento e defina um limite de escalonamento.

lista de verificação

• [] Posso comparar a família de modelos no eixo capacidade/velocidade/custo.
• [] Posso aplicar o princípio do “modelo mais leve e bem-sucedido”.
• [] Posso configurar o roteamento do modelo de acordo com a complexidade da tarefa.
• [] Com um pequeno conjunto de avaliações posso vincular a seleção às evidências.
• [] Posso definir um limite de atualização/rebaixamento.