Quiz final da Unidade 1

Tamanho não tem relação com agência. Um modelo enorme sem Tools continua só gerando texto.

Correto. As duas metades importam: o modelo decide, o seu código executa.

Isso é um script — e muitas vezes é a solução certa. Só não é um Agent, porque não há decisão em tempo de execução.

Nada é recuperado. Se fosse, ele não inventaria números de processo com dígito verificador plausível.

Correto. Toda a capacidade e todos os defeitos do modelo saem daí.

O modelo do curso roda offline, na sua máquina. Não há consulta a nada — a não ser que você construa uma Tool para isso.

Não existe camada fora do prompt. Confira o chat template do qwen2 no capítulo de mensagens: a system message vira texto entre tokens especiais, como todo o resto.

Correto. Foi exatamente o que o experimento do capítulo mostrou: instruído a não responder sobre o mérito, o modelo respondeu assim mesmo.

Ela tem efeito, e considerável. O erro é confundir efeito com garantia.

O chat template do qwen2, que reproduzimos no capítulo de Tools, mostra o bloco sendo escrito dentro da system message.

Correto. O framework automatiza a escrita desse texto; ele não deixa de ser texto.

Não há introspecção. Se a Tool não estiver descrita no prompt, o modelo não sabe que ela existe.

É um efeito colateral, não o motivo.

Correto. É o experimento 4 do capítulo do Agent do zero: sem a parada, aparecem processos fabricados em formato impecável.

A parada não valida nada. JSON malformado continua acontecendo — e volta como Observation de erro.

Correto. As duas saídas precisam existir: sem o limite, um modelo em laço roda até estourar o contexto.

Nada obriga o modelo a usar todas as Tools. Ele usa as que julgar necessárias.

Seria um péssimo critério de parada para um sistema que roda sem supervisão.

Não é indiferente. Compare os dois casos rodando o experimento 2 do capítulo do Agent do zero.

Correto. Escrever mensagens de erro pensando em quem vai lê-las — o modelo — é projeto, não estilo.

Não exige. O motivo é o comportamento do modelo na volta seguinte do ciclo.

Essa distinção não existe. Para o modelo, tudo é texto no mesmo prompt.

Correto. O modelo pode obedecer. O que impede o estrago é a Tool não conseguir ler além do permitido, aconteça o que acontecer.

Não há detecção confiável. Projetar contando com ela é projetar errado.

Instrução em prompt não é controle. O capítulo de mensagens mostra o modelo desobedecendo a uma instrução explícita.

Erro grave: transforma o controle de acesso em uma decisão do modelo. O nível nunca deve ser argumento.

Correto. O registro sigiloso não é lido, não entra no prompt, e o modelo não sabe que ele existe.

Tem, mas esse é o menor dos problemas — erro de sintaxe você percebe.

Correto. Uma Tool por intenção, com os parâmetros que você controla, é o oposto disso.

Consumo de contexto é uma preocupação real, mas não é o motivo aqui.

É a interpretação mais perigosa possível, e a mais tentadora, porque a resposta parece boa.

Correto. A aparência da resposta não carrega nenhuma informação sobre a procedência dela.

Conferir não faz mal, mas a conclusão já está disponível: sem consulta, não houve dado.

Funcionaria — e seria mais lento, mais caro e menos confiável do que a alternativa óbvia.

Correto. Quando uma consulta fixa resolve, ela é a resposta certa — e reconhecer isso é parte de saber usar Agents.

O que muda são os dados, não a decisão. Um SELECT com data relativa já cobre isso.

Foi o que o resultado sugeriu, e é a conclusão errada. Bastou acrescentar um exemplo ao prompt para o comportamento inverter.

Com um exemplo *few-shot* no prompt, o mesmo modelo passou a fabricar Observations e três números de processo inexistentes.

Ele gera, e gerou. O que faltava era o padrão a imitar.

O experimento em que a fabricação ocorreu rodou com temperature: 0.

Nenhuma rodou. Se tivessem rodado, o código do assunto seria 1001, não 2002.

Nem essa. A geração foi contínua, sem devolver o controle ao programa em momento algum.

Tudo — códigos, Observations, números de processo, resposta final — saiu do modelo prevendo o próximo token.

Não houve execução alguma para descartar.

Os cinco processos listados são reais e vieram da Observation. O erro está em outro lugar.

O limite funcionou como projetado — cortou em 20 e o banco devolveu tudo o que havia.

Mais discreto que uma alucinação de dados, e por isso mais fácil de passar despercebido em uma leitura rápida.

O int() converteu corretamente; o valor chegou como número.

Deixaria o Agent travado em uma volta extra, e o modelo poderia repetir a contagem errada assim mesmo.

Dá ao modelo o dado que faltava. É o mesmo princípio das mensagens de erro: escreva a saída pensando em quem vai lê-la.

Ajuda no comportamento médio e não garante nada — a lição do experimento com a system message.

Muda o número, não o mecanismo. O modelo repetiria "500" do mesmo jeito.