Интересное что-то
517 subscribers
2.72K photos
253 videos
139 files
4.52K links
Материалы и мысли, понадерганные отовсюду
Блог: https://t.me/asisakov_channel
Чат: https://t.me/youknowds_chat
Download Telegram
Forwarded from Женя Никитин
мой сетап
vscode + continue.dev + cline
Дизайн 🆎 экспериментов и почему это важно.

😱 Ранее я считал, что важнее всего подводить итоги, но как оказалось не только. Дизайн эксперимента подразумевает определенную структуру, комплекс действий, направленных для корректного запуска и последующего анализа эксперимента. Подразумевается, что разметка уже готова (более подробно хочу рассказать в следующих постах).

🎄 При проектировании A/B эксперимента учитывайте сезонность, например, в Новый Год пользователи могут вести себя по-другому

💡 Нужно определиться с гипотезой. Проводя A/B тестирование, мы всегда говорим о постановке различных гипотез, как на языке бизнеса (в понятном для всех формате), так и на языке статистики, когда говорим про нулевые и альтернативные гипотезы. Важно понимать, что от гипотезы зависит многое. По сути, как мы дальше будем интерпретировать различные варианты.

🙅‍♂️ Риски. Какие могут быть риски для компании? Если что-то резонирующее, которое сразу улетит в СМИ - тест можно перезапускать, можем получить при анализе невалидные результаты. Например, если мы просто убираем точку входа или полностью меняем популярное приложение при раскатке 50/50.

🗒 Определение метрик и теста. А на что мы смотрим, когда подводим итоги? Может есть какие-то целевые, по которым мы хотим принимать решения, а может есть какие-то вспомогательные, которые нам нужны для дальнейшего анализа. Если у нас есть своя A/B платформа, проблемой с подсчетов быть не должно. На этом этапе важно также понимать какой тест мы используем для анализа.

Сегменты пользователей. Хотим мы катиться на всех или нет зависит от сетапа эксперимента, возможно, нам нужно брать определенный срез пользователей (старички/новички, пользователи, обладающие каким-то признаком).

🌳 Дерево принятия решений. Если метрик несколько, мы должны определиться с различными вариантами, когда эксперимент катим, а когда нет. Если метрика серая, то..., а если нет, то. Базово должно фиксироваться до проведения эксперимента.

😁 Определение MDE / размера выборки / длительности эксперимента. Мы должны понять на истории, а действительно ли мы сможем прокрасить эксперимент? По сути, тот же MDE нужен нам для определения примерной длительности эксперимента или ответа на вопрос, а эта метрика чувствительна вообще будет на данном срезе или нет?

🥪 Другие слои. А считаем ли мы корректным проводить эксперимент, если слои забиты, а насколько забиты, все ли окей в этом плане?

📱 Если есть своя команда разработки и платформа, то с заведением пользователей (кому какой флаг навешиваем) проблем нет, а если самому, то нужно продумать. Не все могут себе позволить запускать так тесты. Если нет, то со старичками понятно, мы отдаем контроль и тест списком, с новичками сложнее, как будто нужно раз в какое-то время на дню отдавать пользователей списками с айдишниками.

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

Корректное логирование эксперимента. Можно раскатить на себя, посмотреть, собрать различные события в тестовой группе, попробовать посчитать метрики (просмотр, клик по фиче X, которую мы запускаем на тестовую группу).

🚀 Запуск эксперимента

От вас жду 100
🐳 за пост. Далее пройдемся по вопросам, касаемых разметки и ТЗ для команды разработки и я продолжу писать посты из списка.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Start Career in DS
📊 Как оценивать LLM: метрики [Ч.1]

🤖 Оценка языковых моделей также необходима, как и при работе с классическими ML-моделями. Однако, в случае с LLM задача усложняется тем, что мы должны оценивать текстовые данные.

💯 В этой части поста мы расскажем про наиболее популярные NLP-метрики для оценки языковых моделей, а уже в следующем посте поговорим про более продвинутые техники, включая бенчмарки.

А в чем, собственно, отличие между метриками и бенчмарками:

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

Поговорим про статистические метрики:


1️⃣ Перплексия:
Перплексия показывает, насколько точно модель предсказывает следующий токен: чем ниже значение, тем уверенее предсказание.
Например, если перплексия равна 1000, это означает, что модель в среднем имеет 1000 равновероятных вариантов для каждого следующего слова, что указывает на плохое качество предсказаний. Через перплексию в LLM можно определить галлюцинации, хоть и сама метрика не всегда коррелирует с качеством генерации текста.
Более подробно про перплексию и формулу данной меры читайте тут.

2️⃣ BLEU и ROUGE:
О данных метриках мы писали в одном из вопросов недавнего квиза (п.5) и оставляли хорошие материалы для изучения, советуем вернуться и ознакомиться.

3️⃣ METEOR:
Данная метрика создавалась, как улучшенная альтернатива BLEU, которая учитывает не только точное совпадение слов в сгенерированном тексте с эталонными примерами, но и их синонимы и морфологические варианты, что делает её более гибкой и устойчивой к разнообразным формулировкам. В добавок, метрика выдает штраф за неправильную фрагментацию текста и неверный порядок слов. Подробно про методику расчет METEOR смотрите в этом видео.

4️⃣ Классические ML-метрики:
Оценивать текст можно также, как и числа, используя ML-метрики. Например, посчитать количество слов (токенов) в сгенерированном примере, вошедшие в эталонный пример - accuracy. Или посчитать recall через количество слов, вошедшие в эталонный пример (TP), но, учитывая недостающие токены (FN).

Теперь поговорим про model-based метрики:

5️⃣ BERTScore:
Данная метрика в процессе расчета использует BERT-модели, чтобы через векторные представления слов в предложении оценивать схожесть текстов. Кратко процесс оценки выглядит следующим образом: получение эмбеддингов для каждого слова в сгенерированном и эталонном текстах с помощью BERT. И затем (в упрощенном виде) по косинусному сходству токены из сгенерированного текста сопоставляются с токенами эталонного текста, после чего высчитывается Recall-BERT, Precision-BERT F-BERT. Более детально про архитектуру подсчета BERTScore читайте тут.

6️⃣ G-Eval:
G-Eval
(Generative Evaluation) создан для того, чтобы преодолеть ограничения статистических метрик (неустойчивость к формулировкам, разные длины сравниваемых текстов, непренимость к сложным задачам). В G-Eval в виде оценщика используются другие GPT-модели, например, GPT-4 от OpenAI. Оценка проводится через сравнительный анализ сгенерированного текста и эталонного примера по заранее выбранным критериям (согласованность, точность и т.д.).

🔥 Однако, это не весь список метрик, с помощью которых можно оценивать LLM, дополнительно читайте тут:

- Серия постов на Хабре про эволюцию NLP-метрик
- Ещё две статьи тут и тут про метрики, фреймворки и лучшие практики для оценки LLM.
- Отличная статья для погружения в бечнмаркинг LLM
- Статья с объяснением подхода "LLM-as-a-Judge" (LLM, как судья) [ENG]
- Evaluating-Cookbook - руководство по оценке LLM, созданное командой Hugging Face.

Ставьте ❤️ и 🔥 под постом!
Также пишите свои комментарии и вопросы! До встречи👋
Forwarded from DevFM
Почему не нужно отвлекать программиста

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

В статье Как поймать «поток», и как сделать так, чтобы он не сорвался объясняется, что такое состояние потока и как постоянное прерывание этого самого потока замедляет работу. По оценке автора, погружение в состояние потока "стоит" 15 минут, то есть любое прерывание имеет вот такие дополнительные накладные расходы.

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

#edu
Про мой опыт в RecSys Research

Вчера нашу новую статью приняли на ECIR 2025 - это A-конференция (значит, входит в некоторый топ-23% от некоторого набора конференций) по информационному поиску в Италии 🎉! Статья про e-grocery рекомендации, но подробности позже. Это четвертая статья на основном треке A-конференций с моим участием и четырнадцатая, если считать еще воркшопы. В этом посте напишу про свой путь, как я к этому пришел.

Весна 2019 года. Я на 4 курсе ФРКТ МФТИ, меня берут на стажировку в ML-команду. Первая задача там - сделать обзор на методы объяснений рекомендаций. Я читаю статьи, вникаю в сам домен рекомендаций. В итоге получаю табличку с ~20 статьями, где выделены важные пункты про каждую работу. На тот момент кажется, что я прекрасно разобрался в теме.

2019-2020 учебные годы. Меня берут лаборантом в VK Lab при МФТИ в recsys. Чтобы пройти отбор, я реализовывал статью про музыкальные рекомендации и пытался догнать ALS по качеству. На тот момент отгремела статья "Are we really making much progress", где авторы победили нейронные модели через простые линейные. Моя же задача была либо в поиске, либо в создании такой нейромодели, которая в честном сравнении все-таки победила бы простую модель. Мы с коллегами собрали статью на RecSys 20, но ее не взяли. Это была моя первая статья на английском языке, писать было очень сложно и получалось плохо.

2021 год. На работе начинается ресерч. Я подключаюсь, провожу эксперименты, помогаю с текстом. Мы не успеваем подать статью на RecSys 21, подаем на CIKM 21. Там нашу статью не берут, в том числе потому, что мы подали не на тот трек. Статью мы все равно выложили и ее даже процитировали зарубежные авторы. Также в этом году мы занимаем 4 место в SIGIR challenge, и пишем статью на Хабр.

2022 год. Мы пишем дипломы со студентами ВШЭ. Темы предложили исходя из наших интересов, которые потенциально могли раскрутиться и доехать до прода. Некоторым студентам предлагаем обернуть результаты в научные статьи и подать на воркшопы при конференциях. Получаем публикации про графы знаний, индуктивные sequential модели. Также в октябре мы пишем статью на ECIR 23 про next-basket recommendation и ее берут!

2023 год. В этом году у нас получается много работ со студентами ВШЭ на воркшопах, которые преобразуются в статьи. Также мы едем на первую для нас международную конференцию ECIR в Ирландию, где рассказываем про нашу статью. Впечатлений много, и мы по возвращении вкладываемся в еще одну работу, и ее тоже принимают на RecSys 23! Мы едем презентовать статью и Сингапур, оказываемся в международном RecSys коммьюнити. Также я удивляюсь, как много людей приехало из России от разных компаний: Сбер, Яндекс, Одноклассники, Дзен. В этом же году я поступаю в аспирантуру МФТИ на кафедру от Т-Банка. Статьи-то уже есть, и вроде их можно будет засчитать для защиты диссертации.

2024 год. Мы занимаемся RnD по RL&RecSys, о чем я рассказывал в докладе на Turbo ML Conf. Также у нас принимают статью по BPR на reproducibility track на RecSys 24 - полноценный full paper. Чуть позже мы пишем новую статью на ECIR 2025 по e-grocery рекомендациям, и вот, под конец года, получаем решение, что ее принимают! Параллельно у нас ведется и другая работа, о которой расскажу позже)

Итого, мой опыт с recsys research - это постепенное и довольно долгое развитие. Чем больше пишешь тексты статей, тем лучше и легче они получаются. Есть еще много идей и планов, одной из которых является написание и защита диссертации в МФТИ. Кроме этого, конечно, в recsys research есть еще много плюсов, но о них я расскажу в другом посте.
Forwarded from Neural Info
Мини-статья про регуляризацию с визуальным объяснением и сравнением L1 и L2.

Всем советую прочитать, возможно данная статья прояснит некоторые неочевидные моменты, которые обычно опускают.
Forwarded from Душный NLP
ToolkenGPT и Toolken+: расширение возможностей языковых моделей за счёт интеграции инструментов

Сегодня разбираем две статьи. Первая описывает парадигму обучения инструментов ToolkenGPT. Вторая представляет развитие этой концепции, предложенное Константином Яковлевым, Сергеем Николенко и Андреем Бутом из Яндекса.

ToolkenGPT: как научить модель напрямую вызывать внешние функции
В первой работе исследователи предложили представить каждый внешний инструмент в виде токена — toolken (represents each tool as a token) — и выучивать его эмбеддинг. Модель обучается работать с такими токенами так же, как с обычными текстовыми.

В результате работу модели можно условно разделить на две стадии:

1) режим “reasoning” — генерация происходит, как обычно, с той лишь разницей, что добавленные toolken тоже рассматриваются в качестве вероятных токенов на каждом шаге генерации;
2) режим “tool” — когда следующим предсказанным токеном оказался toolken. В этом случае вызывается соответствующий инструмент в режиме “few-shot”. После того как вызов осуществляется внешним инструментом, модель возвращает ответ и переходит обратно в режим “reasoning”.

Авторы показали применимость подхода для математических операций на GSM8K-XL и FuncQA. Также рассмотрели задачи knowledge-based QA и генерации плана.

Toolken+: ранжирование инструментов и отказ от неподходящих функций
Концепция Toolken+ решает две проблемы ToolkenGPT. Во-первых, ранее модель не учитывала документацию по инструментам и часто выбирала неподходящий инструмент. Во-вторых, модель иногда стремилась использовать инструмент там, где это не требовалось.

Toolken+ добавляет два улучшения:

1) Переранжирование нескольких выбранных инструментов. Модель сначала предлагает k вариантов, потом повторно оценивает и выбирает оптимальный.
2) Опцию “reject” для отказа от вызова инструмента. Модель может явно указать, что сейчас не стоит применять никакой инструмент, если вероятность подходящего вызова невысока.

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

Результаты
Исследователи проверяли Toolken+ на математическом бенчмарке GSM8K, на бенчмарках VirtualHome и MetaTool. Они показали, что добавление переранжирования и опции "reject" улучшает качество конечных ответов. При этом в MetaTool требуется только одна функция для заданного запроса, поэтому опция "reject" не нужна — таким образом, замер служит как аблейшн реранжирования гипотез.

Расскажите в комментариях, что думаете о подходах ToolkenGPT и Toolken+.

Разбор подготовил
Андрей Бут
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from addmeto (Grigory Bakunov)
Вот эта работа имеет все шансы стать куда более значимой, чем все нынешние "соры", выпущенные в последние полгода. Это система, в которой вы можете симулировать реальные физические процессы и визуализировать их. По сути используется физическая модель, где из текста строится не видео (как все уже привыкли), а моделируется 3д с учетом физики процессов и материалов. Слова тут вероятно лишние, посмотрите на картинки https://genesis-embodied-ai.github.io