構造化判断の最適解：Liquid AI「d1」

出典

Decision Models - Liquid AI

関連情報

Liquid AI: https://www.liquid.ai/, https://x.com/liquidai, 
 https://huggingface.co/LiquidAI

関連記事

現在の生成AIは本質的に「前後の文脈から次に来る単語（トークン）を確率的に生成し続けるオートコンプリート機械」です。

しかし、システムが求めているのは多くの場合「文章」ではなく、明確な条件分岐のための「確定した数値やカテゴリ」ではないでしょうか。

この構造的なギャップに対し、極めて本質的なアプローチで切り込んできたのが、革新的なニューラルネットワーク技術で世界から注目を集めるLiquid AIです。彼らが発表した新しいモデル群「d1」は、これまでの生成AIの常識を心地よいほど鮮やかに覆してくれます。出典の情報を基に示します。

「出力トークン0」という逆転の発想

Liquid AIが発表した「d1」は、文章を生成するためのモデルではありません。分類、ルーティング、スコアリングといった「構造化された意思決定（Structured Decisions）」のためだけにゼロから設計された、まったく新しいアプローチの決定モデル（Decision Model）です。

最大の特徴は、「生成される出力トークンが完全に0である」という点にあります。
従来のLLMのように、1トークンずつ順番に文字を吐き出していくプロセス自体が存在しません。入力されたコンテキスト（State）を一度読み込むと、あらかじめ定義された評価軸に基づいてキャリブレーションされた確率値を、単一のリクエストでダイレクトに算出します。
APIのレスポンス例を示します。

JSON
{
  "model": "d1:free",
  "answers": {
    "is_complaint": {
      "type": "noul",
      "noul": 0.999
    }
  },
  "usage": {
    "input_tokens": 84,
    "output_tokens": 0
  }
}

「output_tokens: 0」という表記が示す通り、文字を生成する処理を一切行っていません。
文字を生成しないということは、推論にかかる遅延（レイテンシ）を物理的な限界まで圧縮できることを意味します。さらに、JSON構文の崩壊やハルシネーション（もっともらしい嘘）といった、テキスト生成モデル特有の構造的トラブルからも完全に解放されます。

実装を極限までシンプルにする「3つのプリミティブ」

d1のAPI設計は、ソフトウェア開発者の直感に驚くほど素直に寄り添っています。開発者が行うべき問いかけは、以下の「3つの型」のいずれかにマッピングするだけで完結します。

1. Noul（確率的ブーリアン）

「このメッセージはクレームか？」「スパムか？」「有害なコンテンツを含んでいるか？」といった二者択一の問いに対し、0から1の間の確率を返します。

単なるTrue/Falseではなく、「0.92」といった信頼度のグラデーションとして得られる点がポイントです。これにより、「0.8以上なら即座に自動遮断」「0.2以下ならそのまま通過」「中間領域のグレーゾーンだけを人間のオペレーターに回す」といった、堅牢な運用ルールを数行のコードで実装できます。

2. Choice（多肢選択・ルーティング）

「この問い合わせはどのチームが対応すべきか？」のように、複数のカテゴリから1つを選定し、すべての選択肢に対する確率分布と信頼度（confidence）を返します。

単に1位を返すだけでなく、2位の候補にどれくらい確率が分散しているかも把握できるため、「判断が拮抗している場合はフォールバック用のキューに流す」といったフェイルセーフ設計が極めて容易になります。

3. Score（順序尺度スコアリング）

「この障害の緊急度はどれくらいか？」のように、あらかじめ定義した段階的な基準（ルーブリック）に基づいて、重み付けされた連続値（スコア）を算出します。

例えば「即時対応」「本日中」「通常キュー」といった基準を渡すことで、「2.9995」といった精確な数値を返し、SLAに応じた即時エスカレーションのトリガーとしてそのまま利用できます。

実際にシステムへ組み込む手順

この仕組みを日々のプロジェクトへ導入するフローも、非常に洗練されています。

手順1：アカウント開設とAPIキーの発行

まずは console.liquid.ai にアクセスしてサインアップを行います。ダッシュボードの「API Keys」から新しいキーを作成します。生成されるキー（`liquid_` で始まる文字列）を環境変数に設定します。

BASH
export LIQUID_API_KEY="liquid_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

手順2：SDKのインストール

Python環境であれば、公式の専用クライアントライブラリを導入します。TypeScript（Node.js）環境でも同様に提供されています。

BASH
pip install typesafe-sdk

手順3：単一コールで複数の問いを同時に投げる

d1の真価が発揮されるのは、これら「Noul」「Choice」「Score」をひとつのリクエストにまとめて同時に評価させる場面です。

例えば、ユーザーからのサポートチケットを処理する際、以下のように記述します（わかりやすくするために和訳結果を示しています）。

PYTHON
import os
import json
from typesafe_sdk import TypeSafeClient, Noul, Choice, Score

client = TypeSafeClient(
    api_key=os.environ["LIQUID_API_KEY"],
    base_url="https://api.liquid.ai",
)

# 評価対象のコンテキスト（テキストでもJSON文字列でも可）
ticket = {
    "message": "決済画面でクーポンを適用しようとすると画面が真っ白になります。至急対応してください。",
    "account": {"plan": "enterprise", "arr": 52000}
}

result = client.system_one(
    model="d1:free",
    state=json.dumps(ticket),
    questions={
        # 1. バグかどうかを確率で判定
        "is_bug": Noul(
            instructions="顧客はソフトウェアの不具合を報告していますか？"
        ),
        # 2. 担当部署の決定
        "team": Choice(
            instructions="どのチームがこのチケットを対応すべきですか？",
            criteria={
                "billing": "請求、支払い、返金に関する問い合わせ",
                "engineering": "クラッシュ、不具合、技術的な動作不良",
                "account": "プラン変更やログイン関連の問題"
            }
        ),
        # 3. 緊急度の数値化
        "urgency": Score(
            instructions="チケットの緊急度を判定してください。",
            criteria=[
                "低: 業務影響なし、通常対応",
                "中: 一部機能に影響、24時間以内に対応",
                "高: 決済不能やシステム停止、4時間以内に対応"
            ]
        )
    }
)

answers = result.answers
print(f"不具合判定確率: {answers['is_bug'].noul}")
print(f"配属チーム: {answers['team'].choice} (確信度: {answers['team'].confidence:.2f})")
print(f"緊急度スコア: {answers['urgency'].score:.2f}")

一度のAPIコールで入力テキスト全体が解析され、複数の判定結果が整然とした型付きデータとして手に入ります。パーサーエラーを恐れて何重もの例外処理を書く必要は、もうありません。

生成AIの「適材適所」がもたらすアーキテクチャの進化

長文の要約やアイデア出し、自然な対話、コード生成といった領域において、従来のLLMが持つ表現力は今後も不可欠です。

しかし、入力値のフィルタリング、ルーティング、セーフティチェック、エージェントのツール実行承認といった「明確な境界線を持つ判断処理」にまで、高コストで遅延の大きい生成モデルを使い続ける必要はあるでしょうか。

ひとつの巨大なモデルにすべての役割を背負わせるモノリシックな設計から、「判断（Decision）」は超高速な専用モデルに任せ、「表現（Generation）」は表現力豊かな生成モデルに委ねるという責務の分離へ。

システムの裏側で動いている「実は文字を生成する必要がなかった処理」を見直すことが、堅牢で無駄のない次世代アプリケーションを構築するための第一歩になるはずです。

#エージェント #スタートアップ #米株投資 －関連記事の検索