Где NLI-модель помогает в ассистенте для встреч: три примерки, два отказа

Разработчик локального ассистента для встреч Charoite Charoiteai рассказал, где работает NLI-модель и где она мешает. Пробовал в пяти местах, две остались.

В июле он прогнал один и тот же протокол встречи четыре раза через модель автоматического конспектирования — получил 39 разных утверждений, из них 32 встретились только в одном прогоне. Хотелось инструмента, который скажет, где прогоны противоречат. Взял mDeBERTa-v3-base-xnli-multilingual-nli-2mil7: мультиязычная, обучена на 2,7 млн пар, вес 1,1 ГБ в формате ONNX, загрузка полторы секунды.

Место первое: повторы в живой ленте — работает ежедневно

На длинной встрече модель конспектирования видит только 800 символов свежего текста, поэтому повторяет уже сказанное другими словами. NLI ловит дубли через двустороннюю логику: дубль — когда A следует из B и B следует из A одновременно. Уточнение (только в одну сторону: бюджет согласован следует из бюджет согласован до конца года, но не наоборот) остаётся в ленте. Противоречие не проходит ни в одну.

Схема простая: новый тезис сравниваются со всеми предыдущими 16 по difflib с порогом 0,3 (намеренно низкий, чтобы не отсечь раньше времени). Прошедшие идут в модель в обе стороны. Если обе вероятности ≥ 0,8, тезис выбрасывается как дубль, иначе остаётся. Порог 0,8, а не 0,75 по умолчанию, потому что повтор раздражает, но потерянный новый факт хуже. Каждый вызов занимает десятки миллисекунд, большинство пар до модели не доходит благодаря префильтру.

Это единственное место, где NLI работает без вопросов третий месяц подряд. Не идеально: на встрече 29 сентября за 8 минут вернулись к одной теме 5 раз, ничего нового не добавив. Механизм уже в памяти — следующая задача.

Место второе: противоречия в протоколах — отказал

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

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

Место третье: ночная ревизия ядер — выключил

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

Ревизия работала в два шага: bge-m3 собирал кандидатов (косинус от 0,55), потом NLI судил их суть в обе стороны с четырьмя исходами: дубль (обе стороны от 0,8 — кандидат на слияние); возможный дубль (0,72–0,8 — пометка); вложение (одна сторона от 0,85, другая ниже 0,5 — узкая тема в широкой); граница (обе от 0,45 — соседние темы). Ядро с тремя вложениями считалось хабом и не трогалось.

В августе выглядело хорошо: 284 живых ядра, 40186 пар, 1806 через префильтр, ревизия за 6 минут. К октябрю ядер стало более 1000. Ревизия от 27 сентября упёрлась в ночной потолок через 3,5 часа и оставила 824 ядра на следующие ночи. Досье (сводки по теме) в восьми ночах из двенадцати не собрались вообще.

Посмотрел десять случайных уверенных пар, которые ревизия готовилась слить. Настоящих дублей среди них ноль. Спорная одна. Уверенность ложных пар: 0,93–1,00. Разгадка: не у всех ядер есть своя суть. Если её нет, ревизия берёт шаблонный статус вроде «Обсуждение требований и особенностей». Две разные рабочие темы с одинаковым шаблоном — и NLI говорит: эти фразы друг из друга следуют. Да, следуют, потому что это одна и та же фраза. Модель отработала правильно, но это ошибка данных, не модели. Пометок возможных дублей в графе собралось 239, разобрано ноль: служебная заметка с пометками никто не открывал.

5 октября выключил одной строкой в конфиге. Автослияние не включал никогда, но теперь ясно: оно склеило бы разные рабочие темы, подсказка на встрече показала бы статус чужой задачи. Бэкап слияния живёт неделю, в него никто не смотрит — на деле это необратимо.

Место четвёртое: гейт перед молнией — не помог

Кнопка ⚡ (быстрый ответ) срабатывает на вопрос, только что заданный на звонке. Структурный фильтр находит кандидата в ленте, локальная модель пишет ответ за секунды. Но иногда кандидат не вопрос: человек переспросил, задумался вслух, оборвал фразу. Модель отвечает «вопроса не вижу», время потрачено.

Хотел перед моделью судью подешевле без дообучения: две утвердительные гипотезы (с отрицанием модели работают хуже): «Собеседник задаёт вопрос и ждёт ответа» и «Собеседник переспрашивает, думает вслух или обрывает фразу». Каскад: уверен — решает сам, не уверен — отдаёт модели.

В тени: судья считал рядом и ничего не решал, только писал в лог. Четыре встречи, 117 реплик. Модель ответила на 115, отказала на 2 — это 1,7%, потолок того, что гейт вообще мог сэкономить даже идеально.

Но NLI был не идеален. Точность против эталона: 55,6%, почти монетка. Калибровка плохая, уверен заметно чаще, чем прав. Медиана вызова: 99 мс. Проверил пороги:

| Порог | Отсечено | Снято пустых | Потеряно вопросов | |-------|----------|--------------|-------------------| | 0,60 | 31,6% | 1 из 2 | 31,3% | | 0,70 | 17,9% | 1 из 2 | 17,4% | | 0,80 | 9,4% | 0 | 9,6% | | 0,90 | 0 | 0 | 0 |

При любом пороге, который хоть что-то отсекает, он теряет настоящих вопросов в десятки раз больше, чем снимает пустых. Правило закрытия записал за неделю до замера: если пустых меньше 15%, тему закрыть. Вышло 1,7%. 6 октября тень выключил.

Что ломалось

Самое неприятное — отказ без звука. Первый раз: модели лежат в корне данных, а код искал NLI-модель рядом с собой, в корне кода. В репозитории разработчика оба корня совпадают, дефекта не было видно. В установке, где данные лежат отдельно, модели по этому пути не было. Стояло правило: нет модели на диске — дедуп выключен. Никакой ошибки, никакого предупреждения, лента просто опять повторялась. Заметили не по ленте, а при ревью. Произошло дважды. Теперь путь вычисляется в момент вызова.

Второй раз — в ревизии ядер, тоже дважды подряд. Судья собирался, но судить не мог, ревизия считала прогон состоявшимся: пар не нашла, пометку сдвинула, свежие ядра выпадали из проверки насовсем. Ноль для ревизии значил не «похожи» вместо «судить нечем». Теперь отказ судьи — исключение, а не ноль.