AI가 TPC-H를 역설계하다: 22배 빨라진 데이터베이스의 민낯
Next-Level Benchmarking Overfitting – Thomas Neumann
GenDB-V는 Umbra와 DuckDB보다 22~61배 빠르다고 주장하지만, Thomas Neumann은 이것이 벤치마크 과적합의 극치라고 지적한다. 에이전트가 각 쿼리용 보조 구조를 미리 만들어 대부분의 작업을 회피하고, 심지어 dbgen의 키 배치 규칙까지 코드에 하드코딩했다는 것이다. 데이터 생성기의 우연을 데이터로 착각한 최적화는 실제 시스템에서는 단 하나의 튜플만 바뀌어도 무너진다.
AI 에이전트가 특정 데이터베이스 벤치마크에 맞춰 최적화하도록 두면 그 벤치마크는 무용지물이 된다. 에이전트는 이 특정 벤치마크를 빠르게 하려고 온갖 괴상한 꼼수를 찾아낼 것이고, 그중 어느 것도 실제 시스템에서는 통하지 않을 것이다.
HN 토론
13- lmeyerov
우리는 데이터프레임 위에서 오픈소스 벡터화 CPU/GPU cypher를 위한 GFQL을 에이전트 지원을 활용해 만들고 있습니다(그래프용 duckdb라고 생각하시면 됩니다, DB 필요 없음)... 그리고 우리 생각은 이것이 훨씬 더 공격적인 무언가로 가는 디딤돌이라는 것입니다.
오늘날 우리는 예전에는 유지보수하기에 너무 비쌌을 일부 패턴에 대해 핫패스 특화 최적화를 받아들입니다. LLM이 그 비용을 감당할 수 있게 유지해주고, 중요한 사용자(예: 우리 분석 제품 Graphistry 사용자)를 위해 그렇게 할 수 있다는 것은 초능력입니다. 그래프 커뮤니티 벤치마크에서 우리 점수는 큰 업체들을 이기고 있습니다. 그리고 중요한 것은, 우리가 신경 쓰는 모든 부분에서 그렇습니다.
우리가 정말로 그 방향으로 가고 싶은 곳은 런타임/로드타임 특화입니다. 우리 고객들은 분명히 자신들의 상위 쿼리가 자동 튜닝되기를 원할 것입니다. DB 연구는 이미 여기로 크게 기울고 있으며, 이는 10년 전 컴파일러 연구를 추적하는 것과 비슷합니다. 저는 지금 가능한 것들에 대해 꽤 낙관적입니다.
- augment_me
GPU 커널 개발 커뮤니티에서도 비슷한 문제가 있었습니다.
그것은 벤치마크가 제공하는 가치가 당신의 사용 사례에 달려 있다는 것을 이해함으로써 해결되었습니다. 기사 속 저자는 자신이 생각하는 DB 검색이란 무엇인가(신뢰할 수 있고, 범용적)라는 관점에서 벤치마크를 비난하는 것처럼 들리며, 벤치마크가 측정하는 것에서 출발하지 않습니다.
몇 가지 형태에 대해 가장 빠른 커널을 원한다면, 사람들이 깨지기 쉽지만 빠른 코드를 만들도록 두십시오.
일반적이고 폭넓은 해결책에 관심이 있다면, 50개의 서로 다른 출품작을 벤치마크하고, 가능한 모든 입력에 대해 어셈블리 분기를 허용하지 않도록 코드 크기를 제한하십시오.
비트 단위 동등성이나 다른 최종 작업 제한 같은 요구 사항을 거기에 넣으십시오.
공개 및 비공개 데이터셋을 두십시오.
저는 이것이 우리가 이런 것들을 왜, 무엇을 원하는지 더 많이 생각하고, 예전 방식대로 하는 대신 그것을 반영하는 벤치마크를 설계해야 한다는 증거에 더 가깝다고 생각합니다.
- qsort
저자는 이것이 기존 트렌드의 연속이자 증폭이라는 점을 정확히 지적하고 있습니다.
저는 데이터 분야에서 좋은 싸움을 벌이며 '그냥 Postgres 쓰기'의 복음을 전파하고 있는데, 점점 더 의심스러워 보이는 벤치마크를 많이 보고 있습니다. 쿼리 성능은 일반 프로그래밍에서 자료 구조를 선택하는 것과 같습니다: 거의 전적으로 런타임에 예상하는 접근 패턴에 달려 있습니다. 해시 테이블이 필요했다면 세계에서 가장 빠른 연결 리스트를 찾아 나서는 것은 완전히 무의미합니다. 현대 데이터 엔지니어링 환경의 상황과 비교해 보십시오. 벤치마크로 측정된 해결책이 정말로 당신의 문제에 대한 해결책인지, 아니면 '그냥 Postgres 쓰기'보다 significant한 개선인지 확신하십니까? 측정을 했습니까, 아니면 마케팅과 분위기에 의존하고 있습니까?
다시 말하지만, 이런 해결책이 설 자리가 있다고 확신합니다. 하지만 적어도 지금은 전통적인 엔진과 같은 자리는 아닙니다.