7 ошибок в оценке качества LLM‑систем в продакшене
Всем привет, меня зовут Сергей Прощаев и в этой статье расскажу про то, как команды теряют контроль над качеством своих LLM‑фич и что с этим делают инженеры, у которых это работает.Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E‑commerce и преподаю на курсах разработки и архитектуры в ОТУС.
Цена, которой не существовало: две недели поиска бага, который не видел мониторинг
Есть класс ошибок, которые невозможно найти простой сверкой. Не потому, что данные хорошо спрятаны, а потому, что искомого состояния нет ни в одной системе. Оно собирается на лету из двух правильных половинок, каждая из которых по отдельности абсолютно валидна.Хочу рассказать про случай, где искали причину две недели, но при этом мониторинг всё это время показывал, что всё в порядке, и формально он был прав.Оговорюсь сразу:
Звонок голосовому ИИ-агенту стоит 8 рублей: поставил счётчик и посчитал до копейки
В понедельник в 13:24 человек позвонил в небольшую производственную компанию, не дождался ответа и попал на голосового бота. Поговорил 27 секунд и положил трубку. Через пару минут перезвонил и на этот раз договорил до конца: рассказал, что нужно и в какой город, бот попрощался, а владельцу компании улетела SMS с карточкой заявки.
Поставил счётчик на каждый звонок голосового ИИ-агента: 13 сценариев экзамена и себестоимость до копейки
В понедельник в 13:24 человек позвонил в небольшую производственную компанию, не дождался ответа и попал на голосового бота. Поговорил 27 секунд и положил трубку. Через пару минут перезвонил и на этот раз договорил до конца: рассказал, что нужно и в какой город, бот попрощался, а владельцу компании улетела SMS с карточкой заявки.
Вы даже не поймете, что он сломан: почему панель мониторинга зеленая, а агент врет третий день подряд
Я давно привыкла первым делом спрашивать «а как это упадет?». Когда в наш ландшафт пришли ИИ‑агенты, выяснилось интересное: привычные ответы на этот вопрос здесь просто не работают. Агент в проде, дашборды настроены по классике: latency, error rate, uptime. Алертов нет, агент исправно отвечает на каждый запрос. А то, что он три дня подряд уверенно врет, вы узнаете из жалобы пользователя, и никак иначе.
ИИ ускорил разработку. Почему продакшен стал ломаться чаще
В этой статье поговорим о том, почему команды, ускорившиеся с помощью искусственного интеллекта, продолжают ломать продакшен — и что иначе делают те, у кого такой проблемы нет.Начну с ситуации, которая, скорее всего, уже с вами случалась.На прошлой неделе вы сделали пулл-реквест. Код, сгенерированный искусственным интеллектом, выглядел аккуратно: читаемый diff, тесты проходят, ничего явно подозрительного. Вы его одобрили. А через два дня в продакшене что-то сломалось так, как никто не ожидал.Если с вами такого пока не было, вам просто повезло. Я вижу это постоянно, и у таких случаев есть общий паттерн.
PAD+ AI v4.0: исследовательская когнитивная архитектура поверх LLM
Что происходит между запросом пользователя и ответом языковой модели?За последние несколько лет большие языковые модели совершили настоящую революцию. Сегодня они способны писать код, анализировать документы, помогать в исследованиях, создавать тексты и решать сложные задачи.Однако подавляющее большинство современных AI‑приложений имеют практически одинаковую архитектуру:Запрос → Prompt → LLM → ОтветВся интеллектуальная работа фактически сосредоточена внутри языковой модели, а внешняя система лишь подготавливает запрос и отображает результат.
10 дней спустя: как мой бот дважды умирал незаметно, а метрика релевантности мне врала
10 дней спустя: как мой бот дважды умирал незаметно, а метрика релевантности мне вралаTL;DR — продолжение прошлого поста про @futur_e_news_bot (двуязычная лента новостей на sqlite-vec за ~$5/мес). За 10 дней в проде: два тихих многодневных простоя (бот поллил Telegram и казался живым, но не создавал ни одной новости), метрика релевантности, которую отравил один человек 106 дизлайками, и сигнал от реакций 78 юзеров, который заставил выкинуть половину источников. Плюс — я открыл код (MIT)
Почему классический подход к QA больше не работает (и виновата ли в этом эпоха ИИ)
Я всё чаще замечаю, что разговоры о качестве программного обеспечения как будто застряли в прошлой эпохе. Мы по привычке обсуждаем тест-кейсы, регрессию, покрытие, приёмку перед релизом и автоматизацию проверок, как будто этого по-прежнему достаточно, чтобы уверенно говорить о качестве продукта. Но сама среда, в которой живёт современное ПО, уже давно стала другой.
Закон Конвэя внутри нас: инженерные системы ломаются по тем же причинам, что и люди
Linux пропитан магией. Тип файла определяется не по расширению, а библиотекой magic, которая смотрит на сигнатуру первых байтов. В системе живут демоны, процессы могут работать в режиме daemon, а исполняемые файлы хранятся в формате ELF и разбираются утилитой readelf. Это похоже на шутки старых разработчиков, но они появились не случайно.Инженерные системы наполнены метафорами, потому что так проще думать о сложном, объяснять невидимое и работать с тем, что нельзя потрогать руками. Со временем мы привыкаем к этой «магии» и перестаём замечать, что вместе с ней перенимаем определённый способ мышления.
