APIの力：AIインターフェースの影の立役者

人工知能の分野では、モデルそのものに注目が集まりがちです。より大きく、より速く、より賢く、ベンチマークの記録更新ばかりが話題になります。しかし、実際に一人の開発者が構築できるものを変える技術、すなわちAPIはほとんど評価されていません。今や最先端の計算能力は静かにインターフェースへと変貌しています。音声認識はWebSocket経由で、言語モデルはHTTPエンドポイント経由で提供され、研究は誰かが積み上げたレイヤーの上に構築できるものになりました。

私たちは最近、これを実証する小さな実験を行いました。音声でコンピュータを制御するというものです。「コンピュータ、ターミナルを開いてlsと入力」と言うと、コンピュータが音声をリアルタイムで文字起こしし、言語モデルが解釈し、ローカルでコマンドを実行します。10年前なら、この文の各部分はそれぞれ独立した研究分野でした。私たちの実装はたった半日、約400行のPythonコードで完了し、その中にはAIのコアアルゴリズムを実装した行は一行もありません。

能力がインターフェースになる

能力をAPIでラップするとはどういうことでしょうか？音声認識を例に考えましょう。WhisperLiveはオープンソースのストリーミング文字起こしサーバーで、その背後にはWhisperモデル、GPU推論エンジン、音声アクティビティ検出など、長年の研究成果が詰まっています。しかし、提供されるインターフェースはシンプルです。音声ストリームを入力すると、文字起こしテキストをコールバックで返します。同様に、llama.cppをコンテナで実行し、そのAPIと対話しました。llama.cppは独自のインターフェースを定義せず、業界の事実上の標準であるOpenAI互換チャットAPIを意図的に実装しています。

逆方向に動作するAPI

最も興味深い進展は、私たちがAIを呼び出す方法ではなく、AIが私たちを呼び出せるようになったことです。標準のチャットAPIにはツールコーリングと呼ばれるメカニズムが含まれています。ユーザーの言葉とともに、モデルに機械可読な関数リストを渡すことができます。

{
  "name": "open_application",
  "description": "デスクトップアプリケーションを名前で開く（例: 'Chromium'）",
  "parameters": {
    "name": {"type": "string"}
  }
}

ユーザーが「ブラウザを開いて」と言うと、モデルは散文で答えず、構造化された方法で応答します。

{
  "name": "open_application",
  "arguments": {
    "name": "Chromium"
  }
}

私たちの実験では、特定の文に対するルールはどこにもありません。能力を定義し、モデルが言語を処理し、インターフェースがその間の接着剤となります。

統合が新たな実装に

実験での印象的な詳細：私たちがデバッグした問題は、ほとんどが配管の問題でした——コンテナ内のライブラリのバージョン不一致、DNS設定を嫌うダウンローダーなど。APIの上に構築することは、もはや研究というよりシステム統合のように感じられます。

自分で試してみたいですか？公開インターフェースを持つ任意の2つのAIサービスを選んでください。WhisperLiveはすぐに使えるDockerイメージを提供し、llama.cppは任意のオープンウェイトモデルを提供します。それらを何かに接続するだけです。「それはクールな研究プロジェクトになる」と「それは土曜の午後の趣味になる」の距離は縮まりました。あとは部品を組み合わせるだけです。実験のコードはこちらで公開しています。