Creación de instrucciones para LLM listas para producción: un marco de siete capas
Aprende un marco estructurado, inspirado en API, con siete capas de instrucciones: indicaciones, contexto, restricciones y más, para crear sistemas LLM fiables de nivel profesional.
21 Días de Ingeniería Avanzada de Prompts
Una guía práctica que te lleva desde los conceptos básicos de los prompts hasta el diseño de sistemas completos de IA.
La mayoría de las personas piensan que un prompt no es más que una pregunta que se le entrega a un LLM.
Por ejemplo:
Classify this customer support ticket.
Y funciona.
Hasta que deja de hacerlo.
Unos pocos inputs pueden devolver exactamente lo que esperabas. Luego llega un caso ligeramente diferente, y de repente el modelo:
- elige la categoría incorrecta,
- fabrica detalles que no estaban en el input,
- devuelve un formato que no solicitaste,
- escribe un párrafo de explicación en lugar de datos estructurados,
- o se comporta de manera inconsistente solo porque cambió la redacción.
Es exactamente aquí donde comienza a ser importante la diferencia entre un prompt probado de forma casual y un prompt diseñado para producción.
En un sistema de producción, un prompt no es simplemente una pregunta.
Funciona como parte del contrato entre tu aplicación y el modelo.
Los desarrolladores ya saben cómo diseñar APIs con límites bien definidos:
Request → Validation → Business Logic → Response
Los sistemas construidos en torno a prompts necesitan esa misma disciplina:
Instructions
↓
Context
↓
Constraints
↓
Task
↓
Examples
↓
Output Contract
↓
Validation
El resto de este texto analiza cada uno de estos componentes por separado y luego los combina en un ejemplo funcional.
1. El problema de “simplemente preguntarle al modelo”
Imagina una función impulsada por IA para una plataforma de soporte al cliente. Cada ticket recibido debe ser dirigido a uno de cuatro categorías:
billing
technical
account
general
Un prompt mínimo podría verse así:
Classify this customer support ticket:
"I was charged twice for my subscription."
Y el modelo podría responder:
Billing
A primera vista parece bien.
Pero tu backend suele necesitar algo más que una sola etiqueta. Probablemente espera algo estructurado, como:
{
"category": "billing",
"priority": "high"
}
Aquí es donde las cosas se complican.
¿Cómo se decide realmente la prioridad?
Considera un ticket que solo dice:
"No puedo iniciar sesión."
¿Eso pertenece a account, o es realmente un problema technical?
¿Qué sucede si un cliente menciona tanto un problema de facturación como uno de inicio de sesión en el mismo mensaje?
¿Qué pasa si la categoría es realmente ambigua?
¿Cuál es el comportamiento de fallback esperado en ese caso?
Ninguna de estas preguntas puede responderse de manera fiable por un modelo cuando la instrucción inicial nunca especifica las reglas.
Este es precisamente el motivo por el cual la creación de prompts para uso en producción comienza con definir una especificación, no pulir la redacción.
2. La anatomía de un prompt de calidad para producción
Un prompt sólido para producción puede desglosarse en siete componentes distintos.
Estas secciones no necesitan aparecer literalmente como encabezados etiquetados dentro del propio texto del prompt.
Lo importante es que entienda la función de cada capa.
Echemos un vistazo a cada una de ellas uno por uno.
3. Instrucciones del sistema: definir el rol y el comportamiento
La primera capa establece el alcance de lo que el modelo debe gestionar.
En el ejemplo del clasificador de tickets:
You are a customer support classification assistant.
Your job is to classify incoming support tickets
according to the provided category definitions.Return only information supported by the ticket.
Do not invent customer information.
Esto es mucho más útil que algo genérico como:
You are an intelligent AI assistant.
¿Por qué importa la diferencia?
Dado que llamar al modelo “asistente de IA inteligente” no define ningún comportamiento concreto.
La versión más específica detalla:
- qué tarea está realizando el modelo
- en qué dominio opera
- qué información puede utilizar
- qué comportamientos están prohibidos
Puede considerar las instrucciones del sistema como el contrato de comportamiento para la interacción.
4. Contexto: Proporcionar al modelo lo que necesita
La siguiente capa suministra toda la información necesaria para completar realmente la tarea.
Por ejemplo:
Available categories:
billing:
Questions about charges, invoices, refunds, or payments.technical:
Problems with product functionality, errors, or system behavior.account:
Login, password, profile, access, or account-management issues.general:
Questions that don't clearly belong to the above categories.
Seguido del contenido real de la solicitud:
Customer ticket:
"I was charged twice for my subscription this month."
Vale la pena señalar explícitamente esta distinción:
Instructions = What to do
Context = Information needed to do it
Si se cambia el contexto manteniendo las instrucciones intactas, el modelo debería seguir siendo capaz de procesar la nueva entrada correctamente.
Tenerlos separados también hace que las plantillas de prompt sean mucho más fáciles de mantener con el tiempo.
5. Restricciones: Indique al modelo dónde detenerse
Las restricciones son la capa donde se elimina la ambigüedad.
Continuando con el ejemplo:
Rules:
1. Select exactly one category.
2. Use only the four categories provided.
3. Do not create new categories.
4. Do not infer facts that are not present.
5. If the issue is unclear, use "general".
6. Priority must be one of: low, medium, high.
7. Return only the requested JSON.
Estas reglas reducen drásticamente el abanico de respuestas posibles.
Sin ellas, un prompt como:
Classify the ticket.
podría generar algo similar a:
This appears to be a billing-related issue because
the customer mentions being charged twice.
Esa es una respuesta perfectamente razonable para un lector humano.
Pero su API probablemente espera JSON limpio, no prosa.
Agregue la restricción de forma explícita:
Return only the requested JSON.
y el comportamiento esperado deja de ser ambiguo.
6. Tarea: Definir la operación exacta
Una vez establecidas las instrucciones y restricciones, es necesario describir con precisión la operación que se espera realice.
Task:
1. Identify the most appropriate category.
2. Determine the priority based on the rules.
3. Provide a short reason.
4. Return the result using the specified JSON structure.
Compárelo con entregar una directiva vaga como esta:
Understand this customer issue.
Cuando una tarea se escribe con tanta precisión, se puede verificar posteriormente si el modelo realmente entregó lo solicitado.
Imagínese un flujo en forma de esto:
Input
↓
Classify
↓
Determine priority
↓
Generate reason
↓
Return JSON
En ese punto, la tarea deja de ser una conjetura y se convierte en algo medible y verificable.
7. Ejemplos: Mostrar el comportamiento deseado
Las instrucciones le dicen al modelo qué hacer en palabras.
Los ejemplos lo demuestran directamente.
Tomemos este:
Example 1
Example 1Input:
"I was charged twice for the same subscription."Output:
{
"category": "billing",
"priority": "medium",
"reason": "The customer reports a duplicate subscription charge."
}
Un segundo ejemplo puede ilustrar un escenario completamente diferente, como un informe de error técnico:
Example 2Input:
"The application crashes every time I upload an image."Output:
{
"category": "technical",
"priority": "high",
"reason": "The customer reports a repeatable application failure."
}
Los ejemplos son especialmente útiles cuando el comportamiento deseado es difícil de definir solo con reglas, ya que permiten al modelo identificar un patrón concreto.
No obstante, hay algo que debe tenerse en cuenta.
Más ejemplos ≠ prompts automáticamente mejores
Acumular ejemplo tras ejemplo conlleva costos reales. Esto aumenta:
- El tamaño del prompt
- El consumo de tokens
- La latencia
- Posibles contradicciones
Una estrategia más inteligente es seleccionar manualmente un conjunto pequeño y bien pensado.
Dé prioridad a los ejemplos que representen situaciones significativamente diferentes, especialmente aquellos ambiguos o de casos extremos.
Un trío como:
Clear billing issue
Clear technical issue
Ambiguous issue
suele ser mejor que diez ejemplos de facturación casi idénticos apilados uno encima del otro.
8. Formato de salida: trátelo como un contrato API
Pocas cosas son tan importantes en una instrucción de nivel profesional como esta capa.
Si algún otro sistema va a analizar lo que devuelve el modelo, no se puede dejar la estructura de esa respuesta al azar en forma de prosa suelta.
En lugar de eso, se debe especificar el esquema claramente.
Por ejemplo:
{
"category": "billing | technical | account | general",
"priority": "low | medium | high",
"reason": "string"
}
Una vez que esto está establecido, el modelo tiene un objetivo fijo al que apuntar, y el código posterior puede basarse en un flujo como este:
LLM
↓
JSON
↓
Parser
↓
Schema validation
↓
Business logic
en lugar de algo mucho más desordenado, como:
LLM
↓
Some paragraph
↓
Regex
↓
Hope it works
Esa segunda configuración es un verdadero infierno para mantenerla viable con el tiempo.
Una salida estructurada y bien especificada establece una frontera clara entre lo que produce el LLM y lo que realmente necesita su aplicación.
9. Validación: El modelo no es tu validador
Aquí hay un error que aparece constantemente en los sistemas impulsados por IA.
Supongamos que el modelo devuelve:
{
"category": "billing",
"priority": "urgent",
"reason": "The customer has a billing issue."
}
Sintácticamente, este JSON está bien.
El problema se encuentra aquí:
"urgent"
“urgent” nunca fue uno de los valores permitidos.
Es tarea de su aplicación detectar esa discrepancia, no de la capa de modelo.
Así es como se hace usando Pydantic:
from pydantic import BaseModel
from typing import Literal
class TicketClassification(BaseModel):
category: Literal[
"billing",
"technical",
"account",
"general"
]
priority: Literal[
"low",
"medium",
"high"
]
reason: str
Luego llamaría a:
result = TicketClassification.model_validate(llm_response)
Y si el modelo devuelve algo como:
{
"category": "billing",
"priority": "urgent",
"reason": "Duplicate charge."
}
el paso de validación debe rechazarlo de inmediato.
Ese rechazo es precisamente el objetivo.
Nunca permita que la salida del modelo pase sin ser verificada.
Esto nos lleva a una regla que vale la pena adoptar siempre que diseñe un sistema basado en LLM:
El LLM genera. Su aplicación valida.
El modelo puede ayudar en las decisiones difíciles, pero cualquier requisito que sea realmente innegociable debe estar incluido en el código de la aplicación determinista que lo aplique directamente.
10. El prompt completo orientado a la producción
Al combinar todas las capas se obtiene algo similar a esto:
SYSTEM
You are a customer support classification assistant.
Your job is to classify incoming support tickets
according to the provided category definitions.
Return only information supported by the ticket.
Do not invent customer information.
CONTEXT
Available categories:
billing:
Charges, invoices, refunds, or payment-related issues.
technical:
Product functionality, errors, crashes, or system behavior.
account:
Login, password, profile, access, or account-management issues.
general:
Issues that do not clearly belong to another category.
Customer ticket:
{{ticket_text}}
CONSTRAINTS
1. Select exactly one category.
2. Use only the categories provided above.
3. Do not create new categories.
4. Do not infer unsupported facts.
5. If the issue is unclear, use "general".
6. Priority must be "low", "medium", or "high".
7. Return only the requested JSON.
TASK
1. Classify the ticket.
2. Determine the priority.
3. Provide a short reason.
4. Return the result in the required JSON format.
EXAMPLE
Input:
"I was charged twice for the same subscription."
Output:
{
"category": "billing",
"priority": "medium",
"reason": "The customer reports a duplicate subscription charge."
}
OUTPUT FORMAT
{
"category": "billing | technical | account | general",
"priority": "low | medium | high",
"reason": "string"
}
Ahora colóquelo junto al punto donde comenzó todo este ejercicio:
Classify this customer support ticket.
La distancia entre estos dos prompts no se refiere realmente al número de palabras.
Lo que cambió es cuán expreso se volvió todo.
Cada bloque de la versión más larga realiza una tarea específica:
- La parte del sistema establece cómo debe actuar el modelo
- La parte del contexto proporciona la información con la que trabaja
- La parte de las restricciones detalla qué reglas no puede violar
- La parte de la tarea define con precisión qué necesita lograr
11. El diseño de prompts es similar al diseño de APIs
Para los ingenieros de software, esta comparación hace que la creación de prompts para entornos de producción resulte casi inmediata.
Imagínese un endpoint REST típico.
Se especificaría algo como:
POST /tickets/classify
Un cuerpo de solicitud:
{
"ticket": "I was charged twice."
}
Y un cuerpo de respuesta:
{
"category": "billing",
"priority": "medium",
"reason": "Duplicate charge reported."
}
Ahora aplique ese mismo razonamiento a un prompt para LLM.
El prompt es, en efecto, la lógica de implementación que se encuentra detrás de ese endpoint.
API
↓
Input
↓
Prompt Template
↓
LLM
↓
Structured Output
↓
Validation
↓
API Response
Esa es la razón por la cual la ingeniería de prompts sigue orientándose hacia ser una disciplina de ingeniería de software en lugar de un ejercicio de habilidades lingüísticas.
No estás buscando la formulación perfecta.
Estás creando una interfaz fiable sobre un sistema que se comporta de manera probabilística.
12. Errores comunes en los prompts de producción
1. Ser vago
Analyze the ticket carefully.
¿Qué se considera “con cuidado” aquí?
Describe con precisión el comportamiento que deseas en lugar de dejarlo a la interpretación.
2. Pedir cosas que no necesitas
Indica que tu aplicación solo consume:
{
"category": "billing"
}
Luego no solicites:
category
reason
summary
sentiment
customer mood
recommended response
next action
a menos que tu aplicación utilice realmente esos campos posteriormente.
Cada campo adicional que solicites es otra posibilidad de que el resultado varíe o sea inconsistente.
3. Colocar toda la lógica de negocio dentro del prompt
Ejemplo de este error:
If the customer has been waiting more than 48 hours,
has contacted support three times, and is a premium customer,
set priority to high...
Reglas como esta suelen pertenecer al código determinista de la aplicación, no en el prompt.
Una división más clara sería:
LLM → classify issue
Application → calculate priority
Separar las cosas de esta manera tiende a hacer que todo el sistema sea mucho más fácil de probar.
4. Cambiar los prompts sin evaluación
Supongamos que la versión 1 funciona bien en producción.
Luego alguien edita:
Classify the ticket.
para convertirlo en:
Analyze and intelligently classify the ticket.
Parece ser un simple cambio de redacción.
No obstante, el comportamiento en producción puede cambiar notablemente.
Este es precisamente el motivo por el cual los prompts merecen control de versiones y evaluación, la misma disciplina que se aplicaría al código de la aplicación.
5. Suponer que el modelo siempre seguirá las instrucciones
Recuerde que los LLM son probabilísticos por naturaleza.
Incluso un prompt cuidadosamente elaborado puede seguir devolviendo algo que no solicitó.
Por eso un sistema de producción real necesita algo más que una buena instrucción: necesita:
Prompt
+
Structured output
+
Validation
+
Monitoring
+
Fallback handling
Depender únicamente de la redacción de la instrucción no es una estrategia segura.
13. La creación de instrucciones para producción requiere evaluación
La principal diferencia entre experimentar casualmente con un LLM y lanzar una función de IA real radica en la evaluación.
Imagínese que tiene 1,000 tickets de soporte históricos.
Puede crear un conjunto de pruebas a partir de ellos, estructurado de la siguiente manera:
200 billing
200 technical
200 account
200 general
100 ambiguous
100 edge cases
Luego prueba diferentes versiones de las instrucciones con ese mismo conjunto y compara los resultados.
Por ejemplo:
Prompt V1 Prompt V2
----------------------------------------
Category accuracy 88% 93%
Schema failures 4% 1%
Invalid values 3% 0.5%
Average latency 1.8s 2.1s
Token usage 650 820
En ese punto, el trabajo con las instrucciones deja de ser subjetivo.
Ya no se pregunta:
"¿Esta instrucción parece mejor?"
En su lugar, se pregunta:
“¿Esta versión obtiene mejores resultados en los casos que realmente son importantes para nuestra aplicación?”
Esa es una pregunta mucho más útil para hacer.
14. El compromiso: más instrucciones vs más complejidad
No existe una regla fija que establezca:
“Un prompt más largo siempre da mejores resultados.”
Los prompts pueden volverse absolutamente sobrediseñados.
Algo como:
30 rules
+
20 examples
+
multiple exceptions
+
long explanations
+
repeated instructions
puede convertirse en una carga de mantenimiento en lugar de ser una ayuda.
Un hábito útil es seguir preguntándose:
¿Esta instrucción aborda realmente un fallo real que he observado?
Si la respuesta es no, probablemente esa instrucción no debería estar allí.
El mejor prompt para producción no es el que contiene más contenido.
Es aquel que proporciona el contexto adecuado, las restricciones correctas y el comportamiento esperado, al mismo tiempo que lleva consigo la menor carga innecesaria posible.
15. Un modelo mental práctico
Cuando te sientas a crear una instrucción, es útil trabajar con siete preguntas guía.
1. ¿Quién es el modelo en este flujo de trabajo?
Instrucciones del sistema
2. ¿Qué necesita saber el modelo?
Contexto
3. ¿Qué no debe hacer bajo ninguna circunstancia?
Restricciones
4. ¿Qué debe lograr exactamente?
Tarea
5. ¿Puedo mostrar el comportamiento esperado?
Ejemplos
6. ¿Cómo debería ser la respuesta?
Formato de salida
7. ¿Cómo sabrá mi aplicación que la respuesta es aceptable?
Validación
Juntas, estas siete preguntas forman un único marco de trabajo.
Este modelo mental vale mucho más que memorizar cualquier plantilla de prompt en particular.
16. La ingeniería de prompts se está orientando hacia el diseño de sistemas
Puede que esta sea la idea más importante de toda esta discusión.
Al principio, trabajar con un LLM suele reducirse a una pregunta como:
How can I phrase this question better?
Cuando los sistemas se vuelven más complejos, esa pregunta cambia por completo:
What does the model need to know?
What should it be allowed to do?
What should it return?
How do I validate it?
What happens when it fails?
How do I evaluate changes?
Ya no se trata de preguntas de redacción, sino de preguntas de ingeniería de software.
Y ese es precisamente el motivo por el cual la ingeniería de prompts de nivel profesional tiene menos que ver con encontrar una frase mágica y mucho más que ver con diseñar una interacción fiable entre tu aplicación y un modelo que se comporta de forma probabilística.
Puntos clave
Hay unas pocas ideas fundamentales que vale la pena llevarse de todo esto:
1. Un prompt listo para producción es más que una sola pregunta.
Especifica el comportamiento, proporciona contexto, establece límites, describe la tarea, ofrece ejemplos y define cómo debe ser el resultado.
2. Mantenga las instrucciones separadas de los datos.
El modelo debe poder distinguir a simple vista qué se le pide que haga y qué información debe utilizar.
3. Las restricciones claras reducen las conjeturas.
No deje que el modelo decida qué hacer cuando los datos faltan, son ambiguos o están mal formados.
4. Los ejemplos existen para ilustrar el comportamiento.
Úselos de manera intencionada, especialmente en casos límite complicados.
5. El resultado estructurado debe manejarse como un contrato de API.
Cada vez que un servicio posterior lea la respuesta del modelo, especifique con exactitud qué formato debe tener dicha respuesta.
6. No permita que el prompt sea su único mecanismo de verificación de seguridad.
La validación real debe realizarse dentro de su aplicación, a través de comprobaciones de esquema y reglas empresariales deterministas.
7. Trate los prompts como código que necesita ser evaluado.
Versiónelos, póngalos a prueba con casos de uso representativos y supervise su rendimiento.
8. Un prompt más largo no es necesariamente mejor.
Cada línea que añada debe justificar su presencia.
Conclusión
Crear un prompt de nivel producción no consiste en hacer que un LLM suene más inteligente.
Se trata de lograr un intercambio más predecible, más transparente y más fácil de integrar en un sistema real.
El cambio generalmente se presenta de esta manera:
Simple question
↓
Structured instructions
↓
Clear context
↓
Explicit constraints
↓
Defined task
↓
Useful examples
↓
Structured output
↓
Application validation
↓
Evaluation + monitoring
Una vez que se comprende este enfoque, la ingeniería de prompts deja de parecerse a un proceso de prueba y error en la creación de textos para convertirse más bien en algo similar a diseñar un contrato API para un componente que se comporta de forma probabilística.
Ese cambio es de gran importancia una vez que se pasa de las demostraciones y se comienza a desarrollar sistemas destinados a funcionar en producción.
Lecturas relacionadas
- Construyendo un agente AI desde cero: Patrones, ReAct y LangGraph — Aprenda los conceptos fundamentales detrás de los agentes AI: planificación, uso de herramientas, reflexión y el patrón ReAct—y cómo LangChain y LangGraph se integran en la creación manual de uno.