Обзорное видео с доклада об особенностях обучения LLM для тех, кто в теме ML/DL, но хочет расширить кругозор в области работы с большими языковыми моделями. На основе личного опыта и обзора множества научных статей и инструментов. Ссылка на презентацию прилагается.

Хранилище данных — это информационная система, в которой хранятся исторические и коммутативные данные из одного или нескольких источников. Он предназначен для анализа, составления отчетов и интеграции данных транзакций из разных источников.

Рассмотрим сильные и слабые стороны самых популярных методологий.

В сентябре 2023 года прошёл седьмой хакатон Demhack. Тогда особенно тревожной была ситуация с VPN, которые массово начали блокироваться в России через ТСПУ. И естественно эта тема стала центральной. Вторым значительным направлением разработки внезапно оказались инструменты для выявления пропаганды и манипуляций в СМИ и социальных сетях — и в результате хакатона мы смогли получить несколько отличных проектов.

Расскажем сегодня о том, как развиваются лучшие проекты Demhack 7 (и сделаем небольшой анонс нового хакатона!). Итак, чем же помогают эти инструменты, в чём их ценность именно сейчас и что они планируют развиваться дальше?

Видеть манипуляции насквозь

Одним из победителей прошлого хакатона стал проект Textgericht — решение для проверки текстов на признаки манипуляций, логических ошибок и хейт‑спич. После хакатона проект продолжил работу и взял себе название «Насквозь».

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

Машинное обучение — особенно генеративные нейронные сети, такие как ChatGPT, — меняет мир нечеловеческими темпами. Разработчиков на некоторых дистанционных собеседованиях просят направить веб-камеру на рабочее место и клавиатуру, чтобы понимать, самостоятельно ли соискатель выполняет задания. Amazon ограничивает авторов самиздата загрузкой на сайт трех книг в день — фанфики и другая проза создаются неестественно быстро для «кожаных мешков». Поумневшие чат-боты приводят к массовым увольнениям сотрудников поддержки, а дизайнеры опасаются уступить конкуренцию Midjourney и Playground v2.

Генеративный AI словно говорит человечеству: «Сосредоточьтесь на важном, а я займусь искусствами, этими избыточными павлиньими хвостами хомосапиенсов, и рутиной». Люди ставят задачи, а огромная AI-фабрика по созданию цифрового контента их выполняет. Мечта многих, получается, осуществилась? Но преступники тоже используют AI или находят способы обмануть умные системы. Об угрозах ML и AI, в том числе для информационной безопасности, мы будем говорить в традиционном треке на киберфестивале Positive Hack Days 2. У вас есть время подать заявку до 15 марта, чтобы поделиться своим исследованием с 23 по 26 мая на стадионе «Лужники». А сейчас расскажем о некоторых любопытных докладах прошлых лет на ML-треке PHDays.

Привет, Хабр! Недавно мы делали доклад на конференции HighLoad 2023 — «Мифы и реалии Мультимастера в архитектуре СУБД PostgreSQL». Мы — это Павел Конотопов (@kakoka) и Михаил Жилин (@mizhka), сотрудники компании Postgres Professional. Павел занимается архитектурой построения отказоустойчивых кластеров, а Михаил — анализом производительности СУБД. У каждого за плечами более десяти лет опыта в своей области.

Порассуждаем о том, как развивалась технология «Мультимастер» в экосистеме PostgreSQL, остановимся на том, что она из себя представляет, на каких внутренних механизмах PostgreSQL основана и как её можно использовать.

Мы также поговорим о том, существует ли «Честный Мультимастер» (само понятие «Честный Мультимастер» достаточно специфично и в основном употребляется в кругу разработчиков), какие реализации у него есть и как его следует применять.

Сегодня я расскажу про hippotable — удобный инструмент для анализа данных. Мне часто нужно поковыряться в датасете среднего размера (1–100 Мб), чтобы ответить на довольно простые вопросы. Ни один из существующих инструментов (bash, google sheets, jupyter + pandas) не показался мне особо подходящим для такой задачи, и я... решил сделать свой! Хотел поделиться результатом, показать пару интересных JS-инструментов для обработки и отображения данных, и рассказать, как дальше планирую развивать продукт. Запрыгивайте, будет интересно.

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

Меня зовут Николай Усов, я работаю в отделе тестирования «Цифровой индустриальной платформы». В нашей команде в качестве системы управления тестированием программных продуктов используется Test IT. Система в целом нам нравится, претензий к функционалу почти совсем нет. Однако инструментарий Test IT не всегда позволяет настроить работу тестировщиков так, как удобно. Например, тот, кто с ней работал, знает, что при большом количестве тестов может быть затруднительным поддержание соответствия между автоматизированными и ручными тест-кейсами, если их слишком много. Плюс могут потребоваться иные методы расчета успешности автотестов или более простой интерфейс для удаленного просмотра статистики по прогонам. В этой статье я расскажу, как с помощью telegram-бота, работающего в связке с Test IT, мы сделали жизнь тестировщиков немного приятнее.

Пару дней назад я агитировал всеми уважаемого эксперта в хранилищах данных за новый стандарт суррогатных ключей UUIDv7 для высоконагруженных систем. И я получил от него ответ, что суррогатные ключи не нужны, а нужны лишь бизнес-ключи (естественные ключи). Этот абсурдный ответ заставил меня написать ответное письмо, а затем и эту статью.

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

Трансформеры широко используются в операциях, связанных с обработкой естественного языка (Natural Language Processing. NLP), а в последнее время также часто применяются во многих задачах компьютерного зрения, поскольку они моделируют глобальные и действующие на дальнем расстоянии связи, а также семантическую информацию изображений лучше, чем CNN, поскольку последняя является более локализованной.

Идея управления серверной инфраструктурой через код (Infrastructure as Code, IoC) не нова. Управление настройками через скрипты или файлы конфигурации позволяет стандартизировать настройку системы, масштабировать решение, снизить ошибки и исключить “человеческий фактор”. Shell-скрипты или их прототипы существовали с момента создания компьютеров, а с появлением виртуальных машин стало возможно заскриптовать настройку сервера с нуля. Однако сегодня я хочу сконцентрироваться на кодировании именно облачной инфраструктуры. Это интересно, потому что облака вывели фреймворки по управлению инфраструктурой на принципиально новый уровень.

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

Сегодня лидеры индустрии предоставляют 200+ сервисов которые работают на разных уровнях абстракции (IaaS, PaaS, SaaS), но все так же позволяют управлять всем через единый API. В данной статье я рассмотрю историю развития фреймворков для управления облачной инфраструктурой, выделив ключевые этапы и события, которые, по моему мнению, повлияли на их эволюцию.

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

В сборнике VLDB'17 вышла такая статья. В ней представлена NAM-DB, масштабируемая распределённая система баз данных, использующая удалённый прямой доступ к памяти (RDMA) — в основном, однонаправленный вариант RDMA — и инновационную технологию диспетчера временных меток (timestamp oracle) для поддержки транзакций с изоляцией мгновенного снимка (SI). NAM в данном случае означает архитектуру с прикреплением памяти к сети (network-attached-memory), где благодаря активному использованию RDMA вычислительные узлы получают возможность напрямую общаться с пулом узлов памяти.

Изображение сгенерировано ИИ с помощью сервиса rudalle.ru

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

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

«Лама... Альпака...Чатгпт...» — раздавалась в уютненьком чатике по Ирине.

Хабр был не лучше — статьи по работе с GPT множились как грибы, а в комментах раздавались возгласы в духе «Дайте мне голосового помощника, с которым можно болтать!»

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

Тем не менее, и меня заинтересовало, насколько весело будет именно болтать с GPT, но самому в коде и платном API‑доступе разбираться не хотелось. Но сегодня утром меня снабдили и примером, и ключиком...

‑-

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

— Полностью оффлайн SpeechToText и TextToSpeech
— Поддержка плагинов
— Готовые команды «таймер», «погода» и ряд прочих. Поддержка HomeAssistant.
— Поддержка работы в клиент‑серверном режиме — сервер + куча микрофонов + Телеграм‑клиент, например.

Расскажу, что улучшилось за прошедший год с момента прошлой статьи.

TL;DR> Добавлен плагин для общения с GPT-3 нейросетью. Сделан пакет упрощенной установки под Windows — «скачай и запусти». Сделано два веб‑клиента — один распознает слова прям в браузере (тяжелый), другой отправляет весь звуковой поток на сервер (легкий) — так что можно запускать клиенты, например, на смартфоне. Добавлен TTS Silero v3 — имхо, лучшее озвучивание доступное в открытом доступе. Сделан докер‑образ для быстрого запуска Ирины без установки зависимостей. Добавлено нечеткое распознавание фраз. Обновлена VOSK‑модель распознавания голоса на специально натренированную для Ирины.

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

В вашей ленте новый текст по мотивам доклада на Ruby Russia 2022. Сегодня Георгий Быков, Ruby и Elixir-разработчик из igooods, расскажет, с какими проблемами столкнулась его команда при создании пушей, и как им удалось их решить.

Всем привет! Меня зовут Александр Шерман, я тимлид в команде CRM в Самокате. Мы в первую очередь известны по своей модели доставки заказов от 15 минут. Чтобы укладываться в такой норматив, у нас достаточно жёсткие SLA (2,5 минуты на сборку заказа), что, в свою очередь, диктует строгие требования к надёжности и быстродействию сервисов.

Часть проектов у нас написана на Ruby. Если раньше в качестве web-сервера для них мы использовали Puma (который уже стал de-facto стандартом) и горя не знали, то в определённый момент нам его производительности стало не хватать. В статье, сделанной по мотивам моего доклада на конференции Ruby Russia 2022 расскажу, как и зачем мы переехали на другой веб-сервер.

Всем привет! Меня зовут Роман Горбачёв — я основатель российской дизайн-студии, которая успела поработать в странах LATAM задолго до всех событий.

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

В мире кровавого энтерпрайза есть некоторое количество проектов-мамонтов. Они большие, у них базы данных на SQL Server, в этих базах тысячи и десятки тысяч объектов, миллионы строк кода T-SQL, огромная вариативность данных, всё хрупкое, неидемпотентное, недетерминированное и фигово документированное. Короче, как писал Roy Osherove в своей The art of unit-testing:

Finally, as a friend once said, a good bottle of vodka never hurts when dealing with legacy code.

В вольном переводе "Да там без поллитры не разберёшься!"

И вот у этих проектов есть беда — большие контуры тестирования и разработки, часто так или иначе модифицированные и уменьшенные копии основного продуктового контура. Да-да-да, тут сразу поналетят умные да в белой одежде и начнут объяснять, что надо писать тестовые наборы данных (а кто спорит?), что тестовый контур должен быть небольшим (а кто спорит?), что код должен быть переносимым между СУБД (спасибо, Кэп!), что всё было бы лучше, если бы проект переписали N лет назад (ха-ха) и прочие "станьте ёжиками" и "пусть едят пирожные". Нет, дорогие мои. Просто представьте, что у вас есть БД SQL Server с 25К объектов (таблиц и ХП) и миллионами строк запросов, и часть объектов создана с SET ANSI NULLS ON, а часть с SET ANSI NULLS OFF. И точно известно, что в части запросов эта разница используется. И БД на десятки ТиБ. И однодневный простой системы стоит больше, чем квартиры всех разработчиков, которые за последние 20 лет трогали этот код (из которых, кстати, сейчас работает только 7 последних самураев). Одно это может не давать перейти с SQL Server 2008 R2 на что-то более свежее пару лет.