Jev стоит копейки, но я бы не доверил ему решать, кому продавать

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

Jev от TypeSafe - новая модель для принятия решений по тексту. Даёшь ей исходные данные и конкретный вопрос, получаешь ответ в заданном формате. Например, выбор из нескольких вариантов, оценку по шкале или суждение о том, верно ли утверждение. Дальше этот ответ использует программа.

В GTM, то есть в работе по привлечению клиентов и продажам, таких решений полно. Нужно решить, подходит ли контакт, подтверждаются ли факты в персональном письме и кому передать входящий ответ. Jev выносит суждение, а сбор данных и дальнейшие действия остаются за системой вокруг него.

У Jev есть три типа вопросов. Choice выбирает из вариантов, которые ты уже передал: например, какое из готовых предложений подходит компании. В список стоит включить «ничего не подходит». Noul оценивает вероятность того, что утверждение верно по заданным данным. Score ставит оценку по описанной шкале, например насколько явно вакансия подтверждает потребность в интеграции CRM. CRM здесь просто система, в которой команда ведёт клиентов.

Письмо Jev за тебя не напишет. Для текста нужен человек или генеративная модель. И несколько вопросов в одном запросе он рассматривает независимо. Если следующий вопрос зависит от предыдущего ответа, эту зависимость придётся организовать в коде или отдельном запросе.

Смысл оценки тоже задаём мы. Высокий балл соответствия нашим критериям ещё ничего не говорит о вероятности покупки. Для автоматической отправки письма такого балла недостаточно.

У других авторов нашёл демо для поиска обсуждений, разбора рекламы конкурентов, форм, презентаций, оценки постов и подбора сообщений под клиентов. Идей хватает. Проверять результат каждой придётся отдельно.

19 сентября 2026 года мы оценили 83 контакта для двух B2B-брендов. Вызовы Jev в этом тесте стоили $0,0055. Здесь только стоимость работы модели, без поиска данных и ручной проверки.

За эталон мы взяли согласованные оценки трёх независимых агентов на языковых моделях. Люди не размечали всю выборку, и данных о реальных покупках у нас не было. Мы специально собрали сложные пограничные примеры. Промпты настраивали на той же выборке; отдельный тест на незнакомых контактах не проводили. По этому эксперименту нельзя оценить точность на всей рабочей базе.

Jev совпал с эталонной категорией у 77% контактов для первого бренда и у 76% для второго. Но из тех, кого эталон рекомендовал для обращения, модель выбрала только 60% и 44% соответственно. Остальных пропустила. Метка «писать» здесь означает соответствие нашим критериям, а не разрешение отправлять человеку сообщение.

Мы сравнили Jev с шестью моделями: deepseek-v4-flash, deepseek-v4.1-flash, qwen3.8-flash, mercury-2.5, gpt-5.6-luna и glm-5.3-flash. Это идентификаторы моделей, которые мы запрашивали у провайдера. У всех шести был один короткий промпт и стандартные настройки рассуждения провайдера. Jev получал вопросы через свой интерфейс с заданными типами ответа. Для GPT-5.6 Sol использовали пакетную обработку, поэтому напрямую сопоставлять результаты нельзя.

По стоимости Jev оказался примерно в 2-33 раза дешевле шести вариантов с коротким промптом. Победителя по качеству этот небольшой тест не установил. Равенство моделей тоже не доказал. Я бы оставил человеку спорные решения об отборе, особенно отказы.

За общей цифрой совпадений легко пропустить разницу в ошибках. На первом бренде Qwen3.8 Flash получил те же 77%, что и Jev. При этом Qwen нашёл 80% контактов из эталонной категории «писать», а Jev только 60%. Из выбранных моделью для обращения контактов с эталоном совпали 92% у Qwen и 82% у Jev. Прямых перескоков между «писать» и «нет» у Qwen не было, у Jev их оказалось шесть.

DeepSeek V4.1 Flash совпал с эталонной категорией в 81% случаев и нашёл 80% эталонных «писать». За прогон по 83 контактам он стоил $0,1834, Qwen стоил $0,1463. Jev потратил $0,0055; медианное время одного запроса составило 0,95 секунды. У Qwen это было 52,3 секунды, у DeepSeek V4.1 Flash 30,5. Это время отдельного запроса, не всего прогона.

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

На графике стоимость вызовов модели и совпадение с эталонной разметкой на 83 контактах. Размер круга показывает медианное время ответа. Совпадение с разметкой не измеряет продажи.

Jev я бы поручал узкие вопросы. Дальнейшие действия задавал бы в коде.

Здесь и проявляется история с размером компании. Можно отдельно спросить, подходит ли бизнес, за какую функцию отвечает человек и распоряжается ли он нужным бюджетом. Если ответы спорят друг с другом, контакт уходит на проверку. «Неизвестно» нужно хранить отдельно от «нет». И смотреть тех, кого система собирается отсеять, иначе пропущенные кандидаты останутся невидимыми.

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

На наших данных отдельные проверки выглядели обнадёживающе, но первое правило, которое мы собрали из этих ответов, дало всего 66% совпадений с эталоном. Само разбиение на вопросы не гарантирует хороший отбор. Итоговое правило тоже нужно проверить.

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

Вот условный пример с персональным письмом. В источнике написано: «Мы открыли три вакансии инженеров в Германии». Генератор письма превратил это в «Вижу, вы наняли трёх инженеров, чтобы выйти на немецкий рынок».

Здесь несколько разных утверждений. Открытые вакансии не подтверждают, что людей уже наняли. Германия есть в источнике, а цель выхода на новый рынок автор письма додумал. Я бы передал каждое утверждение отдельно, вместе с исходной цитатой и вариантами «подтверждается», «противоречит», «данных мало». Число вакансий и дату проверил бы кодом. Такой тест покажет, пропускает ли модель правдоподобные выдумки.

Начать можно с 200 черновиков, куда заранее подмешаны старые факты, перепутанные компании и преувеличения. Такой тест мы пока не проводили. Критические неподтверждённые утверждения должны останавливать письмо. Даже если в этих 200 примерах ошибок не окажется, будущую безошибочность это не докажет.

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

Например, условный ответ «Сейчас неактуально, поговорите с коллегой, а меня уберите из рассылки» нельзя свести к метке «позитив». В нём есть отказ по срокам, упоминание другого человека и прямое требование прекратить письма. Последнее должно сработать независимо от остальных ответов модели. Данные о коллеге можно передать на проверку, но сам текст ещё не даёт права автоматически включить его в рассылку.

Это схемы, которые я бы тестировал. Наш эксперимент затрагивает только отбор контактов и не проверяет весь процесс. Проверке персонализации и разбору ответов нужны собственные размеченные примеры.

Схема отбора для проверки: исходные данные, отдельные вопросы модели, правила в коде, затем решение или разбор человеком.

В описании вакансии может встретиться фраза «Связать нашу CRM с инструментами для кампаний». Для задачи отбора сигналов это полезнее, чем просто упоминание Salesforce или HubSpot в требованиях.

Я бы дал Jev текст вакансии и спросил, поручают ли человеку интеграцию систем, нужно ли построить новый процесс или поддерживать существующий. Затем предложил бы выбрать из готового списка услуг, включая «ничего не подходит». В этом примере можно рассматривать аудит интеграций. Продажу услуги по написанию контента такая фраза не обосновывает.

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

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

Допустим, мы знаем компанию и должность, но не понимаем, отвечает ли человек за нужную функцию. Покупка ещё одного адреса почты этот пробел не закроет. Jev можно дать известные поля и разрешённые источники, чтобы выбрать, где искать описание обязанностей. Ответ «остановиться» здесь такой же допустимый, как выбор следующего источника.

Лимит расходов и повторных попыток задаётся вне модели. Она не должна придумывать, с какой вероятностью конкретный сервис найдёт ответ. Если новая покупка уже не может изменить решение по нашим правилам, поиск пора остановить. Я бы сравнил такую схему с привычной последовательностью сервисов на 300 неполных записях, учитывая и неудачные запросы. Это план проверки, а не обещание экономии.

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

С ролями людей та же осторожность. Слово Director не говорит, чем именно человек руководит. Для решения нужно описание ответственности, а совпадение домена компании не доказывает, что два профиля принадлежат одному человеку. В тест на сопоставление я бы специально включил однофамильцев и ребрендинги.

В каталоге партнёров можно решать более простую задачу: отличать консультанта, интегратора, конкурента и сам каталог. Модель должна выбрать одну из реально найденных ссылок и указать фрагмент текста, на котором основан выбор. Программа сохранит URL и уберёт дубли доменов. Если описания мало, карточка остаётся кандидатом для проверки на сайте самой компании.

Эти шесть демо мы не воспроизводили. Цифры скорости и стоимости приводят сами авторы; применимость к продажам ещё предстоит проверить.

В Worth Replying от AIsa ищут разговоры в X о проблемах, которые решает продукт компании.

Мне здесь нужна очередь обсуждений для просмотра, с цитатой и объяснением, почему разговор попал в список. Jev мог бы отличать прямое описание проблемы от случайного упоминания. Поиск, свежесть данных и удаление дублей остаются за кодом. Подходящая тема ещё не означает намерение купить или согласие на личное сообщение. При проверке я бы считал и полезные найденные разговоры, и те, которые система пропустила.

Maxfusion раскладывает объявления по этапу пути клиента и стилю рекламы. Из этого можно собрать библиотеку с объяснениями, на чём основана каждая категория.

Но Jev работает с текстом. Для видео и картинок сначала понадобится расшифровка или описание из другого инструмента. Повторы и количество объявлений по категориям посчитает код. Сам факт, что конкурент крутит рекламу, ничего не доказывает про её окупаемость. Гипотезу о сильном объявлении всё равно нужно проверять.

В JevForm Тамира Спиритта следующий вопрос зависит от предыдущих ответов. Я бы давал модели утверждённый набор вопросов и список сведений, которых ещё не хватает.

Обязательные пояснения, согласия, предел длины формы и допустимые переходы лучше задать в коде. Причём сравнивать стоит с обычной формой с ветвлениями. Нас интересует, удалось ли собрать нужные данные без повторов. Более короткая анкета сама по себе ещё не лучше.

Демо Зейна Ходы выбирает слайды по речи выступающего. В продажах так можно подсказывать менеджеру материал под конкретное возражение или вопрос клиента.

Я бы показывал подсказку только менеджеру, пока он сам не решит открыть слайд. Для этого нужны разрешённые к использованию фрагменты расшифровки и согласованные материалы. Распознавание речи, права доступа и пауза между переключениями остаются вне Jev. Сначала можно прогнать записи звонков и посчитать неуместные подсказки и помехи разговору. Само переключение слайда не доказывает, что инструмент помог продаже.

Автор этого демо анализирует предыдущие посты и оценивает новые. К его формулировке «измеритель вирусности» я бы относился осторожно. Публикация автора не доказывает, что инструмент предсказывает охваты.

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

У Gojiberry есть особенно близкий к продажам пример. Авторы пишут, что дали Jev 700 лидов и персональные сообщения. За 40 секунд и $0,09 система оценила ожидаемый результат каждого сообщения, присвоила балл уверенности и нашла несоответствия между человеком и текстом. Это их цифры; мы такой прогон не повторяли. По этому демо нельзя узнать, как прошла реальная кампания.

Я бы начал с более узкой задачи. Дать факты о человеке и несколько согласованных сообщений, причём разрешить ответ «ничего не подходит». Пусть Jev найдёт неподтверждённое предположение о должности или выберет предложение под потребность, для которой есть основания. Код должен проверять, разрешена ли отправка, исключён ли человек из рассылки и согласовано ли сообщение. Соответствие письма человеку и достоверность каждого факта в нём стоит проверять отдельно.

Для теста подойдут размеченные пары «человек и сообщение» с намеренно перепутанными вариантами. Балл уверенности модели не равен вероятности ответа. Последнюю надо сверять с результатами кампаний на отдельной выборке и сравнивать с заранее выбранным способом оценки.

Чтобы проверить эту схему, я бы взял два заранее подготовленных предложения и условного человека, который отвечает за маркетинг, но не за IT-инфраструктуру. Письмо про миграцию серверов должно получить отметку о несоответствии роли. Предложение про маркетинг тоже нельзя выбирать только из-за названия должности: нужны сведения о задаче. Если таких сведений нет, правильным результатом теста может быть «данных мало». Это пример для проверки схемы, а не наблюдавшийся ответ Jev в демо Gojiberry.

Из 13 сценариев выше я бы выбрал для начала тот, где уже есть исходные данные и понятные критерии. Проверка одного факта в письме потребует другой разметки, чем поиск подходящих компаний. Результаты нашего теста на 83 контактах нельзя перенести на все остальные задачи.

Для пилота я бы взял 200 новых примеров и заранее отложил часть, которую не буду смотреть при настройке. В рабочей части можно менять вопросы и пороги. Перед проверкой на отложенных примерах всё это надо зафиксировать. Иначе я снова получу хорошее объяснение знакомой выборки вместо проверки нового процесса.

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

Первое время модель можно запустить параллельно текущему процессу. Её ответы записываются, но ещё не управляют отправкой писем или отказом от контакта. На проверку попадают и предложенные отказы: иначе самые неприятные пропуски никто не увидит.

При сравнении с текущим способом работы считать нужно стоимость принятого результата с учётом сбора данных, неудачных попыток и работы человека.

Иллюстративный расчёт для 10 000 компаний из полной статьи. Браузер, прокси и ручная проверка могут обойтись дороже модели. Это расчёт на допущениях, не фактический счёт.

В этом расчёте один вызов Jev на компанию при 4 000 входных токенов даёт $1,68 на 10 000 компаний. Рядом $3,33 за время браузера, $100 за резидентские прокси и ещё $100 за четыре условных часа ручной проверки по $25. После округления строк получается $205,01. Это иллюстрация по тарифам, которые мы проверили 19 сентября, а не счёт за выполненный проект.

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

Напишите, какое решение в вашей работе с клиентами съедает больше всего времени на проверку и по каким данным вы определяете, что оно правильное.