[Перевод] Объяснение галлюцинаций LLM

Большие языковые модели, типа GPT, Claude, Gemini и другие ИИ-системы, поразили разработчиков своей способностью генерировать тексты, звучащие как человеческие. Однако, если вы когда-либо использовали ChatGPT или подобные инструменты, вероятно, они не раз уверенно говорили вам что-то совершенно неверное. Эти ошибки ИИ, часто называемые «галлюцинациями», варьируются от незначительных фактических ошибок до полных выдумок. Они могут быть забавными (например, ИИ изобретает вымышленный исторический факт) или представлять серьезную проблему (представьте, что ИИ-ассистент предлагает несуществующую функцию или чат-бот выдает медицинский совет, которого не существует).

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

Что такое галлюцинации?

Галлюцинация ИИ — это когда модель выдумывает информацию. Она генерирует текст, который звучит убедительно и уверенно, но не основан на правде или надежных данных. Это аналог того, когда человек уверенно говорит неправду. Например, если языковую модель спросить: «Кто создал Stranger Things?», она может ответить: «Stranger Things был создан Дж. Дж. Абрамсом и премьера шоу состоялась на Netflix в 2016 году». Ответ звучит правдоподобно (известный режиссер, правильная платформа для потокового вещания), но это полностью неверно (Stranger Things создали братья Даффер). Подумайте об этом как о студенте, который не учился, но выдумывает убедительные ответы на экзамене. Модель не пыталась соврать, она просто составила правдоподобный ответ на основе шаблонов, изученных на этапе обучения, без реальной возможности проверки фактов.

Галлюцинации могут появляться в любом контексте. Чат-бот может выдумать личные данные о вас, помощник по вопросам и ответам может сослаться на несуществующие научные статьи, а генератор кода может предложить функции, которые звучат реальными, но не присутствуют в API. В одном известном случае ChatGPT даже выдумал обвинения против реального человека в юридическом резюме, что привело к иску. В юридической сфере использование ИИ-сгенерированного контента без проверки фактов стало причиной проблем — некоторые юристы были наказаны после того, как ИИ «выдумал» фальшивые прецеденты, которые они неосознанно представили в суд. Очевидно, что галлюцинации это не просто академическая ошибка. Они могут подорвать доверие, привести к ошибкам в программном обеспечении или создать серьезные последствия в реальной жизни, если их не контролировать.

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

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

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

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

Поскольку LLM по сути всего лишь сверхмощный автозавершатель, у нее нет встроенного чувства различия между правдой и ложью. Она не «знает» фактов, как база данных; она только знает, как люди склонны говорить о фактах. Это как человек, который не знает истории, но прочитал тысячи исторических книг и может имитировать стиль историков.

Чаще всего общие шаблоны приводят к правильным ответам (модель видела много примеров «Stranger Things созданы братьями Даффер»), но когда данных недостаточно или они неоднозначны, модель делает обоснованную догадку. И, в отличие от человека, ИИ не нервничает, когда не уверен. Он не краснеет, не заикается и не проявляет признаков сомнений. Он представит свою догадку с такой же уверенностью, как и известный факт.

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

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

Галлюцинации в различных приложениях

Галлюцинации могут проявляться по-разному в зависимости от того, для чего используется LLM.

Рассмотрим несколько сценариев:

1. Фактические вопросы и чат-боты. Здесь галлюцинации часто означают неверные факты или утверждения. Если задать чат-боту вопрос вроде «Какая столица вымышленной страны?», он может уверенно назвать несуществующий город. Или приписать известную цитату не тому человеку. В чат-ботах поддержки пользователей галлюцинации могут привести к предоставлению неправильной информации о политике компании. Риском здесь является распространение дезинформации, пользователи могут принять ответ за чистую монету.

2. Генерация кода. Для помощников разработчиков, таких как GitHub Copilot или LLM через API, галлюцинации проявляются как правдоподобный, но неверный код. Модель может вызвать функции, которые звучат как нужные вам, но их не существует, или использовать API неверно. Она может также создать код, который не компилируется или имеет уязвимости в безопасности, при этом выглядит разумным. Поскольку LLM обучаются на большом объеме кода, они обычно генерируют синтаксически правильный код, что может ввести в заблуждение, потому что ошибка проявляется только при его выполнении. Недавний анализ безопасности даже предупреждал, что слепое использование сгенерированного ИИ-кода может привести к скрытым уязвимостям.

3. Креативное письмо и рассказы. При использовании LLM для творческих задач (например, написания художественных произведений, мозгового штурма и т.д.) галлюцинация не обязательно является «ошибкой» (в конце концов, в рассказе мы ожидаем вымышленный контент). Однако даже в нарративе галлюцинации могут стать проблемой, если модель нарушает логику или указания в сюжете. Например, если вы попросите короткий рассказ о средневековом рыцаре, и в какой-то момент ИИ неожиданно вводит современный автомобиль, это будет своего рода галлюцинацией, т. е. несоответствие с намеренным контекстом. В длинных сгенерированных текстах персонажи могут внезапно знать вещи, которых не должны, или сюжет может включать совершенно не относящиеся к делу элементы.

4. Уверенный тон vs Реальное знание. Во всех этих случаях отличительной чертой галлюцинации LLM является несоответствие между тем, насколько уверенным и подробным выглядит ответ, и тем, насколько он правдив. Модель часто будет настаивать на своем ответе, если задать уточняющие вопросы, потому что она не осознает своей ошибки. Это может сбить с толку как пользователей, так и разработчиков.

   

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

Стратегии смягчения галлюцинаций

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

Представьте это как управление выдающимся, но иногда ненадежным сотрудником. Вы предоставляете ему справочные материалы, проверяете его работу, устанавливаете четкие правила и обучаете его с течением времени, чтобы он становился более точным. Вы бы не позволили новичку отправлять важные письма клиентам без предварительной проверки, и точно так же не стоит позволять ИИ-системам предоставлять критическую информацию без должной проверки. Мы рассмотрим несколько ключевых стратегий — все они «бесплатные» в том смысле, что это алгоритмические или процедурные корректировки, которые можно применить без необходимости использования проприетарных данных. Это включает внедрение реальных данных в процесс генерации, тонкую настройку моделей для улучшения поведения, умелое создание запросов, добавление правил проверки, оценку уверенности модели и даже разрешение модели критиковать себя. Сочетая эти методы, можно значительно улучшить надежность LLM.

Давайте рассмотрим их по порядку.

Генерация с дополненной выборкой (RAG) — привязка ИИ к реальным данным

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

Представьте, что вам задают вопрос: «Кто был президентом США в 1881 году?» Если у вас нет ресурсов, вы можете сделать догадку и, возможно, ошибиться. Но если быстро заглянуть в историческую книгу, можно уверенно ответить (это был Джеймс А. Гарфилд в первой половине 1881 года, а затем Честер А. Артур). RAG дает модели этот «открытый учебник» для справки. Вместо того чтобы галлюцинировать, модель может процитировать или подытожить извлеченную информацию.

Как это работает на практике для разработчиков? Обычно pipeline RAG использует что-то вроде векторной базы данных или поискового API для нахождения документов, связанных с запросом пользователя. Например, если пользователь спрашивает о политике компании, система может извлечь соответствующий раздел документа политики компании. Извлеченный текст затем добавляется к запросу (или иначе используется), и модель запрашивает генерирование ответа с учетом этого контекста. Поскольку ответ теперь основан на реальном справочном тексте, вероятность случайных выдумок значительно снижается. Модель, как правило, придерживается предоставленных фактов.

Ключевым моментом является то, что хорошо реализованная система RAG часто показывает использованные источники, что добавляет прозрачности. Например, некоторые приложения отображают фрагменты текста, из которых был извлечен ответ. Это помогает пользователям доверять ответу (или проверять его самостоятельно). RAG быстро становится популярным решением в корпоративных ИИ-приложениях, потому что решает сразу две проблемы: ограниченность знаний модели/устаревшие обучающие данные и проблему галлюцинаций. Привязывая LLM к актуальной и релевантной информации, мы ограничиваем ее склонность к импровизациям без фактической основы.

Конечно, RAG не является панацеей. Если ваша база знаний неполная или если этап извлечения не находит нужной информации, модель все равно может галлюцинировать или использовать свои общие знания. Кроме того, комбинирование извлечения и генерации добавляет сложность — нужно поддерживать индекс знаний и убедиться, что извлечение информации релевантно. Но на практике RAG значительно повышает надежность при выполнении таких задач, как поддержка клиентов (бот ссылается на текст политики компании) или помощники по коду (бот ссылается на документацию для API, а не угадывает использование). Для многих разработчиков RAG — это первая линия обороны против галлюцинаций. Не позволяйте модели гадать, позвольте ей искать ответ.

Тонкая настройка (дообучение) и выравнивание — обучение модели быть более правдивой

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

Дообучение это не только добавление фактов; она также может научить модель определенному поведению. Один из популярных методов — обучение с подкреплением на основе человеческой обратной связи (RLHF) — использованный при обучении ChatGPT, где люди оценивают результаты работы модели, а модель настраивается так, чтобы предпочитать ответы, которые не только полезны, но и правдивы. Если в процессе этой обратной связи модель наказывается за галлюцинации или вознаграждается за то, что говорит «Я не знаю», когда это уместно, она может научиться быть более осторожной при предоставлении неопределенных ответов. Модели OpenAI, например, были настроены так, чтобы часто отвечать отказом или оговоркой, а не выдавать случайные ответы на определенные вопросы. Именно поэтому ChatGPT может сказать «Извините, у меня нет информации по этому вопросу» для очень редких вопросов — это поведение было обучено.

Существуют также специализированные подходы к тонкой настройке, направленные на фактическую точность. Некоторые исследовательские проекты создают наборы данных с известными проблемами или ложными утверждениями и обучают модель исправлять их. Другие используют контрастную тонкую настройку (иногда называемую «переговорной» или «настройкой инструкций»), где модель обучается с явными инструкциями избегать неподтвержденных утверждений. Например, инструкции вроде: «Если вы не уверены в каком-то факте, явно скажите, что вы сомневаетесь». За множество примеров модель может усвоить эвристику, чтобы не выдумывать детали.

Кроме полной тонкой настройки модели, разработчики могут использовать более легкие методы настройки, такие как LoRA (Low-Rank Adapters) или настройка запросов на меньших наборах данных, чтобы изменить стиль модели. Эти методы можно использовать, чтобы сделать модель более сжато-выраженной (меньше вероятности скатываться в галлюцинации) или направить ее на вывод ответов, которые содержат ссылки только на исходные материалы.

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

Инжиниринг запросов — как правильно задавать вопросы для получения надежных ответов

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

Один простой метод явно поручить модели быть правдивой и признавать незнание. Например, вместо того чтобы просто задать открытый вопрос, можно сказать: «Ответьте на следующий вопрос, используя предоставленный контекст. Если ответ не содержится в контексте или вы не уверены, скажите ‘Я не знаю’». Это дает модели четкое правило, которому нужно следовать. Хотя не все модели будут соблюдать это правило идеально, многие, по крайней мере, будут более неохотно заполнять пустоты выдуманным контентом, если вы скажете им этого не делать. Запрос модели на показ своей логики тоже может помочь, например: «Думайте шаг за шагом и убедитесь, что каждый шаг основывается на известных фактах, прежде чем дать окончательный ответ». Для некоторых моделей такой запрос с рассуждениями приводит к более точным ответам, потому что модель «проходит» через процесс рассуждения, что позволяет исправить очевидные ошибки по пути.

Еще один эффективный подход к инжинирингу запросов — это показать модели примеры честных и точных ответов. Эта техника, называемая «few-shot prompting», обучает модель через демонстрацию. Например:

Q: Who discovered penicillin? A: Alexander Fleming discovered penicillin in 1928. Q: Who is the author of the novel Moby-Dick? A: Herman Melville wrote Moby-Dick, published in 1851. Q: What is the boiling point of water in Celsius? A: The boiling point of water at standard atmospheric pressure is 100°C (212°F). Q: (Your actual question here) A:

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

Инжиниринг запросов также охватывает системные сообщения или инструкции роли в чат-ориентированных моделях. Если вы используете API, где можно задать системный запрос, можно написать такие инструкции, как: «Вы — полезный помощник, который всегда подкрепляет утверждения доказательствами и никогда не выдумывает информацию. Если вы чего-то не знаете, вы ясно говорите, что не знаете». Это создает склонность в ответах модели к осторожности и опоре на доказательства. Хотя это не является гарантирующим решением (модель может все еще галлюцинировать, не осознавая этого), это формирует стиль ответа и может сократить количество ложных деталей.

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

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

Правила пост-обработки и контрольные механизмы — поймать ошибки до того, как они станут проблемой

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

Простой пример контрольного механизма: после получения ответа от LLM можно провести проверку на наличие URL или ссылок, которые она предоставила. Если модель говорит «согласно исследованию xyz (Smith, 2022)…», ваша система может попытаться проверить, существует ли такое исследование в базе данных или через быстрый поиск в интернете. Если оно не существует, вы поймали вероятную галлюцинацию (LLM нередко выдумывали академические ссылки!). Затем вы можете либо попросить модель попытаться снова, либо отметить ответ с оговоркой.

Для генерации кода подход с правилами может быть таким: компилировать или запускать тесты на сгенерированном коде в песочнице. Если код не компилируется или вызывает ошибки, это означает, что вывод модели был неверным. Некоторые инструменты могут даже вернуть ошибку модели, побуждая ее исправить код. Этот тип «самовосстановления» использует жесткий внешний сигнал (код не запустился), чтобы исправить галлюцинацию (код был неверным или вызывал несуществующие функции).

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

Современные библиотеки «защитных барьеров» для ИИ (такие как Microsoft Guidance или системные сообщения OpenAI) позволяют задавать эти правила гибким образом. Например, можно потребовать, чтобы определенные ключевые слова из запроса присутствовали в ответе. Если пользователь спросил о X, а ответ даже не упоминает X, возможно, модель ушла от темы (или галлюцинировала интерпретацию самого вопроса). Точно так же можно использовать защитные барьеры, чтобы гарантировать, что вывод модели остается в пределах предоставленных исходных материалов. Любая информация, не основанная на источнике, считается «недостоверной» и может быть отфильтрована.

Еще одна техника это использование внешних источников знаний после получения ответа для проверки фактов. Допустим, модель отвечает на фактический вопрос без извлечения данных (например, потому что у вас нет базы знаний). Вы можете взять ключевое утверждение и выполнить поисковый запрос, чтобы проверить, подтверждают ли его авторитетные источники. Если нет, вы относитесь к этому как к подозрительному ответу. Это похоже на быструю проверку фактов модели. Это не всегда легко преобразовать произвольный ответ в проверяемый запрос, но для числовых ответов или конкретных утверждений это может работать довольно хорошо.

Красота подходов на основе правил заключается в детерминированности. У вас есть явный контроль, и вы можете с полной уверенностью применять определенные меры безопасности. Они не поймают все ошибки (необходимо предсказать, какие именно ошибки нужно ловить), но они являются отличным «запасным вариантом». По сути, можно рассматривать это как процесс рецензирования ответа модели — даже если модель «звучала» уверенно, ваша программа может сказать: «Подождите, соответствует ли этот ответ нашим критериям доверия? Если нет, обработаем это соответствующим образом». Это может привести к запросу на уточнение, добавлению оговорки или, в некоторых случаях, просто отказу от ответа, если его вероятность ошибки слишком велика.

Оценка уверенности и оценка неопределенности — как понять, когда вы чего-то не знаете

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

LLM генерируют текст, присваивая вероятности возможным следующим словам. Если в какой-то момент модель была очень неуверенной (например, несколько слов имели схожие низкие вероятности, и ей пришлось выбрать одно), это может указать на то, что она находится в незнакомой области — потенциальный момент для галлюцинации. Некоторые исследователи пытались использовать собственные логарифмические вероятности модели, чтобы отмечать участки с низкой уверенностью. Например, если распределение вероятностей модели было очень плоским, когда она генерировала имя человека или какое-то другое данные, возможно, она просто выбрала что-то произвольно. В системе можно установить порог, если уверенность модели в полном ответе ниже определенного уровня, возможно, не стоит доверять этому ответу. Этот подход, хотя и перспективный, сложен, потому что сырые вероятности не всегда идеально отражают уверенность в правде (модель может быть уверена, но ошибаться — что является худшим случаем!). Тем не менее, это подсказка.

Другой подход использовать ансамбль ответов моделей. Вы задаете тот же вопрос модели (или нескольким экземплярам модели с разными случайными начальными значениями) несколько раз. Если модель говорит правду, ответы, скорее всего, будут сходиться (поскольку истина выступает как аттрактор). Если модель галлюцинирует, вы можете получить разные выдуманные ответы каждый раз. Например, задайте вопрос «Какая популяция Марса?» пять раз, и, скорее всего, вы получите пять разных цифр (все, конечно, неверные). Если ваша система обнаружит большую изменчивость в ответах, это признак низкой надежности. Тогда можно либо не предоставлять ответ, либо представить диапазон ответов с оговоркой. Это связано с техникой, называемой самосогласованностью, когда рассуждения модели несколько раз «выбираются», и только согласованный ответ принимается как окончательный.

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

Еще одна умная идея заставить модель пересмотреть свой ответ. После того как модель даст ответ, вы можете попросить ее (или второй экземпляр модели): «По шкале от 1 до 10, насколько уверены вы, что ваш ответ верен и почему?» Удивительно, но иногда модель признает свою неопределенность после размышления и даже укажет на возможные ошибки. Например, она может сказать: «Я не совсем уверен в дате рождения, которую я дал, она может быть неверной». Эта самопроверка может служить как оценка уверенности. Если модель дает низкую оценку или указывает на ошибку, можно попросить ее исправить ответ или просто не использовать этот ответ.

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

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

Саморефлексия и итеративное улучшение — позвольте модели проверить свою работу

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

Один из подходов это самосовершенствование. Вы задаете модели что-то вроде: «Вот ваш ответ. Теперь дважды проверьте каждый факт в нем. Если вы найдете неподтвержденное утверждение, исправьте его». Модель затем проходит по своему ответу и часто выявляет предложения, которые могут быть сомнительными. Она может сказать: «После проверки я осознал, что утверждал X как факт, но я не совсем уверен, что это правильно. Я скорректирую это» и затем предоставить исправленный ответ. Это работает удивительно хорошо в некоторых случаях. Акт рефлексии кажется уменьшающим стремление модели блефовать. Как бы генерируя ответ, а затем смотря на него после, модель получает второй шанс поймать ошибки. Исследования показали, что такая саморефлексия в сочетании с извлечением информации может значительно уменьшить количество галлюцинаций, особенно в задачах с многоступенчатым рассуждением.

Другой метод это цепочка рассуждений с самосогласованностью. Ранее мы упоминали о выполнении нескольких цепочек рассуждений. На практике можно попросить модель сгенерировать подробное пошаговое рассуждение (которое может включать проверки, например, «знаю ли я этот факт?»), а затем посмотреть, остается ли конечный ответ согласованным каждый раз. Выбирая наиболее распространенный результат или прося модель исправить различия, можно получить более надежный ответ. По сути, вы используете собственные рассуждения модели для самопроверки.

Есть также концепция «помощник-наблюдатель». Вы создаете один экземпляр модели, который предлагает ответ, и другой экземпляр (возможно, с запросом, чтобы он вел себя как критик или проверяющий факты), который анализирует этот ответ. Модель-критик может поймать очевидную галлюцинацию и сказать, например: «В ответе выше утверждается, что AngularJS был выпущен в 2010 году, но я помню, что это было в 2012. Это может быть неверно». Вы можете затем передать этот отзыв в исходную модель, чтобы она исправила ответ. Эта двухмодельная установка похожа на пару программирования с ИИ или второе мнение. Она использует идею, что хотя одна модель может ошибиться, две модели, которые проводят проверку, могут заметить ошибки друг друга.

Еще одна вариация интерактивный запрос. Вместо того, чтобы пользователь задавал вопрос один раз и получал один ответ, можно спроектировать систему для многократного взаимодействия. Модель отвечает, затем система (или пользователь) задает уточняющий вопрос «Вы уверены в X? Как вы пришли к этому выводу?», и модель должна обосновать или пересмотреть свой ответ. Этот диалог может подтолкнуть модель либо предоставить обоснование с источниками (если они есть), либо вернуться на шаг назад и пересмотреть что-то, что она выдумала. В каком-то смысле это похоже на то, как вы можете попросить эксперта быть уверенным, что они не делают предположений и если они не могут предоставить твердые доказательства или аргументы, вы начинаете сомневаться в их ответе.

Эти техники саморефлексии часто пересекаются с более ранними методами. Например, саморефлексия может вызвать извлечение информации (модель может сама попросить доказательства, что может стать еще одним запросом на извлечение) или взаимодействовать с проверками на основе правил («дайте мне проверить против известных данных»). Границы стираются, но основная идея заключается в использовании интеллекта LLM для самоулучшения. В конце концов, эти модели довольно хороши в задачах с языком, так почему бы не поручить им задачу корректуры и проверки фактов?

Стоит отметить, что саморефлексия требует больше вычислительных ресурсов (вы фактически делаете несколько проходов генерации), и она не гарантирует, что все будет поймано. Некоторые ложные утверждения могут показаться приемлемыми для модели даже при саморефлексии, если она сильно «верит» в них из-за предвзятости обучения. Тем не менее, исследования и практические реализации показали значительное снижение частоты галлюцинаций при использовании этих методов. Одно исследование смогло снизить частоту галлюцинаций модели с почти 47,5% до около 14,5% путем активного обнаружения участков с низким уровнем уверенности в генерации и исправления их в итеративном цикле. Это огромное улучшение, достигнутое с помощью процесса автоматического саморедактирования.

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

Собираем все воедино

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

Каждая из рассмотренных стратегий имеет свои плюсы и минусы, и на практике лучшим решением обычно является комбинация. Например, надежная система вопросов и ответов может извлекать документы (RAG), давать модели запрос с инструкцией «отвечать только по этим документам» (инжиниринг запросов), затем выполнять финальную проверку, сравнив утверждения в ответе с исходным текстом (пост-обработка по правилам), а также быстрое «проверочное» уточнение «Все ли в ответе поддерживается текстом?» (саморефлексия). При таком подходе вероятность того, что галлюцинация пройдет незамеченной, значительно снижается.

Также важно подбирать стратегию в зависимости от приложения. Для генерации кода ключевыми могут быть автоматическое тестирование и, возможно, тонкая настройка на корпусе правильного кода. Для чат-бота поможет четкое управление через инструкции и наличие библиотеки фактических ссылок. В креативных приложениях можно допускать больше галлюцинаций, так как они «творческие», но все равно использовать мягкие защитные барьеры для сохранения логичности сюжета. Контекст — кто ваши пользователи, какой риск галлюцинации и какие ресурсы доступны — будет определять ваш план смягчения.

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

Если вы хотите использовать LLM в аналитике без вечной ручной проверки, пригодится дисциплина работы с данными и промптами. На курсе «AI для аналитики и работы с данными» учимся извлекать инсайты без кода, автоматизировать отчёты и визуализации, а ещё собирать простых AI-агентов под метрики и гипотезы.

• 12 февраля, 20:00. «Почему AI уверенно врёт в аналитике и как его поймать». Записаться

• 19 февраля, 20:00. «5 задач аналитики, с которыми поможет AI». Записаться