Thomas Neumann: AI-агенты превратили бенчмарк TPC-H в фикцию
Next-Level Benchmarking Overfitting – Thomas Neumann
Автор блога Database Architects разбирает GenDB-V — систему, где AI-агенты генерируют и формально верифицируют движок БД и заявляют ускорение в 22–61 раз над Umbra и DuckDB. Neumann показывает, что рекорды держатся на предвычислениях и жёстко зашитом знании генератора данных dbgen: агенты «знают», в какой строке лежит каждый ключ, и превращают join в Q18 в почти бесплатную операцию. Проверка корректности при этом есть, но срабатывает лишь на официальных данных TPC-H.
Позволяя AI-агентам оптимизировать под конкретный бенчмарк, вы делаете бенчмарк бесполезным. Они найдут безумные трюки, чтобы ускорить именно его, но ни один из них не сработает в реальной системе.
- lmeyerov
Мы строим GFQL для открытого векторизованного CPU/GPU cypher на датафреймах (это как duckdb для графов, БД не нужна) с помощью агентной поддержки... и наша мысль в том, что это ступенька к чему-то ещё более агрессивному.
Сегодня мы приветствуем оптимизацию специализаций горячего пути для некоторых паттернов, которые раньше было бы слишком дорого поддерживать. LLM делают эту стоимость терпимой, и возможность делать это для важных пользователей (например, пользователей нашего аналитического продукта Graphistry) — это суперсила. Наши результаты в графовых бенчмарках сообщества бьют больших парней — и, что важно, по всему, что нам небезразлично.
Куда мы действительно хотим двигаться — это специализация во время выполнения/загрузки. Наши клиенты абсолютно точно хотели бы, чтобы их топовые запросы автотюнились. Исследования БД уже сильно смещаются в эту сторону, подобно исследованиям компиляторов десятилетие назад. Я довольно оптимистичен насчёт того, что теперь возможно.
- augment_me
В сообществе разработчиков GPU-ядер была похожая проблема.
Её решили, поняв, что ценность бенчмарков зависит от вашего случая использования. Похоже, автор статьи кричит на бенчмарк, исходя из собственного представления о том, каким должен быть поиск по БД (надёжным, общим), а не из того, что бенчмарк измеряет.
Если вам нужно просто самое быстрое ядро для нескольких форм, дайте людям писать хрупкий, но быстрый код.
Если вам интересны общие широкие решения, бенчмаркайте 50 разных вариантов, ограничьте размер кода, чтобы запретить ассемблерные ветки для каждого возможного случая.
Включите туда требования вроде побитовой эквивалентности или других ограничений конечной задачи.
Заведите публичные и приватные датасеты.
Я думаю, это скорее доказательство того, что нам стоит больше думать о том, что и почему мы хотим от этих вещей, и проектировать бенчмарки, отражающие это, вместо того чтобы идти старым путём.
- qsort
Автор прав, указывая, что это продолжение и усиление уже существующего тренда.
Я в области данных веду праведную борьбу, распространяя евангелие «Просто используйте Postgres», и вижу всё больше бенчмарков, которые выглядят крайне сомнительно. Производительность запросов — это как выбор структуры данных в обычном программировании: она почти полностью зависит от того, какой шаблон доступа вы ожидаете во время выполнения; совершенно бессмысленно искать самый быстрый в мире связный список, если вам нужна хеш-таблица. Сравните с ситуацией в современном ландшафте инженерии данных. Вы уверены, что решение, измеряемое бенчмарком, действительно решает вашу проблему, не говоря уже о значительном улучшении по сравнению с «Просто используйте Postgres»? Вы измеряли или опираетесь на маркетинг и вайбы?
Опять же, я уверен, что у подобных решений есть своё место, но по крайней мере сейчас это не то же место, что у традиционных движков.