Entrevista de AI Engineer em 2026: RAG, Avaliação e System Design

Olá HaWkers, estudar nomes de modelos já não basta para explicar como uma aplicação de IA funciona. O repositório aberto AI Engineering Interview Questions Company Wise, criado em setembro de 2026, organiza perguntas sobre recuperação de informação, inferência, agentes, avaliação e segurança. Na consulta ao GitHub feita para este artigo, ele registrava 1.562 estrelas. O sinal é de interesse pelo assunto, não uma prova de que cada pergunta apareceu em uma seleção real.

Se uma pessoa entrevistadora pedir que você desenhe um assistente que responde com documentos internos, por onde começaria? Aqui você vai montar uma resposta verificável: definir o problema, criar um pequeno conjunto de casos, medir a recuperação, observar falhas e defender decisões de arquitetura. O roteiro serve para praticar em português e para adaptar a uma entrevista em inglês, espanhol ou francês.

Comece pelo trabalho que o sistema precisa fazer

Antes de escolher um modelo, descreva o usuário, a informação disponível e o resultado aceitável. Imagine uma equipe de suporte que consulta políticas internas. A pergunta “posso cancelar depois da renovação?” parece simples, mas a resposta depende da versão da política, do país, do tipo de contrato e da permissão de quem pergunta. Se você ignorar esses detalhes, um resultado fluente pode estar errado.

Em uma entrevista, diga quais documentos entram no índice, com que frequência mudam e quem pode acessá-los. Depois defina a saída: resposta curta, indicação do trecho de origem e recusa quando não houver evidência suficiente. Isso mostra entendimento de produto e de risco. A documentação de avaliações da OpenAI enfatiza que testar uma aplicação exige casos representativos e critérios claros. O AI Risk Management Framework do NIST também ajuda a pensar em contexto, medição e acompanhamento, sem transformar uma lista de princípios em garantia automática de segurança.

Uma boa pergunta de volta é: “qual erro custa mais caro aqui: deixar de responder ou responder com uma política desatualizada?”. A resposta muda o limiar de confiança, a necessidade de revisão humana e até a experiência de uso. Faça essa pergunta antes de prometer precisão. Ela vale mais do que recitar uma arquitetura genérica.

Transforme perguntas soltas em casos de teste

Muitas pessoas praticam entrevista lendo uma lista enorme de perguntas e tentando decorar respostas. Para funções de AI Engineer, vale converter algumas delas em experimentos pequenos. Se o assunto for RAG, crie um conjunto com pergunta, documento esperado e resposta aceitável. Inclua um caso sem resposta: um sistema confiável precisa saber dizer que não encontrou informação.

O exemplo abaixo usa apenas a biblioteca padrão de Python. Salve como casos.py e execute com python casos.py. Os dados são fictícios, feitos para treino; não representam regras de uma empresa. A validação inicial impede que um caso fique sem pergunta ou referência, erro comum em planilhas de avaliação montadas às pressas.

# Casos fictícios para praticar uma entrevista técnica.
casos = [
    {"pergunta": "Qual é o prazo de cancelamento?", "fonte": "politica_2026", "resposta": "Consulte o contrato vigente."},
    {"pergunta": "Como redefinir a senha?", "fonte": "acesso", "resposta": "Use a página de recuperação."},
    {"pergunta": "Qual é o preço do plano futuro?", "fonte": None, "resposta": None},
]

for numero, caso in enumerate(casos, start=1):
    assert caso["pergunta"], f"Caso {numero} sem pergunta"
    assert (caso["fonte"] is None) == (caso["resposta"] is None), f"Caso {numero} incoerente"
    print(numero, "respondível" if caso["fonte"] else "sem evidência")

Esse conjunto ainda é pequeno demais para estimar desempenho real. Na entrevista, explique como ampliá-lo: perguntas frequentes, formulações ambíguas, documentos contraditórios, atualizações de política e tentativas de acessar dados de outra pessoa. Separe exemplos de desenvolvimento e de avaliação final para não ajustar o sistema olhando a resposta do teste. Se o domínio for regulado, peça revisão de especialistas do assunto.

O repositório que motivou esta pauta é útil como catálogo de temas, mas trate suas descrições de processos seletivos como relatos dos autores. Verifique sempre a vaga e o contato da empresa. Perguntas públicas mudam; a capacidade de montar um teste reproduzível continua útil mesmo quando o roteiro de uma entrevista muda.

Explique RAG como uma sequência de decisões

RAG combina recuperação de trechos com geração de resposta. O desenho mínimo tem ingestão, divisão de documentos, indexação, busca, seleção de trechos e geração com indicação de fonte. Mas cada etapa pode perder informação. Dividir um contrato no meio de uma exceção pode retirar a condição que torna uma cláusula válida. Uma busca que encontra o documento certo, mas usa a versão antiga, também falha.

Mostre que você separa a qualidade da busca da qualidade da resposta. Se o trecho correto nunca chega ao modelo, mudar o prompt não resolve o problema principal. Uma métrica simples de treino é recall@k: em quantos casos o documento esperado aparece entre os primeiros k resultados? Este código recebe resultados simulados e conta acertos sem depender de um serviço externo.

# Meça se a fonte esperada apareceu nos três primeiros resultados.
avaliacoes = [
    {"esperado": "politica_2026", "recuperados": ["faq", "politica_2026", "arquivo"]},
    {"esperado": "acesso", "recuperados": ["acesso", "suporte"]},
    {"esperado": "faturamento", "recuperados": ["vendas", "faq"]},
]

k = 3
acertos = sum(item["esperado"] in item["recuperados"][:k] for item in avaliacoes)
recall = acertos / len(avaliacoes)
print(f"recall@{k}: {recall:.1%} ({acertos}/{len(avaliacoes)})")

O resultado mede somente esta amostra fictícia. Ele não demonstra que a resposta gerada é correta, nem que a fonte citada sustenta a frase final. Diga isso explicitamente. Depois proponha filtros por versão, idioma e permissão; compare busca lexical, vetorial e híbrida com os mesmos casos; examine manualmente os erros antes de trocar de ferramenta. Uma resposta madura para a entrevista inclui também a condição de desligar ou rever o sistema.

Avalie a resposta, a recusa e a origem

Uma resposta pode citar um documento certo e ainda inventar uma conclusão. Por isso a avaliação precisa olhar pelo menos três coisas: se responde à pergunta, se o conteúdo é sustentado pelo trecho e se recusa quando não há base. Não reduza tudo a uma nota única sem saber que tipo de erro ela esconde. Para política interna, uma falsa afirmação pode ser mais grave do que uma recusa cautelosa.

O exercício a seguir mostra um verificador determinístico bem limitado. Ele aceita apenas respostas cujas frases constem literalmente nos trechos permitidos. Em produção, paráfrases legítimas exigem avaliação mais sofisticada e revisão humana; aqui a regra rígida serve para deixar o contrato visível e discutível na entrevista.

# Verificação didática: a resposta deve estar no trecho autorizado.
def verificar_resposta(resposta, trechos):
    if not resposta.strip():
        return "recusa"
    texto_permitido = " ".join(trechos).casefold()
    return "sustentada" if resposta.casefold() in texto_permitido else "revisar"

trechos = ["Use a página de recuperação para redefinir a senha."]
print(verificar_resposta("Use a página de recuperação", trechos))
print(verificar_resposta("A senha é enviada por SMS", trechos))
print(verificar_resposta("", []))

Não apresente o código como detector universal de alucinação. Ele falha com paráfrases, negações e textos longos. Uma solução séria combina critérios automáticos, amostras revisadas por pessoas, investigação de incidentes e monitoramento depois da publicação. Na conversa, explique o que você mediria por segmento: idioma, tipo de documento, versão e classe de pergunta. A média geral pode esconder uma falha grave em um grupo pequeno.

Também registre a origem de cada afirmação que o sistema apresenta. Se o documento for atualizado, você precisa reproduzir qual versão sustentou a resposta antiga. Sem esse rastro, uma reclamação vira discussão de memória. Esse requisito liga avaliação a arquitetura: identificador do documento, versão, horário da indexação e trechos usados precisam viajar com a resposta.

Defenda o system design com limites explícitos

No quadro ou documento da entrevista, desenhe dois caminhos. O primeiro atualiza os documentos: recebe uma versão, valida metadados, aplica controle de acesso e publica um índice novo. O segundo atende à pergunta: autentica a pessoa, recupera apenas o que ela pode ver, produz uma resposta com referências e registra a operação. Explique como você evita que uma atualização parcial misture trechos velhos e novos.

Depois fale de orçamento: limite de tempo, custo por solicitação, tamanho de contexto e capacidade de atender picos. Não invente uma meta de latência se o problema não trouxe esse dado. Peça o objetivo de serviço e diga como o mediria. Uma fila, cache ou modelo menor pode ajudar, mas cada escolha tem custo: cache exige invalidação quando a política muda; um modelo menor precisa ser avaliado nos casos difíceis; uma fila pode ser inadequada para atendimento interativo.

Um rastreio mínimo ajuda a comparar alternativas. O código abaixo mede uma função local e grava identificadores fictícios, sem registrar texto sensível. Em um sistema real, os identificadores devem respeitar a política de privacidade e a retenção definida pela organização.

# Cronometre a operação e registre somente metadados necessários.
from time import perf_counter

def responder(pergunta):
    return "Consulte a política vigente" if pergunta else "Pergunta vazia"

inicio = perf_counter()
resposta = responder("Posso cancelar?")
duracao_ms = (perf_counter() - inicio) * 1000
evento = {"documento": "politica_2026", "modelo": "exemplo_local", "duracao_ms": round(duracao_ms, 2)}
print(resposta, evento)

Esse exemplo não mede uma chamada de rede nem prevê desempenho em produção. Ele demonstra a disciplina: medir a operação real, registrar a versão usada e comparar resultados sob condições equivalentes. Na entrevista, explicite o que acontece quando a busca falha, o modelo demora ou a citação aponta para um documento removido. Um caminho de erro claro costuma revelar mais maturidade do que um diagrama cheio de caixas.

Segurança é parte da resposta técnica

Documentos recuperados são dados, não instruções confiáveis. Um trecho pode conter uma frase maliciosa dizendo para ignorar regras ou enviar informações para outro endereço. O projeto OWASP Top 10 para aplicações com LLM reúne riscos como injeção de prompt e exposição de informação sensível. Use essa referência para estruturar perguntas de segurança, sem supor que um filtro de texto elimine todos os riscos.

Descreva fronteiras concretas: autorização antes da recuperação, ferramentas com permissões mínimas, confirmação para ações sensíveis, isolamento entre dados de clientes e teste de entradas adversariais. Se a aplicação apenas responde, não dê a ela acesso de escrita. Se puder agir, registre quem autorizou, qual ação foi solicitada e qual resultado voltou. Uma resposta responsável distingue claramente ler, sugerir e executar.

Vale conectar isso à carreira. Quem está começando pode mostrar maturidade sem construir um produto completo. Um projeto pequeno com casos de teste, falhas documentadas e decisões justificadas ensina mais do que uma demonstração perfeita em um único prompt. O artigo sobre como se destacar nas vagas júnior de 2026 aprofunda como apresentar evidências do próprio trabalho. Aqui a evidência é simples: mostrar o que você testou, onde falhou e o que faria em seguida.

Um roteiro prático para a próxima entrevista

Reserve uma sessão para entender a vaga e listar as tarefas que ela realmente pede. “AI Engineer” pode significar produto com LLM, infraestrutura de inferência, avaliação ou integração de dados. Separe os assuntos que aparecem na descrição da vaga em três grupos: consigo explicar e demonstrar; consigo explicar, mas preciso praticar; ainda não consigo defender. Essa classificação impede que você gaste o estudo inteiro em novidades irrelevantes para aquela seleção.

Na sessão seguinte, escolha um problema pequeno e monte os casos. Escreva primeiro a resposta manual esperada e a fonte, depois implemente uma busca simples e meça onde ela erra. Em outra sessão, apresente sua arquitetura em voz alta: entrada, permissões, atualização, busca, geração, avaliação e recuperação de falhas. Peça a alguém que interrompa com “e se o documento estiver desatualizado?” ou “como sabe que a resposta está certa?”. Treinar objeções prepara melhor do que decorar siglas.

Feche com uma folha de decisões: premissas conhecidas, perguntas em aberto, alternativas rejeitadas e métricas que faltam. Se a pessoa entrevistadora mudar o cenário, você consegue adaptar o desenho em vez de defender uma receita fixa. Seja honesto sobre os limites dos exemplos. O código deste artigo é didático; uma aplicação real exige autorização, dados representativos, monitoramento e testes proporcionais ao risco.

Perspectivas: menos decoreba, mais evidência

Listas públicas de perguntas ajudam a mapear o território, mas não substituem uma explicação que resista a um caso novo. O melhor sinal em uma entrevista técnica é conseguir dizer o que o sistema deve fazer, como você verificaria o resultado e em que condições ele não deve responder. RAG, avaliação e system design entram juntos nessa conversa porque um erro em uma etapa atravessa as demais.

Leve um projeto pequeno que você possa abrir, executar e criticar. Se a vaga pedir outra tecnologia, conserve o método: delimite o problema, mostre um teste, apresente trade-offs e deixe visível a incerteza. Isso demonstra prática de engenharia, inclusive quando a resposta correta é pedir mais contexto antes de escolher uma ferramenta.

Bora pra cima! 🦅

📚 Quer Acompanhar o Que Vem Por Aí?

Este artigo cobriu entrevistas de AI Engineer, mas o ecossistema muda toda semana e nem tudo vira artigo aqui.

No X eu compartilho o que estou testando, os bastidores dos projetos e as novidades que aparecem antes de virarem post.

Me Segue Lá

👉 Seguir @jeffbruchado no X

💡 Conteúdo diário sobre desenvolvimento, carreira e as ferramentas que eu realmente uso