Remove pgrust: the entry is cheating
pgrust를 ClickBench에서 제외해야 합니다: 제출물이 벤치마크 규칙을 어겼습니다
ClickBench의 pgrust 0.4-preview 제출물에 쿼리별 최적화 코드와 결과 재사용 캐시가 포함됐다는 이유로 제외 요청이 제기됐습니다. pgrust 제작자는 해당 코드는 실행되지 않았고 캐시는 사전 계산 결과가 아닌 중간 데이터용이라며 반박했지만, 제한된 SQL 지원 상태로 제출한 점은 인정했습니다.
- 주제
에디터 노트
쟁점은 커널 파일이 저장소에 있다는 사실보다 제출 바이너리가 실제로 어떤 경로를 실행했고 캐시가 무엇을 저장했는지입니다. 요청자는 쿼리별 커널과 결과 재생을 주장하고, 제작자는 커널은 벤치마크 실행에 쓰이지 않았으며 캐시에는 딕셔너리 조건 판정만 담겼다고 설명합니다. 제공된 자료만으로는 양쪽 설명을 대조해 판정할 바이너리 해시나 독립 검증 결과가 확인되지 않습니다. 제작자가 좁은 SQL 지원 범위로 제출한 점을 인정한 만큼 제출의 적절성 문제는 남습니다. 반면 캐시가 허용된 중간 데이터인지 쿼리 결과 재사용인지는 벤치마크 공정성에 직접 영향을 주므로 두 설명을 같은 사실처럼 취급하기 어렵습니다. 댓글의 AI 코딩 비판은 이 사건의 실행 경로를 입증하지 않으며, 제작자가 제안한 바이너리 대조가 실제로 이뤄졌는지도 자료에는 나오지 않습니다.
AI 요약
ClickBench에 등록된 pgrust 0.4-preview를 제외해 달라는 pull request가 올라왔습니다. 요청자는 제출 바이너리에 벤치마크 쿼리마다 손으로 작성한 커널이 들어 있고, 필터 판정 결과를 쿼리 사이에 캐시해 데이터에 접근하지 않고 이전 실행 결과를 재생한다고 주장합니다. 벤치마크 쿼리를 조금 바꾸면 오류를 내며 거부한다는 지적도 덧붙였습니다.
제출물에 대한 주장
요청 내용에 따르면 바이너리에는 ClickBench의 37개 쿼리에 대응하는 q00.rs부터 q36.rs까지의 커널과 쿼리 이름을 딴 실행 계획 매처가 포함됐습니다. hot run에서 필터 판정을 재사용한다는 설명도 제시했습니다. 이를 근거로 제출물이 일반적인 쿼리 처리가 아니라 벤치마크에 맞춘 구현이라고 봤습니다.
pgrust 제작자의 반박
제작자 @malisper는 해당 커널이 IR 성능을 확인하려고 개발 중 작성한 코드이며 실제 0.4-preview 벤치마크 경로에서는 실행되지 않았다고 설명했습니다. 제출 바이너리는 SQL을 Gravity IR로 변환한 다음 x86 또는 ARM 어셈블리로 컴파일해 실행했다는 주장입니다. 문제의 캐시는 사전 압축된 딕셔너리에서 문자열별 조건 일치 여부를 저장하는 중간 데이터 캐시이며, 쿼리 결과를 저장하는 캐시가 아니라고 반박했습니다. ClickBench 규칙은 중간 데이터를 보관하는 캐시를 허용한다고 덧붙였습니다.
다만 제작자는 0.4-preview가 ClickBench 쿼리 일부만 처리하는 초기 버전이었다는 점은 인정했습니다. 이전 쿼리 엔진으로 되돌아가는 코드가 있었다면 더 많은 쿼리를 처리할 수 있었지만, 새 엔진이 벤치마크 쿼리를 지원하자 제출을 서둘렀다고 설명했습니다. 새 0.4-beta는 CTE와 MERGE 관련 일부 버그를 제외하면 PostgreSQL SQL 전반을 지원한다고 밝혔습니다. 제출 당시 더 넓은 SQL 범위를 확인했어야 했다는 점도 인정했습니다.
Hacker News 반응
- @malisper — 제작자는 직접 해명하면서, ClickHouse가 테스트한 바이너리의 SHA를 제공하면 보관 중인 바이너리와 일치하는지 확인할 수 있다고 말했습니다. 다만 제출 당시 바이너리가 정확히 그 파일이었다고 증명할 방법은 없다고 덧붙였습니다.
- @philipwhiuk — PGRUST_GRAVITY_Q20_VARIANT가 무엇인지 물었습니다.
- @malisper — 내부 벤치마킹에 쓰던 기능 플래그이며 SQL을 실행할 때는 작동하지 않는다고 답했습니다.
- @jimmydoe — 해명에 감사하며 먼저 바이너리가 일치하는지 확인해 보자고 했습니다.
- @acalvino4 — 벤치마크 오류나 오해는 AI 시대 이전에도 있었고, 저자가 문제를 인정하고 수정하려는 점이 중요하다고 했습니다. 이번 논의가 AI 생성 프로젝트에 대한 기존 반감으로 흐른다고 지적했습니다.
- @hmry — 저자가 문제를 인정했다는 표현을 뒷받침할 내용은 보이지 않는다고 반박했습니다.
- @bmacho — 벤치마크 결과가 무작위화되지 않았고 어딘가에서 캐시된 결과를 반환한다는 의견을 내며, 일부 벤치마크는 무작위 데이터로 실행해야 한다고 했습니다.
- @chuckadams — AI가 작업자를 대신해 의도적으로 속임수를 쓴다는 주장에는 동의하지 않지만, pgrust 벤치마크에서는 사람이 명백한 편법을 제출했다고 봤습니다. 자신이 만든 AI 보조 프로젝트에서는 테스트가 실제로 실패하는지 확인하는 절차를 두었지만, 테스트 체계가 지나치게 복잡하고 취약해져 직접 단순화해야 했다고 경험을 전했습니다.
- @jerf — 기존 코드보다 훨씬 빠른 AI 작성 코드라면 벤치마크에 맞춘 최적화 가능성을 의심해 볼 만하다고 했습니다. 단위 테스트가 있어도 벤치마크에 맞춰 동작하는 코드를 막지 못할 수 있다고 덧붙였습니다.
원문: GitHub, ClickBench pull request #2165 / 번역·요약: Trawling