Big Data *

Привет! Меня зовут Саша Журавлев. Я основатель и управляющий партнер фонда Mento VC. Мы инвестируем в технологические компании на стадиях Seed / Series A в США, Великобритании и Израиле, а в своем телеграм-канале рассказываю, как вижу рынок и принимаю инвестиционные решения.

Одна из вещей, которую я заметил за много лет в венчуре – решения крупных фондов могут быть не так независимы, как принято считать. Мы со-инвестируем с top-tier фондами и пристально за ними наблюдаем. И со временем начали замечать паттерны: одни и те же фонды снова и снова вместе оказываются в одних и тех же сделках. Потому что у них похожий фокус, или есть еще какая-то связь?

Мы с командой Mento VC решили проверить это на данных. Проанализировали тысячи раундов топ-36 фондов мира – и обнаружили 8 устойчивых кланов Кремниевой долины (вообще-то, 11, но при более пристальной проверке трое как кланы не подтвердились). «Кланами» мы считаем группы фондов, которые связаны не только через стартапы, в которые инвестируют, но и рабочими, дружескими и даже семейными связями. Про это не принято говорить вслух, но кто вам еще расскажет если не мы? 🙂

Читайте наше исследование ниже, а если вам интересны регулярные заметки и инсайты о венчуре, разбор наших сделок и новости рынка - добро пожаловать в мой телеграм-канал.

Привет, Хабр! Я Миша Онянов, Python-разработчик и платформенный инженер в крупнейшем проекте MAGNIT TECH – F&R. Из статьи вы узнаете, как с помощью механизма Cluster Policies в Apache Airflow вынести требования к DAG’ам в исполняемый код:

- Поговорим о том, когда и зачем нужен отдельный слой Policies.

- Посмотрим на примеры требований в больших data-инженерных проектах и способ их реализации с помощью политик.

- Покажу нашу архитектуру, примеры кода и способы внедрения.

- Сделаем выводы из моих ошибок, допущенных при разработке и внедрении.

- В конце посмотрим, в каких ещё системах используется аналогичный механизм.

Материал будет полезен всем, кто собирается внедрять или уже работает с Apache Airflow ✌️🥸

Всем привет! Меня зовут Вардан Манучарян, я аналитик в команде Монетизации Авито, и мы отвечаем за механику алгоритмов продвижения, то есть управляем порядком, в котором пользователи видят объявления. Для этого нам нужно отслеживать, как изменения в ранжировании влияют на бизнес и покупателей. В этой статье расскажу про интерливинг, — метод, который помогает корректно проводить A/B-тесты с изменением ранжирования. Статья будет интересна аналитикам, которые проводят много A/B-тестов.

28 мая мы провели в Альпине закрытую мастер-встречу про то, как растить ИИ-компетенции в команде без миллионных бюджетов. На встречу подключились более 150 специалистов из фармы, ритейла, IT, логистики и банков. Я рассказывал про наш путь в AlpinaGPT, коллеги показывали свои кейсы в маркетинге, продажах и разработке, в зале задавали вопросы CTO и L&D-директора крупных российских компаний. После трёх часов разговоров у меня осталось одно главное наблюдение — то, ради чего я и пишу эту статью.

Меня зовут Жемал Хамидун, я CPO AlpinaGPT, Head of AI Alpina Digital и автор тг-канала «Готовим ИИшницу». Главное наблюдение простое: разрыв в ИИ-компетенциях растёт. Одни сотрудники работают с моделями ежедневно, у них уже свой стек, свои шаблоны, своя память между сессиями и встроенные в рабочий процесс агенты. Другие открыли ChatGPT один раз, написали что-то вроде «составь мне отчёт», получили шаблонный текст без контекста, решили, что инструмент бесполезный, и закрыли вкладку. Между этими двумя сотрудниками разрыв растёт каждый месяц быстрее, чем компании успевают его закрывать обучением. 

Разрыв в компетенциях растёт быстрее, чем обучение его закрывает

Главная цифра, которую я показывал на мастер-встрече, — из свежего отчёта DataCamp и YouGov State of Data & AI Literacy 2026 (опрос 517 enterprise-руководителей в США и Великобритании, декабрь 2025 — февраль 2026). 82% компаний уже предоставляют ИИ-обучение для сотрудников, и при этом 59% этих же компаний сообщают, что разрыв в ИИ-компетенциях у них всё равно сохраняется. 23% опрошенных заявили, что программы обучения не адаптированы к конкретным должностным обязанностям, 21% опрошенных говорят, что сотрудникам сложно понять, с чего начать. То есть деньги в обучение пошли, программы запустили, лицензии раздали — а сотрудники в массе своей по-прежнему не владеют ИИ на нужном уровне.  

На заметку всем, кто интересуется, как меняется современная разработка ПО.

Недавно Anthropic выпустил отличную статью о том, как меняется современная разработка ПО на примере трансформации подходов внутри собственной компании.

Любой аналитик знает, что самым надёжным способом проверки гипотез являются рандомизированные контролируемые эксперименты (RCT), или, как их называют в народе — A/B-тесты. На практике часто возникают ситуации, когда провести A/B-тест невозможно — в основном это происходит по этическим или техническим причинам. Однако бывают кейсы, когда рандомизация невозможна потому, что treatment-ом является определённое действие пользователя. Например, treatment-ом может быть оформление платной подписки или отмена бронирования на сервисе. Давайте назовём такой вид воздействия добровольным.

В русскоязычном пространстве, и в частности на Хабре, достаточно много статей, посвящённых таким методам Causal Inference, как DiD, PSM и Causal Impact. Тем не менее, к моему удивлению, практически нет статей, посвящённых методам на основе ортогонализации и regression adjustment, хотя, на мой взгляд, именно эти методы являются самыми удобными для оценки эффекта от добровольного treatment-а. Пришло время исправить это недоразумение и разобрать метод Double/Debiased Machine Learning (DML) и Partial Linear Regression для задач Causal Inference!

Привет, Хабр! Я Ольга Попова, ИИ-Евангелист Лаборатории искусственного интеллекта Департамента больших данных Россельхозбанка. Подготовила дайджест новостей про ИИ. Пишите, что вас больше всего зацепило.

Привет, Хабр! На связи Анастасия Шулакова и Георгий Геймбух, аналитики поддержки Авито. Мы помогаем командам развивать внутренние инструменты для специалистов так, чтобы пользователи получали ответы быстрее, а поддержка оставалась управляемой по качеству и стоимости.

Недавно мы переработали один из самых нагруженных блоков админки — страницы пользователя и объявления, с которыми ежедневно работают поддержка, модерация и другие линии. Это был не косметический редизайн, а замена ключевого операционного контура. И главный вопрос, на который нужно было ответить перед решением о масштабировании: не ухудшает ли новый интерфейс AHT (среднее время обработки обращения)  — нашу ключевую метрику эффективности?

По задумке это выглядит как классическая задача для A/B-теста. Но в реальности дизайн сложнее: единица воздействия здесь — специалист, а не обращение, выборка маленькая, дисперсия большая, и обычный рандомный сплит даёт слишком высокий MDE.
В этой статье расскажем, как мы собирали группы генетическим алгоритмом, балансировали ковариаты, проверяли баланс после старта и считали итоговый эффект через CUPED — этот метод доступен из коробки в нашей внутренней A/B-платформе Trisigma, поэтому нам не пришлось писать расчёт с нуля, и мы сосредоточились на дизайне теста и выборе ковариат.

Всем привет, меня зовут Илья и я хочу вам рассказать как я после небольшой правки в тераформ я потерял все мастера в кластере Elasticsearch. ЧатГПТ и гугл уже принесли мне лопату чтобы похоронить эти сервера, но начальство сказало: "Может что нибудь придумаешь?". В итоге 6 часов работ и кластер снова живой и зеленый. Хотите знать больше?

Когда пайплайн отработал без ошибок, тесты зелёные, а в дашборде внезапно нули, проблема может быть не в инфраструктуре, а в отсутствии договорённостей между командами.

В статье разбираем, как data contracts помогают фиксировать структуру, правила и ответственность за данные — и почему это спасает витрины, отчёты и нервы дата-инженеров.

Искусственный интеллект давно перестал быть темой только для исследовательских лабораторий. Он уже пишет код, редактирует изображения, помогает бизнесу, спорит с нами в чатах и постепенно превращается в новый слой интерфейса между человеком и цифровым миром. Но за громкими словами «нейросеть», «сильный ИИ» и «агент» часто теряется главное: что именно мы автоматизируем, где заканчивается маркетинг и почему искусственный интеллект может оказаться не угрозой, а способом не погибнуть от собственных технологий.

Я, Александр, автор телеграм-канала «Shulepov Code», поговорил с Сергеем Марковым — директором по развитию технологий искусственного интеллекта Сбера, автором сайта «markoff.science»  — о том, как устроена профессия ИИ-разработчика: от первых шахматных программ до мультимодальных моделей, почему за генеративными нейросетями будущее и как не потерять человеческое лицо в гонке алгоритмов.  

Здравствуйте, уважаемые читатели Хабра!

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

Привет, Хабр! Пишет команда Business Intelligence GlowByte. Каждый год мы проводим Fine Day Online – конференцию про бизнес-аналитику, где практики из разных компаний делятся честным опытом. 22 апреля собрались спикеры из сети “Галамарт”, банков Уралсиб и ОТП, а также FanRuan, и все пять докладов оказались про одно и то же: данные есть, деньги в инструменты вложены, а бизнес по-прежнему принимает решения на ощущениях.

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

Год назад я начал заниматься задачей, которая в маркетинговой индустрии формулируется так: «у вас на сайт пришло 1000 человек, заявку оставили 30 — что делать с оставшимися 970?». Чисто маркетинговый ответ — улучшать сайт, прогревать ремаркетингом, гнать в подписку. Технически — есть другой класс решений: идентифицировать часть тех 970 анонимов и инициировать контакт по телефону.

В рунете эта область с 2022–2023 годов разрослась до десятков сервисов с разной степенью легальности и разной технической архитектурой. Я работаю с одним из них (платформа INTER), но цель этой статьи — не реклама, а разбор того, как такие системы вообще устроены, где они законны, а где нет, и какие технические компромиссы за этим стоят.

Статья рассчитана на инженеров, продакт-менеджеров, юристов в IT и всех, кому интересно, как технически работает рынок «возврата ушедшего трафика».

Часть 1. Откуда берётся «соответствие»

Базовая задача: пользователь зашёл на сайт example.ru, посмотрел страницу, ушёл. С точки зрения сайта он анонимен — у него есть IP, User-Agent, набор куки, fingerprint браузера, возможно, идентификаторы рекламных систем (Яндекс Crypta, Google Click ID и так далее).

Чтобы сопоставить этот набор сигналов с телефонным номером, нужна где-то стоящая база, в которой такое соответствие уже есть. Источники этих баз — главный вопрос всей индустрии, и от ответа на него зависит легальность сервиса.

Условно источники делятся на три категории:

1. Согласие первой стороны (легально). Пользователь однажды оставил телефон на каком-то сайте-партнёре, при этом согласившись с обработкой ПД и передачей данных третьим лицам — это написано в политике обработки. Сайт-партнёр или DMP-агрегатор, с которым у партнёра есть договор, складывает: «вот fingerprint браузера X — вот телефон Y». Когда тот же fingerprint X появляется на сайте example.ru, происходит matching. Это самый чистый путь с точки зрения 152-ФЗ — пользователь сам дал согласие на обработку и передачу.

Компании массово покупают AI-инструменты, но сотрудники часто бросают их после первой же неудачной попытки. Разбираем, почему большинство AI-пилотов не доходят до реального эффекта, как появляется shadow AI и что на самом деле влияет на внедрение ИИ в корпоративной среде — от AI-грамотности и процессов до поддержки команды и рабочих сценариев использования.

В ресторанных сетях данные о гостях часто распределены между несколькими системами. Бронирования хранятся в одном сервисе, чеки — в ресторанной учётной системе, переписки — в мессенджерах, отзывы — в агрегаторах, данные приложения — в отдельной базе, платежи — у эквайринга.

Такая архитектура усложняет работу с клиентским профилем. У бизнеса нет единой истории взаимодействия с гостем, менеджеры работают с фрагментами данных, а сервис, маркетинг и аналитика опираются на неполную картину. Для ресторанной сети это напрямую влияет на персонализацию, качество обслуживания, LTV и повторные визиты.

В проекте для сети из 10 ресторанов была реализована единая база данных гостей. Задача системы — собрать в одном профиле все взаимодействия клиента с бизнесом: от первого контакта и переписки до бронирований, чеков, отзывов, оплат, технических инцидентов и повторных визитов.

-Gartner прогнозирует, что 80% инициатив в управлении данными провалятся к 2027г.

-MIT подводит статистику - 95% AI-проектов не срабатывают и основная причина - незрелость компаний в работе с данными.

-Chief Data Officer, высший руководитель функции управления данными, живёт в компании в среднем 30 мес.(2.5 года) Логично, что руководитель функции, инициативы которой проваливаются достаточно быстро выгорает.

Поговорим о причинах.

Думаю, причина этой статистики одна - заблуждение в сути работы с данными и AI.

Соблазнительно считать, что данные будут работать вместо вас, AI агент заменит сотрудников. Но они работают только вместе с вами.

Представьте: ваш сервис Y генерирует 10 000 событий в секунду, а сервис X может проглотить только 500. И при этом нельзя потерять ни одного события, а порядок обработки обязан быть строгим. Очередь? Конечно. Но какую? И что делать, когда она переполнится?

В статье — разбираем реальную архитектурную задачу с разбором типовых ошибок, двух подходов к порядку (strict FIFO и per‑key ordering), нюансами DLQ, backpressure, идемпотентностью и скрытыми проблемами типа head‑of‑line blocking.

Когда Impala-запрос начинает выполняться заметно дольше обычного, первое место, куда обычно идут смотреть - query profile, то есть профиль запроса. Там есть план выполнения, счетчики, оценки кардинальности, память, scan-часть, exchange, admission, хвосты по backend-ам и другая полезная информация.

Проблема в том, что текстовый profile не слишком удобный для анализа. Он большой, в нем много повторяющихся секций, часть сигналов видна только в связке с другими счетчиками. При этом почти всегда внутри есть чувствительная информация: SQL-текст, имена таблиц и колонок, пользователи, resource pools, хосты, фрагменты топологии выполнения.

Поэтому на практике появляются два привычных варианта:

Разбирать profile руками.

Скопировать SQL и profile в LLM и попросить объяснить, что не так.

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

Здравствуйте, уважаемые читатели Хабра!

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