Como pedir respostas estruturadas que possas reutilizar

Começa pelo destino da resposta

Decide onde vais usar a informação antes de pedir uma tabela ou um ficheiro JSON. Uma pessoa que revê pedidos precisa de contexto legível; uma aplicação precisa de campos previsíveis. A estrutura deve servir essa utilização concreta e evitar que alguém tenha de interpretar novamente cada resposta recebida.

Imagina uma pequena empresa que recebe pedidos de formação por email. A equipa quer reunir o tema, o número de participantes e as dúvidas que impedem preparar uma proposta. Neste exercício fictício, a IA ajuda a organizar a informação; não envia propostas nem assume compromissos com clientes.

Se uma pessoa vai copiar o resultado para uma folha, uma tabela curta pode bastar. Se um workflow vai ler automaticamente os valores, interessa acordar uma estrutura que o passo seguinte reconheça. Não escolhas JSON apenas porque parece mais técnico. Escolhe-o quando existir uma utilização que beneficie dessa organização.

Define também o que a resposta não vai decidir. Extrair “queremos formação em Excel” é diferente de recomendar o programa, calcular um preço ou confirmar disponibilidade. Quando misturas essas tarefas, deixas de perceber quais os campos retirados da mensagem e quais os criados pelo modelo.

O guia para escrever um pedido claro a um assistente de IA ajuda a preparar objetivo e contexto. Aqui vamos concentrar-nos na entrega: o que precisa de permanecer estável para poderes usá-la repetidamente.

Define o significado dos campos

Escreve uma definição curta para cada campo e indica de onde pode vir o respetivo valor. Dois campos com nomes claros podem continuar ambíguos se misturarem informação confirmada, estimativas e sugestões. Estabelece essas diferenças antes de pedir ao modelo que organize os dados do teu processo.

No exemplo, “participantes” significa o número confirmado na mensagem. Se a pessoa diz “somos cerca de dez”, há uma estimativa, não uma confirmação de dez inscrições. Podes guardar a frase original e deixar o número confirmado por preencher, conforme a regra escolhida.

Também precisas de definir “tema”. É o assunto pedido pelo cliente, não o nome de um curso que a empresa gostaria de vender. “Queremos aprender a automatizar relatórios” pode ser preservado como tema mesmo que ainda falte escolher ferramentas e nível de formação.

Um pequeno dicionário de campos evita interpretações diferentes entre pessoas. Este é um exemplo editorial para o pedido fictício:

Não acrescentes campos que ninguém vai usar. “Sentimento do cliente” ou “probabilidade de fechar” exigem critérios próprios e podem introduzir interpretações que não ajudam esta tarefa. Começa pelo necessário para preparar o próximo contacto e avalia novos campos quando houver uma decisão concreta a apoiar.

Distingue desconhecido, zero e não aplicável

Escolhe uma convenção explícita para os dados em falta, porque um campo vazio pode ter vários significados. Desconhecido, zero e não aplicável devem continuar distinguíveis quando essa diferença altera a decisão. A mesma regra precisa de ser compreendida pelo assistente, pela pessoa que revê e pelo sistema que recebe a informação.

Se não foi indicado um orçamento, o valor não é zero. Zero pode significar que a pessoa procura uma opção gratuita. Se guardares ambos da mesma forma, podes excluir um pedido válido ou apresentar uma proposta completamente inadequada.

Num objeto JSON, podes convencionar null para um valor desconhecido, desde que o sistema de destino aceite essa representação. Num documento para leitura humana, podes usar “não indicado”. A escolha deve ser consistente; não alternes entre texto vazio, traço, zero e “n/a” sem saber como serão interpretados.

Há situações em que precisas de mais contexto do que um valor. Um campo pode conter uma data desconhecida e outro guardar “preferência por novembro”. Assim preservas a informação disponível sem transformar uma preferência vaga num dia inventado.

Se o teu destino exige sempre uma data exata, cria uma etapa de esclarecimento. Não peças à IA para preencher a data “mais provável” só para passar a validação. Um requisito técnico mal definido não deve transformar ausência de informação numa afirmação sobre o cliente.

Mostra uma entrada e uma saída esperada

Fornece um exemplo pequeno que explique a transformação pretendida, incluindo pelo menos uma informação ausente. Um exemplo completo demais pode ensinar o modelo a preencher todos os campos mesmo quando a fonte não permite fazê-lo. Escolhe uma mensagem realista e descreve os critérios pelos quais vais aceitar a saída.

Usa esta entrada fictícia, com uma referência atribuída previamente pelo processo:

Pedido F-018: Queremos uma formação de Excel para a equipa de operações. Preferimos novembro, mas ainda estamos a confirmar quem participa. Podem indicar o que precisam de saber para preparar uma proposta?

A saída esperada deve conservar o tema, deixar o número de participantes desconhecido e manter “novembro” como preferência textual. A mensagem não contém ano, dia, orçamento ou duração. Nenhum desses detalhes pode ser apresentado como confirmado.

Uma representação possível seria esta. É um exemplo escrito para explicar o formato, não o resultado de uma integração executada:

{"pedido_id":"F-018","tema":"Formação de Excel para a equipa de operações","participantes_confirmados":null,"prazo_texto":"Preferimos novembro","pendencias":["Confirmar participantes","Confirmar ano e datas possíveis","Clarificar tarefas e nível de Excel"]}

As pendências são propostas de perguntas, não informações extraídas. Essa diferença está no significado do campo. Se mais tarde quiseres acrescentar sugestões de programa, coloca-as numa área própria e identifica-as como sugestões sujeitas a revisão.

Guarda este exemplo juntamente com as definições. Quem alterar o pedido deve conseguir explicar por que motivo o número ficou desconhecido e por que motivo não apareceu uma data completa. O exemplo passa a ajudar a revisão de versões futuras.

Escreve um pedido que permita avaliar a resposta

Pede uma operação delimitada, especifica os campos e descreve o comportamento perante informação ausente ou contraditória. Acrescenta a fonte e o formato final, evitando instruções vagas como tornar a resposta profissional. O pedido deve permitir comparar a entrega com critérios observáveis, mesmo que precises de corrigir a primeira tentativa.

Podes adaptar este pedido para o exercício:

Organiza o pedido de formação fornecido. Usa apenas a mensagem como fonte para tema, participantes e prazo. Preserva o identificador recebido. Devolve um único objeto JSON com os campos pedido_id, tema, participantes_confirmados, prazo_texto e pendencias. Usa null nos valores desconhecidos. Em pendencias, propõe perguntas curtas necessárias para preparar uma proposta e devolve sempre uma lista. Não inventes datas, quantidades, orçamento ou disponibilidade. Não acrescentes explicações fora do objeto. Se houver contradições, inclui uma pergunta de esclarecimento em pendencias.

Este texto orienta um assistente numa conversa, mas não cria por si só uma validação técnica. Se a saída vier com uma introdução ou com campos diferentes, tens de a corrigir ou rejeitar antes de a entregar a um consumidor automático.

Separa claramente as instruções da mensagem a analisar. O texto recebido de um cliente pode conter pedidos ou frases que não fazem parte das tuas regras de extração. Num processo automatizado, aplica ainda os limites de acesso e de ações no sistema, sem depender apenas de uma frase no prompt.

Para organizar as entradas antes desta etapa, consulta como preparar dados em JSON antes de os enviar à IA. Aqui estamos a definir a saída; a qualidade da informação que entra continua a influenciar aquilo que podes obter.

Percebe o que um esquema consegue garantir

Uma estrutura pedida em linguagem natural e uma resposta validada por esquema oferecem controlos diferentes. Numa integração, podes definir tipos, campos obrigatórios e valores permitidos, conforme a ferramenta utilizada. Esses controlos verificam a organização dos dados, mas continuam a precisar de regras e revisão para confirmar o significado dos valores.

A documentação de JSON Schema para objetos distingue propriedades definidas, propriedades obrigatórias e propriedades adicionais. Declarar um campo em properties não o torna automaticamente obrigatório. A lista required identifica os campos exigidos; additionalProperties permite controlar outros campos.

Também há diferença entre um campo presente com null e um campo ausente. O esquema deve permitir a representação que escolheste. Se declaras que participantes é sempre um número, uma entrada sem participantes não cabe nessa regra, mesmo quando desconhecido é a resposta correta.

Na API da OpenAI, Structured Outputs permite usar um esquema suportado para controlar a resposta. É diferente do modo JSON, que não garante correspondência ao teu esquema. A documentação também prevê recusas, respostas incompletas e erros no conteúdo, que a aplicação deve tratar.

Isto não significa que escrever “usa Structured Outputs” numa conversa ative essa funcionalidade da API. Quem implementa a integração tem de configurar a opção adequada e conferir a compatibilidade do modelo e do esquema. Neste exercício, não é necessário contratar ou executar uma API para aprender a definir os campos.

Um número de participantes inventado pode ter o tipo certo e continuar errado. A validação técnica resolve parte do problema; a comparação com a mensagem original resolve outra parte. Não confundas uma estrutura aceite pelo programa com uma proposta comercial pronta a enviar.

Testa situações que obrigam a preservar diferenças

Experimenta a estrutura com casos que variem aquilo que realmente importa no teu processo. Um pedido completo testa apenas uma parte do trabalho. Acrescenta ausência de dados, estimativas, contradições e várias solicitações na mesma mensagem, registando o resultado esperado antes de pedir novas respostas ao assistente.

No pedido F-018, a quantidade deve continuar desconhecida. Noutro caso fictício, “confirmamos oito participantes” deve permitir extrair oito. Se a mensagem disser “serão oito, talvez doze”, precisas de preservar a incerteza e pedir confirmação, em vez de escolher silenciosamente uma das quantidades.

Experimenta também “não queremos formação presencial”. A palavra “presencial” aparece no texto, mas a negação muda o significado. Se a tua estrutura inclui modalidade, define como representar preferências, exclusões e opções ainda abertas. Não uses uma simples presença de palavra como prova de escolha.

Uma mensagem pode pedir Excel para uma equipa e apresentações para outra. Decide se a saída deve ter dois registos ou uma lista de necessidades dentro do mesmo pedido. Essa escolha depende de como vais acompanhar a proposta, não da formatação que o modelo preferir naquele momento.

Estes são testes propostos, sem resultados medidos neste artigo. Regista para cada caso o que esperavas, o que recebeste e o que precisou de correção. Repete os casos relevantes quando mudares as instruções, o esquema ou a ferramenta.

Confirma o que chega ao sistema seguinte

Verifica a informação depois de a colocar no destino onde será utilizada. Uma resposta correta no chat pode perder significado durante a cópia, a importação ou o mapeamento de campos. Confere pelo menos um registo completo e um registo com informação em falta antes de alargar o processo.

Se copias uma tabela para uma folha, observa se cada valor ficou na coluna certa e se as quebras de linha das pendências foram preservadas. Se usas uma integração, confirma os nomes e tipos esperados pelo passo seguinte. Um campo ignorado silenciosamente pode retirar precisamente a informação necessária para a revisão.

No exemplo, abre o registo F-018 no destino e compara-o com a mensagem de entrada. O tema deve continuar associado à equipa de operações, participantes deve manter o estado desconhecido e novembro deve continuar uma preferência. A aparência de uma linha preenchida não demonstra que essa distinção foi preservada.

Guarda a referência da fonte e a versão das regras utilizadas, com acesso adequado à informação. Assim consegues rever uma classificação sem procurar entre conversas soltas. Evita copiar dados pessoais para locais que não precisam deles só para facilitar a auditoria.

Quando a entrega já funciona, podes integrá-la numa biblioteca de prompts que continua útil. Guarda o pedido, as definições, os exemplos e os critérios de revisão. Reutilizar o conjunto é mais fiável do que guardar apenas uma frase que produziu uma boa resposta uma vez.

Como podes aprender a aplicar isto no Laboratório da IA

No Laboratório da IA, podes trabalhar a passagem de pedidos vagos para processos que consegues executar e rever. Traz uma tarefa concreta, define a entrega e experimenta uma estrutura adequada ao teu negócio. As aulas semanais e os Zooms de acompanhamento semanais ajudam-te a praticar e a esclarecer dificuldades reais.

Começa por uma resposta que hoje precisas de reorganizar à mão. Escolhe os campos necessários, prepara um exemplo sem dados pessoais e verifica se outra pessoa consegue usá-lo. É um exercício pequeno que liga escrita de instruções, organização de informação e automação.

Referências e data de revisão

Este artigo foi revisto em 14 de outubro de 2026, com base em conteúdos do Laboratório e documentação primária sobre respostas estruturadas. O pedido de formação, o objeto JSON e os testes são exemplos editoriais. Não representam dados de clientes, uma integração executada ou uma medição de precisão.

• JSON Schema: propriedades, campos obrigatórios e propriedades adicionais.
• OpenAI: Structured Outputs, esquemas suportados e tratamento de exceções.