TypeSafe и Jev в Laravel: что показала проверка 4 344 GitHub-проектов

Какую задачу поручили Jev

В IdeaRadar проекты проходят несколько этапов: сбор данных с GitHub, проверки PHP-кодом, первичную оценку через Ollama и подробный анализ через DeepSeek. На раннем этапе нужен ответ на один вопрос: есть ли в этом репозитории самостоятельная продуктовая идея, которую стоит изучить?

Для эксперимента Jev получил отдельный проход по накопленной базе. Он сохранял собственную оценку и не управлял отправкой проектов в DeepSeek. Так мы могли сравнить результаты, не меняя действующую маршрутизацию.

1. Подготовить данные

   Название, описание, README, метаданные репозитория и доступные сведения о главной странице.

2. Получить короткое решение

   Jev выбирает между «не стоит» и «стоит рассмотреть».

3. Сохранить результат

   Решение, вероятности, версию модели, хеш входа, время запроса и расход токенов.

4. Сопоставить с Ollama

   Сравнить, какие проекты каждая схема пропустила бы на следующий этап.

TypeSafe: решение с заданным типом ответа

В HTTP API TypeSafe передаются данные state и набор вопросов questions. Для нашей задачи подошёл Choice: выбор из заранее описанных вариантов. В ответе приходят выбранный вариант, распределение вероятностей и confidence.

Мы обращались к POST https://api.typesafe.ai/v1/systemone с моделью jev-latest. В сохранённых ответах всего прогона фактическая версия была jev-1.13.0. Это позволяет привязать результаты эксперимента к конкретной модели, даже если alias позже начнёт указывать на другую версию.

Как запускали проверку из Laravel

Добавили отдельный сервис на штатном HTTP-клиенте Laravel и разовую Artisan-команду. Вход собирался тем же builder, который использует короткий Ollama-gate. В API передавались сведения о проекте, без готовых вердиктов других моделей.

Команда фиксировала верхний ID выборки и сохраняла каждый результат сразу. Повторный запуск пропускал уже обработанные записи; для ошибок предусмотрели отдельный режим повторной проверки. При временных сбоях API выполнялись ограниченные повторы с увеличением задержки, а при проблемах авторизации или серии ошибок пакетная обработка останавливалась.

php artisan idearadar:jev-evaluate --max-id=111618
php artisan idearadar:jev-evaluate --report --max-id=111618

В таблице проектов появилась строка Jev - 1 или Jev - 2. В базе сохранили и подробный ответ: одной цифры недостаточно для последующего разбора ошибок.

4 344 запроса: скорость и результаты

Проход выполнен 21 сентября 2026 года, с 18:42:39 до 19:29:33 UTC — примерно за 47 минут. Обработка была последовательной.

Медиана запроса — 611 мс, 95-й процентиль — 734 мс, среднее — около 640 мс. Суммарный расход по ответам API: 4 764 842 входных и 139 008 выходных токенов. Денежную экономию по этим данным мы не заявляем: для неё нужно учесть тариф и стоимость дальнейшего анализа.

У сохранённых коротких запросов Ollama медиана составляла около 25 секунд. Это эксплуатационные замеры в разное время, а не синхронный тест на одинаковой нагрузке. Их также нельзя напрямую сопоставлять с длительным полным анализом из предыдущей статьи: здесь задача значительно уже.

Первая найденная ошибка — в нашей выборке

Для запуска мы выбрали проекты со статусом screening_decision=accept. При разборе обнаружили, что этот статус не равнозначен прохождению PHP pre-filter: среди 4 344 записей были 875 с решением reject и 20 без результата этого фильтра.

Корректная для следующего этапа группа pass/review составила 3 449 проектов. В ней Jev отклонил 1 299 и пропустил 2 150. Обе AI-оценки нашлись у 3 448 проектов — именно на них построено сравнение ниже.

Перед оценкой модели нужно проверить, какие записи действительно попали в эксперимент. Иначе показатели описывают другую выборку, чем та, которую мы собирались исследовать.

Почему совпадение с Ollama составило 59,8%

Схемы согласились в 2 062 случаях и разошлись в 1 386. 59,8% — доля совпадений, а не точность Jev. Ответ Ollama не является эталонной разметкой.

Из 1 291 случая «Jev пропускает, Ollama не пропускает» в 1 053 Ollama ответила MAYBE с confidence ниже 75. Код не отправляет такие проекты дальше. При этом инструкция Jev прямо предлагала выбирать consider при сомнениях. Значительная часть расхождений связана с разной политикой обработки неопределённости.

У 3 437 из 3 448 пар совпали сохранённые хеши входных данных. Остальные 11 пар нельзя считать сравнением на полностью одинаковом входе.

Аудит обнаружил и несогласованность интерфейса: таблица отображала любой MAYBE как положительную оценку Ollama, хотя реальная маршрутизация применяла порог. Для отчёта мы использовали правило из кода, а не цифру на экране.

Где Jev оказался полезен, а где ошибся

Самые показательные ошибки нашлись в FroggyAwesome/FroggyAwesome и jishan2001/jishan2001. Это README-профили разработчиков, но оба получили 2. Вероятность consider составила соответственно 91% и 78%.

Вероятное объяснение: модель перенесла ценность перечисленных в README проектов на сам репозиторий профиля. Например, упоминание собственной операционной системы заслуживает отдельного исследования, но не превращает страницу «обо мне» в программный продукт.

В выборке нашёлся 71 репозиторий, у которого имя совпадает с именем владельца; Jev пропустил 37. Это повод проверить потенциальные профили, а не доказательство 37 ошибок: совпадение имён само по себе недостаточно для окончательного решения.

Уверенность модели не заменяет проверку смысла

В 516 ответах всего прогона confidence оказался ниже 0,3. Текущая реализация всё равно сохраняла выбранный вариант как 1 или 2. Поэтому одинаковая цифра на экране могла скрывать и уверенное решение, и почти равные вероятности.

Согласно документации TypeSafe, confidence вычисляется из распределения вероятностей. Он помогает отличать определённый ответ от сомнительного, но не доказывает правильность классификации. Ошибка с профилем, получившим 91% за consider, хорошо показывает ограничение одного лишь порога.

Здесь нужны два разных исправления: точнее определить объект оценки в вопросе и отдельно решить, что делать при неопределённости. Для профилей полезна ещё и обычная проверка кодом до обращения к AI.

Быстрый фильтр может увеличить расходы дальше по цепочке

На общей группе из 3 448 проектов схема Ollama пропускает 953 кандидата, а Jev — 2 149. Если просто заменить один фильтр другим, поток в DeepSeek вырастет в 2,25 раза.

Это расчёт потенциальной нагрузки по сохранённым решениям. В эксперименте дополнительные запросы в DeepSeek автоматически не запускались. Больше кандидатов может означать меньше пропущенных идей, но также больше шума и расходов. Выбирать между этими вариантами нужно на размеченных примерах.

Что нужно проверить перед включением в основной конвейер

1. Зафиксировать выборку и правила

   Отбирать нужные результаты PHP-фильтра и одинаково трактовать сомнения у сравниваемых моделей.

2. Оценивать текущий репозиторий

   Явно отделять собственный продукт от упоминаний чужих или соседних проектов в README.

3. Подготовить ручную разметку

   Проверить 100–200 примеров: полезные продукты, профили, учебные работы, шаблоны и спорные случаи.

4. Измерить весь маршрут

   Считать пропущенные идеи, лишние допуски и стоимость DeepSeek вместе со скоростью первого запроса.

На момент этого эксперимента Jev остаётся отдельной оценкой для сравнения. Он показал подходящую скорость для массовой предварительной проверки, а анализ ошибок дал конкретный список доработок. Автоматическую замену Ollama эти результаты пока не обосновывают.