Como responder perguntas de design de sistemas de IA: o framework de 7 passos

Por que as perguntas mudaram (e por que isso importa agora)

Durante anos, “design de sistemas” em entrevistas significava projetar YouTube, Uber ou WhatsApp. Agora, empresas que contratam engenheiros de IA, cientistas aplicados e engenheiros de GenAI fazem perguntas diferentes: “Desenhe o ChatGPT”, “desenhe um suporte ao cliente com IA”, “desenhe o GitHub Copilot”.

O motivo é simples: a demanda explodiu. A profissão de engenheiro de IA foi ranqueada como a que mais cresce nos EUA pelo segundo ano consecutivo, com vagas subindo 143% ano a ano em 2025. Dados do LinkedIn mostram 75 mil novas vagas entre 2023 e 2025, e a fatia de empregos de IA e machine learning no mercado tech saltou de 10% para 50% no mesmo período.

Nesse volume, a avaliação mudou de foco: em vez de internals de modelo, os entrevistadores querem saber como você embrulha um LLM em um produto — projetando loops agênticos, integrando recuperação de informações e raciocinando sobre custo. A maioria dos engenheiros sabe chamar uma API de LLM; poucos sabem explicar a arquitetura ao redor e defender as escolhas sob pressão. É exatamente isso que essas rodadas testam.

Prós e contras de dominar esse framework

✅ O que você ganha:

• Um único processo reutilizável que funciona para qualquer prompt de design de IA;
• Segurança para falar sobre trade-offs de custo, latência e qualidade com naturalidade;
• Capacidade de citar arquiteturas reais (Copilot, Perplexity, Uber) e ganhar credibilidade;
• Respostas que demonstram raciocínio, não decoreba;
• Diferencial claro em vagas de AI Engineer, Applied Scientist e GenAI Engineer.

⚠️ O que você NÃO ganha:

• Não substitui conhecimento sólido de fundamentos de sistemas e ML;
• Não é uma fórmula mágica — cada design exige adaptação ao contexto da vaga;
• Não cobre entrevistas de codificação ou de ciência de dados clássica.

O que os entrevistadores avaliam

Essas entrevistas testam sua capacidade de raciocinar sobre sistemas probabilísticos e limitados por custo, em vez de serviços CRUD determinísticos. A habilidade central é navegar trade-offs entre latência, custo, qualidade e segurança quando essas pressões puxam em direções opostas.

Candidatos fortes explicam por que cada camada existe e o que quebra sem ela. Nomear as camadas sem esse raciocínio é lido como superficial. Relatos de nível sênior indicam que os entrevistadores escolhem de 3 a 5 áreas para aprofundar — então você precisa saber defender cada peça do diagrama.

O framework de 7 passos

Passo 1 — Esclareça o problema

Antes de desenhar qualquer caixa, faça perguntas: quem é o usuário? Qual é o caso de uso principal? Quais são os limites de latência e custo? O que define sucesso? Pular esta etapa é o erro mais relatado em debriefs de entrevistas.

Passo 2 — Estime a carga

Estime volume de requisições, tamanho do contexto e tokens por chamada. Isso ancorará todas as decisões seguintes — do roteamento ao cache.

Passo 3 — Esboce a arquitetura

Desenhe o fluxo de ponta a ponta: entrada → recuperação → LLM → guarda-corpos → saída → observabilidade. Comece simples e adicione complexidade só onde o requisito exigir.

Passo 4 — Aprofunde em 1 ou 2 componentes

Escolha os componentes críticos (normalmente RAG e roteamento) e desça ao detalhe: indexação, chunking, embedding, re-ranking.

Passo 5 — Nomeie seus trade-offs

Explique o que você está trocando: qualidade por latência, custo por precisão. Números ajudam — roteamento costuma economizar de 40% a 70% de custo.

Passo 6 — Planeje falhas e observabilidade

Fale de alucinações, prompt injection, indisponibilidade de provedor e isolamento multi-tenant — e como você detectaria cada um. Registre versões de modelo, metadados de recuperação, rastros de ferramenta e custo por requisição.

Passo 7 — Diga como o sistema evolui

Mostre que você pensa além do MVP: como escalaria, o que trocaria de modelo, o que observaria para decidir o próximo passo.

As cinco primitivas que você precisa dominar

RAG (Geração Aumentada por Recuperação)

O padrão para sistemas que respondem a partir de conhecimento externo: indexar documentos, recuperar trechos relevantes, ancorar a resposta no contexto recuperado e citar fontes.

Roteamento de modelos

Nem toda pergunta precisa do modelo mais caro. Roteie consultas simples para modelos menores e reserve os grandes para tarefas complexas. Roteamento, cache semântico, compressão de prompt e streaming juntos cortam de 40% a 60% do custo mantendo a qualidade.

Guarda-corpos (guardrails)

Operam em duas camadas. Pré-LLM: validação de entrada, redação de PII e defesa contra prompt injection. Pós-LLM: validação de schema, políticas de recusa e checagem de fatos contra o contexto. Guarda-corpos em camadas podem reduzir alucinações em 71% a 89% — apresente esses números como faixas, já que variam por fonte.

Avaliação e observabilidade

Combine avaliações offline (LLM-como-juiz calibrado contra ground truth) com métricas online como fidelidade, recall de contexto e relevância da resposta. Os mesmos logs servem para debug, segurança e compliance.

Loops agênticos

Para designs com agentes (code reviewer, assistente de pesquisa, suporte), o padrão é: intake da requisição → montagem de contexto → raciocínio do LLM → validação da ação → execução em sandbox → processamento do resultado → atualização de estado → repetir ou parar. Separe as responsabilidades: o LLM raciocina, o orquestrador controla o fluxo, o motor de políticas governa e o sandbox executa.

Tabela comparativa: primitivas e quando usar

Arquiteturas reais que valem a pena citar

Citar um sistema real mostra que você leu além dos tutoriais. O GitHub Copilot é bem documentado: a extensão extrai o código antes e depois do cursor junto com sinais de contexto (arquivos abertos, imports, metadados de linguagem) para montar o prompt. O Fill-in-the-Middle (FIM) dá um ganho relativo de ~10% em aceitação sobre prompt prefix-only, e o GitHub roda ainda um modelo separado para pontuar completions por qualidade e segurança.

Outros sistemas valem uma frase cada: o Uber GenAI Gateway (com redator de PII em 60+ casos de uso), a IA conversacional do Airbnb (raciocínio em cadeia de pensamento com guarda-corpos), o Perplexity (200 milhões de consultas diárias no Vespa.ai), o RAG stateless do Slack e o sistema multiagente da Anthropic (orquestrador Opus com subagentes Sonnet).

Erros comuns (e como evitá-los)

❌ Desenhar antes de esclarecer. O erro mais frequente: ouvir “desenhe o ChatGPT” e começar a rabiscar caixas em segundos, pulando requisitos e critérios de sucesso. Gaste os primeiros minutos fazendo perguntas.

❌ Listar componentes sem dizer o porquê. Um diagrama com banco vetorial, re-ranker e camada de guarda-corpos significa pouco se você não explicar o que quebra ao remover cada peça.

❌ Ignorar custo e latência. São restrições de primeira classe em sistemas de IA. Um design que ignora a conta de tokens ou o tempo de resposta de 3 a 5 segundos está incompleto.

❌ Esquecer modos de falha. Respostas fortes cobrem alucinações, prompt injection, queda de provedor e isolamento multi-tenant, além de como detectar cada um.

Casos de uso além da entrevista

• Preparação para entrevista técnica: pratique o framework em prompts reais de vagas de AI Engineer;
• Design de produto interno: use os 7 passos para estruturar a arquitetura de um chatbot corporativo;
• Estimativa de custo: o passo 2 (estimar carga) vira base para prever gastos com tokens;
• Revisão de arquitetura: use as cinco primitivas como checklist para auditar sistemas existentes;
• Mentoria de times: o framework serve como roteiro para onboard de engenheiros juniores em IA.

Troubleshooting: 5 erros comuns ao responder

❌ Sintoma: você trava na hora de estimar carga. Causa: falta de prática em ordem de magnitude. Solução: decore referências — um usuário ativo gera poucas requisições/dia; contexto médio fica entre 2k e 8k tokens.

❌ Sintoma: o entrevistador aprofunda e você não sabe responder. Causa: você desenhou camadas que não entende de fato. Solução: só coloque no diagrama o que consegue defender; aprofunde RAG e roteamento.

❌ Sintoma: esqueceu de falar de custo. Causa: hábito de pensar em sistemas determinísticos. Solução: faça um checklist mental: latência, custo, qualidade, segurança.

❌ Sintoma: não citou nenhuma arquitetura real. Causa: leitura limitada. Solução: estude Copilot, Perplexity e Uber GenAI Gateway antes da entrevista.

❌ Sintoma: citou números de redução de alucinação sem nuance. Causa: memória de fontes mistas. Solução: apresente faixas (“71% a 89%”) e diga que variam por configuração.

FAQ

Preciso saber internals de transformers para essas entrevistas? Menos do que antes. O foco está em como você monta produtos ao redor de LLMs, não em detalhes de arquitetura do modelo.

Quanto tempo devo gastar esclarecendo o problema? Os primeiros 3 a 5 minutos. É o investimento que molda todo o resto do design.

Posso usar o mesmo framework para qualquer prompt? Sim. “Desenhe o ChatGPT”, “desenhe um code reviewer” e “desenhe o Copilot” passam a soar como o mesmo problema com entradas diferentes.

RAG é obrigatório em toda resposta? Não. Só introduza RAG se o sistema precisa de conhecimento externo; senão, você estará adicionando complexidade sem justificativa.

O que impressiona mais: citar números ou arquiteturas reais? Ambos, juntos. Números dão credibilidade quantitativa; arquiteturas reais mostram que você leu além do tutorial.

A tendência

A entrevista de design de sistemas de IA veio para ficar enquanto empresas seguirem contratando para “embrulhar” LLMs em produtos. Em 2027, espere que o foco se desloque ainda mais para avaliação e observabilidade — à medida que mais sistemas entram em produção, a capacidade de medir e corrigir comportamento vira o novo diferencial de sênior. Dominar um framework repetível hoje é investir na habilidade que vai sustentar entrevistas (e designs reais) nos próximos anos.