Недетерминированность — что это простыми словами

Зачем это знать

• Понять, почему на демонстрации всё вышло гладко, а на потоке ответы разъехались
• Задать подрядчику проверяемый порог качества вместо обещания «модель отвечает верно»
• Знать, какие процессы отдаются модели целиком, а какие — только с проверкой на выходе

Что такое недетерминированность простыми словами

Калькулятор на одном и том же примере всегда выдаёт одно число. Опытный юрист на один и тот же вопрос напишет два письма разными словами. Смысл совпадёт, порядок абзацев и обороты — нет.

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

Разброс неоднороден. Формулировка меняется почти всегда. Смысл ответа — заметно реже. Конкретные поля вроде суммы, даты и номера договора — реже всего, и именно за ними следят.

Второй источник разброса лежит вне запроса. Поставщик обновляет модель, и поведение меняется без объявления. Поэтому версию модели фиксируют письменно, а замер качества повторяют после каждого обновления.

Как это работает

1. Фиксируют версию модели. В договоре указывается конкретная версия, а не название семейства. Переход на новую делается через повторный замер, а не автоматически.
2. Задают формат ответа. Модель обязывают вернуть поля: сумма, дата, контрагент, тип обращения. Свободный текст остаётся только там, где он идёт человеку.
3. Понижают температуру там, где нужна ровность. Разбор документов держат внизу шкалы, ответы клиенту — выше, иначе текст выходит сухим.
4. Собирают эталонную выборку. 200–300 типичных обращений, размеченных руками. Она же служит приёмкой и повторяется после каждого изменения промпта или версии.
5. Ставят порог и проверку на выходе. Например: доля разборов с ошибкой в ключевых полях не выше 3%, замер на выборке из 300 документов за две недели. Всё, что ниже порога уверенности, уходит человеку.

Отдельно проверяют устойчивость. Один и тот же запрос прогоняют 30 раз подряд и смотрят, насколько расходятся ключевые поля. Разъезжаются поля — рано автоматизировать. Разъезжается только формулировка — можно работать.

Пример из практики

Разбор входящих счетов, около 4 000 документов в месяц. Цифры ниже — расчётные ориентиры для процесса такого профиля, а не отчёт по внедрению; методика указана, чтобы замер можно было повторить на своих данных.

На демонстрации показали десять счетов, разобрались все. На потоке ответы разошлись: у части документов сумма НДС уезжала в поле «итого», а формулировка комментария менялась при каждом прогоне.

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

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

Что это даёт бизнесу

• Качество становится измеримой величиной. Порог, выборка и период замера пишутся в договор до старта. Дальше спор о качестве решается прогоном выборки, а не перепиской.
• Обновления перестают быть сюрпризом. Зафиксированная версия и готовая выборка позволяют перейти на новую модель за один замер, а не через месяц жалоб.
• Гибкость остаётся там, где она полезна. Тот же разброс даёт модели способность отвечать на формулировки, которых не было в правилах. Жёсткая программа такое не берёт.
• Понятно, что можно отдать агенту целиком. Шаги с проверяемым результатом автоматизируются полностью, шаги с оценочным суждением — с контролем на выходе. Прикинуть, какие шаги процесса готовы, помогает чек-лист готовности.

Когда об этом можно не думать

Есть задачи, где разброс безвреден по природе. Черновик письма, варианты заголовка, пересказ встречи для себя — там результат читает человек, и он же правит.

Не нужен этот разговор и там, где модель работает как подсказка внутри интерфейса: сотрудник видит предложение и принимает решение сам. Рамки нужны с того момента, когда ответ уходит клиенту или попадает в учётную систему без человека.

Что важно проверить

Первое: попросите прогнать демонстрационную выборку дважды и покажите оба результата рядом. Расхождение по ключевым полям видно сразу, и именно оно определяет, сколько ручного контроля останется.

Второе: разберитесь, где проходит граница между разбросом и галлюцинацией. Разные формулировки одного верного факта — рабочая ситуация. Разные факты в ответах на один запрос — сигнал, что данных модели не хватило.

Третье: узнайте, как подрядчик поступает при обновлении модели поставщиком. Ответ «перегоняем эталонную выборку и сравниваем с порогом» проверяем. Ответ «следим за качеством» — нет.