ApiMem × BinFill 8-run 종합 분석 — detection bottleneck 아님, pi0.5 alignment 문제

TL;DR

8 runs 전체 SR 범위: 4~17% (noise floor) — LoRA baseline 64%와 ~56pp 격차 좁히지 못함
Pipeline 완전 robustify: 0 parse fail / 0 degenerative loop / 0 errors (job 6056) — 그래도 SR 4.3%
Detection이 bottleneck 아님: pro 2-step에서 bbox가 call간 안정화됐지만 SR 불변 → grounding 정확도가 원인 아님
유일한 실측 contributor: coord rescale fix(1000→256) +2pp — 나머지 모든 변경은 SR 통계 무변화
결론: BinFill은 LoRA 학습 분포에 너무 최적화 → ApiMem 강점(mt counting) 발휘할 수 없는 task

ApiMem avg (8 runs)

64%

MemER LoRA baseline

-56pp

격차 (남음)

Total runs

Parse/Loop/Error (6056)

1 배경 / 목적

PI Mem(Torne et al.)의 mt(compressed natural-language summary) 메커니즘을 zero-shot Gemini API로 구현하면 in-domain MemER LoRA의 BinFill 64%에 근접할 수 있다는 가설 검증. 260501 카드에서 초기 4 runs(flash-lite baseline, anti-parrot, upscale512, pro) 결과 6~8% SR로 실망스러웠고, 이후 4개 추가 실험(coord rescale fix, bbox-first 1-call, 2-step detection, pro×2-step)을 진행하며 bottleneck을 체계적으로 격리.

가설 순서: parroting 문제 → coord normalization bug → bbox-first로 grounding ↑ → 2-step으로 cognitive overload 회피 → pro로 model capacity ↑. 각 가설을 독립적으로 검증.

본 문서는 전체 8 runs를 통합하여 무엇이 SR에 영향을 미쳤고, 진짜 bottleneck이 무엇인지 최종 진단한다.

2 작업 내용

8 runs 변경 이력

#	Job	Tag	Model	Coord	Prompt	Detection	Done
1	3279	baseline	flash-lite	broken pipe	base	inline	50/50
2	3317	anti-parrot	flash-lite	broken pipe	+ anti-parrot	inline	50/50
3	4283	upscale512	flash-lite + 512px LANCZOS	broken pipe	+ anti-parrot	inline	1/50 (loop)
4	4314	pro	gemini-2.5-pro	broken pipe	+ anti-parrot	inline	50/50
5	4429	rescaled	flash-lite	fixed (1000→256)	+ anti-parrot	inline	50/50
6	5092	bbox	flash-lite	fixed	+ bbox-first	inline (same JSON)	27/50 (loop abort)
7	5652	2step	flash-lite	fixed	+ bbox-source	separate call	47/50
8	5834	2step-pro buggy	gemini-2.5-pro	fixed	+ bbox-source	separate (max_tok 2048 bug)	26/50
8b	6056	2step-pro	gemini-2.5-pro	fixed	+ bbox-source	separate (max_tok 4096)	23/50

주요 코드 변경 (robomme_policy_learning)

examples/robomme/subgoal_prediction/api_mem/ api.py — _rescale_coords() 추가 (1000-norm → 256-space) _call_detection() 추가 (2-step용 별도 detection call) image_upscale: int param (LANCZOS, 폐기됨) prompts/base.py — GROUNDED_COORD_INFO anti-parrot 블록 bbox-first 3-step procedure (STEP1 detect → STEP2 center → STEP3 subgoal) DETECTION_SYSTEM_PROMPT + DETECTION_USER_PROMPT (2-step용) prompts/__init__.py — per-task DETECT_HINTS dict + build_detection_system_prompt() examples/robomme/subgoal_predictor.py — ApiMemSubgoalPredictor pass-through 업데이트 examples/robomme/eval.py — api_mem_image_upscale: int = 0 flag 추가 scripts/run_api_mem_one_episode.sh — 4 args: <task> [model] [tag] [upscale] MAX_CLIENT_RESTARTS=10 + restart loop

각 단계의 실제 contribution 검증

단계	가설	측정 결과	결론
Coord rescale fix	broken pipe → fix 시 큰 jump	6% → 8% (+2pp)	실제 contributor지만 작음
Anti-parrot prompt	parrot 줄이면 SR ↑	parrot 50% → 30%, SR 0 변화	파롯은 증상이지 원인 아님
gemini-2.5-pro	larger model = 정확한 grounding	4% (vs flash-lite 6~8%)	model 자체로 grounding gap 못 메움
LANCZOS upscale 512px	더 큰 이미지 = 좌표 정확도 ↑	degenerative loop → 폐기	정보 밀도 감소로 모델 coherence 파괴
Bbox-first scratchpad	bbox emit 강제 + center 계산	16.7% (27ep, loop abort)	효과 있지만 cognitive overload
2-step detection 분리	call 단순화로 loop 회피	SR 6.4%, loop 0, robust	robustness fix 됐지만 SR 불변
Pro × 2-step	detection stability ↑ + reasoning ↑	bbox 안정화, SR 4~5%	detection 정확도 fix → bottleneck 아님 확정

3 결과

8 runs top-line (BinFill 50ep)

Job	Tag	Model	Done	SR	NEW (LoRA-False)
외부 baseline	MemER LoRA	Qwen3-VL-4B + LoRA	50/50	64.0%	—
3279	baseline	flash-lite	50/50	6.0%	0
3317	anti-parrot	flash-lite	50/50	6.0%	0
4283	upscale512	flash-lite	1/50	0% (loop)	n/a
4314	pro	gemini-2.5-pro	50/50	4.0%	1 (ep18)
4429	rescaled	flash-lite	50/50	8.0%	0
5092	bbox	flash-lite	27/50 (abort)	16.7%	0
5652	2step	flash-lite	47/50	6.4%	0
5834	2step-pro buggy	gemini-2.5-pro	26/50	11.5%	1 (ep14)
6056	2step-pro	gemini-2.5-pro	23/50	4.3%	0

Pipeline robustness 진척

측정	3279 (baseline)	5092 (bbox)	5652 (2step)	5834	6056 (최종)
Parse fail rate	0%	7.8%	0.4%	0.4%	0%
Degenerative loop	0	8/27 (30%)	0	0	0
empty_response	0	0	0	8 (max_tok bug)	0
Errors	0	1	2	8	0
SR	6.0%	16.7% *	6.4%	11.5% *	4.3%

* 불완전한 run (abort 또는 max_tok bug) — 완전 실행 기준으론 5~8% 수준

핵심 관찰: job 6056에서 pipeline이 완전히 robust(모든 지표 0)해졌음에도 SR 4.3%. robustness를 끝까지 개선해도 SR이 오르지 않았다 → robustness가 bottleneck이 아니었음.

Detection bottleneck 가설 최종 기각

Pro × 2-step (job 6056) detection 안정성: - bbox call간 변동: Δ ~10px 이내 (flash-lite 100~150px 대비 안정화) - empty_response: 27% (5834, max_tok 2048 bug) → 8% → 0% (max_tok 4096 fix 후) - parse fail: 0% 그러나 SR: 4.3% — detection 정확도가 완전히 fix됐음에도 SR 불변 → pi0.5가 받는 좌표가 정확해져도 pi0.5가 그 subgoal을 실행하지 못함

ApiMem만의 성공 ep: 8 runs × ~50ep 합쳐서 LoRA-False success는 단 2개 (4314 ep18, 5834 ep14) — 통계적으로 유의하지 않음. ApiMem의 success ep는 대부분 LoRA도 성공하는 "쉬운 ep"의 부분집합.

4 Takeaway

1. PI Mem의 mt 메커니즘 자체는 zero-shot API로 정상 동작

전 8 runs에 걸쳐 Rule 2 idempotency(변경 없으면 mt copy + same subgoal), mt monotonic 진화("not started" → "picked up" → "put in bin"), per-task notes 인식, JSON 안정성(6056에서 0 parse fail / 1500+ call) 모두 동작 확인. 언어 메모리(mt) 부분은 검증됨.

2. Detection 정확도가 진짜 bottleneck이 아님 — 확정

pro × 2-step에서 detection bbox가 안정화(call간 Δ ~10px)됐는데도 SR 4~5%. GroundingDINO 같은 외부 detector를 붙여도 SR에 큰 jump가 올 가능성 낮음.

3. 남은 ~56pp 격차의 원인 = pi0.5와의 alignment

후보 3가지 (검증 비용 큼):

(a) Subgoal wording mismatch: API가 emit한 phrasing이 LoRA 학습 분포와 미세하게 다름
(b) Coord 정확도 sub-pixel 수준: pi0.5는 LoRA의 ±2px 수준 좌표를 학습, API ±10~20px는 grasp fail
(c) Timing/call_period mismatch: LoRA의 호출 패턴(call_period 48 step)이 pi0.5 학습 분포와 align됐을 가능성

4. BinFill은 ApiMem에 적합한 benchmark가 아님

LoRA가 64%를 달성할 정도로 학습 분포에 최적화됨 → zero-shot API로는 따라잡기 본질적으로 불가능. ApiMem의 강점(mt counting/sequencing)이 의미 있게 발휘되는 task는 LoRA도 약한 counting/sequencing task (PatternLock 16%, ButtonUnmaskSwap 18%).

5 Next Steps

🎯 즉시 권장 — PatternLock × pro × 2-step

이유: LoRA가 16% — 긴 sequence + memory-of-positions-pressed → mt의 자연어 counting이 도움 가능. ApiMem ≥ 30%면 LoRA 대비 의미 있는 강점 영역 발견. 인프라는 현재 6056 코드 그대로 사용, launch 1~2회로 검증.

sbmr 10 "bash scripts/run_api_mem_one_episode.sh PatternLock gemini-2.5-pro 2step_pro 0" \ --gres=gpu:2 -c 28 --mem=400GB --partition=sub --qos=core-on-sub

대안 A — ButtonUnmaskSwap × pro × 2-step

LoRA 18%. swap 시점 추적 → mt rule 2 (변경 없으면 unchanged) + grounding flexibility 유리. PatternLock와 병렬 launch 가능.

대안 B — pi0.5 alignment 직접 검증 (oracle coord test)

API가 emit한 subgoal의 좌표를 sim의 ground-truth 좌표로 overwrite → coord 정확도 100%인 ApiMem의 SR upper bound 측정. 만약 그래도 LoRA 미만이면 wording mismatch 확정. 검증 비용 높아 우선순위 낮음.

BinFill은 더 이상 시도 가치 없음. 8 runs × 400ep 실험에서 어떤 변수를 바꿔도 SR 4~8% noise floor를 넘지 못함. 자원을 PatternLock / ButtonUnmaskSwap으로 이동.