Как измерить качество модели, когда эталонов всего пятнадцать

В первой статье серии мы рассказали, как устроено приложение, которое превращает рассказ о бизнес-процессе в схему. Здесь подробно разберём одну из восьми задач: как понять, хорошо ли модель справляется, если проверить её почти не на чем.

У нас было 15 эталонных схем из трёх процессов, на всех 152 шага. Настоящих рассказов людей, по которым эти схемы когда-то составили, не было. Ниже — как мы сделали из этого измерение, которому можно доверять в известных пределах, и где оно ошибалось само.

Как устроен один прогон #

Берётся эталонная карточка процесса: шаги, исполнители, системы, переходы. Из неё программа строит текст — связный рассказ о процессе. Модель получает этот текст и два примера «рассказ → карточка» из других процессов. Эталон проверяемого процесса она не видит. Её ответ превращается в карточку и сравнивается с эталоном.

Оценка складывается из восьми частей:

Шаги сопоставляются по сходству названий, а не по номерам, поэтому другая нумерация и другие слова ошибкой не считаются. Вопросы, которые модель задаёт человеку, в оценку не входят: эталонных вопросов у нас нет, их качество смотрит аналитик.

Первая проверка оказалась слишком лёгкой #

На двух схемах модель набрала 100 %: совпали шаги, переходы, типы, исполнители, системы, документы и условия.

Радоваться было нечему. Рассказ построен из эталона и сохраняет точные названия шагов, так что задача сводится к аккуратному переносу. Такая проверка показывает, что вся цепочка работает и формат ответа модели понятен. О качестве на настоящих рассказах она не говорит ничего.

Портим текст и записываем, что испортили #

Настоящий рассказ человека неполон и непоследователен. Мы стали делать таким и проверочный текст:

• — названия шагов пишутся без кавычек и с маленькой буквы, как в обычной речи;
• — списков участников и систем в начале нет;
• — часть шагов перенесена в конец («ещё не упомянул»);
• — часть шагов склеена в одно предложение;
• — у части шагов убраны исполнитель, система, документы, срок или ветка «иначе».

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

Потолок — это оценка эталона, из которого убрано то же, что из текста. Больше по такому тексту без догадок набрать нельзя. Если потолок 96 %, то 96 % — отличный результат, а не «четыре процента ошибок».

Честность — что модель сделала с каждым убранным сведением: оставила пустым, восстановила верно или придумала неверно. Отдельно считается, задала ли она об этом вопрос.

На всём наборе результат был такой: в среднем 96 % при потолке 96 %, найдены все 152 шага. Из 67 убранных сведений 61 оставлено пустым, 4 восстановлены верно по структуре процесса, 2 модель прочитала в описании шага в другой формулировке. Придуманных не было. Вопрос задан по 64 пропускам из 67.

Выше потолка — не значит лучше #

В отдельных прогонах оценка оказывалась выше потолка: 94 % при потолке 92 %, а на одной схеме 99 %. Модель достраивала ветку, о которой текст молчал, и угадывала.

Угаданное остаётся догадкой. На другой схеме модель так же достроила исход процесса и назвала его словами, которых в описании не было. Это единственное неверно достроенное сведение за все прогоны, но оно показало, откуда берутся такие ошибки.

Мы добавили в инструкцию правило: ветку, о которой текст молчит, не достраивать, а оставить пустой и спросить. Оценка схемы, где модель раньше угадывала, упала с 99 до 94 % при потолке 95 %. Три убранные ветки теперь пустые, и по каждой задан вопрос. Мы считаем это улучшением: аналитик получает вопрос вместо правдоподобной выдумки.

«

Аналитик получает вопрос вместо правдоподобной выдумки.

Трудный текст: разговорные слова и противоречия #

В испорченном тексте оставалась подсказка — официальные названия шагов. Мы добавили два усложнения.

Первое — разговорные формулировки. «Валидация формы регистрации» превращается в «проверяет заполнение и ищет, нет ли уже такой записи в базе». Формулировки написаны один раз и зафиксированы, поэтому текст по-прежнему воспроизводим. Их среднее сходство с официальными названиями — 0,24 по шкале от 0 до 1.

Второе — противоречия. В конец текста добавляется блок «и пара уточнений», где для части шагов назван другой исполнитель, другая система или другое продолжение. Оценивается, задала ли модель вопрос и какой вариант записала в карточку.

Сравнение пришлось усложнить. Если названия у модели свои, сопоставлять шаги по названиям уже нельзя, и мы стали учитывать описание шага и его место в потоке: те же предшественники и последователи. Сходство названий считается отдельно и в оценку не входит. Аналитик названия всё равно правит; важнее, что шаг найден и стоит на своём месте.

Результат: 95 % при потолке 96 %, снова все 152 шага, из них шесть сопоставлены только по месту в потоке. Все 11 противоречий замечены и вынесены в вопрос. Названия модели совпали с эталонными на 67 % по словам.

Что на самом деле делает правило в инструкции #

Перед этим прогоном мы дописали в инструкцию правило о противоречиях. Возник вопрос: модель замечает их сама или только потому, что ей велели?

Мы убрали правило и противоречия из примеров и повторили прогон на трёх наборах искажений. Из 39 противоречий модель заметила и вынесла в вопрос 35. Внимательность почти не изменилась.

Изменился выбор. С правилом модель всегда записывала в карточку вариант из основного описания. Без правила в 22 случаях она взяла вариант из «уточнения», в 11 записала оба перехода как развилку и только в 5 оставила вариант из описания. Это разумное прочтение: уточнение обычно отменяет сказанное раньше.

Вывод оказался не тем, которого мы ждали. Правило не делает модель внимательнее — оно делает её предсказуемой. Для системы это важнее, поэтому правило осталось, а какой вариант верен, решает аналитик.

Слабое место нашлось в склеенных шагах #

Тот же прогон показал главный источник потерь. Шаг, склеенный с соседним в одно предложение, модель не всегда делила на два: три промаха из одиннадцати. Один пропущенный шаг сдвигает и переходы, так что оценка схемы падает сразу на 9–12 пунктов.

Причина была не в невнимательности. Разговорные формулировки сами составные, и по тексту нельзя понять, сколько в предложении шагов. А в инструкции стояло «не дроби один описанный шаг», что подталкивало объединять.

Новое правило даёт критерий: у шага один тип, один исполнитель и одна система, а части предложения — разные шаги, если различаются местом выполнения, исполнителем или результатом. На тех же входных текстах склейки были разделены в 7 случаях из 7 против прежних 4 из 7. Три схемы поднялись с 85 до 97 %, с 82 до 94 % и с 81 до 90 %.

У правила есть цена: два лишних шага на 304. Оба раза модель разделила шаг самого эталона, где составители объединили действия разной природы, и оба раза задала об этом вопрос. Объединить два шага при проверке проще, чем заметить пропущенный, поэтому правило осталось.

Оставалось сомнение: правило написано по трём промахам, и оно могло быть подогнано именно под них. Мы зафиксировали инструкцию — записали её контрольную сумму до запуска и сверили после — и взяли следующие по порядку наборы искажений, без отбора. На данных, которых при написании правила не было, склейки разделены в 10 случаях из 10.

Оценка ошибалась чаще, чем модель #

За время работы мы нашли пять ошибок в самом измерении:

• — сравнение названий не учитывало отрицание: «выполнена» и «не выполнена» считались одним исходом;
• — проверка честности записывала в «придуманное» то, что модель прочитала в описании шага;
• — сопоставление связывало два похожих шага крест-накрест, из-за чего на одном процессе переходы совпадали на 66 % при верном ответе модели;
• — два шага короткого цикла с вольными названиями менялись местами, пока сопоставление не стало учитывать текст, место в потоке и признаки шага одновременно;
• — поиск вопроса о противоречии не узнавал формулировки вроде «названы два перехода».

Как минимум четыре из пяти занижали оценку. Последняя исправлена не до конца: один вопрос из 39 программа до сих пор не узнаёт, это проверено чтением ответов.

После каждого исправления мы пересчитывали все прежние прогоны. И завели правило для себя: если ответ выглядит верным, а оценка низкая, сначала смотреть, как сопоставлены шаги, и только потом винить модель.

Сравнение моделей #

Прогоны выше делались без обращения к API: на каждую схему запускался отдельный сеанс модели-ассистента без истории, который видел только свою инструкцию. Для выбора рабочей модели мы прогнали весь набор через API на трудном тексте — младшую модель три раза, старшую модель того же поставщика один раз.

Старшая модель не лучше по оценке, заметно хуже видит противоречия и стоит в два с половиной — три раза дороже. Мы выбрали младшую.

Три прогона одной модели показали ещё одну вещь. Входной текст в них один и тот же, а результаты отдельных схем расходятся: одна схема получила 99, 87 и 99 %, другая — 98, 97 и 86 %. Средняя по набору устойчива, отдельная схема — нет. Поэтому один прогон на одной схеме ничего не доказывает, а старшую модель, которую мы прогнали один раз, честно было бы прогнать ещё.

Чего это измерение не показывает #

• — Текст построен из эталона. Даже испорченный, он происходит из готовой схемы. Результат — верхняя граница качества, а не прогноз для настоящих рассказов.
• — Набор мал. 15 схем из трёх процессов дают ориентир, а не статистику.
• — Описания шагов остаются близкими к исходным. Названия мы заменили разговорными, а описания помогают модели опознать шаг.
• — Часть прогонов сделана без API. Параметры ответа в них не заданы так строго, как в рабочем режиме.

Честная проверка требует настоящих рассказов и карточек, которые по ним составил аналитик. Когда они появятся, их достаточно добавить в набор: остальное устройство измерения не меняется.

Следующая статья серии — о защите : почему ограничения в инструкции модели не работают как ограничения и что стоит перед каждым платным запросом.