Executive Summary

주요 수치

출처: Podstawski, Auditing a Model-Hub Benchmark, arXiv:2611.03727(2026)

허깅페이스에는 모델과 데이터셋과 Space가 수십만 개 올라와 있고, 사용자는 마음에 드는 것에 좋아요를 누른다. 난징대 연구진은 2024년 12월에 이 허브를 크롤링해 노드 260만 개와 엣지 620만 개짜리 관계망 HuggingKG를 만들고, 그 위에 세 가지 시험을 얹었다. 사용자에게 다음 자원을 추천하기, 모델이 어떤 과업용인지 분류하기, 파생 모델이 어느 모델에서 나왔는지 추적하기. 이 시험 묶음이 HuggingBench이고, SIGIR 2025에 실렸다.

이번 감사가 집중한 것은 첫 번째 시험이다. 사용자 38,624명이 항목 25,080개에 누른 좋아요 106만 건을 훈련·검증·시험으로 나누고, 추천 방법 열한 가지의 성적을 Recall@10으로 비교한다. 상위 열 개를 추천했을 때 실제로 누른 항목을 얼마나 담아냈는지 보는 지표다. 항목은 모델 16,200개와 데이터셋 3,634개와 Space 5,246개로 이뤄져 있다. 열한 가지 가운데 세 가지는 좋아요 기록만 보지 않고 항목끼리의 관계망까지 함께 읽는 지식그래프 기반 추천이라, 벤치마크는 외부 관계망 네 벌을 따로 배포했다.

네 벌은 성격이 다르다. 항목과 항목만 이어 붙인 동종 그래프 하나, 허브 전체 관계망에서 항목 주변 한 걸음만 떠낸 1홉 그래프, 두 걸음까지 떠낸 2홉 그래프, 그리고 누가 올린 자원인지로 묶은 퍼블리셔 그래프다. 원 논문이 보고한 최고 성적은 동종 그래프를 쓴 KGCL의 0.1578이었다. 한편 KGIN이라는 방법은 어떤 설정에서도 거의 0에 가까운 점수를 받았는데, 논문은 그것을 그대로 결과로 실었다.

감사는 그 숫자들을 먼저 그대로 다시 냈다. 공개된 설정 파일과 격자를 손대지 않고 열한 가지를 모두 돌려 보니 LightGCN과 DCCF는 보고된 여덟 개 값을 소수점 넷째 자리까지 똑같이 냈고, 나머지도 2홉 관계망의 KGCL 한 칸을 빼면 Recall@10 0.0010 안쪽에서 맞았다. KGIN의 0.0004도 그대로 재현됐다. 보고된 숫자는 공개된 코드가 공개된 데이터 위에서 계산한 값을 정확히 적은 기록이다. 남는 물음은 그 값이 무엇을 재고 있었느냐다.

추천기가 관계망을 읽을 때는 좋아요 파일의 항목 번호를 그대로 들고 건너간다. 항목 17166의 추천 근거를 찾으려면 관계망에서 엔터티 17166이 가진 사실을 긁어 온다. 번호가 같으면 같은 대상이라는 뜻인데, 이 약속은 어느 파일에도 적혀 있지 않다. 이 분야에서 오래 쓰여 온 구현 관행이고, 항목이 엔터티 가운데 앞에서부터 번호를 받는다는 전제 위에 서 있다. 두 파일을 번호로 맞붙이는 이 대목을 데이터 쪽에서는 조인이라고 부른다.

동종 그래프에서는 약속이 지켜졌다. 나머지 셋에서는 깨졌다. 1홉과 2홉 그래프에서는 항목 25,080개 가운데 좋아요 파일과 같은 번호를 쓰는 것이 하나도 없었고, 퍼블리셔 그래프에서는 넷뿐이었다. 두 그래프는 항목에 관한 사실을 이어 붙이는 끝점을 각각 767,927개씩 갖고 있는데, 그중 제 항목에 닿은 것이 하나도 없다. 사실을 하나라도 바르게 받은 항목도 없다. 1홉에서는 117,260개가, 2홉에서는 99,312개가 자기를 설명하지 않는 다른 항목에 가서 붙었고, 나머지는 항목이 아닌 엔터티 쪽에 떨어졌다. 떨어져 나간 자리에는 파인튜닝·양자화·어댑터·머지로 모델 사이의 계보를 적어 둔 끝점 278,358개가 통째로 들어 있다. 허브에 거의 같은 모델이 여러 벌 올라와 있는 구조를 설명하는 바로 그 사실들이다.

그런데 각 파일은 멀쩡했다. 저자가 돌린 단일 파일 검사 34개를 전부 통과한다. 키가 유일한지, 값이 범위 안에 있는지, 훈련과 시험이 섞이지 않았는지를 보는 검사들이다. 항목 이름 목록도 엔터티 이름 목록도 각자 안에서는 흠이 없었기 때문이다. 오류는 두 목록을 이름으로 맞춰 보는 순간에만 모습을 드러낸다. 저자는 그 대조 한 줄을 검사 코드에 넣으면 몇 초 만에 잡힌다고 적었다.

어쩌다 이렇게 됐는지는 배포 파일의 구조를 보면 짐작이 간다. 같은 좋아요 기록이 여섯 벌의 파일 묶음으로 들어 있고, 묶음마다 번호 체계가 따로 돈다. 관계망 묶음 둘을 아무렇게나 골라 비교해도 항목 25,080개 중 최소 25,077개가 서로 다른 번호를 달고 있는데, 묶음 사이를 잇는 매핑은 배포되지 않았다. 이름으로 맞춰 보면 네 묶음의 분할 내용은 전부 같다. 같은 데이터를 관계망마다 번호를 새로 매겨 내보냈을 뿐이고, 읽는 쪽은 번호가 같으면 같은 것이라고 믿었다.

결과는 모델 하나만 따라가 봐도 선명하다. SmolLM2-1.7B-Instruct는 좋아요 파일에서 항목 17166이다. 1홉 관계망에서 이 모델은 엔터티 366541이고, 사실 153개를 달고 있다. 그 가운데 하나가 SmolVLM-Instruct와의 양자화 관계다. 추천기는 이 사실을 받지 못했다. 번호를 따라 엔터티 17166으로 갔고, 거기 있던 것은 dpbos/postvalidation이라는 Space와 그에 딸린 사실 한 개였다.

보정 자체는 단순하다. 모든 항목이 좋아요 파일에서 쓰던 번호를 관계망에서도 그대로 쓰도록 다시 매기고, 나머지 엔터티를 그 뒤로 밀었다. 사실은 한 건도 더하거나 빼지 않았다. 저자는 보정판 파일과 매핑, 검증기, 실행 로그를 Zenodo에 통째로 올려 두었다. 그 위에서 같은 방법들을 시드 세 개로 다시 돌린 결과가 아래다.

시험 분할 Recall@10, 세 시드 평균, 100에폭 예산. 출처: 논문 Table V 전체. 보정 대상이 아닌 동종 그래프의 참고값은 KGCL 0.1585, KGRec 0.0987, KGIN 0.1351이다. KGIN은 원저자 구현 기준. 변화 칸은 표에 적힌 반올림값으로 계산한 것이라, 논문이 반올림 전 값으로 보고한 4%에서 73%라는 범위와 끝자리가 다를 수 있다.

내려간 칸은 없었다. 모든 관계망, 모든 시드, 모든 방법에서 보정판이 더 좋았고 상승폭은 4%에서 73% 사이였다. 가장 적게 오른 쪽이 KGCL, 가장 크게 오른 쪽이 KGRec이다. 설정끼리 누가 앞서는지를 견준 27개 비교 가운데 10개는 세 시드 전부에서 순서가 뒤집혔다. 원 논문에서 KGIN이 배포된 2홉 관계망으로 KGRec을 앞섰던 대목은 보정판에서 뒤처지는 쪽으로 바뀐다. 어떤 방법이 더 나은가라는 물음의 답이 데이터 보정 하나로 달라진 것이다.

저자는 보정이 건넨 것이 제 사실인지 사실 비슷한 무엇인지를 따로 시험했다. 보정된 1홉 관계망에서 항목과 엔터티의 짝을 항목 종류와 연결 수를 맞춰 무작위로 다시 지어 보면, 바르게 맞춘 쪽이 어떤 무작위 짝짓기보다 좋았다. 그런데 그 무작위 짝짓기들도 아홉 번의 실행 전부에서 배포판보다는 좋았다. 종류와 연결 수만 그럴듯해도 어느 정도는 오른다. 끝까지 올리는 것은 제 항목에 제 사실이 붙는 일이다.

KGIN의 거의 0점은 조인 오류만으로 설명되지 않는다. 저자가 들여다보니 벤치마크가 쓴 프레임워크의 KGIN 이식본은 임베딩을 GPU에서 학습하지 않았고, 이 결함은 데이터와 상관이 없다. 그래서 KGIN은 원저자 구현으로 바꿔 다시 돌렸다. 바꾼 구현에 배포판 1홉 관계망을 물리면 0.1169가 나오고, 거기에 보정까지 하면 0.1445가 된다. 원래 보고된 0.0004는 무작위로 세운 순위와 같은 수준이었고, 저자의 재현에서도 그대로 0.0004가 나왔다. 저자는 이 대목을 두고, 무작위 수준의 점수는 발견이 아니라 오류 신호로 다뤄야 한다고 적었다.

왜 아무도 눈치채지 못했는지는 항목을 인기순으로 갈라 보면 드러난다. 1홉 관계망에서 KGRec을 500에폭으로 돌린 경우, 훈련 구간에서 좋아요를 한 개에서 네 개 받은 항목은 어긋난 관계망에서 시험 좋아요의 0.004만 상위 열 개에 담겼다. 보정 뒤에는 0.020으로 다섯 배가 된다. 좋아요 20개에서 99개 구간도 0.011에서 0.040으로 올랐다. 그런데 좋아요 100개가 넘는 인기 항목에서는 0.148이 0.155가 됐을 뿐이다. 2홉 관계망에서는 인기 항목도 0.133에서 0.157로 절대값이 제법 올랐지만, 상대적인 크기로는 역시 가장 희귀한 쪽의 개선이 훨씬 컸다. 평균 Recall은 인기 항목이 끌고 가는 수치여서, 희귀한 쪽에서 벌어진 일이 집계에 거의 비치지 않았다.

희귀한 쪽이 작은 구석인 것도 아니다. 훈련 좋아요가 100개에 못 미치는 항목이 시험 좋아요의 54%를 받는다. 평균이 가린 것은 가장자리가 아니라 절반이었다.

감사는 벤치마크의 두 번째 결함도 함께 짚는다. 학습을 100에폭에서 끊는 예산이 조기 종료 조건보다 먼저 닿는 경우가 시드에 따라 29개 설정 중 일고여덟 개 있었다. 그렇게 잘린 설정-시드 쌍 23개 가운데 21개는 예산을 500에폭으로 늘리자 성적이 올랐고, 상승폭은 최대 31%였다. 두 결함은 서로 얽혀 있다. 어긋난 관계망으로 학습한 모델은 수렴이 느려서, 예산을 늘리면 보정의 효과가 조금 줄어든다. 73%라는 숫자에는 학습 부족분이 섞여 있다. 1홉 관계망의 KGRec만 놓고 보면 두 판 사이의 간격이 평균 0.0613에서 0.0374로 좁아진다. 그래도 모델 깊이 둘과 시드 셋을 합친 여섯 경우 전부에서, 두 예산 모두 보정판이 앞선다는 결론은 그대로 남는다.

HuggingBench는 항목마다 카드 텍스트를 함께 공개한다. 모델 카드와 데이터셋 카드 본문, 태그, 올린 조직과 이름, 라이브러리, 언어, 설명까지 최대 3,000자다. 원 논문이 보고한 열한 가지 방법 가운데 이 텍스트를 쓴 것은 하나도 없다. 저자는 이 공백을 겨냥해 가장 단순한 추천 모델을 가져왔다. 반복 학습 없이 한 번의 행렬 계산으로 끝나는 선형 모델 EASE다.

결과는 순서대로 읽을 만하다. 텍스트도 관계망도 없는 맨 EASE가 0.1684로 이미 원 논문 최고 보고값 0.1578을 넘었다. 정규화를 항목별로 조정한 변형이 0.1746, 거기에 항목 관계망을 더하면 0.1776이다. 관계망 대신 카드 텍스트를 단어 빈도 방식으로 넣은 쪽은 0.1846으로 더 높았고, 둘을 다 넣은 최고 구성이 0.1860이었다. 기존 최고값 대비 18%다.

비용 쪽이 더 당혹스럽다. 맨 EASE의 학습은 CPU 8코어에서 253초, 텍스트와 관계망을 다 넣은 최고 구성도 358초에 끝난다. 비교 대상인 KGRec은 2홉 관계망에서 설정을 다 훑는 데 GPU로 하루가 넘게 걸린다.

텍스트를 읽는 방식에서도 예상은 빗나갔다. 같은 카드 텍스트를 최신 임베딩 모델 두 종으로 벡터화해 넣어 봤더니, 네 번의 비교 전부에서 단어 빈도 방식이 더 좋았다. 차이는 0.0046에서 0.0077 사이였고 신뢰구간이 0을 품지 않았다. 저자는 허브 텍스트가 틀에 박혀 있다는 점을 이유로 든다. 같은 조직이 올린 모델 둘의 단어 빈도 유사도는 중앙값이 0.40이고, 무작위로 고른 두 항목은 0.03이다. 이름과 태그가 비슷한 문자열로 되풀이되는 데이터에서는 뜻을 넓게 잡는 임베딩보다 글자를 그대로 맞추는 쪽이 유리하다.

신호가 어느 칸에 들었는지도 뜯어 봤다. 항목 종류와 조직·이름만 남겨도 0.1850에 닿고, 설명문만 넣어도 맨 EASE보다 0.0134 오른다. 주소와 저장소 식별자와 제 조직·이름을 가려 설명문 19,191개 가운데 18,251개를 바꿔 놓아도 0.0125가 남는다. 같은 신호가 여러 칸에 겹쳐 적혀 있다는 뜻이다.

그리고 텍스트가 가장 크게 기여한 자리는 3절에서 보정이 가장 크게 작용한 자리와 겹친다. 좋아요를 한 개에서 네 개 받은 항목에서 맨 EASE는 0.0057이었고 텍스트와 관계망을 더하면 0.0339가 된다. 좋아요 100개가 넘는 인기 항목에서는 0.1976이 0.1949로 오히려 조금 내려갔다. 좋아요를 적게 누른 사용자 쪽도 같은 모양이다. 항목 종류로 갈라도 결이 같다. 카드가 있는 모델이 0.012로 가장 많이 올랐고, 카드가 아예 없는 Space가 0.005로 가장 적게 올랐다. 텍스트가 일을 하고 있다는 뜻이다. 어긋난 연결과 쓰지 않은 설명문은 서로 다른 결함인데, 벤치마크의 성적을 같은 자리에서 같은 방향으로 깎고 있었다.

나머지 두 시험에서 텍스트가 한 일은 서로 달랐다. 계보 추적에서 원 논문 최고 보고값은 구조만 보는 방법의 MRR 0.559, 저자의 재현값은 0.549였는데, 학습을 전혀 하지 않고 파생 모델의 카드 본문에 언급된 모델 이름을 등장 순서대로 세운 것만으로 0.542가 나왔다. 시험 트리플의 54.3%에서 정답이 카드 안에 이름으로 적혀 있었다는 뜻이다. 카드에서 뽑은 후보를 앞에 놓고 나머지를 기존 방법으로 세우면 0.831까지 간다.

반면 과업 분류에서는 카드만 읽는 방식이 통하지 않았다. 카드에 등장하는 과업 이름을 그대로 답으로 내놓으면 micro-F1 0.404에 그친다. 가장 흔한 과업 하나로 전부 찍는 0.384보다 조금 나은 수준이고, 보고된 0.885에는 한참 못 미친다. 대신 다른 것이 걸렸다. 모델의 과업 태그와 데이터셋의 과업 칸이 시험 항목의 99.99%에서 정답 이름을 그대로 적고 있었다. 공개된 분류기 코드가 없어 실제로 그 칸을 봤는지는 확인할 수 없지만, 벤치마크가 먼저 밝혔어야 할 통로다. 시험 항목 수가 배포본 27,345개와 논문 보고 28,682개로 어긋난다는 점도 감사가 함께 적어 두었다.

논문은 마지막 절을 벤치마크와 모델 허브를 만드는 쪽에 건네는 권고로 채웠다. 여섯 가지인데, 묶어 놓고 보면 요구는 하나다. 데이터를 묶어 내보내는 쪽이 그 묶음이 무엇을 약속하는지 파일 바깥에 적어 두라는 것이다.

• 파일이 아니라 조인을 검증한다. 오류는 파일 안이 아니라 파일 사이에 있었고, 검증기는 데이터와 함께 배포돼야 한다.
• 암묵적 관행보다 명시적 연결을 쓴다. 항목과 엔터티를 잇는 파일을 따로 요구하는 프레임워크에서는 이 실패가 구조적으로 나지 않는다.
• 모든 칸의 출처를 밝힌다. 언제 어떻게 수집했는지 적고, 시험 분할 정보가 섞일 수 있는 칸은 빼거나 훈련 구간에서 다시 계산한다.
• 프로토콜이 스스로 점검하게 한다. 설정마다 최고 성적이 몇 에폭에서 나왔는지 보고하고, 예산 끝에서 멈춘 학습에는 표시를 단다.
• 공개한 것을 실제로 쓰는 기준선을 넣는다. 곁들인 정보를 공개하는 벤치마크라면 그것을 쓰는 단순한 모델 하나는 기본으로 보고한다.
• 출처를 묻는 시험과 그 출처가 적힌 본문을 분리한다. 계보와 분류처럼 답이 카드에 적혀 있는 과업은 텍스트를 가리거나, 텍스트만으로 얼마나 풀리는지 먼저 보고한다.

세 번째 권고가 나온 자리도 이 벤치마크 안에 있다. 관계망에 저장된 좋아요·다운로드 카운터는 크롤링 시점의 값이라 시험 분할에 들어간 좋아요까지 품고 있을 수 있다. 실제로 항목 25,080개 중 25,057개에서 카운터가 세 분할의 좋아요 합계보다 적지 않았고, 시험 좋아요와의 순위 상관이 0.80으로 훈련 좋아요와의 0.71보다 높았다. 측정해 본 실제 영향은 작았지만, 영향이 작다는 것과 설계가 옳다는 것은 다른 말이다. 반대로 같은 절에서 무혐의로 끝난 것도 있다. 네 관계망의 관계 종류를 전부 훑어 봐도 사용자와 항목 사이의 좋아요가 관계로 들어간 경우는 없어서, 시험 좋아요가 관계망을 타고 새는 일은 일어나지 않았다.

이 실패가 HuggingBench 한 벌의 사고가 아니라는 증거도 논문 안에 있다. 어긋남을 허용한 파일 형식은 KGAT에서 내려온 것이고, 저자는 같은 형식으로 배포된 다른 데이터셋들을 같은 검사에 걸어 봤다. 항목을 앞에서부터 번호 매긴 배포본은 통과했다. 그런데 같은 데이터셋을 다른 팀이 번호를 새로 매겨 다시 배포한 경우에는, 먼저 나온 배포본의 항목 목록으로 읽었을 때 훈련 쌍의 0.7%와 2.4%만 제 항목을 지켰다. 배포본 하나하나는 그 자체로 멀쩡하다. 어긋남은 서로 다른 배포본의 파일을 섞는 순간에 생긴다.

여기부터는 논문 밖이다. 이 감사가 겨눈 구조는 벤치마크만의 사정이 아니다. 서로 다른 시스템에서 나온 테이블을 번호로 이어 붙여 학습 데이터를 만드는 곳이면 같은 일이 일어난다. 각 테이블은 스키마 검사를 통과하고, 적재 파이프라인은 초록 불을 켜고, 모델 성적은 그럭저럭 나온다. 어긋남은 두 테이블을 사람이 읽을 수 있는 이름으로 맞춰 볼 때만 보인다. 그 대조를 자동 검사에 넣어 둔 팀은 생각보다 적다.

그래서 세 가지는 물어볼 만하다.

• 우리 파이프라인의 조인 키는 무엇이 보증하는가. 스키마가 보증하는가, 아니면 아무 데도 적혀 있지 않은 관행이 보증하는가.
• 평균 지표가 가리는 구간은 어디인가. 희귀 구간을 따로 떼어 보지 않으면 정합성 오류는 평균 뒤에 숨는다.
• 우리가 수집해 놓고 한 번도 모델에 넣지 않은 칸은 무엇인가. 그 칸이 가장 센 신호일 가능성은 이 논문이 이미 한 번 보여 줬다.

여기까지 읽어 주셔서 감사하다. 원문은 arXiv:2611.03727에서 볼 수 있고, 보정 파일과 검증기는 Zenodo에 공개돼 있다. 조인 대조를 상시 데이터 검사로 이미 돌리고 있는 팀이 있다면, 어떤 방식으로 걸어 두었는지 들려주시면 좋겠다.

• 1.Podstawski, M. (2026). "Auditing a Model-Hub Benchmark: Data Quality, Training Budgets, and Side Information in HuggingBench." arXiv:2611.03727 [cs.LG].
• 2.Chen, Q., Huang, K., Zhou, X., Luo, W., Cui, Y., & Cheng, G. (2025). "Benchmarking Recommendation, Classification, and Tracing Based on Hugging Face Knowledge Graph." SIGIR 2025.
• 3.Podstawski, M. (2026). "Corrected HuggingBench knowledge graphs, mappings, validators, and logs." Zenodo.