Python *

Всем привет! Я создал инструмент для разработки AIDD и назвал его Spawn. Это Python-утилита, которая помогает когерентно использовать несколько AIDD-методологий в одном репозитории — без ручной синхронизации правил, скилов и MCP-конфигов между ними.

Далее — краткое введение, затем я расскажу, как работает Spawn, как им пользоваться с клиентской точки зрения, как разрабатывать расширения, и приведу несколько примеров.

Многие ML‑инженеры знают, что нужно использовать CrossEntropyLoss, log_softmax и logsumexp. Гораздо меньше людей могут объяснить, что именно они спасают и почему без них обучение модели периодически превращается в генератор nan. Именно об этом и поговорим.

Каждый раз, когда нужно перекинуть файл, код или ссылку с ПК на телефон (или другу в той же Wi‑Fi сети), начинается классическая возня. Либо гоняешь через «Избранное» в мессенджерах (где режется качество и файлы вечно висят в облаке), либо поднимаешь локальные веб‑серверы через консоль. Мне это надоело, и я решил написать свою утилиту — FlashStash.

Основная идея: софт должен запускаться в один клик, работать без интернета внутри локалки, иметь всеядный предпросмотр файлов прямо в браузере и не требовать от пользователя установки Питона или настройки окружения.

После нескольких итераций проект дорос до версии 1.6, и я хочу поделиться тем, как устроена утилита изнутри и с какими техническими проблемами пришлось столкнуться.

В статье представлен разбор создания CRM-системы, разработанной с применением искусственного интеллекта для ускорения кодинга и архитектурного планирования. Проект представлен как будущий полигон для построения хорошего фреймворка для автотестирования с помощью Python.

Представьте: клиент зашел на сайт в полночь. Менеджер спит. Утром клиент уже забыл о вас и купил у конкурента. Обычный чат-бот не спасает: он либо тупой, либо безумно дорогой, либо хранит данные за океаном.

Я создал решение, которое решает эту проблему раз и навсегда.

Всем Q. А тем, у кого малиновые штаны много QqQq. Когда-то, n-лет тому назад, много и долго исследовал фракталы ...

Хорошего тренера узнают в лицо.

Как я создал и развиваю ИИ‑тренера привычек в Telegram: техническое описание проекта для гиков и нетехническое описание продукта для тех, кто хочет стать лучше.

DLQ — это просто топик. Сложное — всё, что вокруг него.

Эта статья — про практическую архитектуру обработки событий из Kafka с отправкой данных во внешний REST API.

Главная проблема такого сценария — нестабильность внешнего API. Он периодически деградирует по latency или начинает отвечать с ошибками, и это напрямую влияет на пропускную способность всего консьюмера.

В этой статье мы начинаем погружение в одну из фундаментальных тем цифровой обработки сигналов (ЦОС) — дискретное преобразование Фурье (ДПФ). Именно ДПФ служит математической основой для понимания более сложных методов спектрального анализа и является отправной точкой для изучения всех остальных видов преобразования Фурье в ЦОС. Будет рассмотрено ДПФ действительных сигналов.

Материал построен так, чтобы объединить теорию, наглядные графики и практический код на Python.

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

Краткое содержание статьи. Часть 1

В ней поэтапно разбираются фундаментальные понятия, необходимые для понимания ДПФ:

Аналоговые и дискретные сигналы — краткое введение, объясняющее разницу между двумя типами сигналов. В статье используются только дискретные сигналы, поэтому эта тема кратко рассмотрена.

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

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

Формула ДПФ — финальный этап, где все изученные понятия сводятся к классической формуле дискретного преобразования Фурье.

Привет! Я Влад Вандер, контент-маркетолог в Velmi. Ребята из команды рассказали мне, как автоматизировали отдел продаж и научили ИИ-бота квалифицировать лидов в Битриксе. В этой статье расскажу про это: от архитектуры до граблей, на которые пришлось наступить.

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

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

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

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

В одном из проектов этот узел был собран так, первый платеж создается с capture=False, входящий webhook проверяется по IP, каждое событие сначала пишется в журнал, потом маршрутизируется в обработчик, capture подтверждается стабильным idempotence key, успешный платеж валидируется по сумме, валюте и metadata, а на случай расхождения остается отдельный ручной confirm, который умеет дочитать фактический статус из ЮKassa и синхронизировать локальную базу.

То есть задача тут не просто принять webhook, а построить платежный контур, которому можно верить.

Смотрю на этот текст и понимаю, что все пользуются ИИ, просто кто-то это хорошо скрывает.

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

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

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

ИИ с такой первичной сортировкой может помочь. Но для этого ему нужно дать нормальные данные: таблицу, где есть номер закупки, заказчик, регион, наименование, цена, сроки, ОКПД2, ссылка и дополнительные поля.

Мне был нужен не просто “поиск на сайте”, а программа, которая создаёт Excel для последующей загрузки в ИИ и ручного анализа.

Так появилась идея сделать локальную программу, которая:

TL;DR: Привет, Хабр. С 2 по 12 мая я в режиме нон-стоп писал Doday — кросс-платформенный todo: web, Telegram Mini App, чат-бот. Получилось 317 коммитов, ~40 000 строк кода, 633 теста, 38 модулей в app/. Стек — FastAPI + HTMX + Alpine.js + Tailwind, без единой строчки React. Писал в паре с Claude Code, и не скрываю этого — расскажу как именно и какая часть кода реально моя голова, а какая — клавиатура. Грабли, цифры, ссылки внутри.

Разбираю, как я отделил жизненный цикл задачи от владельца следующего действия, чтобы AI-агент видел не просто список дел, а очередь: что можно брать в работу, что ждет человека, что требует ревью и что заблокировано.

Это продолжение первой статьи про Briefka — там я описывал самого бота и базовую архитектуру каскада LLM-провайдеров. За прошедшие 4 месяца бот органически вырос с 59 до 84 пользователей, и именно на этом масштабе бесплатный каскад начал срываться на платного провайдера. Расскажу, почему так вышло и как я вернул расходы к нулю — с цифрами и кодом.

Код ниже — реальные фрагменты из боевого Briefka, слегка сокращённые для читаемости: убраны логирование и сбор статистики.

В этой статье я шаг за шагом расскажу, как дообучить LLM под свою задачу. В качестве примера возьму open-source модель Qwen2.5-0.5B и дообучу её извлекать информацию из текста в формате JSON по заданной схеме. Сначала дам короткую вводную по этапам обучения языковых моделей, а затем перейдём к практике: подготовим данные, настроим LoRA, обучим модель в Colab и сравним метрики до и после — заодно проверим, насколько сильно модель забывает прежние знания. Рассказ будет сопровождаться кодом на Python.

MacBook M3, 16 ГБ, никакого облака. Поставил свежую Gemma 4, написал инструмент: кидаешь картинку с графиком или таблицей — получаешь CSV. Три кейса из семи — идеально. На остальных модель начала врать, причём аккуратнее, чем говорила правду: вместо рваных реальных чисел подсовывала гладкие выдуманные. Разобрал по шагам — сетап на маке, грабли с llama.cpp, сам инструмент — и собрал карту, где локальному зрению можно верить, а где оно тихо галлюцинирует

Привет, Хабр! Меня зовут Андрей, как и многие, я уставал от красных сообщений в консоли, где не видно значений переменных. Приходилось ставить print(), гуглить – терял кучу времени. Поэтому я написал crashprobe – библиотеку, которая делает отладку простой и наглядной.

В восьмой части мы завершили изучение SVM и разобрались с Kernel Trick. Теперь пришло время познакомиться с деревьями решений — одним из самых популярных и интуитивно понятных алгоритмов машинного обучения.

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