Контекст: Почему JEV важен для локального запуска
Архитектура Jev позиционируется как решение для задач, требующих мгновенной структурированной классификации (менее 0.1 секунды), таких как модерация чатов в реальном времени или фильтрация API-запросов. Традиционные LLM часто проигрывают здесь из-за долгих циклов генерации текста. Автор создал тестовый стенд на базе Ollama и модели Qwen 3 4B, реализовав интерфейс в стиле Tinder для модерации стримов, чтобы выявить структурные ограничения открытых моделей.
Ловушка №1: Опасная предвзятость порядка (Order Bias)
Самый простой подход — заставить модель выдать один токен (num_predict: 1) на основе списка вариантов. Однако тесты показали критическую чувствительность к порядку перечисления классов в промпте. При изменении порядка с [PASS, BAN] на [BAN, PASS] вердикт по одному и тому же сообщению менялся на противоположный.
| Конфигурация промпта | Сообщение | Вердикт | Интерпретация модели |
|---|---|---|---|
| Option A: [PASS, BAN] | "Are you dumb or just pretending? 😂" | BAN ❌ | Воспринято как враждебность |
| Option B: [BAN, PASS] | "Are you dumb or just pretending? 😂" | PASS ✅ | Воспринято как игривая шутка |
Это демонстрирует сильную позиционную предвзятость (Recency/Primacy Bias), характерную для LLM, оптимизированных под естественный язык, а не под строгую логику.
Ловушка №2: Стена двойного отклонения (Dual Rejection)
Чтобы устранить bias порядка, автор попытался эмулировать архитектуру Jev: вместо списка вариантов в одном промпте, классы оцениваются параллельно через два независимых запроса. Система отправляет сообщение в два потока, спрашивая у каждого: «Соответствует ли этот класс сообщению? Ответь ТОЛЬКО YES или NO».
Ключевая техническая реализация требовала отключения автогенерации (num_predict: 1) и использования асинхронных запросов (asyncio/httpx). Однако такой подход столкнулся с проблемой «двойного отклонения», когда модель может негативно оценить класс даже при его наличии в контексте, если промпт сформулирован недостаточно изолированно.
Ловушка №3: Отсутствие шаринга KV-кэша
Главное архитектурное преимущество Jev — разделение вычислений. В локальной среде с Ollama каждый параллельный запрос к модели Qwen 3 4B требует полного пересчета ключей и значений (KV cache) для контекста. Это нивелирует преимущество параллельности, так как вычислительная нагрузка на GPU возрастает линейно с количеством потоков, а не остается постоянной, как в специализированных архитектурах Jev.
Итог: Что это значит для разработчиков
Простое использование открытых моделей через Ollama для задач жесткой классификации в реальном времени сопряжено с рисками:
- Нестабильность: Вердикты зависят от синтаксиса промпта (порядка токенов).
- Производительность: Отсутствие шаринга KV-кэша делает параллельные запросы ресурсоемкими.
- Надежность: Модели типа Qwen 3 4B склонны к «двойному отклонению» при декомпозиции задачи.
Для продакшн-решений уровня JEV требуется не просто «запуск модели», а специализированная инфраструктура, учитывающая эти структурные ограничения.
Источник: Towards AI pub ↗