Воспроизводимый рейтинг: можно ли с помощью краудсорсинга предсказать выбор пользователей 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 | Другие наши каналы