Диагностика проблем с выводом ЯИИ: когда использовать запросы, извлечение данных или тонкую настройку
Способ определения на основе симптомов того, требуется ли слабой функции ИИ лучший промпт, слой поиска или доработка, а также почему обучение модели на фактах приводит к обратному эффекту.
Первая версия любой функции искусственного интеллекта даёт результат, который не совсем правильный. У вас есть три способа это исправить: изменить инструкции, предоставить модели отсутствующие документы или перенастроить её на собственных примерах. Они сильно отличаются по затратам — от нескольких минут работы до недель сбора данных, — причём каждый из них устраняет другой тип сбоев. Этот руководство помогает выбрать подходящий способ, исходя из симптомов проблемы, чтобы не тратить недели на решение проблемы, которая вообще не требовала устранения.
Относитесь к модели как к способному новичку
Полезная ментальная модель — представлять модель как очень талантливого сотрудника в первый день работы. Он знает о мире общее количество информации, но совершенно ничего не знает о вашей компании: ни о ваших продуктах, ни о правилах, ни о том, как ваша команда предпочитает форматирование ответов. Он будет делать ошибки, как и любой талантливый новичок.
Вы можете помочь новому сотруднику ровно тремя способами. Вы можете лучше проинструктировать его, передать ему справочные материалы или отправить на учебный курс. Это соответствует методам формулировки запросов, поиска информации и доработки результатов, причем они расположены от самого дешевого к самому дорогому. Секрет заключается в соответствии меры вмешательства проблеме, поэтому имеет смысл рассматривать их в таком порядке.
Формулировка запросов: сначала перепишите инструкции
Всегда начинайте с этого. Запрос — это просто инструкции, которые вы отправляете вместе с заданием: само задание, один-два примера хорошего ответа, для кого предназначен ответ и желаемый формат. Изменение этих инструкций не стоит ничего и занимает несколько минут. Большая часть жалоб на то, что «ИИ плохой», на самом деле связана с тем, что запрос был нечетким.
Предположим, что ответы вашего функционала бывают длинными и формальными. Для этого не требуется переобучение. Достаточно добавить инструкцию вроде «отвечайте в трех предложениях, теплым и простым тоном», вставить один хороший пример ответа — и проблема обычно решается уже после одной итерации. Постоянные инструкции, которые вы устанавливаете для каждого запроса, называются системным промптом; примеры ответов, которые вы включаете для демонстрации определенного стиля, называются примерами типа few-shot.
Однако у метода промптинга есть четкое ограничение: инструкции не могут предоставить знания, которых модель никогда раньше не видела. Если новому сотруднику никогда не показывали цифры за текущий квартал, просьба «быть более точным» не приведет к их получению. Когда настоящей проблемой является отсутствие информации, требуется второй подход.
Краткая проверка перед переходом дальше
Прежде чем считать, что метод подсказок не сработал, убедитесь, что вы попробовали очевидные способы улучшения: четко указайте формат вывода, приведите хотя бы один конкретный пример, опишите действия в случае отсутствия ответа и протестируйте решение на небольшом фиксированном наборе реальных входных данных, а не на одном-двух выбранных вручную случаях. Без такого фиксированного набора трудно понять, действительно ли какое-либо изменение помогло.
Получение данных: передача файлов
Технология генерации с использованием дополнительных данных, обычно сокращаемая как RAG, позволяет модели получать доступ к вашим документам в момент ответа: к текущему списку цен, политике возвратов, истории заказов конкретного клиента. Она помогает справляться с недостающими знаниями, часто меняющейся информацией или данными, принадлежащими исключительно вашей организации. При обновлении документа меняются и ответы модели, причем для этого не требуется повторной настройки. Этот метод является оптимальным в тех случаях, когда знания принадлежат вам, часто меняются или требуют цитирования. Более подробно о различии между тем, что модель запоминает в своих весах, и тем, что она поискывает в момент ответа, рассказано в статье «В чем разница между памятью ИИ, контекстом, эмбеддингами и весами модели».
В ситуации с новыми сотрудниками вы больше не даете им лекции; вы просто передаёте им руководство и позволяете им ознакомиться с ним перед тем, как отвечать. Теперь они могут отвечать на вопросы о изменениях, произошедших давно после обучения модели, и могут указать точное место, откуда взялся каждый ответ.
Это дороже, чем простая корректировка запроса. Вы создаёте небольшую систему, которая хранит документы и выполняет поиск с учётом смысла, что обычно требует не минут, а дней работы. Это всё равно значительно дешевле тонкой настройки модели, и система остаётся актуальной вместе с вашими документами. Кроме того, появляются элементы, которые необходимо обслуживать: способ разделения документов, метод оценки качества поиска и действия в случае, если не находится ничего релевантного.
Получение информации имеет свои четкие границы. Документ заполняет пробелы в знаниях модели, но не меняет ее поведения. Предоставление кого-либо руководства не влияет на его стиль написания или способность к принятию решений. Для этого его нужно обучать.
Тонкая настройка: отправка на курс обучения
Тонкая настройка предполагает повторное обучение модели на большом количестве примеров до тех пор, пока определенный стиль или навык не станут автоматическими. Это средство для обеспечения последовательного поведения, когда простые указания не дают результата, или в тех случаях, когда ваш запрос превратился в целую страницу правил и по-прежнему ненадежен. Представьте, что каждый ответ должен соответствовать очень конкретному стилю бренда в течение миллиона разговоров, причем ни один из ответов не должен отклоняться. Обучение на тысячах примеров может сделать такое поведение стандартным без необходимости дополнительных указаний.
Самое частое недопонимание заключается в следующем: тонкая настройка изменяет поведение модели, а не её знания. Этот процесс медленный и дорогой, он требует большого количества примеров данных, и любые факты, встроенные в модель, устаревают сразу же при изменении этих фактов. Поэтому её не следует использовать для хранения фактов — для этого предназначена система поиска. Среди трех вариантов это способ обучения: он эффективен, когда проблема действительно связана с поведением модели, но бесполезен в случаях, которые можно было решить с помощью более чёткого описания задачи. Чтобы узнать больше об экономических аспектах этого решения, ознакомьтесь с сравнением затрат на тонкую настройку модели и вызов API.
Выбор в зависимости от симптомов
Начните с одного вопроса: в чём именно заключается проблема с результатом?
- Формат или тон запроса неверны, либо модель игнорирует части ваших инструкций. Это проблема сформулировки запроса, поэтому её необходимо улучшить.
- Отсутствует или устарела какая-то информация, модель приводит неверную версию данных, или требуется указание источника. Это проблема знаний, поэтому необходимо добавить функцию поиска информации.
- Информация верна, но поведение модели остается нестабильным независимо от формулировки запроса, и требуется его надежность в тысячах ответов. Это проблема поведения, поэтому стоит рассмотреть возможность финтунинга.
Симптомы помогают выбрать способ решения. Ещё два момента легко упустить из виду.
Различные методы действуют совместно, а не конкурируют
Почти каждая функция начинается с промпта. Многие из них позже добавляют механизм поиска информации, когда требуются актуальные или конфиденциальные данные, а некоторые — процедуру тонкой настройки для достижения поведения, которое невозможно обеспечить с помощью промпта. Обычно вы сами решаете, какой слой добавить дальше, а не выбираете один подход на всё время. Даже тонко настроенная модель по-прежнему получает промпт, а система RAG по-прежнему зависит от инструкций, указывающих модели, как использовать полученные данные.
Действуйте только настолько, насколько требует симптом
Поскольку варианты идут от дешевых к дорогим в таком порядке, остановитесь на первом решении проблемы. Тот же принцип применим и до начала разработки: если задача зависит от изменяющихся данных, планируйте использование механизма поиска; если требуется очень точное поведение в больших объемах, тонкая настройка может оказаться оправданной; во всех остальных случаях всё начинается с промпта.
Дорогостоящая ошибка: тонкая настройка для изучения фактов
Ошибкой, которую стоит отметить особо, является попытка использовать тонкую настройку для того, чтобы заставить модель что-то знать. Это кажется серьезным, требующим глубоких инженерных усилий решением, и именно поэтому команды сначала обращаются к нему. Однако факты, которые постоянно меняются, не должны входить в привычки модели; они должны находиться в документе, к которому модель может обратиться. Если поступать наоборот, можно тратить недели на обучение модели факту, который к моменту запуска снова окажется неверным, при этом не будет простого способа показать, откуда взялся ответ.
Другая связанная ловушка — использование тонкой настройки для исправления на самом деле нечеткого запроса. Если вы еще не пробовали использовать четкие инструкции по форматированию и несколько хороших примеров на фиксированном наборе тестов, вы еще не знаете, действительно ли у вас есть проблема с поведением модели.
Основные выводы
- Сначала диагностируйте, прежде чем тратить ресурсы: определите, связана ли проблема с инструкциями, знаниями или поведением.