Un planificateur léger, quel que soit le nombre de cartes

Chaque film PageToVid commence par un planificateur : un appel à Gemini qui lit la page et répond par un storyboard, scène par scène. Pour que cette réponse soit fiable, nous transmettons au modèle un schéma de réponse, une description précise de la forme que doit prendre sa réponse.

Le modèle ne se contente pas de lire ce schéma. Il le compile en une grammaire qu'il suit mot à mot en écrivant, si bien que la réponse ne peut jamais revenir sous une mauvaise forme. Cette garantie permet au reste de la chaîne de faire confiance au plan sans rien deviner.

Une grammaire a un prix. Chaque champ optionnel, chaque alternative multiplie le nombre d'états possibles, et un modèle qui sert des millions de requêtes plafonne ce nombre.

Les nouvelles cartes animées ont chacune leurs propres champs : un titre ici, trois puces là, un chiffre et son libellé ailleurs. Notre première façon de laisser le planificateur les remplir consistait à décrire les champs de chaque carte dans le schéma, un par un. Avec des centaines de cartes, la description du plan devenait assez grande pour toucher le plafond du modèle. Nous voulions un plan qui ne puisse plus jamais s'en approcher.

La réponse : ne plus décrire les champs de chaque carte dans le schéma. Quelle que soit la carte choisie, son contenu voyage désormais sous forme d'une seule chaîne JSON. Le schéma garde exactement la même taille, que nous proposions dix cartes ou dix mille.

• Le prompt continue de lister en clair les champs de chaque carte, pour que le modèle sache quoi écrire.
• Juste après la réponse du planificateur, du relecteur et de la passe de révision, unpackRushieProps reconvertit cette chaîne en champs.
• Le compositeur vérifie ensuite ces champs selon les règles de la carte, comme avant : une carte qui ne convient pas est toujours repérée.

Avant de livrer, nous avons fait un vrai appel à Gemini sur le schéma exact de production, car seul le modèle peut confirmer ce que le modèle accepte.

Une règle qui ne vit que dans la mémoire de quelqu'un finit oubliée. Un test hors ligne compte donc désormais les nœuds du schéma de scène et le tient à un budget : 137 nœuds aujourd'hui, pour un plafond de 250. Le même test vérifie que le contenu des cartes reste une seule chaîne.

Le nombre de nœuds n'est qu'une approximation de ce que mesure vraiment le modèle. Peu importe : il est fait pour échouer tôt et bruyamment dans nos contrôles, bien avant qu'un schéma ne s'approche de la limite du modèle.

Notre surveillance regardait déjà les pièces : le service qui répond, les tâches qui tournent, les erreurs dans les journaux. Nous voulions qu'elle regarde aussi le résultat, ce qui compte vraiment pour vous : un film qui se fabrique.

Nous avons donc ajouté une sonde horaire. Une fois par heure, elle fait un vrai appel de planification avec le schéma et le modèle de production, exactement comme un film réel. Elle regarde aussi les six dernières heures de films : si plusieurs d'affilée n'ont pas atteint l'arrivée, elle nous prévient.

• Elle alerte au plus une fois toutes les six heures, pour qu'un signal ne se noie jamais dans les répétitions.
• Elle ne lève jamais d'erreur elle-même, et ne peut donc pas perturber la tâche qui l'exécute.
• Un refus de l'API du modèle déclenche l'alerte immédiatement.

Vos films continueront de gagner des cartes animées à mesure que la bibliothèque d'animations grandit, sans que le plan derrière eux ne devienne plus lourd ni plus lent à écrire. Et si la planification cessait de fonctionner, pour quelque raison que ce soit, nous le saurions dans l'heure, grâce à un test qui se comporte exactement comme votre film.

La leçon plus large, pour quiconque construit sur la sortie structurée : votre vérificateur de types voit votre schéma, mais seul le modèle en voit le coût. Gardez le contenu ouvert dans un seul champ, validez-le ensuite, et testez la vraie chose.