Niklas Bramböck · Planung & Digitalisierung

Daten & Prozesse · Pflanzendatenbank

Vier Läufe, einer davon mit einer Pflanze, die es nicht gibt

Eine Zapier-Strecke füllt eine Notion-Pflanzendatenbank: Name rein, 28 Felder raus. Am 3. September 2026 ist sie viermal gelaufen – einmal normal, einmal mit derselben Pflanze von der anderen Seite, einmal mit einem erfundenen Namen und einmal mit einer Hybride. Hier stehen die vier Läufe Schritt für Schritt, so wie sie protokolliert sind.

Was hier läuft – und was nicht

Die Läufe sind echt und aufgezeichnet: eigene Strecke, eigene Notion-Datenbank, eigene Läufe vom 3. September 2026. Die Antworten des Modells stehen im Wortlaut, samt Tokenverbrauch. Es läuft hier kein Sprachmodell – dieselbe Anfrage würde beim nächsten Mal andere Zahlen liefern. Reproduzierbar ist die Prüfung: Sie rechnet jedes Mal neu auf denselben aufgezeichneten Antworten.

Weggelassen sind alle Kennungen aus dem Export – Notion-Seiten-, Datenbank- und Benutzerkennungen zeigen auf einen privaten Arbeitsbereich. Zugangsdaten und Schlüssel gibt es hier keine, und das Bildschirmfoto des Auslöserschritts fehlt bewusst: Es zeigt die E-Mail-Adresse des verbundenen Kontos.

Nicht belegt: dass die Angaben botanisch stimmen. Die Strecke prüft die Form jedes Wertes, nicht seinen Wahrheitsgehalt – siehe „Was diese Läufe nicht belegen“ unten.

1 · Die vier Läufe

Jeder Lauf stellt eine andere Frage an dieselbe Strecke. Wählen Sie einen aus – darunter steht, was in jedem der sieben Schritte geschah.

2 · Die Vokabularschranke

22 der 28 Felder haben eine feste Werteliste. Das Modell darf dort keinen neuen Wert hineinschreiben – auch keinen, der fachlich richtig wäre. Was nicht passt, meldet es stattdessen über ein eigenes Feld namens NEUE_WERTE, und ein späterer Schritt legt es in eine Prüfliste. Die Regel dahinter steht als Prosa in der Anweisung an das Modell; hier läuft sie als Code.

Vokabularschranke

Zum Ausprobieren:

Warum das die interessante Stelle ist

Die naheliegende Bauweise wäre: „Nimm den ähnlichsten vorhandenen Wert.“ Dann stünde bei Acer griseum unter Frucht das Wort „unbedeutend“ – die Liste hat keinen Eintrag für eine Flügelnuss, und „unbedeutend“ klingt harmlos genug. Der Datensatz wäre vollständig und falsch. Diese Strecke lässt das Feld stattdessen leer und meldet den echten Begriff. Eine Lücke, die man sieht, ist besser als ein Wert, der stimmt zu sein scheint.

3 · Dieselbe Pflanze, zwei Wege hinein

Lauf A bekam den botanischen Namen Acer griseum und keinen deutschen. Lauf B bekam den deutschen Namen Zimtahorn und keinen botanischen. Es ist dieselbe Pflanze. Die Frage ist, ob auch dasselbe herauskommt.

4 · Was die Läufe über die Datenbank verraten

Ein Teil der Abweichungen zwischen A und B liegt nicht am Modell, sondern an der Werteliste selbst. Beide Befunde unten sind aus dem Vokabular gerechnet, nicht hineingeschrieben.

Was diese Läufe nicht belegen

Keine Berufserfahrung mit Zapier, Notion oder OpenAI. Das ist ein eigenes Werkzeug für eigene Zwecke, gebaut und getestet von einer Person.

Kein Beleg, dass die Angaben botanisch stimmen. Die Strecke prüft die Form: Steht der Wert in der Liste? Lässt er sich sinnvoll abbilden? Ob Acer griseum tatsächlich bis −30 °C freilandhart ist, prüft sie nicht. Lauf A und B geben hier verschiedene Werte an – mindestens einer davon ist falsch, und die Strecke merkt es nicht.

Vier Läufe sind keine Messreihe. Sie zeigen, dass die Strecke in vier ausgesuchten Fällen tut, was sie soll. Über die Trefferquote auf hundert Pflanzen sagen sie nichts.

Der Halluzinationsschutz ist keine Regel

Lauf C hat den erfundenen Namen abgefangen – aber nicht durch einen Filter und nicht durch eine Zeile Code. Die Namensregel der Anweisung prüft nur auf Platzhalter wie „Untitled Page“; Dracodendron luminara ist formal ein einwandfreier botanischer Name. Abgefangen hat ihn das Modell, weil es die Pflanze nicht kannte.

Das ist ein gutes Ergebnis und eine dünne Absicherung zugleich: Sie ist genau so verlässlich wie das Modell an diesem Tag. Ein Regeltest hält das ausdrücklich fest – er prüft, dass der Abbruch nicht aus der Namensregel kam.

Regeltests

Die Regeln oben sind eine zweite Fassung der Anweisung an das Modell. Zwei Fassungen derselben Regel sind eine Fehlerquelle – deshalb schicken diese Tests die vier aufgezeichneten Läufe durch den Code und prüfen, ob dabei herauskommt, was tatsächlich zurückkam.

Die Daten zum Mitnehmen