Миграция данных CMS с использованием графовых БД | 10 июня 2026 года, 03:12

Опубликовал новую статью на Hybrismart — после долгого перерыва. Она о том, как мигрировать данные из старого сайта в новый с использованием graph db (конкретно я юзал neo4j и memgraph). Кейс такой: есть старый сайт и новый сайт, и нужно перенести CMS данные — компоненты, страницы, сетку из старого в новый, и по ходу сделать всякие трансформации — например, в новом стили другие, сетка другая, компоненты частично другие. Вот для этой задачи я и использовал graph db.

Давно не писал на свой блог про SAP Commerce Cloud. Работал на SAP два года, и считал некорректным писать про их продукты, формально имея доступ к внутренним документам. Сейчас работаю на двух проектах параллельно — один про миграцию SAP Commerce Cloud, а другой в существенной спепени про графовые БД. И на стыке этих миров и родилась статья.

https://hybrismart.com/2026/06/10/migrating-sap-commerce-content-with-a-graph-database/

Migrating SAP Commerce Content with a Graph Database

Трехмерные надписи: от идеи до печати | 27 мая 2026 года, 21:12

Сделал скрипт, который генерит надписи, читаемые как три разных слова слева, справа и сверху. В целом это развитие того, что у меня было в предыдущем посте. — там было только лево-право. Один скрипт генерит тройки слов по словарю, которые технически можно сделать. Другой делает 3D-модель, которую можно кинуть на принтер (может сегодня и кину), а третий делает визуализацию этой модели — см видео

Алгоритмическое искусство в большом формате: создание через сплайны и CMYK | 2026-05-24T22:40:31

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

Работает так: на вход дается изображение, оно разбивается на квадраты разных размеров. Каждый квадрат — одно число: насколько он тёмный. Чем темнее — тем больше линий рисуется внутри. Линии не прямые — это сплайны Безье. Они плавно перетекают из одного квадрата в соседний, потому что точки на границах — общие. Получается не сетка, а единая непрерывная нить. Цвет — изображение раскладывается на каналы CMYK (как в типографии). Каждый канал обрабатывается отдельно: своя сетка, свои линии. Потом слои накладываются друг на друга — и из трёх или четырёх чёрно-белых пластин появляется цветная картинка.

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

сетками. Первый проход — крупные клетки, второй — мельче и сдвинуты на 10 пикселей вправо, третий — ещё мельче и сдвинуты по диагонали.

Весь процесс управляется JSON-конфигом — для каждого канала свои параметры, для каждого прохода внутри канала свои. На выходе — SVG, который можно масштабировать до размера стены без потери качества, и PNG, в котором CMYK слои накладываются с полупрозрачностью.

Автоматизация кросс-постинга: боремся с трудностями API Facebook | 2026-05-23T14:28:22

Доделал в лучшем виде кросс-постинг из фейсбука на два моих сайта-блога [на которые почти никто не заходит] — beinginamerica точка com и raufaliev точка com. При публикации нового поста в фейсбуке по расписанию стартует механизм перевода поста на английский, разбор приложенных картинок, генерация описаний к ним, создание заголовка на основе текста поста и описания картинок, создание тегов на их же основе, запись поста в turso db — это облачная база, бесплатная до определенных лимитов, создание эмбеддингов через openai, запись в qdrant cloud — это тоже облачная база, но уже векторная, ну и загрузка изображений в wordpress по API, и публикация поста на английском и на русском по API.

Все бы хорошо, но из всех API самый дурацкий — у фейсбука. Во-первых, для страниц как у меня, переведенных в New Experience, нет возможности использовать почти все из этого API. Точнее, есть, но нужно долго доказывать фейсбуку, что это реально надо, показывая документы на стартап, демонстрируя приложение и т.д. Очевидно, им не хочется иметь дело с чем-то уносящим контент из их системы во вне. Кроме этого, токен, который дает доступ к последним сообщениям, относительно короткоживущий (возможно, несколько недель), и получать его заново нужно через браузер только. То есть, любая автоматика требует регулярного внимания, иначе она ломается.

Если протупил и вовремя не выгрузил последние посты через этот Facebook Graph API, они просто исчезают из списка последних и все, больше по API к ним не обратиться. Единственный способ — запросить выгрузку архива у фейсбука. Эта выгрузка тоже довольно дурацкая — там нужно много трансформаций делать и убирать лишнее. Например, в файле с постами, который я обрабатываю, там почему-то хранятся ссылки, которые я отправлял в комментариях без сопроводительного текста. А комментарии там идут в отдельном файле!

Чтобы назначить теги, пришлось решить отдельный челендж. Вот есть около 10000 постов за все время. Это большой кусок, и по нему теги построить нельзя, потому что он в контекстное окно LLM не помещается. А надо. Поэтому я делал так: скрипт берет случайные посты из 10000 в таком объеме, чтобы их суммарный размер был чуть меньше указанного лимита в токенах, и в конец этого блока добавляется промпт «сгенери мне наиболее частые теги, 30 штук» (промпт привожу упрощенно). В итоге я запустил это 10 раз и получил 10 наборов тегов по 30 штук, сгенерированных для разных срезов базы. Получилось 300 тегов, из которых конечно есть полные дубликаты, а есть синонимы и близкие по смыслу. Это все скармливается LLM, и получаем список тегов и иерархию тегов. Теперь у нас есть ограниченный набор тегов, которые максимально отражают 10000 постов. Так получилось, что за почти 20 лет на фейсбуке у меня расклад такой:

Тег Постов

==================================================

#Russia 3412

#Thoughts 3146

#Tech 3105

#Culture 2765

#Hobbies 2726

#AI 1603

#Science 1367

#Software 1358

#Travel 1298

#Learning 1138

#Society 1050

#Nature 958

#Education 915

#Business 902

#Art 894

#Programming 889

#Humor 840

#History 807

#Gadgets 750

#Moscow 713

#USA 614

#Cinema 567

#Webdev 493

#Music 476

#Sports 473

#Mindset 443

#Auto 400

#Books 386

ну и так далее. Этот список включает как теги из ограниченного списка, так и теги, которые LLM поставила материалу просто потому, что не нашла в ограниченном ничего подходящего.

Теги из ограниченного списка стали категориями на сайте. Остальные теги + эти стали просто тегами wordpress.

Поиск по картинкам. У меня было две идеи как его сделать. Первая — OpenCLIP. Это довольно просто, но требует хостинга модели где-нибудь. На своей машине легко, но каждый раз ее запускать неудобно, плюс я планировал переносить мигратор на дешевый сервер в амазон. В облачных моделях тоже нормально считать, но хоть немного за это надо платить, а это еще одна dependency. Но главное — что и без этого неплохо работает. Я с помощью OpenAI , который и так используется для перевода на английский, генерю описания к картинкам, и дальше по этим описаниям делаю embeddings с помощью large модели. Пока что все тесты на поиск проходят на ура. Особенно, когда на картинке есть текст, и большой вопрос разобрал бы ли его OpenCLIP.

В итоге:

1) вордпресс raufaliev точка com — бесплатный

2) вордпресс beinginamerica точка com — бесплатный

3) turso db где хранятся все посты — бесплатный

4) qdrant cloud где хранятся эмбеддинги — бесплатный

5) openai для перевода и описания картинок — не бесплатный, но недорогой (обработка постов за год потребовала 30 баксов).

Прикладываю два скриншота — как работает поиск по изображениям, и по текстам, а также дашборд мигратора.

Автоматизация документации больших данных: от анализа к действию | 2026-05-06T22:28:27

Интересно, а существует такой агент, который получает на вход таблицу (эксель), по размерам значительно превосходящую контекстное окно, и начинает ее документировать по сути. Вот есть несколько вкладок. Вот есть на вкладке 5 табличка в миллион строк и пять столбцов. Столбцы такие-то. Берем случайные данные из таблички, так, там вроде числа, а там — фамилии. Делаем предположение, что числа там везде — пишем код, который проверяет это предположение и заодно вычисляет мин/макс и набор уникальных значений. Так, значений немного, всего пять. Запишем. Проверяем теперь фамилии. Да, это просто строки, новый сэмплинг показал, что там фамилии правда. Тут формула. Смотрим куда она указывает. И т.д. А вот эта колонка — неясного назначения. Смотрим на данные — это какие-то числа от 0 до 1. Померяем среднее и разброс. Спросим у пользователя — может, даст какие комменты. Дал. Окалось это выданный kpi этого юзера из внешней системы. Запишем. И так далее. Получается документация. Дальше, когда есть документация, можно просить сделать какие-то операции со всем этим, поскольку LLM уже понимает плюс-минус назначение данных, и их связь, и может строить какие-то гипотезы на выявление outliers и их проверять.

Зачем вашему проекту надсмотрщик за качеством данных? | 2026-05-06T16:07:42

Почти в каждом проекте разработки есть выделенная команда автоматизации функционального тестирования, однако на удивление редко встречается аналогичный акцент на Data Quality. Неважно, идут ли данные из внешних интеграций, от пользователей или генерируются самой системой, часто они остаются без должного контроля просто потому, что почему-то никто не считает это важным, а потом борятся с последствиями — они накапливаются как снежный ком. Чем дольше длятся такие проблемы, тем труднее их устранить, что в итоге приводит к ситуации, когда народ просто смиряется с «непоправимым» состоянием базы. Уж насколько лучше выявлять эти проблемы в момент их возникновения, пока технический долг не стал непреодолимым, чем потом решать, как сделать так, чтобы из-за них ничего не падало;

По сути, надо внедрять постоянного «надсмотрщика» над базами данных всех типов, использующихся системой (реляционных, NoSQL, поисковых индексов или графовых БД) — по сути, это слой проверки качества данных поверх процессов. Конечно, должны быть четкие правила — что именно проверять и какими флагами отмечать конкретные аномалии.

Должен быть ответственный за процесс (кожаный мешок, не AI), который будет интегрировать эти отчеты в рабочие процессы разработки и поддержки. Многие проблемы целостности данных невозможно решить просто через интерфейс — они требуют от инженерной команды разработки скриптов для массового исправления и очистки данных.

Тут кстати еще переходит все в область детектирования аномалий (outlier detection). Машинное обучение и LLM для выявления тонких «плохих» паттернов, которые традиционные системы на основе правил могут пропустить.

Что вы об этом думаете? Внедрены ли подобные механизмы в ваши процессы?

Разбор полетов: что скрыто внутри очистителя воздуха | 2026-05-03T15:00:42

Сломался очиститель воздуха, купил такой же б/у с новым картриджем по цене стоимость сменного картриджа+40 долл. Старый полностью разобрал, заодно извлек компоненты, которые можно переиспользовать, и понял, как оно работает. Прям как в школе 🙂

В общем, внутри:

— контроллер на ESP32-WROOM-32D. Но на плате сгорела часть, отвечающая за напряжения, поэтому в помойку.

— газовый (CO) сенсор MQ-7 (к сожалению, впаянный в плату, но можно выпаять). Правда, для корректной работы нужен цикл нагрева. Сначала 5В (60 сек) для очистки сенсора, затем 1.5В (90 сек) для измерения. Но тоже можно использовать где-нибудь.

— Plantower PMS9103M — высокоточный лазерный датчик концентрации взвешенных частиц в воздухе (PM1.0, PM2.5, PM10). Можно подключить к Arduino, есть специифкация.

— микроволновый датчик движения (радар), модель RCWL-0516. Можно подключить к Arduino, очень простой по интерфейсу. Видит на 5-7 метров вокруг себя 360 градусов.

— 200W мотор Snowfan YY225H310B. Подключить тоже довольно просто, только там напряжение 310V DC плюс 15V управляющее оборотами. Но зато больше ничего нет.

— датчик Холла (магнит)

Самое ценное — мотор. На eBay он стоит 100 долл. Правда, надо бы и его проверить сначала, не сгорел ли он.

Преобразование чата в семантический поиск вопрос-ответ | 2026-04-30T04:05:37

За вечер сделал простую утилитку, которая вытаскивает чат Natural Language Processing за полтора года — там 65 тысяч сообщений, и переводит его в пары вопрос-ответ, по которым есть семантический поиск. При клике на результат поиска (слева) открывается диалог в чате. Подсвечиваются те сообщения, которые являются ответами на вопрос. Ну и сверху подсвечивается вопрос а оригинальной формулировке.

Как работает: система предполагает, что люди в основном делают reply to на сообщения, находящиеся относительно близко в прошлом. Если на одно сообщение делается несколько reply-to, то наверняка оно полезное, и зацепило в чате других. Система берет сообщения, начиная с того, на которое многие отвечали, и заканчивая последним в цепочке reply-to — и среди таких берет те, которые имеют минимум 3 reply-to к оригинальному вопросу. То есть, по сути, она вырезает из чата кусок, начинающийся популярным вопросом так, что после нижнего отреза скорее всего уже идет нерелевантное. Такие блоки могут накладываться друг на друга — например, если кто-то спросил, пока другие отвечали на что-то еще.

То есть, если пользователь А спросил какая погода, и ему ответили «хорошая», «плохая», «дождь», и еще было пять сообщений без reply-to, а потом кто-то ответил на «дождь» вопросом «почему дождь», и на этот вопрос ответили еще пятеро, то в систему попадет первый вопрос про погоду — кусок будет заканчиваться 13 сообщениями.

Дальше эти куски суммаризуются в вопрос-ответ.

Получается прикольно.

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

Не та раскладка: когда gremlin стал похуистом | 2026-04-28T20:33:08

Это я набрал слово gremlin, не переключив раскладку. Собрался блин почитать про язык запросов графовых баз данных, по работе надо. Удивляет гугл, удивляет

Сравнение производительности CPU и GPU на примере создания эмбеддингов | 2026-04-11T18:08:07

Когда работаешь с определенными задачами, насколько велика разница между CPU и GPU просто поражаешься. Например, мне вот нужно создавать много (миллионы) эмбеддингов, модель BGE M3. При запуске на моем совсем не слабеньком 24-ядерном процессоре Intel Core Ultra 9 285K создание 500 эмбеддингов занимает 45.85 секунд, а при использовании GPU NVIDIA 5090 точно такая же работа выполняется за 0.36 секунды. Это настолько быстро, что я специально писал этот бенчмарк, чтобы понять, а у меня вообще GPU привлекается или нет. Просто та программа, которая шлет в TEI запросы, делает это в тестовом режиме недостаточно активно (условно пару раз в секунду), и графики GPU просто около нуля показывают загрузку.

— Testing http://localhost:8080/embed — <— CPU version

Requests completed: 500

Total time: 45.85 sec

Throughput: 10.90 req/sec

Average latency (Avg Latency): 4386.11 ms

P95 latency: 5021.88 ms

— Testing http://localhost:8090/embed — <— GPU version (NVIDIA 5090)

Requests completed: 500

Total time: 0.36 sec

Throughput: 1398.69 req/sec

Average latency (Avg Latency): 31.38 ms

P95 latency: 53.18 ms

========================================

RESULT: is 99.22% faster