Python *

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

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

Рассмотрим следующую задачу:Дан постоянный магнит некоторой формы и нужно получить аналитическое выражение для его магнитного поля B в трёхмерном пространстве.Разберём несколько случаев.Будем считать магнит однородным.

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

Однако, какой бы ни была архитектура, все их объединяет одна и та же проблема — данные. Для полноценного обучения нужны сотни и тысячи изображений, с разных ракурсов, в разных условиях. Если цель — академический проект, обнаружение машин или колосков пшеницы, то найти датасет не составляет проблем. Но что, если датасета нет и/или его невозможно собрать в принципе в нужном объеме? Скажем, редкий дефект в производстве, истребитель новой конструкции? Ждать, пока накопится много брака, или надеяться на утечку чертежей?

Мы провели пару экспериментов с моделью YOLO для проверки гипотезы: как далеко можно уехать, используя исключительно синтетические данные?

Когда я начал развивать Discord-сообщество, обычной команды /ban хватило совсем ненадолго. Роли настраивались в одном месте, приветствия — в другом, логи — в третьем, а за уведомления о стримах отвечал отдельный бот.

GPU-версия ByteTrack, где математика всех камер считается общими батчами: один вызов на все потоки вместо трекера-на-камеру. На 16 потоках это ускоряет трекинг в 6 раз (104 → 17 мс/кадр на RTX 4090). А за первой, «наивной» версией пряталось всего 1.2x — почему, показали три антипаттерна PyTorch, на которых легко застрять и вне трекинга: GPU-вызовы в цикле, заливка кадров на 1.6 ГБ/с вместо 25, и FP16, который тихо съедал по 300 мс на кадре. Все цифры воспроизводимы, есть сравнение с NVIDIA DeepStream и открытый код.

Claude Code, Codex, Gemini CLI — мощные штуки. Но живут они в терминале: вы открываете окно, печатаете задачу, смотрите, как агент думает, лезет в файлы, гоняет тесты. Для человека — отлично. А теперь представьте, что в это кресло перед терминалом нужно посадить не человека, а вашу программу: чтобы она сама ставила агенту задачу, видела каждый его шаг и могла остановить опасное действие до того, как оно случится.

Вот тут и начинается ACP — протокол, который позволяет любому коду управлять CLI-агентом.

💾 MinIO, MongoDB, PostgreSQL для хранения 25 лет истории стоимости акций

Когда строишь эмулятор для проверки торговой стратегии 20 акций на 25 лет исторических данных поминутно, выбор хранилища становится архитектурной задачей. В статье разобрал, почему попытка использовать MinIO не оправдала себя, где упирается MongoDB и как PostgreSQL с Pgpool-II и read-репликами сократил время чтения одной свечи с 40мс до 10мс

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

Привет, Хабр! Меня зовут Владимир, и это вторая часть цикла статей по написании и обучению небольшой decoder-only LLM с нуля. В первой части мы вытащили текст, обучили Byte-level BPE токенизатор и собрали pretrain-датасет. Теперь напишем сердце модели - трансформер.

Чтобы AI-агент понимал инженера, индустрия предлагает поставить между ними еще одну большую языковую модель. Мы поставили модель на 34 млн параметров, в несколько десятков раз меньше, и она справляется лучше.

Секрет в данных. 200 тысяч пар «формулировка задачи → элемент КОМПАС API», где негативные примеры подбирались специально коварные: одноименные методы разных интерфейсов, соседние get/set одного свойства, кандидаты, которых базовая модель ошибочно ставила на первое место. Дообучение заняло меньше пяти часов на одной видеокарте, а Hit@5 на запросах, где метод описан задачей, а не именем, вырос с 5,8% до 79,6%.

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

В статье реальные логи, метрики трех бенчмарков, включая неудобные для нас, и объяснение, почему в продакшен пошла именно первая версия модели, а не две следующие.

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

В предыдущей статье я описал процесс компиляции модели yolo8n в HEF-файл для нейрочипа HAILO-8L в модуле HAT+. В этой работе я оцениваю быстродействие инференса нескольких моделей YOLO для этого же чипа.

Добрых дней, товарищи хабравчане! Изначально я писал этот текст как конспект по асинхронности в пайтоне для самого себя, потому что вещь эта довольно хитрая и не хотелось бы в будущем растерять и забыть знания о ней, когда буду работать с другими языками программирования и фреймворками. Но потом решил попробовать переделать это в формат статьи и опубликовать, потому что сами знаете — когда кому‑то объясняешь, сам начинаешь лучше понимать. Очень надеюсь на конструктивную критику в комментариях, так как хочу сделать эту статью хорошим пособием для новичков или просто людей, которые хотят повторить и закрепить фундаментальные концепции, потому что без их понимания никуда. Итак, приступим.

Асимптотика на практике: Сравнение алгоритма сортировки вставками и выбором

Автор: Шуравин Александр, к. т. н., доцент, в IT более 20 лет.

Введение

В теории алгоритмов мы привыкли оперировать абстракциями: O(n²), O(n log n), O(1). Но что скрывается за этими обозначениями в реальном продакшене? Насколько критичен выбор алгоритма для вашей системы?

В этой статье я исследую два классических алгоритма сортировки — сортировку выбором (Selection Sort) и сортировку вставками (Insertion Sort) — на трёх типах входных данных:

1. Случайный массив.

2. Уже отсортированный массив (best case).

3. Массив, отсортированный в обратном порядке (worst case).

 Эксперимент проведён на Python с замером времени выполнения для размеров массива от 100 до 1000 с шагом 100.

Теоретическая справка

Сортировка выбором (Selection Sort)

Идея: На каждой итерации находим минимальный элемент в неотсортированной части массива и меняем его с первым элементом этой части.

История о том, как сервис логирования Discord-серверов прошёл путь от сложной связки MySQL + PHP + Python до простого решения на Python + SQLite в одном Docker-контейнере — и почему упрощение стека того стоило.

«Честный Знак» накрывает всех: как не платить по несколько тысяч рублей в месяц за готовые облачные решения, если у вас небольшие тиражи. Рассказываю, как я написал (а точнее навайбкодил) собственное веб-приложение на Python/Flask для учета товаров и автоматизации работы с КМ (кодами маркировки), чтобы упростить складской учет и не сойти с ума от бюрократии.

У меня есть функция. Крошечная - десяток строк, которые приводят суммы из платёжек к нормальному виду: "1 234,50 ₽" превращают в 1234.5. Ничего гениального. Но я писал её, кажется, раз пять. В парсере банковских выписок, в импортёре заказов, в отчёте для бухгалтерии, в скрипте, который потом выкинул, и ещё где-то, о чём уже забыл.

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

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

Задача звучала как на полчаса: пусть Яндекс.Станция сама произносит вслух сообщения из Telegram-канала, без обращения к Алисе. По факту — несколько вечеров, потому что Яндекс не даёт из коробки простой возможности “скажи произвольный текст по внешнему событию”. Прошёл два тупика (виртуальные устройства и локальный TTS) и собрал рабочий пайплайн на Home Assistant + webhook. Рассказываю весь путь, включая то, что не сработало — тупики тут поучительнее итога.

Ни для кого не секрет, что IoT‑устройства собирают огромное количество информации, в том числе личные данные пользователей и фиксируют их местоположение. А также они жёстко привязаны к конкретному производителю, т.е. пользователь зависим от конкретного производителя или бренда. Гаджеты совместимы с парой основных систем, но кроссплатформенность отсутствует. Устройства разных производителей часто не могут взаимодействовать друг с другом без дополнительных шлюзов. Универсального протокола связи устройств тоже нет. Из стандартов: Zigbee, Matter, Z‑Wave, Bluetooth, Wi-Fi — как следствие умные устройства плохо дружат между собой.

Наверное, как и многие обитатели Хабра, весной я попал под волну сокращений. Погрустив над текущей ситуацией на рынке, решил попробовать себя в open‑source. В конце концов, есть запас денег, отсутствуют (тьфу‑тьфу‑тьфу) ипотеки/кредиты, да и всегда хотелось почувствовать себя частью чего‑то большего, что ли. Спустя пару месяцев у меня получилось стать мейнтейнером в небольшой ML‑библиотеке, о чём и хочу сегодня рассказать.