Ejecución
Cada fase recibe las entradas previstas, respeta su contrato y deja un estado coherente tanto si termina como si falla.
Ingeniería de IA aplicada · Conocimiento y contenidos
Sistema de automatización editorial con IA
He diseñado e implementado una aplicación que convierte propósitos, fuentes y criterios de revisión en procesos versionados que avanzan por fases controladas.
Los modelos ejecutan tareas delimitadas. La aplicación prepara el contexto, guarda el estado, coordina las dependencias y registra las comprobaciones que deciden si un resultado puede avanzar.
- Orquestación de modelos y herramientas
- Estado, colas y versionado
- Contratos y validaciones
- Trazabilidad y control humano
El sistema de un vistazo
Qué entra, qué lo mueve, qué lo frena y qué sale
- 01
Entrada
Propósito, alcance, fuentes, restricciones y los criterios con los que se va a revisar el resultado.
- 02
Ejecución
Fases coordinadas por procesadores, con modelos y herramientas a los que doy tareas delimitadas.
- 03
Control
Estado persistente, versiones, contratos de salida, evaluaciones y las decisiones que reservo para una persona.
- 04
Salida
Artefactos estructurados y revisables, con el historial que hace falta para reconstruir cómo se produjeron.
El problema
El reto no era generar texto, sino gobernar el proceso.
Lo que faltaba no era más texto: era saber qué se había comprobado y sobre qué versión.
Un proceso puede ejecutar todos sus pasos, guardar sus informes y salir en verde mientras el texto contiene una afirmación que ninguna fuente sostiene o el informe pertenece a un borrador anterior. Por eso la capa que construí no genera: coordina, guarda el estado y decide qué puede avanzar.
Decisión principal
El modelo ejecuta tareas; la aplicación gobierna el proceso.
El modelo no lleva el proceso ni custodia el estado. Recibe una tarea delimitada, trabaja con el contexto que le corresponde y devuelve un resultado sujeto a un contrato. La aplicación es la que sabe en qué fase va cada trabajo, qué dependencias se han cumplido y qué validaciones faltan; los resultados se registran fuera del modelo. Esa separación es la que me permite cambiar las instrucciones, el modelo o el proveedor sin rehacer el sistema entero, y la que evita que una respuesta convincente se cuele como si fuera una comprobación.
Criterios de diseño
- 01
Construyo el contexto de cada fase en lugar de arrastrar la conversación entera: escojo el material que esa tarea necesita, lo estructuro y lo dejo atado al trabajo al que pertenece.
- 02
Guardo el estado en la aplicación, no en el modelo. Los trabajos, las versiones y los resultados se conservan en la base de datos, y una cola se lleva las tareas largas para que la interfaz no dependa de lo que tarde una respuesta.
- 03
Reservo el modelo para lo que exige interpretar. Lo que se puede comprobar de forma exacta —un esquema, un enlace, un identificador— lo resuelvo con código: gastar capacidad probabilística en eso cuesta más y falla peor.
Funciones
Qué permite hacer
Seis funciones, cada una con lo que deja garantizado cuando termina. Ninguna depende de que lo que se publique sea un artículo.
- 01
Gestionar trabajos y fases
Cada pieza se registra como un trabajo independiente con su propósito, sus fuentes, su configuración, la fase en que está y los resultados que ha producido.
Estado consultable - 02
Preparar el contexto de cada operación
Selecciono y estructuro la información que necesita cada fase. No arrastro el historial entero ni doy por hecho que el modelo recuerde una decisión anterior.
Contexto acotado - 03
Ejecutar fuera de la petición
Lo que puede tardar se envía a una cola, se procesa aparte y conserva su estado, sus errores y sus reintentos aunque nadie esté mirando.
Proceso asíncrono - 04
Conservar versiones y evaluaciones
Cada cambio produce una versión identificable, y los informes y las aprobaciones quedan atados al contenido concreto sobre el que se ejecutaron.
Revisión con versión - 05
Validar antes de avanzar
Las salidas pasan por contratos, reglas deterministas, evaluaciones asistidas por modelos o revisión humana, según lo que haya que decidir.
Avance condicionado - 06
Reconstruir una ejecución
Relaciono el trabajo, el modelo, la versión de las instrucciones, el contexto preparado, la respuesta, la duración y los errores que se produjeron.
Traza completa
Recorrido
Flujo de un trabajo
Recorrido completo, desde que se crea el trabajo hasta la salida. Lo que no cuenta un diagrama de flechas hacia delante es el paso de vuelta: la evaluación devuelve el trabajo atrás, y eso invalida comprobaciones que ya estaban hechas.
- 1
Crear trabajo
Fijo el objetivo, el alcance, las restricciones y con qué criterios se va a revisar.
- 2
Incorporar fuentes
Vinculo los documentos y referencias que podrán usar las distintas fases.
- 3
Preparar contexto
La aplicación compone la entrada concreta de cada operación.
- 4
Ejecutar fases
Los procesadores coordinan modelos y herramientas, y conservan los resultados intermedios.
- 5
Evaluar y revisar
Se ejecutan los controles y entro yo cuando la decisión exige criterio.
- 6
Preparar salida
Lo aceptado se exporta con sus metadatos, sus versiones y sus evidencias.
Corrección, nueva versión y repetición de las comprobaciones afectadas
Arquitectura
Cómo está montado
La aplicación es la que manda. El modelo entra como una dependencia con límites y contrato, igual que la base de datos o la cola.
Interfaz
Donde se crean los trabajos, se consultan las fases y se aprueba o se devuelve un resultado.
API de la aplicación
El único sitio donde se decide qué se puede pedir, con qué permisos y en qué orden.
Orquestador
Sabe en qué fase está cada trabajo, qué dependencias se han cumplido y qué falta por validar antes de dejarlo avanzar.
Lo que coordina el orquestador
- Almacén del estadoBase de datos relacional con los trabajos, las versiones, los informes y las aprobaciones. El estado oficial vive aquí, no en una conversación.
- Cola de tareasLo que tarda sale de la petición y conserva sus reintentos y sus fallos.
- ProcesadoresEjecutan cada fase con una entrada definida y devuelven un resultado identificable.
- Modelos y herramientasTareas delimitadas y salidas sujetas a contrato. Intercambiables sin rehacer el proceso.
- TrazasModelo, versión de las instrucciones, contexto, respuesta, duración y error de cada ejecución.
- Revisión humanaLos puntos donde el sistema se detiene porque la decisión no es suya.
Cuatro planos de validación
Una salida convincente no valida nada.
Ninguno sustituye a otro. Un sistema puede ejecutar bien y producir peor, o acertar y costar demasiado.
Calidad
Los cambios de modelo, instrucciones o contexto se comparan sobre un conjunto estable de casos. Sin él no distingo una mejora de una ejecución afortunada.
Operación
Duración, consumo, errores, reintentos y coste por fase. Es donde se ve si el sistema aguanta el ritmo al que se le pide.
Intervención humana
Cuánto trabajo sigue necesitando una persona, en qué fases entra y qué tipo de defecto llega hasta ella sin haberse detectado antes.
Estado
Qué hay construido y qué no
Sin una medición que pueda repetirse, un porcentaje de cobertura sería un número inventado. Estos tres estados dicen más y no afirman nada que no pueda sostener.
Construido
- Aplicación y procesadores de trabajos
- Trabajos y versiones persistidos fuera del modelo
- Cola para las tareas de larga duración
- Registro de llamadas, resultados y errores
- Contratos de salida declarados y validados
- Informes de revisión atados a una versión
Por validar
- Corpus estable con defectos conocidos
- Pruebas de regresión al cambiar de modelo
- Umbrales de coste y latencia por fase
- Recuperación ante fallos parciales
- Qué información no puede salir del perímetro
Fuera de alcance
- Publicación sin intervención de una persona
- Garantía automática de que algo es cierto
- Uso por terceros
- Sustituir la revisión de un especialista
Decisiones de arquitectura
Las que cambiaron la arquitectura
Ninguna estaba en el diseño inicial. Todas salieron de ver aprobarse un defecto que el sistema debería haber parado.
- 01
El estado oficial vive fuera del modelo
La respuesta del modelo no determina en qué fase está el trabajo ni qué queda por validar; eso lo decide la aplicación. Así puedo cambiar las instrucciones, el modelo o el proveedor sin que el proceso quede pegado a una herramienta concreta.
- 02
Quien corrige no cierra el hallazgo
La función que propone una modificación no tiene autoridad para aprobarla. Cuando las tuve juntas, un parche introdujo una afirmación falsa y sobrevivió: el mismo lado que la había escrito participaba en aprobarla.
- 03
Una evaluación solo vale para una versión
Cuando cambia el contenido, decaen las comprobaciones que ya no corresponden al artefacto actual. Un informe correcto sobre un borrador anterior deja de valer, y si no está atado a su versión nadie se entera.
- 04
Cómo compruebo los controles
Vuelvo a ejecutar la herramienta en lugar de leer el fichero que dice que se ejecutó: encontré una comprobación que salía en verde mientras leía una clave que no existía. Y cada prueba parte de una pieza válida a la que le meto un defecto concreto, porque que el sistema rechace algo que ya estaba roto por otro motivo no demuestra que el control nuevo funcione.
Límites del sistema
Automatizar la ejecución no traslada la responsabilidad.
El sistema reúne material, propone una estructura, produce una versión y ejecuta controles. Lo que no hace es garantizar que una afirmación sea cierta ni decidir qué merece publicarse. Fijo el propósito, decido qué fuentes bastan, reviso lo que exige criterio y autorizo el resultado. La supervisión no es un botón de aprobar al final: es parte de la arquitectura, y necesita contexto suficiente para devolver el trabajo o detenerlo.
Patrones transferibles
Qué se traslada y qué hay que rehacer cuando cambia el problema
- Cambia el dominio
El corpus, los permisos, las instrucciones y los criterios de validación son propios de cada problema y se rehacen. El patrón de orquestación, el estado fuera del modelo, los contratos y las trazas puede reutilizarse, aunque sus esquemas y controles deben adaptarse al nuevo dominio.
- Cambia el modelo
Una versión distinta altera el comportamiento de una fase sin avisar. Por eso la comparación necesita un conjunto estable de casos: sin él no distingo una mejora de una ejecución afortunada.
- Crece el volumen
Lo primero que se nota no es la calidad, es la cola: tareas simultáneas, reintentos y coste por fase. Un sistema puede dar buenos resultados y no aguantar el ritmo al que se le pide.
Qué acredita este trabajo
Un proceso editorial convertido en una aplicación de IA con estado y contratos
He llevado el trabajo desde una cadena de llamadas a un modelo hasta un sistema que guarda el estado fuera de la conversación, ejecuta cada fase contra un contrato y deja el rastro necesario para reconstruir por qué avanzó. Lo que se publica sigue dependiendo de mí.
- 01Arquitectura de aplicaciones de IA
- 02Orquestación de modelos y herramientas
- 03Estado, colas y procesamiento asíncrono
- 04Evaluación y observabilidad
Contexto profesional