Warum wir der KI kein Datum mehr ausrechnen lassen

Anfang September stellte jemand unserem Chat eine ganz gewöhnliche Frage: „Kannst du mir den Hauptausschuss nächste Woche zusammenfassen? Welche Themen sind für uns interessant?“

Die Antwort: Die Sitzung sei im Bestand nicht vorhanden.

Sie war vorhanden. Seit zehn Tagen. Vollständig, mit Tagesordnung und sämtlichen Vorlagen — über fünfhundert Textabschnitte im Index. Der erste Verdacht fiel auf den Importdienst, der die Daten nachts abholt. Der lief einwandfrei, alle 33 Minuten, ohne Beanstandung.

Es waren vier Fehler. Sie lagen in vier verschiedenen Schichten, hatten nichts miteinander zu tun, und jeder einzelne hätte gereicht, um die Antwort zu verderben.

Fehler 1: „nächste Woche“ ist kein Rechenweg

Bevor gesucht wird, übersetzt ein Modell die Frage in einen Suchauftrag — auch den Zeitraum. Aus „nächste Woche“ machte es schlicht heute plus sieben Tage. Gefragt wurde an einem Dienstag, gesucht wurde also ab dem folgenden Dienstag. Die Sitzung war an einem Montag. Sie fiel um genau einen Tag aus dem Filter.

Kein Treffer. Und damit, aus Sicht des Systems, korrekt: keine Daten.

Fehler 2: zwei Anführungszeichen

Zwei der Rats-PDFs trugen Anführungszeichen im Titel. Beim Übergeben an die Dokumentenaufbereitung brach das jedes Mal den Upload — ein Detail im Übertragungsprotokoll, das mit Anführungszeichen im Dateinamen nicht zurechtkommt. Der Import meldete deshalb dauerhaft „mit Fehlern abgeschlossen“.

Das war nicht die Ursache des Problems, aber es hat die Suche danach verlängert: In den Protokollen stand ein echter Fehler, der bloß ein anderer war.

Fehler 3: Das Modell glaubte dem Kontext nicht

Nach der Korrektur von Fehler 1 lag die richtige Sitzung im Kontext — mit Datum, Tagesordnung, vierzehn Textpassagen, einundzwanzig Quellen. Das Antwortmodell rechnete sich trotzdem ein eigenes Datum aus, kam auf einen anderen Tag und erklärte den korrekt gelieferten Kontext für leer.

Die Antwort war jetzt nicht mehr nur unvollständig. Sie war falsch, und sie klang überzeugt.

Fehler 4: Der Reparaturversuch, der alles schlimmer machte

Der naheliegende Weg wäre, dem Modell im Systemtext zu erklären, was es zu tun hat: „Vertraue dem Datum, das im Kontext steht. Rechne nicht selbst.“ Genau das haben wir versucht.

Es wurde schlechter.

Ein Sprachmodell befolgt Anweisungen nicht wie ein Programm eine Bedingung. Es gewichtet sie — gegen alles andere, was im Kontext steht, und gegen das, was es aus dem Training für plausibel hält. Eine höfliche Bitte ist eine schwache Kraft. Ist das Modell klein und antwortet es ohne Zwischenschritte, verliert die Bitte regelmäßig.

Was wir stattdessen gemacht haben

Wir haben dem Modell die Gelegenheit zum Irrtum genommen, statt es um Nachsicht zu bitten:

• Zeiträume werden im Programm berechnet, nicht vom Modell. „Diese Woche“, „nächste Woche“, „nächster Monat“ — der Code rechnet Montag bis Sonntag aus und übergibt fertige Daten. Das Modell darf sie verwenden, nicht herleiten.
• Das Sitzungsdatum steht samt Wochentag fest im Kontext. Nicht als Bitte, sondern als Kopfzeile über dem Textblock: Datum, Wochentag, und bei künftigen Terminen die Kennzeichnung als kommende Sitzung.
• Bei Sitzungsfragen denkt das Modell nach. Wo ein Sitzungsblock im Spiel ist, schalten wir den langsameren, sorgfältigeren Modus ein. Das kostet Sekunden und spart falsche Antworten.
• Dateinamen werden entschärft, bevor sie das Übertragungsprotokoll erreichen. Umlaute und Gedankenstriche bleiben, header-brechende Zeichen fliegen raus.

Jede dieser Änderungen ist durch Tests abgesichert — einschließlich der unangenehmen Fälle: Wochenwechsel, Monatswechsel, Jahreswechsel. Und der echte Dateiname, an dem es gescheitert war, steht jetzt als Testfall im Code.

Danach lieferte die Frage die richtige Sitzung, mit korrektem Datum, richtigem Wochentag und der tatsächlichen Tagesordnung.

Was wir daraus mitnehmen

Harte Fakten gehören in den Code, nicht in eine Bitte an das Modell. Ein Datum, ein Betrag, eine Frist, eine Zuständigkeit — alles, was eindeutig ausrechenbar ist, sollte ausgerechnet und übergeben werden. Das Modell ist gut darin, Sprache zu verstehen und Zusammenhänge zu formulieren. Es ist nicht gut darin, zu rechnen, und es ist unzuverlässig darin, sich an Regeln zu halten, die seiner eigenen Einschätzung widersprechen.

Der zweite Punkt ist unbequemer: Ein einzelner Fehler ist selten allein. Hier haben sich vier unabhängige Fehler so überlagert, dass das Symptom nach einem kaputten Import aussah — und der war der einzige Teil, der funktionierte. Wer beim ersten plausiblen Verdacht aufhört, repariert das Falsche.

Wir schreiben das auf, weil bei künstlicher Intelligenz überwiegend über das geredet wird, was gelingt. Verlässlich wird ein System aber dort, wo jemand die Fehler ernst genug nimmt, sie zu Ende zu verfolgen — und die Lösung nicht dem Modell überlässt.