Мы решили проверить технологию, на которой основан ChatGPT, посмотреть актуальное состояние open-source GPT-like моделей и ответить на вопрос — можно ли обучить GPT-like модель в домашних условиях?

Для эксперимента выбрали LLaMA и GPT-J и не самый мощный ПК с видеокартой Nvidia GTX 1080TI с 11 GB VRAM. Оказалось, что этого достаточно не только, чтобы загрузить модель, но и дообучить ее (fine-tune). Рассказываем — как мы это сделали.

Apache Spark – фреймворк для обработки больших данных, который давно уже стал одним из самых популярных и часто встречаемых во всевозможных проектах, связанных с Big Data. Он удачно сочетает в себе скорость работы и простоту выражения своих мыслей разработчиком.

Разработчик работает с данными на достаточно высоком уровне и, кажется, что нет ничего сложного в том, чтобы, например, соединить два набора данных, написав всего одну строку кода. Но только задумайтесь: что происходит в кластере при соединении двух наборов данных, которые могут и не находится целиком на каком-либо из узлов кластера? Обычно Spark со всем справляется быстро, но иногда, а особенно, если данных действительно много, необходимо все-таки понимать – что происходит уровнем ниже и использовать это знание, чтобы помочь Spark работать в полную силу.

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

В конце прошлого года Джеффри Хинтон, пионер Deep Learning, на конференции NeurIPS 2022 предложил новый алгоритм обучения нейронных сетей — Forward‑Forward — как альтернативу методу обратного распространения ошибки. FF более гибок и использует меньше памяти, чем backpropagation в архитектурах с множеством скрытых слоев, а его основная отличительная черта в том, что он основывается на современном понимании устройства человеческого мозга.

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

Не так давно на одном из проектов нашей компании было принято решение наконец отказаться от использования Subversion для хранения и версионирования кода в пользу Git.

Основными целями перехода были следующие:

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

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

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

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

До того как встретиться с Big Data и Spark, в частности, мне довелось много и часто оптимизировать SQL запросы, сначала для MSSQL, потом для Oracle, и вот теперь я столкнулся со SparkSQL.

И если для СУБД уже существует множество хороших книг, описывающих методологию и «ручки», которые можно покрутить для получения оптимального плана запроса, то для Spark такого рода книг я не встречал. На глаза попадались больше статьи и наборы практик, причем больше относящиеся к работе через RDD/Dataset API, а не чистому SQL. Для меня одной из эталонных книг на тему оптимизации SQL является книга Дж. Льюис «Oracle. Основы стоимостной оптимизации». Что-то подобное по глубине проработки я и искал. Почему предметом исследования стал именно SparkSQL, а не API, лежащий в основе? Тут интерес был вызван особенностями проекта, над которым я работаю.

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

В статье показано применение таких методов оценки эффекта от внедрения проекта, как AБ-тестирование (классический подход, стратификация, CUPED), альтернативное прогнозирование, синтетический контроль и мэтчинг.

Статья  будет полезна начинающему разработчику или тому, кто хочет расширить свой кругозор практическим знакомством с графовыми базами данных. Часто в аналогичных статьях не хватает либо пошаговой инструкции по установке, либо более детального разъяснения –  как общаться с данными в базе.

Информации по теории графов достаточно много, поэтому в материале будут сугубо прикладные знания, которые существенно облегчат закрепление материала практикой. В данном примере рассматривается работа с локальным экземпляром БД Neo4j. Считаю, что СУБД именно этого вендора позволяет осваивать тему графовых баз данных с достаточно низким порогом входа – нам понадобится только понимание SQL. Иными словами, статья представляет собой краткую сводку/инструкцию о том, какие шаги нужно пройти и что освоить, чтобы начать "играться" с Neo4j на вашем личном ПК или сервере в инфраструктуре вашей компании. Поскольку в этот тип БД заходят специалисты, ранее работавшие с реляционными БД, для облегчения понимания принципов в статье сделан упор на сопоставление языка общения с графовыми базами данных и классическим SQL. Чтобы сделать пример прикладным, в материале приводится  решение типовой бизнес-задачи для графовых БД на простом примере из финансовой предметной области.

Доброго времени суток!

При работе с данными часто приходится сталкиваться с ситуацией, когда имеется некоторая функциональная зависимость y_i = f(x_i), которая получена в результате эксперимента или сбора статистики. То есть исходные данные представлены набором точек (x₁, y₁), (x₂, y₂) … (x_n, y_n), где n – количество экспериментальных значений. Если аналитическое выражение функции f(x) неизвестно или весьма сложно, то возникает чисто практическая задача: найти такую функцию Y = F(x), значения которой при x=x_i будут близки к экспериментальным данным. Приближение функции f(x_i) к более простой F(x) называется аппроксимацией. Аппроксимация позволяет исследовать числовые характеристики и качественные свойства объекта, сводя задачу к изучению более простых или более удобных объектов. Как правило, выбор модели аппроксимации определяется по минимальному значению погрешности на всем интервале исходных данных. Для расчетов необходимо использовать несколько видов аппроксимаций, чтобы определить более точное описание зависимости экспериментальных данных y = f(x_i).

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

Первая статья посвящена мониторингу потоков данных с помощью инструмента GUI NiFi. В последующих материалах мы рассмотрим задачи отчетности, опишем примеры сбора метрик и визуализации при помощи таких популярных систем, как Prometheus и Grafana.

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

Большинство средств визуализации предлагает широкий выбор вариантов отображения данных, от обычных линейных графиков и столбчатых диаграмм до временных шкал, карт, зависимостей, гистограмм и настраиваемых представлений. Для решения задачи визуализации принципиальное значение имеет тип источника данных. И хотя современные средства визуализации проделали в этом вопросе большой путь, и предлагают на сегодняшний день весьма большой выбор, задача визуализации не решена в полной мере. Если для баз данных и целого ряда web сервисов задача визуализации не представляет принципиальной проблемы, то понять, что происходит с информационными потоками внутри некоторых программных продуктов из мира больших данных, не так просто.

Инструмент, на котором хотелось бы остановиться более подробно – Kafka.

Привет, меня зовут Александр. Сейчас я руковожу одной из групп дата-инженеров центра компетенций Big Data Solutions в Neoflex и дополнительно выступаю деливери-менеджером проекта, связанного с дата-инжинирингом. А ещё осенью 2020-го я был уставшим и сердитым дата-инженером, которого добровольно-принудительно перевели на нежеланную управленческую должность. 

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

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

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

Kafka нельзя назвать новым продуктом на рынке ПО. Прошло примерно 10 лет с того времени, как компания разработчик LinkedIn выпустила его в свет. И хотя к тому времени на рынке уже были продукты со схожей функциональностью, но открытый код и широкая поддержка экспертного сообщества прежде всего в лице Apache Incubator позволила ему быстро встать на ноги, а впоследствии составить серьезную конкуренцию альтернативным решениям.

Традиционно Kafka рассматривался как набор сервисов для приема и передачи данных, позволяющий накапливать, хранить и отдавать данные с крайне низкой задержкой и высокой пропускной способностью. Этакий надежный и быстрый (да и в общем-то наиболее популярный на данный момент) брокер сообщений по этой причине весьма востребован во множестве ETL процессов. Преимущества и возможности Kafka многократно обсуждались, в том числе и на Хабре. К тому же, статей на данную тематику весьма много на просторах интернета. Не будем повторять здесь достоинства Kafk-и, достаточно посмотреть на список организаций, выбравших этот продукт  базовым инструментом для технических решений. Обратимся к официальному сайту, согласно которому на данный момент Kafka используется тысячами компаний, в том числе более 60% компаний из списка Fortune 100. Среди них Box, Goldman Sachs, Target, Cisco, Intuit и другие [1].

На сегодняшний день Apache Kafkaне без оснований часто признается лучшим продуктом на рынке систем по передаче данных. Но Kafka не только интересен в качестве брокера сообщений. Огромный интерес он представляет и в силу того, что на его основе возникли и развиваются многие специфические программные продукты, которые позволяют Kafka существенным образом расширить возможности. А это свою очередь позволяет ему уверено продвигаться в новые области ИT рынка.

В статье будет рассмотрен процесс экспорта данных в Hadoop из различных РСУБД посредством фреймворка Spark. Для взаимодействия с фреймворком Spark будет использован язык программирования Python с применением api pySpark.

Привет! Сегодня мы поговорим и попробуем на практике реализацию паттерна Change Data Capture (далее – CDC) в Apache Flink. 

Статья разделена на несколько частей: в первой мы рассмотрим теоретические основы Change Data Capture, варианты реализации и сферы применения. Во второй – обратимся к особенностям CDC-коннекторов экосистемы Apache Flink, а также выделим самые интересные фичи (а заодно и немного расскажем об Apache Flink для тех, кто раньше с ним не сталкивался). В третьей части – перейдем к практике, закатаем рукава и реализуем несложный сценарий захвата изменений из WAL PostgreSQL, приправленный объединениями, агрегацией, стеком ELK и целым кластером Flink, правда в миниатюре.

{source: "app1", error_code: ""}

{source: "app1", error_code: "error", description: "Network error"}