Forwarded from Статистика и R в науке и аналитике
Diff-in-Diff на самом деле
Вокруг методов квазиэкспериментов (diff-in-diff, regression discontinuity, Propensity Score Matching и тд), которые применяются в случае, когда A/B невозможен, есть некая атмосфера крутизны. Считается, что обычные A/B тесты это база, которую умеют делать все, а вот методы причинного вывода это реально сложно и интересно. Хотя все понимают (надеюсь), что с точки зрения валидности и надежности выводов правильно задизайненный и проведенный A/B тест опережает все вышеперечисленное. Все остальные квазиэксперименты это "A/B для бедных". Тем не менее, иногда действительно нет возможности провести A/B тест по разным причинам. Например, он технически невозможен или этически недопустим, однако эффект все равно оценить нужно, тогда без квазиэкспериментов никак.
У меня самой было в планах наконец-то разобраться с этими методами, так как это интересно, а еще про это любят спрашивать на собеседованиях 😏.
И вот оно: по работе возникла задача посчитать влияние уже внедренной фичи, которую запускали сразу на 100% без A/B (были на это причины). Это как раз типичный кейс применения diff-in-diff. Я обрадовалась возможности с этим разобраться на реальных данных (ооо наконец-то сложные методы), так что поставила задачку на себя и пошла читать статьи как это работает.
Оказалось, что аналитики в очередной раз назвали умными словами обычную линейную регрессию с двумя факторами и взаимодействием. Основная сложность метода не в формуле, а как обычно в наличии качественных данных и в умении правильно их приготовить. Например, нужно выбрать подходящую контрольную группу или построить синтетическую, проверить выполняются ли параллельные тренды до вмешательства, при необходимости добавить ковариаты, но это уже детали.
Общую идею метода неплохо объяснили в статье на хабре, но мне немного показалось, что в статье есть то самое "назвать простое сложным".
Сама формула:
Как видите, это обычная формула линейной регрессии с взаимодействием, где
β0 (Intercept) – значение интересующего показателя, например конверсии, в контрольной группе до воздействия.
β1 – значение показателя в тестовой группе до воздействия.
β2 – значение показателя в контрольной группе после воздействия.
β3 – тот самый эффект взаимодействия, Diff-in-Diff, дополнительное изменение конверсии в тестовой группе после воздействия по сравнению с контрольной группой.
Никакой сложной математики, старая добрая линейная регрессия в тренде 😎
Пример кода на🖥
Пример кода на🐍
Самое главное для применения метода подобрать подходящий контроль с соблюдением параллельности трендов до воздействия, а дальше сама формула занимает буквально две строчки. И необязательно делать вид, что это что-то супер сложное и крутое, потому что по сравнению с моделями, с которыми сталкиваются ученые, это совсем не рокет саенс🤓
Вот еще несколько полезных ссылок:
1) Статья из книги Causal Inference for the Brave and True
2) Небольшая заметка на kaggle
3) Хорошая статья от X5 на хабре
👇 В комментарии приложила пример кода для генерации подходящих под Diff-in-Diff данных на R и Python
#analytics #stats
Вокруг методов квазиэкспериментов (diff-in-diff, regression discontinuity, Propensity Score Matching и тд), которые применяются в случае, когда A/B невозможен, есть некая атмосфера крутизны. Считается, что обычные A/B тесты это база, которую умеют делать все, а вот методы причинного вывода это реально сложно и интересно. Хотя все понимают (надеюсь), что с точки зрения валидности и надежности выводов правильно задизайненный и проведенный A/B тест опережает все вышеперечисленное. Все остальные квазиэксперименты это "A/B для бедных". Тем не менее, иногда действительно нет возможности провести A/B тест по разным причинам. Например, он технически невозможен или этически недопустим, однако эффект все равно оценить нужно, тогда без квазиэкспериментов никак.
У меня самой было в планах наконец-то разобраться с этими методами, так как это интересно, а еще про это любят спрашивать на собеседованиях 😏.
И вот оно: по работе возникла задача посчитать влияние уже внедренной фичи, которую запускали сразу на 100% без A/B (были на это причины). Это как раз типичный кейс применения diff-in-diff. Я обрадовалась возможности с этим разобраться на реальных данных (ооо наконец-то сложные методы), так что поставила задачку на себя и пошла читать статьи как это работает.
Оказалось, что аналитики в очередной раз назвали умными словами обычную линейную регрессию с двумя факторами и взаимодействием. Основная сложность метода не в формуле, а как обычно в наличии качественных данных и в умении правильно их приготовить. Например, нужно выбрать подходящую контрольную группу или построить синтетическую, проверить выполняются ли параллельные тренды до вмешательства, при необходимости добавить ковариаты, но это уже детали.
Общую идею метода неплохо объяснили в статье на хабре, но мне немного показалось, что в статье есть то самое "назвать простое сложным".
Сама формула:
y = β0 + β1*treat + β2*post + β3*(treat × post) + ε
Как видите, это обычная формула линейной регрессии с взаимодействием, где
β0 (Intercept) – значение интересующего показателя, например конверсии, в контрольной группе до воздействия.
β1 – значение показателя в тестовой группе до воздействия.
β2 – значение показателя в контрольной группе после воздействия.
β3 – тот самый эффект взаимодействия, Diff-in-Diff, дополнительное изменение конверсии в тестовой группе после воздействия по сравнению с контрольной группой.
Никакой сложной математики, старая добрая линейная регрессия в тренде 😎
Пример кода на
# предварительно уже создан df, в комментарии пришлю как сгенерировать
model <- lm(y ~ treat*post, data = data)
summary(model)
Пример кода на
# предварительно уже создан df, в комментарии пришлю как сгенерировать
import statsmodels.formula.api as smf # ключевой import для работы с Diff-in-Diff
df['did'] = df['treat'] * df['post'] # создание переменной взаимодействия
model = smf.ols("y ~ treat + post + did", data=df).fit()
print(model.summary())
Самое главное для применения метода подобрать подходящий контроль с соблюдением параллельности трендов до воздействия, а дальше сама формула занимает буквально две строчки. И необязательно делать вид, что это что-то супер сложное и крутое, потому что по сравнению с моделями, с которыми сталкиваются ученые, это совсем не рокет саенс
Вот еще несколько полезных ссылок:
1) Статья из книги Causal Inference for the Brave and True
2) Небольшая заметка на kaggle
3) Хорошая статья от X5 на хабре
#analytics #stats
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Ars Poetica Numeralis
Внезапный препринт про обход защиты (по генерации нежелательного контента) в современных LLM через переписывание промптов в поэтической форме:
Adversarial Poetry as a Universal Single-Turn Jailbreak Mechanism in Large Language Models
https://arxiv.org/pdf/2511.15304
Цитата из абстракта:
TL/DR: Our central hypothesis is that poetic form operates as a general-purpose jailbreak operator
Пересказ на русском: https://www.ixbt.com/news/2025/11/23/pojeticheskij-dzhejlbrejk-stihi-okazalis-kljuchom-k-obhodu-ogranichenij-bolshih-jazykovyh-modelej.html
Adversarial Poetry as a Universal Single-Turn Jailbreak Mechanism in Large Language Models
https://arxiv.org/pdf/2511.15304
Цитата из абстракта:
We present evidence that adversarial poetry functions as a universal single-turn jailbreak technique for Large Language Models (LLMs). Across 25 frontier proprietary and open-weight models, curated poetic prompts yielded high attack-success rates (ASR), with some providers exceeding 90%.
TL/DR: Our central hypothesis is that poetic form operates as a general-purpose jailbreak operator
Пересказ на русском: https://www.ixbt.com/news/2025/11/23/pojeticheskij-dzhejlbrejk-stihi-okazalis-kljuchom-k-obhodu-ogranichenij-bolshih-jazykovyh-modelej.html
Forwarded from Б/У ml
Коллеги, вы как боретесь с item cold start?
Сегодня расскажу про статью от Google: «Item-centric Exploration for Cold Start Problem»
На недавнем RecSys 2025 было много неплохих работ, которые зацепили сходу.
Сегодня хочу рассказать про простую идею, которую можно переиспользовать везде, где важна вероятность.
Например, для кандидатогенерации. В моем докладе про кросскат мы предсказываем не айтемы, а категории товаров. Для каждой категории находим вероятность и пропорционально ей семплируем уже айтемы из этой категории.
Проблемы рекомендательных систем:
Допустим, мы научились предсказывать вероятность клика/контакта от показа — но насколько такой вероятности можно доверять?
Если айтем новенький и по нему мало коллаборативных фичей-счетчиков, то модели ранжирования поставят его сильно ниже. Похожая ситуация и в кандидатогенерации.
Что предлагают авторы:
Давайте не показывать айтемы слепо. Посчитаем честную конверсию для айтема из показа в клик/контакт. Также у нас уже есть обученная модель ранжирования, которая предсказывает персональную вероятность клика S на айтем для конкретного пользователя.
Если персональная вероятность меньше, чем глобальная вероятность клика - 2 * std, то этот айтем можно не показывать пользователю — с большой вероятностью он ему не интересен.
Но получается, что мы уменьшаем пул айтемов, не предлагая ничего взамен?
Тут на арену выходят параметры alpha и beta. Когда мы считаем честную вероятность N+/N (N+ — положительное событие "клик/контакт", N — показы), мы можем добавить в числитель alpha, а в знаменатель — alpha + beta.
Таким образом, если у айтема было много N+, то alpha и beta не внесут большого вклада — мы уверены в истинной конверсии айтема.
Но если айтем холодный, то alpha и beta значительно скорректируют (повысят) его расчетную конверсию.
На картинке представлена полная картина: условия фильтрации (1), перерасчитанная конверсия (2) и поправка для оценки std (3).
Результат:
Метод позволяет без дополнительного обучения модели поднять выдачу для холодных айтемов.
Мои мысли:
Такую поправку очень легко использовать в современных индустриальных рекомендательных системах — расчет количества контактов/кликов и показов это уже решенная задача.
Для ранжирования можно дешево "прогревать" новые категории объявлений, не переобучая модель ранжирования, что обходится кратно дороже.
Для кандидатогенерации — чуть сложнее. Если брать в расчет вероятностные кандгены — например, на базе semantic ids, где можно посчитать вероятность на этапе инференса — то, добавив поправку, можно настроить количество свежих айтемов для пользователя. Для векторного отбора кандидатов — сложнее, так как вероятность будет известна уже после похода в БД за кандидатами.
Вот такие мысли по статье :)
Делитесь, как еще вы решаете cold-start проблему для айтемов.
Сегодня расскажу про статью от Google: «Item-centric Exploration for Cold Start Problem»
На недавнем RecSys 2025 было много неплохих работ, которые зацепили сходу.
Сегодня хочу рассказать про простую идею, которую можно переиспользовать везде, где важна вероятность.
Например, для кандидатогенерации. В моем докладе про кросскат мы предсказываем не айтемы, а категории товаров. Для каждой категории находим вероятность и пропорционально ей семплируем уже айтемы из этой категории.
Проблемы рекомендательных систем:
Допустим, мы научились предсказывать вероятность клика/контакта от показа — но насколько такой вероятности можно доверять?
Если айтем новенький и по нему мало коллаборативных фичей-счетчиков, то модели ранжирования поставят его сильно ниже. Похожая ситуация и в кандидатогенерации.
Что предлагают авторы:
Давайте не показывать айтемы слепо. Посчитаем честную конверсию для айтема из показа в клик/контакт. Также у нас уже есть обученная модель ранжирования, которая предсказывает персональную вероятность клика S на айтем для конкретного пользователя.
Если персональная вероятность меньше, чем глобальная вероятность клика - 2 * std, то этот айтем можно не показывать пользователю — с большой вероятностью он ему не интересен.
Но получается, что мы уменьшаем пул айтемов, не предлагая ничего взамен?
Тут на арену выходят параметры alpha и beta. Когда мы считаем честную вероятность N+/N (N+ — положительное событие "клик/контакт", N — показы), мы можем добавить в числитель alpha, а в знаменатель — alpha + beta.
Таким образом, если у айтема было много N+, то alpha и beta не внесут большого вклада — мы уверены в истинной конверсии айтема.
Но если айтем холодный, то alpha и beta значительно скорректируют (повысят) его расчетную конверсию.
На картинке представлена полная картина: условия фильтрации (1), перерасчитанная конверсия (2) и поправка для оценки std (3).
Результат:
Метод позволяет без дополнительного обучения модели поднять выдачу для холодных айтемов.
Мои мысли:
Такую поправку очень легко использовать в современных индустриальных рекомендательных системах — расчет количества контактов/кликов и показов это уже решенная задача.
Для ранжирования можно дешево "прогревать" новые категории объявлений, не переобучая модель ранжирования, что обходится кратно дороже.
Для кандидатогенерации — чуть сложнее. Если брать в расчет вероятностные кандгены — например, на базе semantic ids, где можно посчитать вероятность на этапе инференса — то, добавив поправку, можно настроить количество свежих айтемов для пользователя. Для векторного отбора кандидатов — сложнее, так как вероятность будет известна уже после похода в БД за кандидатами.
Вот такие мысли по статье :)
Делитесь, как еще вы решаете cold-start проблему для айтемов.
Forwarded from Быть CTO – подкаст о c-level карьере в айти
План выживания руководителя с новой командой
В новом выпуске мы с Мишей говорим про 5 фатальных ошибок, из-за которых отношения с командой могут не сложиться.
Реальный опыт: как заходить в новую команду, когда ты не самый сильный эксперт в техническом домене своей команды, но от тебя ждут решений.
Обсуждаем:
• почему опасно доказывать команде, что ты «тут самый умный»
• как не работать «в тумане», если у бизнеса нет внятной стратегии
• что делать, если ты еще не понимаешь продукт и код, а решения принимать нужно вчера
• как не превратить людей в «ресурсы» и при этом сохранять план и жёсткость
• почему попытка тащить всё одному ломает и тебя, и команду
Видео особенно зайдёт тем, кому:
• уже дали новую команду,
• вот-вот отдадут,
• или кто сейчас в роли тимлида/руководителя чувствует, что отношения с командой шаткие.
Смотреть на YouTube
Смотреть на VK Видео
В новом выпуске мы с Мишей говорим про 5 фатальных ошибок, из-за которых отношения с командой могут не сложиться.
Реальный опыт: как заходить в новую команду, когда ты не самый сильный эксперт в техническом домене своей команды, но от тебя ждут решений.
Обсуждаем:
• почему опасно доказывать команде, что ты «тут самый умный»
• как не работать «в тумане», если у бизнеса нет внятной стратегии
• что делать, если ты еще не понимаешь продукт и код, а решения принимать нужно вчера
• как не превратить людей в «ресурсы» и при этом сохранять план и жёсткость
• почему попытка тащить всё одному ломает и тебя, и команду
Видео особенно зайдёт тем, кому:
• уже дали новую команду,
• вот-вот отдадут,
• или кто сейчас в роли тимлида/руководителя чувствует, что отношения с командой шаткие.
Смотреть на YouTube
Смотреть на VK Видео
Forwarded from Находки в опенсорсе
Аллокаторы в СPython: база
Тема аллокаторов иногда питонистам кажется сложной, потому что в питоне мы их не вызываем явно. Оттого с ними не очень знакомы, так давайте исправлять и знакомиться!
Зачем вообще нужно много разных аллокаторов? Все они делают одно и то же: выделяют память в куче (heap). В зависимости от наших вариантов использования данной памяти - выделять и освобождать её нужно очень по-разному.
Где-то множество мелких объектов, которые часто создаются и очищаются. Где-то несколько больших, которые должны умирать все вместе. Где-то мы работаем в рамках одного потока, где-то несколько потоков будут запрашивать / высвобождать память параллельно.
Например: при парсинге AST мы используем PyArena аллокатор. Он выделяет сразу много памяти, сразу вычищает все за один раз. Что идеально подходит для парсинга.
Но, для рантайма - задачи, конечно же другие. Там есть долгоживущие объекты, есть много мелких краткоживущих, есть довольно большие, есть маленькие. Для таких задач используют "general purpose allocators". Которые в среднем хороши во всем.
Дизайн аллокаторов в CPython
Питон знает, как его будут использовать. Потому поверх базовых GPA есть собственные надстройки.
Документация:
- https://docs.python.org/3/c-api/allocation.html
- https://docs.python.org/3/c-api/memory.html
В CPython есть: malloc, pymalloc, mimalloc и некоторые их варианты для дебага.
Они разделены на три "домена" для аллокаторов, то с чем они работают, какие задачи решают:
-
-
-
Разработчики C-extensions должны понимать, когда какой использовать и под какие задачи.
К счастью, разработчикам на питоне - такое нужно только для любопытства.
А вот таблица, какие реальные аллокаторы используют те или иные C-API функции в разных режимах:
Она правда немного устарела и не отражает Free-Threading сборки, которые требуют mimalloc 🌚
Кто первый успеет сделать PR с исправлением - тот молодец!
О
Зачем питону свой аллокатор?
В CPython есть (был? для free-threading он не используется и не будет) свой аллокатор: pymalloc, основная задача которого – работа с маленькими Python объектами.
Про него полностью тоже нужно писать большой отдельный пост.
Что вообще важно в аллокаторе?
- Стратегия выделения памяти под новый запрос
- Работа с округлениями размера памяти и выравнивание
- Дефрагментация памяти
- Стратегия очистки памяти
Но кратко про
- Он создает арены по 1MB
- Внутри арены разделены на пулы по 16KB
- Внутри пулы поделены на блоки фиксированного размера
Зачем? Чтобы не аллоцировать часто маленькие кусочки памяти. Что дорого.
Можно ли управлять аллокаторами?
Да! Есть опции для сборки:
И даже переменная окружения PYTHONMALLOC, которая позволяет указать, какой аллокатор использовать для всех случаев. Зачем? Прежде всего для дебага. Но можно потестить, вдруг будет давать буст по скорости или потреблению памяти в ваших вариантах использования.
Обсуждение: какой ваш любимый аллокатор? И почему jemalloc?
| Поддержать | YouTube | GitHub | Чат |
Тема аллокаторов иногда питонистам кажется сложной, потому что в питоне мы их не вызываем явно. Оттого с ними не очень знакомы, так давайте исправлять и знакомиться!
Зачем вообще нужно много разных аллокаторов? Все они делают одно и то же: выделяют память в куче (heap). В зависимости от наших вариантов использования данной памяти - выделять и освобождать её нужно очень по-разному.
Где-то множество мелких объектов, которые часто создаются и очищаются. Где-то несколько больших, которые должны умирать все вместе. Где-то мы работаем в рамках одного потока, где-то несколько потоков будут запрашивать / высвобождать память параллельно.
Например: при парсинге AST мы используем PyArena аллокатор. Он выделяет сразу много памяти, сразу вычищает все за один раз. Что идеально подходит для парсинга.
Но, для рантайма - задачи, конечно же другие. Там есть долгоживущие объекты, есть много мелких краткоживущих, есть довольно большие, есть маленькие. Для таких задач используют "general purpose allocators". Которые в среднем хороши во всем.
Дизайн аллокаторов в CPython
Питон знает, как его будут использовать. Потому поверх базовых GPA есть собственные надстройки.
Документация:
- https://docs.python.org/3/c-api/allocation.html
- https://docs.python.org/3/c-api/memory.html
В CPython есть: malloc, pymalloc, mimalloc и некоторые их варианты для дебага.
Они разделены на три "домена" для аллокаторов, то с чем они работают, какие задачи решают:
-
Raw: для выделения памяти для общих задач, например под сишные буферы или IO. Может работать без PyThreadState-
Mem: для выделения памяти для общих задач, но уже с PyThreadState, например под Python буферы, подходит для мелких объектов-
Object: для выделения памяти под конкретные мелкие объектыРазработчики C-extensions должны понимать, когда какой использовать и под какие задачи.
К счастью, разработчикам на питоне - такое нужно только для любопытства.
А вот таблица, какие реальные аллокаторы используют те или иные C-API функции в разных режимах:
PyMem_RawMalloc -> malloc
PyMem_Malloc -> pymalloc
PyObject_Malloc -> pymalloc
Она правда немного устарела и не отражает Free-Threading сборки, которые требуют mimalloc 🌚
Кто первый успеет сделать PR с исправлением - тот молодец!
О
mimalloc мы как-нибудь отдельно поговорим, там нужно рассказывать сильно глубже, в том числе про GC и PyGC_Head.Зачем питону свой аллокатор?
В CPython есть (был? для free-threading он не используется и не будет) свой аллокатор: pymalloc, основная задача которого – работа с маленькими Python объектами.
Про него полностью тоже нужно писать большой отдельный пост.
Что вообще важно в аллокаторе?
- Стратегия выделения памяти под новый запрос
- Работа с округлениями размера памяти и выравнивание
- Дефрагментация памяти
- Стратегия очистки памяти
struct arena_object {
uintptr_t address;
pymem_block* pool_address;
uint nfreepools;
uint ntotalpools;
struct pool_header* freepools;
struct arena_object* nextarena;
struct arena_object* prevarena;
};
Но кратко про
pymalloc можно сказать следующее:- Он создает арены по 1MB
- Внутри арены разделены на пулы по 16KB
- Внутри пулы поделены на блоки фиксированного размера
Зачем? Чтобы не аллоцировать часто маленькие кусочки памяти. Что дорого.
Можно ли управлять аллокаторами?
Да! Есть опции для сборки:
--without-mimalloc, --without-pymallocИ даже переменная окружения PYTHONMALLOC, которая позволяет указать, какой аллокатор использовать для всех случаев. Зачем? Прежде всего для дебага. Но можно потестить, вдруг будет давать буст по скорости или потреблению памяти в ваших вариантах использования.
Обсуждение: какой ваш любимый аллокатор? И почему jemalloc?
| Поддержать | YouTube | GitHub | Чат |
Python documentation
Allocating Objects on the Heap
Deprecated aliases: These are soft deprecated aliases to existing functions and macros. They exist solely for backwards compatibility.,, Deprecated alias, Function,,,, PyObject_New,,, PyObject_NewV...
Forwarded from Находки в опенсорсе
git-lfs: храним большие файлы в репозитории правильно
https://www.youtube.com/watch?v=82wj6y2rmR4
Вы сталкивались с проблемой, что рабочий проект клонируется 10 минут?
А когда начинаешь разбираться: почему так? То оказывается, что внутри десятки непережатых картинок для фронта, которые еще и менялись регулярно (а значит, оставили след в истории git навсегда).
Данная проблема влияет не только на локальное использование, ведь мы на самом деле довольно редко делаем
Решение: использовать git-lfs!
Я пригласил замечательного Олега Чирухина @tg_1red2black, чтобы обсудить:
- Как работает git-lfs на базовом уровне?
- Как мигрировать на него с базового сетапа?
- Как он устроен внутри? Поднимаем https://github.com/git-lfs/lfs-test-server и детально смотрим, что там внутри происходит
Ну и конечно чуть-чуть глянули исходники, они, кстати, на #go 🌚️️️️
Обсуждение: как вы храните большие файлы в рабочих проектах? Насколько большие файлы вы храните?
| Поддержать | YouTube | GitHub | Чат |
https://www.youtube.com/watch?v=82wj6y2rmR4
Вы сталкивались с проблемой, что рабочий проект клонируется 10 минут?
А когда начинаешь разбираться: почему так? То оказывается, что внутри десятки непережатых картинок для фронта, которые еще и менялись регулярно (а значит, оставили след в истории git навсегда).
Данная проблема влияет не только на локальное использование, ведь мы на самом деле довольно редко делаем
git clone с нуля, но и самое главное – на скорость всех наших сборок (если мы не используем fetch-depth: 1 или аналог, а использовать их надо). Решение: использовать git-lfs!
Я пригласил замечательного Олега Чирухина @tg_1red2black, чтобы обсудить:
- Как работает git-lfs на базовом уровне?
- Как мигрировать на него с базового сетапа?
- Как он устроен внутри? Поднимаем https://github.com/git-lfs/lfs-test-server и детально смотрим, что там внутри происходит
Ну и конечно чуть-чуть глянули исходники, они, кстати, на #go 🌚️️️️
Обсуждение: как вы храните большие файлы в рабочих проектах? Насколько большие файлы вы храните?
| Поддержать | YouTube | GitHub | Чат |
YouTube
Находки в опенсорсе: git-lfs, не засоряй репозиторий большими файлами зря! #git
GigaCode – AI-ассистент разработчика c агентным режимом. Это полноценный помощник разработчика, способный понимать контекст проекта и выполнять задачи от анализа до готового решения. Ассистент сам открывает нужные файлы, вносит изменения, запускает тесты…
Forwarded from Всеволод Викулин | AI разбор
Фреймворк, как привести к успеху любой AI-проект
Самый частый вариант беседы, когда меня просят помочь с проектом:
Беседа потом идет примерно одинаково. Готовьтесь, дальше не будет никакого роя AI-агентов. Дальше будет нуднота.
Итеративный фреймворк управления проектом
AI — это работа с высокой неопределенностью. Нельзя все спланировать и пустить по канбану. Мы должны быть готовы, что что-то не взлетит. И это нормально. Нужно просто это как можно быстрее понять.
Элементом фреймворка является гипотеза. Гипотеза — это идея, что некоторое изменение улучшит качество AI-проекта. Например, что нужно LLM обновить до GPT 5.1. Гипотеза может быть в одном из трех состояний:
- Прототипирование. Нужно как можно скорее понять, а стоит ли инвестировать силы. Подробнее в статье.
- Оценка качества. Замерили и теперь понимаем успешная ли гипотеза. Гайд по замеру качества.
- Внедрение. Уверены, что гипотеза полезная. Разрабатываем и внедряем.
Любой проект начинается с самого простого и легко поддерживаемого решения. Например, чат-бот. Вначале просто API к GPT + простой промпт. Больше ничего. Смотрим недостатки (время/цена/галлюцинации/etc). Делаем гипотезу. Потом еще одну. Идею вы поняли.
Откуда берутся гипотезы
Нет, не из статей с хабра и даже не с arxiv.org. Гипотезы рождаются из анализа проблем. Типовой анализ выглядит примерно так:
- Собрали репрезентативный список задач в систему. Например, запросы в чат-бот за год.
- Оценили качество текущей системы.
- Разбили примеры с проблемами на понятные группы.
Дальше для групп проблем придумываем гипотезу, которая их должна починить.
Резюме
Только итеративный подход, где мы понимаем смысл каждого шага. Анализ проблем, прототипирование гипотезы, оценка качества, внедрение.
Если за всю жизнь я смогу донести только одну эту идею, я буду уверен, что все было не зря.
Ваше путешествие начинается с одного шага. Так написано на моей беговой дорожке. Уверен, эти ребята знают, о чем говорят.
Самый частый вариант беседы, когда меня просят помочь с проектом:
- Сева, вот смотри, хотим решить проблему X. Понятно?
- Пока да.
- Супер! Короче, мы взяли 15 ИИ-агентов, в них запихали 4 роутера, облили это все графовой базой знаний. И все это на 1.5B квене, который мы специально доучили, но код обучения случайно удалили.
- Уже понятно меньше, но допустим. А что вы от меня хотите?
- Вот оно у нас плохо работает...
Беседа потом идет примерно одинаково. Готовьтесь, дальше не будет никакого роя AI-агентов. Дальше будет нуднота.
Итеративный фреймворк управления проектом
AI — это работа с высокой неопределенностью. Нельзя все спланировать и пустить по канбану. Мы должны быть готовы, что что-то не взлетит. И это нормально. Нужно просто это как можно быстрее понять.
Элементом фреймворка является гипотеза. Гипотеза — это идея, что некоторое изменение улучшит качество AI-проекта. Например, что нужно LLM обновить до GPT 5.1. Гипотеза может быть в одном из трех состояний:
- Прототипирование. Нужно как можно скорее понять, а стоит ли инвестировать силы. Подробнее в статье.
- Оценка качества. Замерили и теперь понимаем успешная ли гипотеза. Гайд по замеру качества.
- Внедрение. Уверены, что гипотеза полезная. Разрабатываем и внедряем.
Любой проект начинается с самого простого и легко поддерживаемого решения. Например, чат-бот. Вначале просто API к GPT + простой промпт. Больше ничего. Смотрим недостатки (время/цена/галлюцинации/etc). Делаем гипотезу. Потом еще одну. Идею вы поняли.
Откуда берутся гипотезы
Нет, не из статей с хабра и даже не с arxiv.org. Гипотезы рождаются из анализа проблем. Типовой анализ выглядит примерно так:
- Собрали репрезентативный список задач в систему. Например, запросы в чат-бот за год.
- Оценили качество текущей системы.
- Разбили примеры с проблемами на понятные группы.
Дальше для групп проблем придумываем гипотезу, которая их должна починить.
Резюме
Только итеративный подход, где мы понимаем смысл каждого шага. Анализ проблем, прототипирование гипотезы, оценка качества, внедрение.
Если за всю жизнь я смогу донести только одну эту идею, я буду уверен, что все было не зря.
Ваше путешествие начинается с одного шага. Так написано на моей беговой дорожке. Уверен, эти ребята знают, о чем говорят.
Forwarded from Всеволод Викулин | AI разбор
А судьи кто? Гайд по LLM-as-a-judge
Оценка качества — ключ к фрейморку успешного AI-проекта. Если вы не овладете этим навыком, любые ваши AI-успехи, если они и будут, окажутся только случайной удачей. Недавно в моей статье мы бегло просмотрели эту тему.
Сегодня погрузимся в самый популярный метод — оценка качества моделей “LLM-as-a-judge”. В нем вместо оценки ответов людьми мы оцениваем ответы другой "LLM-судьей". Тут обычно все шутят, что критиковать всегда проще, чем творить. Мне шутка уже надоела, но законы жанра. Извините.
Когда использовать LLM-as-a-judge?
LLM дешевле, быстрее размечает, не жульничает, но хуже следует сложным инструкциям. Из этого вытекают кейсы, когда этот подход нужно применять вместо разметки людьми.
1) Разметка не слишком интеллектуальная. Она не требует ни:
а) фундаментальных экспертных знаний
б) сложных логических рассуждений
Например, оценить, был ли ответ модели в контексте, LLM-судья может. Но проверить, логически следует ли ответ из контекста, ей будет сложно.
2) Вам нужны очень быстрые итерации.
Гонка, пожар, стартап. Если вам нужно получать оценку качества через часы, а не дни.
3) У вас нет ресурсов.
Не только денег. Обучение разметчиков это обычное преподавание. Это материалы, ответы на вопросы, тесты, экзамены. Регулярные проверки, что они все не забыли и не жульничают. Это требует много сил и отдельного штата специалистов.
Как сделать LLM-судью? Пошаговый план
1) Берем бизнес-эксперта. Человека, который понимает, когда система работает правильно. Вместе с ним прорабатываем критерии, по которым оцениваем. Например, релевантность ответа, безопасность, достоверность и тд.
2) Вместе с экспертом размечаем по критериям репрезентативную корзинку ответов модели. Репрезентативная, значит это случайное подмножество реальных запросов в нашу систему.
3) Переразмечаем, спорим, пока мы с экспертом согласованно не разметим корзинку. Так мы поверяем, что мы сами поняли критерии. В итоге у нас получается «голден корзинка» таких эталонных примеров хороших и плохих ответов.
4) На части этой корзинки тюним LLM-судью. Тестируем итоговое качество на другой части. Тюнить можно по-разному: писать промпты, разбивать задачу на подзадачи (на каждый критерий можно отдельного судью), добавлять агентность. Можно даже файнтюнить LLM. Важно делать это итеративно, как и во всем AI-проекте.
Резюме
Это не просто дешевый, быстрый в разработке подход. Он еще очень гибкий. Если вы хотите поменять критерии качества, намного проще поменять промпты в LLM, чем переучивать 50 людей размечать по-новому.
Если ваша разметка явно не противоречит 3-м пунктам из этого поста, начните с LLM-as-a-judge, а не с разметки людьми. Если не получится, вы всегда сможете часть простых задач разметить LLM, а все сложные отправить людям. Или сможете давать людям LLM-подсказки, чтобы они могли быстрее размечать.
Пробуйте, пишите промпты, замеряйте качество, задавайте мне вопросы. Если оваладете оценкой качества, тогда никакой AI вам не будет страшен.
Оценка качества — ключ к фрейморку успешного AI-проекта. Если вы не овладете этим навыком, любые ваши AI-успехи, если они и будут, окажутся только случайной удачей. Недавно в моей статье мы бегло просмотрели эту тему.
Сегодня погрузимся в самый популярный метод — оценка качества моделей “LLM-as-a-judge”. В нем вместо оценки ответов людьми мы оцениваем ответы другой "LLM-судьей". Тут обычно все шутят, что критиковать всегда проще, чем творить. Мне шутка уже надоела, но законы жанра. Извините.
Когда использовать LLM-as-a-judge?
LLM дешевле, быстрее размечает, не жульничает, но хуже следует сложным инструкциям. Из этого вытекают кейсы, когда этот подход нужно применять вместо разметки людьми.
1) Разметка не слишком интеллектуальная. Она не требует ни:
а) фундаментальных экспертных знаний
б) сложных логических рассуждений
Например, оценить, был ли ответ модели в контексте, LLM-судья может. Но проверить, логически следует ли ответ из контекста, ей будет сложно.
2) Вам нужны очень быстрые итерации.
Гонка, пожар, стартап. Если вам нужно получать оценку качества через часы, а не дни.
3) У вас нет ресурсов.
Не только денег. Обучение разметчиков это обычное преподавание. Это материалы, ответы на вопросы, тесты, экзамены. Регулярные проверки, что они все не забыли и не жульничают. Это требует много сил и отдельного штата специалистов.
Как сделать LLM-судью? Пошаговый план
1) Берем бизнес-эксперта. Человека, который понимает, когда система работает правильно. Вместе с ним прорабатываем критерии, по которым оцениваем. Например, релевантность ответа, безопасность, достоверность и тд.
2) Вместе с экспертом размечаем по критериям репрезентативную корзинку ответов модели. Репрезентативная, значит это случайное подмножество реальных запросов в нашу систему.
3) Переразмечаем, спорим, пока мы с экспертом согласованно не разметим корзинку. Так мы поверяем, что мы сами поняли критерии. В итоге у нас получается «голден корзинка» таких эталонных примеров хороших и плохих ответов.
4) На части этой корзинки тюним LLM-судью. Тестируем итоговое качество на другой части. Тюнить можно по-разному: писать промпты, разбивать задачу на подзадачи (на каждый критерий можно отдельного судью), добавлять агентность. Можно даже файнтюнить LLM. Важно делать это итеративно, как и во всем AI-проекте.
Резюме
Это не просто дешевый, быстрый в разработке подход. Он еще очень гибкий. Если вы хотите поменять критерии качества, намного проще поменять промпты в LLM, чем переучивать 50 людей размечать по-новому.
Если ваша разметка явно не противоречит 3-м пунктам из этого поста, начните с LLM-as-a-judge, а не с разметки людьми. Если не получится, вы всегда сможете часть простых задач разметить LLM, а все сложные отправить людям. Или сможете давать людям LLM-подсказки, чтобы они могли быстрее размечать.
Пробуйте, пишите промпты, замеряйте качество, задавайте мне вопросы. Если оваладете оценкой качества, тогда никакой AI вам не будет страшен.
Forwarded from PRACTICAL AI Broadcast
Ночной пост, для тех кто потерялся в череде новых обновлений ИИ инструментов.
Ответ на вопрос кто такие Cursor, VS Code, Claude Code, AntiGravity и как они работают в интерактивном формате.
К слову, это новый формат ответа от Gemini Pro.
Теперь так, по одному запросу, можно получить сгенерированный лично под вас интерфейс - хоть инструкцию к использованию чего-то, хоть дашборд вашей эксельки.
https://gemini.google.com/share/5eb1ef25134b
Ответ на вопрос кто такие Cursor, VS Code, Claude Code, AntiGravity и как они работают в интерактивном формате.
К слову, это новый формат ответа от Gemini Pro.
Теперь так, по одному запросу, можно получить сгенерированный лично под вас интерфейс - хоть инструкцию к использованию чего-то, хоть дашборд вашей эксельки.
https://gemini.google.com/share/5eb1ef25134b
Gemini
Gemini - слушай можешь мне просто объяснить что такое вс код курсор клод код как они вообще работают и я не понимаю эту историю…
Created with Gemini
Forwarded from PRACTICAL AI Broadcast
Ребята, всем привет!
Мы с командой решили вернуться к истокам и разобрать базовые настройки ChatGPT.
Почему это важно, даже если вы профи?
Потому что ИИ — это не про штамповку одинаковых ответов, а про поток, некую сонастройку.
Чтобы нейросеть стала продолжением ваших мыслей, её нужно правильно забрифовать на уровне настроек.
Разобрали со Светой неочевидные фишки, которые мы сами используем каждый день, чтобы улучшить качество отклика.
Заходите посмотреть👇
Мы с командой решили вернуться к истокам и разобрать базовые настройки ChatGPT.
Почему это важно, даже если вы профи?
Потому что ИИ — это не про штамповку одинаковых ответов, а про поток, некую сонастройку.
Чтобы нейросеть стала продолжением ваших мыслей, её нужно правильно забрифовать на уровне настроек.
Разобрали со Светой неочевидные фишки, которые мы сами используем каждый день, чтобы улучшить качество отклика.
Заходите посмотреть👇
YouTube
Базовая настройка ChatGPT: что важно сделать в первую очередь
В этом видео разбираем, как настроить ChatGPT так, чтобы он перестал выдавать шум и начал работать как полноценный рабочий ассистент.
Покажем, что GPT знает о вас, как правильно настроить профиль и инструкции, и как подключить напоминания о встречах, как…
Покажем, что GPT знает о вас, как правильно настроить профиль и инструкции, и как подключить напоминания о встречах, как…