Ein FAQ-Generator, der die Seite liest, ohne ihr zu gehorchen

Ausgangslage: Der Text ist billig, das Vertrauen ist teuer

Ein Sprachmodell schreibt zwanzig FAQ-Paare für eine Produktseite in unter einer Minute. Das Problem fängt danach an. Damit die Antworten stimmen, braucht das Modell die Firmenfakten – Preise, Lieferzeiten, Garantiebedingungen. Damit die Fragen zur Seite passen, braucht es den Seitentext. Sobald beides im selben Kontextfenster liegt, hat jede fremde Seite eine Stimme in einem System, das Firmendaten kennt und Werkzeuge bedienen darf.

In Agenturprojekten kommt dieser Seitentext aus fremden CMS, gewachsen über Importe und übernommene Domains hinweg. Zeile für Zeile prüfen kann ich ihn nicht. Ich kann nur die Architektur so bauen, dass es darauf nicht ankommt.

Was der Workflow tut

Ein Zeitplan startet den Lauf, standardmäßig montags um sechs. Für jede aktive Seite holt der Workflow den Rohtext, extrahiert Kandidatenfragen und Kernaussagen daraus, plant den Antwortumfang, schreibt Entwürfe gegen die freigegebene Faktenbasis und legt sie mit status=review in Google Sheets ab. Am Ende steht eine Mail an die Redaktion: Entwürfe als Tabelle, offene Faktenlücken als eigene Liste, dazu eine Vorschau des FAQPage-JSON-LD.

Veröffentlicht wird nichts davon. Die Freigabe im Sheet ist ein getrennter, manueller Flow: Häkchen setzen, CMS-Webhook, status=published. Zielgruppe sind Marketing und Content-Management, nicht die Entwicklung.

Die Architektur: drei Modelle, die einander nicht sehen

Der Kern ist Simon Willisons Dual-LLM-Pattern vom April 2023. Die Idee dahinter: Ein privilegiertes Modell darf Werkzeuge bedienen, bekommt aber nie unkontrollierten Text zu sehen. Ein isoliertes Modell liest den unkontrollierten Text, hat aber weder Zugänge noch Daten. Was zwischen beiden fließt, sind symbolische Variablen – Platzhalter, die das privilegierte Modell weiterreicht, ohne ihren Inhalt zu lesen.

Rolle	Sieht	Sieht nie
Privileged Planner	Enums, Zähler, IDs	Seitentext, extrahierte Sätze
Quarantined Extractor	rohen Seitentext	Firmendaten
Quarantined Writer	freigegebene Fakten, validierte Extraktion	Credentials, Werkzeuge
Controller (Code)	alles, deterministisch	–

Die symbolischen Variablen sind hier zwei Sheet-Spalten: candidate_questions_json und key_claims_json. Freitext aus der Quarantäne liegt darin als totes Datum. Der Controller reicht ihn weiter und rendert ihn in die Review-Mail, das steuernde Modell liest ihn nie. Der Planner arbeitet ausschließlich auf topic_class, audience und intents – alles Enum-Whitelists – sowie auf Zählern und IDs. Es gibt schlicht keinen Kanal, über den eine präparierte Seite ihn erreicht.

Zwischen den Modellen sitzen drei Code-Knoten, Gates A bis C. Sie prüfen ohne Modell und damit reproduzierbar: striktes JSON-Schema, Enum-Whitelists, Längenkappen, Verbot von URLs und E-Mail-Adressen in Antworten, Scan auf Injection-Muster, Dedupe. Und Grounding: Jede Antwort muss Fakten-IDs aus dem übergebenen Set zitieren. Wer nichts zitiert, wird rejected.

Die Datenschutz-Richtung stimmt damit gleich mit. Der Extractor bekommt null Firmendaten, eine vergiftete Seite kann also nichts abphishen. Der Writer bekommt nur Fakten mit approved=TRUE, und davon nur die Kategorien, die der Planner ausgewählt hat.

Datenmodell

Google Sheet
├── pages           page_id, url, page_type, language, active
├── company_facts   fact_id, category, fact_text, source, approved
├── extractions     Rohsignale je Lauf, inklusive Quarantäne-Ablehnungen
└── faq_drafts      Entwurf, status, fact_ids, flag, reviewer_note

Vier Tabs, kein Server, keine Datenbank. Wie beim Share-of-Voice-Monitor ist das Sheet gleichzeitig Konfiguration, Speicher und Arbeitsoberfläche der Redaktion. Die Faktenkategorien sind eine geschlossene Liste aus elf Einträgen, pricing, security und warranty darunter; was dort nicht steht, kann der Planner nicht anfordern. Der Status eines Entwurfs wandert von review über approved oder rejected nach published.

Die interessanteste Zeilensorte trägt das Flag fact_gap. Sie entsteht, wenn die Seite eine Frage aufwirft, für die in company_facts kein freigegebener Fakt existiert. Statt einer erfundenen Antwort steht dort dann eine Arbeitsanweisung an die Redaktion. Nach zwei Läufen liest sich diese Spalte wie ein Audit der eigenen Wissensbasis.

Was der Betrieb kostet

Die Rechnung unten ist eine Schätzung, keine Messung – gerechnet an einer echten Produktseite mit 691 Token Nutztext, aber mit einer plausibel konstruierten Faktenbasis aus zwölf Einträgen. Ein Lauf durchquert drei Modelle.

Phase	Modell	Input	Output	Kosten
Extract (quarantined)	gpt-4o-mini	936	296	0,00032 $
Plan (privileged)	claude-sonnet-4.5	300	56	0,00174 $
Write (quarantined)	gemini-2.5-flash	804	465	0,00140 $
Ein Seitenlauf				0,00346 $

Beim Nachrechnen ist mir aufgefallen, was ich vorher falsch angenommen hatte. Der Planner verbraucht mit 356 Token die mit Abstand kleinste Menge und trägt trotzdem die Hälfte der Kosten, weil Claude Sonnet 4.5 den Input mit dem Zwanzigfachen von gpt-4o-mini und dem Zehnfachen von Gemini Flash berechnet. Er macht aber nur eine geschlossene Klassifikation auf Enums und Zählern. Für diese Aufgabe reicht ein günstigeres Modell, und der Lauf wird ungefähr halb so teuer.

Ein Durchlauf über einen Katalog aus 50 bis 100 Seiten kostet damit 0,17 bis 0,35 $. Im voreingestellten Wochenrhythmus werden daraus 0,75 bis 1,50 $ im Monat, für eine einzelne Seite 0,015 $. Kosten sind hier kein Argument, weder dafür noch dagegen – das Sheet und der Review-Prozess wiegen schwerer als die API-Rechnung.

Die ehrliche Grenze

Ein Restkanal bleibt, und ich schreibe ihn lieber selbst hin, als ihn wegzulassen. Der Writer liest die Kandidatenfragen aus der Quarantäne. Eine präparierte Seite kann über diesen einen Hop also weiterhin beeinflussen, wie eine Antwort formuliert ist. An Werkzeuge oder Firmendaten kommt sie darüber nicht, und veröffentlichen kann sie erst recht nichts – der Kanal endet an Gate C und am menschlichen Review.

Das Pattern schützt Zugänge, Werkzeuge und Daten. Den Geschmack schützt es nicht.

Stolperstellen

Der Kostentreiber sitzt beim Extractor, weil dort bis zu 15.000 Zeichen Seitentext hineingehen und dieser Posten mit jeder langen Seite mitwächst, während Planner und Writer auf kompakten Strukturen arbeiten und ihre Rechnung nahezu konstant bleibt. Wer an der Rechnung drehen will, kürzt also den Seitentext oder tauscht das Extractor-Modell, nicht die beiden anderen.

Die Enum-Listen entscheiden über die Brauchbarkeit. Eine Faktenkategorie, die im Vokabular fehlt, existiert für den Planner nicht, und die zugehörigen Fragen landen dauerhaft als fact_gap in der Tabelle statt als Antwort. Prüfen Sie die Kategorien gegen zehn echte Kundenfragen, bevor Sie den Zeitplan scharf schalten.

Und die Faktenbasis ist Handarbeit. Der Workflow erzeugt Entwürfe, keine Wahrheit. Steht in company_facts eine veraltete Lieferzeit, produziert das System sie in zwanzig Varianten und mit approved=TRUE im Rücken.

Aufwand

Von null bis produktiv: rund drei Arbeitstage für Datenmodell, Gates, Prompts und Testläufe. Wer den fertigen Workflow importiert, braucht für Credentials, Google Sheet und den ersten Lauf zwei bis vier Stunden. Die Modell-IDs liegen offen in drei Code-Knoten, jede OpenRouter-ID funktioniert.

Bleibt die Frage, wann sich das nicht lohnt. Bei einer Handvoll Seiten kostet das Anlegen der Faktenbasis mehr Zeit, als die FAQ-Blöcke von Hand zu schreiben. Der Aufbau rechnet sich ab dem Punkt, an dem dieselbe Preisangabe über dreißig Seiten hinweg konsistent bleiben muss – und ab da ersetzt er auch das Nachpflegen bei jeder Änderung.

Am Anfang stand die Frage, ob ein Modell fremden Seitentext lesen darf, ohne dass ich ihm dabei die Firmendaten in die Hand gebe. Die Antwort ist jetzt ein offener Workflow: FAQ Factory auf GitHub, 30 Funktionsknoten, CC BY 4.0. Importieren, ein Sheet anlegen, eine Seite aktivieren, montags in die Mail schauen. Und wenn Sie wissen wollen, welche Fragen Ihre Kunden den Antwortmaschinen tatsächlich stellen: Schreiben Sie mir.