Ein schlanker Planer, egal wie viele Karten dazukommen

Jedes PageToVid-Video beginnt mit einem Planer: einem Aufruf an Gemini, der die Seite liest und mit einem Storyboard antwortet, Szene für Szene. Damit diese Antwort verlässlich ist, geben wir dem Modell ein Antwortschema mit, eine genaue Beschreibung der Form, die seine Antwort haben muss.

Das Modell liest dieses Schema nicht nur. Es übersetzt es in eine Grammatik und folgt ihr beim Schreiben Wort für Wort, sodass die Antwort nie in der falschen Form zurückkommt. Diese Garantie erlaubt dem Rest der Kette, dem Plan zu vertrauen, ohne zu raten.

Eine Grammatik ist nicht umsonst. Jedes optionale Feld und jede Alternative vervielfacht die Zahl ihrer möglichen Zustände, und ein Modell, das Millionen Anfragen bedient, setzt dieser Zahl eine Obergrenze.

Die neuen gestalteten Karten bringen jeweils eigene Felder mit: hier eine Überschrift, dort drei Stichpunkte, anderswo eine Zahl mit Beschriftung. Unser erster Weg, den Planer sie füllen zu lassen, war, die Felder jeder Karte einzeln im Schema zu beschreiben. Bei Hunderten Karten wurde die Beschreibung des Plans so groß, dass sie an die Obergrenze des Modells reichte. Wir wollten einen Plan, der sich ihr nie wieder nähern kann.

Die Antwort war, die Felder der einzelnen Karten nicht mehr im Schema zu beschreiben. Welche Karte der Planer auch wählt, ihr Inhalt reist jetzt als ein einziger JSON-String. Das Schema bleibt genau gleich groß, ob wir zehn Karten anbieten oder zehntausend.

• Der Prompt listet die Felder jeder Karte weiter in Worten auf, damit das Modell weiß, was es schreiben soll.
• Direkt nach der Antwort von Planer, Prüfer und Revisionsdurchgang macht unpackRushieProps aus dem String wieder Felder.
• Der Composer prüft diese Felder dann wie bisher gegen die Regeln der Karte, eine unpassende Karte fällt also weiterhin auf.

Vor der Auslieferung haben wir einen echten Gemini-Aufruf mit dem exakten Produktionsschema gemacht, denn nur das Modell kann bestätigen, was das Modell annimmt.

Eine Regel, die nur im Gedächtnis eines Menschen lebt, wird vergessen. Deshalb zählt jetzt ein Offline-Test die Knoten im Szenenschema des Planers und hält es an einem Budget fest: heute 137 Knoten bei einer Obergrenze von 250. Derselbe Test prüft, dass Karteninhalte ein einziger String bleiben.

Die Knotenzahl ist nur eine grobe Annäherung an das, was das Modell wirklich misst. Das ist in Ordnung: Sie soll früh und laut in unseren Prüfungen anschlagen, lange bevor ein Schema auch nur in die Nähe der Grenze des Modells kommt.

Unsere Überwachung sah schon auf die Teile: den Dienst, der antwortet, die Jobs, die laufen, die Fehler in den Logs. Wir wollten, dass sie auch auf das Ergebnis schaut, auf das, was dir wirklich wichtig ist: dass ein Video entsteht.

Also haben wir einen stündlichen Kanarienvogel eingeführt. Einmal pro Stunde macht er einen echten Planungsaufruf mit Produktionsschema und -modell, genau wie ein echtes Video. Außerdem schaut er auf die letzten sechs Stunden: Kommen mehrere Videos hintereinander nicht ans Ziel, meldet er sich.

• Er meldet sich höchstens alle sechs Stunden, damit ein Signal nie in Wiederholungen untergeht.
• Er wirft nie selbst einen Fehler und kann so den Job, in dem er läuft, nie stören.
• Eine Ablehnung durch die API des Modells meldet er sofort.

Deine Videos bekommen weiter neue gestaltete Karten, während die Animationsbibliothek wächst, ohne dass der Plan dahinter schwerer oder langsamer wird. Und sollte die Planung aus irgendeinem Grund einmal nicht funktionieren, erfahren wir es innerhalb einer Stunde, durch einen Test, der sich genau wie dein Video verhält.

Die allgemeinere Lehre für alle, die auf strukturierter Ausgabe bauen: Dein Typchecker sieht dein Schema, aber nur das Modell sieht, was es kostet. Halte offene Inhalte in einem Feld, prüfe sie danach und teste das Echte.