Что же делать с управлением качеством GenAI систем

Три года назад все и их мамы стали промпт инженерами. Потом все эти промптинг трюки отжили свое, а мы, засучив рукава, занялись context/harness/specs инженерингом и побежали разворачивать MCP. Сейчас Борис Черный утверждает, что это все снова пройденный этап, и нам надо учится луп-инженирингу. Жизнь кипит, только успевай за этим паровозом: это и фаново и сулит большой аплифи т от внедрения в работу. Ну мы и внедряем.

И на все это смотрят СТО и владельцы бизнес процессов и задаются вопросом «а это вообще будет нормально работать?». И на мой взгляд это самый главный вопрос внедрений GenAI: как измерять и управлять качеством получившихся продуктов. Потому что в этой кроличьей норе много ньюансов:

1/ human-in-the-loop
То с чего начинались все внедрения GenAI, и на первый взгляд самый надежный способ контроля и управления качеством. Каждая единица контента/решение проходит через человека. Но есть две проблемы. Во-первых HitL убивает львиную долю эффекта от агентизации. Во-вторых встает в полный рост вопрос ответственности проверяющих. Все, кто управлял службами контроля качества знают, что такая монотонная активность притупляет внимание, и люди совершают много ошибок. Да и очень сложно держать замотивированными квалифицированных людей на такой работе (спросите любого кодера, любят ли они код ревью?). Сильно хуже ситуация, если контент LLM может давать отложенные эффекты. Например плохо написанный код может отстрелить не сразу. И эти инциденты могут наслоиться друг на друга в произвольный момент, что делает всю систему хрупкой. Так что вопрос ответственности за контент, созданный LLM, и мотивации встанет в полный рост и должен стать ключевым фокусом внедрятора.

2/ эвалы для строго верифицируемых задач
Есть узкий класс проблем, где по входным данным и состоянию среды мы точно знаем, что должен сделать агент. Например, к условиям математической задачки мы знаем точный ответ. Или по запросу разработчика на человеческом языке на задачу в терминале мы знаем какую CLI команду должен вызвать агент. В общем, если мы можем очень точно проэмулировать среду и знаем ответ - мы можем проверять на этом поведение агента. Важно, что не любую среду можно проэмулировать: например в поддержке это невозможно. И системы бизнеса могут быть сложные и поведение пользователя непредсказуемо. Плюс создавать такие эвалы - часто очень дорогое удовольствие. Зато если получилось, то можно давать агенту полную свободу в среде и проверять только финальный стейт. Есть мягкая версия такого эвала в кодинге - это сет автотестов. Очевидно, они не могут полностью проверить качество работы агента, но хотя бы отсеют очевидный шлак. Ну и этот подход дает только измерение качества: что делать с системой, чтоб это качество растить - каждый раз уникальный ребус.

3/ пошаговые эвалы
А что делать, если среда неэмулируемая, и проблему можно решить множеством способов? Поддержка или продажи - это отличный пример подобной ситуации. Как правило такая автоматизация предполагает, что есть люди, которые уже как-то справляются с этой задачей, и мы постфактум можем разметить каждую интеракцию на «хорошие» и «плохие». В этом случае мы можем измерять «попадание» агента в действия человека на каждом шаге цепочки действий. И надеяться что накопленная ошибка не уведет в проде агента с нужной нас траектории. Попадания могут быть и строгими (нажал на ту же кнопку) и нестрогими (ответил по сути так же). Такой метод контроля качества позволяет проверять агента задешево на широком наборе кейсов, но очевидно не заменяет замеров качества на взаимодействии с реальной средой. Плюс в полный рост встает вопрос строгости регламентов: если из одного состояния человек может успешно добраться до финального разными путями, то метрика получится очень шумная. Так что в таком подходе большая часть фокуса уйдет на синхронизацию сотрудников и причесываение единых регламентов (иначе агента будет сложно настроить).

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