こんにちは、皆さん
エンタープライズ環境で、クラウドプラットフォームのサポート用ディスカッションボードとしてDiscourseを使用しています。
Discourse AIプラグインをいくつかのユースケースに利用したいと考えており、OpenAI互換の内部AIエンドポイントも持っています。
問題は、これらのエンドポイントへの送信リクエストに、事前に取得する必要がある内部m2m認証エンドポイントからのoauth2トークンを含む認証ヘッダーを含める必要があることです。
Discourseをホストしているec2インスタンス上のローカルプロキシなど、いくつかのアプローチを検討しました。これは、その認証情報でリクエストを強化できます。
別のアプローチは、オーソライザーLambdaがトークンを取得するAPIゲートウェイです。
現時点では、Discourse AIプラグイン自体に追加できるツールについて理解していません。
私が考えていることを達成するためにそれらを使用できますか？
サポートに感謝し、素晴らしい一日をお過ごしください！
よろしく、
WS
これは難しいですね。
通常、私たちは人々を混乱させるため、あまり多くの設定項目を追加したくありませんが、これが現在解決するのが難しいことは理解しています。別の設定項目が必要になるかもしれません。
1つの選択肢は、OpenAI互換のものに「カスタムヘッダー」セクションを設けることです。
ツールでは、これは非常に複雑なワークフローを作成するため、簡単に解決できませんでした。また、ツールが必要とするすべての情報を簡単に渡す能力もありません。
@Falco さん、どう思われますか？
これは機能リクエストなので、機能に移動します。
@sam様
ご返信とご意見ありがとうございます。
カスタムヘッダー用のフィールドだけでは不十分です。トークンは、各API呼び出しの前に動的に取得する必要があるためです。
代わりに、送信される呼び出し全体を、独自のコードで変換できるようなパイプライン/ミドルウェアのようなものはどうでしょうか？
皆さん、本当にありがとうございます。良い一日をお過ごしください！
WS
うわー、これは本当にかなり高度ですね。
カスタムツールが十分に豊富な機能を持っていれば、これを達成できると思います…少しルーブ・ゴールドバーグ・マシン（複雑すぎる機械）のように感じますが、想像してみてください。
これはかなりの量の変更であり、維持するのが非常に困難になるでしょう。
代替案としては、Discourse-AIに依存し、独自のダイアレクトとエンドポイントを定義する新しいカスタムプラグインを定義することです。これは間違いなく最も簡単な方法です。
この特定のニーズは、NginxとLUAスクリプティングのような軽量プロキシを介して解決する方がはるかに簡単なので、@Wurzelseppi はそのルートを進む方が良いと思います。
皆さん、こんにちは。
私のような小規模ユーザーの必要性について真剣に議論していただき、ありがとうございます。皆さんの献身にはいつも感銘を受けています（冗談ではありません :-)）。
ええ、全体がec2インスタンスで実行されており、すでにAWS API Gateway → Lambda → LLMエンドポイントの経路を選択しました……
Discourseに組み込まれていればもっとクールですが、もちろんそれがもたらす複雑さも理解しています……
お時間と、ここで全ユーザーを助けてくださるお時間に感謝いたします。
このソフトウェアは、その成熟度だけでなく、サポートしてくれる人々のおかげでも、これ以上の掲示板ソフトウェアは考えられません。
皆さん、素晴らしい一週間を……そして今のまま yourselves でいてください！
Cheers,
WS