Проектирование эффективных примеров

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

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

Выбирайте примеры, чьё распределение входных данных соответствует рабочему трафику. Набор безупречных, коротких и простых примеров не справится с неаккуратными, длинными и неоднозначными входными данными, которые на самом деле отправляют пользователи.

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

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

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

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

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

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

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

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

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

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

Также не допускайте утечки ответа через формулировку входных данных (например, когда входные данные примера уже содержат целевую метку как слово).

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

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

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

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

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

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

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

Этот процесс превращает разработку примеров из интуитивного занятия в воспроизводимый инженерный процесс.

Примените принципы разработки примеров к неочевидному режиму отказа.

Основные выводы:

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