Question 1

なぜWindowsでtrain_agent.pyを実行すると、すべてのツール呼び出しが「tool not found」エラーを返すのですか？

Accepted Answer

根本原因: `signal.SIGALRM` と `signal.alarm()` は POSIX 専用であり、Windows には存在しません。`trainer/train_agent.py` では、`execute_tool()` が裸の `except:` ブロック内で `signal.signal(signal.SIGALRM, ...)` を呼び出しているため、結果として発生した `AttributeError` が静かに握りつぶされ、関数は `None` を返します。そして `rollout_single` がその `None` を、すべてのツール呼び出しに対して `{"error": "tool not found"}` に変換します — クラッシュも警告もありません。これは Agentic RL トレーニングも静かに破壊します。フォーマット報酬は引き続きスコアされますが、モデルが実際のツール結果を一切見ることがないため、メインの ground-truth 報酬(重み 2.5)は到達不能になります。

修正(PR #847): `trainer/trainer_utils.py` にある AST ベースの `safe_math_eval()` を含むバージョンに更新してください。これは、モデルが生成した文字列に対する生の `eval()` を置き換え、シグナルベースのタイムアウトを完全に除去します(AST 評価器は無限ループに入ることができないため、`signal.alarm` は不要です — プラットフォームガードなしでクロスプラットフォームの問題が解消します)。同じ修正が 3 つすべての `eval()` 呼び出し箇所(`trainer/train_agent.py`、`scripts/eval_toolcall.py`、`scripts/web_demo.py`)に適用されています。

古いコミットから動けない場合は、この最小限のクロスプラットフォームパッチを適用してください:

```python
_HAS_ALARM = hasattr(signal, "SIGALRM")

def execute_tool(name, args):
    fn = MOCK_RESULTS.get(name)
    if not fn: return None
    try:
        if _HAS_ALARM:
            signal.signal(signal.SIGALRM, lambda *_: (_ for _ in ()).throw(TimeoutError()))
            signal.alarm(1)
        return fn(args)
    except Exception as e:
        print(f"[tool] {name} failed: {type(e).__name__}: {e}")
        return None
    finally:
        if _HAS_ALARM: signal.alarm(0)
```

重要なルール: 裸の `except:` は絶対に使用しないでください(これが AttributeError を隠蔽し、失敗をサイレントにしました)。また、クロスプラットフォームコードでは `signal.SIGALRM`/`signal.alarm` を必ず `hasattr(signal, 'SIGALRM')` でガードしてください。

Question 2

24GB GPU（RTX 4090）で train_agent.py または train_grpo.py を実行する際の CUDA Out of Memory (OOM) エラーの修正方法は？

Accepted Answer

実効的な学習バッチは `batch_size × num_generations` です(Agent RL: 2×4=8、GRPO: 2×6=12)。学習時には Policy モデル、Reference モデル、および 1.8B の Reward Model が同時に読み込まれるため、24GB の VRAM では不足する可能性があります。対処方法:

1. `train_agent.py` の場合、バッチサイズと総シーケンス長を小さくします:
```
python train_agent.py --batch_size 1 --max_total_len 1536
```

2. `train_grpo.py` の場合(`max_total_len` オプションはありません)、バッチサイズ、生成数、シーケンス長を小さくします:
```
python train_grpo.py --batch_size 1 --num_generations 4 --max_seq_len 512 --max_gen_len 768
```

3. PyTorch が大きな 'reserved but unallocated memory' を報告する場合は、以下を設定してフラグメンテーションを軽減します:
```
export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True
```

Question 3

MiniMindでYaRN rope_scalingを使用する場合、なぜoriginal_max_position_embeddings（2048）が事前学習のmax_seq_len（340）と異なるのですか？

Accepted Answer

`original_max_position_embeddings` は、YaRN を有効にする前にチェックポイントが実際に学習されたコンテキスト長を参照する必要があります — `train_pretrain.py` の値ではありません。MiniMind のパイプラインは次のとおりです。(1) 元の RoPE を使用し、max_seq_len=340 で事前学習を実施 (YaRN は無効)。(2) 元の RoPE を使用し、max_seq_len=2048 で Full SFT を実施 (YaRN は無効 — 公開されている `full_sft` の重みは、簡易 mini-dataset 再現スクリプトで使用される 768 ではなく、2048 トークンで学習されたものです)。(3) YaRN を有効にして推論を行い、2048 のウィンドウから外挿 (例: `python eval_llm.py --weight full_sft --inference_rope_scaling`)。したがって、`original_max_position_embeddings=2048` は Full SFT チェックポイントと一致します。RoPE 自体は学習可能なパラメータを持たない決定論的な位置回転であり、学習が必要なのはモデルの重みの位置範囲への適応であり、これは 2048 トークンの Full SFT ステージで既に行われています。Full SFT をスキップし、長さ 340 で学習された事前学習のみのチェックポイントに YaRN を直接適用する場合にのみ、`original_max_position_embeddings=340` を設定すべきです。

minimind

概要

README プレビュー

FAQ (3)

同类型项目

freeCodeCamp

generative-ai-for-beginners

cs-self-learning

ai-agents-for-beginners