1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • Echoは、GLM-5.2、Kimi K2.7 など複数のオープンウェイトモデルをリクエストごとに組み合わせ、単一モデルにすべての作業を任せる方式の限界を補う
  • リクエストごとに計算量と参加モデルを決め、結果の結合方法まで調整することで、単純なプロンプトには少ない推論リソースを使う
  • 最初の評価構成ではプール内の最高の個別モデルを一貫して上回り、Fableに近い総合結果を約3分の1の推論コストで達成した
  • 全体的には弱いモデルでも特定の問題や組み合わせでは有用なほど能力が相互補完的だが、割り当てや結合を誤って決めるケースも残っている
  • チャットインターフェースとOpenAI互換APIを公開しており、品質測定がさらに難しいコーディング・エージェント作業でも同じアプローチが有効かを試験中である

モデル選択と結果の結合

  • 初期実験では GLM-5.2、Kimi K2.7 などを同一評価に投入し、問題ごとに有用なモデルと適切な出力結合法を事前に知っていると仮定して結果を測定した
    • この仮想システムは、プールに含まれるどの個別モデルよりもはるかに高い性能を示した
    • 結果を確認した後でしか良い判断を識別できないため、実運用には使えず、Echoは事前情報なしでもその利点の一部を取り戻そうとする試みである
  • リクエストの特性に応じて、必要な計算量、参加モデル、結果の結合方法を選択する
    • 単純なプロンプトには比較的少ない推論を割り当てる
    • 別の問題では、複数のモデルがそれぞれ異なる部分を処理するように構成する
  • モデルの能力は相互補完的であり、全体性能が明らかに低いモデルでも、特定の問題や組み合わせでは非常に有用でありうる

評価結果と公開テスト

  • 最初の評価構成では最高の個別モデルより一貫して高い性能を記録し、比較対象の Fable とおおむね同等の総合結果を約3分の1のコストで達成した
  • 一部のリクエストでは計算割り当てやモデル結合を誤って決定しており、現在こうした失敗事例を分析している
  • コーディングおよびエージェント作業は各判断の品質を測定するのがはるかに難しく、同じアプローチが通用するかを別途試験中である
  • 外部テスト向けに Echo チャットインターフェースOpenAI互換 API を提供している
  • 動作説明動画評価手法・個別モデルの結果・コスト・現在の限界 を公開し、異常な失敗や直感的でないリソース割り当て事例についてのフィードバックを求めている

1件のコメント

 
GN⁺ 3 시간 전
Hacker News の意見
  • 応答が得られるかのように見える Message Echo の入力欄を見せた後、登録ページへ送る典型的なダークパターン
    サイトが促した最初の行動から足止めされたので、すぐに離脱したし二度と訪れないと思う

    • 自分もまったく同じように感じた。こういうダークパターンが大嫌いなので、もうこの製品にはまったく興味がない
    • 今、削除しているところです
    • 一方で、ログイン前のリクエストを許可すると、制作者が最初のクエリ費用を負担しなければならず、悪用されて高額な請求が発生する可能性もある
      AI製品を作る立場からは、理解できる選択でもある
  • Echoを使い、フィードバックをくれた皆さんに感謝します。まさにこうした理由から早期に公開しました
    より難しいコーディング・エージェント系ベンチマークを含め、最新の最高水準との差をより正確に示す評価を引き続き公開し、公開評価ダッシュボードも拡充していく予定です。評価ダッシュボードのUIと登録フローで見つかった問題は本番環境で修正しました
    Echoの体験にクレジットカードは不要で、アカウントごとにAPIとチャットで使える無料クレジット10ドル分が提供されます
    単純なモデルルーティングより広く、オープンウェイトモデル間で推論リソースを効率的に配分する方法を探っています。どのモデルを使うかだけでなく、リクエストにどれだけの計算を投入し、中間結果をどう結合するかも決定します
    アンサンブル自体はランダムフォレスト以前から知られていますが、Echoの核心は、リクエストごとにアンサンブル全体の費用を払わずに、それをモデル化して活用する点です。FusionやFuguと概念的に似た面はあっても、構造と最適化目標は異なります

    • 小さなフィードバックですが、create password が特殊文字を要求する一方、Google パスワード マネージャーがデフォルトで生成するパスワードには特殊文字がありません
      2桁の長さの英数字の組み合わせで十分に見えますが、アイデア自体は素晴らしいです
    • なぜダークパターンを使ったのか疑問です。興味はありましたが、今はなくなりました
    • 登録を1回試しただけなのに、too many authentication attempts エラーが発生しました
    • ダークパターンを削除すべきです
    • オープンウェイトを繰り返し強調しているのに、どのモデルを使っているのかはまったく公開していません
      透明性がないなら、オープンウェイトモデルを使うことがエンドユーザーにどんな利点をもたらすのか分かりません
  • Fable級の結果を3分の1のコストでという説明は、大きく補助されている月額200ドルプランのユーザーには魅力的に見えない
    このプランがいつまで維持されるかは分からないが、それまでは公開API価格の3分の1でもそれほど魅力的ではない

    • 月額200ドルプランで週間のFable利用量を使い切った後、販促用クレジット200ドルで中規模のコーディング計画を実行したところ、1時間15分で120ドルを使った
      複数のサブエージェントが同時に実行され、Claudeが安いモデルを使えという指示を忘れて複数のFableインスタンスが動いたせいもあるが、トークン単位の課金は耐えがたい。月200ドルでも高いが、一晩で200ドルは法外だ
    • 業務で使う法人顧客は補助付きプランを利用できないため、全体の利用量に占めるそうしたプランの割合は少数である可能性が高い
    • このプランは**新規株式公開(IPO)**までは維持されるだろうが、その後は長く続かないと思う
      月額200ドルのユーザーがAPIクレジット1万ドル分を使えば、ユーザーあたりの利益率は-98%で、損益には役立たない
    • 利用量制限や、境界線を越えたときのアカウント停止を避ける目的なら話は変わる
    • Anthropicから今日受け取ったメールによると、Fable 5は7月20日から利用量クレジット方式に移行する
      引き続き使えるが従量制クレジットが必要で、サブスクリプションプランの利用量制限には含まれない
  • 今後数年以内に、最高のモデルという概念がニッチに追いやられても驚かない
    ほとんどの運用システムでは、いつ安いモデルを使い、強力なモデルへ切り替え、複数の出力を結合するかを知っているオーケストレーターが勝者になり得る

    • それがGemini CLIの発想ではないのか気になる
    • 進化の分岐は非常に多いが、結局は最高のモデルがニッチな概念になる方向へ収束しそうだ
      大きな流れはオンデバイスモデルであり、モデルがチップダイに入り、数年ごとにチップセットを交換する形もあり得る。そうした環境では大手クラウド事業者が損をするだろう
  • 最も興味深い結論の1つは、モデルのサイズよりモデルの選択のほうが重要になり得るということだ
    業界はより大きなモデルに注力してきたが、リクエストを適切な専門モデルの組み合わせへ知的にルーティングすれば、はるかに低いコストでより大きな改善が得られそうだ
    弱いモデルも役に立たなくなったわけではなく、それぞれ異なる領域で優れており、他のモデルと組み合わせると価値が大きく高まる可能性がある。ただし、適切なモデル選択がはるかに難しいコーディング・エージェント作業でも成り立つのかは気になる

    • 各タスクに専門性を持ち、相関の低い小型モデルを強力にアンサンブルすると、非常に興味深い結果が得られる
      エージェント・コーディング作業は粒度のためにさらに複雑です。各モデルをいつ、どのように、そしてセッション・目標・タスク・会話ターン・ツール呼び出しのどの抽象化レイヤーで使うかを決める必要があり、現在積極的に研究しています
  • 実際にいくつかのユーザー体験上の欠陥を見つけた
    Thinking が表示され続け、停止したかネットワーク問題が起きたように見えるし、プロンプトを入力する左側のパネルを展開したりサイズ変更したりできない。コード生成を依頼すると、出力が何度も途切れた後に最初からやり直し、以前の会話を引き継げない

  • 問題の複雑さを事前に分からず、その後の会話を同じモデルへ送る保証がないなら、この方式はうまく機能しない
    同じ会話を複数モデルへラウンドロビンで送るとキャッシュが壊れ、キャッシュを考慮するシステムよりむしろコストが高くなる可能性がある

  • Anthropic Opus 4.8とFable 5をしばらく使い、最新のOpenAIモデルも試したが、どれも不要な出力を過剰に生成する
    価格ではなく品質のために他のモデルを試し始め、私の業務領域ではGLM 5.2がFable 5よりあらゆる面ではるかに優れていた。タスクをうまく完了できないことのほうが、むしろ驚くほど少ない
    Kimi K2.7は少し多めに指示が必要だが、Opus 4.8より使い心地がよく、K3はまだ試していない。最新のOpenAIモデルは、ソフトウェア設計と実装能力がばかげて低い
    これはデータ分析、機械学習、ソフトウェア工学の多い私の業務領域に限った評価である

  • ベンチマークも使用モデル情報もなく、AI生成動画と登録ページだけがある
    「モノリスをマイクロサービスに変えて、すべての障害を殺人ミステリーのようにした」というアーキテクチャのジョークを思い出す

    • 公開評価器は https://echo.tracerml.ai/eval/ にある
      現在、7つのベンチマーク系列で保存された907行を公開しており、プロンプト、出力、評価、コストの記録を確認でき、今後さらに追加する予定
      リクエストごとのルーティングポリシー自体が製品なので公開しないが、リクエストごとの秘伝のタレを露出しない範囲で、利用可能なオープンウェイトモデルの一覧の一部、バージョン日付、全体の割当比率、評価設定は公開できる。新しい動画も制作中
    • ベンチマークは https://echo.tracerml.ai/eval/ にある
      良いベンチマークではないが、少なくとも存在はする
    • 本質的にはOpenRouterを再現しようとしているように見える。OpenRouterはフェイルオーバー、使用量計測、自動切り替えなどで特定プロバイダーを抽象化しており、かなりうまく機能する賢いインフラ抽象化である
      実際の問題を解決するというより、「OpenRouterがユニコーンになったから、自分もバイブコーディングで似たものを作れる」と投資家に言おうとしている試みに見えて残念
      Fable級と呼ぶのも、知的に怠慢か不誠実に感じる
    • tenderloveの「マイクロサービスは関数呼び出しを分散コンピューティング問題に変える」という言葉を思い出す
    • ログインで保護されたアプリはShow HNでは許可されていないと理解している
  • Ask Jeeves、AltaVista、Lycosの結果を集約していたDogpile.comを作り直したものなのか気になる。時間は循環するようだ

    • 良いアイデアは、時代やツールが変わってもたいてい依然として良い
    • アンサンブルモデルはKaggleでも常に最高の性能を出していた
      私たちも同じ方式を実装した: https://trustedrouter.com/blog/prometheus-2-new-draco-state-...
    • サービスのすべての作業に同じEC2インスタンスサイズを使わないというアプローチである
    • 三角形の車輪を作ることもできるが、車輪が丸いのには理由がある
    • モデルの混合(Mixture of Models) と見ることができる
      OpenRouter、JusCode、Fireworksのような他のAIゲートウェイ製品も最近同じ構成を推奨しているので、有用な部分はある可能性が高い