Prompt engineering

Это руководство делится стратегиями и тактиками для получения лучших результатов от больших языковых моделей (иногда их называют моделями GPT), таких как GPT-4. Описанные здесь методы иногда можно использовать в комбинации для большего эффекта. Мы рекомендуем экспериментировать, чтобы найти методы, которые лучше всего работают для вас.

Некоторые примеры, демонстрируемые здесь, в настоящее время работают только с нашей наиболее мощной моделью gpt-4. В общем, если вы обнаружите, что модель не справляется с задачей и доступна более мощная модель, часто стоит попробовать снова с более мощной моделью.

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

Тактики:

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

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

Тактики:

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

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

Тактики:

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

Если вас спросят умножить 17 на 28, возможно, вы не знаете ответ сразу, но можете вывести его со временем. Аналогичным образом модели делают больше ошибок в рассуждениях, когда пытаются ответить сразу, вместо того, чтобы взять время для выработки ответа. Запрос на «цепочку мысли» перед ответом может помочь модели надёжнее продвигаться к правильным ответам.

Тактики:

• Инструктируйте модель сначала выработать собственное решение, прежде чем спешить к выводу
• Используйте внутренний монолог или последовательность запросов, чтобы скрыть процесс рассуждения модели
• Спросите модель, не пропустила ли она что-то при предыдущих проходах

Компенсируйте слабости модели, используя выходные данные других инструментов. Например, система извлечения текста (иногда называемая RAG или retrieval augmented generation) может рассказать модели о релевантных документах. Механизм выполнения кода, такой как Интерпретатор Кода OpenAI, может помочь модели решать математические задачи и выполнять код. Если задача может быть выполнена более надежно или эффективно с помощью инструмента, а не языковой моделью, поручите её инструменту, чтобы получить лучшее из обоих.

Тактики:

• Используйте поиск на основе embeddings для эффективного извлечения знаний
• Используйте выполнение кода для более точных вычислений или вызова внешних API
• Дайте модели доступ к определенным функциям

Улучшение производительности становится проще, если вы можете измерить ее. В некоторых случаях изменение в prompt может привести к лучшей производительности на нескольких изолированных примерах, но привести к худшей общей производительности на более репрезентативном наборе примеров. Поэтому, чтобы быть уверенным в том, что изменение положительно сказывается на производительности, может потребоваться определить комплексный набор тестов (также известный как "eval").

Тактика:

• Оценивайте выходные данные модели с учетом эталонных ответов

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

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

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

Разделители, такие как тройные кавычки, XML-теги, заголовки разделов и т.д., могут помочь разграничивать текст на секции, которые будут обрабатываться по-разному.

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

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

Предоставление общих инструкций, применимых ко всем примерам, как правило, более эффективно, чем демонстрация всех возможных вариаций задачи на примере, но в некоторых случаях предоставление примеров может быть проще. Например, если вы хотите, чтобы модель копировала определенный стиль ответов на запросы пользователя, который сложно описать явно. Это известно как подход с использованием "few-shot" запросов.

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

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

Учитывая, что все модели имеют ограниченные окна контекста, нам нужен способ динамически искать информацию, которая актуальна для задаваемого вопроса. Embeddings могут использоваться для реализации эффективного поиска знаний. Смотрите тактику "Используйте поиск на основе embeddings для реализации эффективного поиска знаний" для получения более подробной информации о том, как это реализовать.

Тактика: Инструктировать модель отвечать с цитированием из источника

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

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

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

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

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

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

Альтернативное решение - динамически выбирать предыдущие части диалога, которые наиболее актуальны для текущего запроса. См. тактику "Использовать поиск на основе embeddings для эффективного извлечения знаний".

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

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

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

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

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

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

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

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

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

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

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

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

Текстовый embedding - это вектор, который может измерять степень схожести между текстовыми строками. Похожие или релевантные строки будут ближе друг к другу, чем несвязанные строки. Этот факт, наряду с существованием быстрых алгоритмов поиска векторов, означает, что embeddings могут использоваться для реализации эффективного извлечения знаний. В частности, текстовый корпус может быть разделен на части, и каждая часть может быть представлена в виде embedding и храниться. Затем может быть представлен запрос в виде embedding, и может быть выполнен поиск вектора для нахождения вложенных частей текста из корпуса, которые наиболее связаны с запросом (то есть наиболее близки в пространстве embeddings).

Смотрите тактику "Инструктировать модель использовать извлеченные знания для ответа на запросы" для примера того, как использовать извлечение знаний для минимизации вероятности того, что модель представит неверные факты.

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

Еще один хороший пример использования выполнения кода - вызов внешних API. Если модель инструктирована о правильном использовании API, она может написать код, который использует его. Модель может быть инструктирована о том, как использовать API, предоставив ей документацию и/или примеры кода, показывающие, как использовать API.

ВНИМАНИЕ: Выполнение кода, созданного моделью, не является по своей сути безопасным, и при любом использовании, которое стремится сделать это, следует предпринять меры предосторожности. В частности, требуется среда выполнения кода с ограничением, чтобы ограничить вред, который могут нанести ненадежные коды.

API завершения чата позволяет передавать список описаний функций в запросах. Это позволяет моделям генерировать аргументы функций в соответствии с предоставленными схемами. Сгенерированные аргументы функций возвращаются API в формате JSON и могут быть использованы для выполнения вызовов функций. Вывод, предоставленный вызовами функций, затем может быть возвращен в модель в следующем запросе для замыкания цикла. Это рекомендуемый способ использования моделей OpenAI для вызова внешних функций.

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

Процедуры оценки (или "evals") полезны для оптимизации дизайна систем. Хорошие evals:

• Репрезентативны для использования в реальном мире (или по крайней мере разнообразны)
• Содержат множество тестовых случаев для большей статистической мощности (см. таблицу ниже для рекомендаций)
• Легко автоматизировать или повторять

Оценка выходных данных может выполняться компьютерами, людьми или их сочетанием. Компьютеры могут автоматизировать evals с объективными критериями (например, вопросы с одним правильным ответом), а также с некоторыми субъективными или нечеткими критериями, при которых выходные данные модели оцениваются другими запросами модели. OpenAI Evals — это программа с открытым исходным кодом, предоставляющая инструменты для создания автоматизированных evals.

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

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

Например, используя следующее системное сообщение:

Вот пример ввода, где оба пункта удовлетворены:

Вот пример ввода, где удовлетворен только один пункт:

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

Вот пример входных данных с неудовлетворительным ответом, который тем не менее не противоречит ответу эксперта:

Вот пример ввода с ответом, который прямо противоречит ответу эксперта:

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