LLM-агенту недостаточно выдать правдоподобный ответ: в продакшене он должен понимать, когда ответ лучше не отправлять автоматически. Stack Overflow предлагает строить калибровку уверенности из нескольких независимых сигналов, проверять её на реальных результатах и передавать сомнительные случаи человеку. Для российских команд, которые внедряют ИИ в поддержку, разработку и внутренние процессы, это практичнее очередного разговора о «магии» моделей.
Третий уровень зрелости LLM-систем Stack Overflow называет уровнем confidence: агент действует сам лишь при высокой подтверждённой вероятности корректного решения. В заметке от 7 октября 2026 года, как пишет Stack Overflow Blog, такая вероятность складывается не из самооценки модели, а из результатов детерминированных проверок, оценки независимого судьи и истории точности на конкретном типе задач.
Авторы предлагают давать самооценке модели минимальный вес — 0,25. По 0,35 и 0,25 получают соответственно техническая верификация и согласие модели-судьи, ещё 0,15 — историческая точность для данного среза запросов. Если судья не запускался, а в примере он проверяет только около 8% решений, его вклад исключается, а остальные веса пересчитываются. Логика проста: отсутствие проверки нельзя записывать ни в плюс, ни в минус. Главное здесь не сами коэффициенты, а защита от одной точки отказа: модель может быть уверена в ошибке, но не должна пройти порог, если тесты не сошлись или внешний судья не согласен.
Число от нуля до единицы само по себе ещё не вероятность. Команда должна сверять прогноз уверенности с фактической точностью по диапазонам. В приведённом примере решения со средней заявленной уверенностью 0,95 оказались правильными лишь в 71% случаев. Это не повод слегка подкрутить дашборд: такой верхний диапазон нельзя безопасно автоматизировать. Для преобразования сырого балла в вероятность корректности авторы рекомендуют монотонную калибровку, например изотоническую регрессию, и пересчёт на скользящем окне. Модель, входные данные и поведение пользователей меняются, а вместе с ними портится и вчерашняя оценка риска.
После калибровки уверенность становится маршрутизатором. Для каждого типа задач задаётся свой порог автоматизации: при значении выше порога решение выполняется, ниже — уходит на human-in-the-loop. Универсальный порог для всех сценариев Stack Overflow считает анти-паттерном: извлечение полей из стандартизированного документа и ответ на неоднозначный запрос клиента имеют разный профиль ошибок. Начинать предлагают с консервативного режима, когда почти всё видит оператор, и снижать порог только там, где накопленная статистика подтверждает безопасность.
Отдельное место занимает отказ от ответа. При уверенности ниже 0,40 агенту предлагают не заполнять даже черновик, а сразу эскалировать задачу как требующую ручной обработки. Это особенно полезно для неизвестных классов входных данных — тех самых случаев, которые команда не успела предусмотреть в правилах и тестах. Метрика отказов здесь не признак провала модели, а показатель границы её компетенции. Давление на эту метрику ради красивой доли автоматизации обычно заканчивается тем, что операторы разбирают больше убедительно оформленных ошибок.
Проверяющая модель тоже не должна быть формальностью. Один и тот же LLM с тем же промптом легко повторит исходное слепое пятно и одобрит собственный стиль рассуждений. Судье нужна узкая задача — оценить конкретное предложенное решение — и достаточная независимость от основного исполнителя. Для высокорисковых действий это превращает «похоже на правильный ответ» в решение, которое прошло дополнительный контроль.
Для разработчиков вывод довольно приземлённый: калибровка уверенности — это не поле confidence в JSON-ответе, а контур из проверок, статистики, порогов и очереди для людей. Для бизнеса это способ обсуждать внедрение агентов языком допустимой ошибки и стоимости ручной проверки. Следующий сложный вопрос — где провести границу между ценой второго модельного прогона, нагрузкой на специалистов и ущербом от автоматического решения, которое звучит уверенно, но оказывается неверным.