Когда рост лидов превращается в деградацию процесса: кейс про перегрев колл-центра
Аномалия: CRM «горит», хотя графики растут
Утро. На белой доске ещё держится вчерашний план смены, а в CRM задачи мигают красным — как гирлянда, только без ощущения праздника. При этом на дашбордах всё выглядит прилично: лидов больше, звонков больше, эфир растёт.
Проблема в том, что «больше» не всегда означает «лучше». В процессах с ограниченным ресурсом (в нашем случае — люди и минуты эфира) рост входа часто масштабирует не результат, а потери: очереди, лишние пересадки, паузы в коммуникации, усталость смены.
Эта статья — про момент, когда мы перестали считать рост лидов победой и начали смотреть на управляемость. Данные простые, выводы — скучные. Но именно скучные решения обычно держат систему.
Контекст: вход процесса — лид, выход — следующий шаг
Мы — Lead IT. Приводим застройщикам лиды по фиксированной цене и работаем по CPA. Плюс держим свой колл‑центр..
Чтобы не путаться, зафиксируем термины как процесс.
Читать: https://habr.com/ru/articles/981598/
#ru
@big_data_analysis | Другие наши каналы
Аномалия: CRM «горит», хотя графики растут
Утро. На белой доске ещё держится вчерашний план смены, а в CRM задачи мигают красным — как гирлянда, только без ощущения праздника. При этом на дашбордах всё выглядит прилично: лидов больше, звонков больше, эфир растёт.
Проблема в том, что «больше» не всегда означает «лучше». В процессах с ограниченным ресурсом (в нашем случае — люди и минуты эфира) рост входа часто масштабирует не результат, а потери: очереди, лишние пересадки, паузы в коммуникации, усталость смены.
Эта статья — про момент, когда мы перестали считать рост лидов победой и начали смотреть на управляемость. Данные простые, выводы — скучные. Но именно скучные решения обычно держат систему.
Контекст: вход процесса — лид, выход — следующий шаг
Мы — Lead IT. Приводим застройщикам лиды по фиксированной цене и работаем по CPA. Плюс держим свой колл‑центр..
Чтобы не путаться, зафиксируем термины как процесс.
Читать: https://habr.com/ru/articles/981598/
#ru
@big_data_analysis | Другие наши каналы
Ускоряем загрузку данных в BI в 2 раза: кейс команды VK
Apache Superset — востребованное open-source решение для анализа данных, которое можно быстро установить и встроить в существующий технологический стек компании, благодаря большому количеству коннекторов и видов визуализаций. Однако для высоконагруженных систем и сложных сценариев некоторые компании дорабатывают исходную версию — например, внедряют инструменты автоматического кеширования и оптимизируют архитектуру хранения данных для построения графиков. По этому пути в своё время пошли и мы в VK.
Привет, Хабр. Меня зовут Никита Романов. Я руководитель команды разработки аналитических инструментов в VK. В этой статье расскажу о нашем опыте оптимизации Apache Superset под свои задачи.
Читать: https://habr.com/ru/companies/vk/articles/981820/
#ru
@big_data_analysis | Другие наши каналы
Apache Superset — востребованное open-source решение для анализа данных, которое можно быстро установить и встроить в существующий технологический стек компании, благодаря большому количеству коннекторов и видов визуализаций. Однако для высоконагруженных систем и сложных сценариев некоторые компании дорабатывают исходную версию — например, внедряют инструменты автоматического кеширования и оптимизируют архитектуру хранения данных для построения графиков. По этому пути в своё время пошли и мы в VK.
Привет, Хабр. Меня зовут Никита Романов. Я руководитель команды разработки аналитических инструментов в VK. В этой статье расскажу о нашем опыте оптимизации Apache Superset под свои задачи.
Читать: https://habr.com/ru/companies/vk/articles/981820/
#ru
@big_data_analysis | Другие наши каналы
Архитектура АИС «Налог-3»: или как работает ФНС на самом деле
Вокруг ФНС в последнее время крутится слишком много мифов. Последний из них — история про новогодний стол, икру и якобы контроль налоговой через фотографии в соцсетях.
Этот инфоповод и стал причиной написать статью. Не для того, чтобы обсуждать конкретную «страшилку», а чтобы показать как на самом деле устроен налоговый контроль: что ФНС реально проверяет, на какие данные опирается и почему большинство популярных представлений не имеет отношения к практике.
Я опираюсь не на слухи и пересказы, а на реальный опыт работы с налоговыми проверками и понимание внутренних механизмов ФНС. За плечами — 12 лет работы в налоговой системе в разных направлениях: предпроверочный анализ, камеральные проверки, выездные проверки и курирование отраслевых направлений внутри региона.
Читать: https://habr.com/ru/articles/981988/
#ru
@big_data_analysis | Другие наши каналы
Вокруг ФНС в последнее время крутится слишком много мифов. Последний из них — история про новогодний стол, икру и якобы контроль налоговой через фотографии в соцсетях.
Этот инфоповод и стал причиной написать статью. Не для того, чтобы обсуждать конкретную «страшилку», а чтобы показать как на самом деле устроен налоговый контроль: что ФНС реально проверяет, на какие данные опирается и почему большинство популярных представлений не имеет отношения к практике.
Я опираюсь не на слухи и пересказы, а на реальный опыт работы с налоговыми проверками и понимание внутренних механизмов ФНС. За плечами — 12 лет работы в налоговой системе в разных направлениях: предпроверочный анализ, камеральные проверки, выездные проверки и курирование отраслевых направлений внутри региона.
Читать: https://habr.com/ru/articles/981988/
#ru
@big_data_analysis | Другие наши каналы
ИИтоги 2025 года
Весь год я ежедневно следил за новостями в области искусственного интеллекта. И очень устал. Имена новых моделей, бьющих очередные бенчмарки, превращаются в шум, а мозг уже не реагирует на очередные срочные (!) сообщения инфлюэнсеров о БЕЗУМНОМ прорыве. На деле такое количество информации избыточно, если только вам профессионально не нужно следить за какой-либо областью. Но охота видеть развитие технологий широкими мазками, чтобы понимать изменения на горизонте месяцев и лет. Не найдя такой высокоуровневой подборки, которая бы меня устроила, я решил написать её сам. В этой статье вы найдёте описание развития ИИ за год. Что изменилось в технологиях за 2026 год? Какие компании и стартапы сейчас на слуху? Как ИИ влияет на экономику и регуляции? Помогает ли ИИ двигать науку и медицину? Ответы (с мемами!) смотрите в статье
Читать: https://habr.com/ru/articles/982056/
#ru
@big_data_analysis | Другие наши каналы
Весь год я ежедневно следил за новостями в области искусственного интеллекта. И очень устал. Имена новых моделей, бьющих очередные бенчмарки, превращаются в шум, а мозг уже не реагирует на очередные срочные (!) сообщения инфлюэнсеров о БЕЗУМНОМ прорыве. На деле такое количество информации избыточно, если только вам профессионально не нужно следить за какой-либо областью. Но охота видеть развитие технологий широкими мазками, чтобы понимать изменения на горизонте месяцев и лет. Не найдя такой высокоуровневой подборки, которая бы меня устроила, я решил написать её сам. В этой статье вы найдёте описание развития ИИ за год. Что изменилось в технологиях за 2026 год? Какие компании и стартапы сейчас на слуху? Как ИИ влияет на экономику и регуляции? Помогает ли ИИ двигать науку и медицину? Ответы (с мемами!) смотрите в статье
Читать: https://habr.com/ru/articles/982056/
#ru
@big_data_analysis | Другие наши каналы
Как я вкатывался в Clickhouse
Я блокчейн разработчик, и в проекте у нас базы на сотни гигабайт с децентрализованных бирж. Чтобы строить аналитические отчеты и делать агрегации, такие как вычисления цен, биржевых свечей, объемов торгов, цен на токены, мы используем БД Clickhouse. До этого я работал только с Postgres (и давно с MSSQL), и хочу рассказать, как я вкатывался, что удивило – практический опыт и WTFы. Прочитав эту статью вам, возможно, захочется сделать аналитику по своим данным в Clickhouse – возможно, ищете, что полезного освоить на длинных выходных. Итак, поехали!
Читать: https://habr.com/ru/articles/982130/
#ru
@big_data_analysis | Другие наши каналы
Я блокчейн разработчик, и в проекте у нас базы на сотни гигабайт с децентрализованных бирж. Чтобы строить аналитические отчеты и делать агрегации, такие как вычисления цен, биржевых свечей, объемов торгов, цен на токены, мы используем БД Clickhouse. До этого я работал только с Postgres (и давно с MSSQL), и хочу рассказать, как я вкатывался, что удивило – практический опыт и WTFы. Прочитав эту статью вам, возможно, захочется сделать аналитику по своим данным в Clickhouse – возможно, ищете, что полезного освоить на длинных выходных. Итак, поехали!
Читать: https://habr.com/ru/articles/982130/
#ru
@big_data_analysis | Другие наши каналы
👍2❤1
CUPED на практике: когда помогает, когда мешает и что проверить перед применением
CUPED часто рекомендуют как простой способ сделать A‑B тесты чувствительнее, но в реальных экспериментах он может как помочь, так и навредить. Причины почти всегда практические: историческая ковариата пересекается по времени с экспериментом, отличается единица анализа, есть пропуски или выбросы настолько велики и значительны, что оценка коэффициента становится неустойчивой.
В этом разборе я покажу CUPED на примерах, близких к продовым метрикам вроде выручки на пользователя. Мы посмотрим, почему стандартный анализ плохо работает при выбросах, как меняется ширина доверительных интервалов при добавлении CUPED, и что происходит с мощностью и ошибкой первого рода. Отдельный акцент — как выбирать исторические данные для ковариаты и как не поймать утечку воздействия в предэкспериментальный период. В конце практический набор проверок, чтобы CUPED был полезным инструментом, но не источником искаженных выводов.
Читать: https://habr.com/ru/articles/982280/
#ru
@big_data_analysis | Другие наши каналы
CUPED часто рекомендуют как простой способ сделать A‑B тесты чувствительнее, но в реальных экспериментах он может как помочь, так и навредить. Причины почти всегда практические: историческая ковариата пересекается по времени с экспериментом, отличается единица анализа, есть пропуски или выбросы настолько велики и значительны, что оценка коэффициента становится неустойчивой.
В этом разборе я покажу CUPED на примерах, близких к продовым метрикам вроде выручки на пользователя. Мы посмотрим, почему стандартный анализ плохо работает при выбросах, как меняется ширина доверительных интервалов при добавлении CUPED, и что происходит с мощностью и ошибкой первого рода. Отдельный акцент — как выбирать исторические данные для ковариаты и как не поймать утечку воздействия в предэкспериментальный период. В конце практический набор проверок, чтобы CUPED был полезным инструментом, но не источником искаженных выводов.
Читать: https://habr.com/ru/articles/982280/
#ru
@big_data_analysis | Другие наши каналы
👍1
АИС «Налог-3»: почему это одна из самых мощных государственных IT-систем России
За последнее десятилетие Федеральная налоговая служба (ФНС) совершила фундаментальный переход от традиционной модели администрирования к подходу, основанному на анализе больших баз данных.
Если вы соприкасались с налоговой системой - проходили проверки, бывали на комиссиях в инспекциях, общались с налоговыми органами, то вы слышали про АИС «Налог-3», одну из самых масштабных государственных IT-платформ в России.
Я проработал в системе налоговых органов 12 лет - от рядового инспектора в ИФНС до заместителя начальника отдела проведения налоговых проверок Управления ФНС - и наблюдал эту трансформацию изнутри. В этой статье я хочу показать, насколько эта система действительно мощная, как она эволюционировала, что она реально умеет сегодня и почему, несмотря на весь объём данных, это пока не «искусственный интеллект, который всё делает сам»
Сразу обозначу границу: я не раскрываю никакой служебной информации. Всё, о чём в статье пойдёт речь, это обобщение моего опыта работы в службе и данные, которые размещены в открытом доступе. Из налоговых органов я ушёл относительно недавно (2 месяца назад), и за это время мало, что могло поменяться, поэтому информация все еще остается актуальной.
Читать: https://habr.com/ru/articles/982504/
#ru
@big_data_analysis | Другие наши каналы
За последнее десятилетие Федеральная налоговая служба (ФНС) совершила фундаментальный переход от традиционной модели администрирования к подходу, основанному на анализе больших баз данных.
Если вы соприкасались с налоговой системой - проходили проверки, бывали на комиссиях в инспекциях, общались с налоговыми органами, то вы слышали про АИС «Налог-3», одну из самых масштабных государственных IT-платформ в России.
Я проработал в системе налоговых органов 12 лет - от рядового инспектора в ИФНС до заместителя начальника отдела проведения налоговых проверок Управления ФНС - и наблюдал эту трансформацию изнутри. В этой статье я хочу показать, насколько эта система действительно мощная, как она эволюционировала, что она реально умеет сегодня и почему, несмотря на весь объём данных, это пока не «искусственный интеллект, который всё делает сам»
Сразу обозначу границу: я не раскрываю никакой служебной информации. Всё, о чём в статье пойдёт речь, это обобщение моего опыта работы в службе и данные, которые размещены в открытом доступе. Из налоговых органов я ушёл относительно недавно (2 месяца назад), и за это время мало, что могло поменяться, поэтому информация все еще остается актуальной.
Читать: https://habr.com/ru/articles/982504/
#ru
@big_data_analysis | Другие наши каналы
👍2🔥1
Почему внедрение LLM в АИС «Налог-3» неизбежно — и что это изменит в налоговом контроле
После моей статьи про АИС «Налог-3» (как одну из самых мощных государственных IT-систем России) в комментариях больше всего спорили не про масштабы данных и вопроса, «видит ли ФНС всё». Основной скепсис вызвал мой тезис о необходимости внедрения больших языковых моделей (LLM) в работу налоговых органов.
Основной аргумент в противовес моей позиции звучал так: «Зачем там нужен Искусственный Интеллект? Всё формализовано, достаточно жестких алгоритмов и грамотных шаблонов. Экспертная система справится сама, не надо усложнять».
В этой статье я постараюсь привнести ясность в то, как происходит сбор доказательственной базы по налоговым правонарушениям и как формируется итоговый документ (акт и решение по налоговой проверки). Потому что в реальной налоговой проверке проблема не в том, чтобы найти риск или подсветить признаки. Это АИС «Налог-3» уже умеет делать достаточно хорошо. Проблема в другом - превратить массив фактов в доказательства и выводы, а затем изложить это в юридически выверенном тексте, который выдержит спор сначала на стадии возражений, потом в вышестоящем налоговом органе, а при необходимости и в суде.
Если вы читаете меня впервые: я не аналитик со стороны и не «диванный эксперт». За моими словами 12 лет работы в налоговых органах, в том числе на руководящих должностях. Из системы я ушёл совсем недавно и прекрасно понимаю, как это работает изнутри.
Читать: https://habr.com/ru/articles/982686/
#ru
@big_data_analysis | Другие наши каналы
После моей статьи про АИС «Налог-3» (как одну из самых мощных государственных IT-систем России) в комментариях больше всего спорили не про масштабы данных и вопроса, «видит ли ФНС всё». Основной скепсис вызвал мой тезис о необходимости внедрения больших языковых моделей (LLM) в работу налоговых органов.
Основной аргумент в противовес моей позиции звучал так: «Зачем там нужен Искусственный Интеллект? Всё формализовано, достаточно жестких алгоритмов и грамотных шаблонов. Экспертная система справится сама, не надо усложнять».
В этой статье я постараюсь привнести ясность в то, как происходит сбор доказательственной базы по налоговым правонарушениям и как формируется итоговый документ (акт и решение по налоговой проверки). Потому что в реальной налоговой проверке проблема не в том, чтобы найти риск или подсветить признаки. Это АИС «Налог-3» уже умеет делать достаточно хорошо. Проблема в другом - превратить массив фактов в доказательства и выводы, а затем изложить это в юридически выверенном тексте, который выдержит спор сначала на стадии возражений, потом в вышестоящем налоговом органе, а при необходимости и в суде.
Если вы читаете меня впервые: я не аналитик со стороны и не «диванный эксперт». За моими словами 12 лет работы в налоговых органах, в том числе на руководящих должностях. Из системы я ушёл совсем недавно и прекрасно понимаю, как это работает изнутри.
Читать: https://habr.com/ru/articles/982686/
#ru
@big_data_analysis | Другие наши каналы
Особенности ALL как модификатора CALCULATE и как «создателя» новой таблицы в FILTER
DAX содержит гибкие возможности фильтрации, и важными функциями являются
Интересующимся особенностями
Читать: https://habr.com/ru/articles/982246/
#ru
@big_data_analysis | Другие наши каналы
DAX содержит гибкие возможности фильтрации, и важными функциями являются
ALL и REMOVEFILTERS. При использовании ALL и REMOVEFILTERS в качестве модификатора CALCULATE они ведут себя одинаково, т.к. в этом случае REMOVEFILTERS является псевдонимом ALL, однако ALL в FILTER возвращает «новую таблицу» и очищает влияние всех фильтров, что важно учитывать с точки зрения производительности и результатов.Интересующимся особенностями
ALL и сравнением ALL и REMOVEFILTERS — добро пожаловать под кат :)Читать: https://habr.com/ru/articles/982246/
#ru
@big_data_analysis | Другие наши каналы
Как я пытался создать «конструктор налоговых проверок» для повышения эффективности работы ФНС
Для начала - немного контекста. Я не программист и не разработчик. Последние 12 лет я проработал в Федеральной налоговой службе. Начинал с низов, занимался выездными и камеральными проверками (проводил лично и курировал). Два месяца назад я уволился, завел свой телеграм-канал и теперь работаю в налоговом консалтинге.
Эта статья - история о том, как я попытался решить огромную проблему государственной системы с помощью домашнего ноутбука и нейросетей. О том, как я переоценил свои силы, недооценил масштаб задачи, но все-таки попробовал создать инструмент, который мог бы изменить работу инспектора.
Читать: https://habr.com/ru/articles/982938/
#ru
@big_data_analysis | Другие наши каналы
Для начала - немного контекста. Я не программист и не разработчик. Последние 12 лет я проработал в Федеральной налоговой службе. Начинал с низов, занимался выездными и камеральными проверками (проводил лично и курировал). Два месяца назад я уволился, завел свой телеграм-канал и теперь работаю в налоговом консалтинге.
Эта статья - история о том, как я попытался решить огромную проблему государственной системы с помощью домашнего ноутбука и нейросетей. О том, как я переоценил свои силы, недооценил масштаб задачи, но все-таки попробовал создать инструмент, который мог бы изменить работу инспектора.
Читать: https://habr.com/ru/articles/982938/
#ru
@big_data_analysis | Другие наши каналы
🔥1
Как мы загрузили историю 287 валютных пар с лимитом 8 запросов в минуту
Попробуйте найти исторические курсы для пар вроде «доллар к афгани» или «евро к таджикскому сомони». Данные либо платные, либо их просто нет в виде готового датасета. Мы решили эту проблему в рамках своего проекта, хотя единственный подходящий API диктовал суровые условия: 8 запросов в минуту и 5000 дней за раз.
Получилось! Наш Python-скрипт аккуратно, чанк за чанком, собрал историю всех 287 пар за 4.5 часа, ни разу не превысив лимит. Теперь все эти данные — более миллиона строк — лежат в открытом доступе на GitHub. В статье делюсь техническими деталями, как выстроить такую загрузку, и уроками, которые мы извлекли.
Читать: https://habr.com/ru/articles/983024/
#ru
@big_data_analysis | Другие наши каналы
Попробуйте найти исторические курсы для пар вроде «доллар к афгани» или «евро к таджикскому сомони». Данные либо платные, либо их просто нет в виде готового датасета. Мы решили эту проблему в рамках своего проекта, хотя единственный подходящий API диктовал суровые условия: 8 запросов в минуту и 5000 дней за раз.
Получилось! Наш Python-скрипт аккуратно, чанк за чанком, собрал историю всех 287 пар за 4.5 часа, ни разу не превысив лимит. Теперь все эти данные — более миллиона строк — лежат в открытом доступе на GitHub. В статье делюсь техническими деталями, как выстроить такую загрузку, и уроками, которые мы извлекли.
Читать: https://habr.com/ru/articles/983024/
#ru
@big_data_analysis | Другие наши каналы
Как мы ввели автосертификацию дашбордов в Авито
Привет, Хабр! Меня зовут Евгений Мичурин, я senior BI-разработчик в Авито. Если у вас BI растёт хаотично — вы наверняка сталкивались с тем же, что и мы: сотни дашбордов, разный стиль, неясные владельцы, дублирующиеся датасеты. В какой-то момент это превращается в хаос, где пользователи не доверяют данным, а self-аналитика становится невозможной.
Мы решили навести порядок и создали фреймворк автосертификации BI‑отчётов. В этой статье рассказываю, как он работает, какие критерии мы выбрали и как мотивировали команды участвовать в процессе.
Читать: https://habr.com/ru/companies/avito/articles/983260/
#ru
@big_data_analysis | Другие наши каналы
Привет, Хабр! Меня зовут Евгений Мичурин, я senior BI-разработчик в Авито. Если у вас BI растёт хаотично — вы наверняка сталкивались с тем же, что и мы: сотни дашбордов, разный стиль, неясные владельцы, дублирующиеся датасеты. В какой-то момент это превращается в хаос, где пользователи не доверяют данным, а self-аналитика становится невозможной.
Мы решили навести порядок и создали фреймворк автосертификации BI‑отчётов. В этой статье рассказываю, как он работает, какие критерии мы выбрали и как мотивировали команды участвовать в процессе.
Читать: https://habr.com/ru/companies/avito/articles/983260/
#ru
@big_data_analysis | Другие наши каналы
👍3
Инструмент перехвата медленных запросов StarRocks
Практическое руководство по построению сервиса перехвата медленных запросов в StarRocks: правила kill и пороги (full table scan, scan rows/bytes), анализ execution plan, интеграции с Grafana и Feishu, SQL-схемы и YAML-конфигурация для продакшена.
Читать: https://habr.com/ru/articles/983314/
#ru
@big_data_analysis | Другие наши каналы
Практическое руководство по построению сервиса перехвата медленных запросов в StarRocks: правила kill и пороги (full table scan, scan rows/bytes), анализ execution plan, интеграции с Grafana и Feishu, SQL-схемы и YAML-конфигурация для продакшена.
Читать: https://habr.com/ru/articles/983314/
#ru
@big_data_analysis | Другие наши каналы
Как JOIN изменил наш подход к инфраструктуре данных в NAVER
После миграции с ClickHouse на StarRocks NAVER существенно оптимизировала обработку многотабличных JOIN. StarRocks повысил производительность запросов, обеспечил бесшовное масштабирование и позволил построить единый слой запросов, совместимый с множеством источников данных. Эти улучшения позволили предоставлять инсайты в реальном времени и поддерживать принятие решений на основе данных во всей экосистеме NAVER.
Читать: https://habr.com/ru/articles/983356/
#ru
@big_data_analysis | Другие наши каналы
После миграции с ClickHouse на StarRocks NAVER существенно оптимизировала обработку многотабличных JOIN. StarRocks повысил производительность запросов, обеспечил бесшовное масштабирование и позволил построить единый слой запросов, совместимый с множеством источников данных. Эти улучшения позволили предоставлять инсайты в реальном времени и поддерживать принятие решений на основе данных во всей экосистеме NAVER.
Читать: https://habr.com/ru/articles/983356/
#ru
@big_data_analysis | Другие наши каналы
Когда ИИ не понимает бизнес-контексты
Сегодня многие компании внедряют ИИ‑ассистентов, которые автоматически пишут SQL‑запросы и помогают менеджерам готовить отчеты. На первый взгляд они отлично справляются с цифрами и синтаксисом, но теряются, когда дело доходит до бизнес-контекста. Почему? Потому что бизнес живет не только данными, но и контекстом: историей компании, внутренними правилами, неформальными договоренностями, культурой.
В результате ИИ превращается в «умное автодополнение», а не в стратегический инструмент. В этой статье разберем, что именно мешает алгоритмам учитывать бизнес‑контекст и какие инженерные подходы помогают превратить статистического помощника в полноценного участника управленческих процессов.
Читать: https://habr.com/ru/companies/beget/articles/980974/
#ru
@big_data_analysis | Другие наши каналы
Сегодня многие компании внедряют ИИ‑ассистентов, которые автоматически пишут SQL‑запросы и помогают менеджерам готовить отчеты. На первый взгляд они отлично справляются с цифрами и синтаксисом, но теряются, когда дело доходит до бизнес-контекста. Почему? Потому что бизнес живет не только данными, но и контекстом: историей компании, внутренними правилами, неформальными договоренностями, культурой.
В результате ИИ превращается в «умное автодополнение», а не в стратегический инструмент. В этой статье разберем, что именно мешает алгоритмам учитывать бизнес‑контекст и какие инженерные подходы помогают превратить статистического помощника в полноценного участника управленческих процессов.
Читать: https://habr.com/ru/companies/beget/articles/980974/
#ru
@big_data_analysis | Другие наши каналы
Типология мышления в аналитической культуре больших языковых моделей (Часть_1)
Миронов В.О., Кальченко С.Н.
Введение
Добрый день, уважаемые хаброгорожане ;)) Крайние тренды по части тестирования современных больших языковых моделей выходят на невиданные высоты и ставится цель: пересматривать не только всю систему анализа моделей, но и саму структуру эволюции нашего подхода к пониманию больших языковых моделей в самом широком контексте. Здесь мы всё больше “скатываемся” к математическому описанию объекта промпта и его понятия. По большому счету, наибольшее понимание, а именно, формирование идей в машинном представлении, основано на геометрическом понимании “форм” слов, а не алгебраическом, в виде векторов, эмбеддингов и матриц, хотя это тоже очень важно на базовом уровне. Отличный пример такого подхода изложен в этой статье, где как раз и показано, что важно, топологическое представление пространства слов и их смыслов, так как оно максимально гибко и позволяет работать с двумя главными понятиями для словоформ: значение и время, в течение которого это значение сохраняется для текущего контекста.
Исходя из этого, не так давно мы проводили анализ понимания речи для чат-ботов и, в частности, для больших языковых моделей. При этом мы задались очень ёмким понятием: каково отношение между пользователем и нейросетью и насколько они хорошо друг друга “понимают”. Чем полнее и общо мы сможем очертить границы этого “понимания”, тем более полно мы сможем формировать промпты для наших запросов, расширить новый уровень абстракции и сформировать новый уровень понимания кода моделью.
Читать: https://habr.com/ru/articles/984062/
#ru
@big_data_analysis | Другие наши каналы
Миронов В.О., Кальченко С.Н.
Введение
Добрый день, уважаемые хаброгорожане ;)) Крайние тренды по части тестирования современных больших языковых моделей выходят на невиданные высоты и ставится цель: пересматривать не только всю систему анализа моделей, но и саму структуру эволюции нашего подхода к пониманию больших языковых моделей в самом широком контексте. Здесь мы всё больше “скатываемся” к математическому описанию объекта промпта и его понятия. По большому счету, наибольшее понимание, а именно, формирование идей в машинном представлении, основано на геометрическом понимании “форм” слов, а не алгебраическом, в виде векторов, эмбеддингов и матриц, хотя это тоже очень важно на базовом уровне. Отличный пример такого подхода изложен в этой статье, где как раз и показано, что важно, топологическое представление пространства слов и их смыслов, так как оно максимально гибко и позволяет работать с двумя главными понятиями для словоформ: значение и время, в течение которого это значение сохраняется для текущего контекста.
Исходя из этого, не так давно мы проводили анализ понимания речи для чат-ботов и, в частности, для больших языковых моделей. При этом мы задались очень ёмким понятием: каково отношение между пользователем и нейросетью и насколько они хорошо друг друга “понимают”. Чем полнее и общо мы сможем очертить границы этого “понимания”, тем более полно мы сможем формировать промпты для наших запросов, расширить новый уровень абстракции и сформировать новый уровень понимания кода моделью.
Читать: https://habr.com/ru/articles/984062/
#ru
@big_data_analysis | Другие наши каналы
Визуализация на Python за 15 минут: пошаговый гайд по Seaborn для начинающих
Matplotlib — это мощно, но часто «многословно». Чтобы превратить стандартный график в нечто презентабельное, приходится писать десятки строк настройки осей и легенд.
В этой статье я собрал практическую шпаргалку (Cookbook) по библиотеке Seaborn. Разберем, как одной строкой строить красивые Heatmap, Boxplot и Pairplot. Минимум теории, максимум готовых рецептов (copy-paste), которые покроют 90% задач аналитика.
Читать: https://habr.com/ru/articles/984144/
#ru
@big_data_analysis | Другие наши каналы
Matplotlib — это мощно, но часто «многословно». Чтобы превратить стандартный график в нечто презентабельное, приходится писать десятки строк настройки осей и легенд.
В этой статье я собрал практическую шпаргалку (Cookbook) по библиотеке Seaborn. Разберем, как одной строкой строить красивые Heatmap, Boxplot и Pairplot. Минимум теории, максимум готовых рецептов (copy-paste), которые покроют 90% задач аналитика.
Читать: https://habr.com/ru/articles/984144/
#ru
@big_data_analysis | Другие наши каналы
Соискатель получил отказ в работе от Авито после фидбэка из Яндекса
Предисловие: вся информация находится в открытом доступе. Статья написана с целью привлечения внимания к общественно важной теме.
Я хочу всесторонне разобраться в ситуации, услышать комментарии всех участников (особенно компаний «Яндекс» и «Авито») и только после этого делать какие-либо выводы, и вас к этому тоже призываю.
Недавно вышло интервью HR из Яндекса основателю сообщества «Осознанная меркантильность». В нём говорилось о найме, «красных флагах» в резюме соискателей и другом булщите о найме, от которого уже тошнит...
Примерно сутки спустя в том же сообществе появился комментарий от девушки. Она увидела на YouTube интервью с сотрудницей Яндекса (конкретно из Финтеха, если ссылаться на содержание).
Девушка вспомнила, что эта сотрудница когда-то писала о ней пост в своём Telegram. Я чекнула, там 1500+ подписчиков, включая, скорее всего, HR, так как наша HR из этой истории является публичным лицом, активно участвует в конференциях для HR и ведёт подкаст о HR-сфере на YouTube.
По словам девушки-соискателя, пост HR был обезличен, но содержал много деталей, и её команда, скорее всего, поняла, что речь идёт о ней. Затем девушка пошла на собеседование в Авито, где получила отказ с формулировкой «нам дали плохой фидбэк в Яндексе». Кто дал — неясно. На каком основании вообще запрашивали этот фидбек — тоже неясно. Кто передал информацию о бывшем сотруднике — опять же непонятно.
Такое часто бывает на рынке труда. HR могут собирать информацию друг у друга по знакомству. Не факт, что запрос идёт к вашему бывшему руководителю или коллеге, ведь неизвестно, кто входит в круг общения конкретного рекрутера. Гипотетически возможна ситуация: у вас есть коллега, которая по своим причинам вас недолюбливает или даже ненавидит. HR случайно обратился за реферс, и вуаля, вы не только получаете отказ, но и в системе отслеживания кандидатов (ATS) потенциального работодателя появляется пометка «предыдущие коллеги дали плохой референс». Далее эта метка остаётся в системе, и даже спустя 2–3–4 года новый HR, не вникая в детали, может сделать по ней выводы и отказать вам.
Читать: https://habr.com/ru/articles/984172/
#ru
@big_data_analysis | Другие наши каналы
Предисловие: вся информация находится в открытом доступе. Статья написана с целью привлечения внимания к общественно важной теме.
Я хочу всесторонне разобраться в ситуации, услышать комментарии всех участников (особенно компаний «Яндекс» и «Авито») и только после этого делать какие-либо выводы, и вас к этому тоже призываю.
Недавно вышло интервью HR из Яндекса основателю сообщества «Осознанная меркантильность». В нём говорилось о найме, «красных флагах» в резюме соискателей и другом булщите о найме, от которого уже тошнит...
Примерно сутки спустя в том же сообществе появился комментарий от девушки. Она увидела на YouTube интервью с сотрудницей Яндекса (конкретно из Финтеха, если ссылаться на содержание).
Девушка вспомнила, что эта сотрудница когда-то писала о ней пост в своём Telegram. Я чекнула, там 1500+ подписчиков, включая, скорее всего, HR, так как наша HR из этой истории является публичным лицом, активно участвует в конференциях для HR и ведёт подкаст о HR-сфере на YouTube.
По словам девушки-соискателя, пост HR был обезличен, но содержал много деталей, и её команда, скорее всего, поняла, что речь идёт о ней. Затем девушка пошла на собеседование в Авито, где получила отказ с формулировкой «нам дали плохой фидбэк в Яндексе». Кто дал — неясно. На каком основании вообще запрашивали этот фидбек — тоже неясно. Кто передал информацию о бывшем сотруднике — опять же непонятно.
Такое часто бывает на рынке труда. HR могут собирать информацию друг у друга по знакомству. Не факт, что запрос идёт к вашему бывшему руководителю или коллеге, ведь неизвестно, кто входит в круг общения конкретного рекрутера. Гипотетически возможна ситуация: у вас есть коллега, которая по своим причинам вас недолюбливает или даже ненавидит. HR случайно обратился за реферс, и вуаля, вы не только получаете отказ, но и в системе отслеживания кандидатов (ATS) потенциального работодателя появляется пометка «предыдущие коллеги дали плохой референс». Далее эта метка остаётся в системе, и даже спустя 2–3–4 года новый HR, не вникая в детали, может сделать по ней выводы и отказать вам.
Читать: https://habr.com/ru/articles/984172/
#ru
@big_data_analysis | Другие наши каналы
❤1
Анимированные визуализации потоков данных: движение товаров, денег и пользователей
В современном мире данным кроме накапливания ещё присуще такое свойство как двигаться. Причём они движутся постоянно. Пользователи переходят между страницами и приложениями, товары перемещаются по глобальным логистическим сетям, а деньги циркулируют между счетами, банками и платёжными системами.
В таких условиях традиционные инструменты аналитики — таблицы, статические графики и отчёты, хорошо отвечают на вопросы сколько? и ему подобные, но плохо показывают как именно это происходит. Чтобы понять динамику процессов, выявить узкие места и увидеть реальные взаимосвязи, всё чаще используют анимированные визуализации потоков данных.
Именно о них предлагаю поговорить сегодня.
В этой статье разберёмся: зачем вообще нужна анимация данных, какие типы потоковых визуализаций существуют, какие технологии используются для их создания и в каких задачах они дают реальную пользу.
Читать: https://habr.com/ru/companies/timeweb/articles/981392/
#ru
@big_data_analysis | Другие наши каналы
В современном мире данным кроме накапливания ещё присуще такое свойство как двигаться. Причём они движутся постоянно. Пользователи переходят между страницами и приложениями, товары перемещаются по глобальным логистическим сетям, а деньги циркулируют между счетами, банками и платёжными системами.
В таких условиях традиционные инструменты аналитики — таблицы, статические графики и отчёты, хорошо отвечают на вопросы сколько? и ему подобные, но плохо показывают как именно это происходит. Чтобы понять динамику процессов, выявить узкие места и увидеть реальные взаимосвязи, всё чаще используют анимированные визуализации потоков данных.
Именно о них предлагаю поговорить сегодня.
В этой статье разберёмся: зачем вообще нужна анимация данных, какие типы потоковых визуализаций существуют, какие технологии используются для их создания и в каких задачах они дают реальную пользу.
Читать: https://habr.com/ru/companies/timeweb/articles/981392/
#ru
@big_data_analysis | Другие наши каналы
👍1
Embedding — как машины понимают смысл текста
Я уверен, вы видели модели машинного обучения, которые принимают текст и предсказывают, является ли он спамом. Аналогично модель может проанализировать отзыв о фильме и определить его тональность — положительную или отрицательную, понимать что «груша» связана с «яблоком» куда больше, чем с «теплоходом».
Первое правило обучения любой модели машинного обучения — это преобразование входных данных в числа. Цифровой объект можно представить числом: картинку, текст, аудио или видеофайл — практически всё что угодно.
Для того чтобы ввести этот объект в нашу ML модель как некое понятие, мы должны преобразовать его в определённый набор чисел. По этому набор чисел мы сможем определить, что, например, этот объект «яблоко», а не «груша».
С картинками все просто. В чёрно-белом изображении (в градациях серого) самый яркий пиксель имеет значение 1, самый тёмный — 0, а оттенки серого имеют значения от 0 до 1. Такое числовое представление упрощает обработку изображений. Преобразовав изображение в цифровую форму на основе значений пикселей, мы можем использовать его в качестве входных данных для обучения нашей модели, позволяя нейронной сети обучаться на значениях пикселей.
Однако что делать с текстом? Как спроецировать буквы в числа?
Читать: https://habr.com/ru/companies/ruvds/articles/983958/
#ru
@big_data_analysis | Другие наши каналы
Я уверен, вы видели модели машинного обучения, которые принимают текст и предсказывают, является ли он спамом. Аналогично модель может проанализировать отзыв о фильме и определить его тональность — положительную или отрицательную, понимать что «груша» связана с «яблоком» куда больше, чем с «теплоходом».
Первое правило обучения любой модели машинного обучения — это преобразование входных данных в числа. Цифровой объект можно представить числом: картинку, текст, аудио или видеофайл — практически всё что угодно.
Для того чтобы ввести этот объект в нашу ML модель как некое понятие, мы должны преобразовать его в определённый набор чисел. По этому набор чисел мы сможем определить, что, например, этот объект «яблоко», а не «груша».
С картинками все просто. В чёрно-белом изображении (в градациях серого) самый яркий пиксель имеет значение 1, самый тёмный — 0, а оттенки серого имеют значения от 0 до 1. Такое числовое представление упрощает обработку изображений. Преобразовав изображение в цифровую форму на основе значений пикселей, мы можем использовать его в качестве входных данных для обучения нашей модели, позволяя нейронной сети обучаться на значениях пикселей.
Однако что делать с текстом? Как спроецировать буквы в числа?
Читать: https://habr.com/ru/companies/ruvds/articles/983958/
#ru
@big_data_analysis | Другие наши каналы