Почему ошибки LLM становятся бизнес-риском и как с этим бороться?

Все пользователи ИИ знают, что он может ошибаться. Но настоящая проблема не в том, что он ошибается, а в том, что делает это убедительно. Когда речь идет о бизнесе, галлюцинации LLM из технической особенности превращаются в финансовый риск. Александр Перевалов, руководитель группы разработки ИИ GreenData, объясняет, почему корпоративным системам нужен не просто хороший промпт, а архитектура контроля ИИ.

Почему LLM галлюцинируют

Термин «галлюцинация» в контексте языковых моделей означает правдоподобный, но фактически неверный ответ. Это может быть простое искажение, а может быть полностью выдуманная информация (причем в одном абзаце с реальными и точными данными). Чтобы понять, почему так происходит, нужно разобраться, как происходит генерация.

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

В ее параметрах смешаны языковые закономерности, частотные связи, примеры из обучения и усвоенные шаблоны. Есть то, что она «видела» много раз и воспроизводит точно. Есть то, что она видела в похожем контексте и достраивает по аналогии. Есть то, чего она не знает — но что звучит правдоподобно в рамках запроса. Это частично заложено в обучении. OpenAI, например, упоминали, что логика обучения могла поощрять модель за уверенную догадку без источника: в эксперименте модель «OpenAI o3» попросили дать ответ на основе изображения, не подкладывая его в контекст, в результате 86,7% ответов модели были даны уверенно, но фактически бездоказательно. Это поведение было исправлено в GPT-5 – доля уверенных, но бездоказательных ответов составила всего 9% [1].

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

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

Почему это критично в enterprise

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

Масштабирование

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

Закрепление в процессах

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

Повышенное доверие к ответу

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

Асимметрия ущерба

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

Метрики: как оценить ответы LLM

Если галлюцинации неизбежны, как понять, где система работает надежно, а где начинает ошибаться? Надежность нельзя свести к одной метрике. Скорее это соответствие к комплексу требований. К базовым относятся доля верных ответов (accuracy), частота фактических ошибок (hallucination rate), то, насколько ответ опирается на проверенные источники (grounding), строгость следования источникам (не привносит ли система утверждения, которых нет в исходных данных), качество поиска (находит ли система релевантные материалы), точность отдельных утверждений внутри ответа и способность корректно отказываться от ответа при нехватке оснований.

Для расчета этих метрик нужен ground truth — эталонные данные или «правильные» ответы, с которыми сравнивается результат модели. В корпоративных системах ground truth формируется из внутренних документов, структурированных данных и экспертных оценок. Однако на практике этого может быть недостаточно: документы могут устаревать, противоречить друг другу или не покрывать все возможные кейсы. Экспертные ответы тоже могут различаться в зависимости от контекста. Это означает, что даже формально «правильная» метрика может не всегда отражать реальную полезность ответа.

Кроме того, сами метрики имеют ограничения. Например, сотрудник спрашивает HR-ассистента: «Могу ли я взять отпуск за свой счет на две недели?». Модель отвечает: «Да, отпуск за свой счет возможен на срок до 30 дней с согласия руководителя». Accuracy высокая — такой пункт действительно есть в регламенте, ответ совпадает с эталоном. Hallucination rate низкий — модель ничего не выдумала. Grounding высокий — ответ опирается на реальный документ. Но фактически регламент обновили три месяца назад, и теперь максимум 5 дней, и нужно согласование HR, а не только руководителя. Новый документ просто не попал в базу знаний системы. Сотрудник уходит с неверной информацией. Стоит заметить, что проблематика устаревших источников лежит не в контуре модели, а в периметре обвязки, которая ее окружает. В данном случае это процесс своевременной переиндексации базы знаний.

Допустим, система отвечает на 100 запросов: 95 раз правильно и 5 раз с ошибками. Метрики выглядят хорошо — высокий accuracy, низкий hallucination rate, ответы опираются на базу знаний. Но среди этих редких ошибок может быть критичная. Скажем, модель отвечает, что менеджер может дать клиенту скидку 20% без согласования, хотя по правилам — только до 10%. Ошибка единичная, но приводит к прямым финансовым потерям. Это типичный пример, когда технические метрики не стыкуются с бизнесом и пользовательским опытом.

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

Как настроить контроль в LLM

Часто задачу пытаются упростить — например, через самопроверку модели (self-check). Сравнение нескольких ответов действительно помогает выявить сомнительные места. Если модель «знает», ответы сходятся. А если начинает выдумывать — расходятся. Но это лишь сигнал, а не доказательство. Модель может последовательно воспроизводить одну и ту же ошибку, и без внешней проверки плохо справляться с самокоррекцией. Поэтому self-check используют как датчик — чтобы отправить ответ на дополнительную проверку или понизить уровень доверия. Но не как самостоятельный механизм надежности. Решить архитектурную проблему на уровне одной модели не получится.

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

1. Опора на проверенные данные компании

Модель должна отвечать не «из памяти вообще», а по тем документам, регламентам, записям и справочникам, которым компания готова доверять. Поэтому основа контура — RAG (Retrieval-Augmented Generation): перед генерацией ответа система извлекает релевантные фрагменты из корпоративных источников и ограничивает модель именно ими. На практике это означает инвестиции в качество базы знаний.

2. Прозрачность оснований

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

3. Правила допустимого поведения

Система должна уметь отказываться от ответа при нехватке оснований. Или помечать низкую уверенность, ограничивая себя рамками найденных документов. Отказ от ответа — не сбой, а штатный предохранитель. Технически это реализуется через ограничения (constraints), которые снижают вероятность галлюцинаций: запрет на домысливание, строгая привязка к источникам, контроль формата и содержания ответа.

4. Внешняя проверка перед критическим действием

Если ответ влияет на договор, клиента, деньги, доступ или соответствие требованиям — нужен дополнительный контур: проверка правилами, сверка с источниками, отдельный модуль контроля или человек. Участие человека — нормальный архитектурный элемент, а не признак технологической отсталости. Этот принцип известен как human-in-the-loop. Человек включается в процесс там, где цена ошибки превышает допустимый уровень риска.

5. Защита входа и выхода

Международная некоммерческая организация OWASP, которая разрабатывает общепринятые рекомендации по безопасности IT-систем, относит к базовым угрозам для LLM-приложений подмену инструкций через пользовательский ввод, утечки чувствительных данных и небезопасную обработку вывода. Минимально безопасная архитектура должна включать разграничение входных данных, защиту подключенных инструментов, фильтрацию вывода и ограничение прав на действия.

6. Аудит действий и непрерывная оценка

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

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

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

Автор: Александр Перевалов, руководитель группы разработки ИИ GreenData.