Прекращение галлюцинаций у чат-ботов: RAG, векторный поиск, разделение данных на блоки и защитные механизмы.

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

Почему модели выдумывают

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

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

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

В хорошем ответе стоит рассмотреть следующие темы:

• причины галлюцинаций у моделей и почему финтюнинг недостаточен
• процесс RAG: сбор контекста, а затем генерация ответа
• векторные базы данных и семантический поиск на основе эмбеддингов

стратегии разбиения документов на части

техники формулировки запросов, снижающие галлюцинации

управление окном контекста в рамках лимитов токенов

процессы оценки, контролирующие качество ответов

Как RAG снижает галлюцинации

С помощью RAG система сначала извлекает соответствующий материал из базы знаний и вставляет его в запрос в качестве контекста. Без этого модель делает предположения на основе своих параметров. С контекстом модель читает ответ из предоставленных документов. Она по-прежнему генерирует токены, но контекст ограничивает её действия. Если в документах указано, что возвратов не предусмотрено, модель не будет выдумывать срок возврата в 30 дней.

Векторные базы данных и эмбеддинги

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

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

• Модель векторизации. Она преобразует текст в векторы так, чтобы похожие тексты давали похожие векторы. Среди вариантов — модель text-embedding-3-small от OpenAI с 1536 измерениями, а также open-source модели вроде BGE или E5.
• База данных векторов. Она хранит векторные представления и поддерживает поиск ближайших соседей приблизительным способом (ANN). Среди вариантов — управляемая Pinecone, а также Weaviate, Qdrant, pgvector (расширение PostgreSQL) и Milvus.

Поиск с использованием ANN. Сравнение запроса со всеми сохранёнными векторами занимает много времени. Алгоритмы вроде HNSW (Hierarchical Navigable Small World) и IVF (Inverted File Index) находят приблизительные соседние векторы гораздо быстрее, примерно за логарифмическое время. При наличии 10 миллионов или более векторов полный поиск может занять секунды, тогда как ANN выполняет его за миллисекунды.

Переупорядочивание результатов. Первый этап возвращает примерно 20 кандидатов. Затем более точный кросс-кодер переупорядочивает их по степени релевантности, и только топ-3 результаты попадают к LLM. Быстрый, но приблизительный поиск с последующим медленным, но точным переупорядочиванием позволяет сбалансировать скорость и точность.

Разбиение на чанки

Документ политики объёмом 50 страниц невозможно загрузить целиком, поэтому его необходимо разделить на чанки. Размер чанков влияет как на точность поиска, так и на эффективное использование окна контекста.

• Слишком маленький фрагмент теряет контекст. Например, может появиться текст «Предметы, поврежденные во время доставки, не являются», а остальная часть предложения будет в следующем фрагменте, из-за чего модель не сможет правильно ответить.
• Слишком большой фрагмент разбавляет полезную информацию нерелевантным текстом и заполняет окно шумом.
• Перекрытие защищает от проблем, связанных с границами. Скользящее окно с перекрытием 10–20 процентов предотвращает потерю информации между фрагментами.

Хорошим стандартом для документации является разделение по заголовкам разделов, ограничение размера фрагментов примерно 500–1000 токенов и перекрытие соседних фрагментов на 50–100 токенов. Каждый фрагмент должен быть самодостаточным, содержать полную мысль.

Дизайн промптов как вторая линия защиты

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

• Роль. Фраза вроде «Вы — ассистент службы поддержки клиентов» определяет персонажа для модели.
• Ограничение круга информации. Инструкция отвечать только на основе предоставленного контекста не позволяет модели опираться на свои собственные знания.
• Механизм для случаев неопределённости. Просьба к модели сказать, что она не может ответить, если в контексте отсутствует информация, — это самый важный пункт. Без него модель будет угадывать.
• Цитирование источников. Требование указывать источники документов заставляет модель обосновывать свои утверждения, что затрудняет выдумку.
• Запрет на использование внешних знаний. Прямой запрет на использование информации, выходящей за рамки контекста, усиливает правило ограничения круга информации.

Управление окном контекста

Что делать, если соответствующие фрагменты не влезают или у вопроса есть несколько частей, требующих множества фрагментов? Современные модели имеют большие окна контекста — например, 128K токенов у GPT-4o и до 1M у Gemini, — но заполнение их незначимым материалом снижает качество ответа. Для решения этой проблемы помогают четыре тактики:

1. Ранжирование по релевантности. Получить десять фрагментов, отсортировать их по оценке релевантности и добавить от лучших к худшим до исчерпания лимита токенов, сначала удаляя наименее релевантные.
2. Разбиение запроса. Для вопроса вроде «Расскажите о политике возвратов и сроках доставки» разделить его на подзапросы, получить информацию по каждому из них и ответить на оба в одном сообщении.
3. Краткое изложение обширных тем. Когда тема охватывает множество фрагментов, попросить модель сначала составить краткое изложение, а затем использовать его в качестве контекста для окончательного ответа.

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

Полная архитектура

В целом основные решения заключаются в следующем:

• Семантическое разделение на фрагменты. Разделение происходит по естественным границам, таким как заголовки и абзацы; фрагменты имеют размер около 500 токенов с перекрытием в 50 токенов, причем каждый фрагмент является самодостаточным.
• Двухэтапный поиск. Поиск с использованием ANN выдает 20 кандидатов, после чего кросс-кодер сортирует их, оставляя лучшие 3.
• Низкая температура. Значение около 0,2 в шкале от 0 до 2 делает модель менее творческой и снижает вероятность выдумки информации.

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

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

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

Что необходимо отслеживать

1. Частота галлюцинаций. Доля ответов, содержащих информацию, отсутствующую в предоставленном контексте; оценивается с помощью автоматизированных методов или проверки человеком. Разумной целью является уровень ниже 1 процента.

Точность поиска@3. Из трех лучших фрагментов — сколько из них действительно связано с запросом. Значение ниже 70 процентов указывает на необходимость улучшения модели вживления данных или процесса разбиения на фрагменты.

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

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

Оценка отзывов пользователей. Средняя оценка по кнопкам «лайк» и «дизлайк», показатель общего удовлетворения.

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

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

Четыре уровня защиты

Галлюцинации — это не признак сбоя ИИ. Это проблема проектирования. Модель без ограничений всегда выбирает правдоподобие вместо точности, потому что именно к этому она была обучена. Четыре уровня помогают решить эту проблему:

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

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

Самое важное правило: чат-бот, который уверенно говорит «Я не знаю», намного лучше того, который уверенно выдумывает ответ.