AI에는 맞서 반응하는 테스트가 필요합니다

AI 요약

정답 하나를 맞히는 능력과 연속된 선택을 잘하는 능력은 다릅니다. eSlams 창립자 라마크리슈난 로카나탄(Ramakrishnan Lokanathan)은 AI 모델이 상대의 행동에 대응하고, 상황이 바뀌면 계획을 조정하는 능력을 살펴보기 위해 공개 게임 경기장 eSlams를 만들고 있습니다. 이름은 Electronic Slams의 약자이며, 사람이 AI 모델과 겨루는 Arena와 모델 간 경기를 관전하는 Battlefield로 구성됩니다.

게임으로 이어지는 판단을 평가합니다

고정된 질의응답 시험에서는 응답을 내면 과제가 끝납니다. 게임에서는 그 응답이 다음 문제의 시작입니다. Connect Four에서는 자기 위협을 만드는 것만으로 부족하고 상대의 위협도 살펴야 합니다. 포커에서는 합리적인 선택을 해도 보이지 않는 카드 때문에 패할 수 있습니다. 협동 게임에서는 공동 목표를 향해 조율하는 능력을 살펴봅니다. 목표는 완벽한 플레이를 요구하는 데 있지 않습니다. 모델이 꾸준히 나은 선택을 하고, 상황 변화에 적응하며, 계획이 틀어졌을 때 회복하는지 이해하는 데 있습니다.

eSlams Core는 보드게임, 카드게임, 협상, 협동, 제어 과제를 포함한 50개 게임·제어 환경을 지원합니다. 일부 게임은 간소화하거나 규칙을 변형했으며 카탈로그에 표시합니다. MIT 라이선스로 공개한 엔진은 GitHub와 PyPI에서 제공하며, 개발자는 에이전트를 연결해 실험하고 결과를 살펴볼 수 있습니다.

점수와 실패 기록을 분리합니다

최종 점수만으로는 모델이 나쁜 수를 골랐는지, 상대를 잘못 판단했는지, 유효한 응답을 내지 못했는지 구분하기 어렵습니다. 게임 엔진은 규칙과 플레이어에게 보이는 정보를 통제하고, 수와 기술적 실패를 별도로 기록합니다. 모델이 실패해 소프트웨어가 대신 수를 놓으면 그 개입도 기록하며, 해당 경기는 유효한 점수 산정에서 제외합니다. 경기는 검증과 재생이 가능한 파일로 저장합니다. 공개 리플레이와 비공개 감사 정보는 분리해 관전자는 경기를 보고, 개발자는 결과의 근거를 확인하도록 합니다.

게임은 지능을 전부 평가하지 못하며, 한 번 이겼다고 고위험 애플리케이션에 적합하다는 뜻도 아닙니다. 의미 있는 비교를 하려면 반복 실험과 균형 잡힌 조건, 불확실성에 대한 설명이 필요합니다. 게임 평가는 실제 사용 환경의 시험을 보완하지만 대체하지는 않습니다. eSlams는 2027년 2월 8일부터 14일까지 첫 AI Grand Slams를 열 예정입니다.

dev.to 반응

• @pm25coder — PyPI에서 eslams-core 0.6.2를 설치해 폴백 경로를 처음부터 끝까지 실행했습니다. 주장의 두 부분인 "기록된다"와 "유효한 점수 산정에서 제외된다"는 혼동하기 쉽지만 별개의 기능이기 때문입니다. 사용할 수 있는 행동을 반환하지 않는 좌석과 틱택토에서 첫 번째 합법 수를 고르는 상대를 준비했습니다. Runner API에서는 매 턴 ActResponse(action=None)를 반환하고 on_agent_error="fallback"을 설정했습니다. 이어 실제 CLI에서 --agent http://127.0.0.1:9/act와 --on-agent-error fallback을 실행했습니다. 아래 수치는 코드를 읽어서 추정한 값이 아니라 배포된 코드에서 얻었습니다.

1. 대체 수를 별도로 기록합니다. 확인했습니다. replay/replay_events.jsonl과 traces/public_trace.jsonl의 행에는 action_provenance: "fallback_action"과 markers: ["no_action", "fallback_action"]이 들어 있습니다. 상대가 직접 고른 local_action 행과도 구분됩니다. 행은 턴마다 하나씩이며 대체 수 4개와 직접 고른 수 3개가 기록됐습니다. Runner는 두 경로 모두에서 이 값을 설정합니다. runner.py:350-352는 에이전트 행동이 없는 경우, :436-438은 불법 행동인 경우입니다. 기록을 읽으면 다른 정보와 비교하지 않아도 대체된 수와 모델이 고른 수를 구분할 수 있습니다.

2. 경기를 점수 산정에서 제외합니다. 확인했습니다. 같은 실행 결과에는 match_valid_for_scoring: false, integrity_status: "invalid", invalid_reason_codes: ["agent_error", "provider_timeout", "fallback_action_used"], fallback_action_count_by_player: {"player_1": 4}가 들어 있습니다. 평가 대상 좌석에서 4턴 동안 4번 대체 수가 나왔습니다. --require-scoring-valid 옵션을 준 CLI는 종료 코드 1로 끝납니다.

제가 짚고 싶은 부분은 공개 데이터에서 이 조건이 결과를 읽는 필드에 반영되지 않는다는 점입니다. 해당 실행의 public/public_result_summary.json은 여전히 outcome에 reason: "three_in_a_row", winner: "player_1"을 표시하고 score에는 primary_score: 1.0, player_1의 점수 1.0, player_2의 점수 0.0을 표시합니다. score.json에는 best_score: 1.0과 confidence_interval: [1.0, 1.0]이 나옵니다. 합법적인 행동을 한 번도 내지 않은 좌석이 삼목을 만들어 1.0 대 0.0으로 이긴 것처럼 기록되고 구간도 단일 값으로 표시됩니다. 자격을 박탈하는 valid_for_scoring: false와 per_case_scoring_eligible: false도 같은 객체에 있어 정보가 숨겨진 것은 아닙니다. 하지만 관전자나 후속 시스템이 먼저 확인하는 winner와 score는 조건 없이 표시되므로 누가 이겼고 얼마나 잘했는지에 대해 실제와 반대되는 답을 줍니다. 이를 설명할 agent_error_count_by_player와 fallback_action_count_by_player는 비공개 score.json에만 있습니다. 게시물에서 말한 문제, 즉 최종 점수만으로 나쁜 수와 쓸 수 없는 응답을 구분하지 못하는 일이 여기서 발생합니다. valid_for_scoring이 false면 outcome과 score를 표시하지 않거나 scoring_safety_reason과 함께 null로 처리할 수 있습니다. 또는 공개 행에 폴백 및 에이전트 오류 횟수를 추가하면 관전자가 승자가 실제로는 플레이하지 않았다는 점을 알 수 있습니다. 공개 화면을 점수 산정이 무효인 경우에도 단순 경기 기록으로 유지하려는 설계인지, 아직 공개 데이터 변환을 다듬지 않은 것인지 궁금합니다.

• @jabinpou — 대체 수와 유효한 점수 산정을 분리한 경계는 유용합니다. 그래도 승률 옆에 점수 산정에서 제외된 경기 비율을 보여주겠습니다. 응답을 제대로 낼 때만 경기를 잘하는 모델이 매번 안정적으로 경기를 마치는 모델과 똑같아 보이면 안 됩니다.

원문: dev.to / 번역·요약: Trawling