В четверг выступал на одной конфе, где рассказывал про проект, который мы делаем уже полгода. Проект, который то умирал, то возрождался на протяжении последних трех лет. Это платформа для волонтеров, которые ищут суицидников в соцсетях по постам. Сейчас мы на середине пути, релиз будет летом 2025 года. Но поставить звёздочку репе можно уже сейчас.)

Заценить идею и результаты, которые есть сейчас, можно на записи в Ютубе или Рутубе.

Мы решили создать отдельный канал нашей команды, где будем вести некий дев-лог, хотя бы по месяцам. Также там будем писать о статьях научных, которые будем писать,но вы все равно читать про них будете, даже если не подпишетесь))).

Репостните, по-возможности.

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

Текст вы можете прочитать здесь.

Отдельно хочется сказать «спасибо» Тимуру с его курсами по писательству, которые я проходил год назад. Они явно помогли (и помогают) сделать текст лучше. Я прямо видел в какие моменты это срабатывало.

А конкурс выиграть, к сожалению, не удалось.

Я попался на целой одной фотографии. Здесь вы можете видеть, как я в центре демонстрирую мастер-класс по удлинению шеи.

# генерация данных

Решали задачу RAG по корпоративной базе данных. Использовали открытые модели от 7b до 70b, в том числе две версии Лламы и Сайгу.

Плюсы:
- можно генерировать неограниченное количество данных
- не содержат конфицденциальной информации
- можно котролировать характер данных
- получаем редкие или доменные данные

Проблемы:

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

Основная проблема, с которой столкнулись: сгенерированные данные — запросы пользователей — не совпадали с запросами реальных пользователей. Выход: перефразировать реальные запросы в синтетические (или наоборот).

Фишка проекта: он делался в условиях полного отсутствия данных. Именно по этому столкнулись с расхождением синтетики и реальных запросов. Сейчас на проекте 70 процентов данных — синтетика.

# Доклад про оценку БЯМ
## как оценить умность llm → бенчмарк

На ум приходят образовательные человеческие тексты, профессиональные тесты, специальные тесты для ЬЯМ.

Кастомные бенчи
- знание спецфактов
- провокации
- следование формату
- культурные код

С бенчмарками беда:
- протечки — попадание бенчней в тренировочную выборку.
- результат сильно зависит от способа замера.
- зависимость от опций ответов — у БЯМ есть предпочтения, какие из вариантов в тестах брать.
- тест != ум.

## как оценивать умность БЯМ → люди, лидерборд арена

Например, lmsys или Chatbot Arena.

Быстро, бесплатно, «объективно».

Есть проблемы:
- смещенные типы заданий и темы — на такие платформы приходят люди, интересующиеся БЯМ.
- смещение в формат ответа — у людей есть предпочтение на формат ответа.

## как оценивать умность БЯМ → разметка

Нанимать экспертов — аи-тренеров

Из чего состоит разметка

1. Фиксируем набор заданий.
2. Контроль: разнообразие тем, сложность, контрастность задачи, стратифиации, типы задачи
3. Фиксация правил разметки: безопасность, правдивость, полезность.
4. llm-as-a-judge — используем мощную БЯМ для оценки

Проблемы:
- llm-as-a-judge: модели больше нравятся свои ответы, смещение форматов, модель плохой фактчекер.
- АИ-тренеры это сложно, дорого, долго, немасштабируемо, не всегда коррелирует с тем что нужно пользователям.

## как оценивать умность БЯМ → разметка экспертами

Системная проблемы: чем лучше модель, тем сложнее ее оценивать. С какого-то момента необходимо привлекать экспертов в разных областях, чтобы оценить правильность ответов. Это стоит еще дороже, чем обычные АИ—тренера, и еще сложнее оценивать качество работы эксперта, потому что вы сами таковым не являетесь.

## Общий пайплайн

- Бенчмарки используем для первичного отбора.
- не забываем контролировать протечки, исследовать способы замера качества и устойчивость, делать кастомные бенчмарки и валидировать их.
- Разметкой делаем финальную приемку. Не забываем постоянно проверяйте качество, делать llm-as-a-judge.
- АБ-тесты на реальном продукте

# Разметка с помощью БЯМ

Интересные параллели:
- Затравка - как ключ к разным задачам, причем инструкция для человека — это био-затравка.
- Можно сказать, что человек и БЯМ работают похожим образом по формуле «задача + затравка → черный ящик → результат».
- Логика разработки инструкции хорошо перекладывается на БЯМ.

Время, которая тратит БЯМ, в зависимости от объема, линейно, в отличие от человека

Ролевые модели БЯМ в задаче разметки:
- чернорабочий — помогает разметчику, но не размечает сам.
- разметчик — выполняет непосредственно разметку данных.
- модератор — выбирает из нескольких ответов наилучший.
- эксперт — дополняет, объясняет решения.
## Чернорабочий

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

Чернорабочие работают на базе простой затравки.

Имея чернорабочих, чернорабочих можно менять класс задач. Задача "напиши перефраз" превращается "выбери лучший перефраз". Выбрать из списка несравнимо быстрее, чем писать самому.

Плюсы

1. Быстро справляется с тяжелыми генеративными задачами. Это сохраняет мотивацию.
2. ...

Минусы

1. Люди все еще нужны.
2. "Правдоподобность" — похожая на правду ложь. Проблема: разметчик может начать сильно доверять генерату или у него может просто замылиться глаз.
3. ...
   ## Разметчик

Две проблема:
1. Люди ошибается
2. БЯМ галлюцинируют

На самом деле проблема одна и та же. Для плохих или некорректных ответов людей есть правила обработки. Значит борьба с галлюцинациями — вопрос расширения этих правил.
### БЯМ как разметчик. Сравнение результатов на NER

- потеря 30 процентов сущностей в разметки.
- расширенное описание сущности — входящих в сущность токенов больше, чем нужно.
- различное в понимании имён и названий.
### БЯМ как разметчик. Оценка реплики по признакам.

- На простых репликах полное совпадение.
- 33 процента — частичное совпадение.
- 12 процентов — совершенно разные ответы.
## Модератор
имеет смысл только если ответы не совпали у разметчиков.
очень важно формально описать что есть «лучший» ответ.
* затравка строится так, как если бы мы объясняли человеку как надо выбирать.
* можно запросить обоснование решений, удобно для кросс проверки человеком.
## Ассистент или эксперт

Решаемые задачи:
- указать детали задачи, подводные камни,
- написать инструкцию
- генерация синтетики: диалоги, тексты.
- непосредственно разметка
- Предварительная оценка: оценка трудозатрат на старте задания, поиска аномалий в данных
## Как выбрать свой вариант

- узнать умеет ли llm решать задачу
- оценить цену ошибки
- ...
## Общий алгоритм

- выбираем 5-10 примеров
- накидывваем черновой промт
- итеративная притика в ui
- выделяем x процентов и отдаем 2 разметчикам
- смотрим различия, строим метрики, разбираем примеры расхождений и т. д.
- повторяем по необходимости
## Выводы

Почему БЯМ не просто:
- персональные данные
- нужна маленькая и специализированная модель — с ними проще обращаться и они решают задачу лучше.
- Страдает прогнозируемость и понятность.

# Исследование экосистемых эффектов методами causal inference

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

Иследовать такие эффекты полезно — они позволяют увеличивать синергию продуктов.

В компании докладчика исследовали вклад покупки страховых полисов: насколько вероятность покупки полиса повышает вероятность покупки других сервисов?

Первая идея аналиткика — проведем АБ-тест. Но покупка пользователя — решение клиента, поэтому АБ тест не работает. Мы не можем предложить разную цену разным группам, экономически дорого получается. разница по цене НЕ воля клиента.

Какие варианты? Исторически данные — не подходит, потому что это корреляция. Не вызывает доверия.

На помощь приходит Causal Inference

В чем проблема исторических дайннаы (бейздлайна): спутанность переменных, которых может быть много.

Можно попробовать propensity score ака поправку на общие причины, но есть проблема — важно правильно выбрать переменные, которые надо добавлять в модель. Есть феномены, которые порождают ошибки collider bias, парадокс Берксона. Выбирать можно с помощью алгоритмов. Правильное множество называется adjustment set.

Надо построить причинно-следственную модеь. Как?

Два подхода: экспертный, на данных (causal discovery).

1. Надо понять, какие переменные могут участвовать. -- строил модель предсказания покупки, отбирал переменные, которые лучше всего предсказывают. ВОт эти признаки считаем нашим сетом. МОжно сделать еще точнее с помощью моделей, которые предсказывают сами предикторы.
2. Как связаны эти переменные. Комбинация экспетных знаний и алгоритмов.
3. Убрать связи, которых точно нет и которые точно есть. (вручную)
4. PC algorthim (pip install causal-learn)
5. С помощью критериев находим adjusment set (backdoor criterion)
6. Проверяем граф сами. (может понадобится несколько итераций)
7. Оценка эффекта
8. Propensity score matching
9. uplift models
10. Doubly Robust learn
11. Все это в econML

Далее тесты
1. Расчет эффекта на случайной подвыборе (эффект не помен)
2. Добавить случайный признак (эффект не поменялся)
3. Заменить один из фактов на рандом(связь пропадает)
4. ---

На прошлой неделе был на Practical ML Conf от Яндекса. В этот раз конфа проходила в бизнес-центре на Бауманской, где в качестве залов для выступления переоборудовали парковку. Атмосфера была прям киберпанковая из-за того, что везде темно, а свет был от всяких разноцветных ламп с узким лучом. Надеюсь, вы поняли какие.

С едой правда в этот раз было хуже: потратил весь перерыв, чтобы дождаться в очереди БаБл Ти, и то мне пришлось убежать на доклад, а его потом принес коллега, спасибо ему. Еды готовой тоже не было, надо было ждать в очереди. В прошлом году было лучше. Кто-то скажет, что я зажрался, потому что и еда, и напитки, и кофе были бесплатными, а я скажу да, вы правы))). Но правда кажется, что лучше на такие мероприятия делать еду так, чтобы ее сразу могли забрать, потому что перерыв-то всего полчаса.

Кстати мы с коллегой после первого перерыва поесть не смогли и пошли на доклад, где выступал СТО Яндекса. Доклад этот был про Нейро — их супер-пупер RAG систему. Послушать про нее пришла куча народу, организаторы явно не рассчитывали на такое внимание. Расстроенные тем, что нам досталось место где-то в дальнем углу, тем что мы голодные (я во всяком случае), мы начали костерить презентацию, доклад, организаторов, заслоняющих монитор чуваков. Короче, место, где мы стояли, начало светиться ядовито-зелёным цветом. После этого доклада был очень крутой доклад про озвучку книг, но слушатели испарились и мы смогли занять хорошие места. На втором перерыве нам с коллегой повезло схватить два последних хот-дога, потому что мы стояли первые и жить вообще стало хорошо.

Меня на конфе в первую очередь интересовали доклады про разметку и про синтетику с помощью БЯМ. Первый был прям хороший, пару интересных мыслей вынес. Второй доклад сам по себе тоже хороший, но для меня не такой информативный, как первый. Про озвучку книг я вам уже сказал, очень хороший доклад. И еще самый первый доклад был про causal inference, он больше для аналитиков.
Притащил вам несколько конспектов. Я их причесал, но держите в голове, что они неполные. Где-то я не успевал, где-то для меня были очевидные вещи. Каждый конспект я выложу отдельным постом. Видосы с докладами, кстати, уже должны быть выложены.
Мои конспекты с прошлой конфы PML здесь.

Думаешь, что сейчас придут фоточки с pycon, отберешь себе крутую фотку на аву, где видно, как ты выступаешь
Фотка с pycon, когда ты выступаешь