AIを複数使うと、依頼ごとにどのモデルに任せるかを選ぶ必要があります。この選択をローカルで動く小型モデルに任せ、回答は選択されたクラウドAIに担当させる構成を試しました。
役割を分ける
今回のJeffは自由な文章を生成する回答役ではなく、最後のユーザー入力から候補を選ぶ分類役です。選択肢には、通常作業、難しい技術推論、文章作成、複雑な文書検討、アイデア出しという5種類の用途を設定しました。これは私の初期設定であり、モデルの優劣を同条件で比較した結果ではありません。
処理の流れは「依頼文 → Mac内で分類 → 候補を1つ選択 → 選ばれたクラウドAIが処理」です。Hermes側の拡張で分類結果を受け取り、既存のモデル呼び出しにつなげました。
つまずいた点
Hermesのモデル設定にローカルAPIのURLを直接書くと、その接続が独自の接続先として扱われ、今回の振り分け拡張を通らないことがありました。私の構成ではURLを拡張側に持たせ、モデル設定では拡張を指定する形にしています。これは利用した環境での観測であり、あらゆるバージョンに当てはまるとは限りません。
失敗時と低確信度の扱い
分類結果をそのまま必ず採用せず、確信度が0.60未満の場合、接続に失敗した場合、画像など対象外の入力の場合は、既定のモデルへ回すようにしました。確信度は「クラウドAIの回答が正しい確率」ではありません。
観測できたことと未検証のこと
準備後のローカル分類では、日本語のお礼メールの例で約54msでした。この時間は分類処理のみで、クラウドAIが回答を終えるまでの時間ではありません。数件の観測であり、日本語全般の分類精度を示すベンチマークでもありません。
実クラウド接続では、短い人工タスクでツール呼び出しとストリーミングを確認しました。一方、5モデルすべての実応答や、日本語の振り分け精度の評価は未実施です。
また、ローカルなのは選択処理だけです。回答側のクラウドAIには従来どおり会話情報などが渡ります。機密情報を外に出さず回答まで完結する構成ではありません。
構成の背景、接続のつまずき、導入時に確認した範囲は、無料の導入記録にまとめています。