1. Introdução
Às vezes, em cursos de engenharia de prompts, mostram um feitiço mágico:
«Não invente fatos e diga “eu não sei” se não houver informação.»
Infelizmente (ou felizmente), para o ChatGPT App isso não funciona como uma bala de prata. O motivo é simples: o modelo vê não apenas o seu system‑prompt, mas também:
- a lista de ferramentas com suas descrições e esquemas;
- os resultados dessas ferramentas;
- o histórico do diálogo, incluindo follow‑ups anteriores.
Se essas três camadas — system‑prompt, descrições das tools, padrões de follow‑up — se contradizem ou simplesmente “ficam soltas”, o modelo começa a se comportar como um júnior clássico: aplicado, mas propenso a inventar.
Dentro do curso usamos a ideia de “defesa em profundidade contra alucinações” (defense in depth):
- nível 1 — regras globais no system‑prompt;
- nível 2 — restrições locais na definição de cada ferramenta;
- nível 3 — tratamento de erros, resultados vazios e follow‑ups.
Nesta aula, reuniremos as três camadas em um contrato único e coerente para nosso aplicativo didático GiftGenius.
Insight
Na nova arquitetura de ChatGPT Apps, o campo para system-prompt desapareceu — formalmente ele não existe mais. Mas isso não significa que você deva abrir mão de instruções globais para o modelo. Há um truque: para o ChatGPT, as descrições das ferramentas são texto de prompt do mesmo jeito que o system clássico. É exatamente por meio delas que você pode trazer de volta um “firmware mental” completo do aplicativo.
Crie uma ferramenta de serviço, por exemplo about ou about_app. Ela não é destinada a chamadas frequentes, mas sua description é lida pelo modelo no mesmo nível das demais ferramentas. Portanto, é possível incorporar o system-prompt completo na descrição. É melhor colocá-lo após uma breve descrição técnica da própria ferramenta. No fim, o modelo recebe o seu system-prompt logo no início — e o aplica a todo o diálogo e às chamadas de tools.
Para simplificar a manutenção, recomendo adicionar uma versão explícita no início do system-prompt, por exemplo SYSTEM_PROMPT_VERSION: v3. Isso ajuda a entender por que o modelo se comporta de forma diferente: você vê imediatamente em qual conjunto de instruções ele está operando. Se em produção surgir um comportamento estranho, fica fácil entender se o erro está relacionado à versão antiga do prompt ou à nova.
Exemplo:
tool description
### Comportamento global do assistente para todo o App GiftGenius (ver 3.01)
*(diretrizes em nível de sistema, não são texto voltado ao usuário)*
system prompt text
2. Quais alucinações o ChatGPT App costuma ter (no exemplo de um catálogo de presentes)
Para saber como tratar, ajuda nomear a “doença”. No contexto de catálogo (presentes, produtos, planos) os tipos mais frequentes de alucinações são estes.
Primeiro, itens inventados no catálogo. O usuário pede “um vale digital para assinatura anual de um serviço específico” ou um presente muito exótico que não existe no seu feed, e o modelo, querendo ser útil, alegremente inventa “Super Space Flight 3000 — voo ao espaço”, algo que nunca existiu no banco do GiftGenius.
Segundo, atributos inventados. O presente existe no catálogo, mas o modelo “enfeita” a realidade: altera o preço, o tipo de presente (digital vs físico), a disponibilidade de entrega para o país do usuário ou o prazo de validade do certificado, porque assim “faz mais sentido” ou “soa melhor”.
Terceiro, ações alucinatórias. O modelo escreve “eu já comprei este presente e enviei o código para o seu e‑mail, o cartão foi cobrado em $49”, embora o seu backend GiftGenius nem tenha tentado comprar nada e nenhum fluxo ACP/Stripe tenha sido iniciado.
Por fim, há um caso combinado: a ferramenta retornou uma lista vazia (não há presentes para tais filtros e orçamento), e o modelo, para não desapontar o usuário, inventa alguns “exemplos” e não explica que eles não estão no catálogo.
Nossa tarefa é fazer com que, nessas situações, o modelo:
- admita honestamente que não há correspondência exata no catálogo;
- não invente novos presentes nem altere os valores dos campos;
- explique ao usuário o que exatamente aconteceu e proponha um próximo passo claro.
E fazer isso não por meio de “feitiços” em lugares aleatórios, mas através de um contrato encadeado system‑prompt ↔ tools ↔ follow‑ups.
3. Camada 1: reforçando o system‑prompt contra alucinações
Para conter presentes, atributos e ações inventados do trecho anterior, primeiro fortalecemos a camada superior — o system‑prompt: vamos estabelecer a “filosofia” geral de comportamento do modelo no catálogo.
Na primeira aula do módulo, você já escreveu um system‑prompt básico do tipo: “Você é o GiftGenius, ajuda a escolher presentes…” e fixou os limites de responsabilidade do assistente e o trabalho com ferramentas.
Agora vamos adicionar regras explícitas anti‑alucinação.
A lógica é: o system‑prompt define a filosofia geral do comportamento. Ele não conhece os detalhes de cada ferramenta, mas pode:
- proibir inventar presentes / preços / disponibilidade fora do catálogo;
- definir o que fazer se as ferramentas retornarem resultado vazio ou erro;
- exigir uma distinção clara entre dados do catálogo de presentes e quaisquer “conhecimentos gerais do modelo”.
Exemplo de trecho do system‑prompt (constante TypeScript em nosso projeto Next.js, por exemplo config/systemPrompt.ts):
// config/systemPrompt.ts
export const SYSTEM_PROMPT = `
# Papel
Você é o GiftGenius, um assistente para escolher presentes
com base no catálogo de presentes do nosso aplicativo.
# Dados e restrições
- Não invente presentes que não existem no catálogo ou nas respostas das ferramentas.
- Não invente preços, disponibilidade, tipo de presente (digital/físico),
regiões de entrega ou outros atributos.
- Se a ferramenta não retornou os dados necessários ou ocorreu um erro,
fale isso honestamente e não tente adivinhar valores.
# Trabalho com ferramentas
- Sempre use as ferramentas do catálogo de presentes para quaisquer dados factuais:
lista de presentes, preços, tipos, disponibilidade, SKU.
- Se a ferramenta retornou um resultado vazio, diga que, pelas condições atuais,
não há presentes adequados e sugira afrouxar os filtros
(alterar orçamento, categoria, tipo de presente).
`;
Aqui há alguns pontos importantes.
Primeiro, nós separamos “conhecimentos gerais do modelo” e “dados do aplicativo”. O modelo ainda pode explicar a diferença entre um presente digital e um físico ou quais ocasiões são comuns, mas quaisquer presentes, preços e SKUs concretos devem vir somente das ferramentas do GiftGenius.
Segundo, descrevemos explicitamente o que fazer no caso de erros/resultado vazio: não ficar em silêncio, não “criar”, mas dizer honestamente ao usuário que nada foi encontrado e sugerir alterar os parâmetros.
Terceiro, focamos não em um abstrato “não alucine”, mas em tipos de comportamento concretos, atrelados ao nosso domínio (catálogo de presentes e compra de SKUs digitais/físicos).
Essa camada por si só já ajuda bastante, mas pode ser facilmente “sobreposta” por uma descrição descuidada de ferramenta. Vamos às descrições das ferramentas.
4. Camada 2: descrições das ferramentas (tool descriptions) e esquemas como parte formal do contrato
O modelo decide quando e como chamar sua ferramenta, principalmente com base em:
- nome da ferramenta;
- description da ferramenta;
- inputSchema / outputSchema (JSON Schema que descreve os campos).
Ou seja, a descrição da ferramenta (tool description) não é “documentação para humanos”, mas uma parte do prompt, só que formalizada. E muitas alucinações nascem exatamente aqui.
Imaginemos nossa ferramenta recommend_gifts, que o backend implementa como a seleção de presentes do catálogo do GiftGenius.
Uma descrição ruim poderia ser assim:
// RUIM: vago demais
const recommendGiftsTool = {
name: "recommend_gifts",
description: "Seleciona presentes para o usuário",
inputSchema: {
type: "object",
properties: {
profile: { type: "string" }
}
}
};
Formalmente está correto, mas o modelo não entende disso:
- onde estão os limites da ferramenta;
- o que fazer se não forem encontrados presentes;
- que não se pode inventar presentes e preços fora do catálogo.
Uma boa descrição faz várias coisas ao mesmo tempo: define claramente o domínio, explica quando chamar a tool e fixa rigidamente que não é permitido inventar resultados.
Exemplo (adaptado ao contrato do GiftGenius com segments, budget, locale, occasion):
// config/tools.ts
export const recommendGiftsTool = {
name: "recommend_gifts",
description: `
Seleção de presentes no catálogo do GiftGenius.
Use esta ferramenta quando precisar obter uma lista de presentes reais
por segmentos do perfil do presenteado, orçamento, localidade e ocasião.
A ferramenta retorna somente os presentes que realmente existem
no catálogo do GiftGenius.
NÃO invente presentes e seus atributos fora dos resultados desta ferramenta.
Se a ferramenta retornar uma lista vazia, não invente alternativas,
e passe para o diálogo: sugira alterar o orçamento, o tipo de presente,
a ocasião ou outros parâmetros.
`.trim(),
inputSchema: {
type: "object",
properties: {
segments: {
type: "array",
description:
"Segmentos do perfil do presenteado, por exemplo ['tech', 'fitness'].",
items: { type: "string" }
},
budget: {
type: "object",
description: "Faixa de orçamento para o presente.",
properties: {
min: {
type: "number",
description: "Valor mínimo, não negativo.",
minimum: 0
},
max: {
type: "number",
description: "Valor máximo, maior que 0.",
exclusiveMinimum: 0
},
currency: {
type: "string",
description: "Código de moeda com três letras, por exemplo 'USD' ou 'RUB'.",
minLength: 3,
maxLength: 3
}
},
required: ["min", "max", "currency"]
},
locale: {
type: "string",
description:
"Localidade do usuário (formato de idioma/região), por exemplo 'ru-RU' ou 'en-US'.",
minLength: 2
},
occasion: {
type: "string",
description:
"Ocasião para o presente: por exemplo 'birthday', 'anniversary', 'new_year'."
}
},
required: ["segments", "budget", "locale", "occasion"]
}
};
Aqui a descrição faz várias coisas úteis.
Ela diz explicitamente que a ferramenta trabalha apenas com o catálogo de presentes do GiftGenius e que quaisquer presentes e preços concretos devem ser obtidos somente do resultado dela.
Ela explica quando usar a ferramenta: quando é necessária uma lista de presentes concretos segundo os parâmetros do presenteado, e não teoria geral sobre presentes.
Ela define o comportamento em caso de resultado vazio: não inventar, mas passar ao diálogo (o que fixaremos depois nos follow‑ups).
E o inputSchema ajuda o modelo a extrair de forma mais confiável as entidades da solicitação do usuário: segmentos, orçamento, localidade e ocasião. Especificar estrutura e restrições explícitas para os campos (min, max, currency com comprimento fixo) também reduz a probabilidade de combinações estranhas e erros de parsing.
Também dá para adicionar o outro lado — não apenas “quando chamar”, mas quando não chamar. Por exemplo, se o pedido for claramente teórico:
description: `
...
Não use esta ferramenta se o usuário fizer uma pergunta geral
sobre presentes sem pedir a seleção para uma pessoa específica
(por exemplo, "quais são presentes populares para o Ano-Novo em geral").
Nesses casos, responda você mesmo no chat.
`.trim()
Assim você sincroniza a descrição da ferramenta com as regras do system‑prompt sobre solicitações “teóricas” vs “práticas”.
5. Camada 3: follow‑ups como camada de UX e de segurança
Mesmo que o system‑prompt e as descrições das tools estejam perfeitos, a vida não é:
- o backend pode retornar erro;
- o catálogo — lista vazia;
- os resultados — ambíguos ou numerosos demais.
Se não estiver descrito o que dizer após chamar a tool, o modelo improvisará: às vezes bem, às vezes — com fatos inventados.
Na aula 2 você já viu instruções básicas de UX: como o modelo anuncia o início do App, como encerra o fluxo e o que diz “ao final”. Agora vamos adicionar padrões de follow‑ups que reduzem alucinações.
Esses padrões costumam ser descritos diretamente no system‑prompt em um bloco separado, por exemplo “Diálogo após trabalhar com ferramentas”.
Exemplo de trecho:
// continuação do SYSTEM_PROMPT
export const SYSTEM_PROMPT = `
# ... seções anteriores ...
# Diálogo após trabalhar com ferramentas
- Se a ferramenta de seleção de presentes retornou uma lista vazia:
1) diga honestamente que, com os filtros atuais, nenhum presente foi encontrado;
2) proponha ao usuário mudar 1–2 parâmetros-chave
(orçamento, tipo de presente, interesses do presenteado, ocasião).
- Se a ferramenta retornou opções demais:
1) escolha de 3 a 7 das mais relevantes;
2) diga explicitamente pelos quais critérios você as selecionou
(compatibilidade com interesses, dentro do orçamento, avaliação).
- Se ocorreu um erro na ferramenta:
1) não invente dados;
2) diga que ocorreu um erro técnico e proponha
tentar mais tarde ou simplificar a solicitação.
`.trim();
Com isso “gravamos” no modelo exemplos de falas de follow‑up. Ele vai formulá-las com suas palavras, mas com a estrutura definida:
- constatação do fato (vazio / muitos / erro);
- reconhecimento honesto da limitação;
- proposta cuidadosa do próximo passo.
Para o catálogo de presentes isso é crítico: em vez de “tudo certo, aqui vão três presentes” no caso de resultado vazio, o modelo dirá algo como:
«Com suas condições atuais (presente digital sobre espaço até $5 com entrega apenas nos EUA) não há nada no nosso catálogo. Quer que eu aumente o orçamento ou sugira outras categorias?»
E repare: isso já não é código de ferramenta, mas sim instruções no prompt que definem o UX esperado.
6. Ligando tudo: a evolução do nosso GiftGenius
Vamos olhar a mini‑evolução do nosso aplicativo e reduzir gradualmente o nível de alucinações.
Versão inicial: onde tudo quebra
Suponha que tínhamos um system‑prompt bem minimalista:
export const SYSTEM_PROMPT = `
Você é um assistente para escolher presentes.
Ajude o usuário a encontrar ideias adequadas.
`;
A ferramenta estava descrita assim:
export const recommendGiftsTool = {
name: "recommend_gifts",
description: "Seleciona presentes para o usuário",
inputSchema: { type: "object" }
};
Não há instruções de follow‑up.
O que acontecerá na prática:
- se o usuário pedir “presente digital para um amigo gamer até $10” e não houver nada no banco com esses filtros, o modelo pode:
- ou não chamar a tool e inventar presentes do nada;
- ou chamar a tool, obter uma lista vazia, mas não dizer isso e inventar opções;
- se o backend retornar um erro, o modelo pode pressupor que “algo deve existir” e começar a chutar.
Assim nasce a situação clássica: no chat — uma resposta bonita, no banco — nada parecido.
Nova versão do system‑prompt
Vamos reescrever o system‑prompt, considerando as três camadas de proteção. Parte você já viu acima; vamos juntá-lo inteiro:
// config/systemPrompt.ts
export const SYSTEM_PROMPT = `
# Papel
Você é o GiftGenius, um assistente para escolher presentes
com base no catálogo de presentes do nosso aplicativo.
# Zona de responsabilidade
- Sua tarefa é ajudar o usuário a escolher presentes adequados
do catálogo, explicando prós e contras das opções.
- Não prometa a compra efetiva ou o envio do presente —
você apenas ajuda a selecionar e comparar opções.
A compra e a entrega do código/link são realizadas pelo backend após o consentimento explícito do usuário.
# Dados e restrições
- Não invente presentes que não existem no catálogo ou nas respostas das ferramentas.
- Não invente preços, tipo de presente, disponibilidade ou regiões de entrega.
- Se a ferramenta não retornou dados ou ocorreu um erro,
não tente adivinhar — informe isso.
# Trabalho com ferramentas
- Use as ferramentas do catálogo de presentes (por exemplo, profile_to_segments,
recommend_gifts, get_gift) para quaisquer dados factuais
(lista de presentes, preços, tipos, SKU, descrições).
- Responda você mesmo (sem ferramentas) se a pergunta for teórica
e não exigir a seleção de um presente específico.
# Diálogo após trabalhar com ferramentas
- Em caso de resultado vazio: explique honestamente que nada foi encontrado
com as condições atuais e proponha mudar 1–2 parâmetros.
- Se houver muitas opções: escolha de 3 a 7 das mais adequadas
e explique os critérios da seleção.
- Em caso de erro da ferramenta: não invente dados, peça desculpas pela falha
e sugira tentar novamente ou simplificar a solicitação.
`.trim();
Agora o modelo sabe claramente:
- onde ele é consultor de presentes e onde está o “back‑office” (atrás das ferramentas);
- quais dados exatamente não devem ser inventados;
- como se comportar em situações típicas não ideais.
Novo description e esquema para recommend_gifts
Fortalecemos o system prompt; agora vamos aprimorar a tool e montar a versão final da descrição — com base nas ideias da seção 4.
// config/tools.ts
export const recommendGiftsTool = {
name: "recommend_gifts",
description: `
Seleção de presentes no catálogo do GiftGenius.
Use esta ferramenta quando precisar:
- obter uma lista de presentes reais com preços atualizados, tipo
(digital/physical) e tags;
- reduzir a escolha por segmentos de interesse, orçamento, localidade e ocasião.
NÃO USE a ferramenta:
- se o usuário fizer uma pergunta teórica geral sobre presentes
sem um pedido de seleção para uma pessoa específica;
- para inventar presentes que não existem no catálogo.
Se o resultado for vazio, NÃO invente presentes por conta própria,
mas devolva o controle ao diálogo (siga as instruções do system-prompt).
`.trim(),
inputSchema: {
type: "object",
properties: {
segments: {
type: "array",
description:
"Segmentos do perfil do presenteado: por exemplo, 'tech', 'sport', 'books'.",
items: { type: "string" }
},
budget: {
type: "object",
description:
"Faixa de orçamento para o presente na moeda do usuário (min/max).",
properties: {
min: { type: "number", minimum: 0 },
max: { type: "number", exclusiveMinimum: 0 },
currency: {
type: "string",
minLength: 3,
maxLength: 3,
description: "Código de moeda ISO 4217, por exemplo 'USD' ou 'RUB'."
}
},
required: ["min", "max", "currency"]
},
locale: {
type: "string",
description: "Localidade do usuário, por exemplo 'ru-RU' ou 'en-US'."
},
occasion: {
type: "string",
description:
"Ocasião para o presente: 'birthday', 'anniversary', 'new_year' etc."
}
},
required: ["segments", "budget", "locale", "occasion"]
}
};
Há alguns detalhes aqui.
Ligamos explicitamente o comportamento da ferramenta ao system‑prompt: a frase “siga as instruções do system‑prompt” lembrará ao modelo que “resultado vazio = conversa honesta, não criatividade”.
Definimos condições negativas (“não use…”, “não invente…”), o que, na prática, é tão importante quanto descrições positivas.
Tornamos o inputSchema semanticamente rico: descrições e restrições adequadas ajudam o modelo a mapear corretamente as solicitações para os campos e a “errar menos”, antes mesmo de chamar a ferramenta.
Padrões de follow‑up no código do widget e no formato de resposta
Além das instruções textuais, temos outra alavanca — o próprio formato de resposta da ferramenta. Por meio dele também podemos indicar ao modelo o que aconteceu e reduzir o espaço para invenções.
Formalmente, os follow‑ups são definidos por texto no system‑prompt, mas no seu widget Next.js você pode adicionalmente normalizar o ToolOutput para facilitar a vida do modelo e reduzir a margem para fantasia.
Por exemplo, vamos combinar que o backend de recommend_gifts sempre retorna:
// tipo de resposta da ferramenta no backend
export type RecommendGiftsResult = {
items: Array<{
id: string;
title: string;
price: number;
currency: "USD" | "EUR" | "RUB";
tags: ("digital" | "physical" | "education" | "fitness" | "tech")[];
}>;
// campo que o backend preenche para dizer explicitamente ao modelo o que aconteceu
status: "ok" | "empty" | "error";
errorMessage?: string;
};
O widget pode exibir isso de forma elegante, e o modelo — basear-se no status ao formular a resposta. No Apps SDK você frequentemente retorna o ToolOutput ao modelo como um objeto JSON, e ele vê esse campo.
No system‑prompt é possível adicionar um pequeno bloco:
# Interpretação do status da ferramenta
- Se status = "empty": veja a seção "Diálogo após trabalhar com ferramentas" e
não invente presentes.
- Se status = "error": informe o erro técnico e não tente adivinhar
o conteúdo do catálogo.
Sim, o modelo poderia deduzir isso, mas a instrução explícita reduz a chance de “adivinhações”.
7. Prática: aprimorando seu App
Para não ficar a sensação de “bonito no slide”, vamos descrever um exercício concreto que você pode fazer com seu App atual (no nosso caso — GiftGenius). Faremos um pequeno refactor nas três camadas de proteção: system‑prompt, descrições das ferramentas e tratamento dos resultados.
Primeiro, no nível do system‑prompt, pegue seu system‑prompt da primeira aula e encontre o trecho que descreve a zona de responsabilidade e o trabalho com ferramentas. Adicione:
- proibição de inventar entidades fora do catálogo/base (presentes, SKU, preços);
- regras para resultado vazio e erro da ferramenta;
- a seção “Diálogo após trabalhar com ferramentas” com 2–3 cenários (vazio, muitos, erro).
Em segundo lugar, no nível das descrições das tools, abra a descrição da ferramenta principal (no seu caso pode ser recommend_gifts, search_gifts, search_tariffs, calculate_quote, não importa). Reescreva a description de modo que:
- diga explicitamente que a ferramenta trabalha apenas com sua fonte de dados (catálogo de presentes, planos etc.);
- explique quando ela é necessária e quando não é;
- contenha restrições negativas explícitas: “não invente…”, “não use para…”.
Em terceiro lugar, no nível da estrutura de resposta da ferramenta, se a resposta ainda não tiver um campo descrevendo explicitamente o status (status, resultType, hasMore) — adicione-o no tipo no backend e no ToolOutput. Em seguida, no system‑prompt, escreva como o modelo deve interpretar esse status no diálogo.
Por fim, rode alguns pedidos no Dev Mode, inclusive aqueles em que os resultados são seguramente vazios ou limítrofes. Observe se o modelo parou de inventar entidades, e quão honestamente ele relata as limitações ao usuário.
Na próxima aula você vai formalizar tais solicitações em um golden prompt set e transformar isso em um artefato de teste reproduzível, mas por ora é importante que você sinta a diferença na prática.
8. Erros típicos ao combater alucinações por meio de prompts e ferramentas
Erro nº 1: uma frase mágica “não alucine” no system‑prompt.
O desenvolvedor escreve no fim do prompt: “Não invente informações” — e dá a tarefa por encerrada. Na prática, o modelo continua inventando, porque as descrições das ferramentas e os follow‑ups não definem um comportamento alternativo. Sem regras específicas de “o que fazer em vez de inventar” (admitir resultado vazio, propor mudar filtros, relatar o erro), essa frase ajuda muito pouco.
Erro nº 2: contradição entre o system‑prompt e a description da ferramenta.
No system‑prompt você diz: “Não invente presentes que não existem no catálogo”, e na descrição da ferramenta — “Seleciona presentes adequados e, se não encontrar, pode sugerir opções semelhantes a seu critério”. No fim, o modelo oscila entre duas fontes de verdade, e vence, infelizmente, a mais específica (geralmente a description da ferramenta). É preciso que as duas camadas digam a mesma coisa: se opções semelhantes forem aceitáveis, isso também deve ser formalizado (e obrigatoriamente explicar ao usuário que não é uma correspondência exata).
Erro nº 3: descrições de ferramentas vagas demais.
Uma descrição do tipo “Ferramenta que ajuda o usuário a resolver tarefas” dá ao modelo pouquíssima informação sobre os limites da ferramenta. Nesse caso, ele ou não a usará, ou a acionará por qualquer motivo — e depois “complementará” os dados quando a ferramenta retornar pouco ou nada. Uma boa description deve ser discriminativa: dizer claramente o que a ferramenta faz e quando não deve ser chamada.
Erro nº 4: ausência de estratégia para resultados vazios e com erro.
O desenvolvedor cuidadosamente escreve um backend que retorna { items: [], status: "empty" }, mas em lugar nenhum explica ao modelo o que isso significa. Como resultado, o modelo vê um array vazio e decide: “bem, então vou sugerir algo do conhecimento geral”. Falta no system‑prompt uma seção que explique como interpretar esses status e o que dizer ao usuário. E a adição de duas ou três regras claras para resultado vazio/erro costuma aumentar muito a qualidade.
Erro nº 5: tentar “tratar” alucinações apenas no nível do código do widget.
Às vezes dá vontade de jogar tudo para o frontend: “se a lista estiver vazia — mostro um placeholder e não deixo o usuário ver o texto do modelo”. Isso pode suavizar um pouco o UX, mas o modelo em si continua acreditando em entidades inventadas e age assim nas falas seguintes. A abordagem correta é primeiro mudar as instruções (system‑prompt, descrições de ferramentas, follow‑ups) e só depois complementar com proteções na UI.
Erro nº 6: ignorar a influência de metadados e esquemas no comportamento do modelo.
Alguns desenvolvedores veem JSON Schema e descrições de campos como “apenas para formulário e validação”. Na verdade, para o ChatGPT isso é uma parte importante do prompt: com base nessas descrições o modelo entende quais parâmetros precisa extrair da solicitação e como é uma resposta correta. Descrições fracas ou inconsistentes dos campos (description, enum) aumentam a chance de erros e indiretamente provocam alucinações.
Erro nº 7: proibições rígidas demais sem alternativas.
Acontece de o prompt virar uma lista de “não faça isso, não faça aquilo”, mas em lugar nenhum dizer o que fazer em casos difíceis. Por exemplo, proibimos inventar presentes e nos limitamos apenas ao catálogo, mas não falamos nada sobre perguntas teóricas. O resultado é que às vezes o modelo apenas responde “não sei”, embora pudesse explicar de forma útil princípios gerais de escolha de presentes. Procure sempre não apenas proibir, mas também abrir caminhos permitidos: “se não conseguir encontrar um presente no catálogo — diga isso honestamente e proponha como alterar a solicitação” ou “se a pergunta for teórica — responda você mesmo, sem ferramentas”.
GO TO FULL VERSION