Big Data *

Трансформерная архитектура достигла потолка. Не по нашему мнению, по данным HEC Paris, Nature, arXiv и самих создателей frontier-моделей.
Фундаментальные ограничения архитектуры (квадратичная сложность, неспособность к композициональному рассуждению, отсутствие рекурсии) не решаются увеличением параметров. В этой статье мы разбираем, почему трансформер - это локальный максимум, какие архитектурные альтернативы уже показывают результаты, и почему следующий прорыв в AI - смена вычислительной парадигмы.

Привет! Меня зовут Дмитрий Мележиков, я отвечаю за BI в домене Маркетинг и участвую в общих DWH/BI-проектах Авито.

В статье рассказываю, как мы построили систему HealthScore — метрику здоровья данных. От математической модели и пайплайна сбора метаданных до процесса массовой очистки. А ещё вы узнаете, почему HealthScore и сертификация витрин важны для AI Copilot. Без белого списка доверенных витрин ассистент может масштабировать ошибки так же быстро, как и инсайты. 

Почему в промо-акциях всегда указывается не только новая сниженная цена, но и та, которая была до скидки? Ответ на этот вопрос знает даже начинающий маркетолог. Если покупатель оценивает более низкую цену изолированно, он может даже не понять, что цена снижена, тем более насколько. Но ориентируясь на предыдущую цену, покупатель легко посчитает свою выгоду. Кстати, для этого даже не обязательно снижать цену, можно просто написать две разные цены. Как правило, покупатели не запоминают точные цены, особенно на недорогой товар. А знаете ли вы, что за открытие этой закономерности была присуждена Нобелевская премия по экономике? Конечно, не только за это, но давайте разбираться…

Привет, Хабр! Я Владимир, архитектор департамента больших данных в РСХБ. В команде РСХБ.Цифра руковожу проектом по внедрению решения для CDC-репликации данных на базе отечественного программного продукта Датафлот Репликация. Наступила эпоха импортозамещения, и в последние годы большинство компаний столкнулось с необходимостью отказаться от привычных классических инструментов и архитектурных решений. Для нас, Россельхозбанка, 100% которого принадлежат государству, по очевидным причинам проблема импортозамещения особенно актуальна.

Нашей целью было обеспечить бесшовное переключение систем с замещаемых СУБД, миграция их данных, замена cdc-инструментов поставки данных в ХД в рамках задачи импортозамещения иностранного ПО в банке. В этой статье расскажу про наш подход к этому вопросу с практической точки зрения. Про и контра — с точки зрения не маркетинговых фраз, а сугубо практического «вам шашечки или ехать?». Возможно, не все согласятся с приведёнными критериями и аргументами, что повлечёт холивары в комментах, но… тем лучше. Будет больше осознанности при выборе правильного решения.

Разработчики, работающие с «грязными» данными регулярно сталкиваются с задачами, которые сами по себе несложны, но требуют небольших вспомогательных инструментов. Нужно декодировать строку Base64 из лога, проверить хеш файла, быстро попробовать XOR-ключ, разобрать бинарный фрагмент или понять, что скрывается внутри странной строки из сетевого дампа. Обычно для этого приходится комбинировать несколько утилит, писать короткие скрипты или искать подходящую библиотеку. В какой-то момент вокруг таких задач накапливается целый набор вспомогательных инструментов, каждый из которых решает лишь небольшой кусок проблемы.

Знакомьтесь, CyberChef - веб-приложение, разработанное в Government Communications Headquarters. Его нередко называют «кибер-швейцарским ножом» для работы с данными. В одном интерфейсе собрано несколько сотен операций: кодирование и декодирование строк, криптографические алгоритмы, работа с бинарными форматами, сетевые структуры, временные метки, анализ сертификатов и множество других преобразований. При этом инструмент не требует установки и работает прямо в браузере, хотя при необходимости его можно скачать и использовать локально.

В PostgreSQL есть фича, про которую знают далеко не все, хотя она существует с незапамятных времён. Advisory locks — пользовательские блокировки, которыми управляет не БД, а ваше приложение. PostgreSQL только хранит их состояние и разруливает конкуренцию. А вы решаете, что именно заблокировать и когда отпустить.

Зачем это нужно? Вы строите распределённую систему, несколько инстансов приложения работают с одной базой, и вам нужно гарантировать, что определённую операцию выполняет только один инстанс одновременно. Классический ответ — Redis с SETNX или Consul/ZooKeeper. Но если у вас уже есть PostgreSQL — зачем тащить ещё одну зависимость?

Я работаю в компании, которая занимается автозапчастями. Не буду называть бренд, но представьте любой крупный интернет-магазин запчастей — у нас всё примерно так же.

Десять лет всё работало. Поставщики присылали прайсы, менеджеры загружали. В 90% случаев клиенты искали товар по артикулу — просто вбивали номер и получали результат. Оставшиеся 10% запросов — это названия вроде «хомут бмв х5». И поиск как-то справлялся.

Да, в базе была каша: один и тот же товар мог называться «Хомут винт. BMW X5/E81» и «Хомут крепления топливного шланга 12мм для BMW». Но артикулы вывозили, а на остальное закрывали глаза.

А потом мы узнали про Честный знак.

Сегодня расскажу о модели, которую мы построили для оценки реального эффекта промокодов. Главные вопросы: кому, какой, и зачем мы выдаем промокод. Спойлер: ответ нас удивил. И именно этот ответ стал главной причиной, по которой эту модель вообще стоило строить.

Представьте стандартный отчёт по промокампании: «Пользователи, применившие промокод, потратили на 800 рублей больше среднего». Бизнес доволен, маркетинг рапортует об успехе. Но подождите, а сколько из них потратили бы эти деньги и без промокода?

Это не риторический вопрос. Это принципиальная проблема, которая называется selection bias — систематическая ошибка отбора.

Привет! Меня зовут Егор Лукьянов, я старший аналитик данных в Ozon Tech. В своей работе я часто сталкиваюсь с проблемой масштабируемости в pandas. Код, который быстро работает на гигабайте данных, начинает невыносимо тормозить на десяти. Уверен, эта боль знакома многим.

Сейчас есть быстрые альтернативы, например, Polars. Я сам пробовал переводить на него свои проекты. Скорость действительно впечатляет, но как в анекдоте есть нюанс: приходится переписывать чуть ли не весь код и привыкать к новому синтаксису. А это большая работа, на которую не всегда есть время.

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

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

Издательская практика в настоящее время требует оценивать англоязычные книги, а в идеале — отлавливать бестселлеры — задолго до выхода, по первым черновикам. Занятие увлекательное, но порой рискованное. Поэтому в потенциальной переводной книге мы ищем сочетание «широкого контекста» и заключённой внутри него «необходимой новизны». Книга должна быть понятна и интересна широкой аудитории, но не перемалывать в очередной раз широко известные вещи, к тому же разобранные в блогах, а серьёзно облегчать повседневный труд и при этом предлагать ступеньку для роста.

Привет, Хабр. Меня зовут Сергей Петриченко. Я продуктовый менеджер VK Data Platform, VK Tech.

Традиционно крупные компании использовали централизованную модель управления данными с единой командой Data-инженеров. Однако по мере роста объемов данных и повышения требований к скорости обработки возникает соблазн перейти на новую модель — Data Mesh, которая предлагает делегирование управления данными бизнес-доменам. Вместе с тем это не всегда оправданно, а иногда и рискованно, поскольку классическая централизованная модель и Data Mesh имеют свои особенности и ориентированы на разные сценарии применения.

В этой статье я попробую разобрать, чем отличается Data Mesh от централизованной модели управления данными, каковы ее преимущества и риски, и главное – когда такой подход действительно нужен.

Всем привет! Меня зовут Станислав Ким, я ML-разработчик в команде качества поиска Ozon. В этой статье расскажу, как мы перешли от ранжирования товаров к ранжированию предложений, внедрили «матрицу памяти» для переноса статистики и получили +0,9% к GMV на пользователя.

Представьте простую ситуацию. Вы — продавец электроники. Выводите на Ozon новую модель робота-пылесоса. Чтобы ворваться на рынок, вы ставите цену на 20% ниже конкурентов и отгружаете партию на ближайший склад, чтобы доставка была «завтра». Логика подсказывает: алгоритмы увидят выгодное предложение (дёшево + быстро), подкинут товар в топ, и продажи взлетят.

Реальность: проходит день, два... а товар висит на 5-й странице выдачи. Потому что для алгоритма ранжирования ваш пылесос — «чистый лист». У него нет истории продаж, нет кликов, нет отзывов. Рядом в топе — конкуренты: они дороже, доставка дольше, но у них есть история: тысячи заказов за прошлый год. Алгоритм «любит» их за накопленную статистику, а ваше выгодное предложение игнорирует — он просто не знает, чего от него ждать. В индустрии эта проблема называется cold start — и с ней сталкиваются все крупные маркетплейсы.

Мы поняли, что нужно менять саму парадигму. Наш лозунг: ранжировать не абстрактную карточку товара с её прошлым, а конкретное предложение с его условиями здесь и сейчас.

Бум генеративного ИИ требует всё больше вычислительных мощностей — а значит, новых центров обработки данных. В 2026 году в США работает более 5 000 ЦОДов, по миру — свыше 8 000. По прогнозам Министерства энергетики США, в ближайшие четыре года ежегодно будут вводиться около 450 новых объектов, а суммарная мощность их энергопотребления вырастет с 100 до 200 ГВт.

Но ИИ-инфраструктура — это не только серверы и чипы, а ещё и бетон. Дата-центры требуют массивных фундаментов и инженерных корпусов, а производство цемента даёт около 7–8% мировых выбросов CO₂. Чем быстрее растёт ИИ, тем больше строится ЦОДов — и тем выше углеродный след строительства.

При этом крупнейшие технологические компании — Microsoft, Google, Amazon — декларируют углеродную нейтральность и снижение выбросов. Возникает очевидный вопрос: можно ли масштабировать ИИ и одновременно сокращать углеродный след? В статье разберёмся, как индустрия пытается решить это противоречие.

Зачем OpenAI купила базу данных Rockset за $117M и тут же убила её для всех клиентов.
Как устроена архитектура «пять слоёв контекста».
Почему принцип «meaning lives in code» меняет подход к документированию данных.
И что из этого может взять обычная компания уже сейчас без GPT-5 и без $117M.

Если мы говорим про AI, говорим и про галлюцинации. Эти два понятия, к сожалению, стали неразрывны. И главная задача в 2026 не просто внедрить AI, чтобы потом всем рассказывать о своих успехах и как затраты сократились на 900%. Главная задача – сделать так, чтобы AI не врал. А врать он любит. Он буквально патологический врун! Но его можно понять, ведь наш друг боится показаться несведущим. И если он чего-то не знает о чем его спрашивают, он с высокой долей вероятности начинает привирать.

Давайте разберемся, как сделать так, чтобы AI не врал. И кратко рассмотрим аж 9 способов, а точнее 9 видов архитектур RAG.

Привет, Хабр! Меня зовут Александр Воробьев. За моими плечами разработка более 100 электронных устройств, пуско-наладка АСУ ТП и множество проектов, где нужно было "прикрутить" датчик к микроконтроллеру, написать веб-интерфейс и заставить это всё работать вместе. Каждый раз — это горы кода, даташитов и времени. В какой-то момент я задался вопросом: а можно ли автоматизировать этот процесс? Чтобы инженер думал над архитектурой, а не над синтаксисом? В этом посте я поделюсь своим путем создания инструмента, который позволяет собирать сложные IoT-системы за минуты с помощью AI-агента, и покажу это на реальных кейсах.

Дрейф данных (Drift Data) — это ситуация, когда статистические свойства входных данных для модели машинного обучения изменяются со временем. При дрейфе данных взаимосвязи между признаками и самой целевой переменной перестают быть действительными. Это может привести к низкой производительности модели, неточным прогнозам и даже к сбоям.

Привет, Хаброжители!

От выбора подхода к поглощению данных может зависеть успех или провал работы конвейера данных

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

Как менялся сон моих детей: анализ 5 лет накопленных данных

За 5 лет жена скрупулезно записывала сон наших дочерей. Я взял эти данные и проанализировал: как меняется сон с возрастом, сколько спят дети на самом деле, и правда ли нормы ВОЗ работают.

Оказалось, что наши дети спят по-разному, но оба — в пределах нормы. И даже в одинаковом возрасте их паттерны сна удивительно похожи!

В статье: 📈 графики, 📊 статистика и главный вывод для родителей.

#анализданных #родительство #детскийсон #python #датасаенс

Эту историю неизбежно приходится начинать с тревожной статистики. В России ежегодно теряются сотни тысяч человек. Согласно данным МВД, в стране каждый год регистрируют до 180 тысяч заявлений о пропаже людей. Только за первую неделю нового года в добровольческий поисково-спасательный отряд «ЛизаАлерт» поступило больше 300 заявок от родственников и друзей исчезнувших людей. За сухими цифрами — человеческие судьбы, тревожные дни и ночи и всегда надежда на короткую, но предельно емкую фразу, которая для поисковиков и близких пропавших имеет самое важное значение: «Найден. Жив».