数字より先に、
ルールを公開する。
Telys は 0.1.0b4 — これらは開示済み環境でのプロトタイプ検証済み数値であり、本番環境の数値ではありません。結果として認められるのは、同一ハードウェア上でリコールを揃えて計測し、生サンプルとそれを生成したスクリプトを添えた場合のみだ。以下のルールは全数値を拘束する: 何を計測し、誰と比較し、どこで負けることが求められるか。
後付けの注釈ではなく、ハーネスが強制するルール。
以下の各ルールはベンチマークハーネスの機械チェックとして実装されている。違反したランは脚注に回されるのではなく、無効とマークされすべてのスコアカードから除外される。
“すべての倍率は、同一ハードウェア上で再現率を揃えて計測し、生サンプルと再現スクリプトを公開するまでは仮説にすぎない。”
Telys ベンチマークドクトリン負けられないベンチマークに価値はない
生成されるスコアカードには「負けた箇所」セクションが必須で設けられ、比較対象が勝ったすべてのセルから自動生成される。そのセクションが空の場合、レポートのビルドは失敗する — 完全勝利はハーネスの異常として扱われ、成果とは見なされない。
組み込み同士が公正な比較だ
TCP で応答する競合相手に対してインプロセス呼び出しを見出しに使うことはしない。組み込みライブラリとの比較ではインプロセス対インプロセスが誠実なトランスポートだ。サーバーとの比較ではトランスポートを同条件に揃えるか、数値に注釈を付けて見出しから外す。
同一ティア同士、さもなくば比較しない
コミットごとに fsync する競合相手に対してインメモリ実行を比較することはしない。すべての結果は耐久性ティア — in_mem、wal_async、または wal_fsync — を明示し、ハーネスはティアをまたぐ比較を強制的に失敗させる。
FAISS を呼び出しながら FAISS に勝ったと示唆しない
FAISS は Telys が組み込む ANN コアであり、基盤であって対戦相手ではない。すべてのベクトルスコアカードには生 FAISS トラバーサルのセルを最初に示す。タイの場合はタイと表示する。正当な勝利は別の場所で主張する: リランクカーネル、フィルタープランニング、そしてインデックスを囲むエンジンだ。
各比較対象は一つの主張を切り出す。
単一のリーダーボード数値はアルゴリズム、トランスポート、耐久性、ストレージ形式を混同させる。このセットは各比較が正確に一つの変数を切り出すよう選定されており、すべての見出しの下に同一ノードのコントロールを置く。
| システム | 形態 | 比較が切り出す変数 |
|---|---|---|
| FAISS（同一ノード） | コントロール基準値 | 対戦相手ではなく、床となる数値。Telys は FAISS を組み込んでいるため、生 FAISS の数値が自分たちの基準値だ。公開するデルタは、同一インデックス設定・同一計測再現率のもとでエンジンがその周囲に加える価値を示す。 |
| Postgres + pgvector | リレーショナル + ベクトル | フィルタードハイブリッドクエリ: スカラー述語を候補パスに押し込むことが、過剰フェッチまたは後処理フィルタリングを要するインデックスに対して、フィルター選択率を揃えた同一再現率で勝るかどうか。 |
| LanceDB / Chroma | 組み込みライブラリ | 最も近い競合相手とのインプロセス対インプロセス比較 — インプロセスの数値が公正な見出しになる唯一の場面だ。ANN の床は同じ。比較が切り出すのはその周囲のエンジン: 統一行 ID 空間、コールドオープン、フットプリント。 |
| Qdrant / Milvus | サーバー | アルゴリズム品質 — 固定 k での再現率 — をネットワーク往復から切り離す。レイテンシはサーバーホップを注釈付きで報告し、インプロセス呼び出しとの見出し比較はしない。 |
| Pinecone | マネージドサービス | 固定kでのRecallとコンピュート単位あたりのスループット。組み込みエンジンに対する生レイテンシは主要指標として採用しない。品質の主張は同一ノードのコントロールが担う。 |
| DuckDB / ClickHouse | 分析エンジン | 同一の物理 Parquet ファイルに対してスキャンと集計を行い、ストレージフォーマットの優位性とエンジンの優位性を分離する。ベクトル化分析エンジンはここで優秀な結果を示す。その勝利は公開される。 |
計測対象。
マトリクスが定義するのは計測であり、仮説上の勝利ではない。すべてのレイテンシセルは、オープンループ負荷下で完全な分布を報告する――平均値だけでは決してない。すべてのスピードセルは、ハーネスが出荷済みグラウンドトゥルースに対して算出したRecallゲートに拘束される。ゲートを満たさないセルは無効として出力され、スコアカードに入ることができない。
| ワークロード | セットアップ | 計測内容 |
|---|---|---|
| cold-open | ページキャッシュ削除、プロセス新規起動 | プロセス起動から最初のクエリ成功までの時間――セグメントmmapとインデックスサイドカーのマッピングを、サーバー起動とリカバリに対して計測。定常状態とは別に計測し、決して統合しない。 |
| exact FLAT | ブルートフォース完全探索、f32およびint8 | 構造上Recall 1.0における距離カーネルの下限を、同一バッファ上の同一ノード完全探索ベースラインと比較。すべてのint8セルはf32に対するRecallデルタを報告し、量子化損失を隠さない。 |
| フィルタ付きハイブリッド | スカラー述語 + top-k、3つの選択率で掃引 | フィルターが絞り込まれる際の等Recallでのレイテンシ、およびプランナーがセルごとに選択した戦略――プリフィルター後に完全探索、プリフィルター後にIVF、または探索後にポストフィルター――を報告し、適応的な判断を監査可能にする。 |
| full scan | 全カラムスキャンと集計 | 共有Parquet上の生カラムスループット、同一バイトに対するエンジン間比較。 |
| 選択的スキャン | 低マッチ率での述語スキャン | フッターのmin-maxとゾーンマップのプルーニングが実際に処理をスキップするかどうか――ウォールクロックだけでなく、読み取りバイト数と処理行数として報告。 |
python -m bench.orchestrator.run \
--suite vector --rig m-laptop
# one command: pinned comparators, content-addressed
# datasets, warmup, steady-state measurement
# reviewer mode: the same run with Telys excluded# every run emits a machine-checked ResultEnvelope; # a run that cannot fill every field is invalid index_string = "IVF4096,PQ16" # same for Telys and the FAISS control omp_num_threads = 8 # FAISS threading pinned, disclosed transport = "in_process" # headlined only vs in-process durability_tier = "wal_fsync" # cross-tier comparison hard-fails recall_at_k = 1.000 # harness-measured, never self-reported samples_path = "bench/results/filtered_impact.txt"
実行は少なくとも5回、新規プロセス起動をまたいで繰り返す。固定ハードウェアプロファイル上で、1度に1システムずつ。データセットはコンテンツアドレス指定。クエリセットは固定ファイルであり、実行時に生成しない。ハーネス仕様は本日コミット済み。ハーネスは結果とともに公開される。
計測済み、条件付き、再現可能。
各行は上記の環境での実測値であり、隣に記載されたリコールゲートのもとで取得されています。優位性の源泉は物理レイアウトです。同一の連続サブセット上では Mojo スキャンは生の FAISS と同等であり、以下のデルタはキーパーティション化されたレイアウトがもたらすものであって、より速い距離カーネルによるものではありません。これらはプロトタイプ数値であり、ハーネスの成熟とともに完全なフェアネス契約のもとで再実行されます。
| ワークロード | セットアップ + リコールゲート | 計測結果（M4 Max、シングルスレッド、インプロセス） |
|---|---|---|
| フィルタ済みスライス · 0.1% sel | N=1,000,000 D=128 K=10、ウォーム、recall 1.000（完全一致） | partition-slice p50 0.013 ms — レイアウト優位：フルスキャン比 ~373×、スキャッタギャザー比 ~19×。同一サブセット上の FAISS Flat：0.040 ms（同等 — 優位性がレイアウトによるものでカーネルによるものでないことを証明）。 |
| フィルタ済みスライス · 0.4% sel | N=1,000,000 D=128 K=10、ウォーム、recall 1.000（完全一致） | p50 0.032 ms — フルスキャン比 ~128×、スキャッタギャザー比 ~10.8×。FAISS Flat コントロール 0.035 ms（同等）。 |
| フィルタ済みスライス · 1.6% sel | N=1,000,000 D=128 K=10、ウォーム、recall 1.000（完全一致） | p50 0.112 ms — フルスキャン比 ~42×、スキャッタギャザー比 ~10.3×。FAISS Flat コントロール 0.120 ms（同等）。 |
| 巨大パーティション救済 | N=400,000 D=128 中 247k 行、nprobe キャリブレーション済み、recall 0.9915（下限 0.98） | パーティション内 IVF により、完全スライスが劣化する箇所でレイアウト優位を回復：完全スライス 1.71 ms → IVF 0.033 ms。IVF なしでは、単一の巨大パーティションは ~4–5× にとどまる。 |
| ガバナンス付き自動 nprobe | N=1,000,000 D=128 Q=500 nlist=1000、recall 0.998 維持（下限 0.98） | FIND 0.28–0.31 ms（ベースライン nprobe=32）→ 0.081–0.088 ms（ガバナンス付き自動 nprobe=8）。リコールは下限を上回り維持 — 速度のためのサイレントなリコール低下なし。 |
| FIND vs FAISS コントロール | 等リコール、同一トランスポート、両方インプロセス、N=1,000,000 D=128 | Telys 0.073–0.074 ms @0.998 vs 生 FAISS 0.080 ms @0.999 — 同等からわずかに優位。スケール依存：N=200k では劣後（0.74×）、メモリバウンドな大規模 N でのみ最大 ~1.6×。FAISS 品質、Mojo 加速。 |
| GIL フリー並行性 | N=200,000 D=128、パフォーマンスコア 12、インプロセス Mojo IVF カーネル | FIND スループットは 8 スレッドで ×6.9 にスケール（15,128 → 104,756 qps）。スループットスケーリングの計測であり、クエリあたりレイテンシではなく、サーバーエンジンとの比較でもありません。 |
| 挿入からリコールまでの鮮度 | ベース N=100,000、M=300 挿入、D=128、インプロセス | 直前に挿入したベクトルが次のクエリで top-1：recall@1-of-new = 1.000。挿入 p50 0.3 µs。スループット指標ではなく、正確性ゲートです。 |
上記の全セルは、bench/results/ 内の名前付きスクリプトと保存済み生出力（filtered_impact.txt、partitioned.txt、partition_acceptance.txt、opt.txt、telys.txt、concurrency.txt、freshness.txt）に追跡可能です。永続化再オープン数値は再計測済み生サンプルの取得待ちのため保留中です。各乗数は各行に記載された条件の外では仮説です。
コード向けに構築し、コードベンチマークで評価。
Telys はコードを検索するため、品質基準は汎用テキストスイートではなく CoIR です。LexicalCodeIndex は mteb SearchProtocol としてラップされ、bm25s ベースラインと同一パスで mteb.evaluate によりスコアリングされます — 方法論の乖離なし、自己採点なし。ベースラインは CoIR 論文掲載値ではなく 2026-07-21 の再現実行値です（掲載値の一部は再現できません）。指標：nDCG@10。
| CoIR タスク | multigram | bm25-ref | bm25-code | コード・字句 · 出荷済み | ベスト比 |
|---|---|---|---|---|---|
| CodeTransOceanContest | 0.160 | 0.478 | 0.600 | 0.718 | ✅ |
| CodeTransOceanDL | 0.340 | 0.344 | 0.351 | 0.366 | ✅ |
| CosQA | 0.048 | 0.188 | 0.213 | 0.218 | ✅ |
| SyntheticText2SQL | 0.265 | 0.249 | 0.372 | 0.441 | ✅ |
| CodeFeedbackMT | 0.288 | 0.592 | 0.591 | 0.674 | ✅ |
| CodeFeedbackST | 0.162 | 0.682 | 0.682 | 0.722 | ✅ |
| StackOverflowQA | 0.223 | 0.703 | 0.687 | 0.733 | ✅ |
| AppsRetrieval | 0.001 | 0.048 | 0.014 | 0.034 | ❌ |
| 平均 | 0.186 | 0.445 † | 0.488 | 7/8 | |
8 タスク中 7 勝；平均 0.488 対 0.445（各タスクの強い方のベースライン、† bm25-ref／bm25-code のベスト）— multigram 平均の 2.6 倍。唯一の敗北 AppsRetrieval は全語彙手法がほぼゼロ：長い問題文とコードの照合は埋め込みの領域です。
コード対応トークン＋BM25
識別子をコードの記法どおりに分割 — camelCase、snake_case、ドット区切りパス — そのまま IDF/BM25 に投入。これだけで大半のタスクを制します：CodeTransOceanContest はチューニング前に 0.478 から 0.600 へ。
ストップワード除去＋軽量ステミング
英語ストップワードを除去し、軽量サフィックスステマーで自然言語クエリとコードトークンを整合 — SyntheticText2SQL を敗北から 0.441 へ転じたレバーです。
k1 = 1.8 · b = 1.0
CoIR で Algenta チューニングした出荷デフォルト値：より強い語頻度飽和と完全長正規化 — StackOverflowQA を転じたレバーです。
全セルは単一スクリプト bench/mteb_code_lexical.py から再現可能 — 両サイドを同一の mteb.evaluate 呼び出しで実行（2026-07-21 実施）。code-lexical は Telys が出荷するインデックスで、出荷デフォルト値を使用。
勝ち、引き分け、負け — 明記する。
公開フォーマットは最初の数値が存在する前に確定する。数値がフォーマットを曲げることはできない。
我々が負ける箇所、印刷物として
すべてのスコアカードには「我々が負ける箇所」と「FAISS に並ぶだけの箇所」のセクションが含まれ、いずれもセルから自動生成される。どちらかが空の場合、レポートのビルドは失敗する。
我々なしでフィールドを再現する
ハーネスはTelysを除外した状態で実行できる。懐疑的な検証者は比較対象とコントロールの数値のみを単独で再現し、各競合製品が自社ガイドに従ってチューニングされていることを確認できる――設定はコミットされ、ベンダーデフォルトとの差分が示される。
すべてのセルはサンプルに遡れる
公開された各セルは、操作ごとの生サンプルとそれを生成した正確なスクリプトにリンクする。結果は追記専用で、エンジンのリビジョンと静的リンクされたバンドル依存バージョンをキーとする。
これらはプロトタイプ数値であり、それぞれ条件を付記している。この契約を — そして完全なハーネスのもとで再実行していく数値を — 我々に問え。