Comments 7
BIRD ... Пример из бенчмарка
Вот уж точно - "ближе к реальному миру". Наверное, нужно было обучать модель на запросах, построенных SQL-программистами, а не аналитиками. Ну или доверить написание эталонных ответов SQL-программистам. Я как-то не понял, с какой стороны смотреть-то надо.
А запросы - ну обняться и плакать. Несмотря на то, что вроде бы дадут верный результат. Хотя да - мы же аналитика заменяем. Тогда чего это я вдруг...
Это же бенчмарк, на котором такие модели проверяются. Обычно всегда такие работы ссылаются на то, как они выполнили бенчмарк Spider. Его давно сделали, и эта статья не про бенчмарк, и не про запросы в нем. И вроде бы автор не писал, что модель тренировалась на запросах из бенчмарка. То есть, к формулам в статье вопросов нет, все понятно, но непонятно, с какой стороны смотреть на запросы.
Это же бенчмарк, на котором такие модели проверяются.
Ну и что, что бенчмарк... я вот, например, не понял, что должно быть на выходе - строго показанный эталонный запрос, через какое бы место он ни был написан, или хоть какой запрос, который просто даёт правильный результат, даже если от его неоптимальности волосы дыбом?
Я из статьи понял, что измерялось и первое - точное совпадение, и второе - достаточно правильного результата. Учитывая, что речь идет о замене аналитика (как вы написали), то пользователь (у которого до этого и не было никогда аналитика) делает запрос, ждет результат, не дожидается за то время, за которое хотел его получить, жмет кнопку прервать, переформулирует вопрос. В его ситуации альтернатива - вообще не делать запросы, так как SQL надо учить, а далеко не все программисты. Это может быть директор компании или собственник бизнеса, у него своих проблем в жизни хватает
Эталонный запрос нужен, чтобы сравнить результаты выполнения сгенерированных вариантов.
Вообще GRPO/GSPO можно легко расширить на генерацию не только дающих правильный результат, но и наиболее оптимальных SQL - достаточно модифицировать награду модели, включив туда относительный выигрыш одного запроса над другими. В этой работе мы специально брали очень маленькую модель (всего 600 миллионов параметров) и требовали от нее хотя бы корректного SQL, что дало свои плоды. Далее целевой функционал можно модифицировать как душе огодно
Эталонный запрос нужен, чтобы сравнить результаты выполнения сгенерированных вариантов.
Вот тут есть ну очень большая проблема. Которая хорошо видна на всяких обучающих курсах - написанный запрос даёт верный результат на демо-данных, но не проходит финальное тестирование на некоторых проверочных наборах данных. То есть набор данных должен быть абсолютно точно определён (для любой записи или группы записей можно однозначно определить, может ли присутствовать такая запись/группа в наборе), что само по себе встречается достаточно нечасто, и включать/учитывать ну абсолютно все возможные сочетания, вариации и краевые значения (а ведь порой одни сочетания вполне могут противоречить другим, наличие одной особенности набора гарантирует отсутствие другой, то есть тестировать один запрос нужно на нескольких разных наборах).
Если второе можно обеспечить тщательной подготовкой тестового набора или наборов, то вот первое нужно не только обеспечить, но и донести до LLM, что по моему мнению в принципе нереально на хоть сколько-нибудь сложных датасетах. А без этого LLM запросто может сгенерить код, который точно выполняет задачу, в которой неуказанные особенности датасета интерпретированы иначе, и тест не будет пройден.
Все верно, но для этого у нас и существует валидационный датасет + бенчмарки, которые модель никогда не видела на обучающих данных. И там, и там демонстрируется статистически значимый прирост точности после обучения.
Тут еще дело в том, что модели просто выгоднее усваивать общие паттерны решения задачи, нежели подгонять запрос под правильный вариант на конкретном наборе данных - через нее же проходят десятки тысяч сэмплов, на каждый из которых она генерирует еще по 10 вариантов запросов. В общем в этом сетапе очень сложно упасть в плохой локальный минимум
Information
- Website
- www.postgrespro.ru
- Registered
- Founded
- Employees
- 501–1,000 employees
- Location
- Россия
- Representative
- Иван Панченко
Как мы обеспечили +33% к точности на сложных SQL-запросах