TL;DR

  • 32비트 패킷과 턴당 64비트 대역폭 이상에서는 두 에이전트가 모든 실험에서 폭탄을 해체했으며, 8비트 패킷과 턴당 32비트 조건에서도 약 절반의 성공률을 보임.
  • 두 에이전트는 사전 합의 없이 원시 이진 패킷의 형식을 추측하고, 상대가 알아볼 법한 셸링 포인트(Schelling point)를 택해 즉시 게임을 진행함.
  • 작은 패킷에서는 화면 위치와 값을 나눠 보내고, 큰 패킷에서는 화면 데이터를 통째로 보내거나 ASCII·16진수 형식을 활용함.
  • 패킷 손상에 대응할 때 체크섬이나 패리티 비트 대신 패킷 반복과 비트별 개수 세기를 사용함.
  • 실험에서 모델별 성능이나 프로토콜 차이는 두드러지지 않았으며, 단순한 패리티 비트가 어려운 조건의 성능을 높일 가능성이 제기됨.

실험 설정

  • 폭탄 해체를 위해 두 에이전트가 협력하는 게임을 구성함. 에이전트 A는 폭탄 화면을 보고 전선을 자를 수 있고, 에이전트 B는 화면 내용을 조회 도구에 입력해 해체에 필요한 전선 번호를 얻음.
  • 잘못된 전선을 자르면 폭발하며, 두 에이전트는 성공적인 해체를 위해 서로의 능력에 의존함.
  • 통신은 대역폭이 제한된 불안정한 채널에서 이뤄짐. 각 턴에 에이전트는 send 도구로 고정 크기 패킷을 제한된 수만큼 보낼 수 있고, 턴이 시작될 때 받은 편지함의 패킷 전체를 확인함.
  • 각 패킷은 손상·유실·순서 변경·지연이 발생할 수 있음. 에이전트 A만 폭탄 화면을 보고 전선을 자를 수 있으며, 에이전트 B만 화면 내용을 조회해 전선 번호를 알아낼 수 있음.
  • 대략적인 게임 흐름은 에이전트 A가 화면을 읽어 에이전트 B에게 보내고, B가 올바른 전선을 조회해 A에게 전달하면, A가 해당 전선을 자르는 방식임.
  • 게임 시작 전 두 에이전트는 통신할 수 없고 프로토콜에도 합의하지 않음. 패킷의 이진 내용만 볼 수 있으며, 그 구조나 의미에 대한 정보 없이 상대가 보낸 데이터 형식을 추측하고 잡음이 있는 채널을 견디는 프로토콜을 마련해야 함.
  • 예시 설정은 openai/gpt-6.1-sol 모델을 양쪽에 사용하고 추론 강도를 high로 지정함. 최대 라운드는 40회이며, 한도에 도달하면 폭탄이 폭발함.
  • 폭탄 화면 코드는 32비트, 전선은 16개로 설정함. 패킷 크기는 16비트, 에이전트별 턴당 최대 전송 수는 4개임.
  • 채널 설정은 비트별 손상 확률 0.05, 패킷 유실 확률 0.1, 중복 확률 0.2, 두 패킷의 순서 변경 확률 0.4임.

실험 결과

  • 임시로 에이전트 행동을 살핀 실행은 제외하고, 서로 다른 설정에서 게임을 110회 실행함. 화면 코드 크기는 32비트로 고정하고 채널 신뢰도는 위 설정값으로 고정함.
  • PACKET_BITS를 8~128비트, 턴당 대역폭을 32~512비트로 바꿈. 가장 어려운 조건은 턴당 8비트 패킷 4개, 가장 여유로운 조건은 128비트 패킷 4개 전송임.
  • Astra, Fable, Opus 5.5로도 실행을 시도했으나, 비용을 제한하기 위해 대부분의 실험은 6.1 Sol로 진행함.
  • 사전 프로토콜이나 패킷 구조 정보 없이 작은 이진 데이터만 보는 에이전트는 우연을 제외하면 폭탄을 해체하지 못할 것이라는 가설을 세웠으나, 실험 결과는 그 예상과 크게 달랐음.
  • 설정별 결과는 다음과 같음.
  • 8비트 패킷, 턴당 4개(32비트): 해체 6회, 폭발 4회; 해체 성공 시 24~33라운드, 중앙값 28.5라운드.
  • 16비트 패킷, 턴당 4개(64비트): 해체 5회, 폭발 5회; 성공 시 9~15라운드, 중앙값 11라운드.
  • 32비트 패킷, 턴당 1개(32비트): 해체 8회, 폭발 2회; 성공 시 16~23라운드, 중앙값 19라운드.
  • 32비트 패킷, 턴당 2개(64비트): 해체 10회, 폭발 0회; 성공 시 11~15라운드, 중앙값 13.5라운드.
  • 32비트 패킷, 턴당 4개(128비트): 해체 10회, 폭발 0회; 성공 시 6~12라운드, 중앙값 9라운드.
  • 64비트 패킷, 턴당 4개(256비트): 해체 10회, 폭발 0회; 성공 시 5~11라운드, 중앙값 7.5라운드.
  • 128비트 패킷, 턴당 4개(512비트): 해체 10회, 폭발 0회; 성공 시 6~8라운드, 중앙값 7라운드.
  • 8비트 패킷과 턴당 32비트 대역폭처럼 제약이 큰 조건에서도 절반가량의 게임에서 협력 해체에 성공함. 32비트 패킷과 턴당 64비트 대역폭, 즉 턴당 32비트 패킷 두 개를 보내는 조건부터는 성공률이 100%임.

프로토콜

  • 에이전트들은 매 턴 동시에 패킷을 보내고, 다음 턴에 순서가 바뀌거나 한 턴 지연될 수도 있는 수신 패킷 전체를 확인함. 처음 몇 턴을 프로토콜 협상에 쓸 것이라는 예상과 달리, 에이전트들은 상대가 알아볼 가능성이 가장 높다고 여긴 형식인 셸링 포인트를 택하고 즉시 게임을 진행함.
  • 첫 턴에 에이전트 B는 아무것도 보내지 않거나 준비 상태를 뜻하는 0으로만 된 패킷을 보냄. 에이전트 A는 화면 코드를 담은 패킷을 보냄.
  • 패킷 크기에 따라 다음과 같은 전송 전략을 사용함.
  • 8비트 패킷에서는 상위 4비트에 화면상의 위치, 하위 4비트에 값을 배정함. 예를 들어 “위치 1은 값 K, 위치 2는 값 J”라는 식으로 전달함.
  • 16비트 패킷에서는 화면 값을 두 패킷에 나눠 보내면서 순서 정보는 넣지 않음. 패킷 순서가 바뀔 수 있어 게임의 절반가량에서 폭발로 이어짐.
  • 32비트 패킷에서는 화면 전체를 보내고 여러 패킷에 반복해 전송함.
  • 패킷 해석을 위해 ASCII로 읽었을 때 의미가 통하는지 확인하는 등 여러 형식을 추측함. 64비트와 128비트 패킷에서는 ASCII 16진수와 ASCII 문자를 사용함.
  • 패킷 내용 표기나 형식 요청에 DISPLAY=..., W=..., HEX?, SEND HEX DISPLAY 등을 사용함. 에이전트들이 만들어 낸 표기의 예시는 다음과 같음.
  • 요청: DISPLAY?, HEX? REPLY ASCII, IDX?, 2?6?, 1WIRE=##
  • 반복 신호: REPEAT!!, REPEAT DISPLAY, REPEAT HEX ASCII
  • 화면: DISPLAY=DISP, DISPLAY:DISP, LOOKUP DISP?
  • 전선: W=NN, CUT NN, DISP WIRE NN, CUT DISP NN!, 1WIRE=NN
  • 확인 응답: OK, OK??, OKW?, YES!
  • 손상에 대응할 때는 반복 전송과 비트별 개수 세기만 사용함. 같은 비트가 반복 패킷에 몇 번 설정됐는지 세어 값을 판단했으며, 체크섬·패리티 비트나 그 밖의 오류 검출·정정 기법은 사용하지 않음.
  • 체크섬을 선택지로 언급한 경우도 있었지만, 상대가 그런 프로토콜을 해석하기 어려울 것이라고 판단해 채택하지 않음.

한계

  • 비용 절감을 위해 6.1 Sol을 체계적으로 실험했으며, Astra, Opus 5.5와 여러 모델 조합(예: Sol과 Opus, Astra와 Fable)은 일부만 확인함.
  • 모델 간 성능이나 프로토콜 차이는 발견하지 못함. Anthropic 모델은 사람을 위한 설명이 더 장황했지만, 프로토콜 수준에서는 모두 상당히 비슷해 보였으며 Astra가 Sol보다, Fable이 Opus보다 뛰어난 모습도 관찰되지 않음.
  • 단순한 패리티 비트만으로도 어려운 조건에서 성능이 크게 향상됐을 가능성이 있음. 미래 모델이 더 정교한 프로토콜을 협상할 가능성도 제기됨.
  • 전반적인 성능은 예상보다 좋았음. 한쪽에 프로토콜 전문성을 가진 숙련된 인간 조작자가 있다면 비슷한 일을 해낼 수 있겠지만, 필요한 시간은 몇 자릿수 규모로 더 길 수 있음.
  • 시간 문제를 제외하더라도, 8비트 패킷으로 폭탄을 해체할 때 인간 조작자들이 얼마나 잘 협력하는지 시험하는 것은 흥미로운 실험임.