Хочете будувати кар’єру в Data Science та AI? Vodafone Big Data Lab відкриває новий набір —>
Наталя ХандусенкоШІ
1 жовтня 2026, 09:00
2026-10-01
«Корисний класифікатор ще не означає революції в ШІ». Як українські айтівці оцінюють нашумілу модель Jev — кейси застосування у реальних продуктах
У вересні в IT-світ увірвалася нова ШІ-модель Jev, яка замість того, щоб генерувати текст, ухвалює рішення, а ще вона надзвичайно дешева й неймовірно швидка. Jev є творінням стартапу ексдослідника OpenAI Діого Алмейди, яке вже зчинило справжній ажіотаж: у соцмережі X відеопрезентація набрала 40 млн переглядів, на сервері компанії в Discord налічується понад 100 000 учасників, а через зацікавленість інвесторів оцінка стартапу сягнула $10 млрд. Крім того, модель викликала значний резонанс завдяки тому, що практично одразу після релізу її інтегрували Vercel, Cloudflare та LangChain.
Проте після спілкування з українськими IT-фахівцями, які випробували цю модель на практиці, виявили, що далеко не всі поділяють цей хайп, а дехто навіть повністю відмовився від інтеграції.
Тож розповідаємо про чотири кейси використання Jev, а також висновки та поради від українських засновників ШІ-стартапів і розробників.
У вересні в IT-світ увірвалася нова ШІ-модель Jev, яка замість того, щоб генерувати текст, ухвалює рішення, а ще вона надзвичайно дешева й неймовірно швидка. Jev є творінням стартапу ексдослідника OpenAI Діого Алмейди, яке вже зчинило справжній ажіотаж: у соцмережі X відеопрезентація набрала 40 млн переглядів, на сервері компанії в Discord налічується понад 100 000 учасників, а через зацікавленість інвесторів оцінка стартапу сягнула $10 млрд. Крім того, модель викликала значний резонанс завдяки тому, що практично одразу після релізу її інтегрували Vercel, Cloudflare та LangChain.
Проте після спілкування з українськими IT-фахівцями, які випробували цю модель на практиці, виявили, що далеко не всі поділяють цей хайп, а дехто навіть повністю відмовився від інтеграції.
Тож розповідаємо про чотири кейси використання Jev, а також висновки та поради від українських засновників ШІ-стартапів і розробників.
Зміст
Довідка: Jev — нова модель «швидкого мислення», яка змінює уявлення про ШІ
Jev випустив 15 вересня 2026 року стартап TypeSafe AI, заснований колишнім дослідником OpenAI та співавтором InstructGPT Діогу Алмейдою. Назву обрано на честь економіста Вільяма Стенлі Джевонса та його парадоксу про вибухове зростання споживання ресурсу зі зниженням його ціни — і попит після релізу справді виявився настільки високим, що спричинив тимчасовий оверлоад API.
На відміну від звичайних текстових LLM (GPT, Claude), Jev — це нетекстова модель «Системи 1», розроблена для швидких структурованих рішень замість генерації тексту чи діалогу. Вона оцінює стан систем і видає типізовані відповіді для бізнес-логіки та автономних агентів, а її високу точність забезпечує метод навчання RLCD (Reinforcement Learning for Calibrated Decisions).
Працює Jev за принципом оцінки заданого контексту через три типи запитань: Choice (вибір із переліку), Score (рівневе оцінювання) та Noul (відповідь «так/ні»). Усі запитання в межах одного запиту оцінюються паралельно, що майже не впливає на затримку та мінімізує витрати.
Основні переваги Jev:
Спеціалізоване рішення для вузьких завдань: двигун створений не для вільного креативу, а для точних висновків (класифікація електронної пошти, маршрутизація запитів, скоринг).
Jev демонструє до 200x вищу швидкість інференсу та до 400x нижчу вартість у порівнянні з традиційними LLM на аналогічних завданнях класифікації. Ціна становить близько 4 центів за мільйон вхідних токенів, а плата за вихідні токени взагалі відсутня.
Точна калібрація: завдяки RLCD видає математично обґрунтовані ймовірності для надійної автоматизації.
В TypeSafe AI впевнені: зробивши швидкі AI-рішення декількома порядками дешевшими та швидшими, вони відкриють шлях до повсюдної інтеграції ШІ в найменші елементи програмного забезпечення.
4 кейси застосування Jev від українських айтівців
1. Інтеграція Jev у пайплайн ШІ-стартапу
Інтеграція нової моделі System One Jev у пайплайн ШІ-стартапу Omev AI дозволила розв’язати проблему частих повторних генерацій через дрібні дефекти, які раніше призводили до порушення 90-секундного SLA та використання дорогих резервних моделей. Jev встановили перед етапом важкої генерації для миттєвої перевірки «скелета» результату та класифікації помилок, сформувавши трирівневу систему: детерміновані правила для механічних огріхів, Jev для відсіювання хибних тривог і точковий редактор для виправлення лише пошкоджених фрагментів.
Завдяки новому підходу 100% із 723 реальних запитів вклалися в SLA, використання резервної моделі скоротилося на 70%, а медіанний час відновлення впав із 40–80 до 12 секунд. У результаті витрати на генерацію знизилися на двозначний відсоток без втрати якості, адже відловлювати помилки на рівні швидких типізованих вердиктів значно дешевше, ніж змушувати генеративну модель марнувати токени на самоперевірку.
Наша команда не поділяє хайпу навколо Jev: корисний класифікатор ще не означає революцію в ШІ.
За словами співзасновника Omev AI Дмитра Радіонова, команда стартапу використовує Jev як практичний робочий інструмент для автоматизації базового відбору інформації — відсіювання нерелевантних сайтів, пошуку конкурентів та оцінки коментарів у соцмережах. Хоча подібні класифікатори існували й раніше (як-от Google Cloud Natural Language), Jev вирізняється високою швидкістю та гнучкістю. Водночас у компанії чітко розмежовують простий первинний відбір від повноцінного осмислення даних, зазначаючи, що складні випадки поки що залишаються слабким місцем моделі, а її показник упевненості за багатьма питаннями досі залишається досить приблизним.
Великих перспектив Jev як окремого продукту ми поки не бачимо.
У стартапі планують використовувати Jev як гнучкий змінний компонент у своєму конвеєрі, поєднуючи його з моделью Mercury 2.5: Jev відповідатиме за швидкі вузькі оцінки та первинний відбір, а Mercury — за глибшу перевірку складних випадків і надання пояснень. Команда не розглядає Jev як універсального аналітика чи самостійний окремий продукт, проте бачить у ньому чудовий дешевий інструмент для експериментів та ефективну деталь у складі більшої, комплексної системи.
Наш досвід показав: швидко відфільтроване сміття не стає дослідженням чи цінним набором даних. У сучасному світі ШІ саме якісні й підготовлені дані та системи їх обробки — золото, а не сама модель. Якщо система шукає не тих конкурентів або ставить неправильні запитання, швидкість моделі її не врятує.Отримання та підготовка даних поки що коштують значно дорожче, ніж будь-яка модель, тому вигуки про те, що Jev обвалив ціни на SEO-роботи, дуже передчасні.OmevAI цікавить не перемога Jev у презентації, а якість кінцевого результату для клієнта. Ми постійно шукаємо й порівнюємо нові моделі, і вже з’являються цікаві варіації на тему Jev, тож подивимося.
2. Тестування Jev на реальній задачі ШІ-продукту
Команда стартапу OrchestrAI протестувала Jev у своїй e-commerce платформі Adminly, яка перетворює неструктуроване листування клієнтів (зі сленгом, помилками та кількома намірами) на підготовлені бізнес-дії. Замість громіздких правил із regex та винятками, Jev залучили для швидкої класифікації повідомлень на типи (order / support / mixed), визначення намірів покупців і оцінки ризиків. Модель показала себе як потужний шар первинного розуміння тексту, здатний суттєво замінити частину вартісних викликів традиційних LLM та спростити маршрутизацію запитів.
Зараз ми розглядаємо Jev насамперед як додатковий шар розуміння тексту: для визначення намірів клієнта, маршрутизації повідомлень між замовленнями, підтримкою та змішаними сценаріями, пошуку релевантного контексту й оцінки того, чи потрібна дорожча LLM-обробка.
Перший етап — shadow mode: Jev класифікує повідомлення паралельно з поточною логікою, але його відповідь ще не впливає на дії системи. Ми порівнюємо результати на власному корпусі для оцінювання (evaluation corpus), аналізуємо помилки й визначаємо робочі пороги впевненості (confidence thresholds).
Якщо результати будуть стабільними, поступово застосовуватимемо модель для безпечних класів рішень. Незворотні бізнес-дії — наприклад, створення замовлення, зміна статусу оплати або надсилання важливого повідомлення — все одно проходитимуть через детерміновані перевірки та, за потреби, підтвердження людиною.
У компанії розглядають модель як імовірнісний інтерпретатор усередині детермінованого середовища виконання (runtime), де Jev здійснює класифікацію, система перевіряє результат, бізнес-правила накладають обмеження, а людина підтверджує ризиковані дії. Саме така конструкція дозволяє отримати максимальну користь від моделі, не передаючи їй контроль над бізнес-істиною.
Основний архітектурний висновок для нас полягає в тому, що Jev не повинен керувати бізнес-процесом самостійно.
Також зазначають, що наразі Jev перебуває на стадії тестування та проєктування інтеграції в Adminly. Оскільки це ще не довгострокове впровадження в продакшн, команда поки не оголошує підсумкових production-метрик, а їхній поточний досвід стосується первинних випробувань, практичного проєктування та визначення безпечних меж застосування моделі.
3. Jev для обробки звернень у службі підтримки та відмова від інтеграції
Backend Developer Валентин Ніколаєв працював над завданням із визначення пріоритету звернень за текстом тікета, щоб допомогти службі підтримки першочергово реагувати на найважливіші запити. Він запропонував ідею динамічного перерахунку пріоритету після кожного нового повідомлення в чаті, оскільки розмова доповнюється, і початкова оцінка може втрачати актуальність. На його думку, якщо така повторна оцінка коштує дешево та допомагає команді швидше приймати рішення, вона має високу практичну цінність.
Водночас під час внутрішніх перевірок розробники виявили суттєве обмеження, яке безпосередньо вплинуло на рішення щодо інтеграції. Виявилося, що рівень надійності виявлення персональних даних та чутливої інформації про здоров’я в тексті звернень не відповідав високим вимогам компанії. Оскільки користувачі можуть самостійно вказувати у довільному тексті свої імена, електронні адреси або медичні подробиці, ключовим питанням оцінки цієї моделі стала можливість безпечної передачі такого тексту зовнішньому провайдеру.
Причинами відмови від інтеграції стали недостатня для нас надійність виявлення чутливої інформації та невирішені договірні питання щодо її обробки. Після юридичного аналізу публічних умов TypeSafe залишилися застереження, які потрібно було з’ясувати перед подальшою інтеграцією.
Для завдань, у яких до моделі не потрапляють персональні дані, відомості про здоров’я чи інша чутлива інформація, Jev можна використовувати — за умови перевірки його придатності до конкретного кейсу.
Я б повертався до нашого сценарію тоді, коли буде чітко зрозуміло, які саме дані передаються провайдеру та на яких умовах вони обробляються. Також потрібно перевірити, чи вдасться сформувати запит із достатнім для оцінки пріоритету контекстом і водночас дотриматися наших вимог до безпеки даних. Якщо вилучити потрібні подробиці, сама оцінка може стати менш корисною — це теж потребує додаткової перевірки.
4. Експерименти з керуванням браузером та перевірка заявлених можливостей моделі
Засновник компанії Dev AI Consulting, Ph.D В’ячеслав Колдовський поділився власним досвідом експериментів із Jev, який зосереджувався на керуванні браузером та перевірці заявлених можливостей моделі. Зокрема, він протестував відкритий проєкт jev-ultrafast від Browser Use. У цій архітектурі Jev отримує структурований опис елементів вебсторінки та вирішує, яку саме дію виконати й з яким об'єктом взаємодіяти, тоді як генерацію тексту для введення здійснює окрема мовна модель.
В’ячеслав відзначив цей приклад як вдалу демонстрацію ефективного підходу в розробці: замість спроб покласти всі завдання на одну громіздку модель, функціонал ділять між спеціалізованими інструментами. На його думку, така концепція перегукується з будовою людського мозку, де за різні типи задач відповідають окремі спеціалізовані зони.
Головний висновок — не кожному завданню потрібна генеративна модель. Часто програмі не потрібен текст із поясненнями: їй необхідно перевірити умову, обрати один із доступних варіантів або оцінити щось за заданою шкалою. Саме на таких рішеннях спеціалізується Jev: замість довільного тексту він повертає структуровані значення та ймовірнісні оцінки.
Для мене головна цінність — у можливості практично використати таку спеціалізацію. Зокрема, розробники пропонують застосовувати Jev для підбору моделей, відбору потрібного контексту та перевірок у процесах роботи AI-агентів. Це саме ті допоміжні операції, які варто окремо розглядати під час оптимізації системи.
Швидкість і вартість можуть змінювати не лише економіку наявного рішення, а й те, які продукти взагалі має сенс створювати. Якщо процес потребує великої кількості послідовних перевірок і виборів, затримка та вартість кожного кроку накопичуються. Якщо ці кроки вдається виконувати швидше й дешевше без неприйнятного погіршення якості, можна інакше проєктувати весь процес.
При цьому прискорення окремого виклику не означає такого самого прискорення всієї системи. Тому цифри про сотні чи тисячі разів я б не переносив автоматично на будь-який продукт — кінцевий ефект потрібно вимірювати на конкретному робочому процесі.
В’ячеслав Колдовський планує використовувати Jev для створення «фабрик розробки програмного забезпечення» (software factories) — систем із різним рівнем автономності ШІ та залучення людей. Для нього ця модель цікава як спосіб зробити роботу таких систем швидшою та дешевшою.
Для мене Jev — не історія про «кінець LLM», а хороший приклад того, як перестати використовувати одну модель для всього.
На його думку, складному ШІ не обов’язково доручати абсолютно все. Замість того щоб щоразу викликати дорогу мовну модель для простих кроків (наприклад, обрати потрібного агента, знайти доречний контекст або перевірити код за суворими критеріями), краще залучати дешевші й спеціалізовані інструменти на кшталт Jev. Коли таких дрібних операцій тисячі, економія на кожній із них суттєво зменшує загальну вартість і прискорює весь процес.
Водночас В’ячеслав підкреслює, що це поки очікувана концепція, а не фінальні цифри з продакшну. Головним критерієм оцінки для нього буде не просто низька ціна одного виклику API, а підсумковий час і вартість отримання якісного результату з урахуванням можливих помилок та перевірок.
Де модель виграє, а де потребує страховки
Досвід українських ІТ-спеціалістів, які випробували Jev у реальних продуктах, показує: головна сила моделі полягає у швидкості та структурованості, проте вона вимагає чіткого розуміння меж своїх можливостей.
Для проєктів, де потрібно швидко перевірити гіпотези або відсіяти інформаційний шум перед передачею даних у дорожчі моделі, Jev стає чудовим інструментом розгортання. Він дозволяє уникнути складного парсингу й одразу працювати зі структурованими оцінками.
«Найбільша перевага — можна швидко почати без навчання власної моделі й отримувати структуровані оцінки замість тексту, який ще треба розбирати. Це зручно для перевірки гіпотез, скорочення вхідного контексту для великих LLM та зменшення інформаційного шуму, який часто і призводить до галюцинування в сильних моделях, — зазначає Дмитро Радіонов. — Водночас слабкість у тому, що складне питання все одно потрібно правильно розкласти на прості. Фактично в багатьох процесах доводиться перетворювати одне завдання на 4- чи 5-ступеневий конвеєр за допомогою Jev. Модель не зробить цю інтелектуальну роботу за вас».
Дмитро підкреслює, що такий інструмент — це передусім місток для швидкого запуску, а не універсальне рішення на роки вперед: «Для стабільних завдань із великими обсягами та власними даними ми бачимо більше сенсу в донавчанні своєї моделі. Саме там шукатимемо кращу точність і нижчу собівартість. Зручність на старті не дорівнює перевазі назавжди».
Інша сторона застосування Jev — заміщення громіздких систем із регулярними виразами (regex) та винятками. Модель дає можливість обробляти природну мову без створення сотень ручних правил, проте вимагає обережності в неоднозначних сценаріях.
«На мій погляд, головна перевага Jev — поєднання семантичного розуміння тексту зі структурованим результатом, який програмний код може використати без додаткового парсингу, — пояснює Денис Кірєв. — Замість великої кількості ключових слів, регулярних виразів і винятків ми можемо описати класи та критерії й отримати конкретний вибір, оцінку або ймовірність. Це особливо цікаво для систем, які обробляють багато варіантів природної мови».
Проте Денис застерігає від надмірної довіри до структурованого виводу: «Водночас структурно правильна відповідь не обов’язково є семантично правильною. Jev не поверне клас поза визначеною схемою, але може обрати неправильний дозволений варіант. Ризик зростає у неоднозначних повідомленнях, змішаних намірах, сленгу, довгому контексті або під час роботи з мовами та формулюваннями, недостатньо представленими у тестах. Також Jev не замінює повноцінну LLM там, де потрібно створювати текст, пояснювати рішення або виконувати складне багатоетапне міркування. Це спеціалізований інструмент для швидких структурованих рішень, а не універсальна модель».
Поради айтівців на основі власного досвіду
Дмитро Радіонов наголошує на важливості чіткого визначення меж відповідальності моделі. На його думку, Jev варто застосовувати виключно там, де потрібне ймовірнісне судження: для класифікації, маршрутизації, оцінки ризику або вибору наступного сценарію.
Дмитро підкреслює, що модель не повинна бути джерелом бізнес-істини. Ціна, залишки товарів, статус оплати, доставка, арифметика та ідентифікація конкретного клієнта чи замовлення мають визначатися виключно програмою та даними з бази даних.
Спираючись на власний досвід, він рекомендує:
починати з одного вузького й добре сформульованого сценарію;
створити власний набір реальних деперсоналізованих (або знеособлених) прикладів;
порівняти LLM із поточною логікою або LLM-baseline;
спочатку запускати модель у shadow mode;
окремо вимірювати помилки для різних мов і типів повідомлень;
не сприймати confidence як гарантію правильності;
передбачити fallback на випадок низької впевненості, таймауту або недоступності API;
не дозволяти відповіді моделі обходити бізнес-правила та human approval.
Backend Developer Валентин Ніколаєв радить насамперед детально проаналізувати, які саме дані продукт надсилатиме через API. На його думку, особливу увагу слід приділити полям для довільного тексту від користувачів, оскільки їхній фактичний вміст часто виходить за межі початкового призначення. Крім того, він наголошує на необхідності завчасно розібрати юридичні умови провайдера разом із юристами — ще до передачі реальних звернень.
Що стосується перевірки якості, Валентин рекомендує підготувати тестові приклади на основі власних завдань, використання яких є правомірним. Важливо заздалегідь визначити найбільш критичні для бізнесу помилки — наприклад, коли терміновий запит до служби підтримки помилково потрапляє в кінець черги. Також варто окремо протестувати неоднозначні випадки та чітко погодити критерії, за яких рішення має переглядати людина.
Наостанок розробник радить розраховувати вартість та затримку на всьому очікуваному обсязі запитів, обов’язково враховуючи сумарне навантаження, якщо планується повторна оцінка після кожного нового повідомлення в чаті.
В’ячеслав Колдовський підкреслює, що ймовірнісна оцінка моделі є корисним сигналом, але аж ніяк не гарантією правильності. На його думку, такий показник варто використовувати для визначення меж автоматизації: коли дія може виконуватися автономно, а коли її потрібно передавати на додаткову перевірку людині чи іншій моделі. Порогові значення впевненості необхідно розраховувати на власних даних, чітко зважуючи можливу ціну помилки.
У контексті розбудови «фабрик розробки» В’ячеслав наголошує, що оцінка моделі ніколи не повинна підміняти повноцінне тестування та незалежну перевірку результатів. Головна мета полягає не в автоматизації максимум кроків будь-якою ціною, а в побудові процесу, який гарантує необхідну якість за менших часових та фінансових витрат.
Крім того, експерт зазначає, що замість хмарного Jev можна розглянути й альтернативні рішення. Завдяки наявності бенчмарків для порівняння моделей варто звернути увагу на варіанти з локальним хостингом. Це дозволяє використовувати подібні інструменти фактично безплатно, а головне — забезпечує повну приватність без передачі чутливих даних третім сторонам.
«Чи є у мене талант, якщо комп’ютер може імітувати мене?». Штучний інтелект пише книги авторам Amazon Kindle. The Verge поспілкувався з авторами та виявив багато цікавого
Письменники-романісти використовують штучний інтелект для створення своїх творів. Видання про технології The Verge поспілкувалося з письменницею Дженніфер Лепп, яка випускає нову книгу кожні дев’ять тижнів, й дізналося про те, як працює штучний інтелект для написання романів. Наводимо адаптований переклад статті.
Хочете повідомити важливу новину? Пишіть у Telegram-бот
Головні події та корисні посилання в нашому Telegram-каналі
