state — что оцениваем, и questions — что хотим узнать. Качество ответов почти целиком определяется тем, как сформулированы вопросы. Если вы ещё не отправляли запросов — начните с первого запроса.
Один вопрос — одно суждение
Задавайте вопросы, на которые знающий человек ответит за секунду, взглянув на текст.
Если решение зависит от нескольких факторов — спросите про каждый отдельно и сложите ответы в коде со своими весами. Изменились приоритеты — меняете коэффициент, а не переписываете промпт. Лишних запросов это не добавляет: все вопросы к одному
state уходят одним запросом и обрабатываются параллельно.
Из чего состоит вопрос
- Имя вопроса (
refund_requested) — для вашего кода: под ним придёт ответ. Модель его не видит, поэтому весь смысл должен быть вinstructions. type—noul,choiceилиscore.instructions— сам вопрос. Пишите точно и буквально: Jev отвечает на то, что написано, а не на то, что вы имели в виду.criteria— варианты ответа: уchoiceобязательны, уscoreобязательны, уnoul— по желанию.
Noul — да или нет
Возвращает вероятность «да» от 0 до 1. Около 1 — уверенное «да», около 0 — уверенное «нет», около 0,5 — модель не знает.criteria:
Choice — выбор из вариантов
Подходит, когда ответ — одна из известных категорий без порядка между ними: отдел, тема, тип документа, язык.- Ключ — имя варианта, значение — его описание. Модель видит и то и другое, поэтому описания должны отличать варианты друг от друга. Если имя говорит само за себя, вместо описания можно передать
null. - Давайте полный список, а не выжимку: вариантов может быть до 255, каждый стоит несколько токенов.
- Добавляйте
otherили «ничего из перечисленного», если список может не покрывать все случаи. Иначе модель будет вынуждена выбрать неподходящий вариант.
choice — победитель, probabilities — вероятности всех вариантов (в сумме 1), confidence — насколько победитель оторвался от остальных.
Score — оценка по шкале
Подходит, когда ответ лежит на спектре и вы можете описать каждую его точку: критичность, раздражение, релевантность, качество.score в ответе — положение на этой шкале, и оно может оказаться между уровнями: 1,3 означает «в основном уровень 1, отчасти уровень 2».
Как писать уровни:
- Описывайте ситуации, а не степени. «Функция сломана, но есть обходной путь» модель может сопоставить с текстом. «Умеренно серьёзно» — не с чем сопоставлять.
- Каждый уровень оценивается отдельно, соседей модель не видит. Фразы вроде «хуже предыдущего» и цифры в описаниях не работают.
- Одна шкала — одно измерение. «Пунктуальный, умный и опытный» — это три шкалы. Разделите и сложите в коде.
- От 2 до 10 уровней. Берите столько, сколько можете описать различимо; трёх обычно достаточно.
- Если на краю шкалы есть редкий случай, на который нужна особая реакция, дайте ему свой уровень: после «очень зол» добавьте «угрожает или оскорбляет».
Один и тот же
score могут дать разные распределения: 1,0 — это и «точно уровень 1», и «поровну 0 и 2». Смотрите на confidence и probabilities вместе со score. Низкая уверенность обычно значит одно из трёх: уровни перекрываются, вопрос измеряет сразу несколько вещей или в тексте недостаточно данных.Какой тип выбрать
Берите тот, чей ответ код использует напрямую:noul ложится в if, choice — в ветвление по категориям, score — в порог или сортировку.
Что класть в state
state — это материал для оценки: строка, объект или массив. Только текст: изображения, аудио и видео не поддерживаются.
В большинстве случаев лучше объект: у каждой части есть имя, и в вопросе на неё можно сослаться.
Кладите только то, что нужно для решения. Лишний текст отвлекает модель и снижает точность — отфильтруйте данные в коде до запроса. Актуальные факты (правила возврата, остатки, статус заказа) передавайте в
state, а не рассчитывайте на знания модели.
Ссылки на части state
Еслиstate — объект, укажите в вопросе путь к нужной части в обратных кавычках:
refund_requested — 0,98, policy_supports_refund — 0,97.
Много вопросов одним запросом
Все вопросы к одномуstate отправляйте вместе. Они обрабатываются параллельно и независимо: время ответа почти не растёт, а ответ на один вопрос не влияет на другой.
Спрашивайте и то, что может не понадобиться. Если обращение окажется не про баг — просто не читайте ответ про критичность бага. Лишний вопрос стоит несколько токенов, а отдельный запрос — ещё раз весь state и служебные токены.
Второй запрос оправдан только тогда, когда без первого ответа его нельзя составить: нужно сходить за данными, зависящими от ответа, или варианты следующего вопроса определяются предыдущим (обход дерева категорий уровень за уровнем).
Предел — общий бюджет запроса, см. ограничения.
Когда варианты путаются: структурные описания
Начинайте с коротких строк. Если модель стабильно путает два близких варианта, опишите каждый объектом: что входит, что не входит, примеры. Имена полей вы придумываете сами — модель видит их вместе со значениями, так что называйте понятно и одинаково у всех вариантов.return_status с уверенностью 1,0.
Так же можно структурировать instructions, уровни score и criteria у noul. Примеры помогают, только когда похожи на ваши реальные данные.
Памятка
Формулировки
Формулировки
- Один вопрос — одно суждение.
- Пишите буквально: точное условие, граничные случаи — в
criteria. - Избегайте двойных отрицаний и вопросов «про свойство свойства».
- Следите, чтобы
instructionsиcriteriaне противоречили друг другу.
State
State
- Объект с именованными полями вместо одной длинной строки.
- Только то, что нужно для решения.
- В вопросах — пути к полям в обратных кавычках.
Запросы
Запросы
- Все вопросы к одному
state— одним запросом. - Спрашивайте с запасом, лишнее игнорируйте в коде.
- Пороги уверенности подбирайте на своих данных.