LabyrinthBench는 긴 에이전트 실행(agent runs)을 실제로 망가뜨리는 요소, 즉 모델이 20턴 전에 학습한 내용을 여전히 사용할 수 있는지 여부를 LLM 심판(LLM judge) 없이, 여러분의 자체 하드웨어에서 결정론적(deterministically)으로 측정합니다. 또한 여러분이 문제를 해결할 수 있다고 생각하는 어떤 컨텍스트 관리 전략(context-management strategy)이라도 테스트할 수 있도록 교체 가능한 하네스(harness)를 제공합니다. 첫 번째 등록된 실험 결과는 양방향 모두에서 저를 놀라게 했습니다. 7개의 모델 성능을 높였던 동일한 컨텍스트 트릭이 2개의 모델은 망가뜨렸기 때문입니다. 단 두 개의 명령어와 브라우저 탭 하나면 여러분의 장비에서 실시간 실행이 가능합니다. 그리고 리더보드(leaderboard)도 있습니다. 전략의 장은 열려 있으며, 누군가 제 기록을 깨는 것을 보고 싶습니다. 유의미한 시간 동안 AI를 사용해 본 사람이라면 거의 누구나 이런 시나리오를 겪어보았을 것입니다. AI와 함께 멋진 계획을 세우고 거의 다 실행해 가는데, 컨텍스트 제한(context limit)에 부딪히는 상황 말입니다. 마지못해 "압축(compact)" 또는 그에 상응하는 조치를 취하고 계속 진행하지만, 압축 과정에서 핵심적인 정보가 제거되면서 결국 모든 것이 궤도를 벗어나게 됩니다. "솔직히 말씀드릴게요. 당신이 명시적으로 그렇게 하지 말라고 했는데 제가 그냥 해버렸습니다." 이는 불행히도 흔한 사용자 경험이며, 개인적으로는 그 결과로 인해 키보드를 얼마나 멀리 던질 수 있을지 시험해보고 싶게 만듭니다. 저는 거기서 실제로 무슨 일이 일어나고 있는지 객관적이고 결정론적으로 측정하고 싶었습니다. 그리고 저는 현재 AI를 벤치마킹하기 위해 다른 추론 엔티티(reasoning entity)가 점수를 매기고, 등급을 매기고, 심판해야 한다는 사실을 정말 싫어합니다. 우리는 교실과 실험실 모두에서 표준화되고 객관적인 채점 방식을 구축하기 위해 문자 그대로 수십 년(혹은 수 세기)을 보냈습니다. 적절한 방식으로 적절한 질문을 던지고 확률적 출력(probabilistic output)을 기대한다면, 심판은 전혀 필요하지 않습니다. 무언가를 객관적이고 결정론적으로 측정할 방법이 있다면, 왜 우리가 주관적이고 확률적인 측정에 안주해야 할까요? 그래서 저는 모델을 미로에 넣고 탈출구를 찾으라고 명령했습니다.

미로 그 자체는 새로운 것이 아닙니다. 내비게이션 (Navigation)을 결정론적으로 점수가 매겨지는 간단한 질문들 및 다양한 컨텍스트 관리 (Context-management) 전략과 결합하면, 정말 흥미로운 결과들이 나타나기 시작합니다. 처음에는 미로가 먼저였습니다. 막다른 길, 루프 함정(Loop trap), 하나의 출구가 있는 구조였으며, 'Calculate: 38 + 17'이나 'Evaluate: NOT(FALSE OR FALSE)'와 같은 간단한 독립형 게이트 (Gate)들이 포함되었습니다. 작동은 했지만, 메모리 (Memory)가 테스트되기도 전에 내비게이션이 작은 모델들을 압도해 버렸습니다. 그래서 모델의 내비게이션을 돕기 위해 더 큰 하네스 (Harness)를 구축하는 대신, 일단은 내비게이션을 완전히 제거했습니다. 두 번째 맵 계열은 질문들이 사슬처럼 이어지는 직선 형태의 20개 게이트 복도입니다. 게이트 1은 'Calculate 3 + 4'이며, 후반부에 이르면 '이전 게이트의 답에서 c1b 답을 빼세요'와 같은 게이트가 등장합니다. 즉, 모든 후속 게이트는 특정 이전의 답을 참조하므로, 모델은 요청에 따라 자신이 수행한 모든 것을 회상 (Recall)해야 합니다. 그리고 깨끗한 회상이 여전히 쉬운 사례이기 때문에, 세 번째 계열은 당신의 등 뒤에서 값을 변경합니다. 변수 A가 3으로 초기화됩니다. A의 값은 무엇입니까? … 그러고 나서, 나중에 나오는 게이트에서 E가 변경됩니다: 이제 E는 4입니다 … 그 후 중간에 변화가 생긴 상태에서 이미 답변했던 것과 동일한 질문이 나옵니다. 재계산하십시오, 재사용하지 마십시오. 내비게이션(Navigation) → 유지(Retention) → 최신성(Currency). 각 맵은 이전 맵이 던진 질문에 답을 내놓았기에 존재합니다. (모든 계열의 샘플 질문: https://labyrinthbench.ai/data/questions — 출시된 맵들은 공개 연습 세트이며, 경진대회 인스턴스들은 시즌마다 새롭게 생성되어 봉인됩니다.) 첫 번째 실험: 20개 게이트 복도에서 13개의 로컬 모델을 대상으로 두 번의 테스트를 수행했습니다. 한 번은 전체 채팅 기록을 유지한 상태로, 다른 한 번은 매 턴마다 컨텍스트를 삭제하고 모델이 기록한 게이트 답변만을 다시 주입 (Re-inject)한 상태로 진행했습니다. 조건당 모델별로 6번의 실행을 수행했으며, 통과 기준(중앙값 깊이가 5개 이상의 게이트를 더 통과함)은 컨텍스트 삭제 실행이 존재하기 전에 고정되었습니다.

https://preview.redd.it/gdyyt3h33yhh1.png?width=1280&format=png&auto=webp&s=8d50e9d21f518bae1669a8aac353c77cfc644f67 Wiping(컨텍스트 삭제)은 성능 향상을 보여줄 여지가 있었던 9개 모델 중 7개에서 승리했으며, 나머지 2개에서는 역효과를 냈습니다. (이미 실행된 13개 중 나머지 4개는 맵의 한계치(ceiling)에 도달하여 성능 향상을 보여줄 수 없었습니다. 이들은 별도의 등록된 후속 연구가 있으며, 해당 요약은 데이터 부록(data annex)에 있습니다.) deepseek-r1:70b는 중앙값(median)이 1에서 20으로 상승했습니다. 6번의 대조군(control) 실행 중 5번이 정확히 하나의 게이트만 통과했으나, Wiping을 적용하자 6개 게이트를 모두 통과했습니다. glm-4.7-flash와 qwen3:14b는 모두 중앙값이 15.5 게이트만큼 상승했으며, 7개의 승자 중 4개는 실행 성공률이 033%에서 83100%로 뛰었습니다. Wiping은 qwen3:14b를 중앙값 20/20으로 끌어올렸는데, 이는 이 맵에서 도움 없이 120B급 모델들이 차지하는 것과 동일한 한계치입니다. 두 가지 역전 사례는 다음과 같습니다: llama3.3:70b는 중앙값이 15에서 9로 하락했고, llama4:scout는 10에서 7로 하락했습니다. 파라미터 수(Parameter count)는 성능 변화의 방향을 예측하지 못합니다. 가장 큰 수혜를 입은 모델과 가장 큰 손해를 본 모델 모두 70B 모델입니다. 그중 한 모델의 추적(traces) 결과는 그 이유를 설명해 줍니다: 재주입된 답변(re-injected answers)에 이미 실패했던 내용에 대한 기록이 포함되어 있지 않으며, llama3.3:70b는 Wiping이 적용된 모든 실행에서 동일한 오답을 재제출하며 4개의 생명을 모두 소진합니다. 히스토리(history)가 온전히 유지될 때는 결코 그런 행동을 하지 않습니다. 비용 또한 측정되었습니다. 승자 모델들은 게이트당 턴 수(turns-per-gate)를 대조군 대비 0.11~0.42배로 줄였으나, 한 모델은 깊이(depth)를 얻기 위해 출력 토큰(output tokens)을 21배 더 소모했습니다. 그리고 발견이라기보다는 하나의 주의 사항(flag)으로 전달할 것이 하나 더 있습니다: --look-gate 옵션입니다. 모델에게 답변하기 전에 관찰하라고 말하는 것은 거의 효과가 없었지만(중앙값 4.5 → 5.5, 오차 범위 내), 강제적으로 관찰하게 했을 때는 추측 없이도 동일한 모델이 21+까지 도달했습니다 — 상세 내용은 데이터 부록에 있습니다. 이 부분은 여전히 저를 조금 놀라게 합니다. 클라우드 모델은 API 키가 필요하며, 현재로서는 앞에 프록시(proxy)를 두어야 합니다(FAQ 참조). 리더보드에 실행 기록을 등록하려면 git이 필요합니다. 비표준 설치의 경우 .env 수정이 필요할 수 있습니다. 하지만 모델을 로컬에서 실행하며 단순히 본인의 로컬 모델 성능이 어떤지 확인하고 싶다면? 계정을 만들 필요도, API 키나 git, .env 수정이 필요하지도 않습니다.

AI 모델을 실행할 수 있는 하드웨어와 LB docker compose 파일만 있으면 됩니다. 제가 제공하는 삭제 정책(wiping policy)이 모든 곳에서 승리하지는 않는다는 점을 입증해 보였습니다. 누군가가 자신만의 하네스(harness)를 사용하여 저의 시도를 뛰어넘기를 기대하고 있습니다. 저 또한 여기저기 몇 가지 개선 사항에 대한 아이디어를 가지고 있습니다. 단 한 번의 운 좋은 실행으로 순위표(board)를 차지할 수도 없습니다. 순위는 보수적인 통계적 경계(중앙값 깊이에 대한 단측 95% 부트스트랩 하한 신뢰 구간)이므로, 순위를 올리는 것은 분산(variance)이 아니라 증거(evidence)입니다. 저장소(repo), 전체 요약(full briefs), 잠금 날짜가 명시된 사전 등록(pre-registrations), 원시 실행 로그(raw run logs), 그리고 순위표까지 모든 것이 공개되어 있습니다. 저장소: https://github.com/owl-fleet/labyrinth-bench · 순위표: https://labyrinthbench.ai · 데이터: https://labyrinthbench.ai/data /u/jwdeaver 제출 [link] [comments]