Python *

Почти весь код туториалов, который мне попадался в открытом доступе, с точки зрения кодирования, написан на уровне junior-программиста, что вполне закономерно, ведь все Data Science и ML-инженеры, которых я знаю, в большей степени математики, а не программисты. И сложность их кода не только в языковых конструкциях и отсутствии хороших практик кодирования, но и в том, что он больше похож на математические выкладки и довольно тяжело читаем для людей, имеющих за плечами только институтский и школьный курс математики. И вся это сложность умножается на непростую теоретическую базу, поэтому если ты не знаком с теорией, то догадаться по коду, для чего нужны выполняемые действия, порой бывает просто решительно невозможно.

Я заинтересовался ML и AI в 2019 году, и с тех пор количество статей и примеров кода в Интернете выросло многократно, но одно, к сожалению, так и осталось неизменно — стиль кодирования примеров и их математичность.

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

Это история про пет-проект, который я делал ради трёх вещей одновременно: прогноз приземной температуры на неделю вперёд из данных одной метеостанции, честные интервалы неопределённости вместо голой точки, и работа на железе уровня Raspberry Pi без всякого GPU. По дороге я несколько раз ошибся, один раз откатил целый эксперимент, и в итоге понял про свою же модель больше, чем когда её проектировал.

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

Код лежит в репозитории (ссылка в конце). Данные не выкладываю, брал часовые ряды из Open-Meteo, их можно тянуть самому; в репозитории есть синтетический генератор, чтобы прогнать весь конвейер за пару минут.

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

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

Именно поэтому архитектура проекта получилась такой.

Делюсь опытом: собрал прод-агента на Claude для небольшой студии дизайна интерьера. Чат отвечает на Haiku 4.5, генератор концепций — на Sonnet 4.6, фото из Pexels вместо DALL-E. Без LangChain, без векторной базы, без RAG-фреймворка. Один файл main.py на 712 строк, два промпта. В статье разбираю развилки: почему именно так, на каких граблях постоял (порог кэша 4096 у Haiku, парсинг JSON-обёртки от Sonnet), где этот подход начнёт ломаться. Не «гайд от эксперта» — скорее дневник развилок.

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

Привет, Хабр! Меня зовут Никита Трунов, я — разработчик команды инфраструктурных сервисов K2 Cloud. Сегодня расскажу вам о нашем новом облачном сервисе управления ключами KMS и как он помогает с шифрованием данных в облаке. В этом материале мы разберемся, какие данные приходится защищать, какие существуют модели доверия к облачному провайдеру и как устроена архитектура современного сервиса управления ключами.

Что, если хранить зашифрованный контейнер не в одном файле, а распределять между несколькими JPEG-изображениями? Причём так, чтобы потеря части изображений не приводила к потере данных. В этой статье мы посмотрим, как может работать такая схема, и разберём её основные принципы без погружения в код.

Доброго времени суток . Спасибо всем заинтересовавшимся моей статьей. Задача коммивояжёра — одна из самых известных задач комбинаторной оптимизации. Её суть заключается в поиске самого выгодного маршрута, который проходит через указанные города по одному разу с последующим возвратом в исходный город. Уже при небольшом числе городов >20 задача не может быть решена методом перебора вариантов за приемлемое время.

Для решения задачи коммивояжёра существует большое количество методов и алгоритмов, самые распространённые — поисковые алгоритмы. Лидеры среди них — генетические алгоритмы и алгоритмы колонии муравьёв.

Я придумал свой вариант.

В статье «Сравнение производительности генетических алгоритмов и муравьиных алгоритмов применительно к задаче коммивояжера Авторы: Sabry Ahmed Haroun, Benhra Jamal, El Hassani Hicham Лаборатория LISER, ENSEM, UH2C Касабланка, Марокко.» от May 2015. Приводятся результаты тестов. Генетический алгоритм был разработан на C++. Муравьиный алгоритм оптимизации был написан на C#.

В сети до сих пор висят мануалы из 2013, где предлагают писать громоздкие скрипты на PHP с библиотекой PHPExcel или использовать встроенный импорт через веб-интерфейс phpMyAdmin. На практике эти методы спотыкаются на первой же тысяче строк: слетают кодировки, ломаются форматы дат, а дробные числа округляются до целых.

При взаимодействии разработки с менеджментом или бухгалтерией регулярно всплывает одна и та же задача. Нужно либо выгрузить таблицу из базы в Эксель для отчёта, либо, наоборот, залить обратно в СУБД тяжелый xlsx. файл со свежими ценами или списком контрагентов. Настраивать тяжелые ETL-системы ради разовой выгрузки неэффективно. Проблема решилась написанием короткого CLI-скрипта на Python - mysql_bridge. Утилита обеспечивает сквозную двустороннюю конвертацию данных, автоматически анализирует структуру и сохраняет исходные типы на лету. Исходный код скрипта и Readme Здесь. Если Вас заинтересовала или статья была полезна, поддержите звездочками.

Как устроен двусторонний мост

Вся логика инструмента умещается за счёт связки pandas, sqlalchemy и движка openpyxl. Скрипт работает с файлами Эксель напрямую на уровне бинарного кода, поэтому его можно запускать на серверах без установленного офисного софта. Утилита работает в двух режимах.

Один из самых важных параметров на МРТ снимках — это граница опухоли. Именно эта граница определяет, какие структуры головного мозга были затронуты опухолью, и позволяет оценить степень поражения соседних областей и тканей. Благодаря качественному определению контура можно точнее спрогнозировать лечение, поэтому нельзя недооценивать важность определения границ.

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

BISCUIT-Net стремится решить именно эту проблему. Работая как стандартный U-Net, он добавляет легковесное внимание на контур. Модель буквально делает набросок, после чего аккуратно выстраивает границу. Философия модели: «граница это не побочный эффект, а цель».

Конвейер на Python + Hydra, который превращает папку с аудио в богато размеченный датасет: качество речи, просодия, разборчивость, спикер, транскрипция — по колонке на запись. От одной видеокарты до кластера, карты под нагрузкой, и он не падает на «длинном хвосте» записей, на которых обычно рассыпается наивный скрипт.

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

У нас на проекте десятки прайсингов на топливо: один вендор шлёт CSV, другой Excel, третий JSON на вебхук. Данные одни и те же, но колонка цены везде называется по-своему, даты в трёх форматах, единицы то литры, то галлоны, а половина нужных полей просто отсутствует. И под каждый источник у меня жил отдельный парсер на сотню строк if-else. Сначала их было три, потом восемь, потом я перестал считать. А по-настоящему добило другое: эти парсеры ломались молча. Вендор тихо переименовывал колонку.

В третий раз за месяц копируя один и тот же парсер, я понял, что так нельзя, и вынес логику маппинга из кода в данные. Из этого выросла библиотека fidelis: ты описываешь данные один раз как Pydantic-модель, а соответствие под каждый кривой источник один раз пишет LLM — в виде читаемой YAML-спеки, которую ты ревьюишь и коммитишь. Дальше LLM не нужен: чистый детерминированный Python, валидация каждой строки и отлов изменений схемы ещё в CI. Рассказываю, как дошёл до жизни такой и как это устроено.

Привет! Я Андрей Иванов, NLP-исследователь в R&D-лаборатории red_mad_robot.

Когда мы собираем AI-агента, первым делом выбираем модель под задачу. Но в реальном приложении она не работает в одиночку, ей нужен агентский harness — программная обвязка. Поэтому выбирать приходится не просто модель, а связку «модель + harness».

Чтобы делать этот выбор осознанно, мы создали Harness Bench — открытый фреймворк, который тестирует связки на реальных задачах в одинаковых условиях. В статье расскажу, как он устроен, разберу баги опенсорсных обвязок, которые ломают автоматический прогон, а потом покажу на цифрах, как смена harness влияет на способности одной и той же модели.

Я работаю в контекстной рекламе и аналитике пять лет. Когда популярное расширение xml-river перестало работать, у тысяч специалистов сломался привычный сбор семантики через KeyCollector. Я решила проблему локально: написала десктопную программу на PySide6, которая напрямую работала с новым официальным API Wordstat. Программа продавалась с пожизненной лицензией, а пользователи ходили в API под моим личным токеном. Всё работало отлично, пока клиентов не стало слишком много: общий лимит в 5000 запросов в сутки превратился в массовые ошибки 429 Too Many Requests. Стало ясно: модель с общим токеном доживает дни. В этом посте — технический разбор того, как я за одну неделю полностью переписала архитектуру, перевела парсер на SaaS-модель (FastAPI + SQLite) с независимыми квотами для каждого пользователя. С кодом, схемами и честной юнит-экономикой

Недавно мы с женой придумали небольшой совместный проект: она креативит, я прогаю. Сделав каркас в Codex, я завел чат на троих с Hermes Agent. Пошерил ему доступы и контекст, теперь моя пассия добавляет фичи и двигает пиксели голосовухами. Это сработало так круто, что я всунул Гермеса много куда — и не могу не поделиться этим с вами!

В этой статье я расскажу: что такое Hermes Agent, как я его использую и как сделать себе также.

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

Осенью 2024 года я не планировал начинать новый проект. Тем более связанный с медициной.

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

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

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

Параллельно с этим я заканчивал курс Python в Яндекс Практикуме. Днём — работа, вечером — обучение, ночью — медицинские статьи и клинические рекомендации. Не самый простой период, но именно тогда и появилась идея проекта, о котором пойдёт речь дальше.

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

Хочу рассказать про наш проект Exam AI — внутреннюю платформу для аттестации и тренировки сотрудников.
Это не “ещё один тестик на 20 вопросов”, а система, где:

Градиентный бустинг часто воспринимают как «ещё один алгоритм из sklearn», но за ним стоит простая и сильная идея: модель не пытается сразу угадать правильный ответ, а шаг за шагом исправляет собственные ошибки.

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

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