AI 벤치마크를 매일 발견하고 점수의 출처까지 검색하는 살아있는 데이터베이스

무엇인가

이 논문이 다루는 문제는 AI 연구자와 개발자가 특정 능력을 평가하는 벤치마크를 찾고, 그 데이터셋과 코드를 확보하고, 보고된 점수가 어떤 설정에서 나온 것인지 이해하기 어렵다는 점이다. 기존 LLM Stats, OpenCompass, Artificial Analysis 같은 자원은 리더보드나 평가 플랫폼, 모델 분석을 제공하지만, 새로 나온 벤치마크를 과제 자료와 이후 모델 보고서에서의 사용 사례에 연결하려면 여러 자원을 따로 확인해야 한다. Benchmark Radar는 카탈로그 검색, 일일 발견, 모델 보고서 언급, 문서화된 평가 설정과 출처가 있는 점수 이력을 한 시스템에 결합해 이 간극을 메우려 한다.

어떻게 동작하나

시스템은 BuilderPulse의 일일 공개 소스 수집 접근을 차용해 벤치마크 카탈로그와 발견 이력을 분리한다. v0.11.0 카탈로그는 네 소스로 구성된다. LLM Stats 687행, OpenCompass Hub 461행, Artificial Analysis 25행, 모델 보고서 110행이며 총 1,283개 소스 레코드다. 모델 카드, 기술 보고서, 시스템 카드, 릴리스 포스트는 벤치마크 레지스트리와 같은 레코드 구조로 기여한다. 일일 발견은 48시간 창을 검색하고 소스별 수집 수와 오류를 기록하며 미래 날짜 행을 제거하고 핵심 소스가 건강할 때만 발행한다. 컷오프 시점의 핵심 소스는 arXiv, Hugging Face Hub, GitHub Search였고, 13개 직접 커넥터와 24개 자체 연구·엔지니어링 피드, 총 37개 소스가 동원된다. 발견 관측은 벤치마크 카탈로그 총계에 더하지 않는다.

무엇과 다른가

레코드 보존과 검색은 비교 가능성을 해치지 않도록 설계됐다. 소스 레코드는 한 기여 소스의 한 벤치마크 항목이며, 이름·식별자·아티팩트 링크·점수 관측·모델 정체성·인용 문서를 공통 필드로 정규화한다. 점수나 날짜, 인용이 없어도 레코드는 카탈로그에 남고, 검토된 정체성 링크는 관련 레코드를 연결하되 별도 관측과 카운트를 보존한다. 검색은 BM25F 필드 가중 단어 매칭을 쓰고 이름과 구문 일치에 제한적 부스트를 준다. 각 결과는 일치·누락된 질의어, 해당 필드, 점수 구성요소를 노출하며 소스 소속은 순위를 바꾸지 않는다. CLI는 benchmark-radar init과 sync로 데이터 아카이브를 내려받고 갱신하며 SHA-256 체크섬, 스키마 버전, 출처를 로컬 매니페스트로 검증한다. catalog, radar, all 범위 검색과 모달리티·개방성·소스·논문/저장소/데이터셋 링크 유무 필터를 지원하고, --json으로 버전이 있는 응답을 출력한다. npx skills add ktwu01/benchmark-radar 형태의 에이전트 스킬도 제공한다.

어떻게 쓰나

전체 카탈로그 감사 결과는 수치로 제시된다. 1,283개 소스 레코드 중 790개 레코드에 12,916개 수치 점수 관측이 있고 493개는 수치 점수가 없다. LLM Stats는 687개 중 679개가 점수 보유, 5,544개 관측, OpenCompass Hub는 461개 전부 무점수, Artificial Analysis는 25개 전부 점수 보유, 7,050개 관측, 모델 보고서는 110개 중 86개 점수 보유, 322개 관측이다. 무점수 493개 중 464개는 최소 하나의 논문·저장소·데이터셋 링크를 가진다. 전체 카탈로그에서 논문 링크 475개, 저장소 링크 506개, 데이터셋 링크 293개가 있다. 분류는 1,283개 중 1,279개를 11개 상위 도메인과 63개 하위 도메인으로 나누며, 나머지 4개 LLM Stats 커뮤니티 행은 설명·카테고리·모달리티가 없어 제목으로 분류하지 않는다. 상호작용 패러다임과 입력 모달리티는 도메인 옆의 facet으로 기록해 중복 집계를 피한다. 345개 에이전트 레코드 중 128개는 Agentic & Tool Use, 117개는 Coding & Software Engineering에 속해 단일 축 분류라면 117개가 숨겨진다. 릴리스 날짜가 있는 레코드는 615개뿐이고 668개는 날짜가 없다. 에이전트 비중 상승은 연도별 소스 구성을 공통 구성으로 재가중해도 최대 1.1%포인트만 움직여 카탈로그 구성 변화의 인공물이 아니라고 주장한다.

전제와 한계

일일 발견 컬렉션은 46개 스냅샷에 11,068개 관측과 정확 식별자로 연결된 6,546개 아티팩트를 담는다. 4개 스냅샷은 시뮬레이션된 역사 백필이라 날짜가 재구성된 수집 창을 뜻한다. 5개 발견 소스 라벨이 11,068개 중 9,743개, 88.0%를 차지한다. 6,546개 아티팩트 중 59개만 여러 소스에서 관측됐고, 식별자 누락이나 불일치가 교차 소스 매칭을 막을 수 있다. 워크드 예제에서는 새 평가를 설계하기 전에 2026년 8월의 에이전트 학습 credit assignment 연구를 조사했고, 작은 Qwen 계열 모델을 재현 가능한 베이스라인 요건으로 삼았다. 기여자는 Benchmark Radar 클라이언트와 공개 Skill을 설치해 코퍼스를 내려받고 로컬 검색한 뒤 논문·저장소·데이터셋 링크를 확인하고, 다른 용어로 설명된 연구를 웹 검색으로 보완하고, 원문 증거를 읽어 Table 4의 관련 연구 표를 만들었다. 표에는 SRPO, ContextPilot, SkillGate, CIPO, MoRSE 같은 5개 작업이 Qwen 베이스 모델, credit-assignment 초점, 사용된 에이전트 벤치마크와 함께 정리됐다. 이 워크플로는 후보 검색과 적합성 판단을 분리한다. Benchmark Radar는 후보와 증거를 제공하고, 연구자나 에이전트가 관련성과 설계 중복을 판단한다.

개발자에게 이 논문은 새 평가를 만들기 전 prior art를 확인하고, 모델 카드나 기술 보고서에서 특정 벤치마크가 어떻게 쓰였는지, 점수 이력과 평가 설정, 데이터셋·코드 링크를 한곳에서 추적하는 실무 도구로 의미가 있다. 웹 대시보드는 리더보드, 점수 대 측정 사용량의 파레토 프런티어, 포화·추세 뷰, 일일 피드, 다운로드 가능한 증거를 제공하고, CLI와 JSON 응답은 CI나 에이전트 워크플로에 통합할 수 있다. 다만 점수를 비교할 때는 선언된 퍼센트 단위, 점수 방향, 0~100 범위 같은 조건을 확인해야 하며, 스케일이 같다고 해서 테스트 버전·프롬프트·도구·시도 횟수·평가자가 같다는 뜻은 아니다. 점수 항목의 날짜도 평가 날짜가 아니라 모델 발표나 문서 출판일일 수 있으므로 그대로 평가 시점으로 대체하면 안 된다.

저자들이 밝힌 한계는 분명하다. 이 감사는 기록된 컷오프 시점의 카탈로그를 설명하며 수집 한계, 실패한 요청, 누락된 식별자, 서로 다른 스냅샷 날짜가 커버리지에 영향을 준다. 소스 레코드는 고유한 실제 테스트의 개수가 아니다. 검색 정밀도, 과제 적합성, 절약된 시간은 아직 평가되지 않았고 워크드 예제도 통제된 베이스라인이 없다. 어휘 기반 BM25F 검색은 패러프레이즈나 이름이 바뀐 과제를 놓칠 수 있어 의미 검색 평가에는 검토된 관련성 판단이 필요하다. arXiv 발견 경로는 새 제출만 수집하고 이전에 게시된 논문의 새 버전이 나와도 백필하지 않는다. 실제로 Section 2의 검색은 관련 선행 연구 두 편을 놓쳤고 공저자가 찾아 읽었다. 포화나 점수 정체를 측정하려면 비교 가능한 테스트 버전과 설정, 점수 보고나 평가에 묶인 날짜가 필요하다. 태스크-능력 분류도 이번 재구축에서 검증되지 않았으며, CI의 결정적 null 추출기는 5,863개 발견 유래 트랙에 능력 레벨을 부여하지 않는다. 이 라벨을 완성하고 평가하는 일은 벤치마크 카탈로그 유지와 별개의 과제다.