Senior AI/ML Engineer — Perguntas de entrevista para engenheiro de IA/ML

Explique o KV caching e a quantização na inferência de LLM — por que eles importam?

O KV caching guarda os vetores key e value calculados para tokens anteriores, então gerar cada novo token exige calcular attention apenas para esse novo token, em vez de recalcular a sequência inteira — sem isso, a geração autorregressiva seria quadraticamente mais lenta. A quantização reduz a precisão dos pesos (de FP16 para INT8 ou INT4, por exemplo) para diminuir o uso de memória e aumentar o throughput, trocando uma perda pequena e geralmente aceitável de precisão por uma grande redução no custo de serving. Os dois juntos são o que tornam viável, economicamente, servir um modelo de 70 bilhões de parâmetros.

O que é RLHF, e qual problema ele realmente resolve?

RLHF (reinforcement learning from human feedback) pega um modelo já treinado para prever o próximo token e o ajusta ainda mais para produzir saídas que humanos realmente preferem — tipicamente treinando um modelo de recompensa com comparações humanas de saídas, e depois usando esse modelo de recompensa para fazer fine-tuning da política com um algoritmo como PPO. Ele resolve a lacuna entre "prevê texto plausível" e "é útil, honesto e segue instruções", algo que a previsão pura do próximo token não otimiza de jeito nenhum. Abordagens mais novas como DPO alcançam resultados parecidos sem um modelo de recompensa separado e sem o loop de RL, por isso cada vez mais times pulam o pipeline clássico de RLHF.

Em que data, model e pipeline parallelism diferem, e como decidir entre eles?

Data parallelism replica o modelo inteiro em vários dispositivos e divide o batch, o que é simples mas exige que o modelo completo caiba num dispositivo. Model parallelism divide o próprio modelo entre dispositivos quando ele é grande demais para um só — tensor parallelism divide camadas individuais, pipeline parallelism divide o modelo em estágios processados sequencialmente. Na prática, treinar um modelo grande usa os três ao mesmo tempo, e o verdadeiro problema de engenharia é minimizar o overhead de comunicação entre dispositivos, que é o que de fato limita o throughput.

Como você decide entre construir sobre uma API de foundation model, fazer fine-tuning de um modelo aberto, ou treinar do zero?

Treinar do zero quase nunca se justifica fora de um punhado de laboratórios bem financiados — o custo de dados e computação é enorme e a capacidade base obtida é pior do que a que já existe. A decisão real é API versus modelo aberto self-hosted: uma API é mais rápida de colocar no ar e não exige infraestrutura própria, mas o custo escala linearmente com o uso e você depende do uptime e dos limites de taxa de outra empresa; um modelo self-hosted com fine-tuning tem custo de engenharia inicial, mas dá controle sobre os dados, economia unitária previsível em escala, e nenhuma dependência de mudanças de política de um fornecedor externo. A sensibilidade e o volume dos dados costumam resolver essa discussão mais rápido do que a modelagem pura de custos.

Como você decide entre fine-tuning, retrieval-augmented generation (RAG) e apenas prompt engineering?

Comece pelo prompting — é o mais barato de iterar e costuma resolver 80% do problema quando o que falta são instruções ou exemplos melhores. Recorra ao RAG quando o modelo precisa de fatos com os quais não foi treinado ou que mudam com frequência, porque o retrieval mantém o conhecimento atualizado sem retreinar nada e permite citar fontes. O fine-tuning serve para ensinar um estilo, formato ou habilidade especializada consistente que o modelo base continua errando mesmo com bom prompt e contexto — e é o mais caro de iterar, porque cada mudança significa um novo treinamento e uma nova avaliação. A maioria dos sistemas em produção acaba combinando RAG para fatos com um modelo levemente ajustado para tom e formato, em vez de escolher só uma opção.