Un planificador ligero, con todas las tarjetas que quieras

Cada vídeo de PageToVid empieza con un planificador: una llamada a Gemini que lee la página y responde con un guion, escena a escena. Para que esa respuesta sea fiable, le damos al modelo un esquema de respuesta, una descripción precisa de la forma que debe tener su respuesta.

El modelo no solo lee ese esquema. Lo compila en una gramática y la sigue palabra a palabra mientras escribe, así que la respuesta nunca vuelve con la forma equivocada. Esa garantía es lo que permite al resto del proceso fiarse del plan sin adivinar nada.

Una gramática no sale gratis. Cada campo opcional y cada alternativa multiplica el número de estados posibles, y un modelo que atiende millones de peticiones pone un techo a ese número.

Las nuevas tarjetas animadas traen cada una sus propios campos: un titular aquí, tres puntos allá, una cifra y su etiqueta en otro sitio. Nuestra primera forma de dejar que el planificador las rellenara fue describir los campos de cada tarjeta en el esquema, uno por uno. Con cientos de tarjetas, la descripción del plan se hacía lo bastante grande como para tocar el techo del modelo. Queríamos un plan que no pudiera volver a acercarse nunca.

La respuesta fue dejar de describir los campos de cada tarjeta en el esquema. Elija la tarjeta que elija el planificador, su contenido viaja ahora como una sola cadena JSON. El esquema mide exactamente lo mismo si ofrecemos diez tarjetas o diez mil.

• El prompt sigue listando en palabras los campos de cada tarjeta, para que el modelo sepa qué escribir.
• Justo después de que respondan el planificador, el revisor y la pasada de revisión, unpackRushieProps vuelve a convertir esa cadena en campos.
• El compositor comprueba luego esos campos con las reglas de la tarjeta, igual que antes, así que una tarjeta que no encaja se sigue detectando.

Antes de lanzarlo, hicimos una llamada real a Gemini con el esquema exacto de producción, porque solo el modelo puede confirmar lo que el modelo acepta.

Una regla que solo vive en la memoria de alguien acaba olvidada. Así que un test sin conexión cuenta ahora los nodos del esquema de escena y lo ata a un presupuesto: 137 nodos hoy, con un techo de 250. El mismo test comprueba que el contenido de las tarjetas sigue siendo una sola cadena.

El número de nodos es solo una aproximación de lo que mide de verdad el modelo. No pasa nada: está pensado para fallar pronto y con ruido en nuestros controles, mucho antes de que un esquema se acerque al límite del modelo.

Nuestra vigilancia ya miraba las piezas: el servicio que responde, las tareas que corren, los errores en los registros. Queríamos que mirara también el resultado, lo que de verdad te importa: que se haga un vídeo.

Así que añadimos un canario cada hora. Una vez por hora hace una llamada real de planificación con el esquema y el modelo de producción, exactamente como lo haría un vídeo real. También mira las últimas seis horas de vídeos: si varios seguidos no han llegado al final, nos avisa.

• Avisa como mucho una vez cada seis horas, para que una señal nunca se pierda entre repeticiones.
• Nunca lanza un error propio, así que no puede alterar la tarea en la que corre.
• Un rechazo de la API del modelo avisa al instante.

Tus vídeos seguirán ganando tarjetas animadas a medida que crezca la biblioteca de animaciones, sin que el plan que hay detrás sea más pesado ni más lento de escribir. Y si la planificación dejara de funcionar por cualquier motivo, lo sabríamos en menos de una hora, gracias a una prueba que se comporta exactamente como tu vídeo.

La lección más amplia, para quien construya sobre salida estructurada: tu comprobador de tipos ve tu esquema, pero solo el modelo ve su coste. Guarda el contenido abierto en un campo, valídalo después y prueba lo real.