fit_two_tier_grm: EM 진행 상황을 관측할 수단이 없어 장시간 적합의 상태를 판별할 수 없음

[seonghobae]

무엇이 관측되었나

s1에서 A4(정서성 G+4+W) Oakes SE 적합이 q_primary=241 q_specific=241 n=340 max_iter=2000으로 돌고 있습니다. 프로세스는 8시간 가까이 단일 코어 100%로 누적 CPU 28,077초를 쓰고 있고, 표준출력에는 시작 줄 하나만 있습니다.

starting fit_two_tier_grm q_primary=241 q_specific=241 n_starts=1 seed=20260914 n=340 rss_abort_gb=80.0

호출 측(analysis/library_emotionality_g4w_oakes.py)은 적합이 끝난 뒤에야 출력합니다. write_bytes는 4096에서 멈춰 있습니다.

왜 문제인가

fast_mlsirm 0.11.4의 fit_two_tier_grm 시그니처에는 verbose도, 반복 callback도, 진행 상황을 내보내는 어떤 인자도 없습니다(docstring 확인: verbose/callback/progress 모두 없음). 그래서 다음 두 상태를 밖에서 구분할 수 없습니다.

• 반복 12회째를 지나는 중이고 느리지만 수렴하고 있다
• 로그우도가 진동하며 max_iter=2000까지 갈 예정이다

max_iter 소진은 converged=False로 돌아오지만, 그 사실은 최대 2000회가 다 끝난 뒤에야 알 수 있습니다. 반복당 비용이 큰 설정에서는 그 시점이 며칠 뒤일 수 있고, 그 동안 호스트 한 대가 묶입니다. 실행을 중단해 확인할 수도 없습니다 — 중단하면 지금까지의 계산이 사라집니다.

요청

fit_two_tier_grm(및 같은 성질을 가진 다른 장시간 적합 함수)이 반복 단위 진행 상황을 내보낼 수단을 갖게 해 주십시오. 형태는 구현자 판단이되, 적어도 반복 번호와 현재 로그우도, 직전 반복 대비 변화량을 알 수 있어야 합니다.

판단 근거를 덧붙입니다. Bock과 Aitkin(1981, Psychometrika, 46(4), 443–459, pp. 445, 448)의 MML EM은 매 반복에서 주변 로그우도를 평가하므로, 그 값은 이미 계산돼 있고 내보내는 데 추가 계산이 들지 않습니다. 수렴 판정에 쓰이는 바로 그 수치입니다.

확인한 환경

• fast-mlsirm 0.11.4 (/data/orca/workspaces/a4-oakes-s1-0114/venv)
• s1, 12코어, 실행 중인 PID 2716563, 시작 2026-09-18 22:20:23 +0900
• 호출 스크립트: analysis/library_emotionality_g4w_oakes.py(late-life-anxiety-reanalysis), MAX_ITER = 2000

돌고 있는 A4 실행은 건드리지 않았습니다.

[seonghobae]

관측 불가가 실제로 얼마를 비용으로 만들고 있는지 재 봤습니다.

돌고 있는 A4 적합(fit_two_tier_grm, q_primary=q_specific=241, n=340, 2 primary + 4 specific, n_starts=1, max_iter=2000)과 같은 설정으로, 같은 호스트의 다른 코어에서 max_iter=3 · tol=1e-300(즉 정확히 3회)로 시간을 쟀습니다.

3회가 2시간 안에 끝나지 않았습니다. 프로세스는 내내 99.8% CPU, RSS 15.79GB로 계산 중이었고(돌고 있는 A4와 같은 RSS), 2시간 시점에 제가 중단했습니다. 즉 설정 비용을 포함해 반복 3회에 7,200초 이상, 반복당 2,400초 이상입니다.

이 값을 돌고 있는 A4에 대면 이렇습니다. 경과 12시간 55분 = 46,500초이므로 지금까지 지난 반복은 많아야 19회입니다. max_iter는 2000입니다. 수렴에 50회가 필요하면 33시간, 100회면 67시간, 한도까지 가면 달 단위입니다.

여기서 이 이슈의 요지가 분명해집니다. 지금 19회 언저리에서 로그우도가 잘 줄고 있는지, 아니면 진동하며 한도로 향하고 있는지에 따라 할 일이 정반대입니다 — 전자면 기다리면 되고, 후자면 지금 멈추고 시작값이나 q를 바꾸는 것이 맞습니다. 그런데 밖에서는 그 둘을 구분할 방법이 없습니다. 확인하려면 중단해야 하고, 중단하면 13시간이 사라집니다. 반복 번호와 로그우도 한 줄이면 없었을 손실입니다.

앞서 적었듯 그 값은 이미 계산돼 있습니다. Bock과 Aitkin(1981, Psychometrika, 46(4), 443–459, pp. 445, 448)의 MML EM은 매 반복에서 주변 로그우도를 평가하고, 수렴 판정이 바로 그 값을 씁니다. 내보내는 데 추가 계산이 들지 않습니다.

측정 환경: s1, taskset으로 코어 고정, fast-mlsirm 0.11.4, CPython 3.12.11. 돌고 있는 A4 실행은 건드리지 않았습니다.

[seonghobae]

Lead next-action note (A4 still running — do not touch)

Observed cost (prior comment): ≥2400s/iter at q=241 on s1 → A4 may be ≤19 iters after ~13h with no external progress. That remains the urgency case for this issue.

Next implementation slice (when a worker is free; after #2015 lands / does not block A4):

1. Add opt-in progress for fit_two_tier_grm (and shared long EM entry points): at least iter, current marginal loglik, and Δloglik vs previous — values already computed for convergence (Bock & Aitkin 1981 pp. 445, 448). Prefer callback and/or verbose/progress sink; no extra quadrature.
2. Keep default silent (compat with 0.11.4 callers). ADR-0028: no unsourced knobs.
3. Characterization test: callback invoked once per EM iter with monotonic iter index; silent default unchanged.
4. Do not attach to or restart A4 (PID 2716563). Progress lands for the next long fit; A4 finishes blind or exits first.

Not starting that worker until #2015 Semgrep/Oakes CI clears the merge bar or owner prioritizes #2021 over queue wait.

[seonghobae]

Implementation plan (#2021)

Paper basis (full text read): Bock, R. D., & Aitkin, M. (1981). Marginal maximum likelihood estimation of item parameters: Application of an EM algorithm. Psychometrika, 46(4), 443–459. https://doi.org/10.1007/BF02293801

• p. 445, eqs. (5)–(6): observed-data marginal log-likelihood log L = C + Σ_l r_l log P_l with P_l the quadrature approximation to the marginal pattern probability.
• p. 447: each EM cycle’s E-step recomputes L_l(X_k) and P_l = Σ_k L_l(X_k)A(X_k) before the M-step; cycles continue until estimates stabilize (geometric convergence near the solution).
• p. 448: the procedure satisfies the marginal likelihood equations. Exporting the already-evaluated marginal loglik / Δloglik therefore needs no extra quadrature.

API shape (opt-in; default silent for 0.11.4 compat; ADR-0028: no unsourced numeric knobs):

@dataclass(frozen=True)
class EmIterationProgress:
    iteration: int              # 0-based E-step index within this start
    loglik: float               # current observed-data marginal loglik
    delta_loglik: float | None  # None on first eval of the start; else ll − previous
    start: int                  # multi-start index in 0..n_starts-1

def fit_two_tier_grm(..., progress: Callable[[EmIterationProgress], None] | None = None) -> TwoTierGrmFit: ...
def fit_bifactor_grm(..., progress: Callable[[EmIterationProgress], None] | None = None) -> ...: ...

• progress=None (default): identical silent behavior to 0.11.4.
• Callback invoked once per E-step after the already-computed marginal loglik is recorded for convergence (same value as loglik_trace[iteration]).
• Rust core takes Option<&mut dyn FnMut(EmIterationProgress)>; PyO3 re-acquires the GIL only when a callback is supplied (GIL-detach path unchanged when progress is None).
• No verbose integer levels in this slice — callers print/log inside the callback.

Tests: characterization — callback once per EM iter with monotonic iteration; omit progress → no callback traffic / result unchanged.

Out of scope: do not touch A4 on s1 (PID 2716563); no Semgrep/#2015 changes.