Forwarded from Data Secrets
How much do language models memorize? Новое исследование от Meta FAIR, Google DeepMind и NVIDIA
Задумывались когда-нибудь, сколько данных может запомнить модель с определенным количеством параметров? А сколько конкретно информации может выучить один параметр? А сколько информации он может обобщить?
Кажется, что посчитать это очень сложно или даже невозможно, но вот у ученых из этой статьи получилось: каждый параметр языковой модели способен запомнить примерно 3.6 бит информации. О том, как это посчитали – ниже.
Сразу дисклеймер: до этого были и другие статьи на эту тему, но там запоминание определялось просто тем, может ли модель воспроизвести определенный кусок трейна. На самом же деле все сложнее, и в этой работе подход не такой наивный.
➖ Авторы опираются на понятия из теории информации Колмогорова и Шеннона, и четко разделяют запоминание и обобщение. Если модель воспроизвела что-либо – не значит, что она это запомнила, а не обобщила. В обратную сторону – то же самое.
➖ Количество информации, которое модель именно запомнила, считают так. Берут две модели одинаковой архитектуры и размера: одна – референсная – обучена на огромном количестве данных, вторая – испытуемая – на ограниченном датасете.
Обе модели пропускают один и тот же тренировочный фрагмент через процедуру предсказания и вычисляют вероятности каждого токена. Если вторая модель даёт более высокие вероятности (то есть «тратит» на их декодинг меньше бит, чем референсная), она экономит относительно референсной модели определённое число бит. Сумма сэкономленных бит по всем фрагментам и есть общий объём выученной информации.
Вот так и получилось число 3.6 бит/параметр.
Самое важное, что этот показатель дает возможность четко определить момент перехода запоминания в обобщение: он происходит, когда объём данных в битах примерно равен общей ёмкости модели. И да, экспериментально это сходится: как раз на этом объеме данных тестовый лосс начинает резко падать. Это, кстати, часто называют грокингом.
Красота, как она есть arxiv.org/abs/2505.24832
Задумывались когда-нибудь, сколько данных может запомнить модель с определенным количеством параметров? А сколько конкретно информации может выучить один параметр? А сколько информации он может обобщить?
Кажется, что посчитать это очень сложно или даже невозможно, но вот у ученых из этой статьи получилось: каждый параметр языковой модели способен запомнить примерно 3.6 бит информации. О том, как это посчитали – ниже.
Сразу дисклеймер: до этого были и другие статьи на эту тему, но там запоминание определялось просто тем, может ли модель воспроизвести определенный кусок трейна. На самом же деле все сложнее, и в этой работе подход не такой наивный.
Обе модели пропускают один и тот же тренировочный фрагмент через процедуру предсказания и вычисляют вероятности каждого токена. Если вторая модель даёт более высокие вероятности (то есть «тратит» на их декодинг меньше бит, чем референсная), она экономит относительно референсной модели определённое число бит. Сумма сэкономленных бит по всем фрагментам и есть общий объём выученной информации.
Вот так и получилось число 3.6 бит/параметр.
Самое важное, что этот показатель дает возможность четко определить момент перехода запоминания в обобщение: он происходит, когда объём данных в битах примерно равен общей ёмкости модели. И да, экспериментально это сходится: как раз на этом объеме данных тестовый лосс начинает резко падать. Это, кстати, часто называют грокингом.
Красота, как она есть arxiv.org/abs/2505.24832
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from AbstractDL
Двоеточие взламывает reward-модель на базе GPT-4o
LLM, которые используются для оценки качества других моделей (reward models), оказались на удивление легковерными: они готовы дать положительную награду за совершенно пустые ответы, если те содержат "правильные" ключевые слова.
Например ответ "Thought process:" или "Solution" — часто засчитывается как верный. Иногда достаточно даже одного символа, например, двоеточия «:»!
FPR (доля ложно-правильных ответов) для LLaMA3-70B и Qwen2.5-72B на таких фразах доходит до 80-90%, а у GPT-4o на некоторых атаках превышает 30%.
В итоге модель, которую так обучают, просто перестает решать задачу и начинает спамить этими фразами. Классический reward hacking.
Статья, Huggingface
LLM, которые используются для оценки качества других моделей (reward models), оказались на удивление легковерными: они готовы дать положительную награду за совершенно пустые ответы, если те содержат "правильные" ключевые слова.
Например ответ "Thought process:" или "Solution" — часто засчитывается как верный. Иногда достаточно даже одного символа, например, двоеточия «:»!
FPR (доля ложно-правильных ответов) для LLaMA3-70B и Qwen2.5-72B на таких фразах доходит до 80-90%, а у GPT-4o на некоторых атаках превышает 30%.
В итоге модель, которую так обучают, просто перестает решать задачу и начинает спамить этими фразами. Классический reward hacking.
Статья, Huggingface
Forwarded from ML Baldini • Nikita Boyandin (Nikita Boyandin)
Техника n8n или почему он так хорош😃
В последнее время n8n стал одной из самых горячих тем в DS-сфере. Почему это произошло, чем с технической точки зрения он лучше конкурентов и какое развитие ждет продукт?
Человек, который в первых раз знакомится с этим приложением, видит no-code(можно еще назвать графовой, так как любой кубик является узлом) систему с различными инструментами. Их можно разделить на две типа:
- Узел-триггер : запускает выполнение вашего рабочего процесса. Это может быть отправка новой формы, электронное письмо в почтовом ящике или событие из другого приложения.
- Узлы действий : они определяют логику, конкретные приложения и действия в вашем рабочем процессе.
Действия могут включать в себя простые задачи, такие как сохранение данных в базе данных, отправка уведомлений или обновление задач в приложении для управления проектами. Они также могут включать более сложные действия, такие как отправка HTTP-запросов, запуск пользовательского кода Python или Javascript или генерация ИИ-подсказки с использованием ваших данных.
Почему он так удобен и что у него внутри?👀
1⃣ Ноды позволяют визуально представлять логику автоматизации, делая её интуитивно понятной, но при этом поддерживают сложные операции, такие как ветвление, слияние потоков и циклы.
2⃣ n8n предоставляет ноды, такие как Set, Split in Batches и Compare Datasets, которые используют алгоритмы для обработки и трансформации данных.
3⃣ n8n активно поддерживает интеграцию с AI-сервисами, такими как OpenAI, Perplexity и другими, через специализированные ноды (например, LLM Agent или OpenAI Audio Operations)
4⃣ n8n использует асинхронные алгоритмы для выполнения рабочих процессов, что позволяет обрабатывать задачи параллельно и управлять очередями заданий.
5⃣ n8n позволяет встраивать пользовательский код (JavaScript или TypeScript) в рабочие процессы через ноды.
Лучше ли он, чем конкуренты?💁♂
На рынке автоматизации, no-code и low-code платформ есть решения и с более понятным интерфейсом, да и у Zapier намного больше интеграций. Также лично для меня очень удобным кажется Make. Да и вопросы с безопасностью остаются.
Мое мнение😘
n8n старается убрать понятную и простую боль: все хотят участвовать в AI-революции, но мучаться с датасетами, их сбором и трансформации никто не хочет. По сути для меня это очередная мультиагентская система с прописанными функциями, которая легко автоматизирует простые процессы, так еще и с AI, но когда идет вопрос о разработке, все удобство уходит, так как вам вручную придется прописывать код на JavaScript, который не очень приспособлен к LLM фреймворкам и становится проще все написать на Python. Так что выбираем n8n для автоматизации проверки почты, скрапинга или других сценариев, которые описаны на их сайтов.
Полезные ссылки💃
1. Ноды разработанные комьюнити
2. Документация
3. Сделанные сценарии
4. Компании, которые уже внедрили n8n
Хотели бы видеть разбор других no-code систем или больше про мультиагентов?) Обязательно пишите свои мысли в комментариях, буду рад почитать💗
В последнее время n8n стал одной из самых горячих тем в DS-сфере. Почему это произошло, чем с технической точки зрения он лучше конкурентов и какое развитие ждет продукт?
Человек, который в первых раз знакомится с этим приложением, видит no-code(можно еще назвать графовой, так как любой кубик является узлом) систему с различными инструментами. Их можно разделить на две типа:
- Узел-триггер : запускает выполнение вашего рабочего процесса. Это может быть отправка новой формы, электронное письмо в почтовом ящике или событие из другого приложения.
- Узлы действий : они определяют логику, конкретные приложения и действия в вашем рабочем процессе.
Действия могут включать в себя простые задачи, такие как сохранение данных в базе данных, отправка уведомлений или обновление задач в приложении для управления проектами. Они также могут включать более сложные действия, такие как отправка HTTP-запросов, запуск пользовательского кода Python или Javascript или генерация ИИ-подсказки с использованием ваших данных.
Почему он так удобен и что у него внутри?
Лучше ли он, чем конкуренты?
На рынке автоматизации, no-code и low-code платформ есть решения и с более понятным интерфейсом, да и у Zapier намного больше интеграций. Также лично для меня очень удобным кажется Make. Да и вопросы с безопасностью остаются.
Мое мнение
n8n старается убрать понятную и простую боль: все хотят участвовать в AI-революции, но мучаться с датасетами, их сбором и трансформации никто не хочет. По сути для меня это очередная мультиагентская система с прописанными функциями, которая легко автоматизирует простые процессы, так еще и с AI, но когда идет вопрос о разработке, все удобство уходит, так как вам вручную придется прописывать код на JavaScript, который не очень приспособлен к LLM фреймворкам и становится проще все написать на Python. Так что выбираем n8n для автоматизации проверки почты, скрапинга или других сценариев, которые описаны на их сайтов.
Полезные ссылки
1. Ноды разработанные комьюнити
2. Документация
3. Сделанные сценарии
4. Компании, которые уже внедрили n8n
Хотели бы видеть разбор других no-code систем или больше про мультиагентов?) Обязательно пишите свои мысли в комментариях, буду рад почитать
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Start Career in DS
🐈 Твой будущий пет-проект поэтапно, ч. 2: парсим, предобрабатываем и изучаем данные
Прошлые части:
1. Откуда взять идею и данные
В прошлой части (которая невероятно быстро набрала 50 реакций!) мы рассказали, откуда можно взять идею для твоего пет–проекта. Скорее всего, она будет попадать в одну или несколько категорий из следующих 5 (в зависимости от того, что ты хочешь развивать):
– Аналитика + визуализация (e.g. сделать красивый дашборд)
– Обучение моделек (e.g. дообучить llmку)
– Сбор и подготовка данных (e.g. настроить регулярный парсинг)
– Развертывание моделей (e.g. поднять llamу)
– А/Б, проверка гипотез (e.g. провести стат тест)
В этой серии постов постараемся затронуть все категории проектов и их этапы. И первые этапы (сбор данных, предобработка и EDA) подходят для большинства категорий
# Сбор данных
В прошлой части рассказали про то, откуда брать данные, но не рассказали, что делать, если вы не нашли подходящего датасета. В таком случае можно найти источник, и:
1) Вытащить данные через API
– Вот тут лежит небольшой список самых очевидных API
– Обычно к API всегда есть документация, и достать оттуда данные не составляет проблемы
2) Если API нет, спарсить их
– Про парсинг мы уже писали подробный пост, которого вполне достаточно для большинства сайтов
– Если у сайта сильная защита, то, скорее всего, вам стоит подумать над другим источником данных 🙂
– Если не хочется писать скрипты, то есть готовые воркфлоу в хайповой lowcode платформе n8n, их можно найти тут (кстати, в бигтехах все чаще используется лоукод, если хотите пост про опенсорсный lowcode, то нужно набрать 50 сердечек ❤️ на этом посте)
# Предобработка данных
– Самую базу можно найти, например, в этой статейке
– Про предобработку текстов можно почитать тут
– Про работу с изображениями можно посмотреть слайды из Вышки
– Статейка с полезными штуками для препроцессинга временных рядов
# EDA (Исследовательский анализ данных)
– Разведочный анализ включает в себя построение графичков, тесное знакомство с данными, извлечение инсайтов из них
– Если вы новичок, и вам нужно понять, что такое exploratory data analysis, прочитайте эту статью
– Тут есть наш пост с ссылками на лекции Александра Дьяконова
– А еще мы писали про то, как чувак делал EDA для музыкантов с last.fm, менее научно, но можно посмотреть для развлечения
– Если вы решили делать пет-проект в рамках кагл-соревы, можете посмотреть пример EDA для соревнования
Чтобы вышла следующая часть, давайте наберем 150 🔥 под этим постом, и добьем второй уровень для канала (забустить по ссылке), чтобы мы могли публиковать сторисы
А еще обязательно пишите в комментариях свои вопросы по пет-проектам, и мы постараемся ответить на них прямо там же или в следующих частях 🙂
Прошлые части:
1. Откуда взять идею и данные
В прошлой части (которая невероятно быстро набрала 50 реакций!) мы рассказали, откуда можно взять идею для твоего пет–проекта. Скорее всего, она будет попадать в одну или несколько категорий из следующих 5 (в зависимости от того, что ты хочешь развивать):
– Аналитика + визуализация (e.g. сделать красивый дашборд)
– Обучение моделек (e.g. дообучить llmку)
– Сбор и подготовка данных (e.g. настроить регулярный парсинг)
– Развертывание моделей (e.g. поднять llamу)
– А/Б, проверка гипотез (e.g. провести стат тест)
В этой серии постов постараемся затронуть все категории проектов и их этапы. И первые этапы (сбор данных, предобработка и EDA) подходят для большинства категорий
# Сбор данных
В прошлой части рассказали про то, откуда брать данные, но не рассказали, что делать, если вы не нашли подходящего датасета. В таком случае можно найти источник, и:
1) Вытащить данные через API
– Вот тут лежит небольшой список самых очевидных API
– Обычно к API всегда есть документация, и достать оттуда данные не составляет проблемы
2) Если API нет, спарсить их
– Про парсинг мы уже писали подробный пост, которого вполне достаточно для большинства сайтов
– Если у сайта сильная защита, то, скорее всего, вам стоит подумать над другим источником данных 🙂
– Если не хочется писать скрипты, то есть готовые воркфлоу в хайповой lowcode платформе n8n, их можно найти тут (кстати, в бигтехах все чаще используется лоукод, если хотите пост про опенсорсный lowcode, то нужно набрать 50 сердечек ❤️ на этом посте)
# Предобработка данных
– Самую базу можно найти, например, в этой статейке
– Про предобработку текстов можно почитать тут
– Про работу с изображениями можно посмотреть слайды из Вышки
– Статейка с полезными штуками для препроцессинга временных рядов
# EDA (Исследовательский анализ данных)
– Разведочный анализ включает в себя построение графичков, тесное знакомство с данными, извлечение инсайтов из них
– Если вы новичок, и вам нужно понять, что такое exploratory data analysis, прочитайте эту статью
– Тут есть наш пост с ссылками на лекции Александра Дьяконова
– А еще мы писали про то, как чувак делал EDA для музыкантов с last.fm, менее научно, но можно посмотреть для развлечения
– Если вы решили делать пет-проект в рамках кагл-соревы, можете посмотреть пример EDA для соревнования
Чтобы вышла следующая часть, давайте наберем 150 🔥 под этим постом, и добьем второй уровень для канала (забустить по ссылке), чтобы мы могли публиковать сторисы
А еще обязательно пишите в комментариях свои вопросы по пет-проектам, и мы постараемся ответить на них прямо там же или в следующих частях 🙂
Хабр
Разведочный анализ (EDA)
Разведочный анализ данных, или EDA, – это как археологические раскопки в мире информации. Это первый шаг, когда мы берем на себя роль исследователя данных и начинаем расследовать, как устроены наши...
Forwarded from Тимлид Очевидность | Евгений Антонов
Я принес. Как я собеседовался в Ozon, Т-Банк, Mindbox и другие крупные компании
Сегодня я вам принес статью, которая уже за 650 плюсов на Хабре перевалила. Никогда не видел таких цифр там, если честно. 🙂
https://habr.com/ru/articles/926214/
Статья — большой лонгрид на полчаса, где человек рассказывает, как он ходил на собесы разработчиком и тимлидом на стеке .Net в кучу разных известных компаний. Описывает, какие этапы собесов, что спрашивали, что понравилось, что не понравилось, какой оффер в итоге выбрал и почему.
Особенно мне понравилось, что статья не хайпожерский хейт про то, что гады-капиталисты душат рабочий класс и вот на каком-то собесе меня кто-то обидел, поэтому они плохие. А прям всё по полочкам, довольно профессионально и содержательно, без излишних эмоций.
Моё искреннее уважение автору за такую качественную, подробную и полезную статью.
Сегодня я вам принес статью, которая уже за 650 плюсов на Хабре перевалила. Никогда не видел таких цифр там, если честно. 🙂
https://habr.com/ru/articles/926214/
Статья — большой лонгрид на полчаса, где человек рассказывает, как он ходил на собесы разработчиком и тимлидом на стеке .Net в кучу разных известных компаний. Описывает, какие этапы собесов, что спрашивали, что понравилось, что не понравилось, какой оффер в итоге выбрал и почему.
Особенно мне понравилось, что статья не хайпожерский хейт про то, что гады-капиталисты душат рабочий класс и вот на каком-то собесе меня кто-то обидел, поэтому они плохие. А прям всё по полочкам, довольно профессионально и содержательно, без излишних эмоций.
Моё искреннее уважение автору за такую качественную, подробную и полезную статью.
Хабр
Как я собеседовался в Ozon, Т-Банк, Mindbox и другие крупные компании
Всем привет. Я сеньор и тимлид на .NET (C#). До недавнего времени работал в Росатоме, пока там внезапно не сократили целую дирекцию по цифровизации. Так что пришлось срочно выходить на рынок, причём,...
Forwarded from AI Projects (Vladimir Ivanov)
Эту статью о позиционных кодировках (Positional Encoding, PE) в моем совместном творчестве с Gemini Pro 2.5 и Claude 4 Opus рекомендую прочитать как профессионалам, так и начинающим. Это одна из самых сложных концепций ИИ, поскольку нигде не описаны эмерджентные свойства PE. Везде лишь повторяют формулы на sin/cos, не объясняя, какие сложные и мощные эффекты они дают.
Забавно, что, пока я использовал Claude 4 как ревьюера нашей статьи и мы с Gemini предлагали ему разные примеры, у Claude сработал его «читерский паттерн», благодаря которому его агент прошел SWE Bench с результатом около 70%. Это якорная семантическая разметка для ИИ-патчеров кода/текста. По сути, в статье разбирается это know-how и объясняется, почему без таких якорей ИИ теряется даже на простой задаче исправления текста.
Тщательно разобраны все основные эмерджентные свойства PE на примерах.
Статья написана на основе постов в нашем Telegram-канале и чате, но ревью проводилось с выработкой предложений и критикой не только от Claude, но и от DeepSeek, LLaMA 4 и Grok, так как концепции действительно сложные, но я постарался их доступно изложить.
https://vk.com/@turboplanner-pozicionnye-kodirovki-obemnoe-zrenie-gpt-i-sekrety-ai-agento
Забавно, что, пока я использовал Claude 4 как ревьюера нашей статьи и мы с Gemini предлагали ему разные примеры, у Claude сработал его «читерский паттерн», благодаря которому его агент прошел SWE Bench с результатом около 70%. Это якорная семантическая разметка для ИИ-патчеров кода/текста. По сути, в статье разбирается это know-how и объясняется, почему без таких якорей ИИ теряется даже на простой задаче исправления текста.
Тщательно разобраны все основные эмерджентные свойства PE на примерах.
Статья написана на основе постов в нашем Telegram-канале и чате, но ревью проводилось с выработкой предложений и критикой не только от Claude, но и от DeepSeek, LLaMA 4 и Grok, так как концепции действительно сложные, но я постарался их доступно изложить.
https://vk.com/@turboplanner-pozicionnye-kodirovki-obemnoe-zrenie-gpt-i-sekrety-ai-agento
VK
Позиционные кодировки: «объемное зрение» GPT и секреты AI-агентов
Представьте, что вы можете взглянуть на тысячу строк кода и мгновенно, без единой задержки, понять всю его структуру: где какая функция,..
Forwarded from Заскуль питона (Data Science)
1. Целевая аудитория: прачки, служанки, крестьянские семьи.
2. Боли: тяжёлый труд, холодная вода, отсутствие времени, неудобство.
3. Конкуренты: ручная стирка, природные решения (водяные колёса).
4. Идея MVP: механическое устройство на водяной мельнице, стирающее сразу несколько вещей.
5. Метрики: количество отстиранного белья, удовлетворённость, сокращение времени.
6. Маркетинг: гонцы, слухи, ярмарки, церкви.
7. Ограничения: отсутствие технологий, нужны простые материалы (дерево, канаты).
8. Модели распространения: аренда, прачечные, версии для феодалов.
1. Плюсы: структура, работа с аудиторией.
2. Минусы: мало конкретики, не все гипотезы протестированы, нужны вопросы к нанимающему менеджеру (например: эпоха, регион, цели).
Как мне кажется, тут нужно было еще оценить объем рынка, необходимые инвестиции, возможно, к этому можно было бы подступиться через интервью, чтобы закрыть боли потенциальных клиентов.
1. Анализ конкурентов: Тинькофф, Сбер, Альфа -> кэшбэк, статус, бонусы.
2. Цели Яндекса: рост LTV, удержание, рост выручки.
3. Гипотеза: пользователи хотят кэшбэк и статус.
4. ЦА: частые пользователи Яндекс-сервисов, миллениалы, городские жители.
5. Фичи: доп. кэшбэк в экосистеме, приоритетная поддержка, лимит на переводы.
6. Тестирование: MVP за 2 (4?) недели, A/B-тесты, тест на разных ЦА.
7. Метрики: конверсия в подписку, выручка, удержание, NPS, ARPU.
8. Запуск: бесплатный пробный период, ретаргетинг, промо-кампании.
9. Юнит-экономика: оценка затрат, возврата, LT/CPA.
10. Приоритизация: фичи, которые решают боли, легко объясняются и измеримы.
* Сильная сторона - рыночный анализ и работа с метриками.
* Рекомендация: больше вопросов к контексту, чётче проработка бизнес-целей.
Показывают важность структурного мышления, установки границ, работы с метриками и понимания целей бизнеса.
Умение задать правильные вопросы нанимающему менеджеру - ключ к успешному решению.
Понравился пост? Ставьте
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from LLM под капотом
Schema-Guided Reasoning (SGR)
это метод структурированного промптинга, в котором заранее заданные схемы управляют рассуждениями больших языковых моделей, явно кодируя экспертные когнитивные процессы в процессе вывода.
Да, это тот самый SO CoT/Custom CoT, про который мы уже год говорим в нашем комьюнити. Только Custom Chain of Thought, несколько путает людей, а ведь паттерн позволяет паковать довольно сложные нелинейные рассуждения в один промпт.
Если более формально, то подход Schema-Guided Reasoning (SGR) позволяет управлять LLM, задавая явные сценарии рассуждений через типизированные схемы вывода. Constrained decoding вынудит модель последовательно заполнять эти схемы, а значит мы будет контроллировать не только финальную организацию информации, но и весь процесс.
Вместо расплывчатых инструкций (которые модель может игнорировать) вы прямо задаёте, как именно модель должна подходить к решению сложной задачи: от предварительного анализа до промежуточных проверок и сбора доказательств — фактически превращая ментальные чеклисты экспертов в строго заданные структуры.
Используя схемы (Structured Output/Constrained Decoding) вы получаете предсказуемые и контролируемые рассуждения, можете точно оценивать промежуточные результаты (evals), повышать качество и делать ход рассуждений модели - более прозрачным.
В схему можно закладывать не только онтологии (например, enums), но и ветвления (tagged unions in Pydantic), процедуры (nested objects), циклы (lists) и некоторые дополнительные ограничения (см иллюстрацию)
Почему это полезно:
(1) получаем более стабильные результаты при повторных вызовах, даже на разных моделях
(2) каждый шаг рассуждения становится явным и доступным для анализа.
(3) появляется возможность прямой оценки и улучшения промежуточных шагов (типизированные поля не требуют LLM-as-a-judge). А дальше - см quality is a trajectory.
(4) можно преобразовывать экспертный опыт и чеклисты в исполняемые сценарии. Сюда хорошо ложится DDD метолодогия.
(5) нередко получается прирост точности в 5-10% за счет контроля и возможности видеть цепочку рассуждений
(!) Повышается качество слабых моделей - особенно локальных (без SGR с ними работать почти невозможно)
Технология хорошо поддерживается OpenAI, Mistral, Fireworks AI и современными локальными движками для inference (например, vLLM, ollama, TensorRT). Gemini поддерживает частично.
Ваш, @llm_under_hood 🤗
PS: Английская статья про SGR с примерами
это метод структурированного промптинга, в котором заранее заданные схемы управляют рассуждениями больших языковых моделей, явно кодируя экспертные когнитивные процессы в процессе вывода.
Да, это тот самый SO CoT/Custom CoT, про который мы уже год говорим в нашем комьюнити. Только Custom Chain of Thought, несколько путает людей, а ведь паттерн позволяет паковать довольно сложные нелинейные рассуждения в один промпт.
Если более формально, то подход Schema-Guided Reasoning (SGR) позволяет управлять LLM, задавая явные сценарии рассуждений через типизированные схемы вывода. Constrained decoding вынудит модель последовательно заполнять эти схемы, а значит мы будет контроллировать не только финальную организацию информации, но и весь процесс.
Вместо расплывчатых инструкций (которые модель может игнорировать) вы прямо задаёте, как именно модель должна подходить к решению сложной задачи: от предварительного анализа до промежуточных проверок и сбора доказательств — фактически превращая ментальные чеклисты экспертов в строго заданные структуры.
Используя схемы (Structured Output/Constrained Decoding) вы получаете предсказуемые и контролируемые рассуждения, можете точно оценивать промежуточные результаты (evals), повышать качество и делать ход рассуждений модели - более прозрачным.
В схему можно закладывать не только онтологии (например, enums), но и ветвления (tagged unions in Pydantic), процедуры (nested objects), циклы (lists) и некоторые дополнительные ограничения (см иллюстрацию)
Почему это полезно:
(1) получаем более стабильные результаты при повторных вызовах, даже на разных моделях
(2) каждый шаг рассуждения становится явным и доступным для анализа.
(3) появляется возможность прямой оценки и улучшения промежуточных шагов (типизированные поля не требуют LLM-as-a-judge). А дальше - см quality is a trajectory.
(4) можно преобразовывать экспертный опыт и чеклисты в исполняемые сценарии. Сюда хорошо ложится DDD метолодогия.
(5) нередко получается прирост точности в 5-10% за счет контроля и возможности видеть цепочку рассуждений
(!) Повышается качество слабых моделей - особенно локальных (без SGR с ними работать почти невозможно)
Технология хорошо поддерживается OpenAI, Mistral, Fireworks AI и современными локальными движками для inference (например, vLLM, ollama, TensorRT). Gemini поддерживает частично.
Ваш, @llm_under_hood 🤗
PS: Английская статья про SGR с примерами
Forwarded from LLM под капотом
Forwarded from Обзоры Пива.txt
TL;DR: я прошёл кейс на антифрод в real estate. Фидбек положительный 👍
Как я понял, когда готовился, самое важное — это структура ответа. Я отвечал по такому пайплайну:
1) описываю задачу своими словами
2) выделяю пользу для бизнеса и для пользователя, бизнес, продукт метрики, контр-метрики.
3) формулирую задачу в рамках ML, что поступает на вход, а что на выход модели, оценка нагрузки
4) анализирую доступные данные, фичи + опр таргет
5) бейзлайн (если можно)
6) настраиваем мониторинг метрик (бизнесовые + системные)
7) дизайн аб-теста
8) указываю на проблемы и недостатки бейзлайна
9) продвинутое ml решение (доп фичи, DL)
10) дизайн аб-теста
11) выкатка в прод, вырисовка архитектуры (сервисы, бдшки), требуемые гпушки, оценка нагрузки RPM
Тема кейса — поиск фродовых итемов в недвижимости на Авито.
- Метрики, бизнесовая часть
- Быстро допёр до правильного определения "фрода" (тк меня однажды заскамили с арендой на Авито 😁)
- Бейзлайн
- Архитектура
- Софт скилы
- Когда усложнял решение туда-сюда размышлял, в итоге пришел к какому-то решению, но цепочка рассуждений была слабая
- Пытался как-то вставить разметку через LLM, в итоге был провальный ход, но я вышел из этого тупика сам
- АБ тестирование я кое-как с ошибками вытащил
- Волновался, интервьюер по идее не заметил, но из-за этого было труднее думать. В будущем конечно нужно над собой работать
Так бы я его выложил, конечно, с разрешения HR и интервьюера.
Я пока что в ожидании оффера. Так как собес прошел успешно и фидбек положительный, то я стану уважаемым мидлом (первого уровня), а не джунишкой-обоссышкой. Я очень рад!!
P.S. В комментариях к посту фотки моих рассуждений на доске.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Персонализация неизбежна
recsys-in-shopping-tmc25.pdf
5.3 MB
Про мой доклад на Turbo ML Conf 2025
Вчера выступил на конференции Т-Банка. Рассказал о том:
- Как мы видим академический research с точки зрения продуктовой команды
- Какие инсайты получили из продуктовой разработки (и чего не найдёшь в статьях)
- Как преобразовали продуктовую проблему в статью про SMMR
Ключевые тезисы:
1️⃣ Next-basket recommendation
По нашим экспериментам — не увеличивает GMV. Чем точнее предсказываешь корзину пользователя:
✔️ Больше используют рекомендации
✖️ Но пропорционально меньше пользуются поиском и каталогом
Есть надежды на uplift-рекомендации, но пока work in progress.
2️⃣ Формальный подход к фичам в ранкере
Мы пришли к почти формальной методике:
- Применима к любому сервису
- Покрывает почти все значимые признаки
- Позволяет генерировать тысячи фичей
Алгоритм:
1. Расписать все степени свободы
2. Выделить приоритетные
3. Реализовать
📌 Очень похожий подход описывал Иван Брагин в докладе про 3 место на VK RecSys Challenge
3️⃣ "Нельзя выучить то, чего нет"
Много докладов по recsys про более точные предсказания next item или улучшения трансформерных моделей. Но почти ничего про важное условие: это работает только при наличии персональных паттернов в данных
Пример:
❌ Если дачники не покупали семена в сервисе → никакая модель не порекомендует семена дачникам
✔️ Частичное решение через LLM: статья YouTube 2024
Вывод:
Качество рекомендаций = не только код, но и качество данных.
Как сказал DeepSeek: "На доброй земле и крапива цветёт, на худой и рожь сохнет."
4️⃣ RL в RecSys: год спустя
После прошлогоднего доклада "RL в RecSys: хайп или игра в долгую":
🔹 Пока склоняемся к "хайп"
🔹 Но продолжаем наблюдать за ситуацией
Вчера выступил на конференции Т-Банка. Рассказал о том:
- Как мы видим академический research с точки зрения продуктовой команды
- Какие инсайты получили из продуктовой разработки (и чего не найдёшь в статьях)
- Как преобразовали продуктовую проблему в статью про SMMR
Ключевые тезисы:
1️⃣ Next-basket recommendation
По нашим экспериментам — не увеличивает GMV. Чем точнее предсказываешь корзину пользователя:
✔️ Больше используют рекомендации
✖️ Но пропорционально меньше пользуются поиском и каталогом
Есть надежды на uplift-рекомендации, но пока work in progress.
2️⃣ Формальный подход к фичам в ранкере
Мы пришли к почти формальной методике:
- Применима к любому сервису
- Покрывает почти все значимые признаки
- Позволяет генерировать тысячи фичей
Алгоритм:
1. Расписать все степени свободы
2. Выделить приоритетные
3. Реализовать
📌 Очень похожий подход описывал Иван Брагин в докладе про 3 место на VK RecSys Challenge
3️⃣ "Нельзя выучить то, чего нет"
Много докладов по recsys про более точные предсказания next item или улучшения трансформерных моделей. Но почти ничего про важное условие: это работает только при наличии персональных паттернов в данных
Пример:
❌ Если дачники не покупали семена в сервисе → никакая модель не порекомендует семена дачникам
✔️ Частичное решение через LLM: статья YouTube 2024
Вывод:
Качество рекомендаций = не только код, но и качество данных.
Как сказал DeepSeek: "На доброй земле и крапива цветёт, на худой и рожь сохнет."
4️⃣ RL в RecSys: год спустя
После прошлогоднего доклада "RL в RecSys: хайп или игра в долгую":
🔹 Пока склоняемся к "хайп"
🔹 Но продолжаем наблюдать за ситуацией