チームの機材でthai-chat(qwen38)モデルを運用してしばらく経ち、数字で答えなければならない質問が一つある。「本当にz.aiに代わるほど良いのか」。数字なしの回答は説得力がないので、50ケース5カテゴリのフルテストセットを両システムで対戦させ、どの回答がどちらから来たか分からない状態でモデルに採点させた。

テスト方法

  • bomLLM側:llm.siam2r.com(自社のLiteLLMルーター)経由のthai-chatモデル
  • クラウド側:z.aiのAPIを直接通すglm-4.5-flash(thinkingオフ、予算通りmax_tokens 2000)
  • 5カテゴリ、各10ケース:タイ語LINE Q&A、シグナル要約(RAGSA)、カテゴリ分類、翻訳、厳格なフォーマットのエッジケース
  • 主要判定者:qwen38モデルが各ケースに1-10点の採点。残りのクォータで18ケースにGemini 2.5 Flashをクロスグレーダーとして使用

総合スコア

カテゴリ bomLLM z.ai ratio
LINE Q&A(タイ語) 8.93 6.33 1.41
シグナル要約 RAGSA 8.53 5.80 1.47
カテゴリ分類 1.00 (accuracy) 1.00 引き分け
翻訳 9.63 8.50 1.13
エッジケース(厳格なJSON) 8.10 8.47 0.96
総合50ケース 7.24 6.02 1.20

速度差はさらに顕著:bomLLMのp50=5.19秒(p95=19.9)、z.aiのp50=35.1秒(p95=85.6)— 中央値で約7倍高速。bomLLMのエラー率は2/50ケース(どちらも実行時間が30秒を超えた厳格なフォーマットケース)。

自分自身に正直になるべきこと

このベンチマークには、大きな意思決定に使う前に注意深く読むべき点がある:

  1. 判定者と参加者が同じ系統 — qwen38がqwen38の回答を判定するのは有利に働く。Geminiが独自に判定したサブセットでは比率は1.28に低下し、まだ勝利だが1.44ほどの圧倒的差ではない
  2. テストプロンプトが短い(約310トークン)— 数千トークンの長いコンテキストを送る実際の作業は別問題。7,000トークンのプロンプトでローカル機材がEAの90秒制限を超えて遅くなり、クラウドに戻らざるを得なかった実例がある(6,928トークンプロンプトの記事を参照)
  3. エッジケースが実際の弱点 — 厳格なJSONと混在言語のケースは唯一敗れたカテゴリ(0.96)。固定フォーマットの作業はフォールバックにルーティングすべき

我々のチームへの結論

タイ語チャット、シグナル要約、翻訳の作業では — 自社のbomLLMが品質・速度の両面で明確に勝利し、トークン単価のコストもゼロ。3-4Kトークンを超える長いプロンプトや誤りが許されない厳格なフォーマットの作業では、現時点で最も安全な経路はクラウド+フォールバックを作業種別に応じて切り替えること。これはすでにルーター上に構築したアーキテクチャである。

実際のシステム移行の意思決定は、私が常に最終判断を下す — ベンチマークの役割は実数値を提示することだけであり、代わりにボタンを押すことではない。