Несогласованность эффектов или «Где деньги, Лебовски?»
В статье рассматриваются проблемы, возникающие при оценке эффектов A/B-тестов и Causal Inference в ритейле, когда необходимо анализировать изменения выручки по различным категориям товаров и общей (тотал-) категории. Мы подробно рассмотрим, почему простое суммирование оценок эффектов по категориям не всегда дает корректную оценку для тотал-категории, и предложим эффективный способ решения этой проблемы.
Читать: https://habr.com/ru/companies/X5Tech/articles/940488/
#ru
@big_data_analysis | Другие наши каналы
В статье рассматриваются проблемы, возникающие при оценке эффектов A/B-тестов и Causal Inference в ритейле, когда необходимо анализировать изменения выручки по различным категориям товаров и общей (тотал-) категории. Мы подробно рассмотрим, почему простое суммирование оценок эффектов по категориям не всегда дает корректную оценку для тотал-категории, и предложим эффективный способ решения этой проблемы.
Читать: https://habr.com/ru/companies/X5Tech/articles/940488/
#ru
@big_data_analysis | Другие наши каналы
LLM-агенты против ручного ресерча: кейс Bioptic в биофарме
При разработке новых лекарств важно вовремя оценить конкурентную среду – какие препараты уже существуют или находятся в разработке для той же болезни. Такой анализ конкурентов обычно входит в due diligence проекта: инвесторы и фармкомпании вручную собирают данные из разных источников о всех потенциальных конкурентах целевого препарата.
Команда стартапа Bioptic (сооснователь — Андрей Дороничев) предложила автоматизировать эту рутинную работу с помощью агентной AI‑системы на базе больших языковых моделей (LLM).
Всем привет. Меня зовут Кирилл Пшинник, я научный сотрудник Университета Иннополис и CEO онлайн-университета zerocoder.ru. Сегодня узнал о еще одном важном шаге в деле ускорения анализа и сбора информации с помощью ИИ. На этом примере — в медицине.
Читать
Читать: https://habr.com/ru/articles/940806/
#ru
@big_data_analysis | Другие наши каналы
При разработке новых лекарств важно вовремя оценить конкурентную среду – какие препараты уже существуют или находятся в разработке для той же болезни. Такой анализ конкурентов обычно входит в due diligence проекта: инвесторы и фармкомпании вручную собирают данные из разных источников о всех потенциальных конкурентах целевого препарата.
Команда стартапа Bioptic (сооснователь — Андрей Дороничев) предложила автоматизировать эту рутинную работу с помощью агентной AI‑системы на базе больших языковых моделей (LLM).
Всем привет. Меня зовут Кирилл Пшинник, я научный сотрудник Университета Иннополис и CEO онлайн-университета zerocoder.ru. Сегодня узнал о еще одном важном шаге в деле ускорения анализа и сбора информации с помощью ИИ. На этом примере — в медицине.
Читать
Читать: https://habr.com/ru/articles/940806/
#ru
@big_data_analysis | Другие наши каналы
❤1
Forwarded from Типичный программист
Tproger объединились с Paradox и запустили совместный проект для комьюнити разработчиков
Мы сделали два дизайна — теперь ваш ход. Вы за типичный или за токсичный вайб? Голосуйте за один из вариантов до 30 августа на сайте.
В конце месяца объявим победителя — дизайн, который сообщество реально протащило в прод.
И да, всё самое интересное будет в канале. Среди голосующих разыграем призы — так что не только банке достанется апгрейд.
Мы сделали два дизайна — теперь ваш ход. Вы за типичный или за токсичный вайб? Голосуйте за один из вариантов до 30 августа на сайте.
В конце месяца объявим победителя — дизайн, который сообщество реально протащило в прод.
И да, всё самое интересное будет в канале. Среди голосующих разыграем призы — так что не только банке достанется апгрейд.
Проблема маленьких файлов. Оценка замедления S3 и проблем HDFS и Greenplum при работе ними
Не так давно в блоге компании Arenadata был опубликован материал тестирования поведения различных распределенных файловых систем при работе с маленькими файлами (~2 Мб). Краткий вывод: по результатам проверки оказалось, что лучше всего с задачей маленьких файлов справляется старый-добрый HDFS, деградируя в 1.5 раза, S3 на базе minIO не тянет, замедляясь в 8 раз, S3 API над Ozone деградирует в 4 раза, а наиболее предпочтительной системой в при работе с мелкими файлами, по утверждению коллег, является Greenplum, в том числе для компаний «экзабайтного клуба». Коллеги также выполнили огромную работу по поиску «Теоретических подтверждений неожиданных показателей».
Результаты тестирования в части S3 minIO показались нашей команде неубедительными, и мы предположили, что они могут быть связаны с:
-недостаточным практическим опытом эксплуатации SQL compute over S3 и S3 в целом;
-отсутствием опыта работы с кластерами minIO. В частности в высоконагруженном продуктивном окружении на 200+ Тб сжатых колоночных данных Iceberg/parquet, особенно в сценариях, где проблема маленьких файлов быстро становится актуальной.
-особенностями сборок дистрибутивов;
Мы благодарны коллегам за идею и вдохновение провести аналогичное тестирование. Давайте разбираться.
Читать: https://habr.com/ru/companies/datasapience/articles/941046/
#ru
@big_data_analysis | Другие наши каналы
Не так давно в блоге компании Arenadata был опубликован материал тестирования поведения различных распределенных файловых систем при работе с маленькими файлами (~2 Мб). Краткий вывод: по результатам проверки оказалось, что лучше всего с задачей маленьких файлов справляется старый-добрый HDFS, деградируя в 1.5 раза, S3 на базе minIO не тянет, замедляясь в 8 раз, S3 API над Ozone деградирует в 4 раза, а наиболее предпочтительной системой в при работе с мелкими файлами, по утверждению коллег, является Greenplum, в том числе для компаний «экзабайтного клуба». Коллеги также выполнили огромную работу по поиску «Теоретических подтверждений неожиданных показателей».
Результаты тестирования в части S3 minIO показались нашей команде неубедительными, и мы предположили, что они могут быть связаны с:
-недостаточным практическим опытом эксплуатации SQL compute over S3 и S3 в целом;
-отсутствием опыта работы с кластерами minIO. В частности в высоконагруженном продуктивном окружении на 200+ Тб сжатых колоночных данных Iceberg/parquet, особенно в сценариях, где проблема маленьких файлов быстро становится актуальной.
-особенностями сборок дистрибутивов;
Мы благодарны коллегам за идею и вдохновение провести аналогичное тестирование. Давайте разбираться.
Читать: https://habr.com/ru/companies/datasapience/articles/941046/
#ru
@big_data_analysis | Другие наши каналы
👍1
Воспроизводимый рейтинг: можно ли с помощью краудсорсинга предсказать выбор пользователей LLM?
Всем привет! Сегодня хотим поделиться историей нашего эксперимента, который начался с простого вопроса: а можно ли с помощью краудсорсинга воссоздать рейтинг нейросетей, который мы получаем от тысяч реальных пользователей на нашем сайте LLM Arena?
Причём не в жёсткой парадигме «оцени по инструкции», а приближаясь к реальному user preference, когда пользователь выбирает то, что ему субъективно больше нравится.
TL/DR:
* Мы можем за 3 дня воспроизвести пользовательский рейтинг LLM с точностью 90%+;
* У нас есть отобранная команда аннотаторов и автоматический фильтр качества;
* Мы научились фильтровать фрод и мусорные промпты лучше, чем стандартные крауд-платформы;;
* Теперь мы можем быстро тестировать новые модели и выдавать предрейтинг до массового запуска.
Читать: https://habr.com/ru/articles/941072/
#ru
@big_data_analysis | Другие наши каналы
Всем привет! Сегодня хотим поделиться историей нашего эксперимента, который начался с простого вопроса: а можно ли с помощью краудсорсинга воссоздать рейтинг нейросетей, который мы получаем от тысяч реальных пользователей на нашем сайте LLM Arena?
Причём не в жёсткой парадигме «оцени по инструкции», а приближаясь к реальному user preference, когда пользователь выбирает то, что ему субъективно больше нравится.
TL/DR:
* Мы можем за 3 дня воспроизвести пользовательский рейтинг LLM с точностью 90%+;
* У нас есть отобранная команда аннотаторов и автоматический фильтр качества;
* Мы научились фильтровать фрод и мусорные промпты лучше, чем стандартные крауд-платформы;;
* Теперь мы можем быстро тестировать новые модели и выдавать предрейтинг до массового запуска.
Читать: https://habr.com/ru/articles/941072/
#ru
@big_data_analysis | Другие наши каналы
Переосмысление материализованных представлений: высокопроизводительный инструмент для единого lakehouse
Материализованные представления в StarRocks упрощают моделирование данных, ускоряют запросы и повышают актуальность данных в lakehouse‑архитектуре. Разбираем базовые возможности MV, три практических сценария — моделирование, прозрачное ускорение и «lake + warehouse» — и даём ссылки на актуальные рекомендации для StarRocks 3.5.
Читать: https://habr.com/ru/articles/941588/
#ru
@big_data_analysis | Другие наши каналы
Материализованные представления в StarRocks упрощают моделирование данных, ускоряют запросы и повышают актуальность данных в lakehouse‑архитектуре. Разбираем базовые возможности MV, три практических сценария — моделирование, прозрачное ускорение и «lake + warehouse» — и даём ссылки на актуальные рекомендации для StarRocks 3.5.
Читать: https://habr.com/ru/articles/941588/
#ru
@big_data_analysis | Другие наши каналы
👍1
Как мы устроили эпический BI Challenge: 80 героев, 1000 дашбордов и море данных в FineBI
Привет, Хабр! 👋 Меня зовут Семён Юников, я Head of BI в банке Уралсиб. Сегодня расскажу о том, как наш отдел собственными силами превратил масштабную задачу по улучшению аналитических артефактов в захватывающее и геймифицированное приключение под названием BI Challenge. Более 80 участников (внутренних разработчиков нашего Банка), свыше 1000 дашбордов, десятки внутренних обновлений и одно большое профессиональное сообщество.
😎
Читать: https://habr.com/ru/companies/uralsib/articles/941614/
#ru
@big_data_analysis | Другие наши каналы
Привет, Хабр! 👋 Меня зовут Семён Юников, я Head of BI в банке Уралсиб. Сегодня расскажу о том, как наш отдел собственными силами превратил масштабную задачу по улучшению аналитических артефактов в захватывающее и геймифицированное приключение под названием BI Challenge. Более 80 участников (внутренних разработчиков нашего Банка), свыше 1000 дашбордов, десятки внутренних обновлений и одно большое профессиональное сообщество.
😎
Читать: https://habr.com/ru/companies/uralsib/articles/941614/
#ru
@big_data_analysis | Другие наши каналы
Spark 4.0 на горизонте: Готовимся к апгрейду или остаёмся на проверенном 3.0?
Привет, Хабр! Я Станислав Габдулгазиев, архитектор департамента поддержки продаж Arenadata. Кажется, ещё вчера мы радовались возможностям Apache Spark 3.0, разбирались с Adaptive Query Execution и наслаждались улучшениями Pandas API. Но мир больших данных не стоит на месте, и вот уже на подходе Apache Spark 4.0. Новый мажорный релиз — это всегда событие: он обещает новые фичи, прирост производительности и, конечно же, новые вызовы при миграции.
Apache Spark де-факто стал стандартом для распределённой обработки данных. От классических ETL-пайплайнов и SQL-аналитики до сложного машинного обучения и стриминга — Spark так или иначе задействован во многих современных data-платформах. Поэтому каждый новый релиз вызывает живой интерес у комьюнити: что там под капотом? Какие проблемы решены? Не сломается ли то, что работало годами?
Читать: https://habr.com/ru/companies/arenadata/articles/921252/
#ru
@big_data_analysis | Другие наши каналы
Привет, Хабр! Я Станислав Габдулгазиев, архитектор департамента поддержки продаж Arenadata. Кажется, ещё вчера мы радовались возможностям Apache Spark 3.0, разбирались с Adaptive Query Execution и наслаждались улучшениями Pandas API. Но мир больших данных не стоит на месте, и вот уже на подходе Apache Spark 4.0. Новый мажорный релиз — это всегда событие: он обещает новые фичи, прирост производительности и, конечно же, новые вызовы при миграции.
Apache Spark де-факто стал стандартом для распределённой обработки данных. От классических ETL-пайплайнов и SQL-аналитики до сложного машинного обучения и стриминга — Spark так или иначе задействован во многих современных data-платформах. Поэтому каждый новый релиз вызывает живой интерес у комьюнити: что там под капотом? Какие проблемы решены? Не сломается ли то, что работало годами?
Читать: https://habr.com/ru/companies/arenadata/articles/921252/
#ru
@big_data_analysis | Другие наши каналы
👍1
Как строить умных AI-агентов: уроки Context Engineering от Manus
В самом начале проекта Manus перед нашей командой встал ключевой вопрос: обучать ли end-to-end агентную модель, используя open-source foundation-модели, или же строить агента поверх возможностей in-context learning у frontier models?
В моё первое десятилетие в NLP у нас и выбора-то такого не было. В далёкие времена BERT (да, прошло уже семь лет) модели приходилось fine-tune'ить и тестировать, прежде чем они могли переноситься на новую задачу. Этот процесс часто занимал недели на одну итерацию, даже при том, что тогдашние модели были крошечными по сравнению с сегодняшними LLM. Для быстроразвивающихся приложений, особенно на этапе до PMF, такие медленные циклы обратной связи — смертный приговор. Это был горький урок из моего прошлого стартапа, где я обучал модели с нуля для open information extraction и семантического поиска. А потом появились GPT-3 и Flan-T5, и мои внутренние модели стали не актуальны буквально за ночь. Ирония в том, что именно эти модели положили начало in-context learning — и открыли совершенно новый путь развития.
Из этого болезненного опыта выбор был очевиден: Manus делает ставку на context engineering. Это позволяет выпускать улучшения за часы, а не за недели, и держит наш продукт ортогональным по отношению к базовым моделям: если прогресс моделей — это прилив, то мы хотим, чтобы Manus был лодкой, а не сваей, вбитой в морское дно.
Тем не менее context engineering оказался далеко не тривиальным делом. Это экспериментальная наука — и мы перестраивали наш агентный фреймворк четыре раза, каждый раз находя более удачный способ формировать контекст. Мы с любовью называем этот ручной процесс перебора архитектур, подбора промптов и эмпирических догадок «Stochastic Graduate Descent». Это не изящно, но работает.
В этом посте я делюсь локальными оптимумами, к которым мы пришли через собственный «SGD». Если вы создаете своего AI-агента, надеюсь, эти принципы помогут вам сойтись к решению быстрее.
Читать: https://habr.com/ru/articles/936954/
#ru
@big_data_analysis | Другие наши каналы
В самом начале проекта Manus перед нашей командой встал ключевой вопрос: обучать ли end-to-end агентную модель, используя open-source foundation-модели, или же строить агента поверх возможностей in-context learning у frontier models?
В моё первое десятилетие в NLP у нас и выбора-то такого не было. В далёкие времена BERT (да, прошло уже семь лет) модели приходилось fine-tune'ить и тестировать, прежде чем они могли переноситься на новую задачу. Этот процесс часто занимал недели на одну итерацию, даже при том, что тогдашние модели были крошечными по сравнению с сегодняшними LLM. Для быстроразвивающихся приложений, особенно на этапе до PMF, такие медленные циклы обратной связи — смертный приговор. Это был горький урок из моего прошлого стартапа, где я обучал модели с нуля для open information extraction и семантического поиска. А потом появились GPT-3 и Flan-T5, и мои внутренние модели стали не актуальны буквально за ночь. Ирония в том, что именно эти модели положили начало in-context learning — и открыли совершенно новый путь развития.
Из этого болезненного опыта выбор был очевиден: Manus делает ставку на context engineering. Это позволяет выпускать улучшения за часы, а не за недели, и держит наш продукт ортогональным по отношению к базовым моделям: если прогресс моделей — это прилив, то мы хотим, чтобы Manus был лодкой, а не сваей, вбитой в морское дно.
Тем не менее context engineering оказался далеко не тривиальным делом. Это экспериментальная наука — и мы перестраивали наш агентный фреймворк четыре раза, каждый раз находя более удачный способ формировать контекст. Мы с любовью называем этот ручной процесс перебора архитектур, подбора промптов и эмпирических догадок «Stochastic Graduate Descent». Это не изящно, но работает.
В этом посте я делюсь локальными оптимумами, к которым мы пришли через собственный «SGD». Если вы создаете своего AI-агента, надеюсь, эти принципы помогут вам сойтись к решению быстрее.
Читать: https://habr.com/ru/articles/936954/
#ru
@big_data_analysis | Другие наши каналы