Автоматизация кросс-постинга: боремся с трудностями 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-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

Диплом с отличием: путь программиста Рауфа Велиевича | 2026-03-21T13:54:58

Мама прислала. Это мне с окончанием школы выдали. Хорошее школьное образование было по крайней мере в то время. Часть занятий по точным наукам шла в институте

Словарь Набокова: Мультиязычное путешествие по текстам писателя | 2026-03-15T18:30:39

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

Вы бы купили такую книжку?

Для того, чтобы корректно сделать их определения, я также написал aligner — программу, которая сопоставляет предложения и абзацы на английском с их переводами (набоковским) на русский. И когда создается определение слова, используется не только знание LLM, но и перевод на русский автора. Отдельно стоит рассказать, как работает алгоритм (я его сам придумал, потому что все, что нашел в сети, не работало как мне надо). Он находит сначала длинные предложения, и находит для самых длинных предложений их пару через косинусное сходство embedding-векторов, созданных через модель multilingual e5. Эти предложения становятся якорями. Затем, предполагая, что для длинных предложений ошибка почти исключена, находится самое длинное предложение уже между якорями, и все повторяется заново рекурсивно. Там много ситуаций, когда у предложения на русском нет аналога на английском и наоборот, когда предложение разбито на два, или наоборот два слиты в одно. Алгоритм как может это обрабатывает. Результат — очень неплохое качество выравнивания. До такой степени, что ошибки выравнивания уже не получается находить (но наверняка они есть). Так или иначе, оно нужно только для контекста для перевода слов, даже если там и есть редкие ошибки, то не страшно.

Вы бы купили такую книжку?

С турбо паскаля до CAD для мебели: история Bazis Soft | 2026-03-06T17:43:22

Моя первая работа, программистом, с офисом в Коломне и за деньги. 1993 год, а может еще годом раньше. 10-11 классы школы. И эта компания до сих пор существует, и ребята, с которыми я работал, до сих пор там! Наталья Бакулина, Павел Бунаков, Николай Каскевич. Прикиньте. Причем они вообще начали в 1986 году, то есть 40 лет назад уже! Я с трудом вспомню еще коммерческие компании такого возраста в России. Когда я пришел к ним работать, был MS DOS, писали на Turbo Pascal, но они начинали за много лет до меня еще на ЭВМ СМ-1420, правда, тогда компания была не совсем коммерческой. На момент моего прихода система была конкурентом AutoCAD на рынке, локально еще конкурировали с «Компас». Я делал установщик с дискет 5.25″ и 3.5″ — это чтобы почувствовать дух эпохи. Дальше они перешли на Delphi и Windows. Дальше они сузили тему, и из CAD для машиностроения перешли к CAD для мебели, где до сих пор у них очень неплохие позиции.

Инновационный веб-блокнот с AI и PDF: переосмысление работы с информацией | 2026-02-19T16:19:37

Еще доработал новый тул для себя для работы с информацией и её организации. Основная идея — это веб-блокнот для исследований, изучения темы, работой над ней, интегрированный с AI и поддержкой PDF.

Главная проблема обычных PDF-ридеров и заметок заключается в том, что контекст теряется, как только вы переключаетесь на новую вкладку. В моем инструменте каждый фрагмент текста или PDF становится узлом в «живом» гипертекстовом дереве, к которому я могу доступиться с нескольких компов в любое время.

Процесс работы:

— Контекстный AI. Я могу просить AI разъяснить сложные пассажи прямо внутри документа. Объяснение остается именно там, где был задан вопрос. При этом оно является отдельным документом, привязанным к конкретному месту в источнике. При клике вы видите на экране одновременно и оригинал, и пояснение.

— Панели вместо окон. Если само объяснение требует уточнений, справа открывается новая панель. Это позволяет выстраивать бесконечную цепочку запросов, ни разу не теряя места в исходном тексте. То есть, вы видите сразу несколько панелей, ненужные можно закрыть.

— Поддержка PDF. Я могу загрузить PDF, выделить область на странице (например, сложную диаграмму или список авторов), и LLM мгновенно извлечет данные, дополнит или объяснит их. Объяснение прицепится к месту, где его просили, как и в случае не-PDF.

— Вложенные аннотации. Мои комментарии — это не просто статичный текст. Они могут содержать собственные PDF, ссылки и дальнейшие подзадачи для AI, поддерживая глубину вложенности, которая отражает то, как мы мыслим на самом деле.

Это не просто система хранения файлов, а «движок» для построения знаний.

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