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

Ausgangslage: Der Text ist billig, das Vertrauen ist teuer

Im dokumentierten Testaufbau schrieb ein Sprachmodell 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 Datenfeld. Der Controller reicht ihn weiter und rendert ihn in die Review-Mail; der Planner verarbeitet nur topic_class, audience und intents aus Enum-Whitelists sowie Zähler und IDs. Damit erreicht der rohe Seitentext den Planner nicht. Der spätere Writer sieht jedoch validierte Kandidatenfragen, weshalb ein begrenzter Einflusskanal bestehen bleibt.

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.

Der Extractor bekommt keine Firmendaten. Der Writer erhält nur Fakten mit approved=TRUE und nur aus den Kategorien, die der Planner ausgewählt hat. Das begrenzt den Zugriff, schließt aber eine unbeabsichtigte Offenlegung genehmigter Fakten im Entwurf nicht vollständig aus.

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 kleinste Menge, verursacht in dieser Modellrechnung aber etwa die Hälfte der Kosten, weil Claude Sonnet 4.5 pro Token teurer angesetzt ist als gpt-4o-mini und Gemini Flash. Er macht nur eine geschlossene Klassifikation auf Enums und Zählern. Ein günstigeres Modell würde diesen festen Kostenblock senken; wie stark, hängt vom aktuellen Modellpreis ab.

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 Kandidatenfragen aus der Quarantäne und sieht zugleich die für die Antwort freigegebenen Firmendaten. Eine präparierte Seite kann deshalb die Formulierung beeinflussen; eine unbeabsichtigte Offenlegung genehmigter Fakten im Entwurf kann ich nicht vollständig ausschließen. Der Writer hat jedoch keine Werkzeuge, und ohne menschliche Freigabe wird nichts veröffentlicht.

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

Stolperstellen

Der Planner ist im gezeigten Beispiel der größte feste Kostenblock. Der Extractor ist dagegen der Skalierungstreiber: Dort gehen bis zu 15.000 Zeichen Seitentext hinein, und dieser Posten wächst mit langen Seiten, während Planner und Writer auf kompakteren Strukturen arbeiten. Wer die laufenden Kosten senken will, prüft daher beides: das Planner-Modell und die Länge des Extractor-Inputs.

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. In meinem Modellfall wurde der Aufbau ab etwa dreißig Seiten plausibel, sobald dieselbe Preisangabe konsistent gepflegt werden musste. Das ist eine praktische Schätzung, kein allgemeiner Break-even; Review-Aufwand und Änderungsfrequenz entscheiden mit.

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.