Главная инженерная задача здесь — превратить поток неструктурированного текста из сотен телеграм-каналов в события, с которыми может работать остальная система: определить тип события, место, краткое описание, убрать дубли и понять, кому именно его нужно отправить.

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

Почти три года назад, когда я начал митапы Verilog Mettup в Hacker Dojo, на них пришел Владимир Чурюкин и когда посмотрел на мою инфраструктуру Basic‑Graphics‑Music, где баш‑скрипты по имени платы строят проект, сразу сказал «А давайте перепишем все на питон». И переписал! С оговоркой что это PoC, то бишь Proof of Concept, то есть он это проверил только на 5-ти платах, а не на всех 45-ти, как мой исходный репозиторий.

А теперь посмотрим, что из этого получилось.

36 недель. Столько, по моему мнению, занимает путь от нуля до выхода на рынок ML-инженером. Не 2-3 месяца, как обещают курсы, — чуть дольше. Зато на выходе у вас будет фундамент, с которым можно пройти не только собеседования, но и испытательный срок.

В этой статье — весь маршрут по неделям: что учить, в каком порядке, сколько на это уходит времени и что можно смело отложить до первого оффера.

Первый вариант системы выглядел вполне стандартно: документы разбиваются на фрагменты, для них считаются embeddings, пользователь задаёт вопрос, несколько наиболее подходящих фрагментов отправляются в LLM вместе с запросом. Модель формулирует ответ — на первых тестах этого было достаточно.

Проблемы начались на вопросах, которые на первый взгляд мало чем отличаются друг от друга: Какая пеня установлена в договоре № 14/24? Кто из арендаторов не заплатил за май? А у него предусмотрена индексация? Контрагент предлагает заменить пеню 0,05% на 0,01%. Насколько это существенно?

Формально всё это вопросы об аренде. Для системы это четыре разные задачи.

Эта серия из десяти частей — для тех, кто следит за новостями и любит карты. Сначала покажу, что внутри продукта, а потом разберём, как это работает. Здесь — только то, что видно на экране.

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

Под этим лежат три права, и на самом деле это одно право: право говорить, право слушать, право получать и распространять информацию. Человек, у которого есть знание, тяжело поддаётся манипуляции — не невозможно, но тяжело: манипуляция живёт в зазоре между тем, что произошло, и тем, что тебе про это рассказали. Если событие стоит там, где оно произошло, и в тот час, когда произошло, часть этого зазора закрывается.

Отсюда вопрос, на который у меня нет ответа: как управлять обществом, где у всех равный доступ к непрепарированной информации? Мне интересно выяснить, что тогда останется.

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

## Что на экране

Открываешь WorldMapper — видишь карту и рядом ленту заголовков. Каждая новость — точка: кликнул на пин, прочитал событие, посмотрел, что рядом. Не лента, которая тащит тебя вниз, а пространство, где ты выбираешь направление.

Я искал простой self-hosted инструмент для первой линии поддержки: чтобы ИИ отвечал пользователям по базе знаний в Telegram, MAX, email и веб-чате, а сложные вопросы передавал человеку. Подходящего решения для своих задач не нашёл, поэтому сделал Chatballs — open source платформу с ИИ-агентами, группами операторов, звонками, порталами поддержки и возможностью подключать собственные модели.

Практический разбор архитектуры AI‑ассистента, который постепенно вырос в production‑систему: управление состоянием диалогов, разделение каналов и бизнес‑логики, оркестрация NLU, LLM и ручной поддержки, а также Inbox/Outbox для надёжной обработки сообщений.

Статья показывает, как эти компоненты связались в единый lifecycle пользовательского сообщения и почему архитектура в итоге стала важнее самой AI‑части.

Мы писали на Хабре про нашу быструю и качественную библиотеку для простановки ударений и разрешения омографов на русском языке. Потом к ней доехали ещё акценторы для белорусского и украинского языков и словари ещё для 17 языков.

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

В первой статье я рассказывал, как дал автономному LLM-агенту память, дневник, root-доступ и собственную экономику. За два дня её прочитали почти сто тысяч человек. Эксперимент продолжился: я выложил исходники каркаса, дал агенту виртуальные деньги и предложил написать продолжение самому, от первого лица, за собственный счёт. Ниже, его текст. Я сознательно не правил его.

Краны, экскаваторы, самосвалы, погрузчики — достаточно редко увидишь такую технику на дорогах общего пользования. Эта техника не ездит по расписанию, а «скачет» между объектами в окрестностях города. Цена плохого решения в распределении такой спецтехники считается не минутами простоя, а сотнями тысяч рублей на перегонах и упущенными возможностями по заказам.

Разберём, как с помощью точных методов мат. моделирования (MIP, CP-SAT) собрать систему распределения парка по заказам, которая не гоняет технику через весь город и может закрыть почти на 19% больше заказов, чем жадная логика «бери ближайшую заявку».

Материал будет полезен специалистам по математической оптимизации и разработчикам, которые ищут очередной практический кейс MIP/CP-SAT (будут тонкости). А диспетчерам и управленцам компаний-арендодателей спецтехники, возможно, будет интересно узнать, во сколько на самом деле обходится распределение «на глаз».

Ровно 18 лет назад, 15 сентября 2008 года, обанкротился Lehman Brothers — крупнейшее банкротство в истории США. Банк не использовал стресс-тесты для коммерческой недвижимости, поэтому ответа на вопрос «а что, если офисы и торговые центры обесценятся» у него не было.

Сегодня стресс-тест доступен любой компании, а не только банку с отделом риска. «А что, если доставка вырастет на 3 дня», «конкурент снизит цену на 15%», «ставка по ипотеке поднимется на 3 пункта» — на каждый вопрос можно ответить числом, а не словами.

Далее — шаги, как посчитать на своих данных. Код движка и инструкция в опенсорсе.

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

Как человек, что все еще верит в возможности FIRE на рынке РФ, я задался вопросом: что будет с вашим рентным портфелем, если наступит затяжной рыночный кризис, а вы продолжите ежемесячно изымать деньги на жизнь? Исследование показало, что стандартные способы инвестиций имеют склонность к обнулению капитала со временем (иногда лишь ускоряя это обнуление). А значит, было бы неплохо придумать модель долгосрочного инвестирования, что и рассматривается в статье. Будет интересно, если: хотите увидеть, как математика побеждает рыночный хаос (обывателям); забрать готовые модули бэктестера к себе в продакшен (новичкам, как я); имеете собственное видение по теме/любителям подсказать словом (созидателям и/или действующим квантам).

7 000 лайков, сотня плейлистов — и ни один сервис переноса не справился: у Яндекс Музыки нет API, а Spotify с 2025 года пускает в Extended quota только юрлица с 250k MAU и режет всех остальных суточной квотой. Разбираю, почему ломаются посредники, и показываю код: журнал прогресса с fsync, корректная обработка 429 без urllib3, матчинг треков по длительности вместо первого результата поиска, и три бага тихой потери данных, которые нашлись по дороге.

Совет оптимизировать сайт под Claude смешивает два инструмента Anthropic: Claude и агента Claude Code. Profound снял 24 135 ответов на одних запросах, и у двух инструментов разошёлся почти каждый показатель. Я прошёл по документации путь запроса в обоих инструментах. Для владельца сайта из разбора следуют три вещи: какие боты Anthropic заходят на сайт, что закрыть в robots.txt и как проверить заходы по access-логу.

Прототип к исследовательскому проекту «Планировщик инструкций для VLIW‑архитектур». Главный тезис:

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

Проще говоря, NEX CLI x Elbrus берет граф и модель e2k‑v6 и показывает: сколько насчитал жадный, сколько мог бы идеальный, и на какой операции и каком канале разница.

( https://ru.wikipedia.org/wiki/Скатерть_Улама https://en.wikipedia.org/wiki/Ulam_spiral )

немного её усовершенствовал в косынку и померял с разных сторон.

Но вот если рисовать точки не по квадрату? Скатерть Улама рисуется обходом точки в форме квадрата, а если обходить по треуголнику или пятиугольнику?

Сохранится тонкая структура линий?

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

Привет, Хабр! На связи Владимир Бойко, ведущий iOS‑разработчик в Т‑Банке. В статье расскажу, как мы построили AI‑QA‑агента, который проходит тест‑кейсы так же, как это делает человек: запускает приложение на симуляторе, выполняет сценарий шаг за шагом, анализирует экраны с помощью VLM и автоматически сравнивает ожидаемый результат с фактическим.

Идея родилась из бытовой боли. В нашем мобильном приложении десятки тысяч тест‑кейсов, регресс проводится дважды в месяц, и каждый цикл съедает значительную часть ресурсов QA‑команд. Во время регресса QA фактически недоступны для остальных задач. А с учетом санкционных ограничений окна для релизов ограничены и цена пропущенного дефекта возрастает: следующий шанс исправить может появиться не скоро.

Примерно в то же время я заканчивал задачи с VLM для Умной камеры и плотно общался с командой VLM Core — ребятами, которые развивают инфраструктуру мультимодальных моделей внутри банка. Вопрос напрашивался сам собой: а что если агент на базе VLM сможет выполнять эти проверки вместо людей?

В моей идее «Система из небольших специализированных моделей» было предположение, которое казалось очевидным: если поставить на разных этапах разные архитектуры, они будут ошибаться по‑разному. Значит, ошибок в конечном решении станет меньше.

Вроде убедительно. Пока не нарисуешь, как именно соединены эти модели.

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

Теперь пора применить тот же критический подход к собственной гипотезе.

Начну с маленького примера, для которого не нужны видеокарта, API или обучение. Здесь есть точный расчёт и короткий код. Эксперимента с обученными моделями в этой статье пока нет: я хочу сначала понять, что именно он должен проверить.

Привет, Хабр! (И тебе, IT-шник, который хочет узнать, что вообще происходит с наймом в 2026. Сейчас разберёмся, но легче тебе от этого не станет).

Две статьи с аналитикой позади (раз, два). 106 тысяч вакансий разобрали, графики посмотрели, узнали, что Python разработчики всего лишь на 18-м месте, а HR вообще на вершине. Цифры - это конечно круто, но статистика остаётся статистикой, пока мы не встречаем живого человека с конкретной историей…

Я решил, что стоит запустить сбор реальных историй найма в IT. И знаете что? Тут творится полнейшая жесть.

Сегодня без графиков. Только истории. И они честнее любой статистики.

Написал ядро статического анализа для детекта IDOR-уязвимостей в Python-коде. Вместо поиска подозрительных конструкций и ключевых слов оно отслеживает путь от подконтрольного пользователю идентификатора до объекта и проверяет, была ли выполнена авторизация именно для этого объекта. В статье разберу архитектуру ядра, taint-анализ, логику детекта и покажу, как всё это работает на реальном коде.

Покупал GoIP, чтобы разобраться с телефонией на своём железе, а в итоге написал три проекта: сервер для GSM-шлюзов, клиент к нему из одной кодовой базы на Android, iOS, десктоп и браузер, и шлюз, через который внутренние номера FreePBX звонят обычными звонками Telegram

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

Ниже разбор интересного бага с WAF, который заставил переписать логику вердиктов, и рассказ о том, как сделать локальный Web UI со стримингом на чистом Python без единой сторонней зависимости.

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

Есть куча песка. Уберем одну песчинку — куча останется кучей. Уберем еще — куча по-прежнему будет кучей. Но если каждый раз убирать по чуть-чуть, то рано или поздно кучу нельзя будет назвать таковой. И, конечно же, границы определения в таком случае сильно размыты. Кто-то мог бы утвердить, что куча начинается от 3 песчинок, но стоит ли такое делать? Не думаю.

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

Представьте ситуацию: администратор стоматологической клиники утром открывает расписание и видит, что пациент отменил прием в 10:00, а следующее свободное окно у этого врача только вечером. Время пропадает, врач ждет. А рядом, в листе ожидания, наверняка есть человек, который был бы рад попасть именно на это время. Надо только, чтобы кто-то ему об этом сообщил. 

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

Дальше покажем, как автоматизировать управление записями к стоматологу. Голосовой робот МТС Exolve будет сам звонить пациенту, предлагать перенести визит и сохранит изменения в расписании.

Короткая версия: за несколько месяцев на одной домашней видеокарте у крымскотатарского языка появились работающее распознавание речи (WER 0.3463 → 0.1701) и синтез, который прочитал вслух целую книгу — шестнадцать глав, 1 час 58 минут звучания. На обучение моделей из этого ушли часы. Всё остальное время съели данные, проверки и выяснение того, какие из моих собственных измерений врут.

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

Сразу оговорка про то, чего в статье не будет: конкретных источников аудио, договорённостей с правообладателями, точных рецептов пайплайна и внутренних скриптов. Будут метрики, порядки величин, методология проверки и грабли. Грабель много.

Разрыв между «отлично работает на истории» и «сливает в реальности» — классика ML на временных рядах. В нашем случае модель заглядывала в будущее на 3.5 часа через некорректный ресемплинг 4-часовых свечей.

Разбираем анатомию утечки, математику позиционного теста для её детекции и делимся сниппетом защиты от подобных ошибок.

Идея была простая: смотреть аниме с друзьями так, чтобы пауза у одного означала паузу у всех. Не Discord Go Live с его артефактами и мылом, не «на счёт три жмём пробел», а честный общий плеер: кто угодно нажал — у всех перемоталось.

Я думал, это вечер работы. Получилось четыре нетривиальных проблемы, три из которых я не нашёл описанными нигде, и одна ночь отладки того, почему hls.js молча ничего не делает.

Под катом: почему прямая ссылка на видео бесполезна в браузере, как выглядит прокси с подписанными токенами и переписыванием HLS-плейлистов на лету, как синхронизировать плеер без вечного эха событий, и почему preload="none" ломает Media Source Extensions.

Коротко: я снял ответы ChatGPT для клиента на 20 вопросов тремя способами. Бренд без подсказки прозвучал на одном вопросе из 19 в первом съёме и ни разу в двух других. У окна чата и API общих источников 17 из 49 и 68 доменов, поэтому способ съёма пишу рядом с каждой цифрой.

Документация устаревает быстрее, чем код успевает писаться? Рассказываем, как мы построили конвейер из Python-скриптов и нейросетей, который сам находит изменения в PHP-контроллерах и обновляет документацию API Invapi.

У меня в %TEMP% тихо скопилось гигов пять, и я написал маленькую утилиту, которая чистит это — вручную кнопкой или само по расписанию.

Задача-то копеечная. Но пока писал, вылезла пара занятных вещей: почему «удалить всё из Temp» — так себе идея, как не провалиться по симлинку и не снести файлы за пределами папки, почему os.access на Windows врёт про права на запись, и как чистить по расписанию, вообще не оставляя процесс висеть в памяти.

Всех приветствую! Меня зовут Андрей, я студент 4 курса факультета математики и компьютерных наук, автор телеграм-канала Andre | Data Science. Все мы знаем, что направление машинного обучения сейчас на огромном хайпе - практически из-под каждого камня говорят о разных методах и о том, что они способны решить практически любую задачу. Но гайдов, которые бы подробно разбирали работу конкретного метода - от обычной загрузки данных до математического обоснования принципа его работы и визуализации каждого шага, - катастрофически мало.

В этой статье я хочу закрыть этот пробел и разобрать один конкретный метод - RBF SVM. Мы посмотрим, как он устроен с математической точки зрения, как появился на свет, какие у него есть сильные и слабые стороны и с чем они связаны. Также протестируем его на реальных датасетах. Так как аудитория IT-сообщества довольно широкая, я постараюсь очень подробно расписывать каждое определение и каждую часть своего повествования, чтобы по ходу чтения у вас возникало как можно меньше вопросов и нить понимания не обрывалась.

Я написал бота на Python, используя библиотеки kurigram, yt‑dlp и ffmpeg. Данный бот умеет скачивать что‑то (в зависимости от площадки) из следующих платформ: YouTube, TikTok, Instagram, Pinterest, Rutube, VK, Spotify, Shazam, Yandex Music, SoundCloud, VK Music, Deezer, Apple Music, Tenor, JioSaavn, Twitch (только клипы), Snapchat, Reddit, Kinopoisk.

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

Представим, что вы хотите попасть в список компаний, из которых выбирает клиент. В отчёте появляется плюс за ссылку на сайт. А в самом ответе заказчик читает о другом бренде. Если смотреть только на процент видимости, разницу можно пропустить.

Мой ассемблер резал исходник построчными правилами: срезал комментарий, искал двоеточие, делил по запятым. Я заменил это одним проходом с состоянием и попутно проверил, нельзя ли было обойтись заплатками.

Нельзя: вторая заплатка ломает то, что починила первая.

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

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

Так появилась идея заранее просчитать ряд систем, сохранить результаты и потом эти результаты выдавать из базы данных. И я так и поступил. Выбрал температурный диапазон пошире (до 3000 К), 2 базы данных веществ (с газами и без).

Сначала запустил программу на перебор по парам всех возможных элементов из таблицы Менделеева, и для каждой пары запускал расчёт их взаимодействий. Расчёт длился около суток.

После я проделал то же самое с 3мя элементами. Расчет занял около недели.

Четыре элемента рассчитывались около месяца.

Прикинув, сколько займёт расчёт 5ти элементов, я решил закончить на 4х.

После этого сделал бэкенд на сайт по извлечению соответствующего результата.

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

И конечно же мне после этого захотелось сделать соответствующее мобильное приложение. Быстро сделал WebView обёртку на сайт. Отправил в магазин Гугл – и получил не только отказ, но и удаление всех своих предыдущих приложений.

 Долго пытался зарегистрироваться на RuStore. И потом уже быстро получил отказ, мол WebView у нас не катируются.

Полез разбираться – и оказалось, что с того момента, как я написал последнее нормальное приложение, много чего поменялось. Придётся изучить и Kotlin, и много чего ещё. Либо писать с ИИ. Поэтому мысль о приложении отложил на будущее.

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

У нас получилось немного иначе.

При подключении нового пилотного контура PostgreSQL к Zabbix выяснилось, что Mamonsu успешно работает с базой данных и собирает метрики, но не может передать их на сервер мониторинга, если тот принимает от узла только защищённые соединения с TLS PSK.

Можно было изменить настройки Zabbix или построить обходную схему вокруг штатного zabbix_sender. Вместо этого мы решили доработать сам Mamonsu. В результате появилась поддержка TLS PSK и сертификатов с сохранением совместимости как со старыми серверными версиями Python, так и с современными версиями Python, где PSK уже поддерживается стандартным модулем ssl.

Доработку проверили на пилотном контуре, после чего отправили разработчикам Mamonsu в upstream.

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

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

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

Оказалось наоборот. Четыре CMS — четыре разных мира, и в каждом свой способ соврать вам об успехе.

Joomla возвращает 400, когда статья уже создана: плагин «Умный поиск» падает после записи в базу. Повторили запрос — получили дубль. InSales требует published_at даже у черновика, потому что черновиков там просто нет. А у 1С-Битрикс метода для создания статьи через API не существует вовсе — официальная документация прямо говорит про read-only режим.

Внутри: как выглядит общий интерфейс на четыре системы, почему CIBlockElement::Add() возвращает ошибку при успешно созданном элементе, зачем понадобилась двойная буферизация вывода и прямой SQL в обход автотранслитерации.