Advanced

Escopo: transversal. Aplica-se a qualquer linguagem ou stack do projeto.

Seis assuntos aparecem em toda aplicação de IA que chega a produção: ajuste fino do modelo, alucinação, saídas estruturadas, raciocínio estendido, motores de inferência e AI Gateway (camada que fica entre a aplicação e os provedores de IA). Cada um deles muda uma decisão concreta de arquitetura ou de custo, então vale entender o que fazem antes de escolher.

O fine-tuning (ajuste fino) pega um modelo já treinado e continua o treinamento com um conjunto de dados menor e específico do seu domínio. O modelo que sai dali responde melhor naquele domínio e continua sabendo tudo o que sabia antes.

Modelo base (treinado em internet) → Fine-tuning com dados do domínio → Modelo especializado

Quando usar:

Comece pelo prompt e por RAG (Retrieval-Augmented Generation · Geração Aumentada por Recuperação, técnica que busca o conteúdo relevante e o injeta no prompt). Os dois cobrem a maioria dos casos, custam menos e dispensam o pipeline de treinamento que o ajuste fino exige.

Variantes:

Alucinação é quando o modelo gera uma afirmação falsa em tom seguro. A causa está no treinamento: o modelo aprendeu quais palavras costumam vir juntas, e essa estatística não distingue o fato verificado da frase que apenas soa plausível. A frequência sobe com prompt ambíguo, domínio pouco presente no treinamento e resposta longa sem fatos de apoio.

Tipos:

Mitigação:

Grounding → Fornecer os fatos no prompt em vez de deixar o modelo lembrar
RAG → Recuperar informação atualizada e injetá-la no contexto
Verificação → Pedir ao modelo que cite a fonte no próprio output
Temperature → Usar temperature baixa (0-0.3) para tarefas factuais

Em domínio crítico, a combinação que mais reduz alucinação é RAG com grounding: você entrega os documentos, manda o modelo responder só com base neles e exige a citação da origem de cada afirmação. Quando a resposta precisa apontar de onde veio, a invenção fica difícil de sustentar.

Quais foram os resultados financeiros da Acme Corp no Q3 2024?

Com base no relatório abaixo, quais foram os resultados financeiros da Acme Corp no Q3 2024?
Se a informação não estiver no relatório, responda "não encontrado".

[conteúdo do relatório]

Liste 3 artigos acadêmicos sobre RAG publicados em 2024.

Liste apenas artigos que estejam na lista abaixo.
Se não houver artigos sobre RAG, diga que não encontrou.

[lista de referências verificadas]

Qual a versão atual do framework X?

Qual a versão atual do framework X?
Se não tiver certeza, diga que não sabe e recomende verificar a documentação oficial.

O padrão dos três exemplos bons é o mesmo: dizer ao modelo o que fazer quando a informação falta. Sem essa instrução, o modelo preenche a lacuna com o texto mais provável.

Structured output obriga o modelo a responder com um JSON (JavaScript Object Notation · Notação de Objetos JavaScript) que obedece a um schema que você definiu. O código consome esse JSON direto, sem regex e sem o pós-processamento que quebra na primeira resposta fora do formato esperado.

const response = await client.messages.create({
  messages: [{ role: "user", content: `Extraia nome e email de: ${text}` }],
});

const rawText = response.content[0].text;

const response = await client.messages.create({
  tools: [extractContactTool],
  tool_choice: { type: "tool", name: "extract_contact" },
  messages: [{ role: "user", content: `Extraia nome e email de: ${text}` }],
});

const contact = response.content[0].input;

No exemplo bom, tool_choice obriga o modelo a chamar a ferramenta extract_contact, e o schema dela define os campos. O que volta em input já é um objeto com nome e email.

Suporte por provedor:

Sempre que a saída do modelo alimentar outro sistema, use structured output. Extrair dado de texto livre em produção é apostar que o modelo vai escolher o mesmo formato em toda chamada.

O modelo produz texto um token de cada vez, e cada token gerado entra no contexto do próximo. Gerar passos de raciocínio antes da conclusão dá ao modelo mais contexto para acertar, pelo mesmo motivo que uma pessoa erra menos ao escrever a conta antes de dizer o resultado.

Extended thinking é o modo que reserva um espaço para esse rascunho. O modelo gera os thinking tokens (tokens de raciocínio interno), fecha o bloco e só então escreve a resposta final. O bloco de raciocínio fica separado da resposta e pode ou não ser mostrado ao usuário.

Prompt → [Thinking: raciocínio interno] → Resposta final

Nesse espaço o modelo levanta hipóteses, checa contradições e corrige o próprio erro antes de se comprometer com uma resposta. O ganho de precisão aparece em tarefas de:

Thinking tokens custam dinheiro: eles são cobrados como tokens de saída. Em tarefa simples, o rascunho acrescenta latência e custo sem melhorar a resposta. Ligue o raciocínio estendido quando a precisão valer mais que os dois.

Um inference engine (motor de inferência) é o programa que carrega os pesos do modelo e gera os tokens. Com modelo em nuvem, o provedor cuida disso e você nem vê. Com modelo local, a escolha do engine decide a velocidade, o hardware que serve e os recursos disponíveis.

Para produção com vários usuários ao mesmo tempo, vLLM é a escolha padrão. Ele agrupa as requisições que chegam em um lote contínuo, o que mantém a GPU ocupada, e usa PagedAttention (atenção paginada) para administrar o KV cache (as matrizes de atenção dos tokens já processados, guardadas para não recalcular) em páginas de memória, do mesmo jeito que um sistema operacional pagina RAM.

Um AI Gateway fica no meio do caminho entre a sua aplicação e as APIs de LLM (Large Language Model · Modelo de Linguagem de Grande Escala). Ele concentra as tarefas que se repetem em toda chamada de IA e que não pertencem à lógica de negócio.

Aplicação → AI Gateway → [Claude | GPT | Gemini | modelo local]

Responsabilidades típicas:

Vale a pena adotar um gateway quando a aplicação fala com mais de um provedor, precisa medir custo por tenant ou opera sob regulação (dados pessoais, conformidade). Com um provedor só e um projeto simples, a camada extra vira mais um componente para manter, monitorar e atualizar, sem resolver problema que o projeto tenha.

DoDocs v3.7.0 · Desenvolvido por @thiagocajadev · Baseado no trabalho de pmndrs/docs · Poimandres.