Forwarded from Запрети мне псевдолейблить
Топ-1 в #BirdClef2025 от Никиты Бабича запретите ему псевдолйблить
Никита всё соревнование доминировал — был на первом или втором месте. Я лично не видел его ниже чем на втором.
Данные
Дополнительные птицы
Докачал из архива Xeno ещё 5 489 записей по тем же классам, что и в трейне.
Дополнительные лягушки и насекомые из других таксонов
17 197 записей насекомых и амфибий, в том числе не входящих в лейблы для соревнования. Амфибии и насекомые имеют высокую частоту повторяющихся специфичных звуков, что сильно отличается от птиц — отлично прокачивает модель на низкочастотных и “других” классах.
SED-модели (Sound Event Detection).
Прошлые участники тоже их использовали, но я хотел именно тут объяснить что за SED такой.
Классическая классификация говорит «что это за звук», а SED ещё и «где он начинается и где кончается».
На шумных данных, где вокруг слышно несколько видов на одной записи, это был ключ к успеху вместе с псевдолейблингом.
По сути это мост от per-sample к per-frame разметке, похожий на MIL-задачу. Сильно мне напоминает MIL модели, которые делают что-то похожее, но на картинках
На картинке пример инференса SED: как и почему он помогает на шуме.
Валидация
Нормальной валидации не нашлось, поэтому Никита валидировался по ЛБ. :chad:
Многоэтапное обучение
Бейзлайн
15 эпох, Cross-Entropy, AdamW, Cosine Scheduler
backbone’ы: EfficientNet-0 + RegNetY-8
LB: 0.872
Псевдолейблинг I + MixUp
Генерим псевдолейблы на неразмеченной части.
Смешиваем MixUp: настоящие лейблы + псевдолейблы (малый вес последних).
Добавляем StochasticDepth (drop whole conv-блоки, p=0.15). StochasticDepth- это когда у нас есть дропауты, которые выкидывают целые блоки из бекбона и глубина получается недетерминированной.
Тренируем 25–35 эпох.
LB: 0.872 → 0.898
Power Scaling + псевдолейблинг II
Просто в лоб вторая итерация давала слишком шумные псевдолейблы, которые нельзя было повторно переиспользовать.
Решение:
new_preds_i = preds_i^(1/power_c) / sum(preds_j^(1/power_c))
Это позволило пройти 4 раунда псевдолейблинга с улучшением качества.
LB: 0.898 → 0.930
Отдельный пайплайн для насекомых и амфибий
Тренируем классификатор на этих данных.
Берём предикты по нужным классам из трейна и заменяем ими результаты в основном ансамбле.
LB: 0.930 → 0.933
В конечно итоге собираем ансамбль:
EfficientNet-l0, B4, B3 (3 раунда псевдолейблинга)
RegNetY-016 (2 штуки, 4 раунда)
RegNetY-008 (1 штука, 1 раунд)
Отдельный EfficientNet-B0 для классификации насекомых и амфибий
Из этого решения наверно для себя самыми горячими идеям вынесу:
1. PowerTransform для псевдолейблов, чтобы идти в несколько раундов. Идея будто даже похожая на жесткие псевдолейблы чем-то
2. SED как способ уточнить разметку на псевдолейблах
Никита всё соревнование доминировал — был на первом или втором месте. Я лично не видел его ниже чем на втором.
Данные
Дополнительные птицы
Докачал из архива Xeno ещё 5 489 записей по тем же классам, что и в трейне.
Дополнительные лягушки и насекомые из других таксонов
17 197 записей насекомых и амфибий, в том числе не входящих в лейблы для соревнования. Амфибии и насекомые имеют высокую частоту повторяющихся специфичных звуков, что сильно отличается от птиц — отлично прокачивает модель на низкочастотных и “других” классах.
SED-модели (Sound Event Detection).
Прошлые участники тоже их использовали, но я хотел именно тут объяснить что за SED такой.
Классическая классификация говорит «что это за звук», а SED ещё и «где он начинается и где кончается».
На шумных данных, где вокруг слышно несколько видов на одной записи, это был ключ к успеху вместе с псевдолейблингом.
По сути это мост от per-sample к per-frame разметке, похожий на MIL-задачу. Сильно мне напоминает MIL модели, которые делают что-то похожее, но на картинках
На картинке пример инференса SED: как и почему он помогает на шуме.
Валидация
Нормальной валидации не нашлось, поэтому Никита валидировался по ЛБ. :chad:
Многоэтапное обучение
Бейзлайн
15 эпох, Cross-Entropy, AdamW, Cosine Scheduler
backbone’ы: EfficientNet-0 + RegNetY-8
LB: 0.872
Псевдолейблинг I + MixUp
Генерим псевдолейблы на неразмеченной части.
Смешиваем MixUp: настоящие лейблы + псевдолейблы (малый вес последних).
Добавляем StochasticDepth (drop whole conv-блоки, p=0.15). StochasticDepth- это когда у нас есть дропауты, которые выкидывают целые блоки из бекбона и глубина получается недетерминированной.
Тренируем 25–35 эпох.
LB: 0.872 → 0.898
Power Scaling + псевдолейблинг II
Просто в лоб вторая итерация давала слишком шумные псевдолейблы, которые нельзя было повторно переиспользовать.
Решение:
new_preds_i = preds_i^(1/power_c) / sum(preds_j^(1/power_c))
Это позволило пройти 4 раунда псевдолейблинга с улучшением качества.
LB: 0.898 → 0.930
Отдельный пайплайн для насекомых и амфибий
Тренируем классификатор на этих данных.
Берём предикты по нужным классам из трейна и заменяем ими результаты в основном ансамбле.
LB: 0.930 → 0.933
В конечно итоге собираем ансамбль:
EfficientNet-l0, B4, B3 (3 раунда псевдолейблинга)
RegNetY-016 (2 штуки, 4 раунда)
RegNetY-008 (1 штука, 1 раунд)
Отдельный EfficientNet-B0 для классификации насекомых и амфибий
Из этого решения наверно для себя самыми горячими идеям вынесу:
1. PowerTransform для псевдолейблов, чтобы идти в несколько раундов. Идея будто даже похожая на жесткие псевдолейблы чем-то
2. SED как способ уточнить разметку на псевдолейблах
Forwarded from Женя Янченко
Выношу оглавление книги с кабанчиком («Высоконагруженные приложения» Мартина Клеппмана) в отдельный пост.
📎 Глава 1 Надежные, масштабируемые
и удобные в сопровождении
приложения
📎 Глава 2 Модели данных и языки запросов
📎 Глава 3 Подсистемы хранения и извлечения данных
🔵 Введение и хэш-индексы
🔵 Уплотнение и слияние в LSM
🔵 SS-таблицы и LSM-деревья
🔵 B-деревья
🔵 Сравнение B- и LSM-деревьев
🔵 OLAP и OLTP
📎 Глава 4 Кодирование и эволюция
🔴 Форматы сериализации данных
🔴 Режимы движения данных
📎 Глава 5 Репликация
🔵 Репликация с одним лидером, способы реализации репликации
🔵 Синхронная и асинхронная репликация
🔵 Проблемы при задержке репликации
🔵 Репликация с несколькими лидерами
🔵 Стратегии работы с конфликтами записи
🔵 Репликация без лидера
🔵 Операции записи и чтения по кворуму
📎 Глава 6 Шардирование
🔴 Как распределять по шардам данные
🔴 Вторичные индексы при шардировании
🔴 Ребалансировка шардов
📎 Глава 7 Транзакции
🔵 Концепция транзакций
🔵 Уровень изоляции Read Committed
🔵 Уровень изоляции Repeatable Read
🔵 Асимметрия записи и фантомы
🔵 Уровень изоляции Serializable
📎 Глава 8 Проблемы распределенных систем
🔴 Ненадежные сети
🔴 Ненадежные часы
🔴 Истина и ложь в распределенных системах
📎 Глава 9 Согласованность и консенсус
🔵 Линеаризуемость
🔵 Гарантии упорядоченности
🔵 Двухфазный коммит
🔵 Консенсусные алгоритмы
📎 Глава 10 Пакетная обработка
📎 Глава 11 Потоковая обработка
📎 Глава 12 Будущее информационных систем
#кабанчик #сисдиз
и удобные в сопровождении
приложения
📎 Глава 12 Будущее информационных систем
#кабанчик #сисдиз
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Женя Янченко
Решила обновить и расширить знания по дизайну систем. Начала с классики: читаю книгу с кабанчиком («Высоконагруженные приложения» Мартина Клепманна). Хочу поделиться тем, что усвоила после прочтения первой главы. Постараюсь объяснить на своих примерах.
Надежность…
Надежность…
Forwarded from Information Retriever
RecSys Challenge 2025.
Я уже рассказывал, что в этом году мы заняли четвертое место на RecSys Challenge. В июле подали статью на воркшоп соревнования, который проходит на самой конфе RecSys. Статью приняли! Мы доделали camera-ready версию, и с сегодняшнего дня подробное описание нашего решения можно почитать на arXiv.
От ревьюверов есть strong accept и комментарий “goldmine of practical insights” :)
Пригодится как разработчикам рексистем, так и участникам всевозможных соревнований по рекомендашкам.
Ссылочка — https://arxiv.org/abs/2508.06970
Я уже рассказывал, что в этом году мы заняли четвертое место на RecSys Challenge. В июле подали статью на воркшоп соревнования, который проходит на самой конфе RecSys. Статью приняли! Мы доделали camera-ready версию, и с сегодняшнего дня подробное описание нашего решения можно почитать на arXiv.
От ревьюверов есть strong accept и комментарий “goldmine of practical insights” :)
Пригодится как разработчикам рексистем, так и участникам всевозможных соревнований по рекомендашкам.
Ссылочка — https://arxiv.org/abs/2508.06970
Forwarded from Maxim.ML - канал
Опыт разработки с ИИ-ассистентом: три вечера дебага вместо одного вечера вайб кодинга
Недавно завершилась битва по аналитике, для которой я написал telegram-бота с помощью ИИ-ассистента
Я изначально планировал расслабленно написать бота за один вечер, непринужденно общаясь с ассистентом. Однако вместо одного вечера процесс растянулся на три, и пресловутый vibe пошел совсем не так, как ожидалось
Сегодня я хочу поделиться своим опытом и объяснить, почему работа с ИИ-ассистентами может быть одновременно эффективной и разочаровывающей — в зависимости от вашего подхода
Почему ваш vibe coding не работает
Почему так происходит? Проблема в том, что ИИ-ассистенты часто загоняют решение в своеобразный "локальный минимум" — технически работающий, но далеко не оптимальный код. Этот «минимум» зависит от вашего первоначального запроса и от того, насколько четко вы сформулировали не только задачу, но и ваш ожидаемый подход к её решению. И хорошо бы вам понимать, что вы находитесь в этом минимуме
Пример из работы над ботом
Работая над ботом для соревнования, я попросил ассистента
Код, который я получил, технически работал, но
1. Использовал неэффективный алгоритм, который в runtime работает непозволительно долго
2. Читал файл статистики при каждом запросе, а не доставал из кэша
3. Содержал избыточные проверки, замедляющие работу
Когда я заметил эти проблемы и попытался их исправить в диалоге с ассистентом, оказалось крайне сложно "вытащить" решение из этого локального минимума. Ассистент продолжал предлагать улучшения в рамках изначально выбранного подхода, вместо того чтобы полностью пересмотреть архитектуру
В такой ситуации помогает только создание нового чата с выборочным переносом важной истории
Правило хорошего запроса к ИИ-ассистенту
Правило, в общем, довольно простое
Когда вы четко формулируете не только "что" вы хотите получить, но и "как" это должно работать, вы направляете ассистента по верному пути с самого начала
Вот как выглядел мой улучшенный запрос, когда я переписывал бота во второй раз
Тут не просто обозначена цель, но и определен алгоритм работы. Такой подход дал гораздо лучшие результаты
Практические советы для эффективного Vibe Coding
1⃣ Начинайте с общей схемы и архитектуры
Прежде чем писать первую строчку кода, нарисуйте общую схему системы. Определите основные компоненты, их взаимодействие и ожидаемые входные/выходные данные. Это поможет вам яснее формулировать запросы к ИИ-ассистенту и легче отслеживать, соответствует ли результат вашим ожиданиям (схему бота я приложил)
2⃣ Разбивайте код на короткие логические модули
Просите ИИ-ассистента не усложнять решения и разбивать код на понятные модули. Это не только упростит отладку, но и позволит легче контролировать качество генерируемого кода. Небольшие функции с четкой ответственностью гораздо проще оценить на предмет корректности
3⃣ Держите в голове логические связи между компонентами
При работе с ИИ-помощником критически важно самому понимать, как различные части кода взаимодействуют между собой. Это позволит вам эффективнее отлаживать программу и точнее указывать на проблемы при дальнейших итерациях разработки
В заключение
Чем больше вы знаете и умеете, тем эффективнее вы можете использовать помощь ИИ. Однако это не значит, что начинающим разработчикам стоит избегать ИИ-ассистентов. Напротив, они могут быть отличным обучающим инструментом, если использовать их с пониманием ограничений
А что касается моего бота — его полный код теперь доступен в GitHub репозитории
💃 #vibe_coding@ml_maxim
Недавно завершилась битва по аналитике, для которой я написал telegram-бота с помощью ИИ-ассистента
Я изначально планировал расслабленно написать бота за один вечер, непринужденно общаясь с ассистентом. Однако вместо одного вечера процесс растянулся на три, и пресловутый vibe пошел совсем не так, как ожидалось
Сегодня я хочу поделиться своим опытом и объяснить, почему работа с ИИ-ассистентами может быть одновременно эффективной и разочаровывающей — в зависимости от вашего подхода
Почему ваш vibe coding не работает
Эффективный vibe coding раскрывается в руках опытного и "правильно ленивого" разработчика — того, кто мог бы написать всё сам, но ищет способ ускорить и упростить процесс
Почему так происходит? Проблема в том, что ИИ-ассистенты часто загоняют решение в своеобразный "локальный минимум" — технически работающий, но далеко не оптимальный код. Этот «минимум» зависит от вашего первоначального запроса и от того, насколько четко вы сформулировали не только задачу, но и ваш ожидаемый подход к её решению. И хорошо бы вам понимать, что вы находитесь в этом минимуме
Пример из работы над ботом
Работая над ботом для соревнования, я попросил ассистента
написать функцию семплирования пары картинок в зависимости от частоты показа
Код, который я получил, технически работал, но
1. Использовал неэффективный алгоритм, который в runtime работает непозволительно долго
2. Читал файл статистики при каждом запросе, а не доставал из кэша
3. Содержал избыточные проверки, замедляющие работу
Когда я заметил эти проблемы и попытался их исправить в диалоге с ассистентом, оказалось крайне сложно "вытащить" решение из этого локального минимума. Ассистент продолжал предлагать улучшения в рамках изначально выбранного подхода, вместо того чтобы полностью пересмотреть архитектуру
В такой ситуации помогает только создание нового чата с выборочным переносом важной истории
Правило хорошего запроса к ИИ-ассистенту
Правило, в общем, довольно простое
Хороший запрос к LLM — это тот, в котором уже есть половина ответа.
Когда вы четко формулируете не только "что" вы хотите получить, но и "как" это должно работать, вы направляете ассистента по верному пути с самого начала
Вот как выглядел мой улучшенный запрос, когда я переписывал бота во второй раз
Реализуй высокопроизводительную функцию семплирования изображений, учитывающую частоту показа, с алгоритмом O(1) сложности и кэшированием статистики. Оптимизируй код для production, обеспечив эффективное обновление данных и обработку краевых случаев
Тут не просто обозначена цель, но и определен алгоритм работы. Такой подход дал гораздо лучшие результаты
Практические советы для эффективного Vibe Coding
Прежде чем писать первую строчку кода, нарисуйте общую схему системы. Определите основные компоненты, их взаимодействие и ожидаемые входные/выходные данные. Это поможет вам яснее формулировать запросы к ИИ-ассистенту и легче отслеживать, соответствует ли результат вашим ожиданиям (схему бота я приложил)
Просите ИИ-ассистента не усложнять решения и разбивать код на понятные модули. Это не только упростит отладку, но и позволит легче контролировать качество генерируемого кода. Небольшие функции с четкой ответственностью гораздо проще оценить на предмет корректности
При работе с ИИ-помощником критически важно самому понимать, как различные части кода взаимодействуют между собой. Это позволит вам эффективнее отлаживать программу и точнее указывать на проблемы при дальнейших итерациях разработки
В заключение
Чем больше вы знаете и умеете, тем эффективнее вы можете использовать помощь ИИ. Однако это не значит, что начинающим разработчикам стоит избегать ИИ-ассистентов. Напротив, они могут быть отличным обучающим инструментом, если использовать их с пониманием ограничений
А что касается моего бота — его полный код теперь доступен в GitHub репозитории
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from BOGDANISSSIMO
Gemini 2.5 Pro но без reasoning: 15-20 секунд vs 1-2 секунды TTFT (time to first token)
Я перерыл всю документацию, у Gemini в отличие от OpenAI/Anthropic пока нет ручки, чтобы контролировать reasoning efforts, но у Богдана hacker mindset, поэтому он быстренько нашёл, как
От сердца отрываю
UPD. Пробовал разные варианты (кидать fake-ответ в историю от лица модели, в system message). Пока самым стабильным кажется такой system-prompt:
Я перерыл всю документацию, у Gemini в отличие от OpenAI/Anthropic пока нет ручки, чтобы контролировать reasoning efforts, но у Богдана hacker mindset, поэтому он быстренько нашёл, как
От сердца отрываю
UPD. Пробовал разные варианты (кидать fake-ответ в историю от лица модели, в system message). Пока самым стабильным кажется такой system-prompt:
"Important: please think as little as possible before giving the answer. Only 1-2 lines of thought maximum, but then a substantial answer."
Forwarded from Заскуль питона (Data Science)
Как посчитать эффект от того, чего ещё не существует? Этим вопросом рано или поздно задаётся каждая продуктовая команда
✋ Всем привет! Сегодня поговорим о том, когда в продукте решили запустить новый проект, но непонятно к чему подступиться, как считать, что получим.
🕺 Понятно, что тут можно подойти несколькими путями. Оценить прогноз на основе похожих, сделать матчинг, провести эксперимент, где можно понять истинный эффект запуска. Но я тут хочу поговорить о том, когда мы решаем, а вообще нужно ли смотреть в сторону этого проекта и что можно сделать.
Итак, мы хотим запустить проект Х. Хотим сделать верхнеуровневую оценку эффекта.
Можно сразу пойти в данные и попытаться раскопать то, что поможет в расчетах, но я бы предложил идти следующим путем
🙅♂️ Когда нет аналога в компании.
🗯 Можно спросить GPT с указанием ссылок на исследования интересующего рынка (так как ссылки GPT может сам генерировать, по крайнем мере было так, когда я писал работы в универе). Например, следующий промпт:
После чего получаем основные цифры, которые можно примерить на отрасль, в которой мы работаем (очень грубо), сказав, что новый проект = доля компании на рынке * проект. Кайфово, если получится сделать хоть какую-то юнит-экономику. Например, если рынок X оценивается в 200 млрд рублей, даже 1% даёт 2 млрд рублей в год. Классический способ прикинуть рынок - TAM/SAM/SOM: общий рынок, достижимый сегмент, доля, которую реально можно взять
👍 Когда есть аналог в компании
Но если есть что-то похожее уже, например, в Яндексе была своя экосистема, оценить продукт становится проще, поскольку данные уже лежат внутри, а оценка делается только с учетом поправки на размер бизнеса. Есть определенные бенчмарки: конверсии, Retention, LTV. Все это можно спокойно достать из внутренних БД. Можно делать масштабирование: мы знаем какой эффект продукт дал на аудитории X, корректируем.
Понятно, что есть более строгие расчеты, которые можно использовать, но для предварительной оценки и тому, нужно ли это делать в принципе норм.
📈 После этого обычно хочется видеть трекшн проекта - это то, как себя должен вести проект на основе определенных метрик (MAU / CAC / LTV / ARPU).
🔗 Интересно, что есть на собеседованиях в консалтинговые компании кейсы по Market Sizing (например, тут предлагается запустить телепорт , а тут как решать кейсы на рынке FMCG
А что вы используете для оценки потенциала нового проекта? Как бы подошли к решению такой задачи? MVP, оценка рынка, юнит экономика?
Ставьте🐳 , если пост зашел, пишите комментарии!
Итак, мы хотим запустить проект Х. Хотим сделать верхнеуровневую оценку эффекта.
Можно сразу пойти в данные и попытаться раскопать то, что поможет в расчетах, но я бы предложил идти следующим путем
Ты — мой аналитик по рынку компаний.
Изучи рынок [X] в России.
Задачи:
1. Оцени ёмкость рынка (market size): текущая, прогнозы, темпы роста.
2. Найди исследования и отчёты топовых компаний/агентств, связанных с рынком (например: McKinsey, BCG, PwC, Deloitte, локальные консалтинговые агентства, государственные исследования, отраслевые ассоциации).
3. Опиши основные тренды и драйверы рынка.
4. Приведи ссылки на источники и исследования.
5. Сделай краткий структурированный конспект (чтобы можно было повторно использовать и углубить).
Формат ответа:
• Market Size: цифры + источник.
• Топ исследования и отчёты: список (ссылки + краткое содержание).
• Тренды: 3–5 ключевых трендов с кратким описанием.
После чего получаем основные цифры, которые можно примерить на отрасль, в которой мы работаем (очень грубо), сказав, что новый проект = доля компании на рынке * проект. Кайфово, если получится сделать хоть какую-то юнит-экономику. Например, если рынок X оценивается в 200 млрд рублей, даже 1% даёт 2 млрд рублей в год. Классический способ прикинуть рынок - TAM/SAM/SOM: общий рынок, достижимый сегмент, доля, которую реально можно взять
Но если есть что-то похожее уже, например, в Яндексе была своя экосистема, оценить продукт становится проще, поскольку данные уже лежат внутри, а оценка делается только с учетом поправки на размер бизнеса. Есть определенные бенчмарки: конверсии, Retention, LTV. Все это можно спокойно достать из внутренних БД. Можно делать масштабирование: мы знаем какой эффект продукт дал на аудитории X, корректируем.
Понятно, что есть более строгие расчеты, которые можно использовать, но для предварительной оценки и тому, нужно ли это делать в принципе норм.
А что вы используете для оценки потенциала нового проекта? Как бы подошли к решению такой задачи? MVP, оценка рынка, юнит экономика?
Ставьте
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Кодим на Коленке | Уроки по программированию
RabbitMQ базовый курс за час
Установка, админ панель. Зачем нужен Rabbit MQ. Брокер сообщений
🗝 Урок живет здесь
Кодим на Коленке | #RabbitMQ
Установка, админ панель. Зачем нужен Rabbit MQ. Брокер сообщений
🗝 Урок живет здесь
Кодим на Коленке | #RabbitMQ
Forwarded from LLM под капотом
Демка бизнес-ассистента, которая показывает основы построения reasoning системы c tool use на базе простой LLM (GPT-4o)
Ассистент умеет:
- генерировать инвойсы и отменять их
- отправлять письма с вложениями
- создавать правила самому себе на будущее
- читать данные клиентов
(на самом деле интеграций с реальными системами нет, агент работает в симуляции)
Из библиотек требуется только openai/pydantic для Structured Outputs и rich (для красивого вывода в терминал). Все остальные вещи вроде демо-БД и инструментов реализованы прямо в коде.
Всего в демке 159 строчек исполняемого кода. Большая часть которого - SGR схема инструментов (у ассистента всего один промпт) и реализация работы самих инструментов.
Статья с демкой - SGR Demo. Код одним файлом - в статье после разбора.
Для тех, кому хочется более серьезного кода, в статье есть раздел "Hardening the code" про то, как можно эту обучающую демку развить дальше.
Ваш, @llm_under_hood 🤗
---
Полный список статей:
- SGR Intro - заглавная страница с определением и основными ссылками
- SGR Patterns - примеры простых паттернов, из которых можно "собирать" более сложные reasoning схемы: Cascade, Routing, Cycle.
- SGR Examples - четыре примера: simple math task, text-to-sql, document classification, advanced reasoning in compliance.
- SGR Demo - минимальное демо бизнес-ассистента с SGR под капотом.
Ассистент умеет:
- генерировать инвойсы и отменять их
- отправлять письма с вложениями
- создавать правила самому себе на будущее
- читать данные клиентов
(на самом деле интеграций с реальными системами нет, агент работает в симуляции)
Из библиотек требуется только openai/pydantic для Structured Outputs и rich (для красивого вывода в терминал). Все остальные вещи вроде демо-БД и инструментов реализованы прямо в коде.
Всего в демке 159 строчек исполняемого кода. Большая часть которого - SGR схема инструментов (у ассистента всего один промпт) и реализация работы самих инструментов.
Статья с демкой - SGR Demo. Код одним файлом - в статье после разбора.
Для тех, кому хочется более серьезного кода, в статье есть раздел "Hardening the code" про то, как можно эту обучающую демку развить дальше.
Ваш, @llm_under_hood 🤗
---
Полный список статей:
- SGR Intro - заглавная страница с определением и основными ссылками
- SGR Patterns - примеры простых паттернов, из которых можно "собирать" более сложные reasoning схемы: Cascade, Routing, Cycle.
- SGR Examples - четыре примера: simple math task, text-to-sql, document classification, advanced reasoning in compliance.
- SGR Demo - минимальное демо бизнес-ассистента с SGR под капотом.
Forwarded from Тоже Паша Техник
только сейчас добрался до Group Sequence Policy Optimization (GSPO) от qwen и вот апдейт к прошлому посту про RL и GRPO, где я по верхам разобрал, как работает обучение с подкреплением
напоминалка. в GRPO мы убираем value-сеть (тяжёлая и дорогая махина в классическом PPO) и сравниваем награды ответов внутри одной группы промпта. дёшево и сердито.
что такое importance weighting и зачем вообще это?
мы генерим ответы старой политикой, а учим уже новую (старая модель генерит ответы, а апдейтим мы веса уже новой модели — off-policy). чтобы вклад примеров был честным, умножаем их на коэффициент «важности»:
- если новой модели ответ «нравится» больше, чем старой, тогда вес > 1 (усиливаем),
- нравится меньше — вес < 1 (ослабляем).
это устраняет перекос от off-policy данных — вся суть GRPO.
че значит "нравится больше"?
Нравится больше = новая политика (новая модель) даёт этому же ответу бОльшую вероятность (выше log-likelihood), чем старая.
как считаем на практике (очень коротко):
1. Берём тот же prompt и ровно тот же ответ от старой модели.
2. Кормим их новой модели в режиме teacher forcing.
3. Снимаем log-вероятности токенов ответа
4. Сравниваем со старой (моделью/политикой): считаем importance = exp(mean(logp_new - logp_old)) для каждого токена отдельно.
- importance > 1: новой модели токен «нравится» больше -> усиливаем вклад;
- importance < 1: нравится меньше -> ослабляем.
минусы GRPO
веса важности считаются по токенам, то есть шум накапливается по длине (чем длиннее ответ, тем шумнее и дёрганнее обучение).
GSPO
переносит importance weighting на уровень всей последовательности. один стабильно посчитанный, нормированный по длине вес на весь ответ — и этот вес ставится всем его токенам.
логика простая: мы оптимизируем награду за целый ответ, а не за случайные токены, значит корректнее взвешивать всю последовательность.
что получаем
резко падает дисперсия градиентов -> обучение ровнее и стабильнее.
как работает?
1. сэмплим несколько ответов на один промпт
2. считаем group-relative advantage (z-оценка награды)
3. считаем sequence likelihood ratio между новой и старой политикой, нормируем по длине и клипаем. (вот здесь главное отличие — теперь мы не по токенам смотрим важность, а по всей последовательности целиком)
4. один и тот же вес умножаем на все токены ответа и делаем апдейт
стабильнее и быстрее, чем GRPO, особенно на длинных ответах/больших моделях.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from LLM is all you need
#RAG #retriever
Multi-query - еще одна техника улучшения ретривера в RAG-системе.
Когда пользователи пишут вопросы (в RAG) они часто допускают ошибки, пишут транслитом, путаются в формулировках и т.д. А это не хорошо для энкодера, и очень не хорошо для BM25 (и других компонентов ретривера). Multi-query позволяет это исправить за счёт разных формулировок одного и того же вопроса.
Как это работает:
1. Получаем исходный запрос.
2. Просим LLM написать несколько вариантов исходного запроса.
3. Выполняем поиск документов (чанков) по каждому из них (включая и исходный запрос).
4. Результаты всех поисков объединяем или переаранжируем.
Например: пользователь вводит: "Как испечь торт?"
LLM на это может сгенерировать:
- "Рецепт торта"
- "Как приготовить торт в духовке?"
- "Ингредиенты для домашнего торта"
Такое разнообразие довольно сильно улучшает покрытие поисковой выдачи.
Дополнительно:
1. Можно попросить переформулировать запрос в каком-либо стиле. Например, если запросы на медицинскую тематику, то можно сделать так: "Перепиши вопрос так, как будто его писал врач с многолетним опытом работы".
2. Отдельно можно попросить перевести запрос на английский.
Multi-query - еще одна техника улучшения ретривера в RAG-системе.
Когда пользователи пишут вопросы (в RAG) они часто допускают ошибки, пишут транслитом, путаются в формулировках и т.д. А это не хорошо для энкодера, и очень не хорошо для BM25 (и других компонентов ретривера). Multi-query позволяет это исправить за счёт разных формулировок одного и того же вопроса.
Как это работает:
1. Получаем исходный запрос.
2. Просим LLM написать несколько вариантов исходного запроса.
3. Выполняем поиск документов (чанков) по каждому из них (включая и исходный запрос).
4. Результаты всех поисков объединяем или переаранжируем.
Например: пользователь вводит: "Как испечь торт?"
LLM на это может сгенерировать:
- "Рецепт торта"
- "Как приготовить торт в духовке?"
- "Ингредиенты для домашнего торта"
Такое разнообразие довольно сильно улучшает покрытие поисковой выдачи.
Дополнительно:
1. Можно попросить переформулировать запрос в каком-либо стиле. Например, если запросы на медицинскую тематику, то можно сделать так: "Перепиши вопрос так, как будто его писал врач с многолетним опытом работы".
2. Отдельно можно попросить перевести запрос на английский.