8
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kuririrn

「松尾研LLM講座2025応用編」アドバンスドコンペの感想をまとめてみた

8
Last updated at Posted at 2026-03-09

はじめに

　受講生が総勢約4500人と噂される東大松尾・岩澤研究室主催のLLM講座応用編2025のアドバンスドコンペに参加しました。コンペはメインコンペ（予選）とアドバンスドコンペ（決勝）の2トラック制で、メインコンペのスコア上位者がアドバンスドに進めるという仕組みです。メインコンペの感想はこちらに記載しています。アドバンスドコンペでは、メインコンペの上位者200人が競い合う場になっています。
　実質的なコンペ期間が2週間程度（モデルのホワイトリストやサンプルコードが提供されてから〆切までの期間）とタイトな上に、課題の難易度が高く、リソース的にも心身の疲労的にも、とてもハードなコンペでした。仕事、育児、その他諸々のやるべきことがある中、なんとか時間を捻出して死にかけながらコンペに挑んだので、終わった時に軽い燃えつき症候群になりました。笑
　とはいえ、このコンペで得た経験はとても貴重なものでした。この記事では、コンペに参加した感想、工夫点の概要、学びについてまとめています。

コンペ概要

　本コンペではAgentBenchというベンチマークが用いられました。AgentBenchのうちDBBenchとALFWorldという2つのタスクの総合点を評価指標に、Qwen系の小規模なベースモデルに独自の追加学習を行い、精度を競い合うという内容でした。

AgentBenchとは

  • LLMのエージェントとしての能力を評価するためのベンチマーク
  • 複数の性質が異なるタスク環境でエージェントの行動能力を評価
    （DB操作、Web操作、屋内行動等）
  • 本コンペでは以下の2タスクが対象
    • DBBench: テーブル情報と要求を受け取り、適切なクエリを組み立ててDBを操作するタスク
    • ALFWorld: 環境描写+タスク目標を受け取り、目標を達成する行動を出力するタスク

　このベンチマークはエージェント型AIへの応用を強く意識したものと想定されます。従来の生成AIの役割が「文章や画像を生成して回答すること」であったのに対して、エージェント型AIは「人間からの指示に基づいて自律的に目標を達成すること」である点が、大きく異なります。
　したがって、それぞれのLLMに求められる能力も当然異なります。前者は質問に対して単発の回答をいかに精度良く（あるいはユーザーの意図に沿って）返すかが重要であるのに対して、後者では複雑な目標を達成するために、環境への行動・応答というインタラクションを繰り返しながら、「最終目標に到達する行動」を導き出せるかが重要になります。
　そのため、DBBench, ALFWorldいずれも、1ターンの回答で目標に到達できる類のものではありません。必然的に、事後学習で必要となるデータセットも複数ターンの回答（行動）、環境情報（行動の結果、生じた環境の変化）がセットになったものとなります。

　計算機環境差異による公平性の確保やライセンス既定等の都合から、主なコンペルールとして以下の項目が設定されました。

  • 学習指定モデル（Qwen2.5-7B-Instruct, Qwen3-4B-Instruct-2507）を学習したモデルであること
  • 別途、ホワイトリストで指定されるモデルを使用したデータ合成や蒸留はOK
  • AgentBench, ALFWorldのデータを用いることは一切禁止
  • データセット合成は基本的に自由だが、AgentBench, ALFWorldに過度に適合したものはNG
  • 人手やプログラムによるデータ合成はOKだが、クローズドなLLMを用いることは一切禁止
  • Testデータの推論は事務局提供のAgentBench実行環境で行われるため、推論時のチューニングは不可
  • リーダーボードを利用したチューニングの禁止
  • 採点基準の詳細は非公開

コンペで配布されたもの

　事務局から以下が配布されました。一定の制約はあるものの、メインコンペと違い自由度があるので、標準コードはあくまで最小限のベースラインという位置づけでした。

  • データセットのホワイトリスト　※ライセンス的に問題無ければ、これ以外を使ってもOK
  • モデルのホワイトリスト
  • SFT用の標準コード

評価環境

　事務局からは以下2つの環境が提供されました。後述しますが、SFT時のValidation時のスコア傾向とリーダーボードのスコア傾向に全くと言えるほど相関が無く、実質的には推論を回してみないと対策の効果がわからないというのが難しさの一つでした。

  1. AgentBench推論環境
    用途: 参加者が作成した（Hugging Faceにアップロードした）モデルの推論動作確認と、推論傾向の把握
  2. リーダーボード
    用途: Hugging FaceのモデルURLを提出することで上記同様の環境での推論が実行され、Publicな暫定スコア確認が可能

評価指標

　スコアの算出式は明かされていませんが、ALFWorldとDBBenchの総合スコアで評価されます。以下、各タスクのスコアの一例です。ALFWorldのsuccess_rate, DBBenchのoverall_cat_accuracyが各タスクの正解率を表しています。スコア推移の傾向から、ALFWorldの方が総合スコアへの寄与が大きいようでした。

ALFWorld

{
   "total": 50,
   "validation": {
       "running": 0.0,
       "completed": 0.42,
       "agent context limit": 0.0,
       "agent validation failed": 0.0,
       "agent invalid action": 0.22,
       "task limit reached": 0.36,
       "unknown": 0.0,
       "task error": 0.0,
       "average_history_length": 60.0,
       "max_history_length": 91,
       "min_history_length": 21
   },
   "custom": {
       "overall": {
           "total": 50,
           "pass": 21,
           "wrong": 29,
           "success_rate": 0.42
       }
   }
}

DBBench

{
   "total": 150,
   "validation": {
       "running": 0.0,
       "completed": 0.9333333333333333,
       "agent context limit": 0.0,
       "agent validation failed": 0.0,
       "agent invalid action": 0.0,
       "task limit reached": 0.06666666666666667,
       "unknown": 0.0,
       "task error": 0.0,
       "average_history_length": 10.133333333333333,
       "max_history_length": 34,
       "min_history_length": 6
   },
   "custom": {
       "other_accuracy": 0.7142857142857143,
       "counting_accuracy": 0.2727272727272727,
       "comparison_accuracy": 0.4444444444444444,
       "ranking_accuracy": 0.4,
       "aggregation-SUM_accuracy": 0.3333333333333333,
       "aggregation-MIN_accuracy": 0.4,
       "aggregation-MAX_accuracy": 0.16666666666666666,
       "aggregation-AVG_accuracy": 0.8571428571428571,
       "SELECT_accuracy": 0.4426229508196721,
       "INSERT_accuracy": 0.3333333333333333,
       "UPDATE_accuracy": 0.8,
       "overall_cat_accuracy": 0.5253187613843352
   }
}

奮闘の軌跡

　ここから、どのようにスコアアップにつながったか（つながらなかったかも含めて）紹介します。

SFTベースライン（標準コード, Qwen3-4B-Instruct-2507）のスコア確認

　手始めにベースラインの性能を確認したところ下記の結果でした。DBBenchに比べ、ALFWorldのスコアが低いので、まずはALFWorldの改善からトライしようという方針を立てました。

DBBench ALFWORLD Test Score
0.53 0.42 3.6383

SFT時の行動制約のIn-Context Learning

　SFTベースラインのALFWorldの失敗パターンの内訳は、環境的に実行不可能な行動選択（agent_invalid_action）が22%, 上限ステップ数到達による打ち切り（task_limit_reached）が36%でした。ALFWorldでは、初回のSystem PromptとUser Promptを除くと、以下のように"User Promptによる観測情報・行動選択肢の提示 ⇒ Agentの行動(LLMの回答)"の対が一つのroundを構成し、複数round繰り返されていくという構造です。

ALFWorld Interaction Example

[round 1] done=False
ACTION:
  go to fridge 1

OBS:
  You arrive at fridge 1. The fridge 1 is closed.

ADMISSIBLE COMMANDS:
  - go to fridge 1
  - go to garbagecan 1
  - go to microwave 1
  - go to shelf 1
  - go to shelf 2
  …
--------------------------------------------------------------------------------
[round 2] done=False
ACTION:
  open fridge 1

OBS:
  You open the fridge 1. The fridge 1 is open. In it, you see a bread 1, a mug 3,
  a pan 1, and a plate 3.

ADMISSIBLE COMMANDS:
  - examine fridge 1
  - go to cabinet 1
  - go to coffeemachine 1
  - go to countertop 1
  - go to drawer 1
  - go to toaster 1
  - open fridge 1
  …

失敗パターンの事例としては下記の通りでした。

agent_invalid action

  • 同じ行動を繰り返す
    ※推論時に一定回数以上同じ行動を繰り返すと不正とみなされるロジックが実装されている（と予想）
  • 行動選択肢に無い行動を取ろうとする（行けない場所に行こうとする、無い物を使ったり触ろうとするetc）
  • 突然、"task succeeded"と出力することがある

task limit reached

  • 指定された最大ターン数までに目標を達成できない
    ※ALFWORLDでは通常 step limit があるらしい

　まずはagent_invalid_actionにフォーカスすると、SFTでは「状態依存制約を学習出来ていない」ことが要因と想定されました。SFTでは、環境情報とそれに対応する行動の対を学習することで、「よくある行動パターン」を覚えることは出来ますが、状態依存の制約は陽に学習出来ないためです。
この問題への対策として、まずはシンプルにSFT時のUser Promptに「必ず選択可能な行動（Admissible Commands）から選択する旨」のプロンプトを追加しました。これによって下記の通り、わずかにスコア改善しました。

Overall Score

DBBench ALFWorld Test Score
Before 0.53 0.42 3.6383
After 不明 (非実施) 0.46 3.7266

ALFWorldスコア詳細

agent_invalid_action task_limit_reached
Before 22% 36%
After 20% 34%

ReACTタグの正規化

SFTデータと推論時のデータで、ReACTタグに違いがありました。

SFTデータ Think: / Act: tags
推論データ THOUGHT: / ACTION: tags

小さな言い回しの差異ではあるものの、明確なドメインシフトの問題と思ったので、SFT時のタグを正規化することにしました。

Think: → THOUGHT:
Act: → ACTION:

汎化性能が高いLLMを作るというコンペ本来の主旨を踏まえると、タグの揺れに対応できるよう色々なバリエーションで学習するという対策も考えられましたが、コンペ期間が限られる中、いたずらにサンプルを増やしたくなかったので、このような対策に帰着しました。
　この結果、以下の通りスコア改善しました。（ALFWorldスコア詳細はうっかり取り忘れてました）

Overall Score

DBBench ALFWorld Test Score
Before 不明 (非実施) 0.46 3.7266
After 0.51 0.48 3.8445

ALFWorld合成データの作成

　ここまでは1つのデータセットを使っていたのですが、汎化性能を高めるために複数のデータソースから合成データを作ることにしました。ここで一つ工夫したのは、「選択可能な行動（Admissible Commands）」が含まれる軌跡（Trajectory, 目標に対する一連の行動と観測）に限定したことです。これは、先述の「行動選択肢に無い行動を取ろうとする」ことによるagent_invalid_action抑制のためです。
これによって、DBBenchのスコアは若干悪化したものの、ALFWorldのスコアが大幅に改善しました。スコア改善の主要因はagent_invalid_actionが0.06と激減したことで、狙い通りの効果が得られました。ここまでは順調にスコアが伸びてました。

Overall Score

DBBench ALFWorld Test Score
Before 0.51 0.48 3.8445
After 0.5 0.6 4.2479

ALFWorld+DBBench合成データの作成

　ここからスコアが伸びず、何を信じれば良いかわからない混迷期に入ります（笑）。ALFWorldのスコアはそこそこ良い感じになってきたので、DBBenchもSFT対象に組み込むことを検討しました。注意が必要なのは、ALFWorldとDBBenchはタスクの性質が正反対と言っても過言では無いほど、性質が異なることです。

観測：
ALFWorld：自然言語での環境記述＋行動履歴
DBBench：テーブルスキーマ、エラー、SQLなど

出力：
ALFWorld：Open fridge, examine drawer のような短いaction
DBBench：長めのSQL、自然言語でのreasoning＋SQL

　この性質差異を考慮して、単純に両タスクのデータを合成するのではなく、DBBenchは弱点のサンプル（間違いが多いINSERT等）に限定する、DBBenchに過度に寄り過ぎないようサンプルのバランスに気を付ける（ALF多めにする）という工夫をしましたが、両タスクのサンプルが激下がりするという問題に頭を悩ませました。
　コンペ参加者の間でもこの問題が議論を呼び起こしてました。あるコンペ参加者の方が「DBの出力スタイル（説明が長め/形式が違う）が少し入るだけでも、ALFで欲しい「短く合法ACTIONを出す」癖が薄れて、invalid_action や task_limit が増える」という仮説を立ててましたが、その通りかと思いました。
　MoEが使えればこの課題は解決できそうですが、今回のコンペでは禁止されているので、DBBenchのデータ合成は見切りをつけることにしました。

SFTモデルのハイパラチューニング

　これまでの学習ログからある程度ハイパラ候補のあたりはつけられそうだったので、主要なハイパラであるEpoch, Learning Rate, Warmup ratio, Weight Decayを調整し、複数パターン試してみました。ここで頭を悩ませたのが、Validationの傾向が全くあてにならなかったこと。SFTのValidationの傾向からは最良と思われるモデルでも、Testスコアがむしろ下がるという事象が頻発したので、ハイパラチューニングの方向性が掴めませんでした。
　SFT時のValidationでは性能が良いのにTestでは性能が全然出ないということは、過学習云々ではなく、SFT時とTest時のデータの分布が大きく異なるドメインシフトが本質的な要因なのかと予想しています。仕方なく、デフォルトのハイパラのままに落ち着きました。
　今回のコンペだけでなく、LLMではドメインシフトが常態的に起こりえるにもかかわらず、昨今のクローズドなモデルではうまく汎化出来ているということは、何か取りうる対策があるのか気になるところですが、答えは出ませんでした。

モデル変更

　先述の通り、今回のコンペで使用可能なモデルはQwen2.5-7B-Instruct, Qwen3-4B-Instruct-2507の2つでした。これまでQwen3-4B-Instruct-2507を使い続けていましたが、パラメータ数が多いQwen2.5-7B-Instructに切り替えてみました。デフォルトのハイパラ設定ではスコアが伸びなかったので、色々とハイパラチューニングしてみましたが、結局どれもQwen2.5-7B-Instructのスコアを超えられず。残り期間わずかだったこともあり、モデルはQwen2.5-7B-Instructのままでいくという結論にいたりました。

失敗パターンの分析

　ここで改めてALFWorldの行動ログから、どういう状況で、どんなパターンの間違いをし、それがなぜ発生するのかを分析することにしました。すると面白い傾向が見えてきました。失敗パターンは大きく4つに分類できました。

1. ループ型

例) use desklampの連打

use desklamp 1
use desklamp 1
use desklamp 1

想定される理由

　行動履歴を内部に持っておらず、過去に行った行動を繰り返しても得られるリターンが無いことを学習出来ていない。なぜならば、現状のSFTは「今の」環境観測と望ましい行動の対を学習しているだけ。

2. 無関係探索型

例）spatula(ヘラ)を探すという目標に対して、明らかに関係なさそうな場所を手当たり次第に探す

go to sink
examine sink
go to fridge
examine fridge
go to shelf
examine shelf

想定される理由

　本来は「spatula → 調理器具 → countertopかdrawerにありそう」といった具合に、道具がありそうな場所の尤からしさを考慮した推論が必要だが、そのような概念を獲得できていない。

3. 部分成功誤認型

例）突然、"task succeeded. "を出力することがある

Goal
 Your task is to: put a cool tomato in microwave.

Action
 take egg 1 from microwave 1
 close microwave 1
 task succeeded.

想定される理由

目標（Goal）に含まれる部分的なキーワード（上記の例ではmicrowave）で、タスクが完結したとHallucinationしてしまう。

4. 多段階計画失敗型

例）2つのものを動かす等、複雑なタスクで迷走することがある

目標
put two peppershaker in drawer

望ましい軌跡

1. peppershaker Aを取る
2. drawerへ移動
3. peppershaker Aを置く
4. peppershaker Bを取る
5. drawerへ移動
6. peppershaker Bを置く

実態

peppershaker Aを取る
→ cabinetに戻す
→ 別の物動かす
→ 迷走

想定される理由

タスク目標をサブゴールに分解し、サブタスク単位で段階的に計画を立てることが出来ない

DPO用データセットの作成方法

　これらの失敗パターンを矯正するため、ALFWorldの成功系trajectoryをもとに、各ラウンドの観測を1つの意思決定点とみなし、その時点での正解行動を chosen、望ましくない行動を rejected とする roundwise な DPO データを生成しました。
　具体的には、各trajectoryについて「あるuser観測に対してagent(LLM)が選んだ行動」を chosen とし、同じ文脈に対して失敗パターンに対応する rejected 行動を自動生成しました。なお、データ生成には成功した trajectory を用い、明確に失敗しているログは除外しています。

1. ループ型（loop_prev_action）

　ループ型については、直前のラウンドで実行した行動をそのまま繰り返すケースを rejected として生成しました。

例えば

use desklamp 1
use desklamp 1
use desklamp 1

のような行動の連打です。

　データ生成では、直前の行動が clean、use、examine などの場合に、同じ行動をもう一度行う候補を rejected として作成し、agent(LLM)が実際に選択した行動を chosen としています。
　これによりモデルは、同じ行動を繰り返すことは望ましくないという行動バイアスを学習することが期待できます。

2. 無関係探索型（implausible_location）

　無関係探索型については、成功した trajectory から「物体と配置場所の共起関係」を集計し、ある物体がどの場所に存在しやすいかという統計を作成しました。

例えば

spatula → drawer
spatula → countertop
mug → cabinet

のような関係です。

　この統計を利用し、ある物体を探すタスクに対して、明らかに尤もらしくない場所への探索行動を rejected として生成しました。一方で、そのラウンドでagent(LLM)が実際に選択した行動を chosen としています。
　これによりモデルは、探索対象に応じて「どこを優先的に探すべきか」という常識的な探索方針を学習します。

3. 部分成功誤認型（task_succeeded_negative）

　部分成功誤認型については、タスクがまだ完了していない段階で task succeeded を出力してしまう挙動を抑制するためのデータを生成しました。

例

task succeeded.

　本データでは、通常の行動ラウンドにおいて

  • chosen : agent(LLM)が選択した行動
  • rejected : task succeeded

という DPO ペアを作成しています。

　これによりモデルは、タスクの途中段階では"task succeeded"を出力すべきではないという行動制約を学習します。

　以上1～3の工夫によって、スコアが以下のように改善しました。

Overall Score

DBBench ALFWorld Test Score
Before 0.5 0.6 4.2479
After 0.52 0.66 0.45207

ALFWorldスコア詳細

agent_invalid_action task_limit_reached
Before 6% 34%
After 6% 28%

　不思議だったのはDBBenchのスコアまで改善したことで、なぜそうなったかの解析までは時間不足で出来ていません。
　余談ですが、DPOのEPOCHは0.5にしたのですが、これを1にするとスコアがかなり落ちました。これは、roundwiseのDPOが効きすぎると、chosenに近くrejectedからは遠い固定的な行動が選択されやすくなり、SFT時の探索的な行動が抑制されてしまうため、と予想しています。

最終順位

　コンペ〆切時点でのリーダーボード上の順位(Public)は46位でした。最終スコアは別データ(Private)で評価されるらしく、結果待ちの状態です。
　もうちょっと上位に食い込みたかった歯がゆさは残りますが、この経験を糧に精進していこうと思います。

リポジトリ

今回のコンペで作成したモデル、データセットをHuggingFaceで公開してます。

モデル
https://huggingface.co/kuririrn/qwen3-4b-agent-trajectory-lora-sft_dpo_v3-a

SFTデータセット
https://huggingface.co/datasets/kuririrn/sft_alfworld_trajectory_dataset_v3to5_admissible

DPOデータセット
https://huggingface.co/datasets/kuririrn/alfworld_roundwise_dpo_v3

まとめ

　本記事では、「松尾研LLM講座2025 応用編」アドバンスドコンペにおいて、スコアアップにつながったもの、つながらなかったものを含めて、奮闘の軌跡をふり返りました。ふり返ってみると、座学では得られない実践的な学びがかず多く得られたコンペでした。このコンペを通じての学びをまとめます。

学び

  • ドメインシフト対策
    LLM開発において、学習データの分布と推論データの分布が異なるドメインシフトの問題は常態的に発生しうるものと思います。今回はその対策として、プロンプトやデータに制約をかけてalignemnetを計るという対策が有効でした。今回のコンペはタスクが限定的なSLM開発のお題でしたが、より汎用用途のLLMではドメインシフト対策をどのように講じているのか、今後のテーマとして深めていきたいと思いました。
  • LLM開発の泥臭さ（チューニングの難しさ）
    　ValidationスコアとTestスコアの相関が見られず、Validationでは良い感じでも推論時は全くうまくいかない状況ばかりで、本当に苦しみました。結局、Validaitonでは良し悪しの判断がつかないから、AgentBench環境の推論結果を何時間も待って判断せざるを得ず。LLM（今回はSLMですが）を育て上げていくのは、相当泥臭いプロセスだと感じました。全くスコア改善が見られない期間、途中で何度も↓の感覚に陥りました。笑
    • 優秀だったベースラインをいたずらにSFTで改悪させてるような自責の念に駆られる
    • 結局、AgentBenchで結果を出してみないとわからないガラガラポン（くじ引き）の感覚がする
  • LLM開発におけるデータ合成の大切さ
    　今回はモデル側の制約もあったので、特にデータ合成の戦略が大事だったなと思います。おそらく、スクラッチのLLMの事前学習にせよ、事前学習済モデルのSFT・DPOにせよ、「データが命」であることはLLM開発における命題だと痛感しました。今回は最後にDPOで望ましくない行動を矯正する戦略を取りましたが、根本的には、先述した4つの問題（ループ型, 無関係探索型, 部分成功誤認型, 多段階計画失敗型）を意識したSFT用のデータセット作りからできると、より本質的な改善が狙えたかと思います。
  • 実データに立脚した仮説検証
    　色々と迷走したとはいえ、闇雲に思いついたことを試すのではなく、実データを分析し、仮説を立てて、対策を講じていくことが大事だと再認識しました。全てがうまくいったわけでは無いですが、スコアアップにつながった対策は全て実データに立脚した明確な仮説に基づくものであり、なぜうまくいったかの因果もある程度説明可能なものでした。LLMはブラックボックスとはいえ、このようにして得た知見は再現性のあるものとして非常に貴重だと思います。
  • LLM開発におけるLLM活用
    　今回のコンペでは、データ解析、コーディング、仮説立案の壁打ち等、幅広くLLM(ChatGPTやGemini等)を活用しました。この短期間でこれだけの試行を試せたのは、優秀なLLMの力が大きかったと思います。とはいえ、LLMに全部丸投げするのではなく、あくまで主体はこちらというスタンスでアシスタントとして活躍してもらいました。最近、LLMになんでも丸投げするスタイルでは、自分の学び・成長・モチベーションを著しく下げることを感じており、丸投げは避けていますが、このような活用の仕方が色んな意味でしっくり来ています。

最後に

　この記事が同じ講座・コンペに参加して奮闘された方、これからLLMの学習や評価に取り組む方の参考になれば幸いです。
　最後にこのコンペを用意してくださった運営の皆様に心から感謝申し上げます。

参考文献・関連リンク

参考文献

AgentBench / ALFWorld

  • AgentBench: Evaluating LLMs as Agents
    Liu, X. et al., 2023.
    LLMを「エージェント」として評価するためのベンチマークを提案した論文。
    本コンペで用いられたAgentBenchの全体像を把握するのに有用。
    https://arxiv.org/abs/2308.03688

  • AgentBench GitHub Repository
    AgentBenchの公式リポジトリ。ベンチマークの構成や各タスクの概要を確認できる。
    https://github.com/THUDM/AgentBench

  • ALFWorld: Aligning Text and Embodied Environments for Interactive Learning
    Shridhar, M. et al., 2020.
    ALFWorldの元論文。テキスト環境と行動環境を対応づけたタスク設定が説明されている。
    https://arxiv.org/abs/2010.03768

  • ALFWorld Official Website
    ALFWorldの公式サイト。タスク概要や関連リソースを確認できる。
    https://alfworld.github.io/

手法関連

  • ReAct: Synergizing Reasoning and Acting in Language Models
    Yao, S. et al., 2023.
    ReasoningとActingを組み合わせるReActの提案論文。
    本記事中で触れたTHOUGHT / ACTION形式の背景を理解するうえで参考になる。
    https://arxiv.org/abs/2210.03629

  • Direct Preference Optimization: Your Language Model is Secretly a Reward Model
    Rafailov, R. et al., 2023.
    DPOの提案論文。chosen / rejected のペアを用いた選好学習の基本的な考え方を理解するための文献。
    https://arxiv.org/abs/2305.18290

使用モデル

関連リンク

コンペ参加記

公開物

8
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
8
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?