𝗟𝗟𝗠 𝗚𝗮𝘁𝗲𝘄𝗮𝘆𝘀: 𝗥𝗼𝘂𝘁𝗶𝗻𝗴, 𝗙𝗮𝗹𝗹𝗯𝗮𝗰𝗸𝘀, 𝗔𝗻𝗱 𝗦𝗲𝗺𝗮𝗻𝘁𝗶𝗰 𝗖𝗮𝗰𝗵𝗶𝗻𝗴

たった一行のコードが、AI予算を台無しにする可能性があります。

アプリケーションに特定のモデルプロバイダーをハードコードしてしまうと、次の3つのリスクに直面します。

  • 単純なタスクに対して高額なコストがかかる。
  • プロバイダーがダウンした際に、サービスが完全に停止する。
  • 同じ回答に対して、何千回も料金を支払うことになる。

LLMゲートウェイは、アプリケーションとモデルの間のプロキシとして機能します。主に「ルーティング」「フォールバック」「キャッシング」という3つの重要な役割を担います。

  1. Routing（ルーティング） 多くのアプリは、すべてのリクエストを最も高価なモデルに送信しています。これは非効率です。ルーティングを活用して、簡単なタスクを安価なモデルに振り分けましょう。
  • 静的ルーティング（Static routing）：ユーザー層やタスクの種類に基づいたルールを使用します。
  • コスト/レイテンシ・ルーティング（Cost/Latency routing）：利用可能なモデルの中から、最も高速または最も安価なものを選択します。
  • 難易度ルーティング（Difficulty routing）：小型モデルを使用して、そのタスクに大型モデルが必要かどうかを判断します。 研究によると、スマートなルーティングを行うことで、品質を維持したままコストを80%以上削減できることが示されています。
  1. Fallbacks（フォールバック） プロバイダーは失敗することがあります。レート制限に達したり、オフラインになったりするためです。ゲートウェイはフォールバック・チェーンを管理します。プライマリモデルが失敗した場合、ゲートウェイはリスト内の次のモデルを自動的に試行します。 障害を悪化させないために、以下のパターンを使用してください。
  • 指数バックオフ（Exponential backoff）：リトライの間隔を広げ、負荷がかかっているプロバイダーへの過剰な負荷を避けます。
  • サーキットブレーカー（Circuit breaking）：故障しているプロバイダーへのトラフィック送信を一定期間停止します。これにより、タイムアウトを待つのではなく、即座にフェイルオーバーが可能になります。
  1. Semantic Caching（セマンティック・キャッシング） 標準的なキャッシングは、テキストの完全一致を探します。しかし、ユーザーは質問の言い回しが異なるため、LLMにおいてはこの手法は機能しません。 セマンティック・キャッシングは「意味」に着目します。プロンプトをベクトルに変換し、データベース内に類似した質問が存在するかどうかを確認します。
  • メリット：キャッシュヒットはわずか5msで、コストは0ドルです。一方、モデルの呼び出しには数秒かかり、トークン費用が発生します。
  • リスク：類似度のしきい値（similarity threshold）を低く設定しすぎると、誤った回答が返される原因になります。しきい値が緩すぎると、「パスワードのリセット」に関する質問に対して「メールアドレスの変更」に関する回答が返されるといったことが起こり得ます。

Build or Buy?（自作か、購入か？）

  • 自作（Build）：基本的なフォールバックや完全一致キャッシングなど、シンプルなニーズに適しています。
  • 購入/オープンソース（Buy/Open Source）：セマンティック・キャッシング、オブザーバビリティ、および複雑なフェイルオーバー・ロジックが必要な場合は、LiteLLMのようなツールやマネージドサービスを利用してください。

ゲートウェイは単なる「機能」ではなく、「インフラ」です。コードベースの至る所にモデル呼び出しを散らばらせるのはやめましょう。コストと信頼性を制御するために、その手前にゲートを設置してください。

Source: https://dev.to/nazar_boyko/llm-gateways-routing-fallbacks-and-semantic-caching-1n2b

Optional learning community: https://t.me/GyaanSetuAi