Детерминированный ИИ: как сделать корпоративную систему предсказуемой

---

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

На демонстрации всё обычно выглядит просто. Пользователь задаёт вопрос, нейросеть отвечает. Ответ связный, уверенный и, похоже, правильный. Потом тот же вопрос задаёт другой сотрудник и получает другую формулировку. Меняется одно слово в запросе — и вывод модели уже не совпадает с предыдущим.

В какой-то момент бизнес задаёт разумный вопрос:

«Как мы встроим это в рабочий процесс, если система каждый раз может отвечать по-разному?»

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

Почему одинаковый запрос даёт разные ответы

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

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

На результат влияет не только сам запрос:

• системные инструкции;
• история диалога;
• параметры генерации;
• версия модели;
• найденные документы;
• порядок фрагментов в контексте;
• ответы внешних систем;
• изменения в инфраструктуре поставщика модели.

Это не оценочное суждение, а задокументированное поведение. Microsoft описывает ответы чат-моделей как недетерминированные по умолчанию и прямо предупреждает: даже когда параметр seed и идентификатор конфигурации system_fingerprint совпадают, разброс в ответах всё ещё встречается (документация Microsoft Learn о воспроизводимом выводе, обновление от 27.02.2026). Инструменты воспроизводимости дают «преимущественно похожие», а не гарантированно идентичные ответы.

Но одинаковый текст и правильный ответ — вообще не одно и то же.

Модель может десять раз подряд воспроизвести одну и ту же ошибку. Такой результат будет повторяемым, но не надёжным. Поэтому в корпоративной системе контролируют не формулировку ответа, а другое:

• откуда взялись сведения;
• прошёл ли ответ проверки;
• достаточно ли данных для вывода;
• что произойдёт при сомнении;
• кто отвечает за окончательное решение.

Предсказуемость — свойство системы, а не модели

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

Предсказуемый контур складывается из восьми уровней, и модель занимает в нём ровно один:

Дальше — каждый уровень подробнее.

Правила должны жить не только в промпте

Предположим, ИИ обрабатывает входящие документы и определяет дальнейший маршрут. В промпте можно написать:

«Если сумма превышает миллион рублей, направь документ на согласование руководителю подразделения, а после его согласования — финансовому директору».

Модель, скорее всего, поймёт инструкцию. Но проверку лимита всё равно лучше выполнить обычной программой.

Это простое условие. Оно должно одинаково работать при любой формулировке документа, любой версии модели и любой длине контекста. Его легко протестировать и восстановить по журналу.

Хорошая архитектура разделяет задачи:

• модель извлекает сумму из неструктурированного документа;
• программа проверяет тип и диапазон значения;
• справочник определяет валюту и юридическое лицо;
• правило выбирает маршрут согласования;
• человек разбирает спорный случай.

ИИ работает там, где требуется интерпретация. Детерминированные компоненты отвечают за точные вычисления, лимиты, маршруты и запреты.

Чем выше цена ошибки, тем меньше критичных правил должно существовать только в виде текста внутри промпта.

Справочники ограничивают пространство для фантазии

Допустим, модель должна определить вид договора.

Можно попросить её самостоятельно придумать подходящую категорию. Тогда в одном случае она напишет «договор поставки», в другом — «контракт на поставку», а в третьем создаст более узкую категорию, которой нет в корпоративной системе. Для человека разница несущественна. Для интеграции с ECM (система управления корпоративным контентом и документами) или CRM это три разных значения, и два из них не найдут соответствия.

Поэтому модель должна выбирать из разрешённого справочника:

• поставка;
• оказание услуг;
• аренда;
• подряд;
• другое;
• не удалось определить.

Наличие варианта «не удалось определить» особенно важно. Без него система подталкивает модель к догадке даже там, где данных недостаточно.

Справочник не делает модель умнее. Он делает результат пригодным для процесса.

RAG привязывает ответ к корпоративным источникам

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

RAG (retrieval-augmented generation, генерация с опорой на поиск) решает часть этой проблемы. Система сначала ищет подходящие фрагменты во внутренних документах, а затем передаёт их модели вместе с вопросом. Ответ строится не только на знаниях модели, но и на найденном контексте.

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

Это заметно снижает риск выдумки, но не устраняет его. Если поиск вернул старую редакцию регламента, нерелевантный фрагмент или только половину нужной таблицы, модель построит неверный вывод на плохом основании. Документация Microsoft Foundry фиксирует это как известное ограничение: качество RAG зависит от подготовки контента, настройки поиска и промпта, а при нерелевантной или неполной выдаче модель способна дать неполный или неточный ответ несмотря на найденный контекст.

Поэтому контролировать нужно две вещи по отдельности:

1. Нашла ли система правильные документы.
2. Соответствует ли ответ содержанию этих документов.

Само наличие RAG или векторной базы ещё не делает ответ надёжным.

Формат ответа — это контракт с процессом

Свободный текст удобен человеку, но неудобен информационной системе. Если ответ модели должен уйти в CRM, 1С, TMS (система управления перевозками) или систему документооборота, его структуру лучше определить заранее. Например:

• тип документа;
• номер;
• дата;
• сумма;
• валюта;
• контрагент;
• найденные расхождения;
• ссылка на источник;
• уровень уверенности;
• требование ручной проверки.

Модель должна вернуть значения в заданной схеме, а не написать небольшое эссе о документе. Современные платформы это поддерживают: в Google Cloud есть управляемый структурированный вывод — ответ ограничивается заранее описанной JSON-схемой, и данные из него можно забирать без постобработки.

Но соблюдение формата ещё не означает правильность содержания. Система отдельно проверяет:

• заполнены ли обязательные поля;
• соответствует ли дата допустимому формату;
• существует ли контрагент в справочнике;
• совпадает ли итоговая сумма с суммой позиций;
• присутствует ли подтверждающий источник;
• не вышло ли значение за допустимый диапазон.

Если проверка не пройдена, результат не должен молча уходить дальше по процессу.

Порог уверенности: одной самооценки модели недостаточно

Можно попросить модель написать: «Я уверена в ответе на 92%». Само по себе это число — только один сигнал, и опираться на него как на единственное основание для автоматического продолжения процесса нельзя: оценка формируется той же генерацией, что и ответ, и высокая уверенность встречается у ошибочных выводов.

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

• насколько релевантны найденные документы;
• нашлись ли все обязательные сведения;
• подтверждаются ли ключевые утверждения источниками;
• прошёл ли ответ формальные проверки;
• совпали ли результаты независимых проверок;
• встречалась ли похожая ситуация в тестовой выборке;
• относится ли действие к категории повышенного риска.

На основании этих сигналов система выбирает сценарий:

• качество достаточное, цена ошибки невелика — процесс продолжается автоматически;
• ответ возможен, но требует проверки — система показывает сотруднику результат, источник и обнаруженные сомнения;
• данных недостаточно — система отказывается от содержательного ответа и сообщает, чего именно не хватает.

Это важная характеристика корпоративного ИИ: хороший ответ не всегда является текстом. Иногда правильный результат — остановиться.

Сами пороги не универсальны. Их устанавливают под конкретный процесс, исходя из цены ошибки и обратимости действия, и пересматривают по результатам работы на контрольной выборке.

Как должен выглядеть отказ от ответа

Плохой сценарий:

«Вероятно, договор должен согласовать финансовый директор».

Слово «вероятно» не делает решение безопаснее. Сотрудник всё равно воспримет его как рекомендацию системы.

Хороший сценарий выглядит иначе:

«Не удалось определить согласующего. В найденном регламенте нет правила для договоров этого типа. Требуется проверка владельцем процесса».

Ещё лучше, если система укажет:

• какие документы она проверила;
• каких сведений не хватает;
• кому передан вопрос;
• какое действие было остановлено.

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

Где решение обязательно остаётся за человеком

Универсального списка не существует: граница зависит от цены и обратимости ошибки. Но принцип понятный — чем серьёзнее последствия, тем меньше автономии следует отдавать модели.

Человеку нужно передавать решение, если оно:

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

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

Это не осторожность ради осторожности. NIST в профиле рисков генеративного ИИ (NIST AI 600-1, июль 2024) выделяет конфабуляции — уверенно сформулированный ложный или ошибочный контент — отдельным классом рисков и отмечает, что пользователи склонны действовать на основании такого содержания. Human-in-the-loop, участие человека в контуре принятия решения, — не признак слабой технологии, а нормальная архитектура управления риском.

Что можно и чего нельзя гарантировать

Разговор о гарантиях полезно начинать с того, чего гарантировать нельзя, — иначе заказчик услышит обещание, которого никто не давал.

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

Не отдельный чат, а управляемый контур

В Daturum мы проектируем не окно, куда сотрудник вводит вопрос. Вокруг модели появляется рабочий контур: корпоративные источники, права доступа, справочники, правила, структурированный вывод, автоматические проверки, пороги передачи человеку и аудит действий. Как этот контур собирается по фазам — от концепции до промышленной эксплуатации — описано в методологии AI Factory.

Начинаем обычно с небольшой выборки реальных примеров. Проверяем не только то, может ли модель дать хороший ответ, но и более неприятные случаи:

• что она делает при неполном документе;
• как реагирует на противоречащие друг другу источники;
• умеет ли отказаться от ответа;
• выполняет ли обязательные правила;
• можно ли восстановить причину результата;
• насколько часто требуется участие сотрудника.

После такой проверки становится понятно, где модель действительно полезна и какой уровень автономности ей можно дать. Как это выглядит на реальных системах, видно в реализованных проектах; измеримые обязательства по качеству мы фиксируем в гарантиях с KPI и SLA.

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

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

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

Частые вопросы

Можно ли сделать языковую модель полностью детерминированной?

Нет, если речь о гарантии на уровне модели. Параметр seed и фиксированные настройки генерации дают преимущественно похожие ответы, но Microsoft прямо предупреждает, что даже при совпадении seed и system_fingerprint разброс встречается. Детерминированным делают контур вокруг модели: разрешённые источники, справочники, схема ответа, программные проверки и правила остановки.

Достаточно ли выставить температуру в ноль и написать строгий промпт?

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

Гарантирует ли RAG достоверность ответа?

Нет. RAG привязывает ответ к корпоративным документам и заметно снижает риск выдумки, но качество зависит от подготовки контента, настройки поиска и промпта. При нерелевантной или неполной выдаче модель способна дать неточный ответ даже при наличии найденного контекста — это зафиксировано в документации Microsoft Foundry. Проверять нужно и то, какие документы нашлись, и то, соответствует ли им ответ.

Можно ли доверять оценке уверенности, которую модель называет сама?

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

Что делать, если системе не хватает данных для ответа?

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

С чего начать у себя

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

Именно так устроен Hyperfast Presale — рабочая сессия, по итогам которой мы за 2–24 часа собираем прототип на ваших данных. Разбор процесса и выборки — ask@daturum.ru.

Источники

• Microsoft Learn. How to generate reproducible output with Azure OpenAI — недетерминированность ответов по умолчанию, параметры seed и system_fingerprint, отсутствие гарантии воспроизводимости. Обновление документа: 27.02.2026. https://learn.microsoft.com/en-us/azure/foundry-classic/openai/how-to/reproducible-output
• Microsoft Learn. Retrieval augmented generation (RAG) and indexes, раздел Known limitations — зависимость качества RAG от подготовки контента, настройки поиска и промпта; неточные ответы при неполной выдаче. Обновление документа: 20.05.2026. https://learn.microsoft.com/en-us/azure/foundry/concepts/retrieval-augmented-generation
• Google Cloud Documentation. Structured output — ограничение ответа модели заранее описанной JSON-схемой. https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/capabilities/control-generated-output
• NIST. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1), июль 2024, раздел 2.2 «Confabulation». https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

Опубликовано 25 июля 2026 года. Факты проверены 23 июля 2026 года.

Об авторе