← Voltar a AI Engineer — DEUS.ai

Safety & Observability para RAG e Sistemas Multi‑Agent — Guia de Entrevista (README)

AI Engineer — DEUS.ai

Apresentação

Safety & Observability para RAG e Sistemas Multi‑Agent — Guia de Entrevista

Nota rápida (TL;DR): Este ficheiro é um guião prático para um bloco de entrevista de 20 minutos focado em segurança, observability e operações para RAG/agents. Inclui checklists, script, cenários de incidente e exemplos técnicos. Use as "DICAS" embutidas para orientar a avaliação em tempo real.

Sumário

  • Objetivo
  • Quando usar este bloco
  • Formato recomendado (20 min)
  • Pré‑entrevista: preparação do entrevistador
  • O que avaliar (competências chave)
  • Checklist rápido do entrevistador
  • Instrumentação & trace model (detalhado)
  • Metadados recomendados
  • Métricas & alerting (com thresholds exemplo)
  • Observability tooling (prático)
  • Segurança: mitigação de prompt injection e exfiltration
  • Caching e patterns operacionais
  • Prevenção de loops de agentes
  • Model traceability & governance
  • Mini‑cenário de incidente + resposta esperada por janelas temporais
  • Exemplos de snippets (Python — ilustrativo)
  • Dicas rápidas para o candidato
  • Scoring (20 pts) e perguntas de follow‑up

Objetivo

  • Avaliar conhecimento prático em instrumentação, métricas, alerting, mitigação de risco (prompt injection, exfiltration), governança de modelos e práticas operacionais para colocar RAG/agents em produção.

DICA: Peça exemplos concretos e nomes de métricas/thresholds — respostas genéricas são menos valiosas nesta sessão.

Quando usar este bloco

  • Entrevistas técnicas para engenheiros ML/infra/ops que trabalharão com RAG ou agentes.
  • Avaliar readiness operacional e conhecimento de segurança/observability.

Formato recomendado (20 minutos, timeboxed)

  • 0–1 min — Introdução rápida (objetivo do bloco).
  • 1–11 min — Perguntas técnicas rápidas (6–8 perguntas, ~1.5 min cada).
  • 11–17 min — Mini‑cenário de incidente (STAR técnico): candidato responde 6 min; 1–2 min follow‑ups.
  • 17–19 min — Discussão rápida de mitigação/ops (2 min).
  • 19–20 min — Conclusão, notas rápidas para scoring.

DICA DO ENTREVISTADOR: Sinalize o tempo durante o mini‑cenário para garantir respostas completas sem exceder o bloco.

Pré‑entrevista (checklist do entrevistador)

  • Confirma experiência do candidato com RAG/agents e ferramentas equivalentes (Langfuse/LangSmith, DataDog, etc.).
  • Tenha o mini‑cenário por escrito (garante consistência entre candidatos).
  • Abra a checklist e o scoring sheet antes da entrevista.
  • Tenha acesso rápido a dashboards/alertas exemplo para discussão.

CHECK: Se o candidato não conhece Langfuse, aceite equivalentes e peça para mapear quais eventos/metadados usaria na ferramenta que conhece.

O que avaliar (competências chave)

  • Instrumentação: eventos mínimos e metadados para tracing completo.
  • Métricas & alerting: indicadores específicos a RAG/agent e thresholds.
  • Observability tooling: experiência prática com tracing, dashboards e request‑level tracing.
  • Segurança: mitigação prática de prompt injection e exfiltration.
  • Model traceability & governance: versionamento, snapshots, reproducibility.
  • Operações: caching, rate limits, circuit breakers, incident playbooks.

O QUE PROCURAR: respostas que incluam "trace_id" propagado, metadados por evento e medidas concretas (p95, thresholds, ações automáticas).

Checklist rápido do entrevistador (o que uma boa resposta deve cobrir)

  • Eventos instrumentados: ingest, chunk creation, embedding call, vector search, reranker, prompt build, model call, tool calls, trace_id que correlaciona tudo.
  • Metadados: model_version, embedding_model_version, vector_db_snapshot_id, top_k_ids, reranker_scores, prompt_template_id, token_count, source doc ids.
  • Métricas concretas: latência p50/p95 (retrieval+generation), tokens_per_request, top_k_recall, reranker_precision@k, hallucination_rate, tool_error_rate, agent_step_count.
  • Mitigações práticas: canonicalização, function calling/JSON Schema, allow‑list, sandboxing, least privilege.
  • Caching: exact vs semantic, embedding memoization, invalidação por snapshot.
  • Anti‑loop: max_steps, deduplicação de ações, circuit breakers.
  • Incidente: mitigação imediata, investigação (correlação de traces), comunicação e postmortem.

QUICK HINT: Se o candidato esquece tokens ou prompt_template_id, peça explícito — são sinais de instrumentação insuficiente.

Instrumentação & Trace model (detalhado)

  • Trace_id: tag every request. Propaga entre serviços e ferramentas.

  • Eventos mínimos a emitir (ordem típica):

    • ingestion_event (ingest_id, source_meta)
    • chunk_created (chunk_ids, chunk_hash)
    • embedding_call (embedding_model, embedding_request_id, latency, tokens)
    • vector_search (vector_search_id, query, top_k, distances)
    • reranker_call (reranker_id, scores, chosen_ids)
    • prompt_build (prompt_template_id, final_prompt, prompt_id)
    • model_call (model_call_id, model_name/version, latency, input_tokens, output_tokens)
    • tool_call (tool_id, args_hash, outcome, error)
    • response_event (final_response_id, sources, confidence)

  • Cada evento inclui: trace_id + timestamp + request_id + persona/tenant.

ANOTAÇÃO: Explique ao candidato que trace_id deve aparecer tanto nos logs estruturados quanto em eventos de tracing para facilitar correlação cross‑service.

Metadados a gravar (mínimos recomendados)

  • model_name, model_version
  • embedding_model_version
  • vector_db_snapshot_id (snapshot or index version)
  • top_k_ids (list of doc/chunk ids returned)
  • reranker_scores (per id)
  • prompt_template_id + prompt_id
  • token_counts (input/output)
  • request_owner, tenant_id
  • source doc ids + chunk offsets

DICA PRÁTICA: Use chaves versionadas (ex.: embedding_model:v1.2) e inclua hashes de prompt_template para detectar pequenas mudanças.

Métricas & alerting (práticas e thresholds exemplo)

  • Métricas chave:

    • request_rate (req/s)
    • latency_retrieval_p50/p95
    • latency_generation_p50/p95
    • tokens_per_request (avg)
    • top_k_recall (vs golden set)
    • reranker_precision@k
    • hallucination_rate (user feedback / auto checks)
    • tool_error_rate
    • agent_step_count distribution
    • success_rate for critical flows

  • Alertas exemplares (ações automáticas sugeridas):

    • hallucination_rate > baseline + 5% sustentado por 5m → autoswitch para modelo conservative ou retrieval‑only; notificar oncall.
    • tool_error_rate spike (ex.: > X% increase em 1m) → circuit breaker para a tool, degradar funcionalidades, notificar.
    • vector DB latency > SLA (ex.: > 200ms p95) → throttle ingestion + abrir ticket.
    • agent_step_count média > configured max_steps → bloquear new agent runs e abrir investigação.

EXPLICAÇÃO: Sempre combine alertas com ações automáticas (degrade, switch model, throttle) e com notificações/escalação.

Observability tooling (prático)

  • Request tracing UI: Langfuse / LangSmith ou equivalente. Usar para ver prompts, embeddings, top_k e metadados por request.
  • Tracing distribuído: propagar trace_id entre services; correlacionar logs/metrics/traces.
  • Metrics backend: Prometheus + Grafana (ou gerido). Exportar histograms para latências.
  • Logs: structured logs (JSON) com trace_id; redaction de PII; amostragem para requests de alto volume.

DICA: Tenha dashboards prontos (p50/p95 latências, hallucination trend, tool error spikes) e exemplos de request traces para mostrar ao candidato.

Segurança — mitigação de prompt injection & exfiltration

  • Input handling:
    • Canonicalizar e normalizar encoding; strip/escape sequences.
    • Heurísticas de detecção (patterns, token anomalies) e roteamento para revisão humana.
  • Function calling & schema validation:
    • Expor apenas funções allow‑listed com JSON Schema; validar e rejeitar campos perigosos.
  • Tool execution:
    • Sandbox ambientes de execução; aplicar least privilege nas credenciais.
    • Double‑check de ações sensíveis com aprovação humana.
  • Logging & audit:
    • Auditar chamadas de tool; monitorar padrões suspeitos (ex.: alto volume de credenciais retornadas).
  • Redaction:
    • Policies de PII no logging; minimizar exposição no traces.

CHECKLIST DE SEGURANÇA: Se candidato não menciona allow‑list/JSON Schema e least privilege para tools, pontuar negativo.

Caching e patterns operacionais

  • Onde colocar cache:
    • Embedding cache (antes da chamada de embeddings): chave = hash(input_text) + embedding_model_version.
    • Semantic cache (query → answer) pós‑retrieval com TTL curto; invalidar por doc_version/vector_snapshot.
    • Exact prompt→response cache pós‑geração para prompts idênticos.
  • Invalidação:
    • Version keys com vector_db_snapshot_id e doc_version; on reindex, incrementar snapshot id e evict.
  • Estratégias de cache warming e canary para novos índices.

ANOTAÇÃO: Enfatize que caches devem incluir versão do modelo/índice para evitar respostas fora de sincronia.

Prevenção de loops de agentes

  • Imposição de max_steps por execução do agente.
  • Histórico de ações por trace (detectar repeats com mesma tool+args).
  • Counters por tool/args com circuit breakers (open se > N failures em M minutos).
  • Backoff exponencial e timeouts; escalonamento humano se repetição persistente.

DICA RÁPIDA: Peça um exemplo de implementação (pseudocódigo) para validar entendimento.

Model traceability & governance

  • Guardar em registry/metadata store:
    • model_name/version
    • embedding_model_version
    • training_snapshot_id / provenance
    • prompt_template_id (com history)
    • vector_db_snapshot_id
    • config/hyperparams
    • migration and reindex logs
  • Reprodutibilidade:
    • Armazenar dataset ids, seed values, random states quando aplicável.

BOA PRÁTICA: Integrar model registry com traces para poder reconstruir exatamente um request antigo (model + prompt + index snapshot).

Mini‑cenário de incidente (usar entre 11–17 min)

  • Cenário: "Recebem alertas de aumento súbito de fallback/hallucination_rate em produção (usuários a reportar respostas incorretas)."

Expectativa de resposta — passos por janelas temporais

  • 0–60 minutos (mitigação imediata):

    • Ações rápidas: reduzir tráfego, autoswitch para modelo conservador ou retrieval‑only, aplicar rate limits, rollback de deploy recente.
    • Triage de traces: buscar trace_id das requests falhadas; verificar top_k, reranker_scores, prompt_template_id, modelo deployado recentemente.
    • Notificar oncall e atribuir owner; abrir incidente com severidade.

  • 4 horas (investigação aprofundada):

    • Correlacionar por trace_id, reexecutar requests problemáticos em staging com golden dataset.
    • Verificar alterações recentes: reindex, embeddings, reranker thresholds, prompt template changes.
    • Mitigação parcial: forçar stricter reranker/confidence filtering, bloquear fontes suspeitas, ajustar weights de reranker.
    • Comunicação contínua com CS/Ops e documentação das evidências.

  • 72 horas (correção permanente):

    • Hotfix: ajustar prompt templates, reindex, retrain reranker ou reverter mudanças.
    • Validar em staging com golden dataset; rollout canary e monitorar métricas.
    • Postmortem com RCA e ações corretivas (ex.: testes de regressão, melhores alertas).

GUIA DE AVALIAÇÃO: Pontue pela clareza de ações imediatas, capacidade de triagem por traces e proposta de correção permanente.

Exemplos de snippets (Python — ilustrativo)

  1. Emissão de evento/trace (pseudo‑Langfuse API)
import time

def emit_trace_event(client, trace_id, stage, payload):
    event = {
        "trace_id": trace_id,
        "stage": stage,
        "timestamp": time.time(),
        "payload": payload,
    }
    client.send_event(event)

# Uso:
# emit_trace_event(lf_client, "trace-123", "vector_search", {"query": "...", "top_k": 10})

ANOTAÇÃO: Certifique‑se que cada evento contém trace_id, request_id e metadados mínimos (model/version, prompt_id).

  1. Filtro de prompt injection (simplificado)
import re

INJECTION_PATTERNS = [r"ignore.*previous", r"disregard.*system", r"execute.*shell"]

def suspicious_input(text: str) -> bool:
    t = text.lower()
    for p in INJECTION_PATTERNS:
        if re.search(p, t):
            return True
    return False

# Uso: if suspicious_input(user_query): route to human review or sanitize

NOTA: Este é um filtro simplificado — em produção combine heurísticas, token analysis e modelos auxiliares.

  1. Estratégia de cache (descrição)
  • Antes das embeddings: embedding cache (evita chamadas repetidas de embedding).
  • Após retrieval: semantic cache para (query → best answer) com TTL curto e invalidação por vector_db_snapshot_id.
  • Após geração: exact response cache para prompts idênticos.

Dicas curtas para o candidato

  • Começa com 2–3 frases diretas sobre a tua abordagem.
  • Usa exemplos concretos: nomes de métricas, thresholds, logs e traces.
  • Se não trabalhaste com Langfuse, indica o equivalente (DataDog traces, internal trace UI) e descreve o que meterias nos traces.

DICA: Procura candidatos que articulam trade‑offs (ex.: custo vs latência ao aumentar caching, risco vs utilidade ao autoswitch).

Scoring (20 pontos total)

  • Instrumentação & traces: 6 pts (lista de eventos + metadados).
  • Metrics & alerting: 4 pts (métricas específicas e thresholds).
  • Security & prompt injection: 4 pts (mitigações práticas).
  • Ops & caching + prevenção de loops: 4 pts (onde cache e anti‑loop).
  • Incident response (mini‑cenário): 2 pts (clareza e ações por tempo).

SUGESTÃO: Use o scoring como guia; valide com follow‑ups se a resposta foi superficial.

Perguntas de follow‑up recomendadas (use 1–2 por entrevista)

  • "Como versionas embeddings e reindexas sem downtime?"
  • "Como medes e limitas custo de tokens em spikes de tráfego?"
  • "Como implementas testes de regressão para hallucination rate?"

Notas finais

  • Preferir respostas com experiência prática e exemplos concretos.
  • Evitar respostas demasiado teóricas sem aplicação prática.

Anexos rápidos — Exemplo de alerta (definição concisa)

  • Nome: hallucination_rate_spike
  • Métrica: hallucination_rate (via feedback/auto checks)
  • Threshold: > baseline + 5% por 5m
  • Ação automática: autoswitch para conservative model / retrieval‑only; throttle; notify oncall
  • Escalonamento: abrir incidente P1 se não regressar em 10m

FINAL: Este README contém anotações e dicas para o entrevistador — pode ser adaptado para diferentes níveis de senioridade trocando thresholds e exigência de detalhes (ex.: mais foco em arquitetura para senior, mais foco em implementação para intermediários).

Zona de prática

Sem perguntas. Clica em Editar para adicionar.