Методы разработки запросов

Эти методы не рекомендуется использовать для моделей рассуждения, таких как модели gpt-5 и o-серии.

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

Основы

В этом разделе рассматриваются основные понятия и элементы запросов GPT.

Текстовые запросы — это взаимодействие пользователей с моделями GPT. Как и во всех формируемых языковых моделях, модели GPT пытаются создать следующую серию слов, которые, скорее всего, следует из предыдущего текста. Это как если бы мы говорили вам что первое приходит вам на ум, когда я говорю <prompt>? В приведенных ниже примерах показано это поведение. Учитывая первые слова известного текста, модель может точно продолжить текст.

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

Компоненты запроса

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

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

Инструкции

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

Основное содержимое

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

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

Модели GPT также могут обрабатывать основное содержимое, структурированное. В приведенном ниже примере TSV о beers в Бельгии (сокращенном для отображения в этой статье) передается модели в рамках запроса. Он способен правильно интерпретировать содержимое и отвечать на вопросы о данных.

Примеры

Успешные запросы часто полагаются на практику "обучения с одного примера" или "обучения с нескольких примеров". Это относится к включению одного или нескольких примеров требуемого поведения модели, как правило, путем включения пар входных и выходных данных. Это не является обучением в том смысле, что модель постоянно меняется, но примеры лучше подготавливают модель для реакции, как необходимо, только на текущий запрос. Использование запросов без примеров иногда называется обучением с нулевым примером. Обратите внимание, что при использовании API завершения чата примеры few-shot learning обычно добавляются в массив сообщений в виде примеров взаимодействия пользователей и помощников после первоначального системного сообщения.

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

Сигнал

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

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

Вспомогательное содержимое

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

Руководство по конкретному сценарию

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

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

Обучение с малым количеством примеров

Распространенный способ адаптации языковых моделей к новым задачам — это использование обучения на малом количестве примеров. В обучении с малым количеством примеров набор учебных примеров предоставляется в качестве примера для дополнения контекстом модели.

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

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

Сценарии без чата

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

Начните с четких инструкций

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

Повторите инструкции в конце

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

Подготовьте выходные данные

Это относится к добавлению нескольких слов или фраз в конце запроса, чтобы получить ответ модели, следующий за требуемой формой. Например, с помощью подсказки, например “Here’s a bulleted list of key points:\n- ” , можно убедиться, что выходные данные форматируются в виде списка маркеров.

В приведенном выше запросе текст Один из возможных поисковых запросов: примитивирует модель для производства единственного вывода. Без этого подсказки модель создает несколько поисковых запросов в качестве выходных данных.

Добавление четкого синтаксиса

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

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

Если вы не уверены, какой синтаксис следует использовать, рекомендуется использовать Markdown или XML. Модели были обучены на большом количестве веб-содержимого в XML и Markdown, что может обеспечить лучшие результаты.

Разделить задачу на части

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

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

Использование возможностей

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

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

Цепочка мыслительных подсказок

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

Определение структуры вывода

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

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

Аналогичным образом, если вы попросите модель извлечь фактические инструкции из абзаца, это может извлечь составные инструкции, такие как "X выполняет Y AND Z" (что может быть труднее проверить). Это можно избежать, указав выходную структуру, например (entity1, relationship, entity2).

В этом примере показано использование ссылок и направление ответа модели в соответствии с определенной структурой.

Параметры температуры и Top_p

Изменение параметра температуры изменяет выходные данные модели. Параметр температуры можно задать от 0 до 2. Более высокое значение, например 0.7, добавляет больше случайности в результаты и создает более дивергентные ответы, в то время как меньшее значение, например 0.2 делает выходные данные более ориентированными и конкретными. Вымышленная история может быть создана с помощью более высокой температуры. В то время как для создания юридического документа рекомендуется использовать гораздо более низкую температуру. Top_probability является другим параметром и похож на температуру в том, что он также управляет случайностью ответа модели, но это делает это другим способом. Общая рекомендация заключается в изменении одного из этих двух параметров одновременно, а не обоих.

Предоставление основного контекста

Одним из наиболее эффективных способов предоставления надежных ответов является предоставление модели данных, от которых модель может черпать свои ответы (основные данные). Если ваш сценарий использования опирается на актуальную, надежную информацию и не является исключительно творческим, мы настоятельно рекомендуем предоставлять обоснованные данные. Как правило, чем ближе вы можете получить исходный материал к окончательной форме нужного ответа, тем меньше работы модели необходимо сделать, что означает, что существует меньше возможностей для ошибки. Приведен пример, когда системе предоставлен блог, описывающий запуск GPT-4 в Azure OpenAI в Microsoft Foundry Models, и требуется назвать некоторых из его первых клиентов.

¹ текст из Azure блог о запуске OpenAI GPT-4.

Лучшие практики

• Будьте конкретными. Оставьте как можно меньше интерпретации. Ограничить рабочее пространство.
• Будьте описательными. Используйте аналогии.
• Дважды вниз. В некоторых случаях может потребоваться повторить себя для модели. Дайте инструкции до и после основного содержимого, используйте инструкцию и подсказку и т. д.
• Вопросы заказа. Порядок представления сведений модели может повлиять на выходные данные. Размещение инструкций перед содержимым («суммируйте следующее…») или после («суммируйте вышеупомянутое…») может повлиять на результат. Даже порядок примеров с несколькими выстрелами может иметь значение. Это называется предвзятостью новизны.
• Присвойте модели значение out. Иногда это может быть полезно, чтобы предоставить модели альтернативный путь, если он не может завершить назначенную задачу. Например, когда задаёте вопрос по фрагменту текста, можно попросить что-то вроде "ответить 'не найдено', если ответ не найден". Это поможет модели избежать генерации неверных ответов.

Эффективность пространства

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

Учитывая это ограниченное пространство, важно использовать его как можно эффективнее.

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