Python *

ИИ видео не подходят для инженерных задач, так как работают с пикселями и часто «галлюцинируют», искажая математическую логику и текст. Решение проблемы — разделить процесс: LLM должна генерировать не видео, а код (инструкции), а исполнять его должен детерминированный движок (библиотека Manim). Чтобы исключить программные ошибки, применяется цикл Self-Correction: скрипт автоматически скармливает трейсбэки обратно нейросети, заставляя её исправлять код до тех пор, пока он не скомпилируется в математически точную анимацию.

Когда мы пишем Python-код, обычно кажется, что программа существует сама по себе. Но на самом деле она постоянно взаимодействует с интерпретатором, операционной системой и окружением выполнения. Модуль sys — это как раз тот слой, через который Python предоставляет доступ к этим деталям.

Понимание sys полезно не только для утилит и CLI-программ, но и для отладки, настройки окружения и анализа поведения приложения.

Поиск аномалий под микроскопом: от базовой статистики до робастных моделей с нуля на NumPy В машинном обучении поиск аномалий (Anomaly Detection) часто остается в тени классического обучения с учителем. Однако именно эта «иммунная система» данных спасает миллионы долларов в финтехе, предотвращает катастрофы на производстве и находит критические ошибки в медицинских картах.

В этой статье мы не просто импортируем готовые методы из sklearn. Мы разберем математическую логику трех мощных подходов, напишем их «примитивные» реализации на NumPy/Pandas, чтобы понять механику работы «под капотом», и проверим их в деле на реальном кейсе.

Наш полигон: Credit Card Fraud Detection
Для тестов мы возьмем классический датасет Credit Card Fraud Detection. Это идеальный пример «иголки в стоге сена»: здесь всего 0.17% мошеннических транзакций среди почти 300 тысяч записей. Смогут ли наши рукотворные алгоритмы их найти?

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

IQR (Interquartile Range): Статистическая классика. Узнаем, как «усы» боксплота помогают находить грубые выбросы.

Isolation Forest: Оригинальный подход, основанный на идее, что аномалию проще всего «изолировать» случайными разрезами пространства.

Elliptic Envelope: Тяжелая артиллерия робастной статистики. Будем строить многомерный эллипс, который игнорирует попытки аномалий исказить его форму.

Тест LLM‑модели qwen3‑coder‑next:q8_0: модель успешно построила карту большого форума, собрала все сообщения в JSON и преобразовала их в готовый SQL‑дайджест, показав высокое качество генерации кода, но «залипла» при решении чисто логической задачи.

Привет, Хабр! Эта задача выглядит как разминка для разогрева: найти максимальное произведение двух чисел в массиве. Но именно с неё началось моё знакомство с алгоритмической культурой — на первом же собеседовании я убедился, что «работает» и «работает эффективно» — разные вещи. В статье — три решения: от интуитивного до элегантного, их сравнение и главный вывод: даже простые задачи учат нас думать.

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

Привет, Хаброжители!

От выбора подхода к поглощению данных может зависеть успех или провал работы конвейера данных

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

Добрый день. Сегодня я расскажу о том, как я за 2 месяца с полного нуля создал доменную RAG систему с корпусом в 20+ книг.

В статье затрону проблемы парсинга данных (особенно PDF документов, с которыми приходилось иметь дело), чанкинга, создания и индексации эмбеддингов, а также самого интересного – ретривера. Расскажу о latency, трейд-оффах, и сложностях реализации подобных систем локально на ноутбуке (хоть и «игровом») без использования API LLM.

Вся система делалась мной самостоятельно без использования LangChain – это чистый пайплайн от Tesseract, Pillow, MuPDF/Fitz до e5-multilingual, FAISS (+bm25, который я затрону в статье) и Qwen3:8B в качестве LLM.

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

В этой статье я хочу поделиться опытом разработки пет-проекта, который превратился в полноценный инструмент для автоматической генерации коротких видео (Shorts, Reels, TikTok). Идея проста: на входе — тема (например, "История Римской Империи за 1 минуту"), на выходе — готовый видеоролик с озвучкой, субтитрами и сгенерированным видеорядом.

Но вместо того, чтобы накидать "спагетти-код" в одном файле main.py, я решил подойти к задаче как инженер и построить систему на принципах Clean Architecture.

🎯 Зачем?

Генерация видео — это сложный пайплайн:

1.  Написать сценарий.

2.  Придумать визуальный стиль.

3.  Сгенерировать картинки (Midjourney, Flux).

4.  Оживить картинки в видео (Kling, Runway, Sora).

5.  Озвучить текст (TTS).

6.  Собрать всё вместе с субтитрами.

API меняются, модели выходят новые каждую неделю. Сегодня лучший визуал у Flux, завтра у Midjourney v7. Сегодня видео делаем в Runway, завтра в Kling. Жесткая привязка к конкретным API убила бы проект через месяц.

Поэтому Clean Architecture здесь не роскошь, а необходимость.

🏗 Архитектура

Проект разбит на слои, следуя классической "луковой" архитектуре:

1.  Domain (Entities): Pydantic-модели, описывающие суть (VideoScript, Scene, Character). Они ничего не знают о внешнем мире.

2.  Interfaces: Абстрактные классы (VideoGenerator, ScriptGenerator). Контракты, которые должны соблюдать внешние сервисы.

3.  Services (Use Cases): Бизнес-логика. Здесь живут "Агенты": Сценарист, Арт-директор, Режиссер монтажа.

4.  Infrastructure: Реализации интерфейсов (API клиентов Comet, Yandex, OpenAI и т.д.).

Game Engine 3 - 2D движок с открытым исходным кодом с визуальным редактором на основе нодов, которые позволяют создавать приложения без написание кода

Программист часто копирует и вставляет, переименовывает и рефакторит. Выделил (подсветил) мышкой переменную или функцию и вот бы сразу видеть их количество в статусной строке. Увы, стандартный поиск (Ctrl+F) требует лишние клики.

Мой небольшой Python-скрипт для Notepad++ по дабл-клику
отображает в Status-Bar количество вхождений,
частичных или полных, с учетом регистра и без.

Много раз проскакивало желание у многих получить простой инструмент, позволяющий следить за истекающими сертификатами SSL. Ниже представляю инструмент для самостоятельного развертывания в среде docker.

Код написан для python14, но работать будет и на других версиях (12, 13, 14 и т.д.).

Что включает проект (все в одном):

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

Можно, конечно, заранее срезать количество извлекаемых чанков, но это отразится на качестве ответов.

Можно настроить кэш, который экономит на обращениях к сервису, когда приходят одинаковые вопросы. Но когда пользователь спрашивает "How to get developer support?”, и тут же другой пользователь спрашивает "How to ask development-related questions?", ваш сервис каждый раз будет генерировать ответ заново, сжигая ваши токены и заставляя пользователя ждать. Обычный кэш тут бессилен: для него эти две фразы — абсолютно разные ключи. 

В этой статье я расскажу, как развернуть мощный семантический кэш на базе AlloyDB Omni (PostgreSQL от Google), используя векторный поиск ScaNN, автоматическое партиционирование и планировщик задач. Мы пройдём путь от настройки Docker-контейнера до продакшн-архитектуры.

Пролог: Почему бизнесу нужна эволюция, а не революция

Представьте сцену: Вы запускаете первый ИИ-агент для поддержки клиентов. Первые две недели — восторг. "Он отвечает! Он работает!" Месяц спустя — разочарование. "Он повторяет одни и те же ошибки. Не умеет работать со сложными запросами. Требует постоянного контроля".

Знакомо? Это классическая история "пилотного проекта, который не масштабируется".

Моя команда прошла этот путь. Мы потратили 18 месяцев на эволюцию от примитивного бота до системы, которая:

Самостоятельно обрабатывает 85% сложных запросов

Снизила операционные затраты на 40%

Еженедельно улучшает свои показатели на 3-5% без вмешательства разработчиков

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

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

Этот проект — моя попытка пройти весь путь: от токенизации текста до генерации кода. Не используя готовые решения от HuggingFace, а реализуя каждый компонент самостоятельно. И знаете что? Это оказалось одновременно сложнее и интереснее, чем я предполагал.

Мы все видим, как ассистенты и агенты меняют правила игры. То, что недавно называли «умной IDE» с подсказками, рефакторингом и статическим анализом, сегодня лишь разминка перед сбором функциональности. Ассистенты и агенты могут пройтись по десяткам файлов, обновить тесты и даже оформить базовую документацию. Но вместе с бешеной скоростью генерации пришёл и хаос. 

Поговорим о том, как не дать «вайб-кодингу» развалить ваш продакшен и почему Spec-Driven Development (SDD) — это наш новый «компилятор», которому нужно доверять.

У нас в компании был один проект, с которым я не справился.

Дело было так: мне сообщили, что знакомый плюсовик написал какой-то скелет проекта на питоне, а теперь мне надо его допилить, подставив в нужные места реализации. Почему тогда делал он, а не я, а сейчас должен делать я, а не он? Да чёрт его знает. Но я подумал, что смогу — унаследуюсь и переопределю методы где нужно, подставлю зависимости во всякие DI, ну что там может быть плохого?

Оказалось, что плохо вообще всё.

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

Недавно мне дали черновик статьи на редактуру, чтобы я её подправил где считаю нужным. А статья-то оказалась как раз про тот самый проект — автор рассказывал, как он классно всё написал. Вы даже не представляете, как сложно писать дифирамбы проекту, который настолько плох и полон антипаттернов, что можно собрать по нему целую статью. Так, подождите-ка, а что если...

Короче, вот она — анти-статья, собранная из того проекта. А где мне не хватало примеров, я брал код из Django, потому что он вообще полностью собран на антипаттернах.

Я инженер ОВиК, и меня достало каждый день гуглить перевод кгс/см² в бары. Универсальные конвертеры не знают про Гкал/ч и кгс/м², а инженерные калькуляторы — платные или с рекламой. Написал своё Android-приложение на Python/Kivy: 10 категорий, 60 единиц измерения (включая все инженерные), 5 калькуляторов (скорость в трубе, тепловая мощность с гликолями, расширительный бак по СП 60.13330, потери на клапане, площадь изоляции). Работает полностью офлайн, бесплатно, без рекламы. Рассказываю как сделал, с какими граблями столкнулся и как выложил в RuStore.

Кэш-монтирование в Docker — это мощный инструмент, который может значительно ускорить процесс сборки образов в CI/CD. Но его правильная настройка в GitLab требует понимания не только работы BuildKit, но и особенностей взаимодействия с различными конфигурациями GitLab Runner — DinD и DooD.

В этой статье я расскажу об устройстве кэш-монтирования в Docker и как его использовать в GitLab CI/CD. На примере простой сборки Python-проекта покажу готовые решения для кэширования зависимостей, чтобы оптимизировать сборку Docker-образов.

Выбор фреймворка для глубокого обучения — это стратегическое решение, влияющее на скорость разработки, стоимость и масштабируемость. Правило «PyTorch — для исследований, TensorFlow — для продакшена» больше не работает. К 2026 году оба фреймворка активно заимствуют лучшее друг у друга: PyTorch наращивает промышленные возможности (TorchServe, ExecuTorch), а TensorFlow с Keras 3 становится гибче для исследований.

Согласно опросу Stack Overflow Developer Survey 2024, PyTorch (10,6%) и TensorFlow (10,1%) находились примерно на одной отметке по частоте использования у разработчиков, а в исследовательских и AI-first-компаниях уверенно лидирует PyTorch. Но есть нюансы.