今週のTOPIC

[paper] Separating Representation from Reconstruction Enables Scalable Text Encoders

Megi Dervishi, Mathurin Videau, Yann LeCun — FAIR at Meta / Paris Dauphine / NYU

ICML 2026

tl;dr

• BERT型エンコーダをスケールさせると、パープレキシティ（トークン再構成性能）は改善し続けるのに、凍結プローブで測った表現品質は逆に悪化する。

• 原因は「トークン再構成損失(MLM)」と「表現学習」が、BERTの平坦(flat)な設計の中で不可分に結合していること。

• 解決策として、エンコーダと軽量Predictorをクロスアテンションで分離した二部構造 CrossBERT を提案。著者らいわく「テキスト向け初の Masked Autoencoder」。

• 凍結したままでMTEB性能の99%を保持（BERTは10ポイント以上落ちる）。検索タスクは2倍以上。

なぜ今まで見えなかったのか: 凍結評価

• 従来のエンコーダ評価はフルファインチューニング依存。これだと「事前学習表現が良かった」のか「FTが後から辻褄を合わせた」のか判別できない。

• バックボーンを凍結して軽量なプローブ/プーラーだけを学習させると、表現そのものの質が見える。GLUEでは線形プローブ（リッジ回帰の閉形式解）とkNNプローブ、MTEBではクロスアテンション付きの軽量プーラーのみ微調整。

• 傍証として、BERTを層ごとにプロービングすると最終層より浅い層のほうがGLUEが高い（239Mで平均+1.8pt）。最終層が再構成タスクに過度に特化している。

CrossBERT の構造と Complementary Masking

• エンコーダは可視トークンだけを処理（マスク位置は計算から落とす）。Predictorは プレースホルダと位置インデックスのみを入力とし、マスクされたトークンの中身は一切見ない。

• Predictorは自己注意を持たず、クロスアテンションのみ。これによりエンコーダ埋め込みへの「読み出しインターフェース」として機能することが強制される。深さはエンコーダの約1/4（実験では28層 vs 6層）。位置はRoPEで保持。

• 分離の副産物として高マスク比率に頑健になる（20%→50%でGLUE平均 -0.7ptのみ。BERTは20〜40%を超えると劣化）。

• これにより Complementary Masking Strategy (CMS) が成立する。逆マスクを足して相補的な2ビューを作り、専用アテンションマスクでリークを防ぎつつ同時処理。BERTでやると逆ビューが60〜80%マスクになり破綻する。
💡
CMSは独立した工夫ではなく、「二部構造 → 高マスク比率耐性 → 相補マスクが成立」という連鎖の最後で効率に換金する仕掛け。全トークンから勾配を回収してサンプル効率2倍、スループット1.68倍（207k vs 123k tokens/sec, H100）。

結果: 凍結すると差が出る

評価軸	BERT	CrossBERT	Electra
GLUE フル微調整	86.4	86.6	87.8
GLUE 線形プローブ	67.4	73.8	76.9
MTEB(eng,v1) フル微調整	53.9	54.5	49.0
MTEB(eng,v1) 凍結	42.1	53.6	22.4
Retrieval（凍結）	19.2	40.7	0.0

• CrossBERTはフル微調整→凍結で 54.5 → 53.6（99%保持）。BERTは 53.9 → 42.1 と10ポイント以上落ちる。

• MTEBフル微調整の54.5は、はるかに多くの計算・データを投じた NeoBERT (51.3) や ModernBERT (46.9) を上回る。

• 〜 FLOPs で17モデルを学習。BERTの凍結性能は大規模ほど劣化し、最小モデルを下回るところまで落ちる。CrossBERTは全指標で単調にスケール。

• 大スケールではCrossBERTの凍結適応が非凍結ベースラインを上回り始める。

• 学習の安定性も差がある。大規模BERT/Electraは損失スパイクや1Bスケールでの性能崩壊が報告されているのに対し、CrossBERTは初期化標準偏差を0.02→0.015に下げるだけで2Bまで安定。

Electraとの対比（GLUEの罠）

• GLUEの表だけ見ると Electraが最強に見える（87.8）。しかし凍結MTEBは22.4、検索スコアは0.0。文埋め込みとして機能していない。

• ElectraはMLMではなくRTD（Replaced Token Detection）で学習する。全トークンから勾配が取れトークン単位の判別特徴は鋭くなるが、文埋め込みの幾何構造を歪める（先行研究でも指摘）。

• 著者らの結論は2つ。①平坦なバックボーンのまま目的関数をMLM→RTDに替えても解決しない、表現と再構成を分離する二部構造そのものが鍵。②GLUE型の分類プローブだけでは表現品質を診断できない、MTEBが暴く失敗をGLUEは隠す。

• ただし「RTDがトークンプローブで強いのに文埋め込みで崩壊する」機構的説明は本論文の範囲外（Limitationsに明記）。

所感・実務への示唆

• 検索・類似度用途でエンコーダを選ぶとき、GLUEスコアはあてにならないという指摘が一番効く。社内でエンコーダを選定する場面でも、凍結MTEB/Retrievalを見る価値がありそう。

• 「1つの凍結エンコーダ + タスクごとの軽量プーラー」という運用が現実的になる。タスク数だけバックボーンを複製・微調整しなくてよい。

• 他のLimitations: 平坦MLMが劣化する理論的説明はなし。検証は数十億パラメータ規模まで。

[paper] RECOVER: Robust Entity Correction via agentic Orchestration of hypothesis Variants for Evidence-based Recovery

post-ASR最近ちょっと追ってるので紹介

 

1. RECOVERは、ASR（自動音声認識）の多重仮説を活用し、制約付きのLLMエディタを用いてドメイン固有のエンティティ誤りを補正するエージェント型フレームワークです。

2. この手法は、「仮説の統合」、「修正案の提案」、「検証と適用」という3つのツールを連携させることで、LLMの幻覚を抑制しつつエンティティ認識の再現性を大幅に向上させます。

3. 5つの多様なドメインで評価した結果、ベースラインと比較してエンティティ単位の語誤り率（E-WER）を8〜46%削減し、特にLLM-Select戦略が最も安定した性能を発揮することが示されました。

背景

 

手法

 

Multi-Hypothesis Generation: 同一音声データに対し、異なるTemperature sampling（\(T \in \{0.0, 0.2, 0.4, 0.6, 0.8\}\)）を行うことで、互いに相補的な誤りを含む\(N=5\)個の仮説を生成する。これにより、一つの仮説で消失したエンティティが他の仮説で補完される可能性を高める。

 

Dynamic Entity Candidate Retrieval: エンティティリストから各セグメントに最適な候補（Top-K, \(K=200\)）を動的に絞り込む。以下のスコアリング関数を適用し、正確性、曖昧性、音韻的類似性に基づいて優先順位を決定する。 ここで、は一致トークン数、はLevenshtein similarity、は音韻的キーの接頭辞一致を指す。

 

Agentic Orchestration: Agnoを用いたエージェントが以下の3つのツールを順次実行する。

• Tool 1: Fuse Hypotheses: 複数の仮説から一つを選択・融合する。手法として「1-Best」「Entity-Aware Select」「ROVER Ensemble」「LLM-Select」の4つを比較。特にLLM-SelectはLLMの推論によって最適な仮説を選択する。

• Tool 2: Propose Corrections: 制約付きプロンプトを用いたLLMにより、エンティティの「検索・置換」のみを許可する。文法修正や一般的な書き換えは禁止される。

• Tool 3: Verify & Apply: 決定論的なガードレールにより、LLMの提案がエンティティリストに含まれるか、不要な置換でないかなどを検証し、衝突のない編集のみを適用する。

 

結果

5つの多様なドメイン（金融、航空管制、医療、汎用音声、対話）のデータセットで評価を実施。

• 成果: エンティティphrase word error rate (E-WER) を8〜46%削減し、Recallを最大22ポイント向上させた。

• 知見: 特に「LLM-Select」戦略が、全体的なWERを悪化させることなく、エンティティ修正において最も高い一貫性を示した。「ROVER Ensemble」等は deletion 修正には強力だが、ノイズの多いドメインでは全体的な挿入誤差（Insertion noise）を増大させる傾向がある。

• 結論: 提案手法は、エンティティの欠落や置換というASRの主要な失敗モードに対して極めて有効である。LLMの推論能力と決定論的なガードレールの組み合わせが、ハルシネーションを抑制しつつ正確な修正を実現する鍵となっている。

 

[pon]

ナイーブな人手辞書のループだと過剰修正で終了するので、こういう自社+商談相手のドメインの事前辞書作成+上のようなフレームワークである程度は解決できそう。ただ推論スケーリングは金なんだよなぁ。。。

MonkeyOCRv2: A Visual-Text Foundation Model for Document AI

概要

MonkeyOCRv2は、自然画像向けのCLIP・DINO・SAMなどでは捉えにくい、文書画像の文字 strokes、字体、細かなレイアウト、読み順を学習するための視覚テキスト基盤モデル

 

貢献は以下

• 文章タスク向けの視覚-テキストの大規模学習データセットを構築

• 画像を入力としてテキストレベルとピクセルレベルを組み合わせた事前学習方法の提案

• 事前学習で獲得した視覚エンコーダが強力な転移学習能力を持つことを示した

背景と課題

文書画像では、次のような局所的な視覚情報やレイアウトによる読み順が意味を左右しうる

一般的な視覚基盤モデルは、物体カテゴリや画像全体の意味、領域境界を重視しており、文字単位の細部を必ずしも保持しない。MonkeyOCRv2は、この「自然画像向け表現」と「文書に必要な表現」のずれを解消することを目指す。

主な提案

MonkeyDoc v2データセット

文書画像向けの事前学習データセットとしてMonkeyDoc v2を構築

• 専門家と言ってるが人ではなく特化モデルの意味

• 多言語のコーパスからランダムサンプリングして画像にレンダリングし、言語の多様性を確保。表の構造も自動生成してる

MonkeyOCRv2の全体像

MonkeyDoc v2を用いて視覚エンコーダ、テキストデコータ、視覚デコータを事前学習

三つのエンコーダ系列を学習

モデル	バックボーン	パラメータ数
MonkeyOCRv2-S	ViT-Small	2,800万
MonkeyOCRv2-B	ViT-Base	1億1,300万
MonkeyOCRv2-AS	ViTAEv2-Small	2,100万

用途に応じてモデルを使い分ける

• S/B：認識、文書解析、文書理解

• AS：マルチスケール特徴が重要な検出・セグメンテーション・改ざん検出

 

下流タスクへの転移

事前学習後の下流タスクでは、事前学習時の視覚デコーダとテキストデコーダは破棄し、視覚エンコーダだけをバックボーンとして転用。

既存タスクで利用されるheadはそのままバックボーンを置き換えるイメージ。エンコーダ自体のFTを伴うものとそうでないものがある。

結果

• 視覚デコーダを従来のものから置き換えることで全てのタスクで一貫して性能向上

• 多言語文章解析タスクにおいて他モデルと比較して軽量なモデルサイズでありながらそれらを上回る性能を発揮
• (わかりにくいがバブルサイズがモデル全体のサイズ）

定性評価

例1) 文章解析

例2) 文章理解

文書向けでなく画像基盤モデルをバックボーンとした場合と比較している点に注意

メインTOPIC

HSCodeComp: A Realistic and Expert-level Benchmark for Deep Search Agents in Hierarchical Rule Application

概要

• 提案しているのは手法ではなくベンチマーク。deep search agent が「人間が書いたルールを階層的に適用できるか」を測る。

• タスクは、EC の実データ（商品タイトル・属性・カテゴリ・画像・価格・URL）から10桁の HSCode（関税分類コード）を予測するもの。632件、人間エキスパートによるアノテーション付き。評価対象は foundation model 14本（ツールなし）、OSSエージェント6種、クローズドなエージェント3種。

• ベストのエージェント（SmolAgents + GPT-5 VLM）が10桁 exact match で 46.83%、人間エキスパートが 95.0%。48ポイント程度の差がある。

• majority voting も self-reflection も精度をほぼ動かさない。test-time scaling が効かないタスクとして提示されている。

背景: なぜ「ルール適用」を切り出すのか

• 著者はエージェントが扱う知識を3レベルに整理している。

• Level 3 の難しさは2点とされている。
• ルールの境界が曖昧。"for example ..." "such as ..." のような自然言語表現で外延が確定しない。
• ルール間の論理依存。除外条項（"excluding articles of heading 8539"）やカテゴリ横断の関係を辿らないと結論が出ない。

• 既存の HSCode 予測研究との差分も整理されている。従来は EC のテキスト分類タスクとして BERT 系や LLM プロンプティングで解かれており、エキスパートが書いたルールを活用していない。既存の HSCode ベンチマークは、公開された customs rulings から構築されているため data leakage がある点と、そもそも公開されていない点が制約とされる。HSCodeComp は EC のノイジーな商品説明から構築して公開する、という位置づけ。

問題設定: 10桁HSCodeの予測

• 入力 x = (タイトル t, 属性集合 A = {(k_j, v_j)}, プラットフォームのカテゴリ c, 画像 i, 価格 p / 通貨 u, 商品URL r)。マッピング関数 f: X → Y を LLM/VLM ベースのエージェントで実装する問題として定式化。

• 出力は10桁の数字列。頭2桁=chapter、4桁=heading、6桁=subheading までが WCO 共通で、6〜10桁目が国別コード（本ベンチは米国 HTSUS 想定）。5,000超のコードを持つ階層タクソノミの有効なパスを1本選ぶ。WCO が策定し、200カ国以上で通関・関税決定に使われている。

• エージェントが使える知識は3種類。
1. 階層的な関税規則（eWTP）。除外条項などの implicit logic relationships と、曖昧な言語制約を含む。

2. 人間が書いた decision rules。GRI 相当の6原則で、Rule 1 から Rule 6 まで飛ばさず順に適用する前提で書かれている。
3. 米国税関の判例DB（CROSS）。正しい判例だけでなく失効済み判例も多数含まれ、情報の信頼性をエージェント側で判断する必要がある。加えて判例情報がプレーンテキストのメール形式で提示される。

• decision rules の中身（Figure 13）。
• Rule 1: 見出しと注記の優先。まず heading（4/6桁）の文言と関連 Notes で決める。
• Rule 2: 未完成品と材料への拡張。本質的特徴を持つ未完成品は完成品として、他の材料を加えても原材料の性格を保つ物品は元の材料で分類。
• Rule 3: 複数 heading に該当する場合の優先順。特異性 → 本質的特徴（主材料・機能・用途）→ 番号の後順。
• Rule 4: 最類似の原則。前3ルールで決まらない場合、最も類似する物品の heading。
• Rule 5: 包装材・容器。通常一緒に販売される包装は物品と一緒に、再利用可能容器は別に分類。
• Rule 6: subheading の段階的分類。1-dash（5-6桁）から順に1段ずつ下り、各段で Subheading Notes と同一階層の関係を考慮する。
💡
「どの条文を選ぶかで迷ったときの優先順位」を与えるもの

• 商品説明が実データそのままでノイジー。略語・多言語混在・欠損・マーケ用語（"INS" "Aesthetic" "Korean Stationery"）が含まれる。

• 評価は正規化後の exact match。10桁精度がメインで、2/4/6/8桁も併記。

データ構築

• 大規模EC プラットフォームから収集。同一カテゴリ c ＆ 同一10桁コード y の重複を semantic redundancy filter で落として、簡単で頻出な商品に支配されないようにしている。カテゴリ分布のバランスも取っている。

• アノテーションは5ステップを2名のエキスパートが実施。(1) 商品ページを閲覧して情報を集める → (2) 中核となる構造化特徴を抽出する → (3) CROSS で関連判例を検索し、見つかれば eWTP で検証して軽微な修正を加える。見つからなければクエリを直すか Step 2 に戻る → (4) 判例がない商品では階層的 decision rules を実行して関税規則を適用する → (5) eWTP 上でコードの実在を確認する。
• なお「HSCodeComp のアノテーション中に関連判例が見つかることは非常に稀だった」と明記されている。判例参照ではなくルール適用が主経路になっている。

• 検証（Step 6）は、2名の結果が一致すれば採用、不一致ならシニアの関税エキスパートが両方をレビューして裁定、どちらも有効でなければ除外。さらに初期アノテーションに関与していない4人目のシニアが10%をランダム再アノテーションし、不一致率2%。

• 結果、632件 / 27 HS chapter / 32 first-levelカテゴリ。Jewelry & Accessories 106件(17%)、Home & Garden 83件(13%)、Tools 39件(6%)、Toys & Hobbies 35件(6%)、Shoes 34件(5%) と続く long-tail 分布で、実世界の商品分布に近いとしている。

• アノテータの時給は 34.6 USD 超。Amazon Mechanical Turk の平均時給 3.13 USD との比較が Ethics Statement に記載されている。

• 注意点として、公開版のデータセットは商品URLと画像がコンプライアンス上削除されている（Reproducibility statement に明記）。

実験設定

• LLM/VLM のみ（ツールなし）: 14本。GPT-5, Gemini-2.5-PRO, GPT-4o, Kimi-K2, Claude Sonnet 4, DeepSeek 系, Qwen 系, O3-mini, Nemotron-32B。うち GPT-4o / GPT-5 / Claude Sonnet 4 / Gemini 2.5 Pro は VLM として商品画像も与える。

• OSSエージェント6種: SmolAgents, Aworld, Agentorchestra, OWL, WebSailor, Cognitive Kernel。バックボーンは既定で GPT-5。SmolAgents のみ vision 対応が可能で、他フレームワークは VLM と非互換。全フレームワークが web 検索を含む標準ツールを使う。

• クローズドなエージェント3種: Manus, Gemini Deep Research, Grok DeepSearch。公開 API がないため、49件の representative example に対する手動評価。

• ツールと実行設定: 全ベースラインに検索ツールを持たせ、CROSS データベース、階層的関税規則、人間が書いた知識ベースと decision rules にアクセスできるようにしている。temperature とコンテキストウィンドウはデフォルト設定。decision rules と webpage visit ツールは性能が上がらなかったため既定の評価では使わない（クローズド系は制御できないため webpage visit を制限していない）。商品画像は SmolAgents でのみ使用。出力形式は全システム共通で に10桁コードを1つ。

実験結果

• 全手法で桁数が増えるほど精度が落ちる。SmolAgents (VLM) でも 2桁 82.06 → 6桁 62.38 → 10桁 46.83。2桁の時点で8割程度なので、chapter レベルの見立てを外している例も一定数ある。

• 2桁精度は上位モデル間でほとんど差がない（GPT-5 82.59 / Gemini-2.5-PRO 82.28 / SmolAgents 82.28）。差がつくのは8桁・10桁、つまり国別コードの階層。

• ツールなし LLM はエージェントに大きく劣る。ドメイン固有知識の欠如が要因という説明。同じ GPT-5 でも 28.96 → 42.72 と14ポイント近く差がある。32B 前後のモデルは10桁でほぼ 0（Qwen3-32B 0.32 / QWQ-32B 0.16 / Qwen2.5-72B 0.16 / Nemotron-32B 0.00）。

• VLM と LLM の比較は一律ではない。GPT-5 は 28.96 → 29.27、GPT-4o は 18.35 → 18.51 と微増、Claude Sonnet 4 は 11.87 → 11.23 と微減。

• OSSエージェント間の差は、フレームワークの構成よりも後述の推論深度で説明されている。Cognitive Kernel の 26.42 と SmolAgents の 42.72 は同一バックボーン・同一ツール。

カテゴリ別の分析

• 32 first-levelカテゴリについて2つの分布を見ている。CID (Challenging Product Distribution) は全ベースラインが外した商品の分布、APD (Average Performance Distribution) は全ベースラインの平均10桁精度の分布。

• CID では、最も難しい商品が long-tail カテゴリに集中する。Novelty & Special Use (1.3%)、Men's Clothing (2.2%) が挙げられている。

• APD では、大半のカテゴリで平均精度が25%未満。相対的に高い Hair Extensions & Wigs でも47%。頻出カテゴリの Jewelry & Accessories (13.1%)、Home & Garden (16.8%)、Tools (6.2%) でも平均性能は18%を下回る。件数の多いカテゴリでも精度が上がるわけではない、という形になっている。

• 青がデータセットのうちそのカテゴリが占める割合

• 赤がそのカテゴリの中でベースラインが間違えた割合

アブレーション

• 人間が書いた decision rules をプロンプトに入れると精度が下がる。著者は「現状のエージェントは人間が書いた decision rules の適用に苦戦しており、それが階層的関税規則の利用能力を制限している」と説明し、デフォルト設定から decision rules を外している。

• webページ訪問ツールを足すと下がる。ページ本文の量が多く重要情報が埋もれてエージェントをミスリードする、一方その重要情報は検索エンジンのスニペット側で正確に取れている、という説明。こちらもデフォルトから外している。

• 推論深度を深くすると下がる。WebSailor は SmolAgent と同じモデル・同じツールを使いながら下回る。ツール呼び出し前に深い推論を促すプロンプトになっているためで、think depth を浅くするほど精度が上がり、No-Think では SmolAgent に近づく。OSSエージェント間の性能差の主要因はフレームワークではなくタスクプロンプトで指定された推論深度、というのが著者の結論。
• ケースとしては、T シャツの分類でツール呼び出し前に 6109.90.1050（Women's）まで推論しきってしまい、SmolAgents が検索で得た 6109.90.1007（Men's）を外す例、スプレーガンで 8424.20.1000 と推論で断定して 8424.20.9000 を外す例が挙げられている。

• バックボーンの差は大きい。SmolAgent で GPT-5 42.72 / Gemini-2.5-Pro 34.49 / Claude 4 Sonnet 33.70 / Qwen-MAX 17.43。Aworld・WebSailor・AgentOrchestra でも GPT-5 が Gemini 2.5 Pro を一貫して上回る（Aworld 41.30 vs 29.24、WebSailor 35.44 vs 31.21、AgentOrchestra 41.30 vs 30.61）。

• 画像は概ねプラス。素材や表面の特徴がテキストに現れないケースを拾え、拾った属性が既定のルールに紐づくことが利得につながるという説明。
• Appendix I では、シルク（天然繊維）のブーケを画像から確認して 6702.90.3500 → 6702.90.6500 に直す例、刃のないハンドルキットを部品として 8211.93.0035 → 8211.95.9000 に直す例が挙がっている。ただし Gemini-2.5-Pro のみ微減。

test-time scaling

• Majority Voting: SmolAgent (GPT-5) で Voting@K を K = 1, 2, 4, 8, 16 と増やす。2/4/6/10桁いずれも改善はほぼ無視できる水準。

• Self-Reflection: SmolAgent (GPT-5) に自己評価・修正機構を組み込むと 42.72 → 42.57 と微減。

• 解釈としては、誤りが確率的なブレではなく系統的に同じ分類パスに落ちているためと考えられる。多数決は系統誤差を減らせない。

• 著者は、階層的ルール適用のエージェントに対しては別種の test-time scaling 戦略が必要、という形でまとめている。

失敗例

まとめ

• 判断ルールを明示的に渡す、Webページを直接読ませる、深く思考させる、test-time scalingを使う、といった「素朴に効きそうな介入」の多くが、このタスクでは効果がないか逆効果になる。効いたのは画像などマルチモーダル情報を与えることだけだった。

• 失敗の多くは「素材・機能という本質的性格」よりも「見た目・タイトルの印象」を優先してしまう誤り(Wrong Rule Application, Lack of Domain Knowledge)に集約される — これはルールベース推論を要するあらゆる実務ドメイン(法務・医療・貿易)に共通しうる。