Fundamentos antes de ferramentas: como avaliar e construir com IA generativa

Uma equipe adota um assistente de chat, obtém bons resultados por um mês e então o fornecedor troca o modelo, o preço ou o limite de requisições. Ninguém na sala consegue dizer se a alternativa é melhor, pior ou apenas diferente, porque a equipe aprendeu um produto, não um mecanismo. Essa lacuna é o assunto deste artigo: o que é preciso entender de IA generativa para avaliar seus limites, escolher tecnologias com critério, evitar depender de uma única ferramenta e, em algum momento, construir aplicações com um modelo dentro delas, em vez de apenas digitar na aplicação de outra pessoa.^[9]

1. Fundamentos duram mais que ferramentas

A IA generativa costuma ser conhecida por uma interface: uma caixa de texto, um complemento no editor, um botão que redige um e-mail. A interface é conveniente e também enganosa, porque esconde a única coisa que se transfere entre produtos: o mecanismo. Quem sabe como um modelo produz texto consegue prever onde ele vai falhar, decidir o que conferir e ler um lançamento novo pelo que de fato mudou. Quem só sabe quais botões apertar recomeça toda vez que os botões mudam de lugar.

• Avaliar limitações. Saber que um modelo amostra de uma distribuição aprendida explica por que ele pode ser fluente e errado ao mesmo tempo, e por que uma frase mais confiante não é mais evidência.
• Escolher com critério. Entender a estrutura de custo da inferência transforma "qual modelo é o melhor?" em "qual modelo é adequado para esta carga, este orçamento e esta régua de qualidade?".
• Evitar dependência. Quando você sabe o que o modelo faz e o que a sua aplicação faz, migrar para outro fornecedor ou para um modelo hospedado por você é uma tarefa de engenharia, não uma reescrita.

Num ecossistema em que os nomes mudam a cada trimestre, o conhecimento conceitual é o ativo com a maior validade. O restante deste artigo constrói esse conhecimento na ordem em que um engenheiro precisa dele: primeiro as camadas, depois o mecanismo, depois os critérios, depois o sistema.^[9,10]

2. Onde os LLMs se encaixam: IA generativa, machine learning e deep learning

Os termos costumam ser usados como sinônimos, e essa é a primeira fonte de decisões superficiais. Eles são aninhados. Machine learning é o campo dos programas que melhoram a partir de dados em vez de serem escritos regra por regra. Deep learning é o subconjunto que usa redes neurais com muitas camadas para aprender representações diretamente dos dados brutos.^[1] Modelos generativos são modelos, em geral profundos, treinados para produzir amostras novas que seguem os padrões dos dados de treinamento. Grandes modelos de linguagem (LLMs) são uma família de modelos generativos, construída sobre a arquitetura Transformer e treinada com texto em escala enorme.^[2,3] Um assistente de chat não é nenhuma dessas coisas: é uma aplicação construída em cima de um LLM.

A hierarquia importa porque cada nível responde a uma pergunta diferente. Quando alguém usa um chatbot, está interagindo com uma aplicação: prompts, memória, ferramentas e interface são decisões de aplicação. Quando escolhe um LLM, está escolhendo uma família de modelo: tamanho, licença, janela de contexto e custo são decisões de modelo. Quando discute dados de treinamento, funções de perda ou como o significado é representado em vetores, está no nível de machine learning e deep learning. Separar as camadas torna a análise técnica mais precisa e impede que um recurso de produto seja confundido com uma propriedade do campo.

Tabela 1 — Os quatro níveis, a pergunta que cada um responde e as decisões que pertencem a ele. Uma pontuação de benchmark é um fato no nível do modelo; uma boa resposta no seu produto é um resultado no nível da aplicação.^[6]

Pratique: abrir no Lab: Exercício 1, Onde ficam os LLMs

3. O mecanismo por trás dos modelos generativos

Um modelo generativo é um sistema treinado para aprender os padrões de uma distribuição de dados e produzir saídas novas coerentes com esses padrões. Para texto, a receita é concreta: o modelo é treinado para prever o próximo token dados os anteriores, sobre um corpus enorme; na inferência, um prompt define o contexto e o modelo amostra um token por vez, realimentando cada escolha como contexto para a próxima.^[3] O artigo sobre o que é IA generativa, mais adiante nesta série, apresenta essa fatoração em detalhe; aqui o interesse está no que ela implica para o engenheiro.

Três consequências saem diretamente da equação (1). Primeira: o modelo não tem noção de verdade, apenas de verossimilhança sob os dados que viu; uma continuação plausível é preferida a uma exata quando as duas diferem. Segunda: tudo o que o modelo "sabe" fica congelado nos parâmetros no momento do treinamento; o que aconteceu depois precisa ser fornecido pelo prompt. Terceira: a saída depende de um sorteio, então o mesmo prompt pode produzir respostas diferentes, e os parâmetros de amostragem fazem parte da superfície de engenharia, não são um detalhe.

É por isso que entender o mecanismo muda o modo de usar a ferramenta. Um modelo que responde bem num contexto e falha em outro não está sendo caprichoso: o primeiro contexto se parecia com os dados de treinamento e o segundo não, ou o prompt deixou de fora o que os pesos não poderiam conter. A resposta passa a ser uma decisão de projeto — recuperar o contexto que falta, restringir o formato da saída, baixar a temperatura, adicionar uma etapa de validação — em vez de um pedido mais bem redigido. A pergunta nunca é só "o que ele respondeu?", mas "de onde vem essa capacidade, e que limites vêm junto com ela?".^[7]

Pratique: abrir no Lab: Exercício 2, O que o modelo prevê

4. Comparação de arquiteturas por critérios de engenharia

Escolher um modelo por popularidade, ou pela impressão deixada por uma demonstração, é o equivalente, no nível da aplicação, a escolher um banco de dados porque está na moda. Uma comparação madura olha para critérios de engenharia: quanto o modelo custa para rodar na carga esperada, quanto tempo uma requisição leva, quão bem ele pode ser especializado, que qualidade alcança na sua tarefa e quão bem se encaixa nas restrições do caso — privacidade, licença, implantação, idioma.^[6] Um modelo que lidera um benchmark público pode ser a escolha errada para produção se for caro ou lento demais para o tráfego, e um modelo modesto pode ser o certo se a tarefa é estreita e o volume é alto.

Tabela 2 — Critérios de engenharia para comparar modelos generativos. "O que medir" é deliberadamente sobre a sua carga de trabalho: um ranking público mede uma distribuição de requisições diferente da que o seu produto vai ver.^[6,11]

5. Trade-offs: qualidade, custo, velocidade e especialização

Não existe modelo ideal em todos os cenários; existem trade-offs. Aumentar a qualidade normalmente significa um modelo maior, o que eleva o custo por requisição e o tempo de resposta. Buscar velocidade significa um modelo menor ou saídas mais curtas, o que pode reduzir a precisão. Especializar uma solução para um domínio pode entregar mais valor do que o modelo mais geral disponível, ao preço de manter a versão especializada atualizada. Os resultados de escala tornam o formato dessas curvas explícito: a capacidade cresce suavemente com parâmetros, dados e computação, e a conta também.^[4,5]

Duas fórmulas tornam concreto o lado do custo e da velocidade. O custo de uma requisição é o número de tokens de entrada vezes o preço de entrada mais o número de tokens de saída vezes o preço de saída; tokens de saída costumam ser várias vezes mais caros que os de entrada, então respostas prolixas custam mais do que prompts longos. A latência de uma requisição é o tempo até o primeiro token mais o número de tokens de saída dividido pela taxa de geração; esse segundo termo é o motivo de uma resposta de 500 tokens parecer lenta mesmo vinda de um modelo rápido.^[11]

O trabalho de engenharia consiste em equilibrar essas variáveis conforme o objetivo de negócio, o orçamento e a experiência que o usuário espera. Um hábito útil é escrever as restrições antes de olhar para qualquer modelo: uma latência máxima, um custo máximo por requisição, uma qualidade mínima na amostra de avaliação. Candidatos que violam uma restrição estão fora, seja qual for a reputação; os restantes são ordenados por uma pontuação ponderada. O script abaixo faz exatamente isso, com os pesos como uma entrada explícita e revisável.

from dataclasses import dataclass

@dataclass
class Candidato:
    nome: str
    qualidade: float      # 0–1, acurácia na SUA amostra de avaliação
    custo: float          # moeda por requisição, da equação (2)
    latencia_p95: float   # segundos, da equação (3) medida sob carga
    dependencia: float    # 0–1, quão difícil é substituir (licença, formatos, hospedagem)

def ordenar(candidatos, custo_max, latencia_max, qualidade_min, w):
    """Descarta todo candidato que viola uma restrição rígida e ordena os restantes
    por uma pontuação ponderada. w = pesos de qualidade, custo, latência e dependência."""
    viaveis = [c for c in candidatos
               if c.custo <= custo_max and c.latencia_p95 <= latencia_max and c.qualidade >= qualidade_min]
    if not viaveis:
        raise ValueError("nenhum candidato satisfaz as restrições: relaxe-as ou mude o projeto")
    # normaliza custo e latência pelo pior valor viável, de modo que menor é melhor
    pior_custo = max(c.custo for c in viaveis)
    pior_lat   = max(c.latencia_p95 for c in viaveis)
    def pontuacao(c):
        return (w["qualidade"] * c.qualidade
                + w["custo"]     * (1 - c.custo / pior_custo)
                + w["latencia"]  * (1 - c.latencia_p95 / pior_lat)
                + w["dependencia"] * (1 - c.dependencia))
    return sorted(viaveis, key=pontuacao, reverse=True)

# exemplo: um assistente de suporte interno, 50 mil requisições/dia, interativo
pesos = {"qualidade": 0.45, "custo": 0.25, "latencia": 0.20, "dependencia": 0.10}
ordenados = ordenar([
    Candidato("grande hospedado",   qualidade=0.93, custo=0.012, latencia_p95=4.8, dependencia=0.8),
    Candidato("médio aberto",       qualidade=0.84, custo=0.004, latencia_p95=2.9, dependencia=0.3),
    Candidato("pequeno ajustado",   qualidade=0.88, custo=0.001, latencia_p95=1.1, dependencia=0.2),
], custo_max=0.010, latencia_max=3.0, qualidade_min=0.80, w=pesos)
print([c.nome for c in ordenados])   # o grande hospedado fica de fora: lento e caro demais para este caso

O ponto do script não é a aritmética, e sim a disciplina: restrições primeiro, pesos explícitos, qualidade medida na sua própria amostra. Com esses três no lugar, "escolhemos o modelo X" vira uma afirmação que alguém pode auditar e revisitar quando os números mudarem.^[8]

Pratique: abrir no Lab: Exercício 3, Critérios de trade-off

6. Construção de soluções reais com IA

Construir uma solução real significa sair do uso passivo de uma ferramenta e projetar uma aplicação que resolve um problema concreto do dia a dia de alguém. O modelo é um componente dessa aplicação, e raramente o maior. Em volta dele ficam o código que monta o prompt a partir do pedido do usuário e do contexto relevante, a recuperação que traz documentos que os pesos não poderiam conter, as ferramentas que o modelo pode chamar, a validação que confere a saída antes que ela chegue a alguém e a observabilidade que diz quanto custa e com que frequência falha.^[7,10]

É aqui que os fundamentos se pagam. Selecionar o modelo é uma decisão entre várias: avaliar a arquitetura, entender o impacto no fluxo de trabalho, decidir o que o modelo pode fazer sozinho e o que uma pessoa precisa confirmar, e alinhar a solução ao tipo de tarefa que a equipe ou o produto de fato executa. Um profissional que domina esses fundamentos deixa de consumir IA e passa a projetar sistemas com IA como componente. Esse passo é o que separa experimentação de engenharia aplicada, e é também o que mantém o sistema vivo quando um modelo é trocado: os prompts, a recuperação, as verificações e as métricas permanecem.^[10]

Pratique: abrir no Lab: Exercício 4, Restrições duras

7. Um ecossistema em movimento rápido: adaptar sem recomeçar

O ecossistema de IA generativa se move rápido: novos modelos, ferramentas e técnicas surgem continuamente, e um ranking de seis meses atrás é história. Acompanhar o campo, portanto, não é opcional; faz parte da competência técnica necessária para permanecer relevante. Mas acompanhar não significa decorar nomes de produtos. Significa manter critérios estáveis para julgar novidade, maturidade e utilidade, de modo que cada lançamento possa ser lido rapidamente: o que mudou no nível do modelo, quanto custa, o que mudaria na sua aplicação e se a sua amostra de avaliação confirma a promessa.^[9,12]

Quem entende os fundamentos absorve essas mudanças sem recomeçar do zero a cada nova tecnologia. O Transformer de 2017 continua sendo a arquitetura sob os modelos de hoje; o comportamento de escala descrito em 2020 continua explicando por que modelos maiores custam mais; o pipeline da Figura 2 não mudou. O que muda é a posição de cada produto no gráfico de trade-offs, e é exatamente para isso que servem critérios estáveis.^[2,4]

Pratique: abrir no Lab: Exercício 5, Ecossistema acelerado

8. Da condição de usuário à linha de frente da criação

Dominar IA generativa significa assumir uma posição ativa na criação de aplicações, e não apenas usar interfaces prontas. Esse domínio combina o entendimento técnico do mecanismo, a leitura de um contexto — a tarefa, os usuários, as restrições — e o ofício de transformar um modelo numa solução útil. Em times de software, isso se traduz em decisões mais conscientes sobre adoção, integração e retorno prático: quais tarefas ganham, quanto o ganho custa e o que precisa ser revisado. O resultado esperado não é só produtividade individual; é a capacidade de construir produtos e fluxos de trabalho melhores, com o modelo como uma parte bem compreendida deles. O próximo artigo segue o que essa mudança significa para a própria profissão: para onde migra o diferencial do desenvolvedor quando o código deixa de sê-lo, como a IA amplia competência e o que muda para a liderança técnica e para os produtos.