Big Data *

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

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

Основная причина — отсутствие единого слоя знаний.

В проекте для ресторанной группы с 10+ заведениями и историей более 15 лет мы сознательно начали не с агентов и не с интерфейсов, а с построения корпоративной RAG-инфраструктуры. Этот слой стал основой всей последующей AI-архитектуры.

Когда мы тестируем LLM‑приложение в режиме black box, мы видим только интерфейс: отправили сообщение — получили ответ. При этом модель под капотом может быть любой: DeepSeek, Qwen, GLM, Mistral, Llama, Claude, GPT, Gemini или локальная fine‑tuned модель. Для обычного пользователя это часто неважно. Для security‑тестирования — важно.

В AI cybersecurity это часть reconnaissance: перед тем как оценивать устойчивость приложения к prompt injection, jailbreak‑попыткам, утечкам системного промпта или ошибкам в RAG‑слое, полезно понимать, какая модельная семья работает внутри. Разные модели по‑разному отвечают на странные Unicode‑строки, mixed‑language запросы, вопросы о собственной идентичности, спорные утверждения и безопасные отказы.

Я попробовал воспроизвести идею статьи LLMmap: Fingerprinting For Large Language Models в упрощённом виде: собрать одинаковые probe‑промпты с нескольких моделей OpenRouter и проверить, можно ли отличать модели по совокупности ответов.

Казалось бы, что может быть проще: даёшь LLM доступ к БД и просишь написать тебе нужный SQL! Но на практике и ИИ, и человек быстро сталкиваются с одинаковыми проблемами – взрывом кардинальности при JOIN’ах, ошибками в гранулярности, сложными подзапросами и отсутствием понятного бизнес-контекста.

Рассказываем, зачем и как мы проектировали семантический слой для детерминированной аналитики и адекватной работы ИИ-агентов с данными.

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

Сергей Тищенко, аналитик студии визуализации данных AkademiaDev, рассказывает, как данные перестали быть сугубо аналитическим инструментом и превратились в полноценный язык, на котором сегодня говорят медиа, бизнес, цифровые сервисы и дизайнеры: от доступного визуального сторителлинга в Flourish и Datawrapper до повседневной работы с данными в Superset, Metabase, Power BI и DataLens. Почему данные давно вышли за пределы таблиц и отчетов, как визуализация помогает превращать сложные массивы информации в понятные истории.

Helmfile может координировать несколько Helm релизов. Argo CD и Flux могут синхронизировать Kubernetes объекты с Git. Terraform и Pulumi могут создать инфраструктуру. Argo Workflows может запускать jobs. В этом стеке такие инструменты используются там, где они уместны, но граница стека шире. Развертывание начинается с удаленного Linux хоста, создает k3s lab на Firecracker microVM, открывает контролируемый tunnel для локального доступа к Kubernetes, создает или проверяет S3 bucket, устанавливает платформенные сервисы, разворачивает fraud workloads, запускает Spark, запускает replay и проверяет путь данных снаружи кластера.

Звонил мне на днях один знакомый CIO. Питерский, ритейл, средний бизнес, ничего особенного. Слушай, говорит, надо нам с ИИ что-то делать: все вокруг внедряют, конкуренты вон что-то запустили, на отраслевом Data Summit уши прожужжали, а у меня даже плана нет. И денег, кстати, особо на это не выделили, но не суть.

Это был, кажется, пятый такой звонок за месяц.

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

Так вот, если коротко - не надо бежать.

Сам я не специалист по нейросетям. Много лет вожусь с базами данных в банках, в ритейле, в системной интеграции, и работа моя: смотреть, как данные живут в настоящих, не презентационных компаниях, и решать, что из задуманного взлетит, а что разобьётся об реальность. Через этот фильтр я и предлагаю взглянуть на нынешний шум вокруг локальных LLM, RAG и «корпоративных помощников».

Собрали для вас подробный материал про DWH — корпоративное хранилище данных:

— что это такое и как работает КХД - простыми словами
— когда DWH действительно нужно и какие задачи решает
— как устроена архитектура DWH (LSA, A16Z, подходы к проектированию)
— как данные проходят путь от источников до дашбордов
— какие сложности чаще всего могут возникнуть при внедрении

Этот разбор DWH — от базовых понятий до архитектуры и стека — даст вам целостное понимание и поможет ответить на основные вопросы о хранилищах данных.

К Вам когда-нибудь приходил бизнес с задачей: «Хотим один дашборд, на котором сразу все будет и все будет понятно?»

Да? Вот и к нам пришел.

Мы — Александр Погудин и Елена Сидорова, BI‑разработчики в Лемана Тех.​

В статье мы расскажем, как с помощью одной EAV‑таблицы собрали дашборд из 30 метрик из 7 разных баз и избежали зоопарка из 150+ мер.
И все это на одном экране.

Привет, Хабр!

На связи команда Alpina Digital — мы развиваем корпоративную библиотеку для бизнеса, через которую компании обучают сотрудников и управляют внутренним knowledge-sharing . Через наши системы проходят сотни тысяч сессий чтения от сотрудников крупных компаний: разработчики, менеджеры, продакты, дизайнеры.

В какой-то момент мы поняли, что сидим на интересных данных. Решили покопаться и посмотреть, что реально читают люди из IT — не что рекомендуют списки «10 must-read книг», а что открывают, когда никто не смотрит. 

Статья будет интересна тем, кто отвечает за обучение и развитие сотрудников в IT-компаниях, HR- и T&D-специалистам, тимлидам и руководителям инженерных команд, а также самим разработчикам, которым любопытно сравнить свои читательские привычки с коллегами по индустрии и понять, какие книги помогают расти в профессии.

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

Сегодня SCD-2-таблицы не только остаются актуальными для медленно меняющихся данных, но и, на мой взгляд, становятся гораздо проще в реализации благодаря новым технологиям и инструментам.

Мне поручили пересобрать витрину в ходе миграции в наше новое хранилище данных. Итак, в этой статье мы будем:

— строить Iceberg-таблицы SCD-2 с помощью Trino, SQL и Python;

— попутно освоим прекрасные функции merge, MD5 и другие полезные инструменты;

— напишем свой собственный оператор для Airflow для автоматизации ETL-процесса.

Каждый раз, когда вы делаете EDA, вы стоите перед выбором: нарисовать быстрый df.plot() - или потратить 10-20 минут на оформление, которое скажет что-то важное про ваши данные. В нашем курсе в МТС Школа Аналитиков Данных мы проверили этот выбор экспериментально: 44 студента сделали 220 EDA-графиков, мы получили 6000 попарных сравнений и проанализировали через CrowdBT. (кстати, уже второй раз!) Результат: победители используют не больше данных, а больше контекста. Фоновые зоны, медианы, адаптивная перекраска, inset-axes - именно эти приёмы отличают скучный график от графика, который меняет решения.

В статье - cookbook из 15 рецептов с кодом "до" и "после" на python. Данные - встроенный seaborn.load_dataset("diamonds"), копируйте, запускайте, вдохновляйтесь.

Когда модель промышленной аналитики начинает показывать отрицательный расход электроэнергии или теряет 15% сырья на ровном месте, проблема часто лежит глубже качества данных и выбора алгоритма. SCADA, MES и ERP могут хранить корректные числа, но вкладывать в них разный смысл: по времени, единицам измерения, границам операции и правилам учета.

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

Append-only — целебная пилюля для ClickHouse, без которой он скорее обуза, нежели буст для бизнеса. Разберем что это, и как этим пользоваться.

Недавно прогремела громкая новость: Google DeepMind будет тестировать ИИ-модели в EVE Online — одной из самых сложных MMO с живой экономикой, корпорациями игроков, дипломатией, войнами и рынками. Лаборатория заключила исследовательское партнерство с Fenris Creations, студией-разработчиком EVE Online, ранее известной как CCP Games. Google также получила миноритарную долю в компании.

Сделка прошла в момент крупной перестройки студии. Fenris Creations вышла из-под контроля Pearl Abyss и стала независимой после соглашения на 120 млн долл. Компания сохранила руководство, команды и текущие проекты, включая EVE Online, EVE Vanguard и EVE Frontier.

DeepMind не будет запускать эксперименты в основном мире EVE Online. Для исследований будет использоваться офлайн-версия игры на локальном сервере. Это позволит тестировать и оценивать модели в изолированной среде.

Зачем ИИ-проектам такие песочницы, чему они будут там обучаться и каким может стать ИИ благодаря такому обучению.

Большие языковые модели требуют огромных объёмов памяти. Например, модель с 8 миллиардами параметров в формате FP16 занимает 24–27 ГБ памяти только для инференса (веса, кэш ключей-значений, буферы). Для полного обучения той же модели нужно уже 84–128 ГБ памяти. Даже с такими методами, как checkpointing активаций или offloading на CPU, требования остаются высокими, особенно для моделей с 70 миллиардами параметров.

Квантизация помогает снизить требования к памяти, уменьшая точность представления весов модели без значительной потери качества. В этой статье разберём основные форматы числовой точности, используемые в квантизации LLM, их особенности и ограничения. Также рассмотрим NF4 — ключевую инновацию из статьи про QLoRA, и разберём, зачем нужны такие методы, как блочная квантизация, двойная квантизация и квантизация по квантилям.

Привет, Хабр! Меня зовут Сергей Чекменев, я тимлид ML-команды развития массового промо и монетизации центра развития ML-решений клиентской персонализации в MAGNIT TECH. В этой статье расскажу про наш MVP-проект PromoPersona – сервис автоматической генерации персонализированных промо-коллажей: что именно мы построили с технической точки зрения, как интегрировали модель FLUX.2 и почему именно ее,  и какие инженерные задачи пришлось решить.

Всех нас очаровывают возможности ИИ описывать происходящее перед видеокамерой, особенно часто встречаются презентации Gemini. Но пока мы нигде не нашли ответа к вопросу – А зачем? Хоть какой-то практичный кейс?

Но вот в Спецлабе придумали собственное применение...

В рамках задачи по обработке XBRL-таксономий возникло требование: если таксономия удалена до обработки событий расчёта кэша, эти события не должны приводить к созданию данных для уже неактуальной сущности.

На первый взгляд кажется, что достаточно найти соответствующие сообщения и удалить их из Kafka topic. Но Kafka хранит данные как commit log, поэтому точечное удаление сообщений по версии таксономии или другому бизнес-признаку оказывается небезопасным.

В статье рассмотрим, почему прямое удаление сообщений не подошло, какие варианты были рассмотрены и как в итоге был применён комбинированный подход: стабильный Kafka key, tombstone-сообщения, compact/delete policy и проверка состояния таксономии на стороне consumer.

Когда инженер слышит «нам нужно хранилище данных», задача редко звучит однозначно. Кто-то задыхается на боевой OLTP-базе под аналитической нагрузкой. Кто-то впервые строит BI и не понимает, с какого края подходить. У кого-то накопились данные из десятка систем-источников, и существующих средств уже не хватает.

У всех «хранилище». А правильный технический ответ зависит от условий задачи.

За годы работы в банках, ритейле и системной интеграции мы пришли к простой картине: для среднего и крупного бизнеса большинство DWH-проектов сводится к четырёхзонной архитектуре поверх двух специализированных движков. Не Inmon, не Kimball-star-schema, не Data Vault 2.0 - и при этом не «modern data stack как у Databricks один-в-один».

В этой статье разберу архитектуру по зонам, потом честно скажу что осталось живо от классических методологий и где они продолжают работать, а где безнадёжно отстали от колоночной эры. И в конце - типичные ошибки, которые наблюдаем в проектах коллег и собственных пилотах.