Resume 태스크는 writer가 30초 단위 window(1fps, 30frame)로 메모리를 갱신하는 구조다. 그런데 query의 context_frames cut이 window 중간에 걸리는 경우, 이전 구현은 마지막으로 완료된 window까지만 메모리를 기록했다 — 반면 query frame과 uniform frame sampling은 cut 지점까지 그대로 노출된다. 즉 리더가 보는 "질문 시점"과 메모리가 커버하는 "기록 시점"이 어긋나 있었고, 이는 retrieval 기반 방법(srf, stag)에 불리하게 작용할 소지가 있었다.
동시에 Resume의 Single/Multi 서브타입 분할 기준도 재검토가 필요했다. 기존에는 "잔여 action units 개수(1~5)"로 나눴는데, 이 기준은 논문이 실제로 강조하는 "동시에 몇 개의 작업이 중단된 상태인가(pending task 개수, 1개 vs 2개)"와 다른 축이었다.
srf)과 tagmem이 실제보다 낮게 평가되고 있었을 가능성 + Single/Multi 라벨이 논문 서술과 맞지 않는 축을 사용 중이었음.두 가지를 함께 수정했다 — 서로 다른 이슈지만 같은 Resume 프로토콜 정합화 작업으로 한 커밋에 반영됨.
Qwen3.8-27B는 vLLM 배치 추론이 bit-deterministic하지 않아 동일 설정을 두 번 읽었을 때 13개 행이 뒤바뀌는 현상이 있었고(통계적으로는 tie, p≥.34), 이번에 반영된 값은 그 중 두 번째 read다 — 이 논-결정성은 tail-window 수정과 무관한 별도 노이즈 소스로 appendix에 각주 처리됨.
Resume Avg (전체 161 쿼리 가중평균), tail-window 수정 전 → 후:
| Reader | Strategy | Old Avg | New Avg | Δ (pp) |
|---|---|---|---|---|
| Flash-7 | stag (tagmem, full) | 44.1 | 52.8 | +8.7 |
| Flash-7 | srf (recency-window) | 33.5 | 46.0 | +12.5 |
| Flash-7 | svis (rewritten memory) | 32.3 | 30.4 | -1.9 |
| Qwen3.8-27B | stag | 36.6 | 45.3 | +8.7 |
| Qwen3.8-27B | srf | 30.4 | 43.5 | +13.1 |
| Gemma 4-31B | stag | 23.6 | 33.5 | +9.9 |
| Gemma 4-31B | srf | 15.5 | 25.5 | +10.0 |
GT Action Log(레퍼런스, stextlog)는 그룹핑만 바뀌었을 뿐 동일 정답 텍스트를 주는 조건이라 큰 변화는 없어야 하는데, Flash는 100.0/100.0/100.0으로 불변, Qwen3.8은 91.3→93.8, Gemma4는 90.1→91.9로 소폭 변동 — 재그룹핑에 따른 재계산 폭 안에서 설명 가능한 수준이다.
srf, stag)이 tail-window 수정으로 가장 크게 이득을 봄(+8.7~+13.1pp) — 메모리가 놓치던 마지막 partial window에 정확히 pending task 관련 단서가 있었다는 뜻이다. 반면 svis(전체를 다시 요약해서 쓰는 방식)는 오히려 소폭 하락(Flash -1.9pp) — 재요약 과정에서 tail 정보가 다른 이유로 희석됐을 가능성.이번 수정 전까지 Resume 결과는 retrieval 기반 방법들의 성능을 체계적으로 과소평가하고 있었다. writer-query 구간 불일치는 미묘한 구현 버그지만 방향이 항상 한쪽(메모리 손실)으로만 작용했기 때문에, tagmem의 상대적 우위 자체는 유지되면서도 절대 수치가 8~13pp씩 낮게 보고되고 있었던 것 — 논문 심사에서 "왜 tagmem이 이 정도밖에 안 되냐"는 질문을 받았을 반박 여지가 있던 지점이 해소된 셈이다. Single/Multi 재정의는 수치보다 서술의 정합성 문제로, appendix 설명과 실제 표 그룹핑이 어긋나 있던 것을 바로잡았다.
Qwen3.8의 vLLM 비결정성(13행 flip, p≥.34)은 여전히 남아있는 노이즈 소스 — 보고된 수치가 "두 번의 동일 greedy read 중 두 번째"라는 임의성이 각주로만 처리돼 있다. 재현성 확보를 위해선 seed 고정 방법 조사 필요.
Finding/Restore/Routine에도 동일한 writer-query 구간 불일치가 있는지 점검 — 특히 Routine도 고정 window writer를 쓰므로 같은 tail 누락 패턴이 있을 가능성이 있다(가설: 있다면 srf/stag가 여기서도 과소평가됐을 것).