Python *

В наши дни все, кому было интересно, уже попробовали RAG, я в том числе. И стандартная схема тривиальна: цепляем LangChain, три импорта, .from_documents() — и бот с базой знаний готов. Мой первый опыт был такой же, и это даже заработало за один вечер.

Но как это поддерживать? А что случится, если всё полетит?

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

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

Разговор с Claude Code остаётся на той машине, где начат. Разбираю, почему облачная папка эту задачу не решает, и шесть граблей, на которые я наступил, пока делал перенос сессий, памяти и инструментов между Linux, Windows и macOS.

Год назад я написал статью «Переводим fb2 книжки, с нейронками, для себя» — про то, как собрал на паре Tesla P40 в гараже программу Sunny Narrator («Солнечный сказочник»), которая переводит художественные книги через локальные и облачные LLM. Тогда это был скорее прототип «доказать себе, что так можно»: черновики читались с головной болью, книга в тысячу страниц переводилась два дня, а электричество, отключённое посреди процесса, стоило ещё двух.

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

После того как мой пет-проект случайно «выстрелил» на Reddit, я решил, что пора поделиться так же и своей кроссплатформенной библиотекой на C++20 для мониторинга железа, с нативной поддержкой Python.

Рассказываю историю создания hardware_monitor_cpp: как избавиться от лишних зависимостей, получить адекватную статистику swap-файла под Windows и macOS, упаковать все в удобное C++ API, а заодно получить готовую консольную утилиту с визуализацией графиков прямо в терминале.

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

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

Этим зазором пользуются двумя способами, и оба закрываются одной проверкой.

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

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

Я уже думал писать статью, но решил мимолетом запустить 175 воркеров. Это решение создало неожиданную проблему - задача оказалась обработана за 11 секунд до ее создания.

Фраза «завтра в 18:00» кажется простой, пока сервер и пользователь не оказываются по разные стороны полуночи. В Doday я сделал быстрое добавление задач из одной строки и обнаружил, что программа считает «сегодня» по UTC. Из-за этого дата сдвигалась, а указанное время могло остаться в названии.

В статье покажу, как передать часовой пояс из браузера, в каком порядке собирать локальную дату и время, зачем фиксировать текущее время в тестах и какие ещё ошибки нашлись у фраз «через месяц», «каждый понедельник» и меток с @.

Когда нужно классифицировать текст, дефолтный ход в 2026 – взять предобученный трансформер и дообучить. TF-IDF воспринимается как музейный экспонат: работал в эпоху до BERT, сейчас не всерьез. Обычно этот выбор никто не проверяет на своих данных, потому что и так понятно, кто победит.

Мы решили проверить. Взяли одну задачу, один корпус, одну метрику и прогнали три подхода подряд: счетный бейзлайн на TF-IDF, сверточную сеть TextCNN и дообученный русский энкодер. Считали не только качество, но и стоимость – время обучения и скорость предсказания на обычном процессоре.

Короткий вывод: на этой задаче счетный бейзлайн обучается за три секунды и по честной метрике держится вровень с трансформером, который дообучался восемь минут. А трансформер, взятый по стандартному рецепту, сначала вообще проиграл – и проиграл поучительно.

Дальше – как так вышло и что из этого забрать себе.

Всем привет, меня зовут Евгений Тихонов я работаю в Банке Уралсиб, в дирекции по сопровождению комплаенс-систем, факторинга и электронных продаж. Я хочу рассказать вам о простом кейсе, который облегчил жизнь отдела разработки рекламных crm-кампаний.

Привет, Хабр! Пилю потихоньку пет‑проект и решил поделиться тем, что вылезло при первом же деплое.

Откуда взялась эта штука 

Основная занятость у меня связана с ИИ, но есть ещё подработки по 1С — в основном администрирование: обновления, настройка оборудования, выгрузки и прочее. Всё взаимодействие идёт в Telegram: множество чатов, в каждом свои задачи, у каждой свой дедлайн и своё техническое окно, когда её вообще можно делать. Базу не обновишь в разгар рабочего дня — значит, задача не просто «к пятнице», а «в пятницу после семи».

Пока задач несколько, они держатся в голове. Дальше начинается путаница: помнишь, что на этой неделе у кого‑то обновление, а у кого именно — уже нет. Я начал забывать про клиентов. Писал на бумажке. Бумажка не работает по простой причине: про неё тоже надо вспомнить. Она лежит рядом и молчит. А напоминание должно приходить само и туда, где я и так сижу целый день. Так и родилась мысль сделать свой блэкджек.

Спор «скобочки или отступы» старше, чем некоторые из его участников. У этого спора нет судьи и нет призового фонда, но есть ветераны и есть потерянные души, которые однажды написали end в Питоне и с тех пор не могут остановиться. Выиграть этот спор невозможно: стороны спорят о вкусах, а не о свойствах. Поэтому предлагаю - давайте закончим этот спор не победой, а разоружением.

Я написал маленькую утилиту, которая переводит исходный код Python между тремя синтаксисами: классические отступы, C-подобные фигурные скобки, S-выражения в духе Лиспа. Один и тот же quicksort, три вида:

Всем привет! Меня зовут Илья, я инженер-программист, но чаще пишу промпты вместо кода, что привело к некоторым артефактам, о которых ниже.

В данной статье я покажу, как интегрировать n8n с OpenWebUI, вайбкодить по делу и без, а также напомню о том, как найти идею, если кто не знал.

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

Задача была прикладная: мы переносим интернет‑магазины на свой движок и хотели понять, сколько в зоне .ru магазинов на каждой платформе и как их находить. Готовые сервисы вроде BuiltWith продают выгрузки по подписке, но нам нужен был воспроизводимый обход, который можно гонять когда угодно и по своим правилам.

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

Модель кредитного риска, обученная на данных до 2009 года, ранжирует займы с ROC-AUC 0.89. Ожидаемые потери портфеля она оценила в 161 млн долларов, реальные составили 546. Увидеть эту ошибку можно было еще в 2007 году, за год до дна ROC-AUC, но не в метриках качества, а взвесив ошибку модели деньгами. Ниже — прогон на 26.5 млн реальных ипотечных записей, метрики против денег. Числа воспроизводятся до последнего разряда — код движка и инструкции в опенсорсе.

Система работает и разбирает документы. Претензия у меня к ней одна, зато неустранимая изнутри: я не могу доказать ни одно из полученных значений.

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

В комментариях к прошлой статье сформулировали правило, под которым я подписываюсь обеими руками: «платить» за внепроцессный вызов имеет смысл тогда, когда сама работа дороже транспорта. clean_amount из квикстарта — десять строк, ноль зависимостей, микросекунды работы — этот порог не проходит. Свою задачу тот пример выполнил: показал механику publish/call в шесть строк. Но ноды существуют не для него: 2 + 2 через демон не нужно никому, и splime строился не для этого.

Возьмём случай, где оверхед оправдан, залезем под капот и посмотрим, что происходит между publish и call: где физически живёт нода, как Python‑функция превращается в переносимый объект и как две ноды передают друг другу данные, которым не место в JSON.

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

Всё, что ниже, проверено на актуальной splime 0.4.9.

Допустим, у тебя есть несколько AI-агентов. Один разбирает тикет, второй меняет код, третий запускает тесты, четвёртый готовит релиз.

Задача закрыта, тесты зелёные, артефакт собран. Метрика success_rate показывает успех.

Можно праздновать?

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

Финальное состояние корректное. Процесс — нет.

Именно эту проблему пытается измерить CoCoBench — новый бенчмарк для проверки координации нескольких AI-агентов. Его разработали исследователи из Нанкинского университета, Tsinghua и AgiBot.

Главная идея исследования полезна далеко за пределами робототехники:

Знакомая схема защиты от подмены. Сервер кладёт клиенту cookie user=guest&role=reader и рядом — подпись sha256(secret + данные), чтобы клиент не переписал reader на admin. Секрет знает только сервер, поэтому пересчитать подпись под изменённые данные клиент вроде бы не может.

Поломается не сама SHA-256, а конструкция вокруг неё: к данным можно дописать хвост &role=admin и предъявить к нему валидную подпись, не зная секрета вообще. Атака называется length extension, и в статье мы её проделаем на своём же сервере.

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

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

Пятьдесят дней назад планирование моих тренировок переехало из головы и переписки в телеграм-бота. Он читает восстановление из WHOOP и форму из TrainingPeaks, рассуждает через Claude и сам пишет структурированные тренировки обратно в календарь — оттуда они уезжают в Garmin Connect и на часы. За это время он записал в календарь 72 тренировки, а стоимость эксплуатации (дроплет, инференс, подписки) составила около 4 500 рублей в месяц против 30 000+ за живого тренера с теми же подписками на спортивные сервисы.

Официального доступа к TrainingPeaks у меня нет: в партнёрскую программу я написал и получил отказ без объяснения причин. В статье — как я всё равно научился писать в чужой календарь: обмен куки веб-сессии на bearer, GET-merge-PUT вместо несуществующего PATCH, поле, которое на чтении приходит объектом, а на запись требует JSON внутри JSON, и почему IF и TSS плановой тренировки приходится считать самому.

Вторая половина — про то, где это ломалось. Три отказа за пятьдесят дней, и ни один не был виной модели: устаревший в настройках пороговый темп, мой собственный баг с зонами не того вида спорта, один невалидный OAuth-scope, отбивавший запрос согласия целиком, и ответы, обрывавшиеся на полуслове из-за параметра, у которого «по умолчанию» значит разное у разных моделей. Плюс три дня, когда я был уверен, что агент зря меня бережёт, — а данные говорят, что прав был он.

Спортивного результата пока нет: до целевого марафона сто дней, но надеюсь на лучшее.