Спасибо, классный проект! Делал что-то похожее на 2020 год) К сожалению, схемы не сохранилось, помню делал всё на attiny, травил, паял и вырезал текстолит сам
Впереди ещё много статей по практическим применениям и реализациям LLM-агентов, тулингу, бенчмаркингу и дообучению. Думаю, что очень многое будет меняться, но на некоторые вопросы отвечу - они очень в тему)
Используем ли мы реранкеры? Да, когда вышли эмбедеры и реранкеры от Qwen - мы сразу протестировали их на нашем retrieve и получили, что связка дообученной bge + qwen3-reranker-4b отрабатывает лучше всего по MRR+ACC@5 на нашем бенче.
Пробовали ли другие эмбедеры? Да, но полтора года назад bge-m3 и показал себя лучше всего на нашем корпусе. Далее пробовали разное, но dense/sparse-вектора в bge-m3 и наш гибридный retrieve сохраняются до сих пор. Скорее всего отойдём от него, когда начнём уходить в графы знаний + семантику, но к этому ещё идём.
Как сплитим? Мы используем биение по документам/главам + RecursiveCharacterTextSplitter (4096/128), связываем их через таблицу связи, производим семантическую дедупликацию, векторизуем, делам частотное дисконтирование у sparse-векторов и дальше обычный retrieve через RRF.
System или user? Мы делаем основную инструкцию в system, а далее по разному в разных продуктах. По началу запихивали всё в user, затем, когда появились агенты - начали передавать историю в обычном формате - system→user→assistant (в т.ч. tool calls + tool results)→user→... На таком формате получали более стабильное поведение с точки зрения ролевой модели.
В каком формате промпты? Зависит от задачи, но преимущественно всё в Markdown
Делаем ли в MCP structured output и подаём ли схему промпте? В AskPostgres пока что нет - тул колы выбираются свободно (auto) через цикл ReAct. Но в рамках отдельных прототипов и внутренних разработок прописываем в SGR схемы тулов и передаём всю схему в промпт, чтобы стабилизировать семплирование (а то модель не знает, что и в каком формате от неё вообще ждут, может начать галлюцинировать без конкретной схемы. Короче через промпт смещаем распределения в нужную нам область).
Бывают ли проблемы с иероглифами? Да, часто. Это бич квантизованных китайских моделей. Вообще вставки семантически схожих токенов я и в ChatGPT очень часто наблюдаю, типа constрукция, embedинг, реrankер и другие, но их легко прочитать, а вот что-то типа м模ель распознать уже сложнее. Бывает полностью скатывается в китайский ответ. Тут боролись промптингом и ограничением семплирования на множество "хороших" токенов, но это снижало throughput. В общем проблема есть, но с каждым новым релизом и увеличением размера модели/уменьшением квантизации, она становится всё реже.
Зачем нам увеличивать модель до 235B? Тут всё просто - стабильность агента на сложных сценариях, включая тул колинг и сохранение ролевой модели. Также привлекает лучшая работа на больших контекстах, к чему мы собственно и идём.
Сравнивали ли с t-tech/T-pro-it-2.1-FP8 ? Пока что нет, ещё не успели) Но как минимум есть проблема с тем, что это не MoE. Мы уже привыкли к хорошему througput благодаря MoE (к тому же на наших тестах Qwen3-32B и Qwen3-80B-A3B давали +- схожее качество). Скорее всего это будет основным ограничением при внедрении подобных моделей.
Как работаем с SearXNG? У нас единый search-tool по проверенным движкам. Контекст из тула возвращается в формате json - так и передаём (отдельно url, отдельно content).
Qwen 32B VL спокойно поднять можно, но нам был важен throughput по токенам и хороший параллельный инференс на несколько сессий, исходя из ограничений по ресурсам. Собственно здесь и появляется основной tradeoff - качество vs скорость. Уменьшая размер модели, например, до 14B, мы сильно проседали в качестве. Агрессивная квантизация для 32B модели тоже давала сомнительный результат (модель путала языки и легко циклилась). По итогу спасение появилось, откуда не ждали - 80B модель, но с MoE на 3 миллиарда активных параметров. Здесь и понадобилась 4-bit квантизация, но по сравнению с предыдущими моделями серии у нас сохранилось относительно стабильное поведение на тех же tool calls (80B на то и 80B).
Информация у нас преимущественно текстовая с вкраплениями кода и таблиц. Формул мало, больших рукописных таблиц тоже нет. Всё-таки у вас специфика оффлайн OCR рукописного текста - она отличается. Я бы посмотрел в сторону современных OCR последнего поколения, типа paddleOCR-VL, dots.ocr или другие более компактные и специализированные варианты (хороший обзор здесь https://huggingface.co/blog/ocr-open-models). Также у вас, возможно, пригодится fine-tune на ваших данных, для задач OCR он зачастую оправдан.
Всё зависит от выбранной модели, её размера, квантизации, обвязки и параметров семплирования. Настолько фундаментальными знаниями обладают даже небольшие модели, например, из той же линейки Qwen3 от Alibaba. Про ChatGPT и DeepSeek думаю говорить не стоит, они крайне умны и обладают широким спектром фундаментальных знаний во всех областях.
Спросил у нашей модели про корреляцию, попросил посчитать на реальной базе - результат ожидаемо хороший.
Наша платформа реализует ReAct-агента на базе Qwen3-Next-80B-A3B с 4-bit AWQ квантизацией. Это хоть и большая, но не гигантская модель по современным меркам, особенно учитывая используемую квантизацию.
Все верно, но для этого у нас и существует валидационный датасет + бенчмарки, которые модель никогда не видела на обучающих данных. И там, и там демонстрируется статистически значимый прирост точности после обучения.
Тут еще дело в том, что модели просто выгоднее усваивать общие паттерны решения задачи, нежели подгонять запрос под правильный вариант на конкретном наборе данных - через нее же проходят десятки тысяч сэмплов, на каждый из которых она генерирует еще по 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, основанная на обычном добавлении гауссова шума в матрицу, но всё равно интересно поразбираться.
И насчёт вашей научной статьи - было бы круто глянуть)
Спасибо за статью, это очень важный класс рекомендательных систем. Ещё хотелось бы почитать про диффузии на графах, которые относительно неплохо себя показывают и соревнуются с трансформерными моделями по качеству и скорости работы.
Спасибо, классный проект! Делал что-то похожее на 2020 год) К сожалению, схемы не сохранилось, помню делал всё на attiny, травил, паял и вырезал текстолит сам
Впереди ещё много статей по практическим применениям и реализациям LLM-агентов, тулингу, бенчмаркингу и дообучению. Думаю, что очень многое будет меняться, но на некоторые вопросы отвечу - они очень в тему)
Используем ли мы реранкеры? Да, когда вышли эмбедеры и реранкеры от Qwen - мы сразу протестировали их на нашем retrieve и получили, что связка дообученной bge + qwen3-reranker-4b отрабатывает лучше всего по MRR+ACC@5 на нашем бенче.
Пробовали ли другие эмбедеры? Да, но полтора года назад bge-m3 и показал себя лучше всего на нашем корпусе. Далее пробовали разное, но dense/sparse-вектора в bge-m3 и наш гибридный retrieve сохраняются до сих пор. Скорее всего отойдём от него, когда начнём уходить в графы знаний + семантику, но к этому ещё идём.
Как сплитим? Мы используем биение по документам/главам + RecursiveCharacterTextSplitter (4096/128), связываем их через таблицу связи, производим семантическую дедупликацию, векторизуем, делам частотное дисконтирование у sparse-векторов и дальше обычный retrieve через RRF.
System или user? Мы делаем основную инструкцию в system, а далее по разному в разных продуктах. По началу запихивали всё в user, затем, когда появились агенты - начали передавать историю в обычном формате - system→user→assistant (в т.ч. tool calls + tool results)→user→... На таком формате получали более стабильное поведение с точки зрения ролевой модели.
В каком формате промпты? Зависит от задачи, но преимущественно всё в Markdown
Делаем ли в MCP structured output и подаём ли схему промпте? В AskPostgres пока что нет - тул колы выбираются свободно (auto) через цикл ReAct. Но в рамках отдельных прототипов и внутренних разработок прописываем в SGR схемы тулов и передаём всю схему в промпт, чтобы стабилизировать семплирование (а то модель не знает, что и в каком формате от неё вообще ждут, может начать галлюцинировать без конкретной схемы. Короче через промпт смещаем распределения в нужную нам область).
Бывают ли проблемы с иероглифами? Да, часто. Это бич квантизованных китайских моделей. Вообще вставки семантически схожих токенов я и в ChatGPT очень часто наблюдаю, типа
constрукция, embedинг, реrankери другие, но их легко прочитать, а вот что-то типа м模ель распознать уже сложнее. Бывает полностью скатывается в китайский ответ. Тут боролись промптингом и ограничением семплирования на множество "хороших" токенов, но это снижало throughput. В общем проблема есть, но с каждым новым релизом и увеличением размера модели/уменьшением квантизации, она становится всё реже.Зачем нам увеличивать модель до 235B? Тут всё просто - стабильность агента на сложных сценариях, включая тул колинг и сохранение ролевой модели. Также привлекает лучшая работа на больших контекстах, к чему мы собственно и идём.
Сравнивали ли с t-tech/T-pro-it-2.1-FP8 ? Пока что нет, ещё не успели) Но как минимум есть проблема с тем, что это не MoE. Мы уже привыкли к хорошему througput благодаря MoE (к тому же на наших тестах Qwen3-32B и Qwen3-80B-A3B давали +- схожее качество). Скорее всего это будет основным ограничением при внедрении подобных моделей.
Как работаем с SearXNG? У нас единый search-tool по проверенным движкам. Контекст из тула возвращается в формате json - так и передаём (отдельно url, отдельно content).
Контекстное окно важно, да, преимущественно для результатов вызова инструментов - мы работаем с агентами, поэтому именно здесь наибольшая сложность.
Насчёт формул в LaTEX - вопрос хороший, нужно изучить, возможно, есть модели, подходящие вам, например, в эта или эта.
Наша 80B модель - https://huggingface.co/cyankiwi/Qwen3-Next-80B-A3B-Instruct-AWQ-4bit , но она без VL. Если VL и нужен, то только для анализа графиков и для этого поднимаем отдельно модель, но пока в качестве R&D.
Qwen 32B VL спокойно поднять можно, но нам был важен throughput по токенам и хороший параллельный инференс на несколько сессий, исходя из ограничений по ресурсам. Собственно здесь и появляется основной tradeoff - качество vs скорость. Уменьшая размер модели, например, до 14B, мы сильно проседали в качестве. Агрессивная квантизация для 32B модели тоже давала сомнительный результат (модель путала языки и легко циклилась). По итогу спасение появилось, откуда не ждали - 80B модель, но с MoE на 3 миллиарда активных параметров. Здесь и понадобилась 4-bit квантизация, но по сравнению с предыдущими моделями серии у нас сохранилось относительно стабильное поведение на тех же tool calls (80B на то и 80B).
Информация у нас преимущественно текстовая с вкраплениями кода и таблиц. Формул мало, больших рукописных таблиц тоже нет. Всё-таки у вас специфика оффлайн OCR рукописного текста - она отличается. Я бы посмотрел в сторону современных OCR последнего поколения, типа paddleOCR-VL, dots.ocr или другие более компактные и специализированные варианты (хороший обзор здесь https://huggingface.co/blog/ocr-open-models). Также у вас, возможно, пригодится fine-tune на ваших данных, для задач OCR он зачастую оправдан.
Всё зависит от выбранной модели, её размера, квантизации, обвязки и параметров семплирования. Настолько фундаментальными знаниями обладают даже небольшие модели, например, из той же линейки Qwen3 от Alibaba. Про ChatGPT и DeepSeek думаю говорить не стоит, они крайне умны и обладают широким спектром фундаментальных знаний во всех областях.
Спросил у нашей модели про корреляцию, попросил посчитать на реальной базе - результат ожидаемо хороший.
Наша платформа реализует ReAct-агента на базе Qwen3-Next-80B-A3B с 4-bit AWQ квантизацией. Это хоть и большая, но не гигантская модель по современным меркам, особенно учитывая используемую квантизацию.
Все верно, но для этого у нас и существует валидационный датасет + бенчмарки, которые модель никогда не видела на обучающих данных. И там, и там демонстрируется статистически значимый прирост точности после обучения.
Тут еще дело в том, что модели просто выгоднее усваивать общие паттерны решения задачи, нежели подгонять запрос под правильный вариант на конкретном наборе данных - через нее же проходят десятки тысяч сэмплов, на каждый из которых она генерирует еще по 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, основанная на обычном добавлении гауссова шума в матрицу, но всё равно интересно поразбираться.
И насчёт вашей научной статьи - было бы круто глянуть)
Спасибо за статью, это очень важный класс рекомендательных систем. Ещё хотелось бы почитать про диффузии на графах, которые относительно неплохо себя показывают и соревнуются с трансформерными моделями по качеству и скорости работы.