今週のTOPIC

[blog] Language model harnesses are compositional generalizers

• RLM作者の人のブログ

[paper] Language Models Need Sleep: Learning to Self-Modify and Consolidate Memories

Google Research と Cornell大学による研究。LLMにも睡眠が必要だとのこと。24時間働いてほしい。

継続学習に際して、短期記憶（in-context / memory などに代表）を長期記憶（model parameters）に変換する仕組みの提案。忘却とかを防ぐよん。

1. メモリ統合（Memory Consolidation）
• ノンレム睡眠（NREM）に対応。高頻度更新ブロックに蓄積された脆弱な抽象情報を、低頻度ブロックの安定した長期パラメータへ転送・定着させる。

2. ドリーミング（Dreaming）
• レム睡眠（REM）に対応。外部入力を遮断した状態で、内部知識を再結合した「夢（合成データ）」を生成し、自己修飾を通じて知識を洗練させる。

 

※ 論文内では、全ネットワークがパラメタ更新の対象であるが、パラメタの更新頻度を調整することで短期記憶と長期記憶のモジュールを切り分けている。

[blog] In-House LLM Serving at Netflix

1. なぜ自社構築したのか

• LLMを ML専用サイロ ではなく、既存の本番サービス群に統合 したかった

• 求めたもの: 低レイテンシ / 深いカスタマイズ / 既存インフラとの統合

• 研究→本番のハンドオフコストを下げたい（ML実践者が研究したモデルをそのまま本番へ）

2. アーキテクチャ / 技術スタック

レイヤ	採用技術	入口 / 役割
統合サービング	JVM(Java)	gRPC（社内クライアント向け）＋ 制御プレーン連携
OpenAI互換フロントエンド	FastAPI(Python) / Triton同梱	OpenAI互換HTTP（）
ミドルウェア	NVIDIA Triton Inference Server	推論エンジンのホスティング
推論エンジン	vLLM（V0 → V1 へ移行）	GPUで実際にトークン生成
制御プレーン	JVM(Java)統合	デプロイ・バージョン管理・オートスケール
モデルストレージ	Amazon FSx	モデルキャッシュ（高速ロード）

3. 4つの主要な設計判断とトレードオフ

① 推論エンジン: TensorRT-LLM → vLLM に変更

• 多段コンパイル不要でカスタムモデルを読める／カスタムデコード用の拡張フック／デバッグしやすく研究者に馴染む

• 落とし穴: Triton と vLLM のバージョン非互換（例: Triton 25.09 × vLLM 0.11.2 が破綻）→ vLLMバージョンはパッケージ時に固定必須

② パッケージング: vLLM backend vs Python backend

• vLLM backend: フロントエンドと独立進化できるが HuggingFace標準に限定

• Python backend: カスタム前処理/後処理OKだがフロントエンド変更と同期が必要

③ API: gRPC + OpenAI互換HTTP

• Triton の OpenAI互換フロントエンドを FastAPI 経由で提供

• 落とし穴: （JSON構造化出力）が無言でドロップ されていた → git-subtreeでパッチし、vLLMの guided decoding へ変換

④ デプロイ戦略: Red-Black vs Versioned

• Red-Black: I/O仕様が安定なら有効。スキーマ変更時に調整ギャップ

• Versioned: 破壊的スキーマ変更に対応できるが GPUが一時的に増える

• 推奨: 可変設定をモデルに埋め込み、なるべくRed-Blackで回す

4. パフォーマンス最適化

制約付きデコーディング（constrained/guided decoding）の進化

• vLLM V0の問題: カスタム logits processor が リクエスト単位で逐次実行。CPU処理がリクエスト数に線形増、GIL が並列化を阻害、バッチが大きいほどテールレイテンシ悪化

• vLLM V1での改善: バッチ単位処理 へ移行、C++実装でマルチスレッド化（GIL回避）。バッチが増えても logits処理時間がほぼ平坦に

その他

• モデル配信: S3/HF直DLは遅い → Amazon FSxに事前配置

[paper] Rethinking the Evaluation of Harness Evolution for Agents

LLMエージェントの性能向上手法である自動的なharness進化について、既存の評価プロトコルではテスト時の試行回数による性能向上と設計の改善が混同されており、過学習のリスクがあることを指摘。

 

• ハーネス進化を他の手法と公平に比較するため、統一された計算予算・フィードバック予算の下で以下の4つの手法を定義した。
• Parallel Sampling: 固定されたハーネスを用い、複数の軌跡（trajectory）を並列生成して最良のものを選定する。
• Sequential Refinement: 固定されたハーネスを用い、過去の軌跡やフィードバックを参照して逐次的に推論を修正する。
• Harness Evolution: 経験ストアを保持し、メタエージェントがフィードバックに基づいてハーネス 自体を反復的に進化させる。
• 実験では既存手法の AHE [Lin et al., 2026] をベース
• Harness Scaling: ハーネス進化の概念を単一タスクのインスタンスレベルに適用したものであり、推論時に動的にハーネスを修正する。
• タスクを1つ解くごとに、メタエージェントが「今の失敗はこのハーネス（プロンプト等）のせいだ」と判断し、そのタスク専用にハーネスを書き換えて解き直させる。
• 本論文が比較のために提案した「その場限りのハーネス修正」手法

 

 

• 1. 予算を揃える（Matched Budgets）
• 「予算を揃える」とは、ハーネス進化（Harness Evolution）手法と、より単純なテスト時スケーリング（Test-time Scaling）手法との間で、モデルの推論回数やフィードバックの利用回数を同等にして比較することを指します。
• 背景: ハーネス進化は、タスクのフィードバックを用いて繰り返しハーネスを修正・評価する「探索的」なプロセスです。既存研究では、この手法による性能向上が「ハーネス自体の設計改善」によるものか、単に「より多くの探索予算を費やしたこと」によるものかが不明瞭でした 。

• 2. 探索と発見を切り分ける（Generalization to Held-out Tasks）
• 「探索と発見を切り分ける」とは、ハーネスを最適化するために使用したタスクセット（探索）と、そのハーネスの性能を最終的に測定するタスクセット（評価）を分離し、汎化性能を測定することを指します。
• 背景: 多くの既存手法では、公開ベンチマークのタスクそのものを使ってハーネスを探索し、同じベンチマークで最終結果を報告しています。これでは、得られた性能向上が「未知のタスクにも有効な普遍的なハーネス設計」なのか、その「特定のタスクセットに対する過学習（オーバーフィッティング）」なのかが区別できません。

実験

 

考察

 

「ハーネス進化は一見すごそうに見えるが、『同じ回数だけ解き直しをさせた単純なエージェント』というライバルと比較してみると、実は大した優位性がない（あるいは単に特定のタスクに特化してしまっているだけだ）」という厳しい話をしている。

 

メインTOPIC

HICode: Hierarchical Inductive Coding with LLMs

arXiv: 2509.17946著者: Mian Zhong*, Pristina Wang*, Anjalie Field（Johns Hopkins University） 発表会場/年: EMNLP 2025 (main conference, long paper) コード: https://github.com/mianzg/HICode

概要

• 大規模コーパスのきめ細かい分析は、これまで「人手ラベリング（深いがスケールしない）」か「トピックモデル（スケールするが制御できない）」の二択だった。

• HICode は質的研究の帰納的コーディング（inductive coding）を LLM でスケールさせる 2 段パイプライン
1. 各テキストセグメントから分析軸に沿ったラベルを直接生成
2. 生成ラベルを LLM プロンプティングの反復で階層的にクラスタリング

• 人手アノテーション済みの 3 データセットでテーマ復元性を検証し、最難関の Astro での人手評価では precision 0.72 / recall 0.74 と TopicGPT（0.18 / 0.33）を大差で上回った。

💡 一言で言うと: 「事前定義カテゴリなし・分析軸の指定あり」で、LLM がラベル生成 → 階層マージし、テーマ体系をボトムアップに発見するパイプライン。

📖 用語: 帰納的コーディング（inductive coding） = データから直接ラベルを起こし、それをグループ化してテーマを構成する質的分析手法。既存理論・コードブックからラベルを与える演繹的（deductive）コーディングの対義。

背景

• 人手の主題分析 / 帰納的コーディング: データを手作業で読み通し、関連する内容にラベルを付け、ラベルのグループ化とデータの再コーディングを反復的に行う。深い分析ができるがスケールしない。

• トピックモデル: LDA (2003) が今なお定番で、ニューラル系が LDA を上回らないという証拠すらある（Hoyle et al. 2021, 2022）。根本的な限界は制御可能性の欠如で分析軸の指定ができない。

• LLM を使った先行研究: NLP における LLM アノテーション研究の大半は演繹的（既存コードブックへの分類。Xiao et al. 2023; Ziems et al. 2024）。帰納側では TopicGPT（Pham et al. 2024）があるがシードトピックが必要で出力がトピックに寄りがち。LLooM（Lam et al. 2024）は小規模・インタラクティブ探索向けの設計。

手法

ラベル生成

• ユーザ提供（データセットごとに変わる）
1. 背景情報の短い記述 — 前提・用語の意味を揃えるパート。例えば encoded values を分析するなら「これは論文が暗黙に良しとしている価値観のことだ」と定義しておく必要がある。
2. 帰納的コーディングのゴール — 分析軸を定めるパート。

• 固定部（データセットによらず共通）: 関連性の判定と、observational（観察的）・concise（簡潔）・clear（明確）なラベルの生成を指示する

• ラベル生成（付録 A.1）: → ゴールに照らして関連するときだけラベルを付ける（＝ 判定の基準）

• 階層クラスタリング（付録 A.2）: → ゴールにとって意味のあるテーマになるよう統合する

階層クラスタリング

1. 生成ラベル全体をランダムに 100 件ずつのバッチに分割する

2. 各バッチについて、①生成モジュールと同じ「帰納的コーディングのゴール」＋②そのバッチのラベル群＋③類似ラベルをテーマに統合させる固定指示を LLM に渡す

3. 全バッチを処理し終えたら、出力されたテーマ群を次イテレーションの入力にする（＝テーマがさらに上位テーマへ統合されていく）

4. あらかじめ決めた最大反復回数に達するか、ユーザ指定のテーマ数の閾値に収束したら終了

設計動機

• 各テキストセグメントに対するラベル生成と各バッチのクラスタリングが完全に独立 → 大規模データを並列処理できる

• 2 モジュールが完全分離 → 将来それぞれを小型特化モデルへ蒸留する後続研究が容易

• 先に細粒度コードを作ってから統合する順序なので、各イテレーションの中間層が全て残る → 粒度をユーザが「後から」選べる
• kmeans / LDA は実行前にクラスタ数・トピック数を決めさせられ、粒度を変えるには再実行が要る
• HICode は一度走らせれば全粒度が手元にあり、「17 テーマでは粗すぎるので一つ下の層を見る」「この 1 テーマだけ深く降りる」を再実行なしで選べる（＝ドリルダウン）

実験

評価指標

• テーマレベル: 埋め込みのコサイン類似度が閾値 を超えた ペアをマッチとみなす（多対多を許容 = 粒度差を許容）。precision は 、recall は 。 で複数報告。

• セグメントレベル: テーマレベルはテーマ名の類似度しか見ないため、名前は似ていても指しているデータが全く違うケースを検出できない。そこでマッチしたテーマのペアについて、双方が付いているセグメント集合の重なりを測る。
• precision: 生成テーマ が付いたセグメント集合を 、うち対応する正解テーマにも付いているものを として （拾ったセグメントのうち正しかった割合）
• recall: 正解テーマ が付いたセグメント集合を 、うち対応する生成テーマにも付いているものを として （本来属するセグメントのうち拾えた割合）
• 全体スコアはセグメント数による重み付き平均: として （recall も同様に で加重）。単純平均だと 3 件の小テーマと 14K 件の巨大テーマが同じ重みになってしまうため、データの大部分を占めるテーマを正しく扱えているかを重視する設計

実験設定

データセット

• 規模: 15 テーマ / 112,585 セグメント（11,903 文書を段落分割）/ 複数ラベル可

• 中身: 「Economic」「Morality」等の政策フレームを付与したニュース記事

• 選定理由: フレームが意図的にトピックとは別物になるよう設計されており、分析軸とトピックの乖離を試せる

• 注意: 著者自身が限界を 2 点明記 — ①コーディングが完全な帰納ではない、②2015 年から公開済みで事前学習データへの混入リスクがある

• 規模: 9 テーマ / 369 セグメント（クエリそのまま）/ 複数ラベル不可

• 中身: 天文学文献ボットに送られたクエリを、その「種類」（"Knowledge seeking: Specific factual" 等）でコーディング

• 選定理由: 唯一の完全な帰納コーディングであり、かつ全評価モデルの knowledge cut-off 後に公開されたためリーク懸念もない

• 最も条件の厳しい本命の評価対象。人手評価もこのデータで行われる

• 規模: 82 テーマ / 2,157 セグメント（論文 100 本の選別スニペット）/ 複数ラベル可

• 中身: ML 論文の encoded values を「Efficiency」「Performance」等でアノテート

• 選定理由: **最多のテーマ数（82）**を持つため頑健な評価ができる

• 注意: 演繹と帰納のハイブリッドであり、純粋な帰納コーディングではない

ベースライン

• 従来の内容分析では、研究者はまずデータのサンプルから暫定ラベル集合を作り、残りをそのラベルで注釈しながら合わないデータが出たらラベルを追加し、必要に応じて再コーディングする（Hsieh and Shannon 2005）。これを LLM で再現したもの

• 1 イテレーション = ①未見データのランダムサンプルにラベル生成 → ②ラベルを上位テーマにマージ → ③数ラウンドにわたり少数のセグメントしか割り当たらなかったテーマを削除

• 全 3 モジュールを 10 イテレーション回した後は、生成をやめてマージと削除のみを実行。全ラベルのセグメント数が閾値を超えたら停止

• ① トピック生成: 一様サンプリングした部分集合に対し、逐次的に「既存トピックを割り当てるか、新しく作るか」を問うことでトピックリストを育てる。欲しい出力は個々の割り当てではなくリストの方

• ② assignment: リスト確定後、全データに改めてトピックを割り当て直す（これも LLM プロンプティング）。①は部分集合しか見ておらず、かつ早く処理された文書ほど貧弱なリストで判定されている（1 件目はシード 1 個の中から選ぶしかない）ため、最終リストでやり直す必要がある

• 概念の抽出・クラスタ・統合・割り当てを、人が画面上で何度も行き来しながら進める対話的な分析ツール

• 著者評: 最終ゴールは TopicGPT より HICode に近いが、①帰納的コーディング済みデータで評価されていない、②設計が「的を絞ったコーパス分析」より小規模な対話的探索に向いている

実装

• 公平のため、全パイプラインの全モジュールで に統一

• TopicGPT の example topics、LLooM の seed words、HICode と Incremental のプロンプトはすべて付録 §A・§B に開示

• 各 5 回実行の平均 ± t 分布信頼区間で報告

結果

テーマレベル

• テーマ数が最大であるValuesデータセットにおいて HICode が precision / recall とも全手法最良。

• Astro は「クエリの内容」でなく「クエリの種類」を狙う、分析軸指定が問われる設定。ここで TopicGPT は precision 0.04 まで崩壊（出力が「太陽系外惑星研究」のような内容トピックに寄る）。HICode は Incremental に対して recall 同等・precision 大差（0.53 vs 0.19）。

• Frame での TopicGPT の健闘は、フレーミングアノテーションがトピックに近い性質を持つこと + ゴールドシードを与えていることによる（著者自身が脚注で「TopicGPT の数値はやや水増し」と明記）。それでも HICode は recall で上回る。

セグメントレベル

• 著者自身が「直接比較できない」と明記: セグメントレベル指標はマッチしたテーマの集合に対してのみ計算され、その集合はモデルごとに異なる。

• LLooM は Astro recall 0.96 で HICode（0.76）を上回っている。ただし脚注で「5 回中 4 回はマッチテーマが空で指標が計算不能、これは 1 回の実行のみの結果」と説明される（表の下線は一部実行が除外された印）。
• HICode 自身も Astro k=0.5 は 5 回中 2 回が除外されている（0.57 / 0.30）。

• Frame は表 4 に存在しない。Frame のアノテーションが段落単位ではなくアノテーターによる自由なスパン選択だったため、セグメントレベル評価の対象外。つまり「総じて」と言っても Astro / Values の 2 データセットのみの話。

人手評価（Astro）

モデルアブレーション（Values）

• 実験 A: クラスタリングを gpt-4o-mini に固定し、生成モデルを振る → 性能がほぼ動かない（llama-3.2-3b から Claude まで全モデルで precision ≥ 0.53 / recall ≥ 0.22）。

• 実験 B: クラスタリング側のモデルを振り、各条件で生成 gpt-4o-mini と生成 llama-3.1-8B を比較 → gpt-4o-mini（precision 0.54–0.64 / recall 0.26–0.40）が llama-3.1-8B（0.47–0.58 / 0.21–0.33）を 0.06–0.07 ほど上回る。数値の幅はクラスタリングモデルを変えたことによる振れ。

何を意味するか: 2 モジュールは部分的に代替可能

• クラスタリングが強いとき（A）は、生成が 3B の弱いモデルでも性能が落ちない = 強いクラスタリングが雑なラベルを救っている

• クラスタリングを弱めると（B）、初めて生成モデルの差が表に出る = 強い生成モデルが弱いクラスタリングを補う

なぜ「生成を安くする」のが正解か: 呼び出し回数の非対称性

ケーススタディ（OIDA: オピオイド訴訟文書）

• データの絞り込みも先行研究を踏襲。Eisenkraft Klein らはアーカイブを "sales contest" で検索したが件数が多すぎて狭いサブセットの人手分析に後退した。HICode は同じ検索語を Mallinckrodt 社のメールコレクションに適用し、3,861 通 → 163,173 セグメントを全量分析（人手では不可能だったスケールでの再実行）

• 生成は llama-3.1-8B、クラスタリングは gpt-4o-mini（モデルアブレーションの「生成は安く、マージは強く」構成の実演）

• 生成段階で 40%（65,642 セグメント）が Irrelevant 判定。5 イテレーションで 70K ラベル → 最終 17 テーマに収束。最大テーマは「sales strategies and techniques」（約 14K ラベル）、次点「regulatory and compliance」（約 6K）

限界と今後

• 評価指標の信頼性が最大の限界。質的分析は人間同士でも解釈が割れる前提のため厳密一致は期待できず、5 回実行 × 複数閾値で緩和しているが、指標自体の改善が今後の課題。

• 検証は特定のデータセット・モデルの組に限られ、新しい設定への一般化は未保証。

• ユーザが背景情報・分析軸を与える必要がある。プロンプト最適化はしていない（= 慎重なプロンプト作成なしでも動く示唆でもあるが、プロンプト選択で結果は変動しうる）。