bloggen.xyz

Bloggen von A-Z

Hands-on-Lab Teil 5: Altbestand nachziehen und der Betrieb

von Kommentar verfassen

Die Automatisierung lief. Neue Beiträge wurden eingesammelt, getextet und veröffentlicht. Dann fiel beim Nachzählen etwas auf: Der Blog hatte 82 veröffentlichte Beiträge, davon nur sieben aus den letzten 250 Tagen. Der Rest lag seit Jahren da und war nie auf Social Media gewesen.

Das ist ein Bestand, den man nicht liegen lässt. Wenn der Kanal Reichweite aufbauen soll, ist ein Archiv guter Beiträge der billigste Rohstoff, den man hat.

Aber man kann ihn nicht einfach durchlaufen lassen. Ein Beitrag über Winter-Survival, Ende August gepostet, macht den Kanal nicht seriöser.

Saison als Datenfeld, nicht als Bauchgefühl

Die Lösung war eine kuratierte Liste, in der jeder Beitrag ein Monatsfenster trägt:

{ id: 882,  von: 4,  bis: 10, t: 'Lagerfeuer richtig loeschen' },
{ id: 897,  von: 5,  bis: 9,  t: 'Stand Up Paddling' },
{ id: 1218, von: 12, bis: 2,  t: 'Tierspuren im Schnee' },
{ id: 515,  von: 1,  bis: 12, t: 'Grundlagen des Wanderns' },

Der Filter ist eine Zeile, muss aber den Jahreswechsel aushalten – ein Fenster von Dezember bis Februar hat ein größeres von als bis:

const passt = (e.von <= e.bis)
  ? (m >= e.von && m <= e.bis)      // 4 bis 10
  : (m >= e.von || m <= e.bis);     // 12 bis 2

Ein klassischer Fehler wäre, nur die erste Bedingung zu schreiben. Winterbeiträge würden dann nie erscheinen, weil kein Monat gleichzeitig ≥ 12 und ≤ 2 ist. Das fällt erst im Dezember auf – oder gar nicht.

Die Verteilung nach dem Kuratieren:

GruppeAnzahlFenster
ganzjährig (Grundlagen, Ausrüstung, Technik)331–12
Sommerhalbjahr (Touren, Klettersteige, Wassersport)144–10, teils enger
Herbst (Waldbaden)24–11
Jagdsaison29–12
Winter811–3 bzw. 12–2

Zwei Drittel sind ganzjährig. Das ist typisch: Der Anteil wirklich saisongebundener Beiträge wird meist überschätzt.

Kuratieren heißt auch aussortieren

Der wichtigere Teil der Arbeit war nicht das Einsortieren, sondern das Aussortieren. Von 82 Beiträgen sind 60 eingeplant, acht waren schon gepostet – und 14 habe ich dauerhaft ausgeschlossen.

Die Gründe, nach Gewicht:

Ein Beitrag wegen der Plattformrichtlinien. Ein Thema, bei dem Facebook und Instagram unberechenbar reagieren. Das Risiko liegt nicht beim einzelnen Post, sondern bei der Seite: Eine Sperre trifft alles.

Vier wegen veralteter Zahlen. Statistiken von 2018, Nachrichtenmeldungen von 2017. Der Beitrag selbst darf im Archiv stehen bleiben – aktiv bewerben sollte man ihn nicht.

Neun wegen ungeprüftem Rechtsstand. Beiträge zu Rechtsfragen, teils aus 2017. Ob sie noch zutreffen, konnte ich nicht beurteilen. Und hier ist der Unterschied entscheidend: Ein veralteter Ausrüstungstipp ist ärgerlich. Ein veralteter Rechtstipp, aktiv beworben, ist etwas anderes.

Die allgemeine Regel dahinter: Automatisierte Reichweite verstärkt, was da ist – auch die Fehler. Ein alter Beitrag, den niemand findet, richtet wenig an. Derselbe Beitrag, zweimal pro Woche in die Timeline gespült, wird zu einer Aussage, hinter der man steht. Der Aufwand des Aussortierens ist die eigentliche Arbeit; das Einreihen erledigt die Maschine.

Wie die vierzehn technisch gesperrt sind, stand in Teil 3: als Zeilen mit Status gesperrt in derselben Tabelle, die auch Doppelposts verhindert.

Der Massenlauf

Workflow 3 filtert also auf den aktuellen Monat, prüft gegen die Tabelle, begrenzt auf max_pro_lauf – und schickt den Rest durch dieselbe Kette wie Workflow 1: Volltext holen, Gliederung ziehen, Texte erzeugen, Bild bestimmen, eintragen.

Beim ersten Versuch reihte er genau einen Beitrag ein statt neunundvierzig. Die Ursache – ein Code-Node, der mit $input.first() nur das erste Element verarbeitete – habe ich in Teil 3 beschrieben. Sie ist deshalb erwähnenswert, weil der Lauf erfolgreich meldete. Nichts war rot. Nur die Laufzeit von neun Sekunden hätte stutzig machen müssen.

Nach der Reparatur: 59 Sekunden, 49 Einträge, Termine vom 23. August bis zum 4. Oktober.

Bewusst ist dieser Workflow manuell gestartet. Er löst Dutzende Modellaufrufe auf einmal aus. Das will ich anstoßen, wenn ich davorsitze – nicht nachts von einem Zeitplan überrascht werden.

Was der Betrieb verlangt

Damit läuft die Sache. Aber „läuft“ heißt nicht „braucht nichts mehr“.

Zweimal im Jahr nachreihen. Die zehn saisonal gebundenen Beiträge – Jagdsaison und Winterthemen – sind noch nicht eingeplant, weil ihr Monatsfenster im August nicht greift. Im Oktober und im November muss Workflow 3 erneut laufen. Das ist eine Kalendernotiz, keine Automatik. Man könnte es per Zeitplan lösen; ich habe mich dagegen entschieden, weil ich die Kosten kontrollieren will.

Ins Postfach schauen. Der Fehlerpfad schickt eine Mail, wenn ein Post scheitert. Wer die Mails filtert und nicht liest, merkt einen Tokenausfall erst Wochen später an ausbleibender Reichweite.

Die Warteschlange durchsehen. Einträge mit Status fehler verschwinden nicht von selbst. Alle paar Wochen ein Blick genügt.

An das Token denken. Ein Seiten-Token aus einem langlebigen Nutzer-Token läuft nicht ab – aber es wird ungültig, wenn man das Facebook-Passwort ändert oder der App die Berechtigungen entzieht. Das ist der wahrscheinlichste Ausfallgrund im laufenden Betrieb.

Die Prompt-Duplizierung im Auge behalten. Derselbe Textbaustein steht in zwei Workflows. Wer ihn ändert, muss an beide Stellen. Ich habe mir das notiert, weil ich weiß, dass ich es sonst vergesse.

Was das kostet

Eine Frage, die bei KI-gestützten Automatisierungen zu selten gestellt wird: Was läuft da eigentlich an Kosten auf?

Die Textgenerierung braucht pro Beitrag etwa 2.100 Eingabe- und 400 Ausgabe-Token. Das ist wenig, weil der Prompt zwar ausführlich ist, aber nur die Gliederung und 3.000 Zeichen Fließtext mitgeschickt werden – nicht der ganze Artikel. Bei einem der günstigen schnellen Modelle liegt ein Beitrag damit im Bereich von Bruchteilen eines Cents. Der komplette Altbestandslauf mit 49 Beiträgen kostete weniger als ein Kaffee.

Deutlich teurer wäre der Bildweg gewesen. Für Beiträge ohne Beitragsbild ist ein Rückfall auf ein KI-erzeugtes Bild eingebaut – und ein einzelnes Bild kostet ein Vielfaches eines Textaufrufs. Bei diesem Blog hat der Zweig kein einziges Mal gegriffen, weil alle Beiträge ein Beitragsbild haben. Das war Glück, kein Verdienst. Wer einen Bestand mit vielen bildlosen Beiträgen hat, sollte vorher nachzählen, statt die Rechnung hinterher zu lesen.

Die eigentlichen Kosten liegen ohnehin woanders: in der Prüfarbeit. Das Kuratieren der 82 Beiträge – Titel lesen, Saison einschätzen, Rechtsthemen aussortieren – war die zeitaufwändigste Einzelaufgabe des ganzen Projekts. Die Maschine hat 49 Texte in 59 Sekunden erzeugt. Die Entscheidung, welche 60 überhaupt erscheinen dürfen, hat deutlich länger gedauert.

Acht pro Woche – warum diese Zahl

Bleibt die Frage, die über allem steht: Wie oft soll das Ding posten?

Ich habe mich für acht Beiträge pro Woche entschieden, und die Zahl steht an genau einer Stelle – in einem Konfigurationsknoten, als posts_pro_woche. Der Abstand zwischen zwei Terminen ergibt sich daraus:

168 Stunden / 8 = 21 Stunden

Einundzwanzig Stunden statt vierundzwanzig hat einen angenehmen Nebeneffekt: Die Uhrzeit wandert. Ein Beitrag geht mittags raus, der nächste am Vorabend, der übernächste morgens. Über ein paar Wochen deckt die Serie damit von selbst verschiedene Tageszeiten ab, ohne dass ich Zeitfenster pflegen muss. Wer den optimalen Posting-Zeitpunkt sucht, bekommt hier nebenbei Datenmaterial.

Warum acht und nicht drei oder zwanzig? Ehrliche Antwort: Es ist eine Setzung. Bei sechzig eingeplanten Beiträgen ergibt sie einen Vorlauf von etwa zwei Monaten – lang genug, dass die Sache Bestand hat, kurz genug, dass ich einen Fehler im Textstil nicht erst im nächsten Jahr korrigieren kann. Ob acht für die Reichweite besser sind als vier, weiß ich nicht. Ich weiß nur, dass ich es ändern kann, indem ich eine Zahl anfasse und den Altbestand neu einreihe.

Das ist der eigentliche Punkt: Nicht die Zahl ist wichtig, sondern dass sie an einer Stelle steht und nicht in sieben Ausdrücken verstreut.

Was ich beim nächsten Mal anders machen würde

Drei Dinge.

Erstens: die Datengrundlage vor dem Prompt prüfen. Ich habe eine Runde damit verbracht, Prompt-Formulierungen zu variieren, obwohl das Problem im zu dünnen Input lag. Die Frage „hat das Modell überhaupt genug Material für diese Aufgabe?“ hätte ich zuerst stellen sollen.

Zweitens: früher messen statt annehmen. Bei den Meta-Berechtigungen habe ich drei Runden lang dieselbe Messung mit demselben Werkzeug wiederholt und dasselbe unklare Ergebnis bekommen. Der Durchbruch kam, als ich das Werkzeug wechselte. Wenn eine Messung dreimal nichts Neues liefert, ist nicht die Sache unklar – die Messmethode taugt nicht.

Drittens: bei Stapelverarbeitung die Laufzeit als Prüfgröße nehmen. Neun Sekunden für 49 Modellaufrufe sind physikalisch unmöglich. Das war der Hinweis, und ich habe ihn zunächst überlesen.

Die Bilanz

Was steht am Ende:

  • Drei Workflows: einsammeln, posten, Altbestand nachziehen
  • Eine Datentabelle als Redaktionsplan, Freigabemappe, Doppel-Schutz und Protokoll
  • Zwei Kanäle, beide getestet und mit echten Beiträgen belegt
  • 49 terminierte Beiträge für die nächsten sechs Wochen
  • 14 dauerhaft gesperrte, mit dokumentiertem Grund
  • Acht Posts pro Woche, über eine Zahl in der Konfiguration steuerbar

Der Bauaufwand lag bei einem Abend – zum Vergleich die Bilanz der Content-Automatisierung, die in derselben Woche entstanden ist. Etwa die Hälfte davon ging für die vier Fehler drauf, die in dieser Serie ihren Platz bekommen haben – und die vermutlich der nützlichere Teil sind. Ein Workflow, der beim ersten Versuch läuft, lehrt einen nichts.

Was noch offen ist: ob es sich lohnt. Der Kanal hatte zwanzig Follower, als das hier anfing. Ob acht Posts pro Woche daraus etwas machen, weiß ich in vier Wochen – dann sind die Zahlen da, so wie beim Messpunkt vor dem Umbau. Das wird ein eigener Beitrag.

Die Serie: