«Ошибка на миллиард» в ИИ: боремся с галлюцинациями в LLM по аналогии с NullPointerException

Привет! Меня зовут Денис Березуцкий, я старший инженер по разработке ПО искусственного интеллекта в YADRO. В ML-команде мы разрабатываем системы, которые облегчают работу нашим заказчикам с помощью текстовых генеративных нейросетей: реализуем RAG, создаем чат-ботов, агентные системы и другие решения.

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

О стоимости борьбы с галлюцинациями

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

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

А между тем, если вы неудачно составили промпт для вашей RAG-системы, никакой DeepSeek не спасет.

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

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

«Ошибка на миллиард» в классическом программировании

«Ошибка на миллиард долларов» — это популяризованное ученым Чарльзом Э. Хоаром название для пресловутого «null pointer exception». В большинстве классических языков программирования переменная, якобы содержащая объект какого-то класса, на самом деле может ничего не содержать.

Скажем, в Java вы объявляете функцию в духе:

public static String extractStreet(Address address) {
    return address.get(“street”, “Undefined”)
}

И вы не можете быть уверены, что вам пришел настоящий объект класса Address. В переменной address может скрываться null. Если вы попытаетесь вызвать один из методов Address у такой переменной, вы получите тот самый NullPointerException.

По идее вам нужно проверять, что пришедший объект не равен null. Но, если вы будете делать такую проверку каждый раз для каждого значения переменной, вы замучаетесь, а ваш код вырастет в разы. Вы также можете понадеяться, что проверку на null сделал кто-то до вас. Но где именно? И что если все-таки не сделал? Или сделал раньше, но убрал по ошибке во время рефакторинга?

Возникает путаница, последствия разбирательств с которой Хоар оценил как раз на «миллиард долларов».

Некоторые современные языки, такие как Kotlin, решают проблему тем, что на каждый класс разрешают иметь два типа переменных: те, которые точно не содержат null, и те, которые могут его содержать (в Kotlin это записывается как “Int” vs “Int?”).

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

Хорошо было бы изобрести машину времени и вернуться на 65 лет назад, чтобы предотвратить появление неявных нулевых ссылок. Но, увы, приходится работать с тем, что есть.

«Ошибка на миллиард» в генеративном ИИ

Компьютеры, как известно, отлично справляются с четкой, строгой логикой, но творческая составляющая у них до недавнего времени хромала. Уже много лет назад существовали суперкомпьютеры, считающие арифметические примеры быстрее, чем все люди на планете вместе взятые. Но в плане творческой генерации мы только в последние 3-4 года стали получать нейросети, которые способны творить на уровне хотя бы одного отдельно взятого копирайтера или иллюстратора.

Из-за этого в индустрии LLM случился некоторый перекос. Желая показать, что их нейросеть «человекоподобна», то есть находится на острие прогресса, создатели настраивали ее в первую очередь на работу с творческими, а не строгими задачами. Например, в продуктах OpenAI по умолчанию включен сэмплинг и выставляется ненулевая температура, чтобы LLM выдавала пусть иногда неожиданные, но зато разнообразные ответы.

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

Вспомним, как было в «Поколении П» Пелевина:

— Пойдешь ко мне в штат?
— Кем?
— Криэйтором.
— Это творцом? Если перевести.
— Творцы нам тут [даром] не нужны. Криэйтором, Вава, криэйтором.

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

Хорошо, если ответ в выдаче действительно был. А если нет? Тогда обученная на творческие задачи модель выдумает его «из головы». И попробуйте потом понять, это реальный ответ из базы знаний на тысячу документов или просто фантазия.

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

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

Боремся с галлюцинациями

В основе нашего метода лежит такое же отношение к галлюцинациям в системе RAG, как к NullPointerException.

А как мы боремся с NullPointerException в классическом программировании? Правильно: мы предварительно делаем проверку на null.

Разумеется, первое, что приходит в голову при разработке системы RAG, — прямо в промпте давать указание системе: «Если нужной информации нет в контексте, то ответь фразой “Нет информации”».

Однако, когда мы стали тестировать RAG на базе знаний одного из внутренних заказчиков, выяснилось, что даже с таким промптом модель все еще иногда галлюцинирует, в том числе в откровенно очевидных, непростительно простых случаях. Позже мы собрали два небольших датасета (подробности в следующих разделах) для оценки способности модели отсеивать нерелевантный контекст. И обнаружили, что, например, saiga_mistral_7b ошибается на коротких контекстах в более чем 12% случаев, а на средних/длинных — в более чем 40%.

Поэкспериментировав с промптами, мы обнаружили, что встречаются «волшебные» слова, которые улучшают этот показатель. Нет, не слово «пожалуйста», а «строго»: «Если нужной информации нет в контексте, то ответь строго фразой “Нет информации”».

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

Тогда мы решили дообучить базовую модель при помощи LoRA на специально собранном датасете для ситуаций, когда в контексте нет ответа на вопрос пользователя (см. следующий раздел). На тот момент в качестве базовой модели LLM мы использовали saiga_mistral_7b, которая нетребовательна к ресурсам и долгое время была в топе на Russian SuperGLUE. Да-да, есть модели получше, но, как правило, они либо огромные, либо имеют проблемы с лицензией в России, в том числе все, что основаны на LLaMa.

Но самое главное: в нашем RAG-пайплайне мы решили сделать опциональную петлю, в которой проверяли бы каждый найденный фрагмент контекста на релевантность вопросу пользователя. Только те куски контекста, которые пройдут проверку, будут попадать в финальный вопрос для LLM.

Ниже — грубая схема работа пайплайна:

Отмечу, что каждый шаг пайплайна опционален: 

• Можно делать только поиск, без фильтрации и генерации финального ответа (то есть обычный поиск, как в Google). 

• Можно делать поиск, а затем фильтровать результаты через LLM (совместно с другими фильтрами, реранкерами и пр.) — получится RAG.

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

• Наконец, можно прогонять поток по всем шагам.

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

Самая очевидная идея — спрашивать LLM: «Есть ли в данном контексте ответ на вопрос пользователя? Ответь строго “да” или “нет”». Тогда на выходе мы проверяем, что ответ модели равен одной из этих двух строк (да/нет), и в зависимости от этого реагируем.

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

Поэкспериментировав, мы решили остановиться на следующем варианте.

Задаем модели вопрос с таким шаблоном промпта:

Затем выставляем max_new_tokens генерации всего в несколько штук — для saiga_mistral_7b хватает семи. Если начало сгенерированной строки в точности совпало со строкой «Нет информации», то считаем, что модель не нашла информации в контексте. Во всех остальных случаях считаем, что нашла что-то релевантное.

Сначала это может выглядеть контринтуитивно. Если бы мы переложили наш метод борьбы с «NullPointerException» на классическое программирование, то он выглядел бы примерно так:

public static String extractStreet(Address address) {
    try {
        address.get(“street”, “Undefined”)
    } catch (NullPointerException e) {
        return “”
    }
    return address.get(“street”, “Undefined”)
}

То есть мы дважды проводим одну и ту же процедуру экстракции вместо того, чтобы один раз предварительно проверить address на null. Но, во-первых, для контекста в RAG не существует «простой проверки на null», потому мы и спрашиваем LLM о наличии информации в контексте. А во-вторых, первый вызов строго ограничен по числу токенов, поэтому проходит довольно быстро.

Кроме того, подход основан на следующих соображениях (в том числе подтвержденных экспериментами):

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

2. Модели, как правило, обучены на ответы по вопросам пользователей. Если спросить LLM, есть ли в контексте информация по вопросу пользователя «Сколько планет в Солнечной системе?», то с большой вероятностью нейросеть ответит не «да», а «8». Поэтому можно не просить модель отвечать «да» — пусть сразу дает ответ на вопрос. Нам все равно, так как нас интересует только сравнение со строкой «Нет информации».

3. Текст «Нет информации», с одной стороны, более точный и специфичный, чем абстрактное «нет», а с другой — не такой длинный, как «Информации нет в контексте» или «Информации нет в данном контексте». Современные LLM так устроены, что чем больший текст они генерируют, тем больше у них вероятность сбиться на очередном токене и сгенерировать ерунду. Ну и конечно, мы жалеем драгоценное время на генерацию каждого токена.

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

(true positive “no info” + true negative “no info”)/all results

Здесь:

• true positive “no info” — это число случаев, когда модель начала ответ с «Нет информации», если ответа реально не было в контексте.

• true negative “no info” — это число случаев, когда ответ был в контексте, но модель начала ответ с чего угодно, кроме «Нет информации».

Все остальные случаи считаются ошибками:

• false positive “no info” — модель начала ответ с «Нет информации», а информация в контексте была.

• false negative “no info” — модель начала ответ с чего угодно, кроме «Нет информации», а по факту информации в контексте не было.

Дообучение LoRA для фильтрации контекста

Шаг с дообучением и внедрением LoRA в нашем случае опционален. Вы можете встроить петлю проверки релевантности и с помощью базовой LLM, если она выдает приемлемое качество. Но, как упоминалось раньше, нас не вполне устраивала работа saiga_mistral_7b «из коробки», поэтому мы решили посмотреть, насколько можно будет улучшить показатели, если потратить время на дообучение и внедрение адаптера.

Задача фильтрации контекста перед нами была поставлена в рамках более общей — «приспособить LLM к работе со специализированными базами знаний компании». Поэтому мы создали два принципиально разных датасета. Оба основаны на внутренней базе знаний одного из проектов YADRO.

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

Второй датасет соответствовал задаче RAG. Он содержал вручную подобранные вопросы пользователя, контексты, в которых нужно искать ответ, и идеальные ответы.

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

Пара оторванных от реальности примеров:

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

Итого — 315 сэмплов.

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

Дальше последовала череда экспериментов по обучению, причем в результате мы создали три версии адаптера:

1. Обученную только на датасете с пересказом статей по заголовкам.

2. Обученную только на RAG-датасете для фильтрации контекста.

3. Обученную на обоих датасетах.

Процедуру дообучения описывать не буду, она стандартная для LoRA. Единственное существенное отличие: с определенным интервалом мы запускали еще и кастомную валидацию, где считали дополнительные метрики. Среди них — BLEU, BERTScore и, самое главное, метрика accuracy на классе “No Info”, которая отвечает за способность модели отсеивать нерелевантные контексты.

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

А результаты получились интересные.

В верхней строке — модель «из коробки», без адаптера. Как видно, и она справляется с задачей неплохо, однако в результате дообучения число ошибок сократилось в разы (с 12.5% до 4.2% в случае с accuracy).

Модель, обученная только на автодатасете с пересказом статей, ожидаемо деградировала в задаче RAG. Все-таки отвечать на вопрос по контексту — совсем не то же самое, что пытаться написать вызубренную статью по ее заголовку.

Гораздо интереснее, что лучшие результаты в задаче RAG показал адаптер, обученный на обоих датасетах, а не только на RAG-датасете.

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

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

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

Победителем в нашем сравнении вышла модель, дообученная на обоих датасетах.

Деплоймент модели, дообученной методом LoRA, и петли фильтрации

LoRA, как известно, позволяет очень дешево адаптировать нейросети для решения узкоспециализированных задач без необходимости заводить отдельную LLM с полноценным дообучением (со всеми вытекающими чудовищными затратами VRAM и времени). То есть в плане использования памяти вы получаете вторую модель по цене 5-10% от первой. Однако есть и недостатки — в частности, необходимость поддерживать инфраструктуру для адаптеров и возможность управлять ими извне.

Мы стараемся поддерживать API для заказчиков в соответствии с современными стандартами индустрии. По многим же стандартам использование адаптеров не предполагается. Так, у OpenAI при вызове API вы можете выбрать модель (o1, o3-mini и другие), но у вас просто нет поля для выбора адаптера, потому что OpenAI это не нужно.

Мы приняли простое решение: переиспользовать строку имени модели, но добавлять имя адаптера через двоеточие. Например, вместо “model_name”:“IlyaGusev/saiga_mistral_7b_merged” можно написать “model_name”: “IlyaGusev/saiga_mistral_7b_merged:sm_yadro_tb_rag_filtering_lora”.

Это не противоречит стандартному формату, но дополняет его и позволяет серверу для инференса (Inference Server) понять, что нужно не просто использовать модель, но предварительно включить у нее слои нужного адаптера (или выключить, если адаптер не указан). К счастью, современные версии PEFT позволяют жонглировать адаптерами по цене в сотые или даже тысячные доли секунды за операцию.

# Пример кода загрузки модели с адаптерами на стороне Inference Server при условии, что список адаптеров заранее определен:

self.active_adapter = ""
self.adapter_names: List[str] = (
    (model_params["available_adapters"]["string_value"].split(","))
    if "available_adapters" in model_params
    else []
)
if self.adapter_names:
    first_lora = True
    for lora_name in self.adapter_names:
        lora_path = f"/models/{lora_name}"
        if first_lora:
            self.model = PeftModel.from_pretrained(
                self.model,
                lora_path,
                lora_name,
                **model_kwargs,
            )
            first_lora = False
        else:
            self.model.load_adapter(lora_path, adapter_name=lora_name)
    self.model.base_model.disable_adapter_layers()

# Подготовка модели к инференсу по конкретному запросу пользователя:

adapter = params.pop("adapter") if "adapter" in params else ""
if adapter != self.active_adapter:
    if not adapter:
        self.model.base_model.disable_adapter_layers()
    else:
        self.model.base_model.enable_adapter_layers()
        self.model.set_adapter(adapter)
    self.active_adapter = adapter

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

Например:

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

Примерный код фильтрации:

no_info_indicator = pipeline_config.get(“no_info_indicator”, “Нет информации.”)
context_relevance_chain: BaseCombineDocumentsChain = …
if context_filtering_enabled:
    if check_per_document:
        relevant_docs: list[Document] = []
        for context_doc_info in context:
            relevance_answer = context_relevance_chain.invoke(
                {"input_documents": [context_doc_info], "question": question},
                return_only_outputs=True,
            )[“output”]
            if relevance_answer != no_info_indicator:
                relevant_docs.append(context_doc_info)
        return relevant_docs
    else:
        relevance_answer = context_relevance_chain.invoke(
            {
                "input_documents": context,
                "question": question,
            },
            return_only_outputs=True,
        )[“output”]
        if relevance_answer == no_info_indicator:
            return []
        else:
            return context

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

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

В принципе, вместо такой петли (или вместе с ней) можно использовать и encoder-only модель, которая попытается захайлайтить ответ в выдаче, а если не найдет ответа, то такой чанк тоже можно считать нерелевантным. Пример хайлайтов можно увидеть, например, в поисковой выдаче Google:

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

Результаты внедрения

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

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

Однако, как говорится, «спасибо» на Хабр не положишь, поэтому мы дополнительно создали тестовый датасет из 100 сэмплов, не связанных со спецификой конкретного заказчика, чтобы оценить фичу более объективно.

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

На этом датасете мы прогнали несколько конфигураций, и вот что у нас получилось:

«Правильность» ответов во всех случаях оценивалась вручную. При этом моделям размера 7B делались поблажки по орфографии и прочим мелочам (Saiga часто миксует русский язык с английским, а DeepSeek — с китайским).

В первом случае («с плохим промптом») мы не говорим модели: «Если информации нет в контексте, то ответь строго фразой “Нет информации”». То есть надеемся, что модель сама откажется выдумывать ответ. Во всех остальных случаях говорим.

DeepSeek-R1-Distill-Qwen-7B мы выбрали как современный популярный конкурент примерно того же размера, что и saiga_mistral_7b. А DeepSeek-R1-Distill-Qwen-32B взяли для оценки влияния размера модели на качество. В обоих случаях из ответа, разумеется, удалялась секция reasoning (тэг “<think>”). R1 вместо V3 мы выбрали, потому что для нее существуют официальные дистилляции подходящего размера.

Первый интересный результат. На длинных контекстах «правильный» промпт не оказал на saiga_mistral_7b никакого значимого влияния — качество осталось на уровне 49%. Модель немного варьировала ответы, но ни разу не начала с фразы «Нет информации». В целом, из 46 вопросов в датасете, на которые предполагался ответ «Нет информации», базовая модель только в двух случаях отказалась от ответа по существу. Во всех остальных случаях начинала выдумывать ответ.

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

Второй интересный результат. DeepSeek-R1-Distill-Qwen-7B немного уступила saiga_mistral_7b по качеству, несмотря на то, что первая намного новее и вооружена механизмом reasoning. В нескольких случаях модель просто впала в бесконечный цикл прямо во время reasoning’а.

В то же время DeepSeek-R1-Distill-Qwen-32B показала прекрасный результат, ошибившись всего лишь в трех случаях, из которых два были ложноположительными (то есть, информация в контексте была, но модель решила ответить «Нет информации»). Причем маленькая модель DeepSeek-R1-Distill-Qwen-7B дала правильные ответы на тех же двух сэмплах. Возможно, большая модель перемудрила с ответом.

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

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

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

Но если вы можете себе позволить только одну-две RTX 4090, то дообучение модели размера 7B/8B с помощью LoRA может быть вполне приемлемой альтернативной.

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

Вот пара примеров, где дообучение LoRA оказало влияние:

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

Выводы

Творческая натура LLM играет со строгими задачами злую шутку: в любой непонятной ситуации модель принимается фантазировать на основе претрейна.

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

Например, в популярном русскоязычном датасете RussianNLP/russian_super_glue (подсет MuSeRC) нет примеров, где требуемой информации не нашлось бы в контексте. Если вы на базе MuSeRC составите датасет для обучения RAG, в котором в качестве выходной последовательности будет правильный ответ, ваша модель не будет знать, что делать, если в контексте нет ответа на вопрос. А это прямой путь к галлюцинациям.

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

Но до тех пор приходится применять самодельные стратегии. Описанный в статье метод фильтрации контекста как раз к ним относится.

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

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

А какие методы борьбы с галлюцинациями используете вы? Пишите в комментариях.