Разработчик Чароита объяснил, где NLI-модель работает в ассистенте для зумов, а где нет

В десятой части цикла о локальном ассистенте для зумов автор проекта «Чароит» разбирает NLI-модель, которая работает в его системе уже третий месяц. Анонс на Habr открывается примером, из которого понятно, зачем она нужна: «бюджет на квартал согласован» и «бюджет на квартал не согласован» для эмбеддингов почти одна фраза. Слова совпадают, частица «не» в векторе весит мало. Для встречи это означает, что решили противоположное. Полного текста в анонсе нет, поэтому цифр и бенчмарков ниже не будет: только то, что автор сообщил прямо, и контекст, в котором это стоит читать.

Почему эмбеддинги путают противоположности

Эмбеддинг-модель сжимает предложение в вектор и оценивает близость по тематике и лексике. Для поиска по расшифровке это удобно: запрос «что решили по бюджету» найдёт нужный фрагмент. Но тот же механизм слабо реагирует на отрицание, условия и смену модальности. «Утвердили», «не утвердили» и «утвердим, если найдём деньги» оказываются соседями в векторном пространстве, хотя для протокола это три разных факта.

NLI (natural language inference) решает другую задачу. Модель получает пару утверждений и определяет, следует ли второе из первого, противоречит ему или никак с ним не связано. Это классическая трёхклассовая постановка: entailment, contradiction, neutral. В этой постановке пара про согласованный и несогласованный бюджет даёт contradiction, а не «очень похожие тексты».

Что известно о Чароите и NLI

Чароит — локальный ассистент для созвонов. Автор ведёт про него цикл статей, и десятая часть целиком посвящена одному компоненту. Из заголовка и вводной видно три вещи.

• NLI-модель в Чароите работает третий месяц, то есть это не эксперимент выходного дня, а компонент с историей эксплуатации.
• Автор перебрал несколько мест применения: в заголовке упомянуты три, куда модель «примерялась», и два, откуда она ушла.
• Отдельно обещан разбор цены решения: автор пишет, что снятие модели «во что-то обошлось».

Модель, размер, задержки и точность в анонсе не названы. Для локального ассистента это ключевые параметры: NLI-классификатор вызывается на парах утверждений, а число пар на длинной встрече растёт быстро. Если сравнивать каждый новый тезис со всеми предыдущими, нагрузка становится квадратичной, и на домашнем железе это заметно.

Где NLI обычно уместна, а где нет

В полном тексте автор, судя по заголовку, показывает обе стороны. Из общей практики можно предположить, какие места попадают в каждую группу, но это предположение, а не пересказ статьи. Хорошо NLI подходит для проверки пар, где ошибка стоит дорого: обнаружение противоречий между решениями на разных встречах, сверка итогового протокола с расшифровкой, проверка того, что пункт из саммари действительно прозвучал. Хуже она работает там, где нужна тонкая интерпретация длинного контекста. Разговорная речь с оговорками, незаконченными фразами и ссылками вроде «как мы вчера решили» плохо ложится на пары коротких утверждений. Классификатор обучен на аккуратных предложениях, а не на живой расшифровке.

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

Как использовать этот разбор

Если вы строите собственный ассистент для встреч или поиск по расшифровкам, полезно сделать три вещи.

• Соберите небольшой набор пар с отрицаниями и условиями («согласовали» против «не согласовали», «если» против «когда») и прогоните через свой эмбеддинг-поиск. Станет видно, где вектор ошибается.
• Ставьте NLI после отбора кандидатов, а не вместо него: эмбеддинги быстро находят похожие утверждения, NLI проверяет только эти пары.
• Замерьте качество на реальных расшифровках, а не на чистых тестовых предложениях. Именно там чаще всего и приходится модель снимать.

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