Forwarded from AB Police 🚨 (Ivan Maksimov [ОТПУСК до 24 марта])
Т-тест VS Манн-Уитни
Холивар эпохи во многих компаниях и сообществах) Лично я стою на сторонедобра t-test. Для начала..
Чем плох тест Манна-Уитни?
Многие думают, что это критерий про равенство средних, но на самом деле это ранговый критерий про изменение распределения
H0: f_a = f_b
H1: f_a != f_b
В качестве частного (!) упрощения можно считать, что это критерий про сдвиг распределения
f_a = f(x)
f_b = f(x + dx)
H0: dx = 0
H1: dx != 0
И отсюда вытекает куча проблем
1. Теряется связь AB с финансами компании
Обычно мы подразумеваем что-то вроде
E(выручка) = E(траффик в приложении) * E(СR app start-заказ) * E(средний чек)
Ну и если мы АВ-тестом растим E(средний чек), а остальные множители серые, то мы автоматом влияем на выручку. Но зеленый прокрас по Манна-Уитни ничего не говорит про рост того самого E(средний чек) => ничего не говорит о росте E(выручка). А зачем тогда нужен АВ-тест, если мы не можем сказать в итоге, стали ли больше зарабатывать благодаря фиче?
2. Не работает с дублями значений метрики
Ну точнее формально во многих либах работает, но неправильно:) Критерий ранговый, а проставить ранг серии из одинаоквых значений (например 10К нулей) корректно нельзя. Поэтому с метриками вроде конверсии и ARPU (много нулей), стоимость доставки и средняя позиция кликнутого товара (в принципене много частотных значений) и многими другими критерий просто не применим
3. Слишком устойчив к выбросам
Нередко 1% самых активыз пользователей могут давать даже 20% выручки компании. Новой фичей мы могли вырастить у этих пользователей средний чек пусть на 2%. Это на минуточку +2% * 0,2 = 0.4% выручки компании. Для гигантов индустрии это могут быть дополнительные сотни миллионов рублей. При этом ранги значений метрики из-за этого могли вообще не поменяться: по тесту Манна-Уитни изменение серое
4. Не дружит с методами ускорения АВ
По сути, почти все методы ускорения АВ-тестов - это частный случай линейной регрессии. А она, как известно, не работает с рангами
Есть конечно ordinal regression, которую можно попытаться применить, но никаких статистических гарантий корректности уже не будет
5. Непросто считать необходимое число наблюдений для теста и MDE
Да, формулы тут нет. Придется моделировать: задача решаемая, но сильно сложнее, чем подставить пару чисел в готовую формулу
Всех этих минусов в самом обычном Т-тесте нет! У него есть и свои доп плюсы, но о них в следующий раз
Если интересно более длинный лонгрид, то у Авито есть достойная статья про минусы Манна-Уитни
Так что не усложняте, и пользуйтесь Т-тестом - это просто, корректно, ну и математически красиво 🧐
P.S. Для особо внимательных: Какая классическая ошибка в интерепретации теста Манна-Уитни изображена на картинке к посту? Взял ее на первой же странице гугла по запросу "Mann-Whitney"
Холивар эпохи во многих компаниях и сообществах) Лично я стою на стороне
Чем плох тест Манна-Уитни?
Многие думают, что это критерий про равенство средних, но на самом деле это ранговый критерий про изменение распределения
H0: f_a = f_b
H1: f_a != f_b
В качестве частного (!) упрощения можно считать, что это критерий про сдвиг распределения
f_a = f(x)
f_b = f(x + dx)
H0: dx = 0
H1: dx != 0
И отсюда вытекает куча проблем
1. Теряется связь AB с финансами компании
Обычно мы подразумеваем что-то вроде
E(выручка) = E(траффик в приложении) * E(СR app start-заказ) * E(средний чек)
Ну и если мы АВ-тестом растим E(средний чек), а остальные множители серые, то мы автоматом влияем на выручку. Но зеленый прокрас по Манна-Уитни ничего не говорит про рост того самого E(средний чек) => ничего не говорит о росте E(выручка). А зачем тогда нужен АВ-тест, если мы не можем сказать в итоге, стали ли больше зарабатывать благодаря фиче?
2. Не работает с дублями значений метрики
Ну точнее формально во многих либах работает, но неправильно:) Критерий ранговый, а проставить ранг серии из одинаоквых значений (например 10К нулей) корректно нельзя. Поэтому с метриками вроде конверсии и ARPU (много нулей), стоимость доставки и средняя позиция кликнутого товара (в принципене много частотных значений) и многими другими критерий просто не применим
3. Слишком устойчив к выбросам
Нередко 1% самых активыз пользователей могут давать даже 20% выручки компании. Новой фичей мы могли вырастить у этих пользователей средний чек пусть на 2%. Это на минуточку +2% * 0,2 = 0.4% выручки компании. Для гигантов индустрии это могут быть дополнительные сотни миллионов рублей. При этом ранги значений метрики из-за этого могли вообще не поменяться: по тесту Манна-Уитни изменение серое
4. Не дружит с методами ускорения АВ
По сути, почти все методы ускорения АВ-тестов - это частный случай линейной регрессии. А она, как известно, не работает с рангами
Есть конечно ordinal regression, которую можно попытаться применить, но никаких статистических гарантий корректности уже не будет
5. Непросто считать необходимое число наблюдений для теста и MDE
Да, формулы тут нет. Придется моделировать: задача решаемая, но сильно сложнее, чем подставить пару чисел в готовую формулу
Всех этих минусов в самом обычном Т-тесте нет! У него есть и свои доп плюсы, но о них в следующий раз
Если интересно более длинный лонгрид, то у Авито есть достойная статья про минусы Манна-Уитни
Так что не усложняте, и пользуйтесь Т-тестом - это просто, корректно, ну и математически красиво 🧐
P.S. Для особо внимательных: Какая классическая ошибка в интерепретации теста Манна-Уитни изображена на картинке к посту? Взял ее на первой же странице гугла по запросу "Mann-Whitney"
Forwarded from Neural Kovalskii
Результаты Enterprise RAG challenge (https://abdullin.com/erc/)
На сайте клацаем кнопку Show Local Models Only
На сегодня я завершаю свои исследования по локальным RAG подходам по документам и расскажу как мы заняли 4 место с разницей в 8 баллов от 70+b моделек (Локальных) и 1 первое место среди 32b моделей и Full Dense retrieval and cross-encoder reranker подходом (никаких кстати langchain и другого готового рагоделья только вайб кодинг в курсор и requests + vLLM)
Предыдущие посты на эту тему:
1) Анализ разных векторных моделек
2) Сравнение локальных моделей векторизации с 1 местом
3) Первые эксперименты
В итоге навайбкодил около 11к строк кода которые позволили показать такие результаты
Важное отступление что более 7 дней у меня в итоге заняло эксперименты по экстракту данных из PDF (карл)
И так для начала какое решение я принял сразу что-то ошибочно:
1) Никакой подготовки стендов заранее, все материалы команда и я в частности приступили изучать в день старта соревнований (взял из команды 2 человек ребята помогли вчитаться в условия и понять данные) (Вот тут рефлексия что нужно выделять как минимум неделю заранее свою что бы войти в курс дела)
2) Заранее пополнили все нужные нам сервисы для аренды локальных мощностей
3) Выкинул наш пайплайн RAG и я его стал строить с 0
4) Были заранее развернуты и заготовлены cross encoder bge-rerank + bge-m3 embedding model Арендована машина с А100 для (qwen 2.5 32b (16FP) instruct)
Первый этап парсинг данных из PDF
тут не обошлось без приключений так как внутри компании мы сконцентрировались на интеграциях к конфлюенс и системам для забора данных на документах мы давно не делали акцент по этому пошли гуглить и перебирать что же сможет нам достоверно достать данные из PDF
Перебрав около 3-5 библиотек финальный результат был сделан на библиотеке Marker
Далее чанкование и векторизация
Ничего нового каждая страница была разбита на чанки по 400 токенов с перекрытием в 80 токенов и дальше векторизирована батчами в сервис vLLM где развернута модель bge-m3
Далее под каждый док была созданная коллекция и настроены модели данных (что бы при запросе на KNN возвращать чанки номер страницы с которой он был взят и путь до файла где есть фулл контент страницы как потом я выяснил данный подход называется Parent Document Extraction)
Роутинг был заранее понятен из названия компаний и документов к ним в сабсет там были названя компаний их легко было смэтчить с документами(это я ксатит понял только почти в самом конце и выкинул роутинг совсем)
И так из приятного в сабсете(датасет) изначально указаны типы по этому были составлены через клод промпты под каждый тип запроса
Ну и пошли прогоны (прогонял я систему наверное раз 40 не менее)
Каждый раз вчитываясь что же она отвечает
Ищем чанки внутри дока через KNN
Ранжируем через bge-reranker (cross-encoder)
Передаем в ллм с CoT+SO для ответа
Были проблемы и с множественными вопросами но как показала моя практика курсор (в 20 итераций) смог учесть эти особенности и неплохо обработал этот формат
Как итог часть этих наработок уже ушла в наш прод продукт Smart Platform которая нацелена решать проблему создания RAG агентов для крупных компаний на локальных мощностях
Stay Tuned!
Скоро будет большой анонс нашей платформы будем с нашим CPO рассказывать что же мы там ваяли за год
P.S мы уже провели внутренние демо нашего продукта получили очень позитивный фидбек! Значит движемся куда нужно!
На сайте клацаем кнопку Show Local Models Only
На сегодня я завершаю свои исследования по локальным RAG подходам по документам и расскажу как мы заняли 4 место с разницей в 8 баллов от 70+b моделек (Локальных) и 1 первое место среди 32b моделей и Full Dense retrieval and cross-encoder reranker подходом (никаких кстати langchain и другого готового рагоделья только вайб кодинг в курсор и requests + vLLM)
Предыдущие посты на эту тему:
1) Анализ разных векторных моделек
2) Сравнение локальных моделей векторизации с 1 местом
3) Первые эксперименты
В итоге навайбкодил около 11к строк кода которые позволили показать такие результаты
Важное отступление что более 7 дней у меня в итоге заняло эксперименты по экстракту данных из PDF (карл)
И так для начала какое решение я принял сразу что-то ошибочно:
1) Никакой подготовки стендов заранее, все материалы команда и я в частности приступили изучать в день старта соревнований (взял из команды 2 человек ребята помогли вчитаться в условия и понять данные) (Вот тут рефлексия что нужно выделять как минимум неделю заранее свою что бы войти в курс дела)
2) Заранее пополнили все нужные нам сервисы для аренды локальных мощностей
3) Выкинул наш пайплайн RAG и я его стал строить с 0
4) Были заранее развернуты и заготовлены cross encoder bge-rerank + bge-m3 embedding model Арендована машина с А100 для (qwen 2.5 32b (16FP) instruct)
Первый этап парсинг данных из PDF
тут не обошлось без приключений так как внутри компании мы сконцентрировались на интеграциях к конфлюенс и системам для забора данных на документах мы давно не делали акцент по этому пошли гуглить и перебирать что же сможет нам достоверно достать данные из PDF
Перебрав около 3-5 библиотек финальный результат был сделан на библиотеке Marker
Далее чанкование и векторизация
Ничего нового каждая страница была разбита на чанки по 400 токенов с перекрытием в 80 токенов и дальше векторизирована батчами в сервис vLLM где развернута модель bge-m3
Далее под каждый док была созданная коллекция и настроены модели данных (что бы при запросе на KNN возвращать чанки номер страницы с которой он был взят и путь до файла где есть фулл контент страницы как потом я выяснил данный подход называется Parent Document Extraction)
Роутинг был заранее понятен из названия компаний и документов к ним в сабсет там были названя компаний их легко было смэтчить с документами(это я ксатит понял только почти в самом конце и выкинул роутинг совсем)
И так из приятного в сабсете(датасет) изначально указаны типы по этому были составлены через клод промпты под каждый тип запроса
Ну и пошли прогоны (прогонял я систему наверное раз 40 не менее)
Каждый раз вчитываясь что же она отвечает
Ищем чанки внутри дока через KNN
Ранжируем через bge-reranker (cross-encoder)
Передаем в ллм с CoT+SO для ответа
Были проблемы и с множественными вопросами но как показала моя практика курсор (в 20 итераций) смог учесть эти особенности и неплохо обработал этот формат
Как итог часть этих наработок уже ушла в наш прод продукт Smart Platform которая нацелена решать проблему создания RAG агентов для крупных компаний на локальных мощностях
Stay Tuned!
Скоро будет большой анонс нашей платформы будем с нашим CPO рассказывать что же мы там ваяли за год
P.S мы уже провели внутренние демо нашего продукта получили очень позитивный фидбек! Значит движемся куда нужно!
Forwarded from Neural Kovalskii
Кстати схема работы моего решения) Если смотреть между строк почти ничем не отличается от других топ решений
Forwarded from Душный NLP
Механизм аттеншена NSA
Native Sparse Attention (NSA) — механизм разреженного аттеншена от инженеров из DeepSeek. Утверждается, что NSA имеет качество, сопоставимое с обычным аттеншном на маленьких контекстах, и значительно опережает его на больших — в статье сравнение производится на 64K токенов.
Вместо того чтобы каждый новый query обращался ко всем предыдущим key и value, как это делается в традиционном аттеншне, авторы предлагают сжимать предыдущие ключи и значения в dense-представления. За счёт этого длина последовательности, над которой работает attention, уменьшается, что позволяет работать с контекстом в 64K токенов так, будто их всего 4K. В отличие от предыдущих sparse-методов аттеншна (например, Quest), NSA применяется как при обучении, так и при инференсе.
В статье предлагают три функции для сжатия представления: token compression, token selection и sliding window. Для каждой из них считается аттеншен, а результаты складываются с коэффициентами от MLP-блока.
Token compression предполагает покрытие последовательностей ключей и значений блоками длины 32 с перекрытием по 16 токенов с последующим сжатием каждого блока в «один токен» с помощью MLP с внутриблочным позиционным энкодингом.
На стадии token selection тоже происходит покрытие ключей и значений блоками, но теперь для каждого из них считается скор полезности. После чего выбираются top-16 блоков с максимальным скором. На оставшиеся блоки аттеншн не смотрит, а в выбранных внимание обращается на все ключи и значения.
Авторы отмечают, что в начале обучения сильно доминировали локальные паттерны. Поэтому selection и compression больше фокусировались на последовательностях ближе к текущему токену. В конце, на длинных контекстах, возникали сложности с аттеншеном на начало последовательности. Чтобы решить эту проблему, предлагается дополнительно использовать sliding window для аттеншена на ближайшие 512 токенов.
Метод проверяли на MoE-модели на 27B параметров, из которых 3B — активные. У модели было 30 слоёв аттеншена и 64 головы с разной размерностью. Число экспертов — 72, из них общих — 2. Обучение происходило на 270B токенов с размером контекстного окна в 8K токенов. Далее был SFT с использованием техники YaRN.
Результаты тестов показали, что на бенчмарках, где длинный контекст не так важен — например, MMLU или HumanEval — деградации качества от использования NSA не происходит. На LongBench же NSA показывает качество в среднем на 10% лучше, чем Full Attention. Например, на LCC, где требуется дополнить сниппет кода на основе очень длинного контекста, NSA побеждает 0,232 на 0,163.
Кроме того, есть ощутимый прирост в скорости — вплоть до 9 раз на форварде и 6 раз на бекварде при сравнении с FlashAttention 2. Это стало возможно за счёт эффективного Triton-кернела, кодом которого разработчики не делятся, но в open source уже началась работа по его воспроизведению.
Разбор подготовил❣ Владислав Савинов
Душный NLP
Native Sparse Attention (NSA) — механизм разреженного аттеншена от инженеров из DeepSeek. Утверждается, что NSA имеет качество, сопоставимое с обычным аттеншном на маленьких контекстах, и значительно опережает его на больших — в статье сравнение производится на 64K токенов.
Вместо того чтобы каждый новый query обращался ко всем предыдущим key и value, как это делается в традиционном аттеншне, авторы предлагают сжимать предыдущие ключи и значения в dense-представления. За счёт этого длина последовательности, над которой работает attention, уменьшается, что позволяет работать с контекстом в 64K токенов так, будто их всего 4K. В отличие от предыдущих sparse-методов аттеншна (например, Quest), NSA применяется как при обучении, так и при инференсе.
В статье предлагают три функции для сжатия представления: token compression, token selection и sliding window. Для каждой из них считается аттеншен, а результаты складываются с коэффициентами от MLP-блока.
Token compression предполагает покрытие последовательностей ключей и значений блоками длины 32 с перекрытием по 16 токенов с последующим сжатием каждого блока в «один токен» с помощью MLP с внутриблочным позиционным энкодингом.
На стадии token selection тоже происходит покрытие ключей и значений блоками, но теперь для каждого из них считается скор полезности. После чего выбираются top-16 блоков с максимальным скором. На оставшиеся блоки аттеншн не смотрит, а в выбранных внимание обращается на все ключи и значения.
Авторы отмечают, что в начале обучения сильно доминировали локальные паттерны. Поэтому selection и compression больше фокусировались на последовательностях ближе к текущему токену. В конце, на длинных контекстах, возникали сложности с аттеншеном на начало последовательности. Чтобы решить эту проблему, предлагается дополнительно использовать sliding window для аттеншена на ближайшие 512 токенов.
Метод проверяли на MoE-модели на 27B параметров, из которых 3B — активные. У модели было 30 слоёв аттеншена и 64 головы с разной размерностью. Число экспертов — 72, из них общих — 2. Обучение происходило на 270B токенов с размером контекстного окна в 8K токенов. Далее был SFT с использованием техники YaRN.
Результаты тестов показали, что на бенчмарках, где длинный контекст не так важен — например, MMLU или HumanEval — деградации качества от использования NSA не происходит. На LongBench же NSA показывает качество в среднем на 10% лучше, чем Full Attention. Например, на LCC, где требуется дополнить сниппет кода на основе очень длинного контекста, NSA побеждает 0,232 на 0,163.
Кроме того, есть ощутимый прирост в скорости — вплоть до 9 раз на форварде и 6 раз на бекварде при сравнении с FlashAttention 2. Это стало возможно за счёт эффективного Triton-кернела, кодом которого разработчики не делятся, но в open source уже началась работа по его воспроизведению.
Разбор подготовил
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from 𝖉𝖊𝖋𝖙
А ты стримы не смотришь? https://youtu.be/GIDOuEJg5yo?si=BLTFoaN9CP7o9Cvx
YouTube
#FaangTalk 45 - Сигналы на алго-интервью
Чат по подготовке к интервью: https://t.me/faangtalk
Канал с анонсами https://t.me/faangtalk_news
Канал Макса https://t.me/faang_career
В выпуске мы разбираем три алго-интервью с точки зрения сигналов, которые важны нанимающему менеджеру.
Выпуск с разбором…
Канал с анонсами https://t.me/faangtalk_news
Канал Макса https://t.me/faang_career
В выпуске мы разбираем три алго-интервью с точки зрения сигналов, которые важны нанимающему менеджеру.
Выпуск с разбором…
Forwarded from OutOfScope | Федор Корягин
Yandex Product Party - 20.03.2024 - OutOfScope.pdf
25.8 MB
Под большим впечатлением от крайней трансляции Yandex Product Party. Каждая из четырех лекций пропитана стартаперским духом, подходами как проанализировать рынок и приступить к быстрому тестированию. Так что must see и коротко расскажу почему стоит посмотреть каждый из докладов
Если тебе заходит такой контент, ты можешь забустить канал — http://t.me/out_of_scope?boost
#YandexProductParty #Яндекс
OutOfScope | OOS
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Ai molodca (Dobrokotov)
Вышла новая нейросеть Reve, а это ее художественный тест.
Если коротко: это гибрид FLUX и Идеограма, прекрасно слушает длинные промты, так же прекрасно может в текст (однако немного шакалит лица и детали на крупных планах). Но что самое классное и интересное: отлично знает советское и пост-советское. Панельки, автопром, ковры на стенах. Вот это вот все. Если раньше для этого нужны были отдельные лоры, то теперь можно пользоваться Reve.
Бесплатно, в день дается n-ое количество генераций на один аккаунт (который можно удалить и зарегистрироваться заново ). Приглашаю всех в тесту в комментарии. Помните, что можно кидать картинку в окно промта.
Если коротко: это гибрид FLUX и Идеограма, прекрасно слушает длинные промты, так же прекрасно может в текст (однако немного шакалит лица и детали на крупных планах). Но что самое классное и интересное: отлично знает советское и пост-советское. Панельки, автопром, ковры на стенах. Вот это вот все. Если раньше для этого нужны были отдельные лоры, то теперь можно пользоваться Reve.
Бесплатно, в день дается n-ое количество генераций на один аккаунт (