---
title: "Agentic Analytics Benchmark: Jev を用いたテーブルのランキングと失敗のラベル付け"
date: "2026-10-28T06:56:51.946Z"
author: "Eduardo Vellasques, Lionel Palacin and Al Brown"
category: "Engineering"
excerpt: "Jev は 1 秒未満でウェアハウスのテーブルをランク付けし、エージェントの失敗をラベル付けしますが、検索ヒントを追加しても Agentic Analytics Benchmark の 20 種類のモデル全体で精度は横ばいでした。"
---

# Agentic Analytics Benchmark: Jev を用いたテーブルのランキングと失敗のラベル付け

本記事では、TypeSafe の System One モデルである Jev と、Agentic Analytics Benchmark において Jev が何をもたらしたかについて解説します。Jev はテキストを生成しません。状態と型付きの質問(キャリブレーションされた確率として回答される yes/no、1つ選択する選択肢、ルーブリックスコア)を渡すと、約 70 〜 500 ミリ秒で確信度を伴う型付きの回答を返します。1回の呼び出しに多数の質問を含めることができ、その呼び出しにおいてベンチマークに固有の要素は一切ありません。状態には任意のデータを渡すことができ、質問は平易な指示文です。そのため、Jev は渡されたあらゆる対象に対する分類器として機能します。今回は次のタスクを任せました。失敗した実行ログを読み取って何が問題だったかを判定すること、そして質問文を読み取ってどのテーブルが必要かを判定することです。

## TL;DR {#tldr}

* Jev はすべての失敗を 1 秒未満でラベル付けします。4 モデルによる開発セットの実行において、より詳細な分類体系により、データ選択の誤りが最大のカテゴリーであることが判明しました。その大半はテーブルの誤りではなくエンティティ解決の誤りであり、さらに評価器が誤って採点した可能性の高い 18 件の回答が特定されました。  
* また Jev は、ファインチューニングなし、実行時の正解データなしで、質問ごとにウェアハウスのテーブルを nDCG@10 0.951、所要時間 0.4 秒でランク付けします。  
* このランキングをインループのヒントとしてエージェントにフィードバックしたところ、20 モデル全体で精度は横ばいにとどまり、開発セットで見られたターンの削減効果は評価用ボードでは維持されませんでした。成果と言えるのはランキング機能そのものであり、ヒントの提供ではありません。

## 適切なテーブルの特定と、それをエージェントに伝える効果の検証 {#finding_the_right_tables_and_whether_telling_the_agent_helps}

本記事はラウンド 2 の後半です。前回の記事では GPT-6、Claude Opus 5.5、Claude Sonnet 5.5 を評価用ボードに追加しました。今回は、Jev をベースに構築した低コストなリトリーバルコンポーネントによってスコアを動かせるかを検証します。第 1 回の記事では、テーブルを結合することよりも、必要なテーブルを見つけることのほうが重要であることがわかりました。ボードの上位半分のモデルは、ディメンショナル CRM テーブルを必要とする質問の 87 〜 99% でそれらのテーブルを発見できますが、下位半分のモデルはまったく発見できないことがよくあります。201 問のボードにおいて、精度上位 5 モデルは質問に必要なディメンショナルテーブルの 78% をクエリしたのに対し、下位 5 モデルは 49% にとどまり、失敗した実行の 43% は模範解答で使用されているテーブルを少なくとも 1 つ読み取っていませんでした。

これはリトリーバルの問題であり、リトリーバルはモデルを再トレーニングすることなく、任意のモデルの前段に配置できます。そこで私たちは考えました。もし低コストなコンポーネントが最初のクエリの前にテーブルをランク付けし、それをエージェントに伝えたら、テーブル選択の誤りによる失敗はなくなるでしょうか。以降では 2 つの質問セットが登場します。201 問の評価用ボード(board)は固定されており、モデルを 1 度だけ評価します。136 問の開発セット(development set)は、同じ 18 テーブルのウェアハウスを対象とした別個のセットであり、ボードに手を加えることなく実験を実行して閾値を設定できるように作成されたものです。Jev の調整に使用されたデータはすべて開発セットからのものであり、ボードはホールドアウト検証として使用されています。

### すべての失敗のラベル付けとジャッジの監査

第 1 回の記事では、フロンティアモデルの分類器を使用して、すべての失敗を 5 つのモード(試行なし、計画の誤り、データ選択の誤り、実装の誤り、実行時エラー)に分類しました。このアプローチは機能しますが粒度が粗く、失敗が正当なものであることを前提としています。私たちは、毎回の評価で実行できるほど低コストでありながら、より詳細な 2 つの疑問(具体的に何が間違っていたのか、そして採点器は正しく判定したのか)にも答えられるものを求めていました。

失敗した実行ごとに、ラベラーはトラジェクトリ(質問、模範および候補の SQL、実行結果、最終回答)を分類器に渡し、1 回の呼び出しで 4 つの質問を投げかけます。16 種類の失敗サブモードのどれに当てはまるか、システムプロンプトのどのルールがあれば防げたか、事前にスキーマのヒントがあれば役立ったか、そして失敗の判定にもかかわらず回答が正しそうに見えるか、の 4点です。スナップショット日付でフィルタリングしたかどうかなど、SQL テキストから機械的にチェックできる事項はコード側で判定してファクトとして渡されるため、分類器は判断を要する評価のみを行います。

コード上では、4 つの質問は 2 つの選択肢と 2 つの yes/no の確率であり、トラジェクトリを状態として 1 回の呼び出しで送信されます。以下はリポジトリに含まれるラベラーの構成を簡略化したものです。

<pre><code type='click-ui' language='python'>
from typesafe_sdk import TypeSafeClient, Choice, Noul

questions = {
    "sub_mode": Choice(
        instructions="Given the question, the reference SQL and answer, and "
                     "the candidate's SQL, results and final answer, pick the "
                     "single most specific sub-mode for why it failed.",
        criteria=SUB_MODES),    # 16 sub-modes, each with a one-line meaning
    "prevented_by_rule": Choice(
        instructions="Which judgment-call schema-prompt rule best explains "
                     "the failure? Choose 'none' if no listed rule does.",
        criteria=RULES),        # the rule set is a config file
    "schema_hint_would_help": Noul(
        instructions="Would a correct schema-use hint before the first "
                     "query most likely have prevented this failure?"),
    "correct_despite_fail": Noul(
        instructions="Does the candidate's final answer actually look "
                     "correct for the question, despite being scored a failure?"),
}

with TypeSafeClient() as client:
    resp = client.system_one(state=trajectory, questions=questions)

resp.choices["sub_mode"].choice            # e.g. "wrong_identifier"
resp.nouls["correct_despite_fail"].noul    # a calibrated probability, 0 to 1

</code></pre>

状態は辞書形式です。質問、模範 SQL と回答、候補の SQL、結果セット、最終回答、およびコード側ですでに判定されたファクト(SQL がスナップショット日付でフィルタリングされていたかなど)が含まれます。Jev はその 1 つのペイロードから 4 つの質問すべてに回答します。

これを 4 つのモデルによる開発セットの実行(Claude Sonnet 4.6、GPT-4.1、Qwen3-Coder 30B、Gemini 2.5 Flash)に対して実行しました。544 回の試行のうち 277 回の失敗が対象です。その結果、3 つの事実が明らかになりました。

**より詳細な分類体系により、最大のカテゴリーが変化します。** すべてのサブモードは 5 つの大まかなモードのいずれか 1 つに正確にネストされているため、2 つの視点を比較できます。粗いモード分類では、計画の誤りが最も一般的な失敗でした。サブモードで見ると、データ選択の誤りが最大のカテゴリーとなり(277 件中 87 件)、その大部分はエンティティ解決によるものでした。組織に対して誤った識別子やリテラルを使用する(29 件)、またはファクトをクエリする前に名前付きエンティティを解決しない(20 件)というケースが合算され、誤ったテーブル(28 件)やカラム(10 件)を選択するケースを上回っています。サブモードによって、エンティティ解決やテーブル選択の誤りが「計画」から切り離され、局所化されました。これが、試行すべきアプローチとしてテーブルリトリーバルに着目するきっかけとなりました。

**失敗の傾向はモデルごとに固有です。** Gemini 2.5 Flash は空の結果が返ってくると諦めてしまいます。GPT-4.1 は実行不可能な SQL を記述し、実行時エラーの約半分を占めています。Qwen3-Coder 30B は計画、データ、試行なしに広く分散しています。Sonnet 4.6 は実質的な内容で失敗し、採点器のアーティファクトによるケース 7 件中 6 件を占めました。モデルの性能が低くなるほどラベルの確信度が高くなりますが、これは明白な失敗ほど命名しやすいため、当然の結果と言えます。

**ジャッジには監査が必要であり、分類器がそれを実行できます。** 「失敗判定にもかかわらず正解」のスコアは、採点の問題としてラベル付けされたものだけでなくすべての失敗に対して算出されるため、277 件中 37 件が採点エラーの可能性があるとしてフラグが立てられました。閾値を 0.65 に設定すると、それが 18 件に絞り込まれました。確信度の高いものを追跡したところ、確定的な比較器(comparator)のメカニズムに突き当たりました。カラムの紐付けを行う前に、行数の差異によって「不一致」を返してしまうため、1 つの質問をエンティティごとに 1 つのクエリに分割した正しい回答や、模範解答がスナップショットであるのに対して時系列を返した正しい回答が、失敗として判定されていました。この比較器のバグは現在対応リストに入っています。また「失敗判定にもかかわらず正解」は、失敗が正当であることを前提とする従来の 5 つの失敗モードでは表現できないカテゴリーです。

![](https://clickhouse.com/uploads/jev_oct2026_image1_888b51a460.png)

*4 つのモデルによる開発セット実行における 277 件の失敗をサブモード別に示し、ネスト元の粗いモードごとに色分けしたグラフ。最も大きな単一のバーは空の結果を受け取った後に早期終了したケースで、そのほぼすべてが Gemini 2.5 Flash によるもの。色ごとに合計すると、データ選択の誤りが最大のカテゴリーであり、その大半はテーブルの誤りではなくエンティティ解決によるもの。灰色のバーはモデルの失敗ではなく、失敗判定にもかかわらず正解と判定された 7 件の回答と、曖昧な質問 1 件を示す。*

**実例。** ある組織の MRR を尋ねられた際、GPT-4.1 は会社名「*White, Leonard and Kelly*」を 3 つの名前に分割し、空の結果を受け取った後、そのような組織は存在しないと報告しました。ラベラーはこれを確信度 0.94 で「誤った識別子」と判定し、定められたルールのいずれにも起因しないと帰属させ(名前の分割をカバーするプロンプトはなく、SQL に対する機械的チェックも問題ないため正しい判定です)、「**スキーマのヒントが役立ったか**」を 0.78、「**失敗判定にもかかわらず正解か**」を 0.20 とスコアリングしました。正規表現では捕捉できない純粋に意味的な失敗が、1 回の呼び出しでラベル付けされたことになります。

### テーブルのランク付け

ランキングタスクにおける状態は質問とウェアハウスのスキーマであり、質問はテーブルごとに 1 つの yes/no(「*この質問に答えるためにこのテーブルが必要か？*」)となります。

模範 SQL が読み取るテーブルと照合してスコアリングしたところ、平均 nDCG@10 は 0.951、recall@10 は 0.991 となり、質問の 84% において上位 5 つのテーブルの中に回答が必要とするすべてのテーブルがすでに含まれていました。質問あたりの所要時間は約 0.4 秒です。

![](https://clickhouse.com/uploads/jev_oct2026_image2_0ea704181c.png)

*136 問の開発セットにおけるテーブルランキングの品質。模範 SQL が読み取るテーブルと照合してスコアリング。recall at k は、上位 k 個に含まれる必要なテーブルの割合。all-required at k は、回答が必要とするすべてのテーブルがすでに上位 k 個に含まれている質問の割合。どちらも急速に上昇し、5 テーブル時点でリコールは 95%、84% の質問が必要なものをすべて揃えており、10 テーブル時点でリコールは 99% に達する。2 本の線の間のギャップは、2 つまたは 3 つのテーブルを必要とし、そのうちの 1 つが下位にランクされた質問によるもの。これが、ランキングをヒントとして提供し、スキーマのプルーニングには決して使用しない理由でもある。*

この高いリコールの一部は、ウェアハウスが 18 テーブルと小規模であることによるものです。75 〜 710 テーブルを持つパブリックな Text-to-SQL カタログ(BEAVER、BIRD、Spider、MMQA、計 250 ケース)での検証パイロットでは、同じ yes/no ランキングによって 87% の recall@10 を達成し、73% のケースで必要なすべてのテーブルを見つけ出しました(p90 レイテンシは 3.4 秒、実行全体のコストは約 0.50 ドル)。これは 0.991 よりは大幅に低いものの、SQL クエリを使用して同じスキーマを探索した 2 つのエージェント(必要なテーブルの発見数が少なく、ケースあたり 25 〜 83 秒を要した)を依然として上回っています。したがって、この手法は大規模なカタログにも適用可能ですが、完璧に近いリコールまでは維持されず、実際のウェアハウスでは前者のような結果を想定すべきです。

### ランキングの活用方法

優れたランキングであっても、エージェントがそれに基づいて行動しなければ意味がありません。エージェントは私たちが再トレーニングできるものではなく、プロンプトにスキーマを持ち、SQL を実行するツールを備えた、ベンチマーク対象の任意のモデルです。そのため、ランキングはモデルが読み取れるテキストとして届けられる必要があり、その方法は 2 つの制約によって決まります。

第 1 に、ランキングでスキーマを単純に置き換えることはできません。約 6 問に 1 問の割合で、回答に必要なテーブルが上位 5 位から外れるため、下位にランクされたテーブルをプロンプトから削除すると、それらの質問に答えられなくなってしまいます。そのため完全なスキーマはプロンプトに残し、ランキングは最初にどこを見るべきかを示すだけに留めます。

第 2 に、ランク付けされたテーブルをシステムプロンプトに含めても効果はありません。2 つのモデルによるパイロット実験では、すべての質問の先頭に上位 5 つのテーブルを付加したところ、正解数は GPT-4.1 で 136 問中 +6 問、Qwen3-Coder 30B で 125 問中 +7 問変化しましたが、同じベースラインの実行を再採点しただけでそれぞれ 21 件と 28 件の判定が入れ替わっており、採点ノイズの範囲内でした。必要なテーブルを見逃していた実行にのみ付加した場合は改善が見られ、GPT-4.1 は 11 問を取り戻して低下はゼロ、Qwen3-Coder 30B は 13 問を取り戻して低下は 3 問でした。しかし、この選択を行うには正解データが必要です。

現実のシナリオでは正解データにアクセスできないため、プロキシとして分類器の「確信セット(confident set)」を使用します。これは、スコアが 0.5 以上のテーブルのセットとして定義されます。このセットに含まれるテーブルを 1 つも読み取っていないクエリは、通常、誤ったテーブルにアクセスしようとしています。これがインループのゲートとなります。

**ループ内での処理。** ゲートはモデルが実行するすべてのクエリをチェックします。実行がこれまでに読み取ったテーブルのいずれも確信セットに含まれていない場合、そのクエリの結果に以下の内容を含む短いメモを追加します。

* クエリが読み取ったテーブル  
* 上位 3 つのランク付けされたテーブル  
* そのテーブルに求められているデータが含まれているか確認し、含まれていない場合は最上位のテーブルをクエリするようにとの指示

前述のとおり、完全なスキーマはシステムプロンプトに残ります。ゲートはすべてのクエリをチェックしますが、メモを追加するのは 1 回の実行につき最大 1 回です。メモはトリガーとなったクエリの結果に追加され、独立したメッセージとしては送信されないため、モデルに追加のターンを消費させることはありません。ゲートありの実行とベースラインは、同じ 60 ターンの予算で比較されます。

![jev-schema-retrieval.png](https://clickhouse.com/uploads/jev_schema_retrieval_8929dd2f16.png)

*質問ごとに、分類器は 18 の各テーブルを yes/no の確率でスコアリングし、0.5 以上のテーブルが確信セットを形成する。事前の処理として、上位 5 つのテーブルがプロンプトの先頭に追加される。ループ内では、エージェントが実行する各クエリをゲートがチェックし、これまでに読み取られたテーブルがいずれも確信セットに含まれていない場合、そのクエリの結果に上位ランクのテーブルを記載したメモを追加する。いずれの経路でも、エージェントが見るスキーマから何かが削除されることはない。*

**具体例。** 「*EMEA North リージョンにおける過去 12 か月のサブリージョン / AE / テリトリーごとの月次 MRR をグラフ化せよ*」という質問を考えます。4 つのテーブルが 0.5 を超え、14 のテーブルはそれを大幅に下回っています。回答に必要な 2 つのテーブルのうち 1 つは確信セットに含まれていますが、もう 1 つの月次 MRR テーブルは 0.27 で含まれていません。この場合、以下のようになります。

* アカウントディメンションを読み取るクエリはセット内にあるため、何も起きない。  
* サービスディメンション(0.08)を読み取るクエリはセット外であるため、メモが発動し、アカウントディメンションを指し示す。

この質問に対する開発セットでの 2 つの実行は、両方の結果を示しています。**o4-mini** はベースラインの実行ではアカウントディメンションを一度も読み取りませんでした。ゲートを有効にすると、最初のクエリが確信セット外のテーブルを読み取ったためメモが 1 回発動してアカウントディメンションを指定し、モデルはそれをクエリしました。どちらの実行も成功し、所要ターンは 12 と 14 でした。ベースラインですでに回答を得られていたため、メモは探索経路を変更しただけであり、この例は設計どおりに機能したメカニズムを示していますが、リカバリーではありません。Claude Haiku 4.5 は必要なテーブルをどちらも読み取ることなく 2 ターンで失敗しましたが、読み取ったテーブルが確信セット内にあったためゲートは一度も発動せず、ゲートありの実行も同様に失敗しました。

![](https://clickhouse.com/uploads/jev_oct2026_image4_b05b22cb46.png)

*実際の質問に対するテーブルごとの確率。4 つのテーブルが 0.5 のラインを超えて確信セットを形成している。星印は模範 SQL が読み取るテーブルを示し、1 つはセット内にあり、もう 1 つはセット外にある。セット内を読み取るクエリはそのまま実行され、セット外を読み取るクエリにはメモが付加される。*

### 効果はあるか

136 問の開発セットと 201 問のボードを対象に、20 のモデルにわたり、同一の質問およびモデルに対して 60 ターンの予算でゲートのオン/オフをペアで実行し、ベンチマークの通常の審査員によって採点しました。以下の差分は、ゲートが実際に発動したセル(開発セットのセルの 14%、ボードのセルの 20%)に関するものです。信頼区間は 95% ブートストラップです。

| セット | 発動セル数 | リカバリー / 悪化 | ネット (95% CI) | ターン数 | 出力トークン数 |
| ----- | ----- | ----- | ----- | ----- | ----- |
| 開発セット (136 問) | 371 | 34 / 40 | −6 (−23 〜 +11) | −6.1% (−12.1 〜 +0.1) | −9.3% (−25.4 〜 +5.8) |
| ボード (201 問) | 812 | 87 / 69 | +18 (−6 〜 +42) | +0.5% (−4.8 〜 +6.4) | −6.1% (−16.1 〜 +3.9) |
| プール全体 | 1,183 | 121 / 109 | +12 (−18 〜 +42) | −1.5% (−5.6 〜 +2.9) | −7.1% (−15.5 〜 +1.4) |

**精度は横ばいです。** 開発セットでは一方に傾き、ボードではもう一方に傾き、プール全体でのネットは +12 で信頼区間はゼロを跨いでいます。このメカニズムは意図したとおりに機能しています。121 件のリカバリーのうち 34 件は、「ベースラインが正解テーブルをスキップ → メモがそれを指定 → ゲート付き実行がそれをクエリ」という正確な連鎖を辿っています。しかし、109 件の悪化のうち 19 件も同じ連鎖を辿ったにもかかわらずモデルが回答を誤っており、両セットにおけるその他の差異は試行ごとのノイズです。適切なテーブルを知ることはボトルネックではなく、それを正しく使うことがボトルネックであり、それはヒントでは修正できない計画の失敗です。

**ターン数:開発セットでの削減効果がホールドアウト質問で維持されない理由。** 開発セットでは、ゲート付き実行全体でクエリターンが合計 176 ターン減少しました。しかしボードではその削減効果は消えています。メカニズム自体は両者でまったく同じです。過剰探索の実行(ベースラインで 10 ターン以上)は両セットの発動セルの 22% を占め、ゲートによってターン数と出力トークン数の両方がそれぞれ 17% 削減されました。異なっていたのは残りの 78% です。もともと短かった実行は、メモが届くことでペナルティを支払うことになりました。開発セットでは +6%、ボードでは +17% のターン数増加です。削減効果がホールドアウト質問で消失したわけではありません。もともと問題がなかった実行に対するより大きなペナルティが、それを相殺してしまったのです。

**出力トークン数:傾向は見られるもののノイズの範囲内。** 出力トークンの削減傾向は両方のセットで同じ方向を示していますが、信頼区間はいずれもゼロを除外していません。全体の値は少数の長い実行によって牽引されており、そのロングテールは両刃の剣となります。ある Gemma 4 31B のセルでは、ベースラインの 29 ターン、1,628 出力トークンから、メモを受けたことで上限の 60 ターン、48,910 トークンまで跳ね上がりました。ゲートが発動するのは 5 〜 7 回の実行に 1 回であるため、すべての実行に分散させると、トークンの削減効果は約 1% であり、ターン数への影響は実質ゼロです。

![](https://clickhouse.com/uploads/jev_oct2026_image5_07f16fab7c.png)

*開発セットおよびホールドアウトのボードにおいて、ゲートが発動したセルにおけるモデルごとのターン数と出力トークン数の変化。バーはそれらのセルの集計値を示し、上記テーブルの合計値に対応する。目盛りは中央値のセルを示す。開発セットでは、一部の過剰探索の実行によって集計値が押し下げられているものの、ほとんどのモデルで中央値セルは横ばいとなっている。ボードでは同じテールがコストへと転じ、ある Gemma 4 31B のセルがターン上限まで到達した。各モデルのデータは 8 〜 61 の発動セルに基づいているため、バーは確定的な結果ではなくばらつきとして読み取る必要がある。*

### 得られた知見

このラベラーは、現在私たちが開発セットの評価ごとに実行している計測ツールとなっています。1 回のオフライン処理で、大まかな失敗の内訳、より詳細なサブモード、および採点器の監査を、失敗 1 件あたり 1 秒を大幅に下回る時間で提供します。また、その詳細な分類体系は第 1 回の記事の結論を修正するものでもあります。計画の誤りと呼んでいたものの一部は、テーブルやエンティティの誤りであり、これは推論ではなくリトリーバルの問題です。

リトリーバルランキングは成果を上げた部分です。ファインチューニングや実行時の正解データなしに、質問に対して適切なテーブルをリストの最上位に配置する、1 秒未満かつほぼコストのかからないコンポーネントです。大規模なスキーマを扱う分析エージェントを構築するなら、誰もが備えるべきものです。

インループのヒントはネガティブな結果であり、それを報告することに意味があります。精度は横ばいで、ターン数が削減されるのはモデルが過剰探索していた場合に限られ、ホールドアウトの質問では、順調だった実行に課されるペナルティによってその削減効果が相殺されます。ボードの評価でも、別のアプローチから同じ事実が示されました。前回の記事において、Sonnet 5.5 は Sonnet 5 よりもテーブルを多く発見したわけではないにもかかわらず、ディメンショナルな質問のスコアを伸ばしました。フロンティアモデルはすでにテーブルを見つけることができています。彼らが誤るのは、そのテーブルを使って何をすべきかという点です。

## 自社のデータウェアハウスで実行する {#run_this_on_your_own_data_warehouse}

ここで紹介した内容は、私たちのウェアハウスや ClickHouse に限定されたものではありません。テストハーネスは第 1 回の記事で説明したものと同じです。計測機能を備えたアシスタント、モデリングされたウェアハウススキーマ、委員会による正解データを備えた精選・匿名化された質問セット、そしてどのモデルも自身の回答を採点しないジャッジパネルで構成されています。モデルの追加はレジストリへの登録と 1 つのコマンドで完了し、エンジンのバージョンが固定されているため、再実行によってボードの結果を再現できます。

皆様のウェアハウスにも固有の識別要素があるはずです。私たちの場合はディメンショナル CRM レイヤーでしたが、皆様の環境では緩やかに変化するディメンション(SCD)、半構造化イベントテーブル、あるいはドキュメント化されていない命名規則かもしれません。それを見つけ出す唯一の方法は、ご自身のスキーマと質問でベンチマークを実行し、モデルがどこで失敗しているかを確認することです。

## 次のステップ {#whats_next}

第 1 回の記事で提起した役割分割アーキテクチャの課題(最強のモデルが計画を立て、最も安価なモデルが実行する)は、私たちが引き続き最も関心を寄せているフォローアップ項目です。ヒントに関する横ばいの結果は、この方針をより明確に裏付けています。計画こそがモデルの失敗する部分であるならば、高価なモデルを投入すべきは計画の部分です。リトリーバルの観点では、ランキングは 18 テーブルのウェアハウスと 250 ケースのパブリックパイロットでスコアリングされました。残された疑問は、ヒントがコストに見合う効果を発揮し始めるカタログの規模がどの程度かという点です。

## コード {#code}

* ハーネス: [github.com/ClickHouse/data-agent-mnist](http://github.com/ClickHouse/data-agent-mnist)、Apache 2.0。  
  * ラベラーとランカーはオプションの Jev エクストラとして提供されます  
  * README の「*Optional: ranking and labeling with Jev*」セクションでセットアップを説明しています。TypeSafe のキーが必要です。  
  * schema_retrieval.py がランキングをスコアリングします  
  * schema_retrieval_agent.py がそれを事前またはインループでエージェントに提供し、その差分を測定します  
  * label_failure_modes.py が採点済み実行にラベルを付けます。ラベラーがチェックするルールセットは、自社のウェアハウス向けにコピーして使う設定ファイルです。

---

## 今すぐ始める

実際のデータで ClickHouse がどのように動作するかご興味がありますか？わずか数分で ClickHouse Cloud を使い始めることができ、$300 分の無料クレジットも獲得できます。

[サインアップ](https://console.clickhouse.cloud/signUp?loc=blog-cta-2804&utm_blogctaid=2804)

---