Локальный ассистент для Zoom, часть 10: NLI работает на коротких фразах, но ломается после 120 знаков

NLI (Natural Language Inference, определение логической связи между двумя фразами: следует одна из другой, противоречит или не связана) обещала стать универсальным фильтром противоречий в протоколах встреч, но на практике пригодилась совсем не там, где планировалось, и два сценария из пяти пришлось закрыть.

Автор серии о локальном ассистенте для Zoom, проекте «Чароит», в десятой части делится тремя месяцами жизни с NLI-моделью. Отправной точкой стал эксперимент: один и тот же протокол встречи прогнали четыре раза на боевых настройках. Результат: 39 утверждений, из которых 32 встретились только в одном прогоне, ни одно не повторилось во всех четырёх. Нужна была машина, которая сравнит прогоны и покажет противоречия.

Что понадобится

• NLI-модель: mDeBERTa-v3-base-xnli-multilingual-nli-2mil7, мультиязычная, обучена на двух с лишним миллионах пар. Конвертируется в ONNX, итоговый файл 1,1 ГБ
• Среда выполнения: onnxruntime и токенизатор, без PyTorch
• Эмбеддинг-модель: bge-m3 для предварительного отбора кандидатов по косинусной близости
• Текстовый фильтр: difflib для дешёвого пословного сравнения перед вызовом модели
• Архив встреч: записи с тезисами и протоколами для тестирования
• Время на запуск: загрузка модели полторы секунды, инференс (вычисление ответа модели на входную пару фраз) за десятки миллисекунд на вызов

Пошаговая инструкция: как встроить NLI-фильтр и где он реально работает

1. Конвертируйте модель в ONNX. Скачайте mDeBERTa-v3-base-xnli-multilingual-nli-2mil7 с Hugging Face и экспортируйте в ONNX. Torch тащить не нужно: достаточно onnxruntime и токенизатора.

2. Соберите свой тестовый набор. Возьмите реальные пары фраз из протоколов. Автор собрал 16 пар с ручным эталоном. Но: короткие пары, которые вы пишете сами, дадут завышенный результат. Свой набор не доказательство, это ловушка.

3. Добавьте префильтр по общему предмету. Без фильтра модель путает «про разное» и «наоборот». «Собеседник 5 уточняет статус задачи» против «Собеседник 2 проверяет выкатку» модель назвала противоречием, хотя это просто разные темы. Фильтр поднял точность с 14 из 16 до 16 из 16 на тестовом наборе.

4. Проверьте на реальном архиве и следите за длиной. Автор прогнал 14 встреч, 51 пункт протокола, 1192 пары. Из 76 пар, прошедших фильтр, модель назвала противоречием 30, и почти все оказались ложными. Причина: средний пункт протокола 138 знаков, 69% длиннее 120. Три мысли в одном абзаце, и у любых двух таких абзацев найдётся что-то похожее на конфликт.

5. Примените NLI к живой ленте тезисов (работает). Модель, которая пишет тезисы по ходу звонка, видит только свежий кусок (около 800 знаков) и не помнит сказанное полчаса назад. К концу часа лента наполовину из перепевов. Фильтр дублей устроен так:

Последние 16 тезисов держатся в окне.
Новый тезис сравнивается со всеми по словам через difflib.
Если пересечение слов < 0.3 → пару не трогаем.
Кто прошёл → идёт в NLI в обе стороны.
Если обе вероятности ≥ 0.8 → тезис выбрасывается как дубль.

Порог 0,3 по словам низкий нарочно. У фраз типа «2 RPS» и «2 запроса в секунду» общее по словам только «2», и жадный порог отрезал бы их до проверки моделью.

1. Порог 0,8, а не 0,75. Ошибки неравноценны: повтор в ленте раздражает, но выброшенный тезис с новым фактом означает потерянную информацию. Выше порог, меньше риск потери.

2. Примените NLI к ночной ревизии ядер (работает). Ядра (темы, которые живут дольше одной встречи) часто называют по-разному: «настройка доступа к API» и «получение токена» это одна работа, два ядра, две неполные хроники. По словам совпадение ноль. Ревизия в два шага:

Шаг 1: bge-m3 собирает кандидатов с косинусом от 0.55.
Шаг 2: NLI судит каждую пару по сути ядер, в обе стороны.

Исходы:

- дубль (обе стороны ≥ 0.8) → кандидат на слияние
- возможный дубль (0.72–0.8) → пометка, легко снять
- вложение (одна сторона ≥ 0.85, другая < 0.5) → узкая тема входит в широкую
- граница (обе ≥ 0.45) → темы соседние, связь стоит отметить

1. Откажитесь от NLI там, где она не работает. Противоречия в протоколах ловит не NLI. Протокол просится короткими утверждениями до 60 знаков с названным объектом, а номера и даты сверяются со стенограммой напрямую, поиском. Это на два порядка дешевле. Такая сверка на тестовом прогоне поймала одну выдумку (галлюцинацию, когда модель уверенно выдумывает то, чего не было) из десяти утверждений: «релиз запланирован на 17.08», хотя семнадцатое августа не звучало ни цифрами, ни словами.

Что делать с этим прямо сейчас, по ролям

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

Маркетологу, который ведёт протоколы планёрок. Не рассчитывайте, что модель найдёт противоречия между длинными пунктами плана. Работает обратное: пишите пункты короткими (до 60 знаков), с явно названным объектом, тогда и проверять проще, и модели не нужны.

Разработчику, который строит ИИ-агента (программу, которая сама выполняет цепочку действий) для совещаний. Двусторонний NLI-тест (A следует из B и B следует из A) отделяет дубли от уточнений без ручной разметки. Уточнение проходит только в одну сторону: «бюджет согласован» следует из «бюджет согласован до конца года», а обратно нет.

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