Ich möchte hier einen weiteren Datenpunkt hinzufügen – wir beobachten einen Mechanismus, der zwar dem gleichen zugrunde zu liegen scheint, sich aber anders manifestiert.
Beobachtet bei: Discourse Core + discourse-ai, LLM: GPT-5.1 über OpenAI (benutzerdefinierte API-Verbindung, kein vorgefertigtes Modell).
Nachweise zur Reproduktion
Derselbe Quellbeitrag (Russisch, ~2000 Zeichen, Überschriften/Fett/Bullet-Listen/Links),
übersetzt in mehrere Sprachen über die native KI-Übersetzung:
- Polnisch (pl): Die Markdown-Struktur des eingebetteten Bildes ging verloren – aus
wurde ein fehlerhafter Link, dem das!-Präfix und der|-Separator fehlten, wobei Alt-Text und Abmessungen als Klartext
zusammenliefen. Es wurde als anklickbarer Link statt als eingebettetes Bild gerendert. - Ukrainisch (uk): Literalen
\n\n-Sequenzen erscheinen als Klartext im gesamten Beitrag, anstelle von Absatzumbrüchen. Das Markdown des Bildes in dieser
gleichen Übersetzung war intakt – die Beschädigung ist also nicht auf ein festes Symptom beschränkt, sondern variiert je nach Ausführung.
Im Gegensatz zum oben beschriebenen Abschneiden zeigt unser Fall keine fehlenden Inhalte –
der vollständige Text ist vorhanden, jedoch mit beschädigten Escape-Sequenzen / Markdown-
Syntax statt einer verkürzten Ausgabe. Anderer Anbieter (OpenAI vs. Google
hier), anderes Symptom (Beschädigung vs. Abschneiden), gleicher vermuteter Grund:
StructuredOutput#read_buffered_property fällt zurück auf
BestEffortJsonParser#extract_key, was JSON-String-
Sequenzen (\n bleibt literal) nicht unescaped und scheinbar auch Sonderzeichen neben Markdown-Syntax falsch behandelt, wenn der Fallback mitten im Parsing ausgelöst wird.
Auch in unseren Sidekiq- oder Rails-Logs keine Fehler – dasselbe Verhalten eines stillen Fehlers.