Del Prompt al Proceso
Un buen prompt es necesario, pero no es un sistema
De prompt a proceso
Un buen prompt puede resolver una tarea puntual. Un proceso permite repetir esa tarea con calidad, trazabilidad y control.
Esta diferencia aparece cuando una solución con modelos de lenguaje deja de ser una prueba rápida y empieza a formar parte de un producto, una operación interna o una herramienta usada por clientes. En ese punto, el prompt deja de ser el centro del sistema: pasa a ser una pieza dentro de un contrato operativo más amplio.
Un prompt es una instrucción. Un proceso es una forma repetible y observable de convertir entradas en salidas útiles bajo restricciones de calidad, coste, latencia y riesgo.
Diseñar ese proceso exige definir qué entra, qué sale, qué se valida, cómo se gestionan los fallos, cómo se mide la calidad y cuándo debe intervenir una persona. La recomendación práctica es empezar por la arquitectura mínima suficiente. Si una tarea tiene pasos claros, conviene usar un workflow. Si la tarea es abierta, conversacional o exige planificación autónoma, puede tener sentido usar un agente. La complejidad debe añadirse cuando el caso de uso lo justifica.
La unidad de diseño
En sistemas maduros, la instrucción textual sigue siendo importante, pero convive con esquemas, herramientas, políticas de negocio, reglas de escalado, datasets de evaluación, validadores, trazas y versiones comparables del flujo.
La unidad de diseño debería ser el contrato operativo.
Ese contrato responde a preguntas que un prompt aislado no puede resuelver bien: qué información recibe el sistema, qué puede inferir, qué debe citarse o validarse, cuándo debe abstenerse, cuándo debe reintentar y cómo se mide si una ejecución ha sido aceptable.
Un prompt puede producir una buena respuesta en una demo. Un proceso debe sostener muchas ejecuciones con entradas variables, contexto incompleto, cambios de modelo, fallos de herramientas y expectativas de negocio.
Prompt, workflow, pipeline y agente
Conviene fijar algunas definiciones prácticas.
Un prompt es la instrucción y el contexto que se entregan al modelo para producir una salida. Puede incluir mensajes de sistema, ejemplos, variables, contexto recuperado y restricciones de formato.
Un proceso es un flujo ejecutable y repetible que articula uno o varios prompts con lógica de control, herramientas, validaciones, observabilidad y criterios de aceptación.
Un workflow es un proceso con pasos definidos y orden controlado por código o configuración.
Un pipeline es un flujo compuesto de etapas encadenadas.
Un agente es un sistema donde el modelo toma una parte relevante de las decisiones de control: qué herramienta usar, qué paso ejecutar, cuándo continuar y cuándo detenerse.
Aun no existe una taxonomía universal cerrada, distintos proveedores usan términos cercanos con matices distintos. Lo importante es el grado de autonomía, riesgo y control que necesita el caso de uso.
Qué cambia al diseñar para producción
Un prompt ad hoc suele optimizarse para una ejecución. Un proceso de producción se diseña para muchas ejecuciones. Esto cambia varias decisiones.
Primero, cambia la forma de definir el éxito. Que la respuesta parezca buena está bien para pruebas. Hay que establecer criterios observables: formato válido, cobertura de la intención, ausencia de afirmaciones no fundamentadas, latencia aceptable, coste máximo, tasa de escalado, seguridad y cumplimiento de reglas de negocio.
También cambia la forma de versionar. Un prompt que vive como un string perdido en el código o en el historial de un chat es deuda técnica. Debe tener variables, versión, entorno, dataset de prueba y métricas asociadas.
La depuración también mejora cuando el flujo está separado en etapas. Si todo ocurre dentro de una única llamada al modelo, los fallos quedan mezclados: recuperación deficiente, instrucción ambigua, formato inválido, razonamiento pobre, herramienta incorrecta o ausencia de contexto. Separar etapas permite aislar responsabilidades.
Por último, la evaluación deja de ser una impresión subjetiva sobre unos pocos ejemplos y pasa a ser una comparación sistemática entre versiones.
Tres consecuencias operativas
Muchos fallos atribuidos al prompt son fallos de sistema
Cuando una salida es mala, suele intentarse ajustar la redacción del prompt. A veces funciona. En otros casos, el problema está en otro punto del flujo: falta contexto relevante, el output no tiene esquema, la tarea mezcla demasiadas responsabilidades, no hay validación posterior, la herramienta recupera información de baja calidad o no existe una ruta clara cuando falta evidencia.
En esos casos, mejorar el prompt solo aplaza el problema. El sistema necesita separación de responsabilidades, contratos y validadores.
Sin evaluación es imposible mejorar
Una versión puede parecer mejor en tres ejemplos y empeorar en veinte casos reales. Por eso conviene trabajar con datasets representativos, casos límite y métricas comparables.
La evaluación puede combinar tests unitarios para reglas deterministas, evaluación offline con ejemplos curados, comparación entre versiones, revisión humana, jueces LLM para criterios semánticos y monitorización online en producción.
El objetivo inicial es evitar que cada cambio sea una apuesta opaca.
Sin observabilidad es imposible tener una producción segura
Un flujo con modelos de lenguaje necesita trazas, métricas, logs y feedback.
Como mínimo, conviene registrar la entrada recibida, el contexto recuperado, la plantilla usada, el modelo y la versión, las herramientas llamadas, la duración total, los tokens consumidos, las validaciones ejecutadas, los errores, los reintentos y la decisión final: responder, pedir información, degradar o escalar.
Sin esos datos, los fallos se detectan tarde y se corrigen con poca información.
Componentes de un proceso guiado por prompts
Un proceso guiado por prompts suele tener varias capas. Esta tabla resume su función sin convertir el artículo en un manual exhaustivo.
| Capa | Función | Pregunta que resuelve |
|---|---|---|
| Entrada | Define variables, contexto y límites | ¿Qué puede ver el sistema? |
| Contexto recuperado | Aporta evidencia externa o interna | ¿Con qué información trabaja? |
| Instrucción | Define objetivo y restricciones | ¿Qué debe hacer el modelo? |
| Transformaciones | Divide el trabajo en pasos | ¿Cómo se convierte la entrada en salida? |
| Validación | Comprueba forma, contenido y reglas | ¿La salida es aceptable? |
| Gestión de fallos | Decide reintentos, fallback o escalado | ¿Qué ocurre si algo falla? |
| Telemetría | Registra ejecución y métricas | ¿Cómo se depura y mejora? |
El contrato de entrada define lo que el sistema puede ver: mensaje del usuario, idioma, canal, permisos, metadata, contexto recuperado, límites de seguridad, herramientas disponibles y políticas aplicables. Cuanto más explícita sea la entrada, menor será la ambigüedad del flujo.
El contrato de salida separa lo que ve el usuario de lo que consume el sistema. En muchos casos conviene pedir una respuesta visible y un objeto estructurado con campos operativos: intención, confianza, necesidad de revisión humana y siguiente acción. Cuando el proveedor permite salidas estructuradas con JSON Schema, es preferible usar el esquema como contrato formal.
Las transformaciones son los pasos intermedios que acercan la entrada a la salida final. En un sistema de soporte, por ejemplo, el flujo puede normalizar el ticket, clasificar la intención, recuperar políticas relevantes, generar un borrador, validar groundedness, ajustar tono y responder o escalar.
La validación determinista comprueba reglas objetivas: JSON válido, campos requeridos, tipos correctos, enums permitidos, fechas ISO, longitudes máximas, cálculos, catálogos internos y reglas de negocio. En Python, Pydantic encaja bien en esta capa.
La validación semántica revisa criterios que no siempre pueden expresarse con reglas simples: groundedness, relevancia, completitud, tono, seguridad, coherencia, precisión en llamadas a herramientas y cumplimiento de instrucciones. Puede hacerse con revisión humana, jueces LLM, validadores especializados o una combinación.
La gestión de errores define qué ocurre cuando algo falla:
- reintento acotado, cuando el fallo es recuperable;
- degradación, cuando puede entregarse una salida parcial;
- cambio de estrategia, cuando falla una herramienta o recuperación;
- abstención, cuando falta evidencia suficiente;
- escalado humano, cuando el riesgo supera el umbral definido.
La telemetría permite depurar y mejorar: tasa de salida válida, error por etapa, latencia, tiempo hasta primer token, tokens consumidos, coste estimado, tasa de reintento, tasa de escalado, feedback del usuario y regresiones por versión.
Patrones frecuentes
La arquitectura debe seguir la forma de la tarea, las recetas mágicas sirven para las demostraciones pero se quedan cortas en los casos reales.
| Patrón | Cuándo usarlo | Riesgo principal |
|---|---|---|
| Prompt único | Tareas acotadas, baja variabilidad y bajo riesgo | Fragilidad si aumentan las restricciones |
| Prompt chaining | Subtareas fijas y separables | Más latencia y más puntos de fallo |
| Routing | Entradas con categorías claras | Mala clasificación inicial |
| Paralelización | Revisión desde varias perspectivas | Mayor coste y necesidad de agregación |
| Human-in-the-loop | Alto riesgo o acciones irreversibles | Más fricción y latencia |
| Agente con herramientas | Tarea abierta, multi-turn y dinámica | Mayor variabilidad y más necesidad de guardrails |
Una progresión prudente suele ser: prompt único, chaining con validación, flujo con routing, orquestación con herramientas y revisión humana selectiva.
El salto directo a agentes complejos suele aumentar coste, latencia y superficie de fallo. Muchas aplicaciones funcionan mejor con una llamada LLM bien diseñada, buen retrieval, salida estructurada y validaciones claras.
Cómo elegir la arquitectura mínima suficiente
La decisión puede guiarse por cuatro preguntas.
Si la tarea tiene pasos claros, empieza con workflow o chaining. El control explícito será más barato de depurar que una orquestación autónoma.
Si hay categorías de entrada con tratamientos distintos, añade routing. Un flujo de soporte no debería usar la misma instrucción para una duda general, una cancelación, un bug crítico y una solicitud legal.
Si la calidad mejora al separar perspectivas, usa paralelización. Una llamada puede generar la respuesta, otra revisar groundedness, otra revisar estilo y otra decidir si escalar.
Si el conjunto de pasos es impredecible, considera orquestación dinámica o agentes. Esto encaja mejor en tareas multiarchivo, investigación abierta, uso variable de herramientas o conversaciones largas.
Si cualquier error tiene impacto alto, añade validación fuerte y puntos de revisión humana.
Ejemplos de aplicación
En soporte al cliente, el objetivo es generar una respuesta útil, alineada con política y trazable. Un pipeline razonable clasifica el ticket, recupera políticas relevantes, genera un borrador estructurado, valida forma y contenido, y escala los casos sensibles. Los criterios de aceptación deberían incluir JSON válido, intención correctamente clasificada, ausencia de afirmaciones no fundamentadas y revisión humana en reembolsos, cancelaciones o excepciones.
En extracción de datos de documentos, el objetivo es transformar facturas, contratos, formularios o certificados en datos fiables para sistemas downstream. El flujo suele incluir OCR o texto normalizado, extracción estructurada, validación determinista, validación semántica y revisión humana cuando hay campos críticos dudosos. En este caso, los criterios suelen ser estrictos porque un error pequeño puede afectar contabilidad, facturación, cumplimiento o soporte operativo.
En generación de contenido con restricciones de estilo, el objetivo es redactar artículos, posts, newsletters o documentación con voz de marca, límites explícitos y control editorial. El proceso puede generar un borrador, revisar longitud, detectar términos prohibidos, evaluar tono, marcar afirmaciones que requieran verificación y enviar el contenido a revisión humana ligera antes de publicar.
Métricas y validación
Un proceso debe medirse por capas. Nosotros aun no hemos encontrado una métrica única que capture calidad.
Las métricas habituales incluyen validez estructural, correctitud, groundedness, relevancia, precisión en llamadas a herramientas, latencia, tiempo al primer token, uso de tokens, coste por ejecución, tasa de escalado humano y preferencia entre versiones.
Un método razonable combina tests unitarios para funciones deterministas, evaluación offline con datasets curados, comparación pairwise o A/B entre variantes y monitorización online para detectar regresiones, anomalías y casos reales no cubiertos.
Las técnicas de validación también deben combinarse. JSON Schema y Structured Outputs reducen errores de formato. Pydantic integra contratos y validación en Python. Las reglas de negocio cubren fechas, sumas, catálogos y umbrales. Los jueces LLM ayudan con estilo, relevancia y groundedness. La revisión humana sigue siendo necesaria en casos ambiguos, sensibles o de alto impacto.
Herramientas por capa
La selección de herramientas debería seguir la arquitectura del proceso.
Para resultados consumidos por código, usa salidas estructuradas. Para control directo, una orquestación explícita en código suele ser suficiente. Para flujos largos, con estado, herramientas, aprobaciones y reintentos, pueden tener sentido frameworks de agentes o grafos de ejecución.
En un stack Python, Pydantic es una buena base para contratos de entrada y salida. Puede combinarse con validadores semánticos, reglas de negocio y revisión humana selectiva.
Para evaluación, conviene usar herramientas que permitan datasets versionados, comparaciones entre ejecuciones, graders y trazabilidad. Para observabilidad, OpenTelemetry ofrece una base portable sobre la que añadir paneles, feedback de usuario, alertas y evaluación online.
Hoja de ruta hacia producción
Una ruta prudente tiene cuatro etapas:
- Contrato y baseline. Define output útil, riesgo, esquema y primera versión mínima del prompt. El objetivo de esta fase es fijar qué significa una ejecución aceptable.
- Evaluación offline. Construye un dataset pequeño pero representativo. Incluye casos normales, casos límite y ejemplos donde el sistema debería abstenerse o escalar.
- Endurecimiento del flujo. Añade validación estructural, reglas de negocio, rutas de fallback, control de errores y observabilidad. Separa las responsabilidades que estaban concentradas en el prompt inicial.
- Despliegue gradual. Empieza con shadow mode o revisión humana previa. Después compara variantes con pairwise o A/B. Activa monitorización online y usa los fallos reales para alimentar el dataset de evaluación.
Antes de desplegar, conviene tener al menos este checklist básico:
- contrato del caso de uso;
- prompts versionados;
- esquema de salida;
- validación determinista;
- validación semántica;
- dataset de evaluación;
- métricas operativas;
- observabilidad;
- ruta de fallback;
- revisión de riesgos.
Implementación recomendada para un stack Python
Una implementación backend razonable puede apoyarse en:
- modelos Pydantic para entrada y salida;
- orquestación explícita en código;
- llamadas al modelo encapsuladas por etapa;
- validación determinista después de cada output estructurado;
- validación semántica independiente en puntos críticos;
- trazas OpenTelemetry;
- dataset de evaluación versionado;
- tests automatizados en CI;
- revisión humana selectiva para casos de riesgo.
La estrategia de testing debería cubrir transformaciones deterministas, parsers, validadores, reglas de negocio, flujo completo con fixtures controlados, evaluación offline, comparación entre variantes y monitorización online de latencia, coste, tasa de error, escalado y feedback real.
Conclusión
Un prompt bien escrito ayuda, pero un proceso bien diseñado sostiene el producto.
La transición consiste en dejar de tratar la instrucción como una pieza aislada y empezar a diseñar contratos operativos: qué entra, qué sale, qué se valida, qué se mide y qué ocurre cuando algo falla.
El resultado es menos dependencia de la formulación perfecta y más control sobre el comportamiento del sistema. Esa es la diferencia entre una demo prometedora y una solución que puede mantenerse en producción.