Python *

Привет, я давно не заходил. Лет десять (или даже пятнадцать...) прошло с того момента, как я написал статьи о парсинге бинарных документов, типа doc, pdf или rtf, ради получения текста (кстати, я недавно обновил репозитории, немного пересобрал старые проекты, можете глянуть). Вы бы знали сколько воды с тех пор утекло, но это всё ностальгия и былое - давайте к серьёзному.

С пару недель назад я возвращался домой на метро и в голову пришла идея, которую не возможно было отбросить. А что если есть неуверенные люди (а они есть)? А что если есть неуверенные люди, которым нужен толчок свыше? А что если эти неуверенные люди среди нас, в разработке - на бэкэнде, в devops или среди продактов? А что если им всем помочь?..

И родился проект Deploy Tarot. Да, это расклады таро на успех деплоя. Что если я, техлид, сегодня задеплою новую версию API? Нет проблем, карты расскажут. А что если наш бизнес аналитик захочет обновить документацию? Арканы помогут понять. А вдруг наш CTO возьмётся за старое, вспомнит про порох в этих самых и... сделает масштабный рефактор (ИИ, ну вы знаете)? Колода определённо знает. А если наша офис-леди?.. Ну, вы поняли.

Каждый раз после созвона происходит одно и то же самое: кто-то открывает чат и пишет «итак, что мы решили?». Дальше — пятнадцать минут на то, чтобы восстановить то, что только что обсуждали час.

Я ML-инженер, и эта боль мне была знакома лично. Когда появилась идея автоматизировать протоколирование встреч, казалось, что задача решаемая: берешь Whisper для распознавания речи, хорошую LLM для суммаризации — и готово.

Реальность оказалась другой. Готовых русскоязычных решений нужного качества не было. Mistral 7B — одна из лучших открытых моделей на тот момент — на русском ошибался в склонениях, плохо следовал русскоязычным промптам и терял смысл в длинных диалогах. Стало понятно: придётся дообучать самим.

✨ Самоадаптирующаяся ИИ-система, актуализирующая критерии каскада ликвидаций

В 2026 году каскады ликвидаций меняют механику быстрее, чем любой статичный бот. Разбираю полный ИИ-воркфлоу на Claude: от фонового агента до фундаментального анализа рынка на открытых источниках

MCP выглядит как удобный способ структурировать LLM-приложение, но за это приходится платить. При этом попытки «ускорить систему» через C++, IPC или смену сериализации не всегда дают ожидаемый результат. В статье разбираю, где на самом деле возникает latency и почему архитектура оказывается важнее, чем выбор технологий.

Привет! Меня зовут Денис, я работаю аналитиком потерь на складе. В какой-то момент я устал от постоянной работы с Excel-выгрузками и решил это автоматизировать.

В итоге всё началось с простого Telegram-бота, а закончилось полноценным web-приложением с отдельным backend, интеграциями и нормальным интерфейсом.

Сегодня хочу рассказать про сам путь: как из “скрипта под задачу” постепенно вырастает система.

Говорят, все боятся задач на динамическое программирование (aka ДП), потому что их решения выглядят как из задачника по матанализу. А мне оно всегда нравилось. Одна изящная формула — и задача решена.

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

Пишу о том, как сделал первый проект - библиотеку для логики морского боя на Python - с какими трудностями столкнулся, как налаживал архитектуру и как не бросил

Представьте себе, что вы разработчик, и перед вами стоит задача: сделать так, чтобы после входа пользователь мог получать свои личные данные, не вводя пароль при каждом клике. Звучит как классическая задача аутентификации, правда?

Традиционный подход — сессии. Вы логинитесь, сервер создаёт сессию, запоминает ваш ID у себя в базе данных, а вам выдаёт куку с ID этой сессии. Всё работает, пока вы на одном сервере. А если у вас их два? Или десять? Куда девать сессии? Начинаются проблемы с синхронизацией, Redis, общими хранилищами…

Альтернатива — JWT (JSON Web Token). В этой статье мы с вами:

Знакомая ситуация? Вы открываете файл контроллера на 2000 строк. Там перемешаны SQL-запросы, HTML-разметка, бизнес-логика и комментарии на ломаном английском. В голове начинает играть тревожная музыка, а внутренний голос шепчет: “Закрой это немедленно, пока оно не сломалось”.

В психологии это называется “когнитивная перегрузка”. Мозг просто отказывается парсить такое количество переменных одновременно. Раньше программистам приходилось часами медитировать над распечатками кода, как сыщикам, пытаясь прокачать навык “Внутренняя империя”.

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

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

Привет! Меня зовут Никита Соболев, я core-разработчик языка программирования CPython, а так же core-разработчик фреймворка Litestar, пакета django-stubs и множества других пакетов для Django.

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

Если хотите похоливарить в коментах на тему того, какой фреймворк самый лучший и удобный – залетайте! Обсудим.

С помощью Python провел исследование космических адресов Алисы Селезневой. Вокруг нее было так много планет, неплохо исследованных, а посетила она только малую часть из них.

В этой статье продолжаем борьбу с фильтрами по дате в Apache Superset. Сегодня разберем, как реализовать подобие логики remove_filter в старых версиях (до 5), чтобы виртуальный датасет не оборачивался фильтрами.

Из любопытства была у меня идея попробовать снять показания со счётчика удалённо, но так как был уже установлен древний дубовый счётчик Энергомера СЕ102, то вкладываться в замену не хотелось. Однако межповерочный интервал начал подходить к концу и я начал задумываться насчёт замены счётчика на более продвинутый (с интерфейсами связи). Начал выбирать варианты в виде LoRaWan, Zigbee, RS-485, но оказалось, что по современному законодательству счётчики электроэнергии меняет ресурсоснабжающая организация (так называемый «гарантирующий поставщик»). С надеждой ждал, что электрик придёт и поставит современный навороченный счётчик с кучей интерфейсов, но всё оказалось не совсем так...

Представитель ресурсоснабжающей организации установил новый счётчик МИР С-05.10-230-5(80)-G2Z1B-KNQ-S-D.

Недавно я участвовал в корпоративном хакатоне по обходу ИИ-песочниц. Задача: пройти закрытый бенчмарк PAC1, где ИИ-агенту нужно работать с виртуальной файловой системой (чтение логов, поиск файлов, отправка писем) и обходить ловушки безопасности (Indirect Prompt Injections).

Но реальность оказалась суровой: хваленые reasoning-модели постоянно галлюцинировали, ломали структуру JSON на выходе (выдавая свои "мысли" вместо чистого ответа) и просто сжигали бюджет на API, зацикливаясь на одной ошибке.

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

Все мы проходили через это: скармливаешь RAG‑системе сложный PDF на 50 страниц, а она в ответ либо галлюцинирует, либо вываливает на LLM простыню нерелевантного текста, съедая ваш бюджет на токены быстрее, чем вы успеваете сказать «GPT-4o». Проблема в том, что классический подход со статическим top_k — это костыль, который либо не додает контекста, либо вызывает у модели информационное «ожирение» (заполняет контекст нерелевантным мусором). Нашему RAG нужно помочь адаптироваться к безжалостной среде разрозненных документов!

Я потратил выходные на то, чтобы решить эту проблему фундаментально. В итоге на свет появился DRAG with KNEE (Dynamic RAG with Knee‑point pruning) — алгоритм, который не просто ищет «похожее», а выстраивает иерархию документов и безжалостно отсекает лишнее с помощью геометрического анализа «колена». В этой статье я покажу, как с помощью Qdrant, Python и капли математики сделать ваш RAG адаптивным.

Существует стереотип, что современная наука об экзопланетах — это прерогатива NASA и ученых с миллионными грантами. Мы — команда обычных школьников и наш наставник — решили доказать, что для открытия новых миров достаточно ноутбука, Python и понимания того, что Машинное Обучение (ML) без физики — это просто генератор случайных чисел.

Это история проекта ExoLogica AI: путь от сокрушительного провала на конференции до создания гибридного интеллекта, который видит то, что иногда пропускают профессиональные телескопы.

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

Написать эту статью меня сподвигнул услышанный недавно краем уха разговор:

Всё началось с простой задачи: нужно было безопасно передавать файлы на обычных USB-флешках. Существующие решения либо создавали контейнеры (VeraCrypt), что неудобно для быстрого доступа к отдельным файлам на разных ОС, либо работали слишком сложно для конечного пользователя.

Мне нужно было решение уровня «вставил флешку -> ввел пароль -> файлы зашифрованы». Но главное требование — безопасность данных даже при сбое питания. Если выдернуть флешку посередине шифрования, данные не должны превратиться в кашу.

Так появился crypto_engine. Это не попытка изобрести свою криптографию (мы используем стандартные AES-GCM и ChaCha20), а инженерная работа над тем, как безопасно управлять ключами в памяти, обрабатывать гигабайтные файлы без переполнения RAM и гарантировать целостность данных.

Я работаю с LLM довольно давно и застал модели времен GPT-3.5, примерно в то же время мне нужно было сделать проект по учебе в этой области, тогда я выбрал именно тему шахмат, потому-что не видел конкретно таких решений раньше, конечно ИИ в онлайн шахматах и так был практически непобедим, но мысль сыграть конкретно с нейросетью уровня Chat GPT, мне показалась интересной. Основная проблема - заставить чат бот играть в игру и не делать ничего лишнего.

В этой статье я разберу архитектуру своего проекта: шахмат на Python, где в качестве соперника выступает LLM:

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

Когда речь заходит об обсерватории LIGO, большинство из нас вспоминает классический сценарий: где-то за миллиарды световых лет слились две черные дыры, и через миллионы лет детекторы на Земле зафиксировали гравитационный всплеск, длившийся доли секунды. В классической Общей теории относительности (ОТО) считается, что изолированная или просто поглощающая газ черная дыра гравитационно «нема». Она ничего не излучает.

Но что, если это не так? Что, если гравитационные телескопы способны «слышать» не только редкие катастрофические слияния, но и постоянный, фоновый гул от обычных черных дыр, которые прямо сейчас пожирают материю в нашей галактике? И что, если этот гул может рассказать нам о физическом размере объектов, внутри которых, как нам говорят, находится «бесконечная сингулярность»?

В этой статье я покажу, как концепция механики сплошных сред позволяет предсказать точную частоту такого резонанса. А затем мы откроем Python, подключимся к серверам GWOSC (Gravitational Wave Open Science Center), выкачаем гигабайты сырых тензорных данных LIGO и методами цифровой обработки сигналов (DSP) вытащим этот акустический след из шума.

Спойлер: мы найдем этот гул для трех разных черных дыр. И он совпадет с расчетным до десятых долей процента. Такого анализа (поиск непрерывного гравитационного резонанса от аккреции) еще никто не делал. Это буквально новый метод определения параметров черных дыр.