Core Dynamics 再確認ノート(Activation飽和・Refractory) — 2026-10-02

状態: 記録のみ。事前登録の研究ではない。エンジン(chain_spike_phase0.py、sha256 66b3e7fe…)は無変更。リポジトリの状態(COMPLETE / DORMANT)は変えない。

0. なぜ書いたか

迷路の実験(../../meiz/main.py、activation_cap=5.0、refractory_steps=1)をきっかけに、「CSE 技術仕様書 v0.6 ― Core Dynamics Revalidation」という案が出た。中心の仮説は次のとおり。

CSEの過去の言語予測性能の低下の一部は、アーキテクチャそのものではなく、Activation SaturationとRefractory Candidate Suppressionによって生じていた可能性がある。

再検証のプロトコルを書く前に、コード・ログ・設定の成果物と照合した。その結果、この仮説は、LMの判定に使った系列には当てはまらないことが分かったので、プロトコルは作らず、照合の結果だけをここに残す。同じ「再発見」を繰り返さないためである。

注意: 仕様書の「v0.6」「v0.7」という名前は、既に ../Chain-Spike Engine 技術仕様書 v0.6.docx / v0.7.docx(2026-08-27)で使われている。

1. コードから確認したこと(`chain_spike_phase0.py`)

Refractoryは _candidate_scores の中だけにある(1211〜1228行目)。直近 refractory_steps 個の発火ノードのscoreを0にする。内部の発火を抑える経路(案の「Internal Refractory」)は存在しない。
例外として、学習済みの自己エッジがあれば、同じ記号の連続は max_consecutive_repeats(既定2)まで許される。したがって、既定の refractory_steps=2 で止まるのは次の場合である。
ABA(距離2の再出現): まだまだ、いよいよ、banana、level、英文の " a "、"t t"、"ere"
AAA+(3回目以降の連続)
AA(tree、coffee、ここ)は止まらない。案の「treeのe→eが止まる」は誤り。
_candidate_scores を呼ぶのは採点と生成の経路だけ(1376・1496・1571・1598行目)で、学習(train_text)は呼ばない。Refractoryは学習を変えない。
teacher-forcedの採点(_score_text_streaming)も _candidate_scores を通る。Refractoryが有効なら、ABAの正解記号は確率0(またはbackoff分だけ)になる。
activation_cap=0.0 は、040以降は自動の安全上限(source-026の構成で 3.398744768887789e35)を意味する。

2. 既に記録されていたこと

時期	記録	内容
2026-08-26	`../DEVELOPMENT_LOG.md`(102行目付近)	デモの`かわい。`は、Refractoryが正当な`いい`を禁止していたため → 学習済みの自己エッジに限って2連続まで許す例外を追加(AAの問題の修正)
2026-08-27	`../DEVELOPMENT_LOG.md` Natural Text 001(637〜655行目)	Top-K=8+Refractoryで正解の6.8%が候補から除外された。「Top-K / Refractoryは生成安定化には有用でも、正解候補をHard Zeroにするため尤度評価には不向き」→ 確率評価ではRefractory OFF・Top-Kを全Active Nodeに。同じとき、長い系列のoverflow対策として `activation_cap` を追加
Q57c〜h	`README.md`	活性は約31〜35トークンで自動上限へ飽和し、候補が均等化する。cap ≤ 1e16で鋭さを維持。low-cap(+pair)を以後の基準構成に。Refractoryの警報集合は直近r個と8/8一致
033〜040	`../NUMERICAL_`, `../CORE_AUTOMATIC_SAFE_ACTIVATION_`	上限なしのcapで内部に非有限値が出て、NaNが候補から黙って除外されていた → 自動の安全上限をCoreへ採用
038	`../ALICE_SAFE_BOUND_EXTERNAL_CONFIRMATION_RESULT_038.md`	Aliceで、cap100と自動上限のBPCが1e-12以内で一致
H-GEN-2	`H_GEN_2_PROTOCOL.md` §16〜17	生成・想起の課題で、`history_boost=0`(`hist_off`)は最初の逸脱を遅らせた(PASS、160/0/0)。課題は同じ記号を距離3以上に置く設計なので、Refractoryは関係しない

3. LMの判定に使った構成

自然文のLM系列は ../experiments/external_continuous_text_001.py の engine_config を基準にしており、refractory_steps=0、history_boost=0.0 である。生成の実験(047など)も同じ engine_config を使う。
現在のLMの判定の根拠であるStudy 107の構成(../artifacts/runtime_blind_comparison_107.inputs.json の config、081の configured_engine から作られる)は、refractory_steps=0、history_boost=0.0、activation_cap=0.0(自動の安全上限)、distribution_backoff_mix=0.05、pair_context_capacity=2048、top_k_edges=50、max_nodes=100。
history_boost=0 なので、活性はscoreに入らない。capはNaNの経路にしか効かず、038でcap100と自動上限のBPCが一致したことと整合する。
結論: LMの判定(Study 107、自然文の系列)は、Activation飽和もRefractoryも効かない構成で出ている。v0.6案の中心仮説は、この系列には当てはまらない。
100問のQ61〜68(一般LMはNOT FOUNDの根拠の一部)は、イベント列・異常センサーとしての課題であり、LMの品質評価ではない。Q68の非局所制約の失敗は、局所情報をauditで統制した上での結果である。

4. 迷路の予備試行(探索的、事前登録なし、N=5)

scripts/core_dynamics_maze_pilot.py(迷路・歩数の上限500・壁に当たったときのpenalty +0.1は meiz/main.py と同じ規則。学習用の歩行と行動の乱数はseedで固定)。各条件5回、学習用のランダム歩行は条件の間で共通。

条件	中央値(歩)	平均	500で打ち切り
ランダム歩行(penaltyなし)	181	247.2	1/5
cap5, r0	65	137.8	0/5
cap5, r1	63	136.2	0/5
cap5, r2	192	274.8	2/5
自動cap, r0	500	412.8	4/5
自動cap, r1	84	239.0	2/5
自動cap, r2	500	412.8	4/5

N=5で分散が大きい。順位の主張はしない。ユーザーの手元の記録(meiz/result.csv、cap5・r1の17回、温度1.0と0.8が混在、中央値139歩、500で打ち切り1回)も対照がない。
仕組みはコードから決まる: prime の後、直近の発火は常に現在のState(確認: ('ArB', ['r','B']))。r=1が消すのはそのStateだけで、Stateは行動の候補から除かれているので、行動の選択にはほぼ影響しない(Top-Kの枠を1つ空ける可能性はある)。r=2では直前の行動が消え、同じ方向に続けて進めなくなる。
したがって、案のH17「Refractoryの最適強度はToken/Node表現の時間間隔に依存する」は、検証する仮説というより、Refractoryの定義から導ける事実である。
自動cap(既定の history_boost=0.35)でr0とr1の差が出たように見えるのは、Q57の飽和でStateがTop-Kの枠を占めるためかもしれない。未検証。

5. まだ検証されていないこと(UNTESTED、研究の候補ではなく記録)

既定の構成(r=2)での自然文の生成では、ABAを生成できない。テキストだけの数え上げ(CSE不使用、ファイル全体): ABAの位置はAlice(../data/external/alice_pg11/pg11.txt)で2.3%、Tiny Shakespeareで2.1%(多いのは " a "、"t t"、"ere"、" I "、"eve")。AAA+はAliceで0.4%。
ただし、LMの研究の系列はr=0で回しているので、これは既定値を使ったデモ・generateの性質であり、研究の判定は変わらない。
「内部のRefractory」は存在しない機構なので、試すなら、何を抑えるか(活性の更新・伝播・強制減衰・入力の受け付け)を式で決め、v1本体は変えずにwrapperで実装し、別に事前登録する必要がある。

6. 結論

v0.6案の2つの機構は、どちらも2026-08-26〜27の時点で見つかり、LMの評価系列では無効化されていた。Activation飽和はQ57・033〜040で機構と対策まで確認済み。
「死亡判定の根拠が本当にアーキテクチャの限界だったか」という問いに対して、この2つの機構は答えにならない。LMの判定は、両方が効かない構成で出ている。
ARCHIVE_STATUSの再開条件1(既存の結果から独立した新しい理由)は、このノートの内容では満たされない。