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

Изображение предоставлено редактором.
# Введение
Галлюцинации — это не просто проблема модели. В производственной среде это проблема проектирования системы. Наиболее надежные команды сокращают количество галлюцинаций, основывая модель на достоверных данных, обеспечивая отслеживаемость и контролируя выходные данные с помощью автоматизированных проверок и непрерывной оценки.
В этой статье мы рассмотрим семь проверенных и апробированных на практике стратегий, которые разработчики и команды, занимающиеся искусственным интеллектом, используют сегодня для уменьшения количества ошибок, возникающих при работе с большими языковыми моделями (LLM).
# 1. Закрепление ответов с использованием генерации, дополненной извлечением информации.
Если вашему приложению необходимо корректно обрабатывать внутренние политики, спецификации продуктов или данные о клиентах, не позволяйте модели отвечать, используя память. Используйте генерацию с расширенным поиском (Retrieval-Augmented Generation, RAG) для извлечения релевантных источников (например, документов, заявок, статей базы знаний или записей базы данных) и генерации ответов на основе этого конкретного контекста.
Например:
- Пользователь спрашивает: «Какова наша политика возврата средств за годовые планы?»
- Ваша система получает текущую страницу политики и вставляет её в запрос.
- Помощник отвечает и приводит точный текст использованного предложения.
# 2. Требование указывать ссылки на ключевые утверждения.
Простое оперативное правило, используемое многими помощниками продюсеров: нет источников — нет ответа .
В рекомендациях Anthropic четко указано, что результаты должны быть доступны для аудита, например, путем указания источников и проверки каждым утверждением модели подтверждения путем поиска подтверждающей цитаты и отзыва любых утверждений, которые она не может подтвердить. Этот простой метод значительно снижает вероятность возникновения галлюцинаций.
Например:
- К каждому пункту фактического утверждения модель должна прикреплять цитату из полученного контекста.
- Если найти цитату не удаётся, необходимо ответить: «В предоставленных источниках недостаточно информации».
# 3. Использование вызова инструмента вместо ответов в свободной форме.
Для транзакционных или фактических запросов наиболее безопасная схема выглядит следующим образом: LLM — Инструмент/API — Проверенная система учета — Ответ.
Например:
- Ценообразование: Запрос к базе данных выставления счетов
- Статус заявки: Вызов внутреннего интерфейса прикладного программирования (API) системы управления взаимоотношениями с клиентами (CRM).
- Правила политики: Получить файл политики, находящийся под контролем версий.
Вместо того чтобы позволять модели «вспоминать» факты, она их извлекает. LLM становится маршрутизатором и форматировщиком, а не источником истины. Это единственное проектное решение исключает большой класс галлюцинаций.
# 4. Добавление этапа проверки после генерации
Многие производственные системы теперь включают в себя модель «судьи» или «оценщика». Рабочий процесс обычно включает следующие этапы:
- Сгенерировать ответ
- Отправьте ответ и исходные документы в модель верификатора.
- Оценка обоснованности или фактической поддержки.
- Если ниже порогового значения — регенерировать или отклонить.
Некоторые команды также проводят упрощенные лексические проверки (например, проверку совпадения ключевых слов или оценку по шкале BM25 ), чтобы убедиться, что заявленные факты присутствуют в исходном тексте. Широко распространенный исследовательский подход — это метод «цепочки верификации» (Chain-of-Verification, CoVe) : составить ответ, сгенерировать проверочные вопросы, ответить на них независимо, а затем получить окончательный проверенный ответ. Этот многоступенчатый конвейер проверки значительно сокращает количество неподтвержденных утверждений.
# 5. Предвзятое отношение к цитированию вместо перефразирования.
Перефразирование увеличивает вероятность незначительных фактических отклонений. Практическим правилом является следующее:
- Для подтверждения фактических утверждений требуются прямые цитаты.
- Разрешать суммирование только при наличии кавычек.
- Отклонять выходные данные, содержащие неподдерживаемые числа или имена.
Этот метод особенно хорошо зарекомендовал себя в юридической, медицинской и нормативной сферах, где точность имеет решающее значение.
#6. Калибровка неопределенности и умение достойно принимать неудачи.
Полностью избавиться от галлюцинаций невозможно. Вместо этого производственные системы проектируются с учетом возможности безопасного отказа. К распространенным методам относятся:
- Оценка достоверности
- Пороговые значения вероятности поддержки
- «Недостаточно доступной информации» — запасной вариант ответа.
- Привлечение человека к процессу эскалации для ответов с низкой степенью уверенности
Возвращение неопределенности безопаснее, чем возвращение уверенной выдумки. В корпоративных условиях этот подход к проектированию зачастую важнее, чем стремление к незначительному повышению точности.
#7. Непрерывная оценка и мониторинг
Снижение частоты галлюцинаций — это не разовое решение. Даже если вы улучшите показатели галлюцинаций сегодня, завтра они могут измениться из-за обновлений модели, изменений в документации и новых запросов пользователей. Производственные команды используют конвейеры непрерывной оценки для:
- Оцените каждый N-й запрос (или все запросы с высоким риском).
- Отслеживайте частоту галлюцинаций, охват цитирования и правильность отказов.
- Получайте оповещения при ухудшении показателей и откатывайте изменения в запросах или способах получения данных.
Обратная связь от пользователей также имеет решающее значение. Многие команды регистрируют каждый отчет о галлюцинациях и используют его для настройки системы извлечения информации или корректировки подсказок. В этом разница между демонстрацией, которая выглядит достоверной, и системой, которая остается достоверной.
# Завершение
Снижение количества визуальных галлюцинаций в производственных LLM-моделях не сводится к поиску идеального варианта. Если рассматривать это как архитектурную проблему, надежность повышается. Для поддержания точности:
- Ответы, полученные на основе реальных данных.
- Отдавайте предпочтение инструментам, а не памяти.
- Добавить уровни проверки
- Проектирование с учетом безопасных отказов
- Непрерывный мониторинг
Канвал Мехрин — инженер по машинному обучению и технический писатель, глубоко увлеченная наукой о данных и взаимодействием ИИ с медициной. Она является соавтором электронной книги «Максимизация производительности с помощью ChatGPT». Как стипендиат программы Google Generation Scholar 2022 для Азиатско-Тихоокеанского региона, она выступает за разнообразие и академическое превосходство. Она также является стипендиатом программы Teradata Diversity in Tech Scholar, стипендиатом Mitacs Globalink Research Scholar и стипендиатом Harvard WeCode Scholar. Канвал — убежденная сторонница перемен, основавшая FEMCodes для расширения прав и возможностей женщин в областях STEM (наука, технология, инженерия и математика).
Источник: www.kdnuggets.com
























