Наблюдения за экосистемой Jev (часть 3): неудачи за четыре дня и когда Jev не стоит доверять

В двух предыдущих статьях мы рассказали об успехах, которых эта экосистема добилась за четыре дня. Эта статья посвящена обратной стороне: журналам неудач. Критерии доказательности прежние: все данные взяты из наших десяти раундов сканирования с 2026-09-15 по 09-19, все сторонние цифры указаны самими авторами и оценены по уровням A/B/C; при этом исходные тексты ключевых оценок, на которые мы ссылаемся, мы прочитали дословно, слово за словом.

Строгий эксперимент за $1,43

В рамках независимой оценки agentjournal был проведён один из самых основательных контрольных экспериментов в экосистеме: три задачи классификации, 5 477 тестовых записей, 34,1 млн токенов и общая стоимость $1,43. Сравнивались «один прямой запрос» и «разбиение на 12–14 измерений для оценки с последующей локальной подгонкой». Вот пять выводов, которые стоит запомнить:

1. Не разбивайте простые задачи на измерения. На 200 синтетических примерах с ловушками прямые запросы дали 100% точности — и сохранили те же 100% после замены меток местами, без позиционного смещения, — тогда как пайплайн с разбиением на 12 измерений дал 98,0%. Дополнительные токены лишь ухудшили результат.
2. Некорректное разбиение выборки при оценке заставляет цифры лгать. Случайная кросс-валидация показала 98,0%, но при группировке по семействам шаблонов и исключении совпадающих признаков из обучающей выборки результат упал до 90,0%: утечка через шаблоны дала 8 процентных пунктов. При том же разбиении бесплатный бейзлайн на символьных биграммах достиг 93,5% и превзошёл этот результат. У автора стоит перенять две привычки: всегда сначала выводить бейзлайн мажоритарного класса и проектировать разбиение до просмотра датасета.
3. Разбиение на измерения даёт выигрыш только на сложных задачах. На задаче с 300 записями, где метки были скрыты в совокупности нескольких слабых сигналов, прямые запросы дали 64,7%, а разбиение на измерения — 74,0% (прирост 9 пунктов, p = 0,0050), но бесплатный бейзлайн на символьных биграммах тоже показал 74,0%. Сначала постройте бесплатный бейзлайн, а затем обсуждайте модели.
4. Широкий выбор неизбежно ломается. На реальных бухгалтерских данных промпт с 12 вариантами в одном выборе дал точность всего 0,3998: «каждое слово понято, но выбрать 1 из 12 не получилось», то есть узкое место — формат решения, а не понимание. Разбиение на 14 измерений с весами подняло точность до 0,9105, а в связке с n-граммами — до 0,9695.
5. В сценариях, чувствительных к ложным срабатываниям, разбиение на измерения губительно. На 339 сложных безвредных примерах («упоминают методы атак, но остаются безвредными» — например, в документации по безопасности, заметках о тестировании защиты и статьях вроде этой) прямые запросы дали 1,5% ложных срабатываний, а разбиение на 12 измерений — 37,2%: показатель оказался примерно в 25 раз выше, и все четыре попытки исправить проблему провалились. Вывод автора: проблема в устройстве измерений, а не в настройке параметров; корректные прямые вызовы должны выступать независимыми судьями наряду с моделями, а не встраиваться в модели как признаки.

Даже официальные примеры не избежали проблем

Сообщество задокументировало это в обсуждении № 2 о «Быстром старте» официального SDK для Python: в примере было указано, что комментарий к тикету следует классифицировать как technical, но участники получили billing (0,67), причём результат не менялся в 100 прогонах. Когда тикет поддержки содержит и сбой оплаты, и ошибку интеграции, граница между тремя классами по своей природе размыта. Однако то, что официальный пример не соответствует собственному ожидаемому результату, ощутимо подрывает доверие новичков.

Честные примеры от самих разработчиков продуктов

Ценнее официальных провалов — недостатки, раскрытые самими продуктами. Продукт для проверки утверждений Attest раскрыл две цифры: он убрал поле уверенности, потому что 22 из 24 реальных проверок попадали в диапазон 0,95–0,99 («число, которое всегда одинаковое, — это не информация»), а если подать доказательства в обратном порядке, меняются 5,8% решений. Оценщик стартап-идей killmyidea протестировали пользователи и обнаружили, что удаление трёх символов заметно сдвигает оценки, после чего автор признал, что это лишь «стабильный способ проверить интуицию, а не оракул». В играх автор ИИ для воздушных боёв сам признал, что его система «довольно плоха»; в трейдинге кто-то выложил неотфильтрованные данные: 41,1% прибыльных сделок из 375 симулированных. В экосистеме, где все сообщают только хорошие новости, цифры без хайпа заслуживают отдельного внимания.

Есть и метапредупреждение: известный разработчик steve8708 публично указал, что вирусные демо Jev в X смешивают ускоренные записи и сфабрикованный контент. Мы отразили это в критериях включения: демо со «сверхчеловеческой скоростью» учитываются только при наличии полного описания методики и трассировок запусков.

Когда Jev не стоит доверять

Если объединить уроки этой и предыдущей статьи, получится список предостережений:

• Уверенность ≥ 0,9 не означает, что результат верен: среди этих 42% записей с высокой уверенностью точность составила всего 72,2%.
• Разбиение на измерения не означает большей строгости: в сценариях, чувствительных к ложным срабатываниям, оно работает в 25 раз хуже.
• Больше десяти вариантов за раз: точность падает прямо до уровня случайного бейзлайна.
• Если менять порядок и формулировки входных данных, оценки также могут меняться.
• Пока не запущены бесплатные бейзлайны (n-граммы, наивный Байес, правила), делайте скидку на любые цифры точности.
• Если разбиение спроектировано без учёта реальных распределений, утечка через шаблоны может из ничего добавить 8 пунктов.

Соответствующий список мер защиты состоит из шести пунктов: отдавайте приоритет прямым запросам, предлагайте небольшой набор вариантов ответа, фиксируйте порядок входных данных, сначала запускайте бейзлайны, ведите независимые наборы для оценки и используйте прямые вызовы как независимых судей. Оптимальная зона для примитивов решений остаётся в силе (узкая задача × высокая частота × ограниченное действие), но за её пределами такие примитивы действительно могут навредить.

В следующей статье серии мы отойдём от отдельных кейсов и рассмотрим инфраструктурный слой, который уже вырос в этой экосистеме. Если вашему слою суждений нужны надёжные данные о комментариях, репутации и ценах, начните с руководства по интеграции единого API данных.