Python *

Исследователи Stanford Hazy Research представили CLM-8B - Contrastive Language Model, открытую 8B-модель для быстрых решений внутри агентных систем. В отличие от обычной LLM, которая последовательно генерирует токены ответа, CLM получает состояние среды и набор возможных действий, после чего оценивает, какое действие лучше соответствует текущему состоянию. Код и модели опубликованы открыто, а базовая реализация построена вокруг Qwen3-8B.

Идея меняет саму вычислительную задачу. Пусть агент находится в состоянии s и может выполнить одно из действий a₁, a₂, ..., aₙ; обычная генеративная модель должна сформировать текстовое представление решения токен за токеном, тогда как CLM вычисляет вектор состояния f(s) и векторы действий g(aᵢ), после чего сравнивает их скалярным произведением. Упрощённо решение можно записать как a* = argmaxᵢ f(s)·g(aᵢ): чем ближе представления состояния и действия в обученном пространстве признаков, тем выше вероятность выбора этого действия.

Для обучения используется контрастивная функция потерь InfoNCE. Правильная пара «состояние - действие» притягивается в пространстве представлений, а неправильные действия отталкиваются; математически вероятность правильного действия можно представить как P(aᵢ|s) = exp(sim(s,aᵢ)/τ) / Σⱼ exp(sim(s,aⱼ)/τ), где τ задаёт резкость распределения. Если доступно только одно действие, такая классификация почти бессмысленна, но при сотнях или тысячах повторно используемых действий преимущество становится существенным: их векторы можно вычислить один раз и затем кэшировать.

Чем сложнее бизнес-процессы, тем сильнее размывается логика связей: она оседает в каскадах SQL-джойнов, коде микросервисов и витринах, а LLM поверх плоских таблиц начинают галлюцинировать. Альтернатива — перенести доменные правила, сущности и роли на уровень схемы с помощью семантического слоя. Команда Neoflex протестировала этот подход на TypeDB — СУБД с нативными n-арными отношениями и встроенным логическим выводом. На сквозном датасете из 65 752 заказов и 470 000 веб-событий мы на практике сопоставили классический SQL и TypeQL: сравнили декларативные ролевые паттерны с каскадами JOIN и декартовым раздуванием строк, замерили реальную скорость выполнения и упаковали структурированный контекст для ИИ-агента без мусорных дубликатов. В статье на Хабре — методология декомпозиции схемы, замеры производительности и честный разбор того, в каких сценариях гиперграфы дают преимущество, а где привычные реляционные и графовые базы остаются незаменимыми.

Привет, Хабр! На связи Николай Видов, тимлид команды чат-ботов в Т, пишу на Python с 2017 года. За это время я успел поработать с конфигами во всех видах: INI-файлы в legacy-проектах, переменные окружения в docker-контейнерах, YAML с шаблонами в Helm, pydantic-модели в свежих сервисах, Vault и Consul в инфраструктуре покрупнее. 

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

Пройдусь по четырем заметным инструментам: python-decouple, Dynaconf, Hydra, pydantic-settings. Покажу, попадают ли они в семь требований: много источников, мердж с контролем, типобезопасность, валидация значений, понятные ошибки, секреты на уровне схемы и отладка. В конце соберу сводный взгляд: кто что закрывает и где в инструментах явная дыра.

Когда в день вам присылают 400 резюме на одну вакансию, «посмотреть всех» физически не получится. Зато это выглядит прямо как задача под автоматизацию!

Итак, у меня есть вакансия и огромная пачка PDF-файлов с резюме. Надо понять, в каких из них действительно подтверждаются нужные компетенции, где информации не хватает и кого стоит посмотреть в первую очередь. Мы не будем автоматизировать сам найм или отправку отказов. В кейсе ниже LLM будет составлять техническую выжимку и помогать разобрать очередь. Финальное решение останется за человеком.

По идее можно было бы открыть любую ИИшницу, загрузить туда пачку резюме и собрать результаты. Но это не автоматизация, а ерунда. Поэтому мне нужен API, который можно подключить и встроить в собственный процесс проверки резюме. Для меня тут важен именно уровень абстракции. Я не хочу искать GPU, скачивать веса модели, подбирать версию CUDA, поднимать vLLM, рассчитывать, влезет ли модель в видеопамять, настраивать масштабирование, мониторить отдельный ML-зоопарк и выяснять, почему после обновления драйвера все снова упало.

Все кому не лень говорят о 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 проектов, и независимые логи показывают, что его почти никто не запрашивает; а пустая для краулера страница нашлась у трёх проектов, но после проверки внутренних страниц из них остался один. Метод, код и таблица — дальше, вместе с сопоставлением с чужими исследованиями и командой, которой это можно проверить у себя.

ИИ агент отлично справляется с тем, что раньше раздражало своей механичностью: протянуть поле через модель и сериализатор, обновить тесты, поправить клиент, сгенерировать миграцию. Последний пункт выглядит особенно безобидно. ORM сама умеет строить DDL, агент всего лишь запускает знакомую команду, diff небольшой, тесты зелёные.

Но миграция — странный вид кода. Она может состоять из пяти строк и при этом иметь больший blast radius, чем изменение на тысячу строк в бизнес-логике. Ошибка в Python обычно ломает конкретный путь выполнения. Неудачный ALTER TABLE способен поставить в очередь запросы ко всей таблице, съесть пул соединений и превратить локальную правку схемы в отказ сервиса.

С появлением coding agents эта асимметрия стала заметнее. Генерировать изменения схемы стало почти бесплатно, а стоимость проверки не уменьшилась. Поэтому я бы рассматривал миграцию, созданную агентом, не как обычный файл в diff, а как привилегированный артефакт — примерно как изменение Terraform, Kubernetes RBAC или CI-секрета. Агент может его подготовить, но право пройти в production должно определяться отдельным набором проверок.

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

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

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

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

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