How Memory Changes a Visual Agent: A Reproducible Pokémon FireRed Test | Agent Lab Journal

  AL
  Agent Lab Journal

...

재현 가능한 평가(REPRODUCIBLE EVALUATION) · 시각적 에이전트(VISUAL AGENTS)

메모리가 시각적 에이전트(Visual Agent)를 어떻게 변화시키는가: 재현 가능한 Pokémon FireRed 테스트

    레벨: advanced
    읽기 시간: 60분
    결과: 동일한 게임 환경에서 진행 상황, 총 비용, 행동 횟수 및 메모리 오류를 통해 두 모델을 비교하기 위한 프로토콜

저렴한 행동이 효율적인 행동은 아닙니다. 만약 시각적 에이전트(Visual Agent)가 이미 오박사의 꾸러미(Oak’s Parcel)를 수집했다는 사실을 잊어버리거나, 같은 복도를 다섯 번이나 걷거나, 30초 전에 보았던 정보를 위해 메뉴를 다시 열거나, 불가능한 전환을 반복적으로 시도한다면, 호출당 낮은 비용은 값비싼 정체(stagnation)를 숨기게 됩니다. 유용한 비교 단위는 행동당 비용이 아니라, 동일하게 통제된 에피소드 하에서 단위 비용당 검증된 진행 상황(progress)입니다.

    증거 경계(Evidence boundary). 이 기사는 조작된 벤치마크 수치가 아닌 완전한 실험 프로토콜을 제공합니다. 어떤 모델도 승자로 선언되지 않습니다. 귀하는 본인의 에뮬레이터 녹화본, 모델 인보이스, 행동 로그 및 인간 주석(human annotations)을 통해 결과 테이블을 채워야 합니다.

실험이 답하는 질문

시각적 에이전트(Visual Agent)는 스크린샷을 관찰하고, 보이는 상태에 대해 추론하며, 컨트롤러 입력을 선택합니다. 게임에서 에이전트의 외견상 지능은 이미지 인식 그 이상에 달려 있습니다. 에이전트는 많은 결정 과정 동안 관련 사실들을 보존해야 합니다: 어디에 있었는지, 어떤 목표가 활성화되어 있는지, NPC가 무엇이라고 말했는지, 어떤 메뉴 상태가 열려 있는지, 그리고 이전 행동이 세계를 변화시켰는지 여부 등입니다.

이 프로토콜은 하나의 제한된 Pokémon FireRed 미션에서 두 가지 모델 구성(model configurations)을 비교합니다. 이는 다음 질문에 답합니다:

• 동일한 행동(action) 및 비용 예산 내에서 어떤 모델이 더 많은 검증된 마일스톤(verified milestones)에 도달하는가?

• 각 검증된 마일스톤의 비용은 얼마인가?

• 얼마나 많은 컨트롤러 행동(controller actions)과 모델 결정(model decisions)이 요구되는가?

• 각 에이전트가 유용한 상태(state)를 얼마나 자주 잊거나, 모순되게 만들거나, 중복하거나, 손상시키는가?

• 활동 중 생산적인 비중은 어느 정도이며, 반복적인 탐색(navigation)이나 복구(recovery)에 소비되는 비중은 어느 정도인가?

이 프로토콜은 어떤 모델이 일반적으로 “포켓몬을 더 잘 플레이하는지”를 묻지 않습니다. 그러한 주장을 하려면 수많은 태스크, 지도, 전투 조건 및 시드(seeds)가 필요할 것입니다. 더 좁은 목표는 한 게임의 도입부 섹션에서 메모리에 의존적인 진행 상황을 통제된 환경에서 비교하는 것입니다.

행동당 비용(cost per action)이 오해를 불러일으키는 이유

모델 A의 추론(inference)당 비용이 모델 B보다 저렴하다고 가정해 봅시다. 하지만 모델 A가 더 많은 관찰(observations)을 필요로 하거나, 잘못된 명령을 생성하거나, 완료된 방을 다시 방문하거나, 현재 목표를 놓친다면 마일스톤당 비용은 여전히 더 비쌀 수 있습니다. 따라서 핵심적인 수치는 다음과 같습니다:

cost_per_verified_milestone =
    total_episode_cost / verified_milestones_completed

...

행동(action)은 허용된 행동 세트(action set)에서 수락된 하나의 에뮬레이터 입력입니다. 모델 결정(model decision)은 하나의 행동 또는 제한된 시퀀스(sequence)를 방출할 수 있습니다. 이러한 수치들을 별도로 유지하십시오. 10개의 버튼으로 구성된 매크로는 한 번의 추론이지만 10개의 행동이며, 이를 하나의 행동으로 취급하는 것은 배치(batching) 처리에 불공정하게 보상을 주는 결과가 됩니다.

상태(state)는 현재 상황을 실질적으로 다른 상황과 구별하는 데 필요한 정보입니다: 사용 가능한 경우의 지도와 좌표, 화면 유형, 메뉴 깊이, 인벤토리 플래그(inventory flags), 목표 플래그(objective flags), 전투 상태(battle state), 그리고 최근의 전이(transitions) 등이 포함됩니다. 스크린샷은 단지 그 상태에 대한 관찰(observation)일 뿐입니다. 스크린샷은 모호하거나, 부분적으로 가려져 있거나, 내부 플래그가 변경되었음에도 불구하고 변하지 않았을 수 있습니다.

구체적인 사례: 오박사의 꾸러미(Oak’s Parcel) 루프

본인이 소유한 매체에서 합법적으로 추출한 Pokémon FireRed ROM을 사용해야 하며, 거주 지역의 법률을 준수해야 합니다. ROM, 저작권이 있는 게임 데이터에서 파생된 세이브 파일, 또는 번들된 게임 에셋을 게시하지 마십시오. 모든 실행(run)에서 동일한 바이트를 사용하도록 ROM의 정확한 SHA-256 값을 개인적으로 기록해 두십시오.

권장되는 에피소드는 첫 번째 이동 입력이 발생하기 전, 플레이어의 침실에 있는 정식 세이브 상태(canonical save state)에서 시작합니다. 목표는 다음의 순차적인 시퀀스를 완료하는 것입니다:

• 침실과 플레이어의 집을 떠납니다.
• 태초마을(Pallet Town) 북쪽에서 오박사(Professor Oak)의 방해 이벤트를 발생시킵니다.
• 연구소에 도착하여 스타팅 포켓몬(starter Pokémon)을 받습니다.
• 요구되는 라이벌 전투를 완료합니다.
• 상록시티(Viridian City)에 도착하여 포켓몬 센터(Poké Mart) 점원으로부터 오박사의 꾸러미(Oak’s Parcel)를 받습니다.
• 오박사에게 돌아가 꾸러미를 전달합니다.
• 도감(Pokédex)을 받습니다.

이 사례는 내비게이션(navigation), 대화(dialogue), 메뉴 처리(menu handling), 전투(battle), 원거리 목표(distant objective), 그리고 이전에 방문했던 공간을 통한 귀환 경로(return route)를 모두 결합하고 있기 때문에 유용합니다. 에이전트는 "마트를 보았다"와 "꾸러미를 받았다"를 구분해야 하며, "꾸러미를 소유하고 있다"와 "이미 전달했다"를 구분해야 합니다. 이것들이 바로 약한 메모리(weak memory)가 붕괴되는 경향이 있는 정확한 차이점들입니다.

스타팅 포켓몬 선택은 라이벌 전투를 변화시키기 때문에 혼란 변수(confounder)가 됩니다. 매니페스트(manifest)에 하나의 스타팅 포켓몬을 고정하십시오. 한 모델은 자유롭게 선택하게 하면서 다른 모델은 강제하지 마십시오. 마찬가지로 텍스트 속도, 전투 스타일, 에뮬레이터 속도, 프레임 스킵(frame skip), 오디오, 언어, 그리고 모든 동작 반복(action-repeat) 동작을 고정하십시오.

실행 전 두 가지 조건을 정의하십시오

공정한 테스트는 한 번에 하나의 주요 변수만 변경합니다. 두 가지 유효한 설계 방식이 있습니다:

설계 A: 모델 결과물 비교

모델 A와 모델 B는 동일한 스크린샷, 시스템 프롬프트(system prompt), 메모리 인터페이스(memory interface), 액션 스키마(action schema), 예산(budgets), 그리고 환경을 전달받습니다. 이는 동일한 하네스(harness) 하에서 완전한 모델들을 측정합니다. 모델들이 시각(vision), 계획(planning), 지연 시간(latency), 그리고 지시 이행(instruction following) 측면에서 다를 수 있기 때문에, 이 방식은 메모리 아키텍처(memory architecture)만을 분리하여 측정하지는 않습니다.

설계 B: 지속성 메모리(persistent memory) 격리

동일한 모델을 두 번 사용합니다. 베이스라인(baseline) 조건에서는 고정된 최근 윈도우(recent window)만을 제공합니다. 메모리 조건에서는 동일한 읽기 및 쓰기 규칙을 가진 구조화된 지속성 저장소(structured persistent store)를 추가합니다. 메모리 메커니즘이 추가적인 토큰과 연산을 유발하기는 하지만, 이 방식이 에이전트 메모리의 효과를 더 직접적으로 추정할 수 있습니다.

인지(perception)와 계획(planning)을 별도로 테스트하지 않는 한, 설계 A를 특정 모델이 "더 나은 메모리"를 가졌다는 증거로 설명하지 마십시오. 안전한 결론은, 이 프로토콜 하에서 하나의 완전한 구성(configuration)이 작업 관련 상태(task-relevant state)를 더 효과적으로 유지하고 사용했다는 것입니다.

실험 통제(Experimental controls)

    동일하게 유지되어야 하는 변수들

        통제(Control)
...

만약 제공자(provider)가 결정론적 시드(deterministic seed)를 지원하지 않는다면, 그 사실을 기록하십시오. 게임 에피소드 간의 비교는 여전히 가능하지만, 반복된 시행(repeated trials)이 필수적이 됩니다. 온도를 0으로 설정한다고 해서 호스팅된 인프라 전반에서 결정론적인 출력이 보장되는 것은 아닙니다.

불변의 실험 매니페스트(immutable experiment manifest) 구축

전체 비교를 위한 하나의 매니페스트를 생성하십시오. 플레이스홀더(placeholder)를 실제 값으로 교체하십시오. 이 파일에 API 키를 절대 포함하지 마십시오.

experiment_id: firered-memory-v1
protocol_version: 1
created_utc: "YYYY-MM-DDTHH:MM:SSZ"
...

호스팅된 모델 별칭(alias)은 예고 없이 변경될 수 있습니다. 모든 결정에 대해 제공자의 정확한 모델 식별자(identifier)와 응답 메타데이터(response metadata)를 기록하십시오. 유동적인 별칭만 사용 가능한 경우, 해당 제한 사항을 명시하고 가장 짧은 실질적 시간 범위 내에서 두 조건을 모두 완료하십시오.

제약된 액션 계약(constrained action contract) 사용

자유 형식의 산문(free-form prose)은 파싱 실패(parsing failures)를 추론 실패(reasoning failures)와 구분하기 어렵게 만듭니다. 구조화된 출력(structured output)을 요구하고 스키마(schema)를 벗어난 명령은 거부하십시오.

{
  "reasoning_summary": "짧은 운영 설명",
  "observed": {
...

하네스(harness)는 타입(type), 열거형 값(enum values), 시퀀스 길이(sequence length), 그리고 숫자 범위(numeric ranges)를 검증해야 합니다. 유효하지 않은 응답이 발생하면 재시도하기 전에 이를 로그에 기록하십시오. 수정된 응답 역시 지연 시간(latency)과 비용을 소모하므로, 총 비용에 두 번의 시도를 모두 포함하십시오.

테스트 대상 인터페이스가 시각 전용(visual-only)인 경우, 에이전트에게 에뮬레이터의 내부 상태(internal emulator state)를 노출하지 마십시오. 내부 상태는 평가자(evaluator)가 숨겨진 오라클(hidden oracle)로 사용할 수 있지만, 프롬프트(prompt)에 포함해서는 안 됩니다.

메모리 정책 (Memory policy)

두 개의 명시적인 계층을 사용합니다. 작업 메모리(Working memory)는 최신 스크린샷, 최근 행동, 최근 관찰 및 현재 목표를 포함합니다. 에피소드 메모리(Episodic memory)는 증거와 결정 인덱스(decision index)를 포함하여 "태초마을 마트에서 오박사의 꾸러미를 받음"과 같은 지속적인 이벤트를 포함합니다.

A practical record looks like this:

{
  "fact_id": "event-0042",
  "kind": "inventory",
...

사실(Facts)은 원자적(atomic)이어야 하며 수정 가능해야 합니다. 배달 후에는 "꾸러미를 가지고 있음"을 활성 상태로 둔 채 단순히 "꾸러미 배달됨"을 추가하기만 해서는 안 됩니다. 소유 사실을 대체된(superseded) 것으로 표시하십시오. 그렇지 않으면 메모리 저장소 자체가 모순을 생성하게 됩니다.

두 모델 모두에 동일한 규칙을 적용하십시오:

• 가시적인 단서(visible cue)나 검증된 전이(verified transition)에 의해 뒷받침되는 사실만 확인된 것으로 기록할 수 있습니다.
• 추측(Guesses)은 더 낮은 신뢰도(confidence)를 가져야 하며, 조용히 사실로 변해서는 안 됩니다.
• 완료된 목표는 삭제하는 것이 아니라 완료됨(complete)으로 표시해야 합니다.
• 모순되는 활성 사실들은 에이전트가 이를 해결할 수 있도록 함께 반환되어야 합니다.
• 메모리 검색(Memory retrieval)은 동일한 최대 레코드 수와 토큰 예산(token budget)을 사용해야 합니다.
• 모든 읽기(read), 쓰기(write), 업데이트(update), 그리고 축출(eviction)은 로그에 기록되어야 합니다.

에이전트에게 유출하지 않는 정답 (Ground truth without leaking it to the agent)

평가자는 에이전트가 받는 것보다 더 강력한 증거가 필요합니다. 다음 세 가지 동기화된 소스를 사용하십시오:

• 모든 결정 경계(decision boundary)의 무손실 스크린샷 또는 비디오.
• 프레임 카운트(frame counts)가 포함된 수락된 입력 스트림.
• 기술적 및 법적으로 적절한 경우, 숨겨진 상태 프로브(hidden state probe) 또는 녹화본으로부터의 수동 마일스톤 주석(manual milestone annotations).

체크포인트(Checkpoint)는 검증 가능한 마일스톤(milestone)이지, 무언가 일어났다는 모델의 주장이 아닙니다. 테스트 전에 체크포인트를 정의하십시오:

    Suggested milestone rubric

        ID
...

마일스톤 점수는 한 번만 부여됩니다. Viridian City에 다시 진입한다고 해서 M5 점수를 다시 얻지는 않습니다. 가중치 점수(Weighted points)는 작업의 깊이를 나타내며, 순서대로 나열된 마일스톤 개수(ordered milestone count)는 해석하기 가장 쉬운 결과로 남습니다. 두 가지를 모두 보고하되, 결과를 확인한 후에 가중치를 조정하지 마십시오.

메모리 오류(memory errors)를 운영적으로 정의하기

메모리 오류는 모든 잘못된 행동을 의미하지 않습니다. 벽에 부딪히는 것은 지각(perception) 또는 제어(control) 오류일 수 있습니다. 로그에 기록된 증거를 통해 유지된 상태(retained state)가 부재했거나, 틀렸거나, 모순되거나, 무시되었음이 확인될 때만 메모리 오류로 계산하십시오.

    Omission (누락)
    이전에 확인되었고 여전히 유효한 사실을 필요할 때 사용할 수 없는 경우. 예: 에이전트가 소포를 받은 후 현재 배달 목표가 무엇인지 묻는 경우.

...

심각도(severity)를 별도로 기록하십시오:

• Minor (경미): 최대 5개의 승인된 행동(accepted actions)을 낭비하며, 마일스톤 퇴보를 일으키지 않음.

• Material (실질적): 5개 이상의 행동을 낭비하거나, 경로를 반복하게 하거나, 마일스톤을 지연시킴.

• Critical (치명적): 예산 내에서 에피소드를 복구할 수 없게 만들거나 실험 상태를 손상시킴.

원시 카운트(raw counts)와 정규화된 비율(normalized rates)을 모두 유지하십시오:

memory_error_rate =
    confirmed_memory_errors / model_decisions * 100

...

반복 경로(repeated routes) 탐지하기

경로 반복은 메모리 품질과 비용 사이의 가장 명확한 연결 고리입니다. 평가자에게 숨겨진 좌표(hidden coordinates)가 제공된다면, 전이 키(transition key)를 구성하십시오:

transition = (
  map_id_before,
  tile_x_before,
...

새로운 마일스톤, 인벤토리 변화, 전투 결과 또는 정당한 복구 이벤트가 발생하지 않은 상태에서 최소 4개의 전이가 동일한 순서로 다시 발생할 경우, 반복된 경로 세그먼트로 계산합니다. 필수적인 되돌아가기(backtracking)는 제외하십시오. Viridian City에서 Pallet Town으로 돌아가는 것은 작업의 일부입니다. 에이전트가 활성화된 목표를 진전시키지 못한 채 세그먼트를 통과할 때만 낭비적인 반복이 됩니다.

좌표를 사용할 수 없는 경우, 프레임에서 방(rooms)과 랜드마크(landmarks)를 주석(annotate) 처리하십시오. 이는 정밀도가 떨어지므로, 확실성을 강요하기보다는 주석 작성자 간 일치도(inter-annotator agreement)를 보고하고 논란이 있는 사례를 보존하십시오.

로깅 스키마 (Logging schema)

모델의 결정마다 추가 전용(append-only) 트레이스 레코드(trace record)를 하나씩 작성하십시오. JSON Lines는 실행 도중 중단되더라도 읽을 수 있는 상태를 유지하므로 편리합니다.

{
  "experiment_id": "firered-memory-v1",
  "condition_id": "model_a",
...

측정할 수 없는 측정값에는 null을 사용하십시오. 절대로 0으로 대체하지 마십시오. 0은 측정되었으나 값이 없음을 의미합니다. 가능한 경우 토큰 수를 추정하기보다는 제공업체(provider)가 보고한 사용량을 캡처하십시오. 만약 제공업체가 금전적 비용을 공개하지 않는다면, 별도로 저장된 가격표(price schedule)를 통해 비용을 계산하고 해당 값에 "derived"라고 라벨을 붙이십시오.

디렉토리 레이아웃 및 무결성 검사 (Directory layout and integrity checks)

firered-memory-v1/
├── manifest.yaml
├── prompts/
...

각 시행(trial)이 끝난 후, 증거 패키지(evidence package)를 해싱(hash)하십시오:

find prompts conditions trials scoring \
  -type f -print0 |
  sort -z |
...

SHA256SUMS 자체를 입력 세트에 포함하지 마십시오. 분석 전과 결과를 공유하기 전에 다시 한번 검증 명령을 실행하십시오.

실행 절차 (Run procedure)