Python *

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

В первой статье серии я рассказывал про речевые технологии для крымскотатарского в целом и обещал отдельно разобрать распознавание. Разбираю.

Итоговая таблица, чтобы сразу было видно, о каких величинах речь. Один и тот же отложенный тест, один и тот же скоринг, 893 клипа / 1.86 ч, два диктора, которых модель не слышала:

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

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

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

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

Код прикладываю на github - можете пользоваться и модернизировать!

В этой статье будет разбираться написание GitHub Actions пайплайна на основе моего стенда cicd-practice на GitHub (подробно все можно посмотреть там). Стенд состоит из FastAPI (веб API на Python) и PostgreSQL. Все сервисы разворачиваются в Docker с помощью Docker Compose (микросервисы) на VDS от Timeweb Cloud.

Для части приложения я также написал около 90 Pytest тестов, которые будут воспроизводиться в пайплайне, но об этом позже.

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

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

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

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

Я проверил – в базе оказалось более 4000 двухкомпонентных систем. Написать самостоятельно комментарии к каждой из них не в моих силах. Естественно, первой и единственной идеей, пришедшей на ум, были нейросети.

Нужно было выбрать вариант, который:

·      Был с минимальными финансовыми затратами;

·      Не занял много времени;

·      Описание системы было химически грамотным.

Я выбрал LM Studio и начал перебирать варианты нейросетей, способных работать на моем железе (RTX 3090) и выдавать приемлемый результат. Таковой оказалась gemma-4-31b.

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

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

Меня зовут Микаэл Новиков, я главный разработчик в команде ML-платформы MAGNIT TECH. Расскажу, как мы в проекте F&R не смогли оставить data quality без внимания, отобразили результаты проверок в OpenMetadata и попутно наступили на несколько грабель интеграции open source-решения.

Маленькая модель быстро набрасывает несколько следующих токенов, а большая проверяет всю пачку за один проход. Совпавшее оставляет, на первом расхождении переписывает продолжение сама, поэтому ускорение не меняет распределение ответа. В speculative decoding большая модель буквально говорит черновой: «Давай по новой, Миша».

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

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

Отдельно посмотрим на подходы, где вторая модель вообще не нужна: EAGLE, Medusa, LayerSkip и DFlash.

Способ визуализации n‑мерных эмбеддингов в трёхмерном пространстве.

Обычно при упоминании отображения эмбеддингов (или как мы уже знаем, n‑мерных векторов) имеют в виду отображение множества этих векторов на двумерное или трёхмерное пространство с уменьшением размерности.

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

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

Гипотез было три. Может, дело в файле robots.txt, который блокирует ботов ИИ. Может, у проекта просто нет llms.txt — модного файла, который сейчас советуют выкладывать. Может, документация физически нечитаема для краулера. Я написал скрипт, прогнал его на 30 сайтах документации популярных Python- и JS-библиотек и получил цифры, которые сходятся не с той гипотезой, что я держал в голове изначально.

Коротко результат: robots.txt не блокирует ботов ИИ ни на одном из 30 доменов — ни по адресу документации, ни в корне домена; llms.txt есть у 11 проектов, и независимые логи показывают, что его почти никто не запрашивает; а пустая для краулера страница нашлась у трёх проектов, но после проверки внутренних страниц из них остался один. Метод, код и таблица — дальше, вместе с сопоставлением с чужими исследованиями и командой, которой это можно проверить у себя.

Покажу, как можно ускорить код h11 (HTTP/1.1 библиотечка со 710k пользователями на Github) с помощью компиляции с mypyc примерно в два раза. В процессе расскажу, как я чинил разные интересные ошибки, связанные c адаптацией кодовой базы под mypyc.

За полтора месяца я собрал браузером около двухсот карточек товаров, счётчики просмотров с одиннадцати площадок и содержимое пары десятков объявлений. Данные нужны были не для продажи, а для собственной аналитики: я веду небольшой сайт и считаю по нему цифры.

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

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

У любого ускорителя Python есть число: во сколько раз он быстрее. Меряют его на ядрах - сортировка, обход дерева, арифметика в цикле. Сервис устроен не так: обработчик ходит в базу, считает в numpy, сериализует ответ, и байткода, к которому это число применимо, в нём может почти не остаться. CinderX ускоряет байткод, и за пределы байткода это число не распространяется. Доля байткода в вашем сервисе - свойство вашего кода, а не расширения, и пока она не посчитана, «ставить или нет» решается угадыванием.

Я не знаю человека, который любит долго ждать. Но ожидание и его последствия бывают разные.

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

В статье я расскажу, как нам удалось ускорить сборку Python до 20 раз.

На этой неделе на Хабре спорили, нужны ли программисту самые умные модели или для рутины хватит дешёвых. Триста комментариев и ни одного замера на одинаковых задачах. Я сделал: пять рутинных задач, четыре модели одного семейства, по два прогона, скрытые тесты. Сорок прогонов.

Самая дорогая модель оказалась самой быстрой: 341 секунда против 395 у самой дешёвой, потому что ей нужно меньше ходов и вдвое меньше текста. Четыре задачи из пяти решили все, 32 прогона из 32. А на пятой младшая модель написала баг и отчиталась двумя галочками подряд, вторая из которых опровергает первую.

Я прогнал 20 промптов через Perplexity API по три повтора, собрал 60 ответов и у каждой отсылки [N] в тексте связал предложение ответа со страницей источника, на которую оно указывает. Дальше самое трудоёмкое: для каждой такой пары — предложение ответа и страница источника — я искал в HTML кусок текста, максимально похожий на утверждение из ответа. Из 1355 отсылок 948 привели на страницы, которые ещё открываются, и на 448 из них нашёлся пассаж — абзац, пункт списка или ячейка таблицы, — покрывающий хотя бы треть слов утверждения.

Главный результат для того, кто пишет страницы, а не гоняет замеры: на сработавшей странице задействовано медианно два пассажа из 85, длиной около 49 слов каждый. По числу кусков это 2%, по словам больше — медиана 6,4% текста страницы при среднем 11,6%: сработавший пассаж длиннее типичного. Планировать имеет смысл не прочтение страницы целиком, а то, что из неё вытащат один самодостаточный абзац; что это значит для конкретного текста, я развернул в разделе про работу с Perplexity — он стоит в середине, до разбора моих ошибок в коде. Границы, за которыми эти числа перестают работать, вынесены в отдельный раздел — там же написано, как проверить то же самое на своей нише.

Вопрос, с которого всё началось: в логе замера видно, какие URL Perplexity ставит в источники, и не видно, что именно со страницы поехало в ответ — весь текст, абзац или одна строка списка.

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

Показываю схему, которая решает обе проблемы: API без toggle, ключ идемпотентности в PostgreSQL, очередь в IndexedDB, Service Worker и проверка офлайна в Playwright. Это не полный offline-first — только защита действий в момент обрыва связи.

Я отрендерил трёхминутный ролик из одной статичной картинки и получил файл на 472 МБ. Виновным оказалось плёночное зерно: шум амплитудой меньше 2 % шкалы, который почти не видно, умножает размер видео на тринадцать, а попиксельный — на тридцать три.

Разбираюсь, почему межкадровое сжатие ломается именно о шум, чиню это тремя способами (зерно блоками, другой кодек, синтез зерна в AV1) и меряю результат по VMAF: при одинаковом качестве x264 просит 15.2 Мбит/с, а AV1 — 4.4. Заодно ловлю собственный визуализатор спектра на вранье — на цифровой тишине он бодро плясал на 0.885 от полной высоты — и разбираю три грабли, включая пустую строку в argparse, которая вписала слово «использование» внутрь prog.