В Doclear Laya ищет в документе кандидатов на скрытие. Она может узнать категорию, но границы фрагмента иногда определяет неточно. В Word даже одна фамилия бывает разбита между несколькими элементами XML. Поэтому находка сначала появляется в интерфейсе, и человек решает, добавлять ли её в список замен. Удачная подсказка модели ещё не означает, что документ можно безопасно переписать.
Laya и Jev отвечают на короткие вопросы о тексте структурированным результатом: выбирают вариант, ставят оценку по шкале или возвращают вероятность ответа «да». Такой ответ легко подключить к условию в коде. Сложнее решить, когда этому условию позволено сработать. Jev я в Doclear не использовал и общего теста моделей на своих данных не проводил. Мне интересна разница между тем, как они встраиваются в продукт, и что именно придётся проверять перед автоматизацией.
Что меняется для разработчика
Эта таблица показывает различия в интеграции. Качество ответов на документах Doclear она не оценивает.
| Критерий | Laya | Jev |
|---|---|---|
| Путь данных | В Doclear документ и выбранная модель остаются в браузере. | Текст запроса передаётся в API TypeSafe. |
| Эксплуатация | Версия модели, окружение и обновления остаются задачей команды. | Инференс и обновления сервиса ведёт провайдер. |
| Порог отказа | min_confidence опирается на answer_confidence: максимальную вероятность варианта. | confidence для Choice и Score зависит от распределения вероятностей. |
Где обрабатывается текст
В режиме «Эксперт» Doclear читает DOCX в браузере. Laya здесь дополнительный инструмент: человек выбирает архив модели, после чего она запускается локально. Документ не отправляется в API обработки документов. Если заменить эту схему вызовом Jev, придётся передать текст во внешний сервис. Для документа с персональными данными это уже изменение самого продукта, а не замена одной библиотеки другой.
У Laya открыты веса и код под лицензией Apache-2.0. Можно выбрать версию модели, держать её у себя и дообучать, но придётся отвечать за окружение, память, обновления и проверку качества. Jev приходит как API TypeSafe: приложение отправляет состояние и набор вопросов, а инфраструктуру модели обслуживает провайдер. Когда данные могут покидать контур, это снимает часть работы с команды. Для локального режима Doclear такой вызов изменил бы обещанный пользователю маршрут документа.
Что означает уверенность в ответе
В интерфейсе Doclear рядом с находкой есть процент. Я называю его оценкой модели. Пользователь видит фрагмент в контексте и может отвергнуть даже очень уверенную находку. Оценка категории ничего не говорит о том, насколько точно выделены символы: модель могла верно распознать имя, захватив соседний знак или пропустив часть фамилии.
У Jev поле confidence для Choice и Score вычисляется из распределения вероятностей по вариантам. У Laya тоже есть распределение, а её порог отказа опирается на answer_confidence, максимальную вероятность одного варианта. Из-за этой разницы один и тот же порог нельзя механически перенести между моделями. И само число 0,8 ещё не обещает восемь верных ответов из десяти. Это проверяют на серии размеченных примеров из той задачи, где модель будет работать.
Doclear повторно открывает собранный DOCX и проверяет, что подтверждённые замены попали в файл. Такая проверка ловит ошибку сборки, но не может понять, правильно ли был выбран исходный фрагмент. Для автоматической замены мне понадобилась бы отдельная оценка пропущенных чувствительных данных и ошибочно захваченных символов. Пока процент помогает человеку просматривать находки, а не разрешает сервису действовать за него.
Почему таблица не выбирает модель за нас
В репозитории Laya есть таблица с результатами Jev, но её авторы прямо оговаривают: Jev они не запускали, цифры взяты из сторонних публикаций, а запросы и выборки различаются. По такой таблице я не стал бы выбирать победителя по точности или задержке. Локальный проход по уже загруженной модели и сетевой вызов API тоже измеряют разные участки пути.
Зато там видна полезная архитектурная деталь. В Laya варианты ответа делят между собой бюджет токенов. Когда категорий много, длинные подписи обрезаются и становятся плохо различимы. Для вопроса с несколькими понятными исходами это может не мешать. Для классификатора с большим справочником классов придётся сокращать список кандидатов, менять формулировки или проверять другую схему. Результат на коротком английском запросе ничего не говорит о том, как модель прочитает длинный русский фрагмент документа.
Для прямого сравнения я собрал бы один набор размеченных входов, задал обеим моделям одинаковые вопросы и записал версии. В случае Doclear пришлось бы отдельно проверять границы найденного текста и итоговый DOCX: метрика выбора категории не ловит ошибку замены. Пока такого теста нет, таблица показывает чужие задачи, а не качество моделей на моём документе.
Граница решения остаётся в коде
Ответ Laya или Jev становится входом для следующего шага программы. Сама модель не знает, можно ли отправить договор во внешний сервис, сколько стоит пропустить одно имя и кто отвечает за испорченный файл. Это приходится решать в коде и интерфейсе: где идёт обработка, когда просить подтверждение, что проверять после изменения документа.
В Doclear Laya помогает найти то, что стоит посмотреть, а замену подтверждает человек. Чтобы убрать это подтверждение, сначала пришлось бы измерить ошибки на собственных документах и научиться останавливать сомнительные случаи. Сейчас граница проходит прямо в интерфейсе, между подсвеченной находкой и выбором пользователя.