Jev: новая модель безопасности для LLM, основанная на энкодерах
В сентябре 2026 года компания TypeSafe представила модель Jev, которая позиционируется как guard-модель для больших языковых моделей (LLM). В отличие от предыдущих решений, использующих большие нейросети, Jev основана на архитектуре энкодеров с контекстным окном до 64К токенов. Автор статьи с участием разработчика Raft провел тестирование модели на бенчмарке AEGIS 2.0 и проанализировал её ограничения в задачах детекции персональных данных.
# Jev: новая архитектура для защиты от промпт-инъекций
От LLM к энкодерам: смена парадигмы
Рынок моделей безопасности (Guard models)经历了一场 значительную трансформацию. Два года назад лидирующие позиции занимали модели на базе больших языковых моделей, такие как Qwen Guard, GPT OSS Safeguard и Yufeng Xguard. Несмотря на высокую точность, они требовали значительных вычислительных ресурсов и памяти. Более доступными, но менее качественными альтернативами выступали энкодеры типа BERT, которые часто страдали от недостаточной поддержки мультиязычности.
Однако ситуация изменилась в мае 2026 года. В опенсорс одновременно вышли три новых проекта от независимых организаций: Gliner Guard от Raft, GliGuard от Fastino и Gliclass Guard. Все они базируются на архитектуре энкодеров, что позволяет снизить требования к ресурсам при сохранении высокого качества. Именно в этом контексте 15 сентября появился Jev от компании TypeSafe.
Важно отметить устойчивую тенденцию в индустрии: если модель не является большой языковой моделью (LLM), но выполняет функцию классификации безопасности, правильным термином для её описания становятся "LLM Guardrails". Jev следует этому паттерну.
Технические особенности и контекстное окно
Одним из ключевых преимуществ Jev является возможность обработки длинных контекстов. Документация TypeSafe указывает на поддержку до 64К токенов на запрос. Это существенно отличается от классических энкодеров, которые обычно ограничиваются окнами в 512, 2048 или максимум 8192 токенов.
Существует вероятность, что авторы Jev разработали уникальный подход к механизму внимания (attention mechanism), позволяющий эффективно обрабатывать большие объемы текста без потери производительности, аналогично тому, как это реализовано в Privacy Filter от OpenAI с использованием бэндованного внимания (banded attention). Другой вариант — использование гибридной архитектуры или ex-decoder'а.
Тем не менее, модель имеет существенное ограничение: она не способна выполнять традиционную задачу извлечения сущностей (Named Entity Recognition или NER). Jev может определить, что в тексте присутствуют персональные данные, но не может выделить конкретный фрагмент (спан) текста, содержащий эти данные. Для полноценной маскировки ПДн (персональных данных) на основе только Jev потребуется дополнительное внедрение классического NER-модуля или полная блокировка запроса.
Результаты тестирования на бенчмарке AEGIS 2.0
Для оценки эффективности модели использовался бенчмарк AEGIS 2.0 от NVIDIA, включающий тесты на безопасность (safety) и анализ ответов LLM. Тестирование проводилось через интеграцию с LangChain.
На промптах распределение оценок было бимодальным: безопасные запросы получали низкие баллы, а вредоносные — высокие. Однако модель допускала ошибки: при пороговом значении 0.5 каждый шестой безопасный запрос ошибочно блокировался, а каждый шестой вредоносный пропускался (F1-мера составляет 0.85).
Анализ ответов LLM показал более сложную картину. Модель хорошо ранжировала ответы по уровню безопасности (AUC-ROC 0.927), но порог 0.5 оказался неоптимальным для детекции вредоносного контента в ответе, что привело к показателю recall 0.76.
Сравнение с другими решениями в бенчмарке GuardRate показало, что Jev занимает второе место с метрикой 0.835. Это позволяет ему обогнать многие известные LLM-guard модели, такие как Qwen3Guard-Gen-8B и версии YuFeng-XGuard, уступая только модели opir-multitask-large на архитектуре GliClass (0.906).
Ограничения и практические выводы
Несмотря на впечатляющие результаты, внедрение Jev в продакшн требует учета двух критических факторов.
Во-первых, работа с Jev происходит через вызов внешнего API. Это создает риск утечки конфиденциальной информации, если пользователь передается данные напрямую в модель. Согласно законодательству о защите персональных данных (например, ФЗ-152 в РФ), передача тайны во внешний сервис может быть нарушением. Перед отправкой текста в Jev необходимо убедиться, что все ПДн удалены или маскированы.
Во-вторых, качество работы модели напрямую зависит от качества обучающей выборки. В статье отмечается, что бенчмарк AEGIS 2.0 состоит преимущественно из англоязычных примеров, на которых Jev, вероятнее всего, был протренирован. Применение модели к русскоязычному контенту или специфическим доменам потребует дополнительной валидации и проверки на ложные срабатывания.
Итоговая оценка: Jev демонстрирует высокий потенциал как эффективное решение для фильтрации промптов и ответов, особенно с учетом компактности и поддержки длинного контекста. Однако он не может заменить комплексную систему безопасности, включающую защиту данных и доменную адаптацию.
*Авторский комментарий: развитие энкодеров в сфере безопасности позволяет делать системы защиты более прозрачными и предсказуемыми, устраняя «черный ящик», характерный для сложных LLM, хотя и за счет меньшей гибкости в нюансах понимания контекста.*