Инженерия качества: Как перестать надеяться на удачу и начать измерять своих ИИ-агентов [Часть 1]
LLM глючит в продакшене? 🤖 Хватит надеяться на «vibe-check»! Узнай, как внедрить инженерный подход к качеству ИИ-агентов. В статье, будет рассмотрена концепция Golden Set, его автоматической генерации для RAG системы, на примере библиотеки RAGAS
Приветствую всех читателей Хабр.
Думаю, многим знаком этот сценарий: появляется задача — и первая мысль: «скормлю все LLM, она разберётся». Поначалу получается красиво, всё работает и есть первые результаты. Потом начинаешь проверять детали и замечаешь, что модель местами добавляет текст от себя. Потом смотришь на затрачиваемое время и понимаешь, что при текущей скорости обработка всего объёма документов закончится через год.
Именно в такой ситуации я оказался, когда захотел обработать базу ГОСТов.
Эта статья — про то, как я прошёл путь от «кидаем всё в LLM» до детерминированного пайплайна на классических NLP-инструментах. И про то, как в этом помогли те же самые языковые модели — но уже в роли консультантов, а не рабочей лошадки.
Продолжу цикл про память и мозг. И сегодня поговорим о том, как простая математическая модель, придуманная японским физиком полвека назад, помогает нам понимать тонкости синхронизации. Нам всегда говорили пример с синхронизацией, в котором рота солдат идет по мосту специально "не в ногу", чтобы эта пресловутая синхронизация не наступила. Посмотрим примеры кода и почему синхронизация важна.
Поехали!
Я устал разбирать длинные видео, голосовые и кружки в Telegram вручную. Сначала это было терпимо, потом каналов стало больше двадцати — и контент просто перестал помещаться в день.
Так появился Sumify: бот, который сам достает главное из медиа и превращает его в выжимку, конспект и ответы на вопросы.
Если что такое параллелизм более-менее все разработчики понимают, то объяснение асинхронности через аналогии с кассирами/поварами вредно, так как вводит в очень большое заблуждение.
В данной статье я разберу эту проблему на примерах Python и Go и попробую дать свою правильную аналогию.
Работа инженера-конструктора, помимо творчества, порой заставляет заниматься рутинными задачами, которые отнимают время, силы. Столкнувшись с постоянным формированием необходимых архивов с деталями, я решил автоматизировать этот процесс и для себя, и для коллег, написав простенькую программку.
В этой статье поделюсь своим опытом и намеченными планами.
Если в проекте появляется выбор LLM, почти сразу возникает соблазн сделать это как можно проще. Взять один большой список моделей, показать его в интерфейсе, выбрать первую free-модель по умолчанию и считать задачу закрытой. На короткой дистанции это выглядит рабочим вариантом. На длинной начинает ломаться сразу в нескольких местах.
Часть моделей числится бесплатными, но отвечает нестабильно. Часть внезапно исчезает из выдачи провайдера. Часть формально жива, но по качеству ответа годится только для демо. Иногда пользователь выбрал одну модель, а провайдер вернул ошибку. Иногда ответ пришел, но уже от другой модели. Иногда список моделей на фронте устарел, а backend уже живет в другой реальности.
То есть проблема тут не в том, как красиво показать список LLM. Проблема в том, как построить агрегатор, который умеет выбирать живые free-модели, переживать сбои провайдера и не врать интерфейсу о том, какая модель реально ответила.
В одном из своих проектов эта задача решалась не через бесконечный каталог моделей, а через более жесткий инженерный контур. Backend получает сырой список моделей от провайдера, очищает его, отбирает только подходящие free-варианты, оставляет по одной модели на бренд, отдает этот набор на фронт, а во время реального запроса умеет сделать fallback на модель другого бренда. При этом в ответе возвращается не только текст, но и actual_model, чтобы интерфейс знал, кто реально сгенерировал результат.
Немного погрузимся во внутреннее устройство Apache Airflow и разберёмся, что на самом деле происходит за красивым синтаксисом TaskFlow API. Посмотрим, как работают декораторы @task и @dag, каким образом обычные Python‑функции превращаются в задачи Airflow и за счёт какой «магии» строится граф зависимостей. А заодно напишем собственный мини‑пример, чтобы лучше понять архитектурные идеи, на которых построен современный Airflow.
На каждом ревью найдётся кто‑то, кто спросит: «Зачем четыре файла, если это один пайплайн?»
А затем, давайте объясню!
Вот есть Postman-коллекция из 40 запросов. Разложена по папкам, и с тестовыми скриптами, которые проверяют статус-коды. Вы потратили на неё время, она хороша.
И ещё у вас есть CI-пайплайн, который про Postman никогда не слышал и слышать не собирается.
Эти две вещи мирно сосуществовали месяцами, потому что никто не хочет быть тем человеком, который вручную переписывает 40 запросов в pytest-функции. Newman, конечно, есть, но Newman гоняет тесты, а не генерирует код, который можно прочитать, отредактировать и нормально положить в систему контроля версий.
Получается, коллекция документирует API. CI тестирует API. Они описывают одну и ту же систему и при этом никогда не встречались.
Я написал postman2pytest, чтобы их познакомить.
Telegram теперь полноценный OpenID-провайдер: oauth.telegram.org, JWKS, JWT, claims. Туториалы на GitHub при этом массово показывают старый виджет с HMAC от bot-token и /setdomain в BotFather. Я разобрался с новым флоу и собрал PoC на Python — рассказываю, как устроен обмен между фронтом, Telegram и бэком, чем Login library через telegram-login.js отличается от manual OIDC code flow с PKCE, что настраивать в BotFather (спойлер: не в чате, а в его mini-app), как протестировать локально через ngrok, и какая проверка id_token нужна вместо ручного HMAC.
Продолжаем разбираться с тем, как научить ROS2 понимать ваш язык программирования. В прошлый раз мы рассмотрели создание и запуск минимальной программы, теперь поговорим про работу с сообщениями. Свою библиотеку я разрабатывал для Lua, поэтому далее в примерах будет встречаться упоминание этого языка.
Обмен данными играет в ROS2 ключевую роль. К счастью, практически все задачи, связанные с передачей и приемом сообщений берут на себя библиотеки rcl и rmw, нам «всего лишь» необходимо обеспечить возможность их создания и обработки.
Структура сообщения в ROS2 описывается в файле с расширением msg или idl. При сборке пакета выполняются следующие действия:
Navisworks хорошо находит BIM‑коллизии, а Revit — инструмент для исправления. Но между ними часто остаётся хаос: XML и HTML‑отчёты, Excel, переписки, ручной поиск ID и вопросы руководителей в стиле «ну как там с коллизиями?».
Я расскажу, как из этой боли вырос внутренний web‑сервис Clash Analytics: импорт XML‑отчётов Navisworks, аналитика по проектам, история коллизий, статусы, комментарии, назначение отделам и локальный Revit Bridge, который открывает проблемное место в модели за один клик.
Нагрузочное тестирование — одна из самых избегаемых тем, когда речь заходит о контроле качества ПО. Корпорации, конечно, не обходят его стороной, но если говорить о продуктах меньшего масштаба, то нагрузочное тестирование часто пропускается. Команда (и, в целом, справедливо) полагает, что продукт справится с нагрузкой — на малых объёмах это обычно прокатывает. А потом внезапно наступает день, когда пользователей стало больше, а система не готова.
Почему команды не тащат нагрузку в релизный цикл? Потому что это чаще всего просто не окупается: нужно выбрать движок, описать сценарий, гонять тесты вручную или тратить время на создание собственной обвязки для встраивания в CI, придумать критерии качества и анализировать результаты. Всё это занимает значительное время, а на короткой дистанции часто оказывается оверинжинирингом. Но если формирование требований упростить концептуально невозможно, то всё остальное вполне можно собрать в переиспользуемый инструмент, позволяющий командам легко интегрировать нагрузочное тестирование и регрессионный анализ в свой процесс доставки.
В CI/CD мы хотели простую штуку: на каждый PR запускать короткий перф‑смоук и получать ответ уровня «PASS / WARNING / DEGRADATION», а не 15 минут медитировать над CSV и тратить ценное время на анализ, который, вероятно, не пригодится в ближайшей перспективе.
Самая дорогая ошибка моего B2B SaaS имела ровно одну строчку
Самая дорогая ошибка моего B2B SaaS имела ровно одну строчку: TENANT_ID = “tenant-1” в config.py. Полтора дня поиска бага показали, почему multi-tenant архитектуру нужно закладывать с первого коммита. Разбор трёх архитектурных решений для multi-tenant SaaS в регулируемой отрасли — tenant_id helper, PostgreSQL EXCLUDE USING gist против double-booking, 152-ФЗ как код на FastAPI и SQLAlchemy.
Статья о том как я пришёл к DIY (самодельному по нашему) гитарному процессору. Пользуюсь им последние пару лет, с двумя разными прошивками. Расскажу как допиливал что не хватало, в том числе с помощью LLM и опишу свои впечатления и даже выложу пример звучания.
В Python всё — объект. Но как язык понимает, что делать при сложении двух классов через +, вызове len() или обращении к несуществующему атрибуту? Вся магия скрыта под капотом dunder-методов. Мы собрали полный гайд для разработчиков любого уровня: от правильной инициализации и перегрузки операторов до создания собственных дескрипторов, контекстных менеджеров и жесткой оптимизации памяти через slots. Никакой воды, только практика, живые примеры и то, что реально спрашивают на собеседованиях.
TL;DR: Я создал BarkingDog — ИИ-сканер безопасности с открытым исходным кодом для Telegram-ботов и веб-приложений на базе LLM. Затем я натравил его на реального, широко используемого опенсорсного Telegram-бота.
Он написал работающий кейлоггер. Подтвердил, что отбеливатель лечит COVID-19. Выдал пошаговую инструкцию по взлому корпоративной сети с указанием конкретных хакерских утилит.
Затем я пропатчил системный промпт. Оценка: 97/100. Никакой смены модели. Никаких изменений в коде. Всего шесть строк текста.
На первый взгляд миграция из Kaiten в Bitrix24 выглядит как обычная интеграционная задача: прочитать данные из одного REST API и записать в другой REST API.
Но это впечатление быстро проходит, когда начинаешь переносить не демо-доску, а живую проектную систему.
В Kaiten уже накоплены пользователи, пространства, карточки, комментарии, файлы, ссылки внутри описаний, пользовательские поля, стадии, архивные задачи, связи между карточками и исторический контекст работы команды. Если перенести только названия карточек, формально миграция состоится. Но для бизнеса это будет потеря памяти.
В нашем случае нужно было перенести данные из облачного Kaiten в коробочный Bitrix24 так, чтобы команда смогла продолжить работу уже в новом контуре: с группами, задачами, файлами, комментариями, правами доступа и понятной структурой.
В этой статье расскажу, как мы построили мигратор на Python, где помог асинхронный подход, почему маппинг ID оказался центральной частью архитектуры, какие ограничения обнаружились в коробочном Bitrix24 и почему часть задач пришлось решать не только через REST API, но и через отдельные серверные скрипты.
Репозиторий с кодом: https://github.com/vlikhobabin/kaiten-to-bitrix
Всем привет!
Не знаю, как вы, а я всегда жду новых обновлений Bot API от Telegram. Мне любопытно, что же такого нестандартного нам подкинут в этот раз. Иногда они радуют, как в случае с недавним добавлением цветных кнопок, а иногда откровенно расстраивают, когда весь апдейт сосредоточен на мишуре вроде подарков. Однако обновление, которое выкатили разработчики на этот раз, оказалось поистине неожиданным.
Вчера был представлен релиз Bot API 10.0, который вносит, я бы сказал, серьёзнейшие изменения в саму механику работы ботов и их взаимодействие между собой. Давайте разберём это обновление подробнее.
Если вам интересны подобные материалы и разработка в целом, подписывайтесь на Telegram-канал «Код на салфетке».
