Estructura ideal para un GPT: guía práctica para crear agentes que no alucinen

Mini-plan de esta fase: convertir los puntos clave en una narración fluida; integrar tu experiencia real en varias partes sin agruparla en un bloque; cerrar con una verificación breve.
Cuando hablamos de la “estructura ideal para un GPT”, no estamos pensando en un prompt ingenioso, sino en un sistema completo: contexto claro, rol definido, reglas de trabajo, nivel de investigación permitido, criterios de calidad, formato de salida pactado y una verificación final. Si cualquiera de estas piezas falta o se contradice con otra, el agente se desorienta. Todos hemos vivido ese momento chistoso en el que preguntamos algo obvio y el chatbot contesta cualquier otra cosa. En mi caso, la diferencia llegó cuando empecé a fijar el contexto y el rol con precisión y a evitar contradicciones: el margen de error bajó muchísimo y el GPT dejó de “creer” para empezar a trabajar.
LA FÓRMULA GANADORA: Contexto → Rol→ Tarea → Investigación → Criterios → Output → Verificación
El esqueleto que recomiendo sigue esta secuencia. Primero, el contexto: dónde opera el agente, para qué marca y con qué restricciones. Después, el rol: qué es y qué no es, qué decide y qué debe preguntar. Luego, la tarea: un objetivo concreto con métrica clara de éxito. A continuación, el nivel de investigación: rápido o profundo, con o sin navegación y con límites temporales. Siguen los criterios de calidad: cómo evaluaremos precisión, cobertura y estilo. Después, el formato de salida: Markdown, tabla, JSON, longitud y un ejemplo. Por último, la verificación: qué comprueba antes de entregar. En la práctica, vi que si en un sitio pedía brevedad y en otro un tutorial de dos mil palabras, el agente improvisaba; al unificar prioridades y no contradecir las indicaciones, la calidad se disparó.
Plantillas maestras de estructura
Los marcos de prompt ayudan a estandarizar el pedido y la forma de la respuesta. RTF (Rol, Tarea, Formato) y CTF (Contexto, Tarea, Formato) son muy ágiles para peticiones frecuentes y salidas previsibles. Para escenarios complejos, plantillas más completas (como las que explicitan propósito, expectativas y ejemplos) obligan a definir “cómo luce la salida correcta”. Y existe una plantilla muy directa en cuatro claves —Objetivo, Formato de retorno, Avisos y Contexto— especialmente útil cuando queremos razonamiento más profundo y consistencia. El valor real está en los Avisos: pedir que verifique la existencia de entidades, que compruebe fechas con un formato explícito y que reconozca lagunas en lugar de inventar. Desde que añadí esos avisos, la cantidad de correcciones posteriores se redujo de forma notable.
Anti-alucinaciones en la práctica
La prevención de alucinaciones se gana antes de que el modelo empiece a escribir. Si la tarea exige datos concretos, no públicos o muy matizados, el contexto general no basta; hay que darle una base de conocimiento. Ahí es donde RAG (búsqueda aumentada por recuperación) cambia el juego. A mí me funcionó embeber información propia —documentos, políticas internas, catálogos— y conectarla con búsqueda semántica que trae fragmentos relevantes con su cita. También establecí una “política de silencio”: si no encuentra coincidencias por encima de un umbral de confianza, el agente no responde y pide permiso para investigar o solicita más datos. Ese detalle, junto con el reporte de conflictos cuando dos fuentes dicen cosas distintas, reduce muchísimo el riesgo de inventos. Además, pido que haga dos pasadas: una de borrador donde señale huecos, supuestos y dudas, y una segunda entrega ya resuelta. Ese doble ciclo reduce sorpresas cuando el contenido va a producción.
Configuración paso a paso de un GPT/Agente
En mi configuración, el agente arranca con un contexto y un rol que le dan autoridad y límites. Le indico las fuentes preferidas, cuándo debe pedir aclaración y qué no puede hacer (por ejemplo, inventar estadísticas). Le explico la tarea con una métrica concreta de éxito, especifico cómo investigar y hasta qué fecha, establezco criterios de calidad verificables y doy un ejemplo de formato. En integraciones con orquestación (por ejemplo, con n8n y chatbots) me funcionó una cadena simple: recuperar (RAG), componer (con la plantilla elegida), verificar (avisos y controles) y postprocesar (formato acordado y mini-QA). Cuando incluí el permiso explícito para “parar y preguntar” si su confianza caía por debajo de cierto umbral, la estabilidad del sistema mejoró de inmediato.
Errores comunes y cómo arreglarlos
Los fallos típicos se repiten. El primero es dar instrucciones contradictorias o vagas; se arregla priorizando normas y mostrando ejemplos de salida. El segundo es exigir profundidad sin aportar datos; se arregla con RAG o acotando el alcance (“responde solo con lo que esté en la base de conocimiento; si falta, pregunta”). El tercero es no probar antes: pasar de la idea a producción sin una batería de prompts de estrés ni contra-preguntas. Cuando empecé a medir —por ejemplo, número de correcciones por cada mil palabras, porcentaje de respuestas con citas válidas o tiempo hasta la primera respuesta publicable— fue mucho más fácil iterar con criterio.
Checklist final y mini-FAQ
Como rutina diaria, define el contexto en dos o tres frases pensando en el lector y las restricciones de tu marca; otorga al agente un rol con autoridad y límites claros —incluida la frase “si la confianza es baja, pide más datos”—; explica la tarea con una métrica concreta de éxito; especifica cómo investigar y hasta qué fecha; establece criterios de calidad verificables y no adjetivos vacíos; enseña el formato con un ejemplo; y exige verificación: coherencia interna, marcas de supuestos y, cuando proceda, citas o nota de ausencia de fuentes. Si dudas entre solo contexto o contexto + RAG, recuerda que cuando necesitas datos específicos o de negocio, RAG deja de ser un lujo para convertirse en requisito. Si temes encorsetar al agente con el rol, dale autoridad en el dominio, permiso para pedir datos faltantes y prioriza la precisión factual por encima del estilo. No existe una plantilla universal, pero el combo de una estructura tipo RTF/CTF con la plantilla de cuatro claves (Objetivo, Formato, Avisos, Contexto) cubre la gran mayoría de casos reales.
Conclusión
Un GPT fiable nace de una estructura clara y sin contradicciones: contexto y rol bien definidos, tarea con métrica, investigación controlada, criterios de calidad exigentes, formato pactado y verificación final. Cuando la tarea requiere datos concretos, la base de conocimiento y RAG dejan de ser opcionales. Mi experiencia es que, con esa disciplina y la costumbre de iterar en dos pasadas, el agente deja de alucinar y se convierte en una pieza sólida del flujo de trabajo.

