Продолжаем рассмотрение, того как правильно оценивать качество ИИ систем, в данной части поговорим о двух крайне полезных метриках: одна универсальный способ оценить, что LLM отвечает правильно, вторая для задачи суммаризации текста. На примере библиотеки RAGAS, с разбором того, как эти метрики работают изнутри.
Маленькая компания, человек 20. Гендир тонет в задачах. Помнить кто что обещал, отслеживать движение по целям, держать в голове десяток проектов одновременно. У больших корпораций для этого есть штат руководителей среднего звена и проджектов. У малых есть один директор, который пытается быть всем сразу.
Лира берёт на себя часть этой работы. Это не корпоративный чат‑бот, не ChatGPT с настройками компании. Конкретный продукт с конкретными функциями:
Как соединить LLM-агента на AG2 с Dishka в одном DI-контейнере. На рабочем примере: FastAPI + SSE-стрим по AG-UI + Postgres, тулзы с типизированным внедрением сценариев, отдельная транзакция на каждый tool call. Плюс грабли при сборке.
Инженерия качества: Как перестать надеяться на удачу и начать измерять своих ИИ-агентов [Часть 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.
Я делал AI Review как простой инженерный инструмент. Но реальный фейл оказался не в архитектуре и не в LLM — а в том, чего люди от него ждали.
Продолжаем разбираться с тем, как научить 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 и опишу свои впечатления и даже выложу пример звучания.
