Что побуждает LLM врать и как этого избежать в своих продуктах

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

Это действительно проблема, особенно если учесть, что LLM нельзя уволить или привлечь к ответственности. Особенности работы AI-систем таковы: они не имеют корыстного мотива для лжи и ничего не выигрывают от нее, но при этом, несмотря на кажущуюся разумность, они не являются людьми, поэтому и ответственность повесить на них нельзя.

Некоторые считают, что Retrieval-Augmented Generation (RAG) — это универсальное решение, но на самом деле этот подход устраняет только одну из причин проблемы и не помогает с остальными. Только комбинация нескольких подходов может дать какой-то результат.

Однако не всё потеряно. Есть способы справиться с этой проблемой, и давайте их рассмотрим.

Чтобы не углубляться в филосовские споры о том, что такое "галлюцинация", давайте определим три самых распространненых случая:

1. Модель понимает вопрос, но даёт неверный ответ.

2. Модель не понимает вопрос и поэтому даёт неверный ответ.

3. Вопрос не имеет однозначного ответа, и, следовательно, если вы не согласны с моделью, это не делает её ответ некорректным. Например, вопрос "Трамп или Байден?" — любой ответ будет просто мнением.

Начнём со второго случая. Вот причины, по которым модель может неправильно понять вопрос:

1. Вопрос некорректен (двусмыслен, недостаточно ясен и т.д.), а значит, и ответ будет некорректным. Это не вина модели — задавайте более качественные вопросы (посмотрите в сторону Few Shot prompting и тп). Забавно, но в фильме 'Я, робот' примерно то же самое AI голограмма говорит дектективу - "Извини, в ответах я органичен, правильно задавай свои вопросы".

2. Модели не хватает контекста.

3. Модель плохо понимает язык который вы используете

4. Не повезло, или, другими словами, распределение вероятностей привело рассуждения в странное направление.

Теперь перейдём к первому случаю: почему модель может "соврать", то есть дать фактически неверную и заведомо неправильную информацию, если она поняла вопрос?

1. Модель не следовала всем логическим шагам для вывода ответа.

2. Ей не хватило контекста.

3. Информация (контекст), которой она располагает, неверна.

4. У модели есть правильная информация, но она запуталась в ней.

5. Модель была обучена выдавать неправильные ответы (по политическим или другим причинам).

6. Не повезло: распределение вероятностей привело рассуждения в странное направление.

7. Модель настроена таким образом, что ей разрешено фантазировать (иногда это может быть желательным).

8. Overfitting или Underfitting: модель была обучена в конкретной области и пытается применить эту логику к другой области, что приводит к ошибочным выводам.

9. Модель перегружена данными и теряет контекст.

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

Модели не хватает контекста или информации, либо предоставленная информация некорректна или неполна.

Здесь на помощь приходит RAG (Retrieval-Augmented Generation). RAG, при правильной реализации, должен предоставлять модели необходимый контекст для ответа. Вот статья о том, как правильно внедрить RAG.

Важно сделать это правильно, с указанием всей необходимой метаинформации о структуре и атрибутах данных. Желательно использовать такие методы, как GraphRAG и повторную ранжировку (Reranking) на этапе извелечния (retreival), чтобы модель получала только релевантный контекст. В противном случае она может запутаться.
Также крайне важно поддерживать актуальность данных, которые вы предоставляете модели и постоянно их обновлять, учитывая версионность. Если у вас конфликты в данных, что бывает нередко, то и модель начнет выдавать конфликты в ответах. Есть методы, например, алгоритм Maximum Marginal Relevance Search (MMR), который учитывает релевантность и новизну информации для фильтрации и переупорядочивания. Однако это не панацея, и лучше всего решать эту проблемму на этапе хранения данных.

Язык

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

Если вам нужно использовать определённый язык, придётся выбрать модель, созданную для этого языка.Например, в русском языке много окончаний и фамилий, в которых LLama часто путается. Для русского языка наилучшие результаты на данный момент показывают Gigachat от Сбера и опенсорсная Qwen. LLama работает, но не идеально. 

Модель не следует всем логическим шагам для получения вывода.

Вы можете заставить модель следовать определённому процессу размышлений с помощью таких техник, как SelfRAG, Chain of Thought или SelfCheckGPT. Вот статья о этих техниках.
Основная идея заключается в том, чтобы заставить модель рассуждать пошагово и объяснять/проверять свои выводы и промежуточные шаги, чтобы она могла обнаружить свои ошибки.

Альтернативный подход — использование агентской модели, где несколько LLM-агентов общаются друг с другом и проверяют результаты и каждую ступень рассуждения.

Модель запуталась в имеющейся информации или “не повезло”.

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

1. MultiQuery — запуск нескольких запросов к LLM для одного и того же запроса пользователя с последующим выбором лучшего на основе метрики релевантности, например, Cross Encoder. Если вы получаете три очень похожих ответа и один, который сильно отличается, последний скорее всего - это случайная галлюцинация. Этот метод создаёт дополнительные расходы на дополнительные вызовы LLM, но является надёжным способом избежать случайных ошибок.

2. Снижение температуры модели — настройка параметра температуры на более низкое значение, чтобы уменьшить вероятность выбора менее вероятных путей (то есть фантазий).

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

Например, вы спрашиваете у модели, сколько будет 3 + 7, а она отвечает 37. Почему???
Всё становится понятно, если взглянуть на 3 и 7 в векторном пространстве: ближайший вектор к ним — это 37. Ошибка здесь очевидна, но в других случаях она может быть куда менее заметной.

Пример:

Ответ неверный. «Афонсу» был третьим королём Португалии, а не «Альфонсо». В Португалии никогда не было короля с именем «Альфонсо II». Матерью «Афонсу II» была Дульсе Арагонская, а не Уррака Кастильская. С точки зрения LLM, «Альфонсо» практически то же самое, что «Афонсу», а «мать» — это прямое совпадение. Поэтому, если рядом с «Афонсу» нет "матери" в векторном пространстве, LLM выбирает комбинацию «Альфонсо/мать».

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

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

Модель настроена так, чтобы фантазировать

Это может быть сделано либо через мастер-промпт, либо путём установки слишком высокой температуры модели. Таким образом, чтобы избежать этого, нужно:

• Инструктировать модель не давать ответа, если она не уверена или не обладает информацией.

• Убедиться, что в промпте ничего не побуждает модель придумывать факты, и в целом делать инструкции максимально ясными.

• Установить более низкую температуру модели.

Underfitting и Overfitting

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

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

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

Модель перегружена данными и начинает терять контекст

Вы можете подумать, что чем больше данных, тем лучше — но это совсем не так! (Точнее не совсем так).

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

Решение — использовать RAG (Retrieval-Augmented Generation) с правильным управлением размерами контекста. Нужно заранее отобрать только релевантные данные, повторно их ранжировать и подать в LLM.

Вот моя статья, где рассматриваются некоторые техники для этого.

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

Вот исследование на эту тему.

Другие общие техники

Human in the loop

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

Оракулы

Как альтернативу людям можно использовать автоматизированный "оракул" для проверки результатов системы, если это возможно.

Внешние инструменты

Определённые задачи, такие как вычисления и математика, следует выполнять за пределами LLM, используя предоставляемые модели инструменты. Например, можно использовать LLM для генерации запроса к базе данных SQL или Elasticsearch, выполнить этот запрос, а затем использовать результаты для формирования окончательного ответа.

Если у вас есть вопросы - пишите в комментариях.

Что почитать дальше? 

Гайд по архитектуре RAG

Построение базы знаний компании и поиска документов на LLM и RAG

Advanced RAG

Всем добра!