#interview #analytics

#llm #ml #systemdesign

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 с примерами

#llm #ml #systemdesign #prompt

Иллюстрация к посту про Schema-Guided Reasoning (SGR)

Ваш, @llm_under_hood 🤗

#ml #systemdesign #interview

Про мой доклад на 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: хайп или игра в долгую":
🔹 Пока склоняемся к "хайп"
🔹 Но продолжаем наблюдать за ситуацией

Привет, товарищи-статистики!

Наконец-то написал про еще один метод последовательного тестирования, но очень свежий!

YEAST - YEt Another Sequential Test от ребят из Zalando от 2024-го года.

Это вам не методы из 40-х / 70-х / 80-х, которые индустрия переоткрыла для себя (хоть я и считаю, что Group Sequential Testing + "тщеность" бытия усилий самый простой, лаконичный и понятный из них + легче реализовывается)

Я наткнулся на него случайно: решил посмотреть на создателя известного калькулятора по AB - Эвана Миллера, в его ленте в Линкедин наткнулся на пост как раз про этот тест. И это оказалось - красиво!

Кажется, ребята смогли реализовать мечту многих начинающих AB-щников, а точнее даже типичного заказчика: при какой конкретно сумме транзакций / РТО / конверсий (условно, по B, но там чуть хитрее) мы сможем сказать, что результаты действительно лучше и надо катить. Так-то обычно заказчиками и начинающим после в ответ начинают рассказывать про критерии, и те немного начинают унывать от каких-то статистик, t-распределений..

Метод "идеалогически" является альтернативой всем ранее представленным тестам, работает с аблютной величиной метрики, - максимальная конкретика вместо t, лямбд и пр., - не нуждается в определении моделей данных как тот же (m)SPRT.

Метод уже внедрен в AB-платформу Zalando и является их стандартом.

Подготовил для вас, дорогие товарищи, максимально разжеванный разбор метода, в том числе математики, а она там может привести в уныние и бывалого :) Даже Эван намекнул: "they (Zalando) do real math instead of my 18th century aristocratic hand-waving" (он пытался что-то такое реализовать давненько)

Давайте поймём YEAST: Yet Another Sequential Test

#softskills #career

Применимая в реальной работе модификация RICE

За последнее время уже с несколькими людьми из разных компаний обсуждал, как я модифицировал метод приоритизации RICE, и все говорили: «Да! У нас тоже все эти ситуации и проблемы есть!»

Да кто такой этот ваш RICE?
Длинный ответ можно прочитать, например, тут https://productstar.ru/rice.

А если коротко, то это метод приоритизации задач по нескольким критериям. Когда вам напихивают за воротник целый пучок задач, вы можете благодаря ему аргументированно понять, что вы в работу берете, а на что уже ручек не хватает.

Критерии простые (как я люблю):
- Reach (охват) – количество пользователей, которых затронет предлагаемая фича.
- Impact (влияние) – в некоторой мере оценочное суждение, насколько важна и нужна фича, насколько сильно она повлияет на пользователей.
- Confidence (уверенность) – степень уверенности в двух предыдущих оценках. Одно дело – вы подробный рисерч провели, а другое – вы пальцем в небо ткнули на основании своих ощущений.
- Effort (усилия) – трудозатраты на выполнение.

В теории это всё. Мол, так делайте, и спина болеть не будет.

Но на практике работы в разных командах и компаниях, где у моих команд было много заказчиков, я вывел еще два дополнительных критерия.

Коэффициент обманщика (пишу вам тут литературно приемлемым языком)
Помните сказку про мальчика, который кричал «Волки!»?

Так нередко встречается и в жизни. Есть заказчики, которые говорят: «Это точно очень надо», ты им делаешь, а они потом не пользуются. Или те, кто говорит: «Очень срочно!!!», ты делаешь, а они только откроют посмотреть недели через две-три. Или те, кто говорит: «Это блокер! Без этого нельзя продолжать работу!!!», а при детальном рассмотрении оказывается, что просто у пары людей из десятков что-то медленно работает и надо ждать дольше, чем обычно.

Все примеры – это настоящие истории. А то вдруг подумаете, что это я сочинил для красного словца, ведь кто будет в здравом уме обманывать и драматизировать?)

Ну так вот, зная таких граждан и статистику их поведения, можно закладывать коэффициент понижения.

Коэффициент офигевшего
А еще бывает порой так, что вы посчитали все коэффициенты и задача объективно не сильно важна. А иногда даже просто от неё 0 профита. НО эту задачу хочет видеть какой-нибудь высокий/важный/громкий руководитель. И тогда у вас появляется сильно повышающий множитель.

Примеры тут тоже видел разные:
- На А/Б тестировании проверили, что автогенеренные картинки и крафтовые имеют одну и ту же кликабельность и один и тот же профит. Но у важного руководителя, видимо, нет другой важной работы, он отсматривает каждую картиночку и настаивает, чтобы было «сексуально» (я не выдумываю, это цитата). В результате люди будут кратно тратить больше времени и сил, чтобы босс был доволен, что у стрелочки не прямой хвостик, а волнистый.
- Очередная пассия начальника придумала (ни с кем не обсудив, конечно) и выдала в свою соцсеть, что компания сделает какой-то ивент. Теперь у отдела маркетинга новые планы 🙂
- Один руководитель хочет положить себе в резюме недостающий кусочек менеджерского пазла, и теперь у команды новый проект.

Итог
Нам часто на курсах, в книгах и статьях рассказывают очень складную теорию, которую можно применить к абстрактной задаче и понять, что делать дальше.

Но в реальной жизни не бывает объективных и отстраненных аргументов. Даже в компаниях с культурой эффективности и продуктовости. А уж в компаниях, где такой культуры нет, тем более будет человеческий фактор очень сильно выражен.

Так что, на моем опыте, RICE подойдет для 70-90% задач (я их называю политически нейтральными), но оставшиеся 10-30% будут обмазаны дополнительными понижающими и повышающими коэффициентами, и вам придется с этим смириться. Везде так. Различается только частотой и силой проявления.

#audio #gan #petproject