Entrevista AI Engineer — Iniciativa DEUS (RAG, Agentes e Produção)
AI Engineer — DEUS.aiApresentação
Preparação para Entrevista AI Engineer — Iniciativa DEUS (RAG, Agentes & Produção)
Este guia prepara-te para uma entrevista de AI Engineer de ~45 minutos focada em sistemas práticos de IA (RAG, agentes, produção, MLOps). Inclui: um template de formato com tempo, um pitch de 3 minutos e 3 pitches de projeto (exemplos), respostas rápidas para memorizar (30s RAG, 6 tipos de RAG), orientação para system design (pontos para quadro branco), exercícios de código (chunking, retry/backoff, parse JSON), templates de histórias STAR, perguntas comuns e uma checklist.
Regras rápidas para respostas (postura)
- Começa com uma resposta curta (2–3 frases).
- Pergunta: "Queres que aprofunde / mostre um diagrama?".
- Estrutura: Problema → Arquitetura/Abordagem → Trade-offs → Resultado (métricas se houver).
- Enfatiza pensamento em sistemas (dados, infra, CI/CD, monitoring), não apenas modelos.
Formato & tempo (simula uma entrevista de 45 min)
- 0–5 min: Introdução + pitch rápido (pitch de 3 min) — apresenta-te e os 3 projetos.
- 5–15 min: Experiência & background técnico (perguntas de alto nível).
- 15–25 min: Deep dive LLM / RAG / Agentes (arquiteturas, recuperação, memória, alucinações).
- 25–35 min: System design (quadro branco: sistema RAG + agentes em produção).
- 35–40 min: Específicos de produção / MLOps (CI/CD, monitoring, scaling, custo).
- 40–45 min: Perguntas do candidato + encerramento.
Nota de simulação: pratica com cronómetro — tenta terminar o pitch de 3 minutos exatamente em 3:00.
Pitch de 3 minutos (script + dicas)
- Abertura curta (10s): "Olá, sou [Nome]. Tenho 3 anos a construir sistemas end-to-end com LLM/RAG e a implementar agentes de IA em produção para B2B SaaS e ferramentas internas." (usa esta frase como referência).
- Destaca forças (20s): "As minhas forças são arquitetar pipelines RAG, construir orquestrações agentic e entregar MLOps fiáveis (Docker/K8s/CI). Equilibro custo, latência e groundedness." (usa esta frase como referência).
- Top 3 projetos (2×30s cada): ver exemplos abaixo.
- Fecho (10s): "Estou entusiasmado com a DEUS porque gosto de construir IA ética e produtizada que realmente ajuda os utilizadores. Feliz em aprofundar exemplos técnicos." (usa esta frase como referência).
Dicas: mantém simples, quantifica quando possível (melhorias de latência, redução de custos, métricas de utilizador).
3 pitches de projeto (exemplos — adapta à tua experiência)
- Connells — QA de Documentos Internos (45s)
"Na Connells liderei um produto de Document QA baseado em RAG para suporte ao cliente. Problema: os agentes demoravam a encontrar cláusulas contratuais. Solução: implementei um pipeline de ingestão que normalizou documentos, fez chunking por parágrafo semântico, gerou embeddings (ex.: OpenAI/semantic‑kernel), armazenou vetores em Pinecone e construiu uma recuperação híbrida com fallback BM25. Adicionei um reranker e uma etapa de verificação para reduzir alucinações. Resultado: tempo médio de suporte diminuiu 35% e respostas corretas subiram de 68% para 92%. Também configurei CI/CD, jobs de ingestão programados e LangFuse para observabilidade."
- Insparya — Recomendações Médicas (45s)
"Na Insparya construí um assistente de recomendações para suporte à decisão clínica. Problema: os clínicos precisavam de lembretes baseados em evidência de fontes internas e externas. Solução: ingestão multi‑fonte (extratos EMR + PubMed), gating de privacidade, chunking de 1–2 parágrafos com overlap, e um RAG parent–child onde um sintetizador LLM cria a recomendação final anexando citações. Usámos busca híbrida (densa + BM25), prompts de política rigorosos e revisão humana para respostas de alto risco. Resultado: o assistente poupou ~8 minutos por revisão de doente e passou uma auditoria clínica quanto a citações e rastreabilidade."
- Recommendation Engine — Descoberta de Produto (45s)
"Construí uma camada de recomendação personalizada para um marketplace. Problema: descoberta de produto fraca e recomendações desatualizadas. Solução: pipelines offline de features (Snowflake), geração de embeddings em tempo real, vector DB para nearest neighbors e um agente que escolhia entre modelos de ranking dependendo da intenção da query. Implementámos testes A/B, rollout com feature flags e monitorização de custos para limitar gasto com inferência. Resultado: CTR nas recomendações aumentou 20% e custos ficaram dentro do alvo através de caching e chamadas batch às APIs de embeddings."
Explicação de RAG em 30s (memorizar)
"Retrieval-Augmented Generation (RAG) é um padrão onde um LLM recebe documentos externos (contexto) recuperados em tempo de inferência para fundamentar as suas respostas. Em vez de depender só do conhecimento interno do modelo ou de fine-tuning, o RAG injeta factos relevantes de um índice (vector DB, possivelmente com BM25) e um gerador compõe a resposta, frequentemente seguido por reranking ou verificação para reduzir alucinações."
Os 6 tipos de RAG (definições curtas)
- Naive RAG: passo único de recuperação (top-K) concatenado ao prompt → LLM gera. Simples mas com risco de alucinações.
- Hybrid RAG: combina embeddings densos + recuperação esparsa (BM25); funde resultados antes da geração para melhorar recall.
- Reranked RAG: recupera muitos candidatos e depois rerankeia com um cross-encoder ou um modelo LLM de scoring antes da geração.
- Parent–Child (two-stage) RAG: um "child" retriever traz evidência por sub‑pergunta; um LLM "parent" compõe a resposta final a partir dos outputs dos children.
- Hierarchical RAG: usa hierarquia de documentos/seções e chunking multi‑escala (coarse então fine retrieval) para escalar corpos de texto grandes.
- Agentic RAG: um orquestrador/agente decide qual ferramenta ou retriever chamar (search, query a BD, calculadora), opcionalmente em múltiplos passos.
Quando usar cada um: naive para protótipos; hybrid ou reranked para produção; parent/hierarchical para Q&A complexos; agentic para fluxos de trabalho multi‑ferramenta.
Boas práticas de recuperação & chunking
- Tamanho de chunk: tipicamente 500–1000 tokens dependendo do caso; mantém fronteiras semânticas (parágrafos, secções).
- Sobreposição de chunks (ex.: 10–20%) para evitar partir contexto crítico.
- Armazenar metadata: id do documento, secção, fonte, timestamp; redigir PII conforme necessário.
- Embeddings: usa um modelo consistente entre índice e queries; vigia dimensionalidade e throughput.
- Métricas de distância: cosine/inner product mais comuns; L2 para alguns embeddings.
- Busca híbrida: combina nearest neighbors densos com BM25 para melhorar recall de correspondência exata.
- Reranking: usa um cross-encoder leve ou um scorer LLM para reordenar candidatos e aumentar precisão.
System design: RAG + Agentes (guia para quadro branco)
Ao pedirem para desenhar um sistema em produção, fala através destas camadas por ordem:
- Ingestão
- Fontes: BD, documentos, web, APIs SaaS.
- Processamento: normalização, OCR, deduplicação, redacção de PII, deteção de idioma, chunking com overlap.
- Pipelines: orquestra com Airflow/Prefect; guarda artefactos raw & processados em armazenamento de objetos (S3).
- Indexação
- Geração de embeddings: batch/stream com workers GPU ou endpoints geridos de embeddings.
- Vector DB: Pinecone/Weaviate/Milvus/Snowflake. Particionamento, TTL, compressão de vetores.
- Store de metadata: Postgres para proveniência e logs de auditoria.
- Recuperação
- Tipos de retrievers: ANN (FAISS/HNSW), BM25 (Elasticsearch), reranking híbrido.
- Cache de queries/embeddings quentes (Redis) para caminhos sensíveis à latência.
- Orquestração / Agentes
- Camada de agente: orquestrador que escolhe ferramentas (retriever, calculadora, query a BD, APIs externas). Usa frameworks (LangChain, LangGraph, AutoGen) com cuidado em produção e com guardrails.
- Memória: curto prazo (conversa) vs longo prazo (perfil do utilizador). Persiste memória com TTL e curadoria.
- Evitar loops: deteta chamadas repetidas, define contagens máximas de passos, assegura terminação determinística.
- Geração & Segurança
- Templates de prompt + snippets de grounding; usa mensagens de sistema e chamadas a ferramentas quando possível.
- Verificação: reranker, política de citações, chain-of-thought protegido ou offloaded para passo não‑streaming.
- Rate limiting e filtragem de conteúdo.
- Servir & Infra
- API: FastAPI / Flask com endpoints assíncronos, suporte a streaming de tokens.
- Deploy: imagens Docker, K8s com HPA, autoscaling para workers (embedding, retriever) e controllers.
- CI/CD: Git, testagem, build de imagens (GitHub Actions / GitLab CI), canary/blue‑green rollout.
- Observabilidade & LLMOps
- Métricas: latência, tokens por pedido, custo por pedido, top‑K recall, precisão do reranker, taxa de alucinação.
- Traces & logs: traces de pedido (input, prompt, ids de docs recuperados, outputs do modelo), erros.
- Ferramentas: LangFuse / LangSmith para rastreabilidade, Prometheus + Grafana para infra, Sentry para erros.
- Segurança & Governação
- Mitigação de prompt injection, filtragem de PII, encriptação em repouso/transporte, controlos de acesso, logs de auditoria.
- Custo & Escalabilidade
- Batch de chamadas de embeddings, usa embeddings em cache, usa modelos menores para reranking/classificação, rate limit para utilizadores pesados, prioriza trade‑offs latência/custo por caso de uso.
Trade-offs a mencionar: custo vs latência vs frescura vs groundedness. Ex.: usa LLMs locais mais pequenos para baixo custo mas risco de factualidade menor; usa LLMs maiores remotos com retrieval para melhor grounding mas maior custo/latência.
Exercícios práticos de código (pratica estes ao vivo)
Todos os snippets são pseudocódigo estilo Python; pratica a escrevê‑los em direto.
- Chunking (chunker simples e robusto)
# chunker: divide texto em chunks por parágrafo, max_tokens, com overlap
def chunk_text(paragraphs, max_tokens=800, overlap=100, tokenizer=None):
chunks = []
current = []
current_tokens = 0
for para in paragraphs:
t = tokenizer(para) if tokenizer else len(para.split())
if current_tokens + t <= max_tokens:
current.append(para)
current_tokens += t
else:
chunks.append("\n\n".join(current))
# iniciar novo chunk com overlap
if overlap and chunks:
# pegar tokens finais do último chunk
tail = get_tail_tokens(chunks[-1], overlap, tokenizer)
current = [tail, para]
current_tokens = tokenizer(tail) + t if tokenizer else len(tail.split()) + t
else:
current = [para]
current_tokens = t
if current:
chunks.append("\n\n".join(current))
return chunks
Chave: prefere splits semânticos; evita partir entidades nomeadas através de chunks.
- Retry com exponential backoff e jitter
import time, random
def retry(func, retries=5, base=0.5, factor=2.0):
for attempt in range(retries):
try:
return func()
except TransientError as e:
if attempt == retries - 1:
raise
sleep = base * (factor ** attempt) + random.uniform(0, 0.1*base)
time.sleep(sleep)
Testa simulando uma função que falha N vezes.
- Parse JSON com fallback (saídas LLM são ruidosas)
import json
SCHEMA = {"type": "object", "properties": {"answer": {"type":"string"}}}
def parse_llm_json(s):
# tenta parse direto
try:
return json.loads(s)
except Exception:
# heurística: extrai primeiro {...}
start = s.find('{')
end = s.rfind('}')
if start != -1 and end != -1:
try:
return json.loads(s[start:end+1])
except Exception:
pass
# fallback: pedir ao LLM para reformatar (ou usar um extractor estável)
# fallback seguro: return {"answer": s}
return {"answer": s.strip()}
- Mocking de um LLM para testes unitários
class MockLLM:
def __init__(self, responses):
self.responses = responses
def generate(self, prompt):
return self.responses.pop(0)
# no teste
mock = MockLLM(["{\"answer\": \"42\"}"])
assert parse_llm_json(mock.generate("..."))["answer"] == "42"
- Esqueleto de streaming de tokens (lado servidor)
- Usa FastAPI com Server-Sent Events ou Websockets.
- Stream tokens parciais assim que chegam; também regista tokens (observabilidade) e suporta cancelamento.
Observabilidade & checklist de LLMOps (o que os entrevistadores esperam)
- Trace cada pedido: prompt de input, ids de docs recuperados, ids de embeddings, escolha do modelo, tokens consumidos, latência.
- Métricas chave: tokens/request, custo/request, recall@k, precisão do reranker, taxa de alucinação.
- Alerts: pico de alucinações, custo de tokens > threshold, latência do modelo > SLA.
- Ferramentas: LangFuse/LangSmith para traces; Prometheus/Grafana para infra; Sentry para exceções.
Mitigação de alucinações (passos práticos)
- Ground com retrieval e cita fontes.
- Usa rerankers e modelos de verificação (classificador binário de factualidade).
- Prompts conservadores: pede ao modelo para dizer "Não sei" se a evidência for insuficiente.
- Pós‑cheques: alinhamento resposta‑evidência (a resposta usa o texto fornecido?).
- Humano‑em‑loop para outputs de alto risco.
- Fine‑tune de um verificador pequeno em casos de falso‑positivo.
Táticas de custo & escalabilidade
- Cache de embeddings e recuperações para queries repetidas.
- Usa tiers de modelo mais baixos para tarefas não críticas; reserva grandes modelos para síntese final.
- Batch de chamadas de embeddings, usa workers assíncronos.
- Sharda o vector DB e ajusta parâmetros HNSW para recall/latência.
- Monitoriza tokens e aplica quotas por utilizador.
Templates de histórias comportamentais (STAR) & exemplos
Estrutura: Situação → Tarefa → Ação → Resultado.
-
Resposta a incidente (exemplo curto) "Situação: um endpoint RAG começou a devolver conselhos legais alucinados em produção. Tarefa: parar o dano e identificar a causa raiz. Ação: fiz rollback de uma alteração de prompt, ativei uma rota canary para direcionar tráfego para um modelo mais seguro, despliei um filtro de conteúdo temporário e comecei o debug dos logs de recuperação com LangFuse. Encontrámos um dataset desatualizado a causar factos conflitantes e um prompt que incentivava respostas confiante. Resultado: issue resolvida em 90 minutos; implementámos um checklist de deploy mais rigoroso, testes de regressão e reduzimos incidentes de alucinação em 80% no mês seguinte."
-
Redução de custo "Situação: custos mensais de inferência estavam a disparar. Tarefa: reduzir custo em 30% mantendo qualidade. Ação: introduzi cache para queries comuns, substituí um grande modelo usado para reranking por um cross‑encoder mais pequeno, e agrupei pedidos de embeddings. Resultado: custos caíram 33% e métricas de utilizador mantiveram‑se estáveis."
-
Gestão de stakeholders "Situação: o produto queria suporte imediato para novos documentos; compliance estava preocupado com PII. Tarefa: entregar rapidamente e manter compliance satisfeita. Ação: propus um MVP RAG com redacção estrita de PII, agendei rollout faseado com auditorias e demos semanais aos stakeholders. Resultado: lançámos em 6 semanas, compliance aprovou, e iterámos com base no feedback."
Memoriza 3 histórias como estas com métricas e o teu papel exato.
Perguntas comuns para praticar (prompts curtos)
- Descreve RAG e quando o usarias vs fine-tuning.
- Como desenhas uma camada de retrieval para baixa latência? Para alto recall?
- Explica um incidente de produção que trataste (STAR).
- Desenha um sistema RAG+agent para responder queries financeiras multi‑step.
- Como geres memória para agentes multi‑turn?
- Como instrumentarias um modelo para observabilidade e monitorização de custos?
Exercícios de codificação ao vivo para ensaiar (checklist final)
- Chunking: implementa e testa com parágrafos que possam partir entidades.
- Retry: implementa backoff com jitter e unit test com função instável.
- Parse JSON: extractor robusto e unit tests com saídas LLM malformadas.
- Mock LLMs: testes para prompts e outputs determinísticos.
- Streaming: esboça endpoint FastAPI com streaming e lógica de cancelamento.
3–4 perguntas para fazer ao entrevistador (leva estas)
- Que arquiteturas de IA estão atualmente a construir? (RAG, fine‑tuning, agentic?)
- Como gerem rastreabilidade e observabilidade de modelos hoje? (LangFuse/LangSmith?)
- Quais são os maiores desafios de produção que enfrentam (custo, latência, qualidade de dados)?
- Como a equipa avalia trade‑offs entre fine‑tuning e RAG?
Checklist final antes da entrevista
- Pratica o pitch de 3 minutos e os 3 pitches de projeto.
- Memoriza 3 histórias STAR (incidente, redução de custo, gestão de stakeholders).
- Pratica 3 exercícios de código (chunking, retry, parse JSON) ao vivo com cronómetro.
- Prepara 3–4 perguntas para o entrevistador.
- Está pronto para responder curto e depois expandir.
Boa sorte — ensaia em condições temporizadas e foca‑te em trade‑offs de sistema, prontidão para produção e comunicação clara.
Zona de prática
Sem perguntas. Clica em Editar para adicionar.