Все верно, но для этого у нас и существует валидационный датасет + бенчмарки, которые модель никогда не видела на обучающих данных. И там, и там демонстрируется статистически значимый прирост точности после обучения.
Тут еще дело в том, что модели просто выгоднее усваивать общие паттерны решения задачи, нежели подгонять запрос под правильный вариант на конкретном наборе данных - через нее же проходят десятки тысяч сэмплов, на каждый из которых она генерирует еще по 10 вариантов запросов. В общем в этом сетапе очень сложно упасть в плохой локальный минимум
Эталонный запрос нужен, чтобы сравнить результаты выполнения сгенерированных вариантов.
Вообще GRPO/GSPO можно легко расширить на генерацию не только дающих правильный результат, но и наиболее оптимальных SQL - достаточно модифицировать награду модели, включив туда относительный выигрыш одного запроса над другими. В этой работе мы специально брали очень маленькую модель (всего 600 миллионов параметров) и требовали от нее хотя бы корректного SQL, что дало свои плоды. Далее целевой функционал можно модифицировать как душе огодно
К сожалению, авторы оригинальной статьи ссылками не поделились, однако именно фрейморк START описан подробно и некоторые его реализации можно найти в open-source (в том числе и обученные модели):
Стандарта нет, потому что слишком много частных случаев) В целом LLM достаточно умны, чтобы понимать что чем в БД является, особенно если есть метаданные и названия сущностей осмысленны. Собственно важность сбора и систематизации метаданных освещал в предыдущей статье
У нас, очевидно, база postgresql, поэтому нам доступны все ее преимущества, включая ролевые модели, разделение по схемам, полнотекстовый поиск, векторный поиск, поиск по графу и т.д. Поэтому разграничение доступов у нас на уровне базы. Логи можно присвоить документу, разбить на чанки и проиндексировать - в целом да, на эту задачу можно создать отдельного агента со своими инструментами поиска/фильтрации
Все зависит от задачи. Вы абсолютно правы в том, что создание абстракции в виде некого DSL, на котором модель выражается - это эффективный путь решения проблемы. Особенно, если задать формальную грамматику языка и ограничить вывод модели при помощи guided_decoding и качественно написанного промпта.
Задача, которую мы решали, достаточно общая и SQL/Cypher в ней вполне выступают в виде абстрактных DSL с последующей агрегацией результатов каждого из этапов.
В статье как раз и говорится про необходимость сбора и систематизации метаданных, которые несут семантику так необходимую языковым моделям (и людям, кстати) для решения задачи. Мы уже сталкиваемся с этим и понимаем важность смыслового описания существующих моделей
Да, в этой итерации методов сравнения производились с неназванной ComSys/CommDB, чтобы результаты бенчмарков не становились оружием в руках исследователей. Можно их видеть на рисунках 5, 6 и 7 для Bao (везде сверху PostgreSQL, а снизу ComSys). Аналогично для Balsa рисунок 10. Как можно видеть, там улучшение тоже есть, хоть и не такое значительное.
Можно, поскольку вектор входных признаков моделей открыт к расширению. Bao, например, уже допом может учитывать текущее состояние кэша, как в целом и все другие модели. В предыдущей статье уже размышлял о "произвольности" векторизации и возможности брать все, что посчитаете нужным для конкретной задачи. Вообще говоря, применение ML в динамически меняющихся средах вполне оправдано и будет работать примерно так, как вы и описали.
В Bao GPU используется только во время обучения, которое происходит параллельно основной нагрузке. Для инференса подобных маленьких моделей (меньше 10МБ) вполне достаточно CPU, что в работе и демонстрируется. Конечно, есть простые запросы, на которых оверхед нейросети заметен, но в среднем, тем более на сложных запросах, Bao лучше.
Графики с центами и временем нужно рассматривать параллельно - соответствующая пара столбцов на каждую конфигурацию. Условно, для конфигурации на PostgreSQL n1-2 будет стоимость 70 центов и прогонка займёт 450 минут.
Да, в этом есть смысл. Конечно, небольшая GPU для подобных задач обойдётся дешевле, но немногие готовы к кардинальным изменениям инфраструктуры ради не самой большой оптимизации. Облака отчасти решают данную проблему, однако везде есть свои "но".
Для DQ, относительно сложной RL-модели, используют 32 ядра при сравнении стандартного и нейросетевого оптимизатора.
В других моделях чётко не указывали результаты эксперимента в связи с изменением количества ядер, что на самом деле является интересным вопросом. Могу, исходя из опыта, предположить, что в связи с небольшой способностью параллелиться на CPU, маленькие нейросети будут сравнительно эффективнее отрабатывать на небольших мощностях, порядка 8 ядер. Скорость инференса растёт нелинейно, следовательно, может быть момент, когда очередное добавленное CPU позволит перебрать варианты быстрее и получить лучший результат с использованием обычных оптимизаторов. Однако, это утверждение нужно проверять.
В этой статье рассмотрены пионеры области, что отметил в заключении. Поэтому думать о серьёзном внедрении таких решений в прод я бы не стал. По скорости работы на единичных запросах стандартные оптимизаторы проигрывают нейросетевым. Однако в реальности есть много динамики - данные и структура БД постоянно меняются, частые запросы кэшируются, индексы перестраиваются и т.д. и т.п. В этих условиях нейросетям становится плохо и решение всех этих проблем - предмет следующих статей. Там уже будут показаны модели, протестированные в боевых условиях, которые либо сравниваются, либо превосходят существующие оптимизаторы по скорости и качеству работы на одном и том же железе.
Вообще вот интересный метод: GiffCF - ребята сделали диффузию при помощи уравнения теплопроводности в первом приближении, выглядит интересно. Её менее изощренной предтечей была DiffRec, основанная на обычном добавлении гауссова шума в матрицу, но всё равно интересно поразбираться.
И насчёт вашей научной статьи - было бы круто глянуть)
Спасибо за статью, это очень важный класс рекомендательных систем. Ещё хотелось бы почитать про диффузии на графах, которые относительно неплохо себя показывают и соревнуются с трансформерными моделями по качеству и скорости работы.
Вовсе не удивительно, что на основе аппроксимационной теоремы Колмогорова можно строить такие же функции в виде сетей, как и в случае MLP. MLP в свою очередь обосновываются аппроксимационной теоремой Хехта-Нильсена (и её обобщением на класс измеримых функций, данным Алексеевым).
Как в случае MLP, так и в случае KAN у нас доказывается сходимость представленной структуры в пространстве измеримых функций, но ничего не говорится об их оптимальности. По всей видимости это в принципе очень трудная проблема, сравнимая с задачами тысячелетия. Всё сравнивается с эффективностью на конкретных задачах, но не производится никаких обобщений. Таким образом мы просто метаемся от одного представления к другому, так и не исследовав глубокие морфологические свойства подобных разложений, не поняв структуру созданных сетей и то, как же всё-таки сопоставить классы всевозможных сетей с классами всевозможных функций, чем бы они не являлись.
Безусловно важно следить за чистотой языка, но на вашем месте я бы больше внимания обращал на содержательную часть статьи и оставлял комментарии по теме. И да, помимо "диванной футурологии" в статье тоже много чего имеется. Почитайте, советую)
Хотел оставить мнение на следующие статьи из цикла, когда уже будет широкое понимание существующих технологий, но вкратце и тут можно поразмышлять) Достаточно взглянуть на модель One-2-3-45++, которая уже способна генерировать 3D-модели приемлемого качества по одной лишь фотографии объекта. И что самое интересное, её невозможно рассматривать обособленно от текущего контекста, поскольку она использует и CLIP, и Stable Diffusion и прочие современные подходы, чтобы достичь такого качества.
Вообще всё идёт к тому, что 3D-модели будут создаваться по щелчку пальца, как сейчас происходит с иллюстрациями. Это в свою очередь упростит создание игр, мультфильмов, аниматиков, контента для AR/VR. Также такое глубокое понимание концепта 3D-объектов может в последствии помочь в робототехнике и создании ПО для беспилотников (и мы наконец преодолеем этот барьер, существующий между нашим миром и бурно развивающимся миром нейросетей).
Ещё я мечтаю увидеть момент, когда мы научимся генерировать настраиваемые видеоролики большой продолжительности в приемлемом качестве. Кажется, что и здесь не обойтись без внедрения 3D-нейросетей в процессы генерации. Есть ещё такая штука, называется VQGAN-3D, так вот, там за третье измерение берётся время, а не глубина, и выходит так, что 2D-анимации она генерит неплохо, а вот с 3D уже происходят коллапсы на хоть сколько-нибудь длинных дистанциях. То есть надо шагать дальше в VQGAN-4D? Думаю это сейчас одно из самых перспективных направлений - давать нейросетям больше информации о нашем мире, давать им понимание, какое есть у нас, а не вывозить за счёт эвристик. Конечно, здесь есть ограничения по производительности, но мы всегда с этим что-нибудь придумываем)
Полностью согласен с вами! Но есть проблема - базовой модели, которая удовлетворяла бы всем поставленным бизнес-задачам на проекте изначально не существовало. Т.е. по сути мы и разработали базовую модель, основанную на новом принципе. По ML-метрикам:
косинусное расстояние для энкодера на тесте = 0.258 (рандом даёт 1)
MSE для декодера = 0.281 (вектора единичные, поэтому рандом также даёт единицу)
Все верно, но для этого у нас и существует валидационный датасет + бенчмарки, которые модель никогда не видела на обучающих данных. И там, и там демонстрируется статистически значимый прирост точности после обучения.
Тут еще дело в том, что модели просто выгоднее усваивать общие паттерны решения задачи, нежели подгонять запрос под правильный вариант на конкретном наборе данных - через нее же проходят десятки тысяч сэмплов, на каждый из которых она генерирует еще по 10 вариантов запросов. В общем в этом сетапе очень сложно упасть в плохой локальный минимум
Эталонный запрос нужен, чтобы сравнить результаты выполнения сгенерированных вариантов.
Вообще GRPO/GSPO можно легко расширить на генерацию не только дающих правильный результат, но и наиболее оптимальных SQL - достаточно модифицировать награду модели, включив туда относительный выигрыш одного запроса над другими. В этой работе мы специально брали очень маленькую модель (всего 600 миллионов параметров) и требовали от нее хотя бы корректного SQL, что дало свои плоды. Далее целевой функционал можно модифицировать как душе огодно
К сожалению, авторы оригинальной статьи ссылками не поделились, однако именно фрейморк START описан подробно и некоторые его реализации можно найти в open-source (в том числе и обученные модели):
https://github.com/dongguanting/Tool-Star
Стандарта нет, потому что слишком много частных случаев) В целом LLM достаточно умны, чтобы понимать что чем в БД является, особенно если есть метаданные и названия сущностей осмысленны. Собственно важность сбора и систематизации метаданных освещал в предыдущей статье
У нас, очевидно, база postgresql, поэтому нам доступны все ее преимущества, включая ролевые модели, разделение по схемам, полнотекстовый поиск, векторный поиск, поиск по графу и т.д. Поэтому разграничение доступов у нас на уровне базы. Логи можно присвоить документу, разбить на чанки и проиндексировать - в целом да, на эту задачу можно создать отдельного агента со своими инструментами поиска/фильтрации
Все зависит от задачи. Вы абсолютно правы в том, что создание абстракции в виде некого DSL, на котором модель выражается - это эффективный путь решения проблемы. Особенно, если задать формальную грамматику языка и ограничить вывод модели при помощи guided_decoding и качественно написанного промпта.
Задача, которую мы решали, достаточно общая и SQL/Cypher в ней вполне выступают в виде абстрактных DSL с последующей агрегацией результатов каждого из этапов.
В статье как раз и говорится про необходимость сбора и систематизации метаданных, которые несут семантику так необходимую языковым моделям (и людям, кстати) для решения задачи. Мы уже сталкиваемся с этим и понимаем важность смыслового описания существующих моделей
Да, в этой итерации методов сравнения производились с неназванной ComSys/CommDB, чтобы результаты бенчмарков не становились оружием в руках исследователей. Можно их видеть на рисунках 5, 6 и 7 для Bao (везде сверху PostgreSQL, а снизу ComSys). Аналогично для Balsa рисунок 10. Как можно видеть, там улучшение тоже есть, хоть и не такое значительное.
Можно, поскольку вектор входных признаков моделей открыт к расширению. Bao, например, уже допом может учитывать текущее состояние кэша, как в целом и все другие модели. В предыдущей статье уже размышлял о "произвольности" векторизации и возможности брать все, что посчитаете нужным для конкретной задачи. Вообще говоря, применение ML в динамически меняющихся средах вполне оправдано и будет работать примерно так, как вы и описали.
В Bao GPU используется только во время обучения, которое происходит параллельно основной нагрузке. Для инференса подобных маленьких моделей (меньше 10МБ) вполне достаточно CPU, что в работе и демонстрируется. Конечно, есть простые запросы, на которых оверхед нейросети заметен, но в среднем, тем более на сложных запросах, Bao лучше.
Графики с центами и временем нужно рассматривать параллельно - соответствующая пара столбцов на каждую конфигурацию. Условно, для конфигурации на PostgreSQL n1-2 будет стоимость 70 центов и прогонка займёт 450 минут.
Да, в этом есть смысл. Конечно, небольшая GPU для подобных задач обойдётся дешевле, но немногие готовы к кардинальным изменениям инфраструктуры ради не самой большой оптимизации. Облака отчасти решают данную проблему, однако везде есть свои "но".
Для DQ, относительно сложной RL-модели, используют 32 ядра при сравнении стандартного и нейросетевого оптимизатора.
В других моделях чётко не указывали результаты эксперимента в связи с изменением количества ядер, что на самом деле является интересным вопросом. Могу, исходя из опыта, предположить, что в связи с небольшой способностью параллелиться на CPU, маленькие нейросети будут сравнительно эффективнее отрабатывать на небольших мощностях, порядка 8 ядер. Скорость инференса растёт нелинейно, следовательно, может быть момент, когда очередное добавленное CPU позволит перебрать варианты быстрее и получить лучший результат с использованием обычных оптимизаторов. Однако, это утверждение нужно проверять.
В этой статье рассмотрены пионеры области, что отметил в заключении. Поэтому думать о серьёзном внедрении таких решений в прод я бы не стал. По скорости работы на единичных запросах стандартные оптимизаторы проигрывают нейросетевым. Однако в реальности есть много динамики - данные и структура БД постоянно меняются, частые запросы кэшируются, индексы перестраиваются и т.д. и т.п. В этих условиях нейросетям становится плохо и решение всех этих проблем - предмет следующих статей. Там уже будут показаны модели, протестированные в боевых условиях, которые либо сравниваются, либо превосходят существующие оптимизаторы по скорости и качеству работы на одном и том же железе.
Вообще вот интересный метод: GiffCF - ребята сделали диффузию при помощи уравнения теплопроводности в первом приближении, выглядит интересно. Её менее изощренной предтечей была DiffRec, основанная на обычном добавлении гауссова шума в матрицу, но всё равно интересно поразбираться.
И насчёт вашей научной статьи - было бы круто глянуть)
Спасибо за статью, это очень важный класс рекомендательных систем. Ещё хотелось бы почитать про диффузии на графах, которые относительно неплохо себя показывают и соревнуются с трансформерными моделями по качеству и скорости работы.
Вовсе не удивительно, что на основе аппроксимационной теоремы Колмогорова можно строить такие же функции в виде сетей, как и в случае MLP. MLP в свою очередь обосновываются аппроксимационной теоремой Хехта-Нильсена (и её обобщением на класс измеримых функций, данным Алексеевым).
Как в случае MLP, так и в случае KAN у нас доказывается сходимость представленной структуры в пространстве измеримых функций, но ничего не говорится об их оптимальности. По всей видимости это в принципе очень трудная проблема, сравнимая с задачами тысячелетия. Всё сравнивается с эффективностью на конкретных задачах, но не производится никаких обобщений. Таким образом мы просто метаемся от одного представления к другому, так и не исследовав глубокие морфологические свойства подобных разложений, не поняв структуру созданных сетей и то, как же всё-таки сопоставить классы всевозможных сетей с классами всевозможных функций, чем бы они не являлись.
Благодарю за найденную опечатку - поправил.
Безусловно важно следить за чистотой языка, но на вашем месте я бы больше внимания обращал на содержательную часть статьи и оставлял комментарии по теме. И да, помимо "диванной футурологии" в статье тоже много чего имеется. Почитайте, советую)
Хотел оставить мнение на следующие статьи из цикла, когда уже будет широкое понимание существующих технологий, но вкратце и тут можно поразмышлять) Достаточно взглянуть на модель One-2-3-45++, которая уже способна генерировать 3D-модели приемлемого качества по одной лишь фотографии объекта. И что самое интересное, её невозможно рассматривать обособленно от текущего контекста, поскольку она использует и CLIP, и Stable Diffusion и прочие современные подходы, чтобы достичь такого качества.
Вообще всё идёт к тому, что 3D-модели будут создаваться по щелчку пальца, как сейчас происходит с иллюстрациями. Это в свою очередь упростит создание игр, мультфильмов, аниматиков, контента для AR/VR. Также такое глубокое понимание концепта 3D-объектов может в последствии помочь в робототехнике и создании ПО для беспилотников (и мы наконец преодолеем этот барьер, существующий между нашим миром и бурно развивающимся миром нейросетей).
Ещё я мечтаю увидеть момент, когда мы научимся генерировать настраиваемые видеоролики большой продолжительности в приемлемом качестве. Кажется, что и здесь не обойтись без внедрения 3D-нейросетей в процессы генерации. Есть ещё такая штука, называется VQGAN-3D, так вот, там за третье измерение берётся время, а не глубина, и выходит так, что 2D-анимации она генерит неплохо, а вот с 3D уже происходят коллапсы на хоть сколько-нибудь длинных дистанциях. То есть надо шагать дальше в VQGAN-4D? Думаю это сейчас одно из самых перспективных направлений - давать нейросетям больше информации о нашем мире, давать им понимание, какое есть у нас, а не вывозить за счёт эвристик. Конечно, здесь есть ограничения по производительности, но мы всегда с этим что-нибудь придумываем)
Полностью согласен с вами! Но есть проблема - базовой модели, которая удовлетворяла бы всем поставленным бизнес-задачам на проекте изначально не существовало. Т.е. по сути мы и разработали базовую модель, основанную на новом принципе. По ML-метрикам:
косинусное расстояние для энкодера на тесте = 0.258 (рандом даёт 1)
MSE для декодера = 0.281 (вектора единичные, поэтому рандом также даёт единицу)