Собрали в одном месте самые важные ссылкии сделали Тренажер IT-инцидентов для DevOps/SRE
Я решил посвятить статью своему недавнему мини‑проекту, сутью которого является обучение небольшого перцептрона 2-5-1 с помощью Python без сторонних библиотек (типа NumPy), и его последующий инференс на непрограммируемом инженерном калькуляторе Casio‑Fx-82-Es Plus (2nd edition).
Обучение с подкреплением (Reinforcement Learning) сейчас переживает ренессанс. Мы видим впечатляющие демонстрации успехов искусственного интеллекта: алгоритмы, обыгрывающие чемпионов в го и StarCraft, управляющие роботами‑гуманоидами и оптимизирующие дата‑центры. Но за этими успехами часто стоит жесткая привязка к конкретному окружению. Стоит немного изменить правила игры, и агент теряется.
А теперь о том, что происходило в последнее время на других ресурсах.
Задача звучит просто. Пусть LLM-агент пишет рабочие Python-скрипты под KOMPAS-3D. Открывает сборки, обходит состав, ставит виды, заполняет штампы, собирает спецификации по ЕСКД. То, что инженеры сейчас делают руками или своими скриптами, накопленными за годы.
Конвейер на Python + Hydra, который превращает папку с аудио в богато размеченный датасет: качество речи, просодия, разборчивость, спикер, транскрипция — по колонке на запись. От одной видеокарты до кластера, карты под нагрузкой, и он не падает на «длинном хвосте» записей, на которых обычно рассыпается наивный скрипт.
Один из самых важных параметров на МРТ снимках — это граница опухоли. Именно эта граница определяет, какие структуры головного мозга были затронуты опухолью, и позволяет оценить степень поражения соседних областей и тканей. Благодаря качественному определению контура можно точнее спрогнозировать лечение, поэтому нельзя недооценивать важность определения границ.
Что, если хранить зашифрованный контейнер не в одном файле, а распределять между несколькими JPEG-изображениями? Причём так, чтобы потеря части изображений не приводила к потере данных. В этой статье мы посмотрим, как может работать такая схема, и разберём её основные принципы без погружения в код.
Это история про пет-проект, который я делал ради трёх вещей одновременно: прогноз приземной температуры на неделю вперёд из данных одной метеостанции, честные интервалы неопределённости вместо голой точки, и работа на железе уровня Raspberry Pi без всякого GPU. По дороге я несколько раз ошибся, один раз откатил целый эксперимент, и в итоге понял про свою же модель больше, чем когда её проектировал.
Современный диабетик использует сразу несколько устройств и сервисов. Сенсор непрерывного мониторинга глюкозы, приложение производителя, иногда инсулиновую помпу, иногда обычные шприц-ручки. Каждый производитель строит собственную экосистему, и объединять их между собой никто не собирается.Мне хотелось получить единую систему, которая автоматически собирает показатели сахара, хранит историю и предоставляет данные уже моему приложению.
Модуль для работы с многомерными массивами. Скачать можно по ссылке: https://pypi.python.org/pypi/numpy/
Когда мы собираем AI-агента, первым делом выбираем модель под задачу. Но в реальном приложении она не работает в одиночку, ей нужен агентский harness — программная обвязка. Поэтому выбирать приходится не просто модель, а связку «модель + harness».Чтобы делать этот выбор осознанно, мы создали Harness Bench — открытый фреймворк, который тестирует связки на реальных задачах в одинаковых условиях
Утилита позволяющая измерить процент покрытия тестами. Скачать можно по ссылке: https://pypi.python.org/pypi/coverage/
У нас на проекте десятки прайсингов на топливо: один вендор шлёт CSV, другой Excel, третий JSON на вебхук. Данные одни и те же, но колонка цены везде называется по-своему, даты в трёх форматах, единицы то литры, то галлоны, а половина нужных полей просто отсутствует. И под каждый источник у меня жил отдельный парсер на сотню строк if-else. Сначала их было три, потом восемь, потом я перестал считать. А по-настоящему добило другое: эти парсеры ломались молча. Вендор тихо переименовывал колонку.В третий раз за месяц копируя один и тот же парсер, я понял, что так нельзя, и вынес логику маппинга из кода в данные. Из этого выросла библиотека fidelis:
За три месяца наш голосовой ИИ-агент успел соврать клиенту про несуществующего администратора, принять всех звонящих за одного человека и месяц выдавать обычный синтез за "клонированный голос". Разбираю, почему это лечится структурой кода, а не промптом — на полностью российском стеке.
Я собрал Movie Planner — сервис для ведения базы кино с друзьями, планирования просмотров и трекинга сериалов. Мы используем искусственный интеллект в нашем сервисе, и про него я как раз хочу рассказать: полгода назад я начал открывать для себя его возможности, и с тех пор исследую всё новое и новые способы применения, экспериментирую с мультиагентными системами и ищу, как интересно можно применить нейросети.
В Python при выборе библиотеки для работы с MQTT почти всегда приходишь к paho-mqtt. Это зрелый и самый популярный клиент, но его API построен на колбэках, а современное Python-приложение живёт в asyncio: FastAPI, фоновые воркеры, асинхронные клиенты и всё это в одном общем event loop.В одном из IoT-проектов я столкнулся ровно с этим. Мне нужен был MQTT-клиент, который без сложной адаптации встраивается в асинхронное приложение и позволяет работать с подписками как с управляемыми объектами, а не через набор колбэков.
Надоело разворачивать CVAT через докер и мириться с лагами браузера? Я расскажу свою историю, как от простецкого аннотатора собранного на коленке написал мощную легковесную отечественную альтернативу на PyQt5 и OpenGl, с пакетной авторазметкой и иерархией классов.
Обычный летний день на проекте: ruff зелёный, mypy зелёный, тесты проходят. А domain при этом тихо импортирует adapters. Слоистая архитектура, которую рисовали на старте, теперь осталась только на схеме. Линтер ловит неиспользуемый импорт и кривой отступ. Типизатор - что вместо int передали str. А то, что бизнес-логика потащила в себя SQLAlchemy или Redis, не видит никто.