discourse-ai API にはリグレッションが必要だと思います

開発
1

Discourse AI は現在、コンテンツに構造化された出力を利用していますが、構造化された出力は多くの API プロバイダーではサポートされていません。私の国にある DeepSeek や Qwen のようなほとんどの AI プロバイダーはそれを行っていません。構造化された出力を使用すると、API の選択肢が主要な AI プロバイダー数社に限定されてしまいます。

Discourse AI が現在のプロバイダー選択の制限を打破する必要がある場合、構造化された出力を諦めることが不可欠であり、それなしでは何も実際には壊れません。解決策として、単純な一意の区切り文字を使用するか、JSON スキーマや例を提供して AI に JSON を生成するように依頼することができますが、構造化された出力を使用しないのはなぜでしょうか。

「いいね！」 1
2

中国のMoonshot AI Kimi K2をAPIエンドポイント経由で試していただけますか？

ベースAPI URLは https://api.moonshot.cn/v1 のようです。

構造化された出力要件を導入したのは、モデルが「要約はこちら」を追加したり、AIヘルパーの提案タイトルのリストを取得する際に解析に失敗したりするなどの問題について、数千件の苦情を経験したためです。現在、翻訳では、出力に余分なものを追加しないことを信頼できる何百万ものLLM呼び出しが必要になるため、さらに悪い問題になっています。

信頼性と構造化された出力の一般的な利用可能性を考慮して、サポートされているプロバイダーでこの決定を下しましたが、OpenAIプロバイダーでAPIリクエストから構造化された出力を無効にするチェックボックスを追加するPRには前向きです。

「いいね！」 1
3

それは良いですね。私はDiscourseチームに要求することはできませんし、できませんので、いくつか提案をさせていただきます。

より堅牢な解析のために古い「セパレーター」ソリューションを使用し、以下のようなXMLライクな生のコンテンツを使用します。

<SUMMARY_START>
要約コンテンツ。
<SUMMARY_END>

<SUGGESTIONS_START>
<SUGGESTION_START>
提案1
<SUGGESTION_END>
<SUGGESTION_START>
提案2
<SUGGESTION_END>
...
<SUGGESTIONS_END>

そして、<START>と<END>の外側にあるものは気にしないようにします。最も愚かなプロダクションAIモデルでもラベルを正しく処理できると信じています。

AIに追加の説明を追加しないように依頼し、そのチェックボックスを開いた場合に管理者に潜在的な問題について警告します。ありがとうございます。

Discourse AIが生成するリクエストボディがどのようなものかわかりませんが、もしそうでない場合は、システムプロンプトを最初のsystemロールのメッセージに、ベクトルデータベースのクエリ結果を次のsystemロールのメッセージに、投稿コンテンツやその他の実際のデータをuserロールのメッセージに入れるだけです。