Если вы ищете информацию о том, как использовать модель Jev AI, начните с одной практической идеи: Jev создана для принятия решений, которые может использовать программное обеспечение, а не для замены чат-интерфейса. Вы предоставляете состояние, задаете один или несколько типизированных вопросов и получаете структурированные ответы с сигналами вероятности.
Это делает Jev полезной для таких задач, как классификация тикетов поддержки, маршрутизация запросов, оценка рисков, принятие решений о необходимости проверки действия или выбор следующей модели в рабочем процессе агента. На домашней странице Jev AI это описывается как уровень принятия решений для команд разработчиков ПО.
Это руководство демонстрирует полный путь от первого эксперимента до интеграции API на стороне сервера.
Что делает модель Jev AI
Традиционные языковые модели обычно используются для генерации текста. Jev фокусируется на более узком и прикладном вопросе: учитывая данное состояние, какое структурированное решение должно принять приложение дальше?
Базовое взаимодействие состоит из трех частей:
- Состояние (State) — текст, JSON-объект или массив текста, предоставляющий контекст.
- Вопросы (Questions) — решения, которые требуются вашему приложению.
- Ответы (Answers) — типизированные результаты, на основе которых ваш код может выполнять ветвление, сортировку, маршрутизацию или проверку.
Например, рабочий процесс поддержки может отправить тикет в качестве состояния и попросить Jev определить его отдел, срочность и необходимость проверки человеком. Эти вопросы могут оцениваться одновременно для одного и того же состояния.
Jev наиболее полезна, когда пространство ответов четко определено. Если вам нужно развернутое объяснение, творческий черновик или длинный ответ в стиле диалога, лучше подойдет генеративная LLM. Jev при этом может использоваться до или после LLM для управления маршрутизацией и выполнением.
Шаг 1: Выберите одно решение с четким результатом
Первый шаг в изучении того, как использовать Jev AI, — это не написание промпта. Это определение решения, которое должен принять ваш продукт.
Хорошие первые решения:
- В какой отдел должен поступить этот запрос в поддержку?
- Достаточно ли этот запрос срочный, чтобы попасть в очередь приоритетов?
- Требует ли этот предлагаемый вызов инструмента одобрения человеком?
- Насколько серьезна проблема по определенной шкале?
- Какая модель должна обработать следующий шаг?
Избегайте начала с расплывчатых запросов, таких как «пойми этого клиента». Превратите это в ограниченный вопрос, например: «Какой утвержденный отдел поддержки должен обработать этот тикет?». Узкий вопрос легче оценить, легче протестировать на исторических примерах и безопаснее связать с логикой приложения.
Шаг 2: Подготовьте состояние
Состояние — это контекст, который считывает каждый вопрос. В настоящее время Jev принимает три полезных формата входных данных:
Текстовое состояние
Используйте строку для сообщения, тикета, электронного письма или короткого документа.
Состояние в виде JSON-объекта
Используйте объект, когда решение зависит от нескольких именованных полей. Это позволяет сохранить важный контекст явным, а не скрывать все в одном длинном промпте.
Состояние в виде массива
Используйте массив, когда контекст естественным образом состоит из нескольких текстовых элементов, таких как несколько сообщений или заметок. Сосредоточьте массив на доказательствах, необходимых для принятия решения.
Не отправляйте больше данных, чем нужно для вопроса. Меньшее по объему и релевантное состояние облегчает понимание рабочего процесса и помогает определить, какие именно данные повлияли на ответ.
Шаг 3: Выберите правильный тип вопроса
Jev предоставляет три основных типа вопросов. Выбирайте тип, который соответствует форме решения, а не пытайтесь подогнать каждую задачу под промпт «да или нет».
Используйте Choice (Выбор) для классификации
Choice подходит, когда у приложения есть конечный набор направлений. Например, «биллинг», «техническая поддержка» и «продажи» могут быть утвержденными отделами для тикета.
Используйте Score (Оценка) для спектра
Score полезен, когда есть упорядоченные уровни, такие как низкая, средняя и высокая степень серьезности. Определите уровни от низкого к высокому. Возвращаемая оценка взвешена по вероятности, поэтому она может выражать позицию между названными уровнями.
Используйте Noul для конкретного утверждения
Noul хорошо подходит для таких вопросов, как «Содержит ли этот запрос срочный дедлайн?» или «Должен ли человек проверить это действие?». Результатом является вероятность от 0 до 1 того, что утверждение истинно.
Вы можете комбинировать Choice, Score и Noul в одном запросе. Присвойте каждому вопросу стабильный ключ, так как этот же ключ используется для поиска ответа в результате.
Шаг 4: Проверьте решение в Playground
Прежде чем добавлять учетные данные или производственный код, протестируйте вопрос с реальными примерами в Jev AI Playground.
Используйте этот короткий цикл проверки:
- Вставьте репрезентативное состояние.
- Добавьте один четко сформулированный вопрос.
- Запустите решение и изучите ответ и вероятность.
- Повторите с четкими примерами, граничными случаями и неоднозначными ситуациями.
- Перепишите инструкции или критерии, если результат трудно интерпретировать.
Цель состоит не в том, чтобы сделать один пример «правильным». Создайте небольшой набор для оценки, который представляет трафик, который действительно будет получать ваше приложение. Включите случаи, когда правильным действием будет приостановка, запрос дополнительной информации или отправка элемента на проверку человеку.
Шаг 5: Вызовите Jev API с вашего сервера
Как только вопрос станет полезным, создайте ключ API и вызывайте производственную конечную точку (endpoint) с серверной службы. Текущая конечная точка:
Отправьте ключ API в качестве Bearer-токена и включите состояние, модель и вопросы в тело JSON. Название текущей флагманской модели в справочнике API — jev-latest.
Храните JEV_API_KEY в переменной окружения на стороне сервера. Не помещайте его в код браузера, публичную статью, клиентский бандл или репозиторий.
Шаг 6: Используйте структурированный ответ в коде приложения
Ответ содержит результат для каждого ключа вопроса. Упрощенный ответ может выглядеть так:
Ваше приложение должно решать, что делать дальше. Например:
Важная граница заключается в том, что Jev возвращает сигнал, а ваш код отвечает за действие. Jev не должен молча удалять данные, отправлять платеж, публиковать контент или вызывать чувствительный инструмент без проверки прав на уровне приложения.
Как безопасно использовать вероятность и уверенность
Вероятность и уверенность полезны для маршрутизации, ранжирования и эскалации, но они не являются гарантией того, что бизнес-решение верно. Рассматривайте их как сигналы, которые помогают вашей системе выбрать путь.
Практическая политика может быть такой:
- высокая вероятность и низкий риск → продолжать автоматически;
- средняя вероятность или незнакомый случай → собрать больше контекста;
- рискованное действие или низкая уверенность → требовать одобрения человека;
- неподдерживаемый или некорректный ввод → вернуть ошибку или использовать безопасный запасной вариант.
Выбирайте пороговые значения, используя исторические примеры, затем отслеживайте ложноположительные и ложноотрицательные результаты после запуска. Порог, который работает для маршрутизации поддержки, может быть неуместен для платежей, доступа к аккаунту или деструктивных инструментов.
Чек-лист для продакшена
Перед запуском рабочего процесса Jev проверьте следующее:
- Решение имеет определенное пространство ответов.
- Состояние содержит доказательства, необходимые для вопроса, и минимум не относящихся к делу данных.
- Каждый вопрос имеет одну четкую цель.
- Критерии выбора взаимно понятны и полны.
- Уровни оценки упорядочены от низкого к высокому.
- Инструкции Noul описывают одно проверяемое утверждение.
- Ключ API хранится на стороне сервера.
- Тайм-ауты, повторные попытки и ошибки API имеют безопасный запасной вариант.
- Пороговые значения вероятности и уверенности протестированы на исторических данных.
- Для выполнения действий с высоким уровнем воздействия по-прежнему требуются разрешения приложения или проверка человеком.
- В журналах фиксируются версия входных данных, версия вопроса, результат и окончательное действие без раскрытия секретных данных.
Для получения актуальной информации о полях запросов, форматах ответов, границах входных данных и обработке ошибок используйте документацию Jev AI API в качестве основного источника.
Часто задаваемые вопросы об использовании Jev AI
Является ли Jev AI чат-ботом?
Нет. Jev предназначен для типизированных решений, которые может использовать программное обеспечение. Он может быть частью более крупного ИИ-продукта, но в первую очередь не является генератором чат-транскриптов.
Могу ли я задать несколько вопросов в одном запросе?
Да. Несколько вопросов могут использовать одно и то же состояние и оцениваться параллельно. Это полезно, когда для одного рабочего процесса требуется классификация, оценка и проверка безопасности одновременно.
Должен ли Jev заменить мою LLM?
Не автоматически. Используйте Jev для ограниченных решений, а генеративную модель — для написания текстов, суммаризации или рассуждений открытого типа. Во многих системах Jev определяет, какая модель или инструмент должны быть запущены следующими.
Могу ли я отправлять изображения, аудио или видео в качестве состояния?
В текущей документации API в качестве поддерживаемых входных данных состояния указаны текст, JSON-объекты и массивы текста. Изображения, аудио и видео не указаны как поддерживаемые прямые входные данные, поэтому преобразуйте или обобщите эти источники в своем приложении, прежде чем задавать вопрос для принятия решения.
Заключение
Самый простой способ использования модели Jev AI — начать с одного решения с низким уровнем риска: подготовьте минимально полезное состояние, определите типизированный вопрос, протестируйте его на репрезентативных примерах и подключите структурированный результат к коду. Как только этот цикл станет надежным, добавьте параллельные вопросы, проверку на основе вероятностей, маршрутизацию моделей и проверки разрешений.
Jev наиболее ценен, когда приложению требуется повторяемое решение с четким последующим действием. Оставляйте конечное действие в своем коде, храните учетные данные на сервере и используйте оценочные данные, чтобы определить, где должна заканчиваться автоматизация и начинаться суждение человека.
