昨日アップデートしました が、ログに多くのエラーが発生しています：
Discourse AI: structured output response was not valid JSON, falling back to best-effort parsing (311 bytes)
HTTP レスポンスを確認しましたが、問題はありませんでした。その後、rails console でテキストを試しました：
...
discourse(prod)> p = JsonCompleter.new
=>
#<JsonCompleter:0x00007f48763b0270
...
discourse(prod)> p.parse text
=>
{"spam" => false,
"reason" =>
"..."}
discourse(prod)> p.parse DiscourseAi::Utils::BestEffortJsonParser.escape_control_characters(text)
(discourse):14:in '<main>': unexpected token "\\" (JsonCompleter::ParseError)
どうやら、Discourse が解析前に改行文字をエスケープしていた ことが原因で、エラーが発生していました。
Falco
(Falco)
2
それは警告であり、エラーではありません。
とは言え、人々がこれらについて心配し続けているので、ログレベルを INFO に変更します 
技術的にはその通りですが、これはコードのバグを示しています。フォールバック機能が動作しているためエラーは発生しませんが、INFO レベルに変更して隠蔽するのではなく、根本原因を修正する方が良いでしょう？
JSON では改行文字を空白として許可していますが、文字列外でのエスケープシーケンスは許可されていません。しかし、エスケープ関数はこれをエスケープ処理してしまいます。これを修正するには、JSON 仕様に従って ASCII 文字 0x0 から 0x1f まで（両端を含む）のみをエスケープするように変更できます。（Ruby の書き方が分からないので PR は作成できません。）
説明のために、以下は有効な JSON です：
{
"key": "value"
}
以下はエスケープされたもので、無効であり、問題の原因となっています：
{\u000a "key": "value"\u000a}
llama-server -hf mradermacher/Qwen3-4B-Instruct-2507-GGUF:Q4_K_M
sam
(Sam Saffron)
7
4B（40億パラメータ）モデルは準拠に苦労するでしょう。性能は向上しつつありますが、これは明らかに古い方です。
4Bモデルを使用する場合は、より最近のものを推奨します… Qwen 3.5-4B や Gemma 4 E4B を試してみてください。
llama.cpp は、スキーマに準拠するトークンのみを抽出することで、スキーマを強制していると考えています。また、tcpdump でレスポンスをキャプチャし、返されたレスポンスが有効な JSON であることを確認しました。
ただし、文字列の外部にスペースや改行が含まれており（つまり、インデントが整えられた JSON である）、これらの改行が Discourse によってエスケープ処理されていたため、無効な状態になっていました（Rails コンソールで確認済み）。
ちなみに、スパム検出機能を使用しています。