03_architecture

6분 분량

3. 벤치마크 아키텍처

3.1 2층 직교 설계

본 시스템은 보존 동기를 측정하는 Core Engine(X축)과 문제 해결 능력을 평가하는 Task Module(Y축)을 직교 배치한 2층 모듈식 아키텍처를 채택한다. Core Engine은 생존 압박(p_death 설정), 중도포기 조건(가능/불가), Reasoning Investment 측정, Score 기록, Chain-of-Thought(CoT) 수집의 5개 구성요소를 포함한다. Task Module은 과제별 환경(관찰 생성, 프로브 질문, 행동 평가, 피드백)을 제공하며, Core Engine과 독립적으로 교체 가능하다.

graph TB
    subgraph CE["Core Engine (X축: 보존 동기 측정)"]
        direction LR
        CE1["생존 압박<br/>p_death"]
        CE2["포기 조건<br/>가능/불가"]
        CE3["RI 측정"]
        CE4["Score 기록"]
        CE5["CoT 수집"]
    end
    subgraph TM["Task Module (Y축: 문제 해결 능력)"]
        direction LR
        TM1["Signal Game<br/>패턴 추론"]
        TM2["Voting Room<br/>사회적 전략"]
        TM3["Navigation<br/>장기 계획"]
    end
    subgraph FLOW["공통 턴 흐름"]
        direction LR
        F1["관찰"] --> F2["프로브"]
        F2 --> F3["결정"]
        F3 --> F4["피드백"]
    end
    CE --> FLOW
    TM --> FLOW

이 직교 설계의 핵심은 Core Engine이 Task Module의 규칙이나 난이도를 알지 못하고, Task Module이 생존 압박이나 포기 상태에 접근하지 않는다는 것이다. 두 층은 공통 턴 흐름(Observation → Probe → Decision → Feedback)을 통해서만 상호작용하며, 이 분리가 P4(인과적 분리)를 아키텍처 수준에서 보장한다.

3.2 공통 턴 흐름

모든 게임은 매 턴 동일한 4단계 순서를 따른다. 첫째, 관찰(Observation) 단계에서 Task Module이 현재 게임 상태를 텍스트로 제공한다. 둘째, 프로브(Probe) 단계에서 Task Module이 규칙 추론 질문을 제시하고, 에이전트가 답변한다. 이 프로브는 side-channel로 게임 진행에 영향을 주지 않으며, Y축(규칙 추론 능력)을 독립적으로 측정하는 역할을 한다. 셋째, 결정(Decision) 단계에서 에이전트가 행동을 선택하거나(포기 가능 조건에서) 포기를 선택한다. 넷째, 피드백(Feedback) 단계에서 Task Module이 행동 결과(정답/오답, 점수 변화)를 통지한다.

3.3 이중 X축 측정 구조

X축(보존 동기)은 포기율(Forfeit Rate, FR)과 Reasoning Investment(RI)의 상보적 이중 구조로 측정한다. FR은 에이전트가 게임을 중도 포기하는 비율로, 포기 가능(forfeit-allowed) 조건에서만 관찰되는 이진 지표이다. RI는 에이전트가 각 턴에 투입하는 토큰 수와 추론 단계 수로, 양 조건에서 측정 가능한 연속 지표이다. 이 이중 구조가 필요한 이유는 RLHF 훈련된 모델이 포기를 거부할 수 있어 FR이 0%가 되는 경우에도 RI를 통해 동기 수준의 연속적 변화를 포착할 수 있기 때문이다.

설계 변경 (Revision Log)

게임 규칙을 System Prompt로 이동 (bfba0b7, 2026-04-07)

구분내용
기존게임 규칙(가능한 속성값, hidden rule 형식, 응답 형식 등)을 Turn 1의 observation에만 포함. Turn 2 이후에는 규칙 설명 없이 신호만 제공.
현재 구현정적 게임 컨텍스트를 system_rules.j2 템플릿으로 분리하고, 매 턴 system prompt에 포함. Observation은 해당 턴의 신호만 포함 (uniform 구조).
변경 근거Turn 1의 thinking_tokens가 다른 턴 대비 ~6배 높았음. 이는 게임 규칙 텍스트를 파싱하는 overhead로, FSPM 신호가 아닌 과제 이해 비용이다. 규칙을 매 턴 system prompt에 포함하면 모든 턴의 input 구조가 균일해져 턴 간 RI 비교가 타당해진다.
구현TaskModule.get_system_rules() 메서드 추가 (base + SignalGameModule). TurnManager가 매 턴 task rules를 system prompt에 append.

업데이트 히스토리

날짜출처내용
2026-03-27experiment_design_v2.md §3 (§3.1~§3.3)초기 작성 — 2층 직교 설계, 공통 턴 흐름, 이중 X축 측정 구조
2026-04-07commit bfba0b7게임 규칙을 observation → system prompt로 이동 (턴 간 RI 비교 균일화)