В статье пойдёт речь о том, как можно автоматически разделить датасет изображений на кластеры, которые поделены по качественному контекстному признаку, благодаря эмбедингам из нашумевшей нейронной сети CLIP от компании Илона Маска. Расскажу на примере контента из нашего приложения iFunny.
На рисунке ниже изображена трехмерная реконструкция сердца, полученная в результате работы современного томографа:
Для масштаба указана толщина луковицы аорты — 3.2 см, подумать только! Однако, когда у людей возникают проблемы с сердцем из-за сосудов, то речь, как правило, идет вовсе не о таких больших. На изображении видно, что сердце окружено более мелкими сосудами, и некоторые из них ответвляются прямо из крупных артерий. Это так называемые коронарные артерии, которые питают кровью непосредственно сердце. Если в них происходит сужение просвета (стеноз), например, из-за образования кальция, то уменьшается поток крови. Когда стеноз ярко выражен, то случается некроз ткани, другими словами инфаркт. Далее я расскажу о нашем подходе к вычислению границ сосудов, который в результате позволяет автоматически находить сужения и давать им оценку.
Читать полностью »
В этой статье мы хотим рассказать, как мы создали решение для классификации названий продуктов из чеков в приложении для учёта расходов по чекам и помощника по покупкам. Мы хотели дать пользователям возможность просматривать статистику по покупкам, собранную автоматически на основе отсканированных чеков, а именно распределить все купленные пользователем товары по категориям. Потому что заставлять пользователя самостоятельно группировать товары — это уже прошлый век. Есть несколько подходов для решения такой задачи: можно попробовать применить алгоритмы кластеризации с разными способами векторного представления слов или классические алгоритмы классификации. Ничего нового мы не изобрели и в этой статье лишь хотим поделиться небольшим гайдом о возможном решении задачи, примерами того, как делать не надо, анализом того, почему не сработали другие методы и с какими проблемами можно столкнуться в процессе.
Читать полностью »
Я занимаюсь АТСками. И как-то так сложилась, что с самого первого заказа от меня хотели отказоустойчивости. Одним из ключевых компонентов современной АТС (как и любой информационной системы, наверное) является БД, где хранятся как данные о текущем состоянии системы, так и всякие конфигурационные параметры. Естественно, падение БД приводит к поломке всей системы. Начиналось все с MASTER-MASTER репликации в MySQL (исключительно для оперативности переключения), потом были эксперименты с MySQL over DRBD. Все это жило в pacemaker/corosync инфраструктуре. Там ездили IP-адреса, шлюзы и прочая лабудень. Со временем оно даже стало работать как-то более-менее устойчиво. Но тут мне попалась пара серверов, на которых DRBD сделать было нельзя, в MASTER-MASTER я разочаровался довольно давно (постоянно она у меня ломается, такая репликация), а без отказоустойчивой БД терялся весь смысл решения. На глаза мне попалось название InnoDB cluster и я решил: "была-не-была". Что из этого получилось — смотрите под катом.
Привет всем! Приглашаем изучить седьмую тему нашего открытого курса машинного обучения!
Данное занятие мы посвятим методам обучения без учителя (unsupervised learning), в частности методу главных компонент (PCA — principal component analysis) и кластеризации. Вы узнаете, зачем снижать размерность в данных, как это делать и какие есть способы группирования схожих наблюдений в данных.Читать полностью »
«Дело было вечером, делать было нечего» — именно так родилась идея сделать вью с возможностью зума, распределяющую юзеров по рангам в зависимости от кол-ва их очков. Так как до этого я не имел опыта в создании собственных вьюшек такого уровня, задача показалась мне интересной и достаточно простой для начинающего… но, *ох*, как же я ошибался.
В статье я расскажу о том, с какими проблемами мне пришлось столкнутся как со стороны Android SDK, так и со стороны задачи (алгоритма кластеризации). Основная задача статьи – не научить делать так называемыми “custom view”, а показать проблемы, которые могут возникнуть при их создании. Тема будет интересна тем из вас, кто имеет мало (или не имеет вовсе) опыта в создании чего-то подобного, а также тем, кто хочет словить лулзов с автора в сто первый раз уверовать в «гибкость» Android SDK.
Некоторе время назад перед нами стала задача спроектировать и развернуть систему для потокового видео. Суть была в массовом запуске/остановке инстанций, на которых происходит обратная сборка потокового видео и стриминг на множество media cdn провайдеров (youtube, livestream, ustream итд ) а также на собственные rtmp и ts точки назначения. Каждая инстанция требовала настройки перед запуском т.к. содержала специфическую для каждого клиента информацию. Также было понятно, что система должна работать в большом количестве регионов (как минимум во всех точках, где присутствует Амазон, а как максимум — в любом месте где можно арендовать сервер). Также основное требование — запуск инстанции в течении 1-2 секунд максимум, чтобы это было прозрачно для пользователя.
Все кто использовал Elasticsearch каластер для своих нужд (особенно для логирования и как основную базу данных) на больших нагрузках сталкивался с проблемами консистентности и масштабируемости. Когда требуется распараллелить нагрузку на Elasticsearch обычно применялись статические решения то типу NGINX+Elasticsearch. Это позволяет распараллелить нагрузку, но выглядит не слишком гибко. Особенно если учесть что ноды могут сами выпадать из кластера и простой хелсчек покажет что все отлично, а на самом деле нода перегружена, исключена из кластера. В любом случае хотелось бы иметь данные о состоянии кластера из первых рук, а не довольствоваться простыми проверками.
Итак, приступим к построению балансировки .
В данном случае мы будем использовать CAT node API, которое является частъю мощьнейшего CAT API, который является инструментом поиска заголовков по Elasticsearch клстреру.
Мы будем использовать только Gobetween и встроенные механизмы Elasticsearch для балансировки записи /чтения СRUD (DATA) нод при произвольном количестве/статусе нод в кластере.
Последние полгода я занимаюсь разработкой достаточно большого web-приложения, под капотом которого ревет и дымится NodeJS. Когда дело дошло до деплоя на продакшн я задумался: «почему бы мне не использовать несколько тредов с инстансом приложения?».
Реализовав кластер, я увидел, что производительность от его использования возросла в 1,5 раза, что очень даже не плохо, учитывая малый объем потраченных усилий. Но я решил не останавливаться на этом, и сделать удобный CLI для работы с кластером, чтобы отвязать код, который отвечает за запуск кластера от конкретного приложения. Кроме того, очень хотелось демонизировать кластер, чтобы он висел себе молча в процессах, поднимал упавшие воркеры, писал в логи, и никого больше не отвлекал.
Так появился node-clusterize-cli.
Читать полностью »
В предыдущей статье я рассказывал, как можно реализовать алгоритм k-means на c# с обобщенной метрикой. В комментах можно почитать обсуждение того, насколько целесообразно использовать разные метрики, о математической природе использования разных метрик и тому прочее. Мне тогда хотелось привести красивый пример, но не было под рукой подходящих данных. И вот сегодня я столкнулся с задачей, которая хорошо иллюстрирует преимущества использования расстояния Махаланобиса в k-means кластеризации. Подробности под катом.
