• コード：https://github.com/SakanaAI/ShinkaEvolve

• 先行研究
• 既存のアプローチはサンプル効率が悪いかつ手法が公開されていない
• OSSでサンプル効率の高いShinkaEvolveを提案

• 手法
• 一般的に進化的アルゴリズムは効率が良くない
• サンプル効率を上げるために3つの段階的制御フローを作成した
1. Parent Selection Strategy
• 一様サンプリングや貪欲な山登り法ではなく、重み付きサンプリング
• fitnessはタスク毎に異なる性能を表す指標
• Circle Packing: 縁の半径の合計
• AIME: 正答率
• ALE -Bench: 平均スコア
• novelty_factorは子孫の少なさで評価
2. Code Novelty Rejection Sampling
• 似たようなコードであれば再度計算しないための工夫
• すでに実行されたコード群と新しいコードのコサイン類似度を計算し、その最大値が0.95を超えた場合は受け入れない
• 二段階目としてLLM as a judge的に本当にその二つのコードは本当に同じなのかを判定。
• LLMをかますと時間はかかるがサンプル効率は上がる。
• 重複評価を50%削減できた

3. Adaptive LLM Ensemble Selection
• 異なるLLM （GPT、Gemini、Claude、DeepSeek）の相対的なパフォーマンスに基づいて、それらのサンプリング確率を動的に適応。
• Multi-Armed Banditの一つであるUCB1を改良して使用
• どのモデルを使うかを決めるための手法
• これらの手法を通じて「プログラム」を最適化するのがやりたいこと。promptを最適化するのではない。
• Full Edit, Diff Edit, Cross Over(二つの組み合わせ)のどれかを使う
• 以下にプロンプト一覧
• https://github.com/SakanaAI/ShinkaEvolve/tree/main/shinka/prompts

• 結果
• Circle Packing
• たった150サンプルでAlphaEvolveの解を上回った

• AIME
• 10回までの呼び出しという制限の中で高い性能を発揮



• ALE-Bench
• NP困難問題の最適化
• そもそも優秀だったALE-Agentに対して更に改良。コンテストに参加していれば2位の性能だった。



• LLM Training
• MoEを作成するときのLoad Balancing Loss (LBL)を最適化させて、DeepSeekチームが発見したLBLよりも優れた性能を見せた

• プロダクトにAIエージェントを組み込むにあたって、AIならではの非決定性が難しいよね。特に、決定的な部分と非決定的な部分が入り混じるようなタスクの扱いが難しいよね、という課題の解決を目指したAIエージェントフレームワーク Embabel というフレームワーク紹介

• 紹介されている特徴
1. 多くのエージェントフレームワークがLLMにすべて任せるのに対し、Embabellはタスク実行前にGOAP (Goal Oriented Action Planning) というLLMに依存しないアルゴリズムを用いて計画を策定する。
2. LLMの入出力の定義に、KotlinのデータクラスやJavaのレコードといった厳格な型を持つドメインモデルを利用

• 後者はPydantic AIやzodの利用、あるいはStructured Outputsなど同等のものあるくない？と思ったが、１のGOAPとの組み合わせがユニークで強いと理解した。

• GOAPでは記載の通りLLMを利用せずに、定義されたドメインモデル・型を組み合わせることでGoalを達成できるようなPlanを決定的に組み上げる仕組み。
• それぞれのActionの入出力の型が厳格に決まっているので、Condition を Goal に繋げるようなパズルをしているよう。
• Actionごとに型に加えて前提条件（preconditions）と結果条件（postconditions）ももち、これもヒント。
• Planを実行中に不都合が生じたらPlanを作り直す。

• ワークフロー生成のヒントになりそうだなと感じた。とはいえ、Actionや状態が複雑だとどこまでいけるんだろう。

• あと、Java / Spring との親和性が高いのはそうで、既存のエンタープライズシステムにエージェントを導入する際には有効な手段となりそう。

• EmbeddedGemma



• パラメータ数: 308M
• 大規模モデルに匹敵する精度
• 多言語に対応

• 学習方法
• Gemma 3 (decoder-only, 300M) をベースにし、Encoder-Decoderモデルに変換しpretrain → encoder部分だけ取り出す



• decoder-only checkpointを使ってencoder, decoderを初期化
• EncoderがBidrectional Self-Attentionに変わるので文脈表現の質が向上する
• Decoderの値で初期化することで、知識を受け継ぎ学習がより安定化する
• Pre-finetuning
• 大規模で様々なタスク・コーパスの入った query-target ペアデータを使い学習
• Finetuning
• より品質の高いタスク特化データを使った学習
• ベイズ最適化でタスクの混合比率を調整し、得意領域の異なる何パターンかのモデルを得る
• Model Souping
• finetuningで得られたモデルのパラメータの平均をとって1つに統合する

• 評価



• より大きなモデルに対して同等以上の性能

• コンテキスト設計の変化
• 推論前に埋め込み検索を使う → ジャストインタイム型コンテキスト

• ジャストインタイム型コンテキスト
• すべてを事前処理せず、識別子（ファイルパス、クエリ、リンクなど）を保持
• 実行時に必要情報を動的に読み込む
• 完全記憶ではなく外部の索引システムを利用して必要時に検索
• 人間の認知との類似
• メタデータの活用
• ファイル名・フォルダ構造・タイムスタンプが行動指針や関連性判断に役立つ
• 探索を通じて段階的に文脈を発見し、必要情報のみを作業メモリに保持
• エージェントは網羅的ではあるが必ずしも関連しない情報に埋もれることなく、適切なサブセットに集中

• トレードオフ
• ランタイム探索は速度が遅くなる
• 適切なツール設計がないと誤用や情報見落としのリスク

• ハイブリッド戦略
• 一部データは事前取得し、残りは動的探索
• Claude CodeではCLAUDE.mdを初期挿入しつつ、globやgrepで補完
• インデックスの陳腐化や構文木の複雑化を回避

• 変化の少ない法務・財務分析に有効

要約ツール

• LLMを要約ツールとして利用するが、汎用的なLLM、特に小規模なモデルは、ウェブ検索のコンテキストで効果的に会話を要約するのに苦労することが多い。

• gpt-oss-120bなどのLLMから収集された⟨Conversation , Summary⟩ペアを使用して、Qwen3-30B-A3B-Thinkingをファインチューニングすることにより、要約機能を特化させ、ReSumTool-30Bを作成。

ReSumパラダイム学習

• エージェントがReSumパラダイムを習得できるようにするために、調整されたReSum-GRPOアルゴリズムを通じて強化学習（RL）を採用。

• エージェントはReSumTool-30Bを呼び出して会話を圧縮し、要約状態から続行し、完全な軌跡を複数の部分に自然に分割する。

• 軌跡レベルの報酬 R_1の計算:
• ロールアウト H_1 が終了し、このロールアウト全体に対する単一の報酬 R_1を計算します。

• 軌跡レベルのAdvantage の計算:
• グループ内の他のロールアウトの報酬と比較して正規化

• Advantageブロードキャスト:
• のブロードキャスト: この計算された単一のAdvantage は、そのロールアウトを構成するすべてのセグメント に、同じ値として分配（ブロードキャスト）されます。

実験

• 実験には、エージェントが広範な探索を必要とする3つの挑戦的なベンチマーク（GAIA、BrowseComp-en、BrowseComp-zh）を使用。(問題解決に必要な探索ステップが非常に長い「父親が心臓病で亡くなり、妻との間に5人の子供をもうけた後、姉がいた画家。後に夫婦関係が破綻し、さらに3つの関係を持った。この人物を題材にした文学作品は何という名前か？」)

• LLM AS toolを蒸留で作るのかーおもしろー

• サマライズなどユーザーとのやり取りを分割して強化学習ってこうやるのねー

• Dataset: huggingfaceopenai/gdpval · Datasets at Hugging Face

• Blog: OpenAIMeasuring the performance of our models on real-world tasks

TL;DR

• 研究の背景と目的:
• 高性能なAIモデルが労働市場に与える影響（タスクの自動化、雇用の代替など）についての議論が活発化
• AIの経済的影響を測る従来の方法（AI導入率やGDP成長率など）は、技術が普及した後にしか評価できない「遅行指標」であるという課題
• AIの能力そのものを直接測定することで、AIが経済に与える潜在的な影響を、社会に広く普及する前に評価するアプローチを提案

• GDPvalベンチマークの概要:
• GDPvalは、AIモデルの性能を現実世界の経済的に価値のあるタスクで評価するために作られたベンチマーク
• 米国のGDP（国内総生産）に貢献する上位9セクター、44職種の業務をカバー



• タスクは実際の業務成果物に基づいており、評価は主に人間の専門家による直接比較

• GDPvalの利点:
• 現実性 (Realism): 学術的なテストとは異なり、タスクは業界の専門家が実際に行った業務に基づいて作成
• 代表的な網羅性 (Representative breadth): ソフトウェア工学など特定の分野に偏らず、44職種にわたる1,320のタスクをカバー
• コンピュータ使用とマルチモーダル性: CADファイル、ビデオ、スプレッドシートなど、多様なファイル形式の操作を要求
• 主観性 (Subjectivity): 正確さだけでなく、構造、スタイル、美しさといった主観的な要素も評価対象
• 上限のない評価 (No "upper limit"): 満点が決まっているテストと異なり、比較対象（ベースライン）をより高性能なモデルに更新し続けることで、継続的な評価が可能
• 長期的な難易度 (Long-horizon difficulty): タスクの完了には、専門家でも平均7時間、長いものでは数週間かかる

内容

• タスクの作成 (Task Creation)
• タスクの基本構成
1. リクエスト (Request): 実際の業務依頼を模した指示書。多くの場合、作業に必要な背景情報やデータを含む参照ファイルが添付される
2. デリバラブル (Deliverable): リクエストに応じて作成されるべき成果物。人間の専門家が実際に作成した「お手本」
• 網羅性の確保: タスクを作成した専門家は、自分たちが作ったタスクがどの業務に該当するかを、米国労働省の職業情報データベース「O*NET」のタスクリストと照合。ベンチマークが特定の業務に偏らず、その職種の代表的な活動を広くカバー
• 品質評価: 作成されたタスクの質を評価するため、別の専門家が各タスクを複数の観点から評価
• 難易度 (Difficulty): タスクを遂行する上で求められる専門性や複雑さ
• 代表性 (Representativeness): そのタスクが、その職種の典型的な業務内容をどれだけ反映しているか
• 完了時間 (Time to complete): 専門家がそのタスクを完了するのに要する平均的な時間
• 全体的な品質 (Overall quality): 現実世界の業務基準に照らした総合的な質
• タスクの金銭的価値の推定: 各タスクの経済的な価値を概算するために、専門家が報告した平均完了時間に、米国労働省の職業雇用賃金統計（OEWS）から得た該当職種の中央時給を掛け合わせて算出

• 人間の専門家による評価と自動評価 (Human Expert Grading and Automated Grading)
• 人間による評価 (Human Expert Grading):
• ブラインド・ペアワイズ比較: GDPvalの主要な評価方法は、専門家によるブラインド（誰が作ったか分からない状態）でのペアワイズ（一対一の）比較
• 評価プロセス: 評価者はまずタスクのリクエストと参照ファイルを受け取る。その後、ラベルが伏せられた2つ以上の成果物（例：人間の専門家が作ったもの vs. AIが作ったもの）を提示され、どちらが優れているかを客観的および主観的な基準で判断し、順位付け
• 時間と労力: この評価作業は非常に手間がかかり、ゴールドサブセットのタスク1件を比較評価するのに、専門家は平均で1時間以上を費やす。評価者は、なぜその順位にしたのか、詳細な根拠も記述
• 自動評価 (Automated Grading):
• 開発目的: 人間による評価は高コストで時間もかかるため、より迅速かつ安価な代替手段として、実験的な自動評価モデルを開発
• 性能: この自動評価モデルは、人間の専門家が行うのと同様のスタイルでペアワイズ比較を行うように訓練。人間の評価者との一致率が65.7%。人間同士の評価者間の一致率（70.8%）と比較してもわずか5%の差であり、高い精度を持っていることを示唆
• 役割: あくまで専門家による評価を補完する「代理（proxy）」であり、完全に代替するものではないと位置づけ

• 実験と評価
• モデル比較



• 速度とコストの比較 (Speed and Cost Comparison):
• AIを専門家の業務フローに組み込むシナリオ（例：「まずAIにやらせてみて、満足できなければ自分で修正する」）を分析
• その結果、AIの支援と人間の専門家による監督を組み合わせることで、業務の速度とコストを改善できる可能性があることが示唆

• 限界 (Limitations)
• データセットサイズ: カバーしている職種は44で限定的
• タスクの焦点: PC上で完結する知識労働に焦点が当てられており、手作業、物理的なタスク、暗黙知や対人コミュニケーションが重要な業務は含まれていない
• タスクの形式: 現実の業務と異なり、必要な情報がすべて最初に与えられる「ワンショット」形式であり、対話的に要件を明確にしていくプロセスは含まれていない
• 評価コスト: 専門家による評価は高品質だが非常に高コスト。自動評価はそれを補うものだがまだ限界あり

• ACL 2025に採択
ACL AnthologySampling-based Pseudo-Likelihood for Membership Inference Attacks

背景

• LLMの学習データは秘匿されがち
• 多くのLLMで学習に利用されたデータは公開されない

• メンバーシップ推論攻撃(Membership Inference Attacks; MIA)
• 一般にメンバーシップ推論攻撃は、AIモデルの学習データとしてあるデータが利用されたか否かを判定するタスク
• LLMにおいては、メンバーシップ推論攻撃により権利的に保護された著作物がLLMの学習に利用されたか否かを知ることができる
• 既存のMIA手法はLLMの尤度を利用できることを前提しているが、尤度が必ずしも手に入るとは限らない
• 尤度が高い生成ができているなら学習データにあったと考えられる

本研究が取り組む課題

• LLMの学習データセットに対象テキストxが含まれるか否かのbinary classificationを行うこと
• ただし、既存手法の設定とは異なりLLMの尤度等は利用できず出力テキストのみを利用可能とする

提案手法 SaMIA(Sampling-based MIA)

基本的なアイデア

詳細

1. 検出対象テキストxをx = concat(x_prefix,x_ref)のように分割

2. LLMにx_prefixを複数回入力し、出力x_cand_1, …, x_cand_mをサンプリング

3. 出力とx_refの類似度(ROUGE)の平均を学習データに存在したっぽさとして利用

実験設定

データセット

• 既存研究に倣ってWikiMIAを利用

• MIAの性能はテキスト長さに依存するので異なる単語数(32,64,128,256)で検出性能を評価
• テキスト長が長い方が性能はいい傾向にある
• 判断材料増えると考えればこの傾向は自然だと思う

• 2023年以降のデータを未学習、2017年以前のデータを学習済とみなす
• 未学習か学習済かをデータのカットオフに応じて設定

対象LLM

• GPTJ-6B, OPT-6.7B，Pythia-6.9B，LLaMA2-7B
• いずれもカットオフ日は2022年以前
 

比較手法

結果

• AUC-ROCによる評価
• 尤度にアクセスできないという制限を課してなお既存法とcompetitiveな性能

• サンプリング回数とSaMIAの性能
• 4,5回程度のサンプリングで十分そうに見える

• 単語数ごとのスコア分布

結論

• 尤度を提供しないようなLLMでもテキストが学習データに入っているかを判断すること(=メンバーシップ推論攻撃)は尤度を提供するLLMと同程度以上にできる