Состояние для Jev

Допустимые структуры

Простейшее состояние — обычная строка: «С моей карты дважды списали деньги». Используйте строку, если случай описывается одним фрагментом текста. JSON-объект подходит для именованных полей, связанных записей или состояния приложения, например сообщения вместе с id заказа. Для последовательности сообщений или записей используйте массив текста. В Python передайте соответствующую строку, dict или list в client.system_one(state=...).

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

Jev принимает только текст. Состояние должно быть строкой, JSON-объектом или массивом текстовых значений. Изображения, аудио и видео не поддерживаются. Основной язык обучения — английский; другие языки, включая письменности CJK, принимаются с более низкой точностью. Это языковое ограничение описано в карточке модели. Не передавайте пиксели в запросе: сначала преобразуйте их в поля.

Отделяйте содержимое от вопросов

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

Большое состояние с множеством нерелевантных деталей — документированный источник ошибок jev-1.13. Постороннее содержимое отвлекает модель и снижает точность, а раздувшийся блок мешает понять, какое поле привело к неверному ответу. Сначала фильтруйте данные в коде. Отправляйте только поля, необходимые для вопроса. Если фильтрация невозможна, Noul может оценить релевантность фрагмента до основного суждения, как в руководстве TypeSafe по классификации фрагментов RAG.

Длина контекста ограничена. Jev 1.13 допускает 64k токенов для всего запроса и 32k для состояния вместе с самым длинным вопросом. Спекулятивный fan-out позволяет задать много коротких вопросов к компактному состоянию. Это дешевле и точнее, чем прикладывать полную историю заявки, когда нужны лишь последнее сообщение клиента и две строки списаний.

Запись службы поддержки как состояние

Документированный объект содержит ticket.subject, ticket.messages в виде пар from/text, order.id, order.charges с суммой и статусом, а также refund_policy в виде предложения. Тогда случай с повторным списанием представляется набором Nouls и Choices над этим объектом, а не чатом, где приходится заново излагать правила. Суммы уже известны вашему коду; Jev определяет, запрашивается ли в тексте возврат и применимо ли предложение с правилами.

В игровом цикле вроде Doom состояние — это структурированный текст с описанием мира, а не кадры. В демо TypeSafe этот текст отправляется примерно с 10 запросами в секунду. Для Wikiracing состоянием служат страница и ссылки-кандидаты. Для помощника умного дома — реплика пользователя и список устройств, уже хранящийся в памяти. Ни одно из этих демо не отправляет пиксели в Jev.

Если поле в базе данных числовое, для семантической оценки передавайте именованную категорию или вычисленное число («воспринимается ли этот цвет как предупреждение»), а расчёты с шестнадцатеричными значениями оставляйте коду. jev-1.13 распознаёт тройки RGB и шестнадцатеричные значения хуже, чем английские названия цветов. То же относится к датам: извлекайте части через Choice, а сравнивайте их в коде.

Лимиты и языки

Окно запроса размером 64k охватывает состояние и все вопросы. Окно размером 32k включает состояние и один самый длинный вопрос. Если поместить в состояние PDF с правилами на 20k, для карты вопросов останется мало места, а лишние подробности приведут к сбоям. Сначала найдите нужное, затем отправьте два абзаца, необходимых для оценки.

Сейчас наивысшая точность достигается на английском. Если заявки написаны на японском или корейском, обработайте выборку, постройте распределения уверенности Noul и Choice и оставьте проверку человеку, пока эти гистограммы не станут похожи на английские. Модель всё равно примет текст и не станет без предупреждения отклонять CJK.

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

Если поле нужно только для ваших журналов, не включайте его в состояние. Идентификаторы вопросов уже позволяют связывать данные. Состояние должно содержать доказательства, которые изучила бы группа людей. Такой подход также помогает уложиться в лимит 32k для состояния и самого длинного вопроса при длинной переписке в заявке.

Именованные поля лучше хитроумных кодировок. order_id, charges[].status и refund_policy понятны и вам, и Jev. Объединить те же факты в одну строку допустимо, но хуже. Документированный объект заявки в поддержку служит шаблоном: ticket, order, policy, а затем вопросы, ссылающиеся на эти имена.

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

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