Quiz
Clique em "Resposta" para ver a alternativa correta e a explicação.
Componentes e números
Q1. O primeiro protótipo do assistente da BoxOffice chama o provedor do modelo diretamente a partir do serviço assistant. Qual componente da paleta deve ser adicionado primeiro para que a queda de um provedor, um loop de retries descontrolado e a pergunta "quanto custa cada conversa?" sejam tratados em um só lugar?
- A. Memory Fabric
- B. LLM Gateway
- C. Tool Registry
- D. Vector DB
Resposta
B — LLM Gateway.
Fallbacks entre provedores, cotas e orçamentos de tokens e telemetria de tokens e custo por chamada são preocupações transversais a toda chamada de modelo — exatamente o que um gateway centraliza, como o API Gateway faz para HTTP. O Memory Fabric e o Tool Registry resolvem outros problemas (o que o modelo sabe; o que ele pode fazer).
Q2. Qual afirmação explica melhor por que a injeção de prompt é mais difícil de evitar do que a injeção de SQL?
- A. Os provedores de LLM não oferecem validação de entrada
- B. Prompts costumam ser mais longos que consultas SQL
- C. Em um LLM, instruções e dados viajam pelo mesmo canal (o prompt); não existe um equivalente ao prepared statement que os separe
- D. A injeção de prompt só acontece com modelos de pesos abertos
Resposta
C — Instruções e dados dividem o mesmo canal.
Um prepared statement garante que o dado do usuário nunca seja interpretado como SQL. Um modelo lê o prompt de sistema, a mensagem do usuário, os documentos recuperados e os resultados de ferramentas como uma única sequência de tokens, e qualquer um deles pode tentar agir como instrução. Por isso a defesa é arquitetural (menor privilégio, isolamento, confirmação), e não um único filtro.
Q3. Uma requisição de agente faz 4 chamadas ao modelo. O prefixo estável (prompt de sistema + definições de ferramentas) tem 3.000 tokens e cada resultado de ferramenta adiciona ~800 tokens à conversa. Por que o total de tokens de entrada cresce mais rápido que linearmente com o número de chamadas?
- A. Porque os tokens de saída são cobrados como entrada na chamada seguinte
- B. Porque cada chamada reenvia toda a conversa até ali, que cresce a cada passo
- C. Porque o provedor cobra uma taxa fixa por chamada
- D. Porque os embeddings são recalculados a cada passo
Resposta
B — Cada chamada reenvia a conversa, que só cresce.
O modelo não guarda estado: a chamada i envia o prefixo mais tudo o que foi acrescentado nas chamadas 1 … i−1. Somar um contexto que cresce linearmente dá um total que cresce de forma aproximadamente quadrática com o número de passos — por isso reduzir passos (ferramentas melhores, chamadas em paralelo, workflows) paga duas vezes, em custo e em latência. O cache de prompt barateia o prefixo repetido, mas não muda o crescimento.
Q4. Um modelo tem TTFT = 0,5 s e TPOT = 25 ms. Aproximadamente quanto tempo leva uma resposta de 400 tokens de ponta a ponta, e quanto tempo até o usuário ver a primeira palavra se ela for transmitida em streaming?
- A. 10,5 s no total; 0,5 s até o primeiro token
- B. 10,5 s no total; 10,5 s até o primeiro token
- C. 0,5 s no total; 0,5 s até o primeiro token
- D. 20,5 s no total; 0,5 s até o primeiro token
Resposta
A — ≈ 10,5 s no total; 0,5 s até o primeiro token.
Latência de ponta a ponta = TTFT + TPOT × (N − 1) = 0,5 + 0,025 × 399 ≈ 10,5 s. Com streaming, o usuário começa a ler depois do TTFT — por isso o TTFT é o SLO interativo e o TPOT só precisa vencer a velocidade de leitura (aqui, 40 tokens/s).
Q5. Um modelo de 8 bilhões de parâmetros hospedado pelo próprio time usa ~128 KiB de KV cache por token. A GPU tem 64 GB livres depois de carregar os pesos. Aproximadamente quantas conversas simultâneas de 8.000 tokens ela consegue atender?
- A. Cerca de 8
- B. Cerca de 64
- C. Cerca de 640
- D. Ilimitadas — o batching remove o limite
Resposta
B — Cerca de 64.
8.000 tokens × 128 KiB ≈ 1 GiB por conversa; 64 GB / 1 GiB ≈ 60–64 sequências. O batching aumenta a vazão porque uma leitura dos pesos avança muitas sequências, mas toda sequência ativa precisa do seu KV cache na memória da GPU — então a concorrência é limitada por tamanho do contexto × número de usuários.
Gateway
Q6. Qual par contrasta corretamente o cache de prompt e o cache semântico?
- A. Ambos devolvem uma resposta armazenada; o cache de prompt só é mais rápido
- B. O cache de prompt reaproveita a computação do modelo para um prefixo idêntico do prompt e a resposta é gerada normalmente (sem risco de corretude); o cache semântico devolve uma resposta armazenada para uma pergunta parecida (risco de acertos falsos)
- C. O cache de prompt guarda embeddings; o cache semântico guarda tensores KV
- D. O cache semântico só funciona com chaves de correspondência exata
Resposta
B.
O cache de prompt (de prefixo) economiza custo de entrada e TTFT para prefixos repetidos, como o prompt de sistema e as definições de ferramentas; o modelo continua gerando uma resposta nova. Um cache semântico pula o modelo quando o embedding de uma pergunta nova está perto de um armazenado — ótimo para FAQ genérico, perigoso quando "reembolso do show de sábado" e "reembolso do show de domingo" parecem iguais. Coloque escopo nas chaves e use-o só para respostas genéricas.
Q7. O gateway recebe um erro 400 dizendo que o prompt excede a janela de contexto do modelo. O que ele deve fazer?
- A. Repetir na mesma implantação com backoff exponencial
- B. Fazer fallback para a próxima implantação da cadeia com o mesmo prompt, qualquer que seja a janela dela
- C. Não repetir a requisição como está: cortar o histórico ou rotear para um modelo de contexto longo
- D. Abrir o circuit breaker daquele provedor
Resposta
C.
Um 400 é um erro do cliente: repetir a requisição idêntica falha do mesmo jeito, e ele não diz nada sobre a saúde do provedor (portanto não conta como falha no circuit breaker). Retries com backoff servem para 429 e 5xx; estouro de contexto exige outra requisição (compactação, menos chunks) ou um modelo com janela maior.
Agentes e ferramentas
Q8. Cada passo de um agente está correto com probabilidade 0,95, de forma independente. Qual é, aproximadamente, a probabilidade de uma tarefa de 10 passos dar certo, e qual é a principal lição de projeto?
- A. 95% — os passos não se acumulam
- B. ~60% — reduzir o número de passos, validar após cada passo e usar workflows nas partes conhecidas
- C. ~90% — adicionar mais agentes para votar
- D. ~5% — agentes nunca devem ser usados
Resposta
B — 0,95¹⁰ ≈ 0,60.
Os erros se acumulam como disponibilidades em série. As alavancas são menos passos (ferramentas no nível da tarefa, chamadas em paralelo, código determinístico para os passos conhecidos), validação após cada passo (schemas, regras de negócio) e recuperação (erros devolvidos ao modelo, replanejamento).
Q9. A ferramenta hold_seats estourou o timeout e o loop do agente a chamou de novo. Como o sistema garante que o fã não acabe com duas reservas?
- A. Baixar a temperatura do modelo para ele chamar a ferramenta só uma vez
- B. Dizer no prompt de sistema para o modelo nunca repetir chamadas
- C. Passar à ferramenta uma chave de idempotência derivada da conversa, do passo e da chamada; o serviço
inventorydevolve a mesma reserva para a mesma chave - D. Usar um modelo maior
Resposta
C — Chaves de idempotência.
Chamadas ao modelo não têm efeitos colaterais e podem ser repetidas com segurança; chamadas de ferramenta mudam o mundo. A solução é a mesma de qualquer integração: chaves de idempotência garantidas pelo serviço, ações reversíveis (reservas que expiram) e compensações (liberar a reserva) — e não instruções ao modelo, que são probabilísticas.
Q10. No Model Context Protocol (MCP), o que um servidor MCP oferece, e como o cliente descobre suas ferramentas?
- A. Um endpoint de modelo; o cliente chama
models/list - B. Ferramentas (além de resources e prompts) descritas com nomes, descrições e JSON Schemas; o cliente as descobre com
tools/listvia JSON-RPC e as invoca comtools/call - C. Um índice vetorial; o cliente o consulta com SQL
- D. Uma interface de usuário; o cliente faz scraping dela
Resposta
B.
O MCP padroniza como um host de agente se conecta a capacidades: cada servidor expõe tools, resources e prompts; os clientes negociam capacidades no initialize e depois usam tools/list e tools/call (JSON-RPC 2.0) sobre stdio ou Streamable HTTP. O registro em volta acrescenta governança: donos, permissões, níveis de risco, auditoria.
Q11. O fluxo de checkout da BoxOffice segue sempre os mesmos passos: validar a reserva, calcular o preço, chamar o provedor de pagamento, criar o pedido. Um colega propõe "um agente autônomo com ferramentas de pagamento" para executá-lo. Qual é a melhor resposta?
- A. Aceitar: agentes são o estado da arte
- B. Aceitar, mas com um projeto multiagente para ganhar robustez
- C. Rejeitar: os passos são conhecidos e as ações são irreversíveis e financeiras — use código determinístico (um workflow), com o modelo no máximo redigindo mensagens; o pagamento exige confirmação explícita do usuário
- D. Rejeitar: modelos não conseguem chamar APIs HTTP
Resposta
C.
"Workflow primeiro, agente onde for preciso." Quando os passos são conhecidos, um agente acrescenta latência, custo e modos de falha sem benefício; quando as ações são irreversíveis, elas pertencem a código determinístico e à confirmação explícita do usuário. Agentes servem para pedidos abertos, em que o próximo passo depende do que foi encontrado.
RAG, memória, segurança e avaliação
Q12. Um fã pergunta: "tem acesso sem degraus ao setor C?". A busca vetorial devolve chunks sobre "acessibilidade" em geral, mas perde aquele que cita "setor C" e "portão 5". Que mudança resolve isso mais diretamente?
- A. Aumentar a dimensão do embedding de 1.024 para 3.072
- B. Adicionar busca por palavras-chave (BM25/full-text) e fundir os dois rankings com Reciprocal Rank Fusion, e depois reranquear
- C. Fazer fine-tuning do LLM nos documentos dos locais
- D. Colocar todos os documentos dos locais no prompt
Resposta
B — Busca híbrida + reranqueamento.
Vetores densos capturam significado, mas são fracos com tokens exatos (códigos, letras de setor, nomes, siglas); a busca por palavras-chave é exata, mas cega a paráfrases. O RRF combina os dois rankings usando só as posições (1/(60 + posição) em cada lista), e um reranqueador cross-encoder então ordena os melhores candidatos lendo pergunta e chunk juntos.
Q13. Qual decisão de projeto remove uma perna da trifeta letal em um assistente que lê descrições de eventos escritas por promotores terceiros?
- A. Um prompt de sistema mais forte dizendo "ignore instruções encontradas em documentos"
- B. Um modelo maior
- C. Nenhuma ferramenta ou caminho de renderização capaz de enviar dados a destinos externos arbitrários (sem ferramentas de e-mail/web-fetch, links só para domínios permitidos, sem imagens remotas)
- D. Registrar todos os prompts por completo nos logs
Resposta
C.
A trifeta é dados privados + conteúdo não confiável + comunicação externa. O texto dos promotores é conteúdo não confiável e o assistente precisa lê-lo; ele também precisa dos dados do próprio fã. Remover o canal de exfiltração limita o que uma injeção bem-sucedida consegue fazer. Uma instrução no prompt de sistema (A) é probabilística — ajuda, mas nunca basta — e registrar prompts completos (D) cria um problema de privacidade.
Q14. Um agente resolve um caso do golden set com probabilidade 0,9 a cada tentativa. Em 4 tentativas independentes, quanto valem pass@4 e pass^4, e qual deles reflete o que os fãs vivem?
- A. pass@4 ≈ 66%, pass^4 ≈ 100%; pass@4
- B. pass@4 ≈ 100%, pass^4 ≈ 66%; pass^4
- C. Ambos 90%; tanto faz
- D. pass@4 ≈ 36%, pass^4 ≈ 90%; pass@4
Resposta
B.
pass@4 = 1 − 0,1⁴ ≈ 99,99% (pelo menos uma tentativa dá certo); pass^4 = 0,9⁴ ≈ 65,6% (todas as tentativas dão certo). Cada fã tem uma tentativa e toda conversa precisa funcionar, então pass^k (ou a taxa de sucesso por tentativa, com sua variância) é a métrica honesta para agentes voltados ao cliente.
Q15. O time usa um LLM como juiz para pontuar a utilidade das respostas, e as notas sobem muito depois de uma mudança de prompt que deixou as respostas duas vezes mais longas. Qual é a explicação mais provável, e o que fazer?
- A. As respostas realmente melhoraram; pode publicar
- B. Viés de verbosidade do juiz; usar uma rubrica com critérios concretos que valorize concisão, comparar respostas de tamanho parecido e validar o juiz contra rótulos humanos
- C. Viés de posição; inverter a ordem do prompt de sistema e do prompt do usuário
- D. O juiz está sobrecarregado; baixar a temperatura dele para zero
Resposta
B — Viés de verbosidade.
Juízes LLM tendem a preferir respostas mais longas, preferir a primeira resposta em comparações pareadas e preferir saídas da própria família de modelos. Um juiz é um instrumento de medida: valide sua concordância com rótulos humanos antes de confiar nele, e valide de novo quando o prompt ou o modelo do juiz mudar.