Как принимать LLM-проекты: почему чек-листы больше не работают

«Сдал/не сдал» больше не работает

Если мы говорим про классические IT-проекты, например, разработку мобильного приложения — там всё построено по стандартному подходу: есть набор функций, у каждой из функций — набор тест-кейсов. Когда идет подготовка к проведению приемки, исполнитель формирует документ «Программа и Методика испытаний» (ПМИ), в котором перечисляются все разработанные функции и ожидаемое поведение системы, а рядом с каждой функцией есть столбец для проставления «галочек». Если функция отработала так, как ожидалось,  значит, испытание засчитано как пройденное, если нет — как непройденное. Есть еще опция «Отработала с незначительными замечаниями», которая также рассматривается как вариация успеха, но останавливаться на этом сейчас не будем. Например, функция «Открывать модальное окно при нажатии на кнопку [Х]» проверяется нажатием кнопки [X]. Модальное окно либо открывается, как надо, либо нет. Все логично.

Если сравнивать AI-проекты, например, ML-проекты и LLM-проекты, то разница будет заключаться в том, что и как именно измеряется и как ведёт себя модель в реальном контексте. LLM-проект будет не совсем нерелевантно оценивать по тем же правилам, что и ML-проект, потому что у него другая природа ошибок и другая логика воспроизводимости.

Чтобы адаптировать подход к приёмке с учетом особенностей LLM-моделей, нужен другой способ зафиксировать качество: не по принципу «сдал / не сдал», а по принципу «работает в пределах допустимого коридора».

Так появляется концепция Corridor Acceptance — приемка по диапазону, где система считается принятой, если ее показатели находятся в согласованных границах, обеспечивающих бизнес-ценность.
‍

Что такое Corridor Acceptance

Corridor Acceptance — это подход, при использовании которого система принимается по диапазону показателей, в котором она остается полезной, то есть на смену «работает / не работает» приходит «работает в коридоре от X до Y». Можно провести аналогию со спидометром: необязательно ехать ровно 60 км/ч, 50–70 км/ч — это нормально и безопасно.

Концептуально, для LLM-проектов совершается переход от «всё четко по ТЗ» (так как мы уже не можем описать все требования в ТЗ в «жестком виде» по той же причине вероятностной природы, но это уже другая тема) к «всё согласно требованиям и в пределах, которые позволяют получить ценность и являются технически реализуемыми».
‍

Как определить коридоры качества LLM-проекта

Важно исходить из бизнес-метрик, а не из инженерных. Например, в проекте по внедрению системы подбора аналогов сетевого оборудования задача заключалась в снижении нагрузки на пресейл-инженеров и ускорении обработки клиентских запросов. У заказчика был огромный каталог — свыше 10 000 позиций, и менеджеры ежедневно сталкивались с запросами на подбор альтернативных позиций. Ручная обработка занимала часы, приводила к потерям заявок и снижению конверсии. Поэтому первый шаг для нас, как для команды исполнителя – выявить, какие метрики будут на это влиять. 

В нашем случае ключевой метрикой стала «Доля диалогов, в которых релевантный аналог находится в ТОП-3» (иными словами — релевантность рекомендаций). Если система способна в достаточной доле запросов сформировать релевантные рекомендации, которые не требуют «доработки” предложения со стороны эксперта, то пресейл-инженер тратит в разы меньше времени на подбор. В качестве дополнительных метрик были выбраны «Точность классификации диалога» (оценивающая качество маршрутизации запросов между модулями, предшествующее формированию рекомендаций) и «Соответствие ТОП-1 рекомендации бизнес-правилам» (оценивающая точность соблюдения бизнес-правил при выборе самого подходящего аналога).

После того, как определены метрики, формируем диапазоны. Например, когда мы рассматривали метрику «Доля диалогов, в которых релевантный аналог находится в ТОП-3», мы зафиксировали целевое значение в виде 0.80 (т.е. ≥0.80 — это «успех» или «зеленая зона»). При этом, мы допускаем, что «коридор значений» (т.е. зона допустимого отклонения, в которой система остается ценной для бизнеса, это «желтая зона») находится в диапазоне 0.70–0.79. Все, что ниже 0.70 — недопустимо, так как не будет удовлетворять потребностям бизнеса («красная зона»). В нашем случае именно такие значения стали балансом между технической достижимостью на текущем этапе и требуемой полезностью для заказчика, на что повлияло несколько факторов, включая ограниченность товарной матрицы, с которой мы работали.

Стоит дополнительно отметить, что в парадигме LLM-проектов банально нельзя зафиксировать одно значение — оно будет плавать, и на это могут влиять разные факторы, например, разные выборки при замерах метрики, обновление базы знаний и так далее. 
‍

Как замерять метрики LLM-проектов?

Для замера метрик используются Golden Set’ы — размеченные эталонные коллекции запросов и ожидаемых ответов, которые становятся источником истины для оценки качества LLM-системы. В рамках нашего проекта по подбору аналогов у нас было всего три Golden Set’а — по одному на каждую метрику, при сборе которых мы учитывали несколько ключевых моментов:

• Golden Set должен:
  
  • Быть репрезентативным, то есть покрывать ключевые сценарии: типичные запросы, сложные случаи и пограничные ситуации
    
  • Иметь человеческую разметку, то есть каждый ответ должен быть проверен и оценен экспертами по согласованным критериям
• Чтобы создать качественный Golden Set, стоит придерживаться нескольких базовых принципов:
  
  • Совместная разработка: набор должен создаваться совместно с заказчиком и предметными экспертами
  • Постоянная актуализация: после запуска системы в эксплуатацию (и при развитии системы) набор должен регулярно обновляться, отражая изменения в бизнес-процессах и пользовательском поведении.
  • Статистическая значимость: объем набора должен быть достаточным для надежной оценки метрик. Обычно от 200 до 1000+ разнообразных запросов, в зависимости от объема данных, с которым мы работаем.

Качество всего подхода во многом зависит от качества Golden Set, так как плохой набор ведет к необъективным метрикам, а необъективные метрики — к  неправильным решениям.
‍

Как перестроить процесс приёмки LLM-проектов

Чтобы Corridor Acceptance заработал, он должен быть встроен в процесс разработки:

1. На этапе Discovery должны быть определены и зафиксированы в ПМИ ключевые метрики и допустимые диапазоны их значений;
2. У команды аналитиков данных в проектном плане должна присутствовать задача по формированию Golden Set’ов совместно с заказчиком / бизнес-экспертами, которые будут использоваться для проведения тестирования, промежуточных замеров метрик и непосредственной приемки;
3. Должен быть добавлен дашборд с метриками, на который команда исполнителя совместно с заказчиком сможет регулярно смотреть по итогам спринтов / внесения исправлений, чтобы обеспечить прозрачность процесса.

Сам процесс проведения приемо-сдаточных испытаний (ПСИ) похож на экзамен: команда исполнителя показывает N кейсов (1 кейс – 1 функция). Если все функции успешно проходят испытания, то акты могут считаться готовыми к подписанию. Однако, как мы писали выше, в LLM-проектах это не работает, так как цель заключается в том, чтобы показать попадание в заданный диапазон, а не «идеальный результат».

Как это делается:

1. Подготавливается Acceptance Matrix — таблица с согласованными диапазонами метрик. Например, в проекте по разработке системы подбора аналогов сетевого оборудования, это выглядело так: 

2. На приемо-сдаточных испытаниях (ПСИ) показывается не один кейс, а срез (для той части функционала, которая носит вероятностный характер). Система автоматизированно прогоняется на Golden Set’е, подсчитывается значение метрики и демонстрируется заказчику попадание / непопадание в диапазоны. После этого проводится демонстрация. Например, на наборе из 10 случайных запросов из Golden Set’а, чтобы показать качество «вживую» (вместо того, чтобы остановиться на сухом значении метрики после автоматизированного прогона). Это нужно для того, чтобы предоставить возможность «прощупать» систему на текущем этапе и синхронизировать ожидания по поводу того, что означают метрики на практике;

3. Фиксируется фактическое значение каждой метрики, чтобы подтвердить, что система функционирует в пределах согласованных диапазонов и готова к эксплуатации при условии регулярного мониторинга.

• Если все метрики попали в зеленую зону, проект считается принятым;
• Если какие-то метрики попали в желтую зону, проект считается принятым с замечаниями. Желтая зона означает, что система все еще находится в диапазоне, в котором она способна приносить бизнес-эффект. Эти метрики будут доведены до зеленой зоны во время осуществления поддержки, не препятствуя запуску системы в эксплуатацию;
• Если какие-то метрики попали в красную зону, проект считается не принятым. В таком случае согласуются сроки исправлений и назначается дата проведения повторной приемки.
  ‍

Что происходит после приемки?

Для поддержания работоспособности и качества системы после приемки и запуска в эксплуатацию должны поддерживаться несколько обязательных процессов:

• Регулярный мониторинг метрик.
  Даже когда система уже считается принятой, ее метрики все равно требуют постоянного отслеживания. Для мониторинга необходимо настроить и внедрить автоматизированный прогон на Golden Set раз в 1-2 недели (или какой-то другой короткий временной интервал в зависимости от длительность спринтов команды). После каждого автоматизированного прогона значения метрик должны фиксироваться, а при выходе метрик из «зеленой зоны» — настроены алерты, при поступлении которых должны анализироваться причины и планироваться эксперименты для исправления.
• Актуализация Golden Set. Статичный Golden Set может устареть примерно за 2-3 месяца, так как база знаний пополняется, бизнес-процессы меняются, и это абсолютно нормально. Необходимо анализировать запросы, поступающие в ходе эксплуатации, добавлять и размечать новые типы запросов и  удалять устаревшие сценарии. В кейсе с подбором аналогов оборудования для актуализации Golden Set’ов использовалось несколько источников: 
  
  • реальные пользовательские запросы (выявление пробелов Golden Set’а — кейсов, которые изначально не были покрыты)
  • расширение товарной матрицы (при появлении новых товаров появлялось пространство для новых, более корректных аналогов, которые система может предложить)
    ‍

Чеклист «тревожных звоночков»

Суммируя вышесказанное, выделим следующий набор признаков, сигнализирующих о движении в неверном направлении:

• Нет согласованных метрик и диапазонов.
  На этапе аналитики (Discovery) вам не представили документ (Acceptance Matrix или раздел в ПМИ) с четким перечнем метрик и допустимых диапазонов их значений («зеленая» и «желтая» зоны);
• Не создается или не согласуется Golden Set.
  Исполнитель не планирует совместно с вами и вашими экспертами создавать эталонный набор данных для проверки или отказывается его вам показывать;
• Приемка строится на единичных демонстрациях.
  Вам показывают 2-3 «красивых» примера работы системы и на этом основании требуют подписать акт. Это неверный подход и вы вправе требовать результаты автоматизированного прогона на всем Golden Set'е, чтобы принимать обоснованное решение на основе конкретных значений конкретных метрик;
• Требование идеального соответствия для каждого запроса.
  Если исполнитель или ваш внутренний эксперт начинает проверять систему по принципу «на вот этом конкретном сложном запросе ответ не идеален, значит система не работает»,  это признак недопонимания вероятностной природы LLM. В этом случае вы можете требовать перехода к оценке по совокупной метрике;
• Нет плана по мониторингу после запуска.
  Если после приемки система предоставляется «как есть» без планов по регулярному замеру метрик и обновлению Golden Set'а, то это почти наверняка приведет к деградации качества.
  ‍

Заключение

Если бы мы проводили приемку «по классике» (в парадигме сценариев «Получение ответа на вопрос пользователя, который содержится в базе знаний»), то мы бы столкнулись с тем, что эксперт с высокой долей вероятности признал бы один из сгенерированных ответов некорректным (потому что он был, допустим, не настолько подробный, насколько ожидалось). Мы бы сначала обсуждали общее понятие корректности и полноты информации, после чего сценарий был бы признан «непройденным», и приемка была бы формально провалена и система не могла быть запущена в эксплуатацию, хотя по сути был выдан полезный ответ. 

Из этого можно сделать вывод, что если бы мы продолжали собирать единичные сценарии для проверки LLM-систем и оценивать их бинарно, то бесконечно бы вносили точечные исправления в систему, которая уже способна приносить ценность.

В заключение хочется сказать, что мир технологий меняется, и это нужно понимать. Когда мы впервые проводили приемку LLM-проекта, мы пытались подогнать её под старую схему (тест-кейсы и чек-листы). Однако это не увенчалось успехом, потому что такая приемка не являлась отражением действительности и только усугубляла проблему управления ожиданиями. Тогда и появилась гипотеза с Corridor Acceptance: всё не может быть идеально, но всё должно быть понятно, контролируемо и однозначно полезно для бизнеса.

Этот опыт лег в основу нашего подхода в Napoleon IT: мы проектируем и выводим LLM-решения так, чтобы на этапе передачи заказчику это была система с заранее согласованным диапазоном показателей и понятной связью с бизнес-результатом. Если вы хотите внедрить LLM-решение, которое приносит измеримую пользу, мы поможем пройти весь путь — от оценки ROI до запуска и стабильной работы в эксплуатации.