Представьте, что лингвист внезапно стал экспертом по живописи. Именно это произошло в 2020 году, когда архитектура для обработки текста — трансформеры — научилась "видеть" изображения. Vision Transformer (ViT) доказал: для понимания картинок не обязательны свёртки! Разберем "на пальцах" как она устроена и как изображения превращаются в предсказания.
(версия статьи актуальна на 26 июня 2025 года)
OpenAI за несколько лет превратила ChatGPT из экспериментального проекта в полноценного цифрового помощника, который умеет не только писать тексты, но и думать, видеть, слышать и даже спорить. Это стало настоящим поворотным моментом в истории ИИ и индустрия вошла в новый цикл развития. Появились тысячи приложений на базе LLM, десятки компаний сменили стратегию, а работа с языковыми моделями стала повседневной реальностью.
Новые версии выходят регулярно, и если вы чувствуете себя потерянными в этом потоке, то вы не одиноки. Мы специально подготовили этот материал, чтобы рассказать обо всех ключевых GPT-моделях и сопутствующих инструментов OpenAI, чем они отличаются и какую из них выбрать для своих задач.
Ранее в блоге beeline cloud мы рассказывали об открытых СУБД для систем ИИ. Продолжим тему и рассмотрим еще несколько находок в этой области — разносторонние инструменты, упрощающие работу с эмбеддингами, семантическим поиском и RAG.
LLM-агенты — отстой. Я провёл последнюю неделю, разрабатывая LLM-агента с возможностью веб-краулинга, используя популярный Python-фреймворк, чтобы собирать информацию о потенциальных лидах из интернета. Результат оказался полным разочарованием.
Агент оказался медленным, нестабильным и с огромным числом багов (звучит знакомо? Передадим привет OpenAI!). Он постоянно делал ненужные вызовы функций, а иногда намертво застревал в бесконечных петлях "рассуждений", которые не имели никакого смысла. В итоге я на это забил и заменил его простым web-scraping скриптом, на написание кода которого у меня ушло 30 минут.
Представим себе картину из идеального мира данных, в котором всё стабильно, изменений нет и на горизонте не предвидятся. Аналитик полностью согласовал с заказчиком требования к витрине, спроектировал решение и передал в разработку. Разработчики внедрили витрину в продуктивный контур, пользователи счастливы, всё работает корректно — сопровождение разработчиков и аналитиков не требуется. Представили?
Но, как мы знаем, «IT» и «изменения» — синонимы, поэтому в идеальном мире, как гром среди ясного неба, появляются новые требования: разработать инструмент для регулярного добавления в витрину данных новых атрибутов, на текущий момент в неизвестном количестве.
Сразу отмечу, что решения и оценки, о которых пойдёт речь, подбирались для работы с большими данными на стеке технологий Apache Hadoop, где для обработки данных использовали фреймворк Apache Spark, СУБД — Apache Hive для анализа данных, оркестратор — Airflow, данные хранятся в колоночном формате Parquet.
Привет Хабр! Меня зовут Кучеров Андрей и я Lead Data Engineer с более чем 7-летним опытом в области распределенной обработки данных. Я работал над оптимизацией высоконагруженных Spark-приложений в X5 Retail Group и билайн, где мы обрабатывали петабайтные объемы данных. Регулярно сталкиваясь с производительностью запросов, я убедился, что понимание работы Catalyst — необходимый навык для каждого Data Engineer, работающего со Spark.
Привет, Хабр! Меня зовут Макс Траулько, я занимаюсь анализом данных и проработкой новый фичей в команде RnD в HFLabs. Прямо сейчас я работаю над нетривиальной задачей — учу наши алгоритмы распознавать в именах и фамилиях русский мат и прочие ругательства.
Как появилась эта задача? В одной крупной компании клиенты могут оставить обращения во фронт-системе. И иногда пишут в полях ФИО, прямо скажем, черт знает что. А у бизнеса риски: если при ответе на обращение автоматически использовать данные из поля «Имя», можно стать героем насмешливых или гневных постов.
Чуть раньше с такой же проблемой к нам пришел другой клиент, из ретейла. У того клиенты вообще большие выдумщики — придумывают составные и сложные имена и фамилии с обсценной лексикой. Даже жаль, что показать эти примеры не можем.
В статье расскажу, как мы решаем эту задачу.
Как определить, влияет ли то или иное событие на ключевые метрики, если полноценный A/B-тест недоступен?
В этой статье мы разберём метод Propensity Score Matching (PSM): узнаем, как компенсировать отсутствие рандомизации, выровнять группы по ключевым признакам и избежать ложных выводов при оценке эффектов.
Хабр, привет! Современные высоконагруженные системы требуют точной настройки и регулярного мониторинга, чтобы обеспечить стабильную производительность в условиях постоянно растущих объёмов данных. Когда речь идёт о крупной аналитической базе данных, развёрнутой в облачной среде, оптимизация её работы становится критически важной задачей. В прошлой статье мы уже рассказывали о типичных ошибках при работе с Arenadata DB (ADB), о том, как их избежать и значительно повысить производительность кластера. Сегодня же поделимся реальным опытом на примере компании «Комус» — лидера в области B2B-ритейла, которая обратилась к Arenadata за проведением комплексного аудита своего кластера ADB.
В этой статье мы детально разобрали, как с помощью анализа и оптимизации удалось выявить точки роста, подготовить кластер к текущим и будущим нагрузкам и предложить план улучшений. Мы рассмотрим технические детали аудита, проблемы, с которыми пришлось столкнуться, и эффективные практики, позволившие повысить производительность аналитической базы данных.
Привет, Хабр! В этой статье я хотел бы поговорить про особенности план-факт анализа, а также о работе с денормализованной таблицей, которая «была, есть и будет использоваться», потому что оказывается удобной для некоторых приемов работы с BI. Под катом вы найдете 7 примеров решения типовых задач план-факт анализа, включая расчет долей, отображение данных с учетом иерархии, разбивку по регионам и так далее. Всех, кому интересны эти практические аспекты, жду под катом :)
Привет, Хабр! На связи Александр Бобряков, техлид команды МТС Аналитика. Это мой одиннадцатый пост про Apache Flink. В предыдущей части мы рассмотрели сериализацию данных во Flink, написали сериализатор, поддерживающий эволюцию схемы для Flink-состояния в операторе на основе Jackson.
В этой части мы научимся писать тесты на эволюцию схемы состояния при использовании своего сериализатора.
Весь разбираемый исходный код можно найти в репозитории AlexanderBobryakov/flink-spring. В master-ветке представлен итоговый проект по всей серии. Этот материал соответствует релизной ветке с названием release/10_test_JacksonStateSerializer.
Генерация с дополненной выборкой (RAG) — это метод, который соединяет внешние источники данных для улучшения вывода больших языковых моделей (LLM). Этот метод идеально подходит для LLM для доступа к частным или специфичным для предметной области данным и решения проблем, связанных с галлюцинациями. Поэтому RAG широко используется для поддержки многих приложений GenAI, таких как чат-боты AI и системы рекомендаций.
Базовый RAG обычно объединяет векторную базу данных и LLM, где векторная база данных хранит и извлекает контекстную информацию для пользовательских запросов, а LLM генерирует ответы на основе извлеченного контекста. Этот подход хорошо работает во многих случаях, однако он испытывает трудности со сложными задачами, такими как многоадресное рассуждение или ответы на вопросы, требующие соединения разрозненных фрагментов информации.
Например, вопрос «Какое имя было дано сыну человека, который победил узурпатора Аллектуса?»
Данное исследование посвящено анализу данных о фильмах, собранных с крупнейшей российской платформы КиноПоиск. Основная цель работы — выявить факторы, влияющие на популярность фильмов, их рейтинги и финансовую успешность. В ходе исследования были проанализированы жанровые предпочтения аудитории, проведено сравнение оценок фильмов на Кинопоиске и IMDb, а также исследована взаимосвязь между бюджетами фильмов и их кассовыми сборами.
Разработка включала этапы сбора, обработки, анализа и визуализации данных. Для обработки данных применялись методы очистки от пропусков и ошибок, фильтрации по ключевым показателям и трансформации структур данных. Были реализованы функции для конвертации валют, извлечения данных о жанрах и персоналиях фильмов (актёрах и режиссёрах), а также вычисления статистических показателей полноты и однородности выборки.
Для эффективной работы системы был использован современный технологический стек. Обработка данных осуществлялась с помощью MongoDB, что обеспечило хранение и управление большими объёмами неструктурированной информации. RabbitMQ организовал асинхронный обмен сообщениями между компонентами системы, а серверная часть приложения разрабатывалась на базе Spring Boot, что ускорило процесс разработки и упростило развертывание приложения. Контейнеризация с использованием Docker обеспечила удобное развертывание и масштабирование системы. Основными языками программирования стали Java 17 и Python: Java использовалась для серверной части и микросервисов, а Python — для анализа данных и построения алгоритмов обработки информации.
Для анализа данных применялись библиотеки Pandas, Seaborn и SciPy, которые обеспечили эффективную обработку данных и визуализацию результатов. В рамках анализа строились графики, отображающие популярность жанров, исследовалась корреляция оценок на Кинопоиске и IMDb, а также визуализировалась связь между бюджетами и кассовыми сборами. Для представления результатов применялись такие инструменты, как matplotlib и seaborn, позволяя визуализировать ключевые закономерности в виде графиков и диаграмм.
Анализ выявил ключевые закономерности: популярность определённых жанров, зависимость коммерческого успеха фильма от его бюджета и значительное влияние известных актёров и режиссёров на успех фильма. Полученные результаты могут быть полезны для киностудий и продюсеров при планировании новых проектов, прогнозировании кассовых сборов и выборе жанров. Результаты также могут применяться для оптимизации маркетинговых стратегий при продвижении фильмов. В будущем планируется углубить исследование, проанализировать долгосрочные тренды в изменении популярности жанров и исследовать влияние пользовательских рецензий на успех фильмов.
Специалист отдела перспективных исследований компании «Криптонит» Игорь Нетай на протяжении нескольких лет изучал фундаментальную проблему быстрой потери точности вычислений. Она связана с повсеместно применяемым форматом экспоненциальной записи чисел и наиболее остро затрагивает сферы AI, HPC и Big Data.
Наш заказчик столкнулся с реальной проблемой, когда из-за использования устаревшего ETL-инструмента StreamSets оказался в ситуации, в которой его система начала давать сбои, а это напрямую влияло на финансовые результаты. Мы решили помочь, организовав миграцию на более современное решение — Luxms Data Boring.
В этой статье мы, Николай Павлов и Наталья Глодя, делимся опытом нашей команды в поисках потерянных данных и рассказываем о том, как важно не дожидаться критических ситуаций, а заранее обновлять свои инструменты. Узнайте, как мы смогли не только решить проблему заказчика, но и обеспечить надежность и эффективность бизнес-процессов с помощью отечественного ПО, подходящего под условия импортозамещения.
Привет, Хабр! Меня зовут Дмитрий Бодин, в МТС Диджитал я руковожу командой интеграции DataOps Platform — платформы по работе с данными. Мы занимаемся внедрением и сопровождением инструментов DataOps внутри экосистемы МТС.
При запуске DataOps Platform мы увидели слабую заинтересованность в ее сервисах, так как все привыкли работать с инструментами от известных вендоров. В этот момент мы поняли, что очень важно продвигать платформу внутри компании и сопровождать пользователей на всех этапах внедрения.
Ниже я на нашем опыте расскажу, как нам удалось заинтересовать коллег своим продуктом, какие возникали проблемы с ростом числа пользователей и как мы построили внутреннюю систему консалтинга, которая помогает на всех этапах работы с нашими инструментами. Надеюсь, мой опыт будет полезен тем, кто занимается созданием и развитием с нуля внутренних продуктов в своих компаниях.
Тема преимуществ открытых табличных форматов при работе с озерами данных всё чаще поднимается в среде дата-инженеров. Предполагается, что их использование способно устранить недостатки популярного Apache Hive. Но так ли это на практике?
Меня зовут Иван Биленко, я инженер данных в команде дата-платформы Циан. В этой статье я хочу немного познакомить вас с процессами и стеком внутри нашей платформы, рассказать, почему мы решили попробовать Iceberg, с какими проблемами столкнулись при тестировании и какие преимущества Iceberg может дать тем, кто еще только задумывается о переходе. Дисклеймер: статья носит обзорный характер.
Прогнозирование можно считать одной из основных задач аналитика. Прогноз продаж, оттока, выручки, затрат – всех основных KPI развития бизнеса – может потребоваться где и когда угодно, начиная от небольших ad hoc кейсов до масштабных задач вроде процесса бюджетирования на предстоящий год.
Меня зовут Нина Фещенко, я работаю в команде аналитики продаж FTTB-FMC (или иначе – ШПД и конвергентных продуктов) Билайн. В данной статье мы рассмотрим прогнозирование продаж FTTB-FMC для целей ежедневной отчетности.
Начнем с того, что мы понимаем под продажами ШПД и конвергенции.
Привет, друзья! Если вы имеете отношение к BI или подготовке отчетности и территориально находитесь в Санкт-Петербурге, этот пост — для вас! Visiology и Conteq организуют 15 октября уникальную по своему формату вечернюю конференцию в культурной столице. На мероприятии можно будет вживую познакомиться с новейшей версией платформы, а также заявить свой кейс на бесплатный пилотный проект. Подробности о том, кому имеет смысл спланировать свой вечер 15 октября в Санкт-Петербурге вместе с нами, — под катом.
Привет, Хабр! В рамках Business Intelligence для расчета KPI и других статистических характеристик могут использоваться различные средства. Универсальным и мощным инструментом является язык DAX, в этой статье я хочу показать его преимущества на примере популярной задачи расчета коэффициента проникновения в Power BI.
Если интересна аналитика с DAX - то добро пожаловать! :)
