KI-Agent-Ausgabe fügt \n Zeilenumbruchzeichen bei Verwendung des Mistral Large 4-Modells hinzu

Das Problem/den Fehler/die Frage beschreiben

Der AI Agent-Knoten gibt bei Verwendung des Mistral Large 4-Modells etwa alle paar Token ein \n-Zeilenumbruchzeichen aus. Dies führt dazu, dass das resultierende Markdown nicht korrekt dargestellt wird. Die Ausführungsprotokolle des AI Agent zeigen eine korrekte Ausgabe des LLM, aber die Ausgabe des AI Agent-Knotens enthält fehlerhaft platzierte Zeilenumbrüche. Bislang habe ich dieses Problem nur bei diesem speziellen Mistral-Modell gefunden; andere Modelle funktionieren einwandfrei.

Bitte teilen Sie Ihren Workflow

Teilen Sie die Ausgabe des letzten Knotens

[

{

“output”:
“Hier\n’s what\n’s in your dataset\n:\n\n—\n\n\n## Dataset Overview\n\n\nDataset: \nCASUSER.CARS\n | Rows\n: 428 |\n Columns: \n15\n\nThis is\n a classic car\n-spec\nifications dataset\n — one row per\n car model (2\n004 model\n year\n),\n with who\n made it,\n what\n kind\n of car it is\n, and its\n mechanical\n/\nprice\n specs.\n\n### Variables\n\n\n| Variable |\n Type | Missing\n | Missing\n % | Status |\n\n|:\n--------\n-|:-----\n|\n--------:|----------\n:\n|:------\n|\n\n| Make | Text\n | 0 |\n 0\n% | :white_check_mark: (\n38 brands,\n e.g. Toyota\n \n28, Chevrolet\n 27,\n BMW 20\n) |\n| Model\n | Text | \n0 | 0\n% |\n :warning: \n425 distinct —\n essentially\n a unique ID\n per row |\n|\n Type | Text |\n 0 | \n0% | :white_check_mark:\n \n6 categories:\n Sedan 262\n (\n61%), SUV\n 60\n, Sports\n 49, W\nagon 30,\n Truck 24,\n Hybrid 3\n |\n| Origin |\n Text | 0\n | 0%\n | :white_check_mark: 3\n categories\n: Asia 158\n (\n37\n%), USA 147\n (34\n%), Europe 123\n (29\n%) |\n| Drive\nTrain | Text |\n 0 | \n0% | :white_check_mark:\n 3 categories:\n Front 226\n (53\n%), Rear 110\n (26\n%), All 92\n (21\n%) |\n| MS\nRP | \nText\n :warning: | 0\n | 0%\n | stored\n like\n \"$21,\n739\" — needs\n cleaning to use\n as a number |\n\n| Invoice | \nText :warning:\n | 0 |\n 0% |\n stored like \"$\n20\n,189\n\" — same issue\n |\n| EngineSize\n | Number | \n0 | 0\n% | :white_check_mark: litres\n,\n 1.3\n –\n 8.3\n, mean\n 3\n.2 |\n|\n Cylinders |\n Number | \n2 | \n0.47%\n |\n :warning: only variable\n with missing values\n |\n| Horsepower\n | Number | \n0 | 0\n% | :white_check_mark: \n73–500\n hp, mean \n216 |\n| MP\nG_City |\n Number | 0\n | 0%\n | :white_check_mark: 10\n –60\n , mean 20\n .\n1 |\n| MP\nG_Highway\n | Number | \n0 | 0\n% | :white_check_mark: \n12–66,\n mean 26\n.\n 8 |\n| Weight\n | Number | \n0 | 0\n% | :white_check_mark: lbs\n, 1,\n 850–7\n ,190, mean\n 3,578\n |\n| Wheelbase\n | Number | \n0 | 0\n% | :white_check_mark: inches\n, 89\n –144\n , mean 108\n |\n| Length |\n Number | 0\n | 0%\n | :white_check_mark: inches\n, 143\n –238\n , mean 186\n |\n\n### Things to\n watch out for\n\n\n- MS\nRP and Invoice are\n text\n, not numbers\n — they’re stored\n with\n $\n and commas\n (e.g.\n \"$36\n,945\").\n Any\n analysis using\n price\n must\n strip\n those first.\n Clean\ned,\n MS\nRP runs\n $10,280\n –\n $192,465\n (mean ≈\n $32,775\n) and Invoice\n $\n 9,875–\n $173,560\n (mean ≈ $\n 30,015).\n\n- Cyl\ninders has 2\n missing values (\n 0.47%)\n — negligible, but\n worth knowing\n before\n any test\n .\n- Model\n has\n 425 distinct values\n out\n of 428 rows\n ** — it’s\n effectively\n a unique\n identifier, not\n a grouping\n variable.\n Don’t use\n it as\n a category in\n a test.\n-\n Cylinders\n (\n 7 distinct\n values) is\n a numeric column\n that really\n behaves like a\n category —\n 3, \n 4, 5\n , 6,\n 8, \n 10, 12\n .\n Treat\n it as a group\n label\n if\n you compare\n across\n it, not as\n a continuous measurement\n .\n\n### Example\n rows\n\n| Make\n | Model | Type\n | Origin | Drive\nTrain | MSRP\n | Engine\nSize | Cyl\n |\n HP\n | MPG_C\n | MPG_H\n | Weight |\n|:\n—|:—|:\n—|:—|:\n—|:—|\n—:|—:|\n—:|—:|\n—:|—:\n|\n| Acura\n | MDX |\n SUV | Asia |\n All | $36\n,945 | \n 3.5 |\n 6 | \n 265 | 17\n | 23 |\n 4451 |\n\n| Acura |\n RSX Type S\n 2dr |\n Sedan | Asia\n | Front | $\n 23,820 |\n 2.0\n | 4 |\n 200 | \n 24 | 31\n | 2778\n |\n| Acura\n | TSX \n 4dr | Sedan\n | Asia | Front\n | $26,\n 990 | 2\n .4 | \n 4 | 200\n | 22 |\n 29 | \n 3230 |\n\n—\n\n\nIn\n short:** \n 428 car\n models with\n brand\n , vehicle\n type, origin,\n dr\n ivetrain, price\n (as text\n ), and eight\n numeric specs. The\n data is very\n clean — only \n 2 missing cells\n in\n the whole table\n — and the main\n practical\n got\n cha is that the\n two price columns need\n their\n $/\n commas stripped before\n you\n can compute\n with\n them.\n\nIf you\n want to go\n further\n — e\n .g. \n does\n horsepower differ by\n car type,\n or by\n origin?\n — that’s a\n hypothesis\n question, and you\n 'd select\n the **Test hypothesis\n ** block. Want\n me to set\n that up?”

}
]

Informationen zu Ihrer n8n-Installation

  • n8n-Version:
    2.45.6
  • Datenbank (Standard: SQLite): Postgres
  • n8n EXECUTIONS_PROCESS-Einstellung (Standard: own, main): Standard
  • n8n ausführen über (Docker, npm, n8n Cloud, Desktop-App): Docker
  • Betriebssystem: Linux

Hey @J_Bom, während du auf eine Antwort wartest, könnten dir diese Ressourcen helfen:

Empfohlene Ressourcen

Automatisch zu deiner Frage zugeordnet.

Docs:

Forum:

@ihortom, @Akif, @GollyJer – ihr habt schon bei ähnlichen Problemen geholfen, könnt ihr euch das mal anschauen?

Automatisch vorgeschlagen von n8n’s Community-Bot. Es ist ein Pilotprojekt – bitte gebt hier Feedback.

Hi @J_Bom, das Muster in deiner Ausgabe ist ein guter Hinweis. Das extra \n taucht alle paar Token auf und trennt Wörter („Here\n’s‟, „2\n004‟, „MS\nRP‟), also sieht es so aus, als würde es an Chunk-Grenzen eingefügt, wenn die Teile der Antwort zusammengefügt werden – nicht etwas, das das Modell schreibt. Das würde auch erklären, warum das Ausführungsprotokoll des Modells sauber aussieht, während die Agent-Node-Ausgabe das nicht tut, und warum nur dieses Modell betroffen ist (neuere Mistral-Modelle können den Nachrichteninhalt als Liste von Teilen zurückgeben, statt als einen String, und wenn diese Teile mit einem Newline verbunden werden, bekommst du genau das).

Dinge, die es wert sind, ausprobiert zu werden:

  1. Wenn dein Agent-Node die Streaming-Option hat, deaktiviere sie und führe sie erneut aus. Wenn die Newlines verschwinden, bestätigt das, dass es die Chunk-Verbindung ist.
  2. Workaround, der das normalerweise umgeht: Die Mistral-API ist OpenAI-kompatibel, also kannst du den OpenAI Chat Model-Node mit einer neuen OpenAI-Anmeldedaten verwenden, deren Base URL https://api.mistral.ai/v1 ist und dein Mistral-API-Schlüssel, dann gib den Modellnamen ein. Verbinde das mit demselben Agent und vergleiche.
  3. Versuche nicht, es danach mit einem Replace zu bereinigen. Du kannst das schlechte \n nicht von den echten in deiner Markdown-Tabelle unterscheiden, also würdest du die Formatierung sowieso zerstören.

Wenn 1 oder 2 das behebt, lohnt es sich, ein GitHub-Issue mit deiner n8n-Version, der genauen Modell-ID und der vorher/nachher-Ausgabe zu öffnen, da der Mistral Cloud Chat Model-Node diese Antwortform handhaben sollte.

Ich erhalte das gleiche Ergebnis mit Streaming an oder Streaming aus.

Option 2 hat funktioniert, der Workaround mit einem OpenAI Model Node statt eines Mistral Model Node.

Kannst du das Github Issue hinzufügen? Alle Informationen sind in diesem Beitrag enthalten

Freut mich, dass die OpenAI Node Route funktioniert. Die Tatsache, dass Streaming keinen Unterschied macht, grenzt es ein: Das Modell-Log ist sauber, und dasselbe Modell verhält sich über den OpenAI-kompatiblen Endpunkt gut, daher deutet es wahrscheinlich auf die Response-Verarbeitung des Mistral Chat Model Node hin, nicht auf das Modell oder den Agent.

Am besten meldest du das Problem selbst, da du die Reproduktion hast und Nachfragen beantworten kannst. Suche zuerst in bestehenden Issues nach „Mistral

Wenn die Logs sauber aussehen, aber die Node-Ausgabe beschädigt ist, werden wahrscheinlich Streaming-Chunks mit Zeilenumbrüchen verbunden. Versuche, das Streaming in den Agent-Optionen auszuschalten, oder füge danach einen Code-Node hinzu, der die verirrten \n zwischen Tokens entfernt. Versuche auch den Mistral-Model-Node auf einer anderen API-Route, um zu überprüfen, ob es der Provider ist.

Streaming ist nicht die Ursache. J_Bom hat Streaming bereits deaktiviert und erhielt das gleiche Ergebnis, und das Ausführungsprotokoll ist sauber, also wird die Newline hinzugefügt, während der Mistral-Node die Antwort zusammenstellt, nicht durch das Modell. Anstatt den Prompt zu patchen, normalisiere nachher: ein Code-Node, der eine Newline entfernt, wenn sie zwischen zwei Nicht-Leerzeichen sitzt, wobei der Markdown-Renderer downstream erhalten bleibt.

Das ist die gleiche Grenze, die das Decompiling-Argument diese Woche betrifft: in Ordnung, wenn eine Person die Ausgabe liest, unzuverlässig, wenn etwas Downstream es byte für byte benötigt.