1. Introducción
A veces, en cursos de prompt engineering muestran un conjuro mágico:
"No inventes hechos y di 'no lo sé' si no hay información."
Por desgracia (o por suerte), para ChatGPT App esto no funciona como una bala de plata. La razón es simple: el modelo ve no solo tu system‑prompt, sino también:
- la lista de herramientas con sus descripciones y esquemas;
- los resultados de esas herramientas;
- el historial del diálogo, incluidos los follow‑ups anteriores.
Si estas tres capas —system‑prompt, descripciones de herramientas, patrones de follow‑up— se contradicen entre sí o simplemente "cojean", el modelo empieza a comportarse como un junior clásico: aplicado, pero propenso a inventar cosas.
En el curso usamos la idea de una defensa en profundidad contra las alucinaciones:
- nivel 1: reglas globales en el system‑prompt;
- nivel 2: restricciones locales en la definición de cada herramienta;
- nivel 3: gestión de errores, resultados vacíos y follow‑ups.
En esta lección uniremos las tres capas en un contrato único y coherente para nuestra app didáctica GiftGenius.
Insight
En la nueva arquitectura de ChatGPT Apps el campo para el system-prompt ha desaparecido —formalmente ya no existe. Pero esto no significa que debas renunciar a las instrucciones globales para el modelo. Hay un truco: para ChatGPT las descripciones de herramientas son texto de prompt igual que el system clásico. Justo ahí puedes reintroducir un "firmware mental" completo para la aplicación.
Crea una herramienta de servicio, por ejemplo about o about_app. No está pensada para invocaciones frecuentes, pero su description es leída por el modelo en igualdad con las demás herramientas. Por lo tanto, en la descripción puedes incrustar el system-prompt completo. Mejor colócalo después de una breve descripción técnica de la propia herramienta. Al final, el modelo recibe tu system-prompt en limpio al inicio —y lo aplica a todo el diálogo y llamadas a tools.
Para facilitar el mantenimiento, recomiendo añadir al principio del system-prompt una versión explícita, por ejemplo SYSTEM_PROMPT_VERSION: v3. Esto permite encontrar por qué el modelo se comporta de forma diferente: ves al instante con qué conjunto de instrucciones está trabajando. Si en producción aparece un comportamiento extraño, es fácil entender si el error pertenece a la versión antigua del prompt o a la nueva.
Ejemplo:
tool description
### Global assistant behavior for the entire GiftGenius App (ver 3.01)
*(system-level guidelines, not user-facing text)*
system prompt text
2. Qué alucinaciones se producen en ChatGPT App (en el catálogo de regalos como ejemplo)
Para saber cómo curar, conviene nombrar la enfermedad. En el contexto de catálogos (regalos, productos, tarifas) se dan con más frecuencia estos tipos de alucinaciones.
Primero, ítems inventados del catálogo. El usuario pide "un certificado digital de suscripción anual a un servicio concreto" o un regalo muy exótico que no está en tu feed, y el modelo, queriendo ser útil, inventa alegremente "Super Space Flight 3000 — vuelo al espacio", que nunca ha existido en la base de GiftGenius.
Segundo, atributos inventados. El regalo está en el catálogo, pero el modelo "adereza" la realidad: cambia el precio, el tipo de regalo (digital vs físico), la disponibilidad de envío al país del usuario o la validez del certificado, porque "tiene más sentido" o "suena mejor".
Tercero, acciones alucinadas. El modelo escribe "ya compré este regalo y envié el código a tu e‑mail, se han cargado $49", aunque tu backend de GiftGenius ni siquiera intentó comprar nada ni se lanzó ningún flujo de ACP/Stripe.
Por último, hay un caso combinado: la herramienta devolvió una lista vacía (no hay regalos para esos filtros y presupuesto), y el modelo, para no decepcionar al usuario, inventa un par de "opciones aproximadas" sin explicar que no están en el catálogo.
Nuestra tarea es lograr que en estas situaciones el modelo:
- reconozca honestamente que no hay coincidencia exacta en el catálogo;
- no invente nuevos regalos ni cambie valores de campos;
- explique al usuario qué ha pasado exactamente y proponga un siguiente paso claro.
Y hacerlo no a base de "conjuros" en lugares arbitrarios, sino mediante un contrato conectado system‑prompt ↔ tools ↔ follow‑ups.
3. Capa 1: reforzamos el system‑prompt contra alucinaciones
Para frenar los regalos, atributos y acciones inventados del apartado anterior, primero reforzaremos la capa superior —el system‑prompt: daremos al modelo una "filosofía" general de comportamiento en el catálogo.
En la primera lección del módulo ya escribiste un system‑prompt básico tipo: "Eres GiftGenius, ayudas a elegir regalos…" y fijaste los límites de responsabilidad del asistente y el trabajo con herramientas.
Ahora añadiremos reglas anti‑alucinación explícitas.
La lógica es: el system‑prompt establece la filosofía general de comportamiento. No conoce los detalles de cada herramienta, pero sí puede:
- prohibir inventar regalos / precios / disponibilidad fuera del catálogo;
- especificar el comportamiento si las herramientas devolvieron un resultado vacío o un error;
- exigir una distinción explícita entre los datos del catálogo de regalos y cualquier "conocimiento general del modelo".
Ejemplo de fragmento del system‑prompt (constante de TypeScript en nuestro proyecto Next.js, por ejemplo config/systemPrompt.ts):
// config/systemPrompt.ts
export const SYSTEM_PROMPT = `
# Rol
Eres GiftGenius, un asistente para elegir regalos
basado en el catálogo de regalos de nuestra aplicación.
# Datos y restricciones
- No inventes regalos que no estén en el catálogo o en las respuestas de las herramientas.
- No inventes precios, disponibilidad, tipo de regalo (digital/físico),
regiones de envío u otros atributos.
- Si la herramienta no devolvió los datos necesarios o se produjo un error,
dilo con honestidad y no intentes adivinar valores.
# Trabajo con herramientas
- Usa siempre las herramientas del catálogo de regalos para cualquier dato factual:
lista de regalos, precios, tipos, disponibilidad, SKU.
- Si la herramienta devolvió un resultado vacío, di que con las condiciones actuales
no hay regalos adecuados y propone relajar los filtros
(cambiar presupuesto, categoría, tipo de regalo).
`;
Aquí hay varios puntos importantes.
Primero, separamos el "conocimiento general del modelo" de los "datos de la aplicación". El modelo aún puede explicar en qué se diferencia un regalo digital de uno físico o qué ocasiones son comunes, pero cualquier regalo concreto, precio y SKU deben provenir solo de las herramientas de GiftGenius.
Segundo, describimos explícitamente qué hacer ante errores/resultados vacíos: no callar, no "ponerse creativo", sino contar con honestidad al usuario que no se ha encontrado nada y proponer cambiar parámetros.
Tercero, nos centramos no en un abstracto "no alucines", sino en comportamientos concretos vinculados a nuestro dominio (catálogo de regalos y compra de SKU digitales/físicos).
Esta capa por sí sola ya ayuda mucho, pero puede "verse anulada" por una descripción descuidada de la herramienta. Pasemos a las descripciones de herramientas.
4. Capa 2: descripciones de herramientas (tool descriptions) y esquemas como parte formal del contrato
El modelo decide cuándo y cómo llamar a tu herramienta principalmente por:
- el nombre de la herramienta;
- la description de la herramienta;
- inputSchema / outputSchema (JSON Schema que describe los campos).
Es decir, la descripción de la herramienta (tool description) no es documentación "para humanos", sino otra parte del prompt, solo que formalizada. Y muchas alucinaciones nacen justo aquí.
Imaginemos nuestra herramienta recommend_gifts, que el backend implementa como selección de regalos del catálogo de GiftGenius.
Una mala descripción podría ser así:
// MAL: demasiado impreciso
const recommendGiftsTool = {
name: "recommend_gifts",
description: "Selecciona regalos para el usuario",
inputSchema: {
type: "object",
properties: {
profile: { type: "string" }
}
}
};
Formalmente todo es correcto, pero el modelo no entiende a partir de esto:
- dónde están los límites de la herramienta;
- qué hacer si no se encuentran regalos;
- que no puede inventar regalos y precios fuera del catálogo.
Una buena descripción hace varias cosas a la vez: fija claramente el dominio, explica cuándo invocar la herramienta y deja claro que no se pueden inventar resultados.
Ejemplo (adaptado al contrato de GiftGenius con segments, budget, locale, occasion):
// config/tools.ts
export const recommendGiftsTool = {
name: "recommend_gifts",
description: `
Selección de regalos en el catálogo de GiftGenius.
Usa esta herramienta cuando necesites obtener una lista de regalos reales
por segmentos del perfil del destinatario, presupuesto, locale y ocasión.
La herramienta devuelve solo los regalos que realmente existen
en el catálogo de GiftGenius.
NO inventes regalos ni sus atributos fuera de los resultados de esta herramienta.
Si la herramienta devolvió una lista vacía, no inventes alternativas,
sino pasa al diálogo: propone cambiar el presupuesto, el tipo de regalo,
la ocasión u otros parámetros.
`.trim(),
inputSchema: {
type: "object",
properties: {
segments: {
type: "array",
description:
"Segmentos del perfil del destinatario, por ejemplo ['tech', 'fitness'].",
items: { type: "string" }
},
budget: {
type: "object",
description: "Rango de presupuesto para el regalo.",
properties: {
min: {
type: "number",
description: "Importe mínimo, no negativo.",
minimum: 0
},
max: {
type: "number",
description: "Importe máximo, mayor que 0.",
exclusiveMinimum: 0
},
currency: {
type: "string",
description: "Código de moneda de tres letras, por ejemplo 'USD' o 'RUB'.",
minLength: 3,
maxLength: 3
}
},
required: ["min", "max", "currency"]
},
locale: {
type: "string",
description:
"Locale del usuario (formato lengua/región), por ejemplo 'ru-RU' o 'en-US'.",
minLength: 2
},
occasion: {
type: "string",
description:
"Ocasión para el regalo: por ejemplo 'birthday', 'anniversary', 'new_year'."
}
},
required: ["segments", "budget", "locale", "occasion"]
}
};
Aquí la description hace varias cosas útiles.
Dice explícitamente que la herramienta solo trabaja con el catálogo de regalos de GiftGenius y que cualquier regalo concreto y precio deben tomarse únicamente de su resultado.
Explica cuándo usar la herramienta: cuando hace falta una lista concreta de regalos según los parámetros del destinatario, y no teoría general sobre regalos.
Fija el comportamiento ante un resultado vacío: no inventar, sino pasar al diálogo (lo que luego fijaremos en los follow‑ups).
Y el inputSchema ayuda al modelo a extraer con más fiabilidad las entidades de la petición del usuario: segmentos, presupuesto, locale y ocasión. Indicar estructura explícita y restricciones para los campos (min, max, currency con longitud fija) también reduce la probabilidad de combinaciones extrañas y errores de parsing.
También puedes añadir la cara opuesta —no solo "cuándo invocar", sino cuándo no invocar. Por ejemplo, si la petición es claramente teórica:
description: `
...
No uses esta herramienta si el usuario hace una pregunta general
sobre regalos sin pedir selección para una persona concreta
(por ejemplo, "qué regalos populares hay para Año Nuevo en general").
En esos casos, responde tú mismo en el chat.
`.trim()
Así sincronizas la descripción de la herramienta con las reglas del system‑prompt sobre peticiones "teóricas" vs "prácticas".
5. Capa 3: los follow‑ups como capa de UX y de seguridad
Incluso si el system‑prompt y las descripciones de las herramientas están perfectas, la vida no lo está:
- el backend puede devolver un error;
- el catálogo, una lista vacía;
- los resultados, ser ambiguos o demasiado numerosos.
Si no se especifica qué decir tras llamar a la herramienta, el modelo improvisará: a veces bien, a veces con hechos inventados.
En la lección 2 ya viste instrucciones básicas de UX: cómo el modelo anuncia el arranque de la App, cómo cierra el escenario y qué le dice al usuario "al final". Ahora añadiremos patrones de follow‑ups que reducen las alucinaciones.
Estos patrones suelen describirse directamente en el system‑prompt en un bloque aparte, por ejemplo "Diálogo tras trabajar con herramientas".
Fragmento de ejemplo:
// continuación de SYSTEM_PROMPT
export const SYSTEM_PROMPT = `
# ... secciones anteriores ...
# Diálogo tras trabajar con herramientas
- Si la herramienta de selección de regalos devolvió una lista vacía:
1) di con honestidad que con los filtros actuales no se han encontrado regalos adecuados;
2) propone al usuario cambiar 1–2 parámetros clave
(presupuesto, tipo de regalo, intereses del destinatario, ocasión).
- Si la herramienta devolvió demasiadas opciones:
1) elige las 3–7 más relevantes;
2) di explícitamente con qué criterios las has seleccionado
(coincidencia por intereses, encaje en el presupuesto, valoración).
- Si se produjo un error en la herramienta:
1) no inventes datos;
2) di que hubo un error técnico y propone
intentarlo más tarde o simplificar la petición.
`.trim();
Así "grabamos" en el modelo réplicas de follow‑up aproximadas. Las formulará con sus propias palabras, pero con la estructura indicada:
- constatación del hecho (vacío / demasiado / error);
- reconocimiento honesto de la limitación;
- propuesta cuidadosa del siguiente paso.
Para el catálogo de regalos esto es crucial: en lugar de "todo ok, aquí van tres regalos" en caso de resultado vacío, el modelo dirá algo como:
"Con tus condiciones actuales (regalo digital sobre el espacio por hasta $5 con envío solo a EE. UU.) no hay nada en nuestro catálogo. ¿Quieres que amplíe el presupuesto o te proponga otras categorías?"
Y fíjate: esto ya no es código de herramienta, sino instrucciones en el prompt que marcan el UX esperado.
6. Lo unimos todo: la evolución de nuestro GiftGenius
Veamos una mini‑evolución de nuestra aplicación y reduzcamos gradualmente el nivel de alucinaciones.
Versión inicial: donde todo se rompe
Supongamos que teníamos un system‑prompt muy minimalista:
export const SYSTEM_PROMPT = `
Eres un asistente para elegir regalos.
Ayuda al usuario a encontrar ideas adecuadas.
`;
La herramienta estaba descrita así:
export const recommendGiftsTool = {
name: "recommend_gifts",
description: "Selecciona regalos para el usuario",
inputSchema: { type: "object" }
};
No hay instrucciones de follow‑up.
Qué ocurrirá en la práctica:
- si el usuario pide "un regalo digital para un amigo gamer por hasta $10" y en la base no hay nada para esos filtros, el modelo puede:
- o bien no llamar a la herramienta e inventar regalos de la nada;
- o bien llamar a la herramienta, obtener una lista vacía, no decirlo e inventar opciones;
- si el backend devuelve un error, el modelo puede dar por hecho que "algo debería haber" y empezar a adivinar.
Así nace la situación clásica: en el chat —una respuesta bonita; en la base— nada parecido.
Nueva versión del system‑prompt
Reescribamos el system‑prompt teniendo en cuenta las tres capas de defensa. Ya viste parte arriba, juntemos todo:
// config/systemPrompt.ts
export const SYSTEM_PROMPT = `
# Rol
Eres GiftGenius, un asistente para elegir regalos
basado en el catálogo de regalos de nuestra aplicación.
# Zona de responsabilidad
- Tu tarea es ayudar al usuario a elegir regalos adecuados
del catálogo, explicando pros y contras de las opciones.
- No hagas promesas sobre la compra o el envío de un regalo —
solo ayudas a seleccionar y comparar opciones.
La compra y la entrega del código/enlace las realiza el backend tras el consentimiento explícito del usuario.
# Datos y restricciones
- No inventes regalos que no estén en el catálogo o en las respuestas de las herramientas.
- No inventes precios, tipo de regalo, disponibilidad o regiones de envío.
- Si la herramienta no devolvió datos o se produjo un error,
no intentes adivinar: infórmalo.
# Trabajo con herramientas
- Usa las herramientas del catálogo de regalos (por ejemplo, profile_to_segments,
recommend_gifts, get_gift) para cualquier dato factual
(lista de regalos, precios, tipos, SKU, descripciones).
- Responde tú mismo (sin herramientas) si la pregunta es teórica
y no requiere seleccionar un regalo concreto.
# Diálogo tras trabajar con herramientas
- Si el resultado está vacío: explica honestamente que no se ha encontrado nada
con las condiciones actuales y propone cambiar 1–2 parámetros.
- Si hay muchas opciones: elige las 3–7 más adecuadas
y explica los criterios de selección.
- Si hay un error de la herramienta: no inventes datos, pide disculpas por el fallo
y propone intentarlo de nuevo o simplificar la petición.
`.trim();
Ahora el modelo sabe con claridad:
- dónde es consultor de regalos y dónde está el "back office" (tras las herramientas);
- qué datos exactamente no puede inventar;
- cómo comportarse en casos típicos no ideales.
Nueva description y esquema para recommend_gifts
Hemos reforzado el system‑prompt, ahora afinemos la herramienta y armemos la versión final de su descripción —basada en las ideas del apartado 4.
// config/tools.ts
export const recommendGiftsTool = {
name: "recommend_gifts",
description: `
Selección de regalos en el catálogo de GiftGenius.
Usa esta herramienta cuando necesites:
- obtener una lista de regalos reales con precios actuales, tipo
(digital/physical) y etiquetas;
- acotar por segmentos de intereses, presupuesto, locale y ocasión.
NO USES la herramienta:
- si el usuario hace una pregunta teórica general sobre regalos
sin pedir selección para una persona concreta;
- para inventar regalos que no están en el catálogo.
Si el resultado está vacío, NO inventes regalos por tu cuenta,
sino devuelve el control al diálogo (sigue las instrucciones del system-prompt).
`.trim(),
inputSchema: {
type: "object",
properties: {
segments: {
type: "array",
description:
"Segmentos del perfil del destinatario: por ejemplo, 'tech', 'sport', 'books'.",
items: { type: "string" }
},
budget: {
type: "object",
description:
"Rango de presupuesto del regalo en la moneda del usuario (min/max).",
properties: {
min: { type: "number", minimum: 0 },
max: { type: "number", exclusiveMinimum: 0 },
currency: {
type: "string",
minLength: 3,
maxLength: 3,
description: "Código de moneda ISO 4217, por ejemplo 'USD' o 'RUB'."
}
},
required: ["min", "max", "currency"]
},
locale: {
type: "string",
description: "Locale del usuario, por ejemplo 'ru-RU' o 'en-US'."
},
occasion: {
type: "string",
description:
"Ocasión para el regalo: 'birthday', 'anniversary', 'new_year', etc."
}
},
required: ["segments", "budget", "locale", "occasion"]
}
};
Aquí hay varios matices.
Vinculamos explícitamente el comportamiento de la herramienta con el system‑prompt: la frase "sigue las instrucciones del system‑prompt" recordará al modelo que "resultado vacío = conversación honesta, no creatividad".
Establecemos condiciones negativas ("no uses…", "no inventes…"), que en la práctica son tan importantes como las descripciones positivas.
Hacemos el inputSchema semánticamente rico: descripciones y restricciones adecuadas ayudan al modelo a mapear correctamente las peticiones a campos y a "equivocarse" menos incluso antes de invocar la herramienta.
Patrones de follow‑up en el código del widget y en el formato de respuesta
Además de las instrucciones de texto, tenemos otra palanca: el propio formato de respuesta de la herramienta. A través de él también podemos indicar al modelo qué ha pasado y reducir el margen para la fantasía.
Formalmente los follow‑ups se definen en el system‑prompt, pero en tu widget de Next.js puedes además normalizar el ToolOutput para simplificar la vida del modelo y reducir el espacio para las invenciones.
Por ejemplo, acordemos que el backend para recommend_gifts siempre devuelve:
// tipo de respuesta de la herramienta en el backend
export type RecommendGiftsResult = {
items: Array<{
id: string;
title: string;
price: number;
currency: "USD" | "EUR" | "RUB";
tags: ("digital" | "physical" | "education" | "fitness" | "tech")[];
}>;
// campo que rellena el backend para decir explícitamente al modelo qué ha ocurrido
status: "ok" | "empty" | "error";
errorMessage?: string;
};
El widget puede mostrar esto de forma agradable, y el modelo apoyarse en el status al formar la respuesta. En Apps SDK a menudo devuelves el ToolOutput al modelo como un objeto JSON, y este ve ese campo.
En el system‑prompt puedes añadir un pequeño bloque:
# Interpretación del estado de la herramienta
- Si status = "empty": consulta la sección "Diálogo tras trabajar con herramientas" y
no inventes regalos.
- Si status = "error": informa del error técnico y no intentes adivinar
el contenido del catálogo.
Sí, el modelo podría intuirlo sin esto, pero la instrucción explícita reduce la probabilidad de "adivinanzas" basadas en conjeturas.
7. Práctica: mejora tu App
Para que no parezca "bonito en diapositivas", describamos un ejercicio concreto que puedes hacer con tu App actual (en nuestro caso, GiftGenius). Haremos un pequeño refactor en las tres capas de defensa: system‑prompt, descripciones de herramientas y procesamiento de resultados.
Primero, a nivel de system‑prompt, toma tu system‑prompt de la primera lección y encuentra el lugar donde se describe la zona de responsabilidad y el trabajo con herramientas. Añade:
- una prohibición de inventar entidades fuera del catálogo/base (regalos, SKU, precios);
- reglas para casos de resultado vacío y error de la herramienta;
- una sección "Diálogo tras trabajar con herramientas" con 2–3 escenarios (vacío, demasiados, error).
Segundo, a nivel de descripciones de herramientas, abre la descripción de la herramienta clave (en tu caso podría ser recommend_gifts, search_gifts, search_tariffs, calculate_quote, lo que sea). Reescribe la description para que:
- diga explícitamente que la herramienta funciona solo con tu fuente de datos (catálogo de regalos, tarifas, etc.);
- explique cuándo se necesita y cuándo no;
- incluya restricciones negativas explícitas: "no inventes…", "no lo uses para…".
Tercero, a nivel de la estructura de respuesta de la herramienta, si la respuesta aún no tiene un campo que describa explícitamente el estado (status, resultType, hasMore) —añádelo en el tipo del backend y en el ToolOutput. Luego, en el system‑prompt escribe cómo debe interpretar el modelo ese estado en el diálogo.
Por último, prueba un par de peticiones en Dev Mode, incluidas aquellas cuyo resultado sabes que es vacío o límite. Fíjate en si el modelo ha dejado de inventar entidades y en qué medida cuenta con honestidad al usuario las limitaciones.
En la siguiente lección formalizarás tales peticiones en el denominado golden prompt set y lo convertirás en un artefacto de pruebas repetible, pero por ahora nos importa que sientas la diferencia de primera mano.
8. Errores típicos al combatir alucinaciones mediante prompts y herramientas
Error n.º 1: una frase mágica "no alucines" en el system‑prompt.
El desarrollador escribe al final del prompt: "No inventes información" y da la tarea por resuelta. En la práctica el modelo sigue inventando, porque las descripciones de las herramientas y los follow‑ups no le dan un comportamiento alternativo. Sin reglas concretas de "qué hacer en lugar de inventar" (reconocer un resultado vacío, proponer cambiar filtros, informar del error) esa frase ayuda muy poco.
Error n.º 2: contradicción entre el system‑prompt y la description de la herramienta.
En el system‑prompt dices: "No inventes regalos que no estén en el catálogo", y en la descripción de la herramienta: "Selecciona regalos adecuados, y si no encuentra —puede proponer opciones similares a su criterio". El modelo, en consecuencia, oscila entre dos fuentes de verdad, y gana, por desgracia, la más concreta (normalmente la description de la herramienta). Hay que conseguir que ambas capas digan lo mismo: si las opciones similares son admisibles, también hay que formalizarlo (y explicar al usuario que no es una coincidencia exacta).
Error n.º 3: descripciones de herramientas demasiado vagas.
Una descripción tipo "Herramienta que ayuda al usuario a resolver tareas" no le da al modelo casi ninguna información sobre los límites de la herramienta. En tal caso, o no la usará, o la invocará por cualquier cosa —y luego "completará" datos cuando la herramienta devuelva poco o nada. Una buena description debe ser discriminativa: decir explícitamente qué hace la herramienta y cuándo no debe invocarse.
Error n.º 4: ausencia de estrategia para resultados vacíos y erróneos.
El desarrollador prepara con esmero un backend que devuelve { items: [], status: "empty" }, pero en ninguna parte explica al modelo qué significa eso. Como resultado, el modelo ve un array vacío y decide: "bueno, supongo que debo proponer algo de conocimiento general". En el system‑prompt falta una sección que explique cómo interpretar esos estados y qué decir al usuario. Añadir un par de reglas claras para resultados vacíos/erróneos da un enorme salto de calidad.
Error n.º 5: intentar "curar" las alucinaciones solo a nivel del código del widget.
A veces apetece cargarlo todo al frontend: "si la lista está vacía —mostraré un placeholder y no dejaré que el usuario vea la respuesta textual del modelo". Esto puede suavizar un poco el UX, pero el modelo seguirá creyendo en entidades inventadas y comportándose igual en los turnos posteriores. El enfoque correcto es cambiar primero las instrucciones (system‑prompt, descripciones de herramientas, follow‑ups) y ya luego complementar con defensas en la UI.
Error n.º 6: ignorar la influencia de metadatos y esquemas en el comportamiento del modelo.
Algunos desarrolladores ven JSON Schema y descripciones de campos como "solo para formularios y validación". En realidad, para ChatGPT es una parte importante del prompt: por estas descripciones el modelo entiende qué parámetros debe extraer de la petición y cómo luce una respuesta correcta. Descripciones de campos débiles o incongruentes (description, enum) aumentan la probabilidad de errores y, de forma indirecta, fomentan alucinaciones.
Error n.º 7: prohibiciones demasiado rígidas sin alternativas.
A veces el prompt se convierte en una lista de "no hagas esto, no hagas aquello", pero no se dice qué hacer en casos complejos. Por ejemplo, prohibimos inventar regalos y nos limitamos solo al catálogo, pero no dijimos nada sobre preguntas teóricas. Como resultado, a veces el modelo responde "no lo sé", aunque podría explicar útiles principios generales para elegir regalos. Intenta siempre no solo prohibir, sino abrir vías permitidas: "si no puedes encontrar un regalo en el catálogo —dilo honestamente y propone cómo cambiar la petición" o "si la petición es teórica —responde tú mismo, sin herramientas".
GO TO FULL VERSION