Из рассказа в схему: что приходится строить вокруг языковой модели
Языковая модель превращает рассказ о бизнес-процессе в структуру. Почти вся остальная работа — вокруг неё: восемь задач, которые пришлось решить, в общих чертах.
Мы сделали настольное приложение для аналитика бизнес-процессов. Человек рассказывает, как устроен процесс в его организации, а языковая модель расспрашивает его о том, чего в рассказе не хватает. Готовое описание можно и загрузить документом. На выходе получаются три вещи: схема процесса в BPMN (это стандартная нотация для таких схем), документ по принятому шаблону и черновой список расхождений с требованиями — например, со стандартами отрасли.
Сейчас это рабочая версия. Мы проверили её на небольшом наборе эталонов; на настоящих документах качество ещё не измерялось.
Модель в этой системе читает текст и предлагает: собирает из рассказа структуру, задаёт вопросы, предлагает правки. Всё остальное — расчёты, проверки, хранение — делает обычный код, и на него ушла почти вся работа. Пришлось решить, что именно просить у модели, как не отдать ей лишнего, как понять, что она не выдумывает, и как сохранить правки человека, когда всё остальное пересоздаётся.
Ниже восемь таких задач в общих чертах. Каждую мы разберём подробно в отдельной статье.
Первая мысль — попросить у модели готовый файл BPMN. Это плохо работает. Файл длинный, в нём десятки идентификаторов и ссылок между элементами, и модель в них ошибается. К тому же примерно половина файла — координаты фигур и линий, а их всё равно надо считать отдельно.
Поэтому между моделью и схемой мы поставили промежуточное звено — карточку процесса. Это файл JSON строго заданного формата: шаги, исполнители, системы, документы и переходы между шагами. Схему, документ и анализ требований программа строит из карточки; вручную их не правят.
Модель при этом заполняет даже не карточку, а её упрощённый черновик: роли и системы названы словами, без идентификаторов, а переходы записаны простым списком «откуда — куда». Идентификаторы расставляет код. Модели так проще, а её ответ можно сравнивать с эталоном независимо от нумерации и точных формулировок.
В описаниях процессов есть названия подразделений и внутренних систем, адреса, номера документов. Отправлять это во внешнюю модель нельзя.
Перед отправкой настоящие названия в тексте заменяются подставными по словарю. Словарь хранится только на компьютере аналитика. Почту, ссылки и внутренние идентификаторы отдельные правила находят по шаблону. После замены текст проверяется ещё раз: если в нём осталось хотя бы одно настоящее название, запрос не уходит.
Подставные названия мы сделали читаемыми («Система учёта», «Отдел сопровождения»), а не кодами вида ORG_17. У этого решения есть цена: замена необратима, вернуть настоящие названия в ответ модели по словарю нельзя. Поэтому ответ сопоставляется с исходными данными по структуре — по шагам и переходам, а не по тексту.
В инструкцию модели легко дописать «не отвечай на посторонние вопросы» или «не принимай слишком длинные сообщения». Это не защита: когда модель читает инструкцию, запрос уже отправлен и оплачен, а данные ушли наружу.
Поэтому перед каждым платным запросом стоит проверка в коде. Она ограничивает длину и число сообщений, обезличивает сообщение человека, ищет в нём настоящие названия и сверяет расходы с лимитами — на один разговор и на сутки. Проверка одна на все обращения к модели, и новые обращения добавляются только через неё.
У такой проверки есть предел: код не понимает смысла. Относится ли сообщение к процессу, решает уже модель, и это стоит одного запроса. Сообщение, которое модель пометила как постороннее, приложение убирает из разговора, а человек получает заранее написанный ответ.
4. Качество измеряется на намеренно испорченном тексте #
Чтобы оценить модель, её ответ сравнивают с эталоном — схемой, которую составил человек. Эталонов у нас было мало: 15 схем из трёх процессов. Вдобавок текст, который мы давали модели, был получен из тех же эталонов. Он полный и непротиворечивый, а настоящие рассказы людей такими не бывают.
Мы стали портить текст намеренно. Часть шагов переносится в конец («ещё забыл сказать»), часть склеивается в одно предложение. У некоторых шагов пропадает исполнитель или система. Официальные названия заменяются разговорными. В конец добавляются противоречия: для шага называется другой исполнитель или другое продолжение. Всё, что убрано и искажено, записывается, и это даёт две меры сверх обычной оценки:
— Потолок — оценка эталона, из которого убрано то же, что из текста. Больше без догадок набрать нельзя.
— Честность — что модель сделала с каждым пропуском: оставила пустым, восстановила верно или придумала неверно. Отдельно считается, задала ли она об этом вопрос.
Рассказ после порчи: часть шагов пропала, часть переставлена, один оказался в конце. Модели нужно это заметить, а не додумать.
На таком тексте младшая модель набрала 93 % при потолке 97 %. Старшая модель того же поставщика набрала столько же, стоила втрое дороже и хуже замечала противоречия: 4 из 11 против 8–11 у младшей в трёх прогонах. Мы выбрали младшую. Режим рассуждения у неё всегда включён: без него в разговоре она теряла шаги.
Файл BPMN содержит не только логику процесса, но и положение каждой фигуры и каждой линии. Без второй части редактору нечего показать.
Раскладку мы написали сами. Шаги расставляются по колонкам вдоль самого длинного пути, исполнители — по горизонтальным дорожкам. Линии идут только по свободным промежуткам между колонками и строками, место под подписи резервируется заранее.
Принцип раскладки: шаги стоят по колонкам и дорожкам, линии идут только по свободным промежуткам между ними.
Главное решение здесь — как проверять результат. Смотреть глазами каждую схему после каждой правки невозможно, поэтому правильность задана тестами геометрии: фигуры не пересекаются, линии не проходят сквозь фигуры, подписи не накладываются. Тот же алгоритм рисует картинку схемы для документа, поэтому схема в редакторе и в документе совпадают.
6. Документ пишется так, чтобы его можно было прочитать обратно #
Система и читает документы с описанием процесса, и создаёт их. За это отвечают два модуля: разборщик читает документ, генератор его пишет. Они легко расходятся: один начинает писать то, чего другой не понимает.
Мы связали их тестом: документ, собранный из карточек, при чтении должен дать те же карточки. Это проверяется на всех процессах, которые у нас есть. Если правка в любом из двух модулей нарушает соответствие, это сразу видно.
У разборщика есть ещё одно правило: он ничего не додумывает молча. Если в документе чего-то не хватает и это приходится достраивать, достроенное помечается в карточке и перечисляется в отчёте о разборе.
Карточки пересоздаются: стоит измениться разборщику или словарю, и они строятся заново. Если бы аналитик правил карточку напрямую, его работа пропадала бы.
Поэтому всё, что сделал человек, лежит в отдельном файле разметки: поправки к шагам, ответы на вопросы, оценки требований, целевая схема процесса — то, каким он должен стать. Результат строится из карточки с наложенной разметкой. У файла есть номер версии и история; попытка сохранить изменения поверх устаревшей версии отклоняется.
Сложнее понять, что из сделанного ещё актуально. Аналитик оценил требование, потом схема изменилась — верна ли ещё оценка? Чтобы ответить, оценки, правки целевой схемы и предложения модели хранят отпечаток схемы, по которой они сделаны. Приложение показывает всё, что сделано по прежней схеме. Отпечаток не зависит от номеров шагов, поэтому перенумерация ничего не ломает.
С предложениями модели правило строже. Предложение ничего не меняет, пока человек его не принял, а предложение по устаревшей схеме принять нельзя — только отклонить и запросить заново.
«
Предложение модели ничего не меняет, пока человек его не принял.
Система начиналась под одну область и один шаблон документа. Довольно быстро стало понятно, что механика общая, а от области зависит немногое.
Это немногое мы вынесли в набор области: типы шагов, темы, о которых модель расспрашивает человека, шаблон документа, каталог требований, вид номера процесса. Новая область описывается новым набором. Перенос не закончен: формулировки внутри ячеек таблицы шагов и таблица соответствия для выгрузки во внешнюю систему моделирования пока остались от первой области.
Чтобы сведения об области не вернулись в общий код, есть два приёма. Тест читает исходный код той части, которая ведёт разговор, и проверяет, что в нём нет слов из конкретной области. Остальные общие модули прогоняются на двух разных наборах.
Приложение рассчитано на одного аналитика и работает локально: данные хранятся файлами в рабочей папке, базы данных нет. Наружу уходят только обезличенные запросы к модели.
Если собрать восемь задач вместе, видно общее правило. Модели отдаётся только то, чего кроме неё не сделает никто: понять связный текст, задать вопрос, предложить правку. Всё, что можно посчитать, проверить или сохранить кодом, делает код. А всё, что предложила модель, вступает в силу только после решения человека.
В следующих статьях разбираем каждую задачу подробно. Первая из них — об измерении качества : как устроен испорченный текст и что он показал про разные модели.
