OpenAI представила Decisions API на DevDay у limited preview, а з 6 жовтня розкотила його в public beta. Ідея до болю знайома, якщо ти читав наш розбір Jev: даєш контекст і скінченний набір наперед визначених відповідей, отримуєш рішення – для класифікації, роутингу або вибору наступної дії агента. Без генерації тексту. Тобто «AI-powered if/else» за три тижні перетворився з жарту про один стартап на категорію, в якій тепер грає і OpenAI. Розбираємось, що це означає і як між ними обирати, не вигадуючи порівнянь, яких поки не існує.
Що саме анонсували
За описом OpenAI, Decisions API «фокусує інтелект Luna на конкретному наборі заданих користувачем питань зі скінченними наперед визначеними відповідями». Контекст передається текстом або зображеннями; на виході – відповідь зі списку, яку твій код використовує напряму: класифікувати контент, змаршрутизувати запит, обрати наступну дію агента.
Головна цифра зі слайда DevDay: близько 150 мс проти 1.6 с у стандартного виклику GPT-6 Luna – приблизно десятикратне прискорення. Важливе уточнення, яке я повторюю в кожній такій статті: це vendor-заявка з презентації, а не незалежний бенчмарк. Незалежних замірів на момент написання немає.
Чому це логічний рух, а не копіювання заради копіювання
LLM чудово генерує текст. Але якщо чесно подивитись на production-систему, велика частина AI-викликів у ній не потребує тексту взагалі:
billing | technical | sales– роутинг звернень;allow | review | block– модерація і гейтинг;agent_a | agent_b | ask_user– вибір наступного кроку в агентському циклі.
У таких задачах natural language generation – зайва surface area: повільніша, дорожча, з ризиком «майже валідного» виводу, який ще треба парсити й валідувати. Про це ж, по суті, була вся друга половина статті про Jev: типізоване рішення з обмеженого набору – інший клас задач, ніж вільний текст.
Тому поява другого великого гравця – найкраща новина для самої ідеї. Категорії з одним вендором не існує; категорія з TypeSafe і OpenAI – вже ринок.
Jev vs Decisions API: чесне порівняння (поки що – категорійне)
Спокуса написати «хто переміг» велика, але нечесна: Decisions API щойно вийшов у beta, його характеристики й ціни можуть змінитися, а публічних незалежних порівнянь немає. Що можна чесно порівняти вже зараз – підходи:
| Вимір | Jev (TypeSafe) | Decisions API (OpenAI) |
|---|---|---|
| Архітектура | Окрема «System One» модель, неавторегресивна, тренована під калібровані ймовірності | Сфокусований режим поверх інтелекту Luna |
| Вихід | Типізовані Choice/Score/Noul з confidence і розподілом | Відповідь зі скінченного набору |
| Контекст | Текст/JSON | Текст і зображення |
| Екосистема | Власний SDK + інтеграції (Vercel AI SDK, LangChain) | Рідна інтеграція в OpenAI-стек |
| Статус | GA, публічний прайс | Public beta з 6 жовтня |
Зауваж, чого в таблиці немає: точності, калібровки, реальної latency під навантаженням і вартості на твоїх обсягах. Бо цих даних поки не існує ніде, крім вендорських слайдів.
Як обирати, коли обидва доступні
Так само, як ми радили в статті про evals: власний набір із 200–500 розмічених прикладів із твого продукту і чотири виміри – accuracy, калібровка (якщо вендор віддає ймовірності – перевір, чи «0.9» означає ~90% влучань), latency p95 і повна вартість на місячному обсязі. Плюс два нечислові фактори: ergonomics SDK у твоєму стеку і vendor lock-in – якщо ти вже глибоко в екосистемі OpenAI, інтеграційна ціна Decisions API нижча; якщо цінуєш незалежність шару рішень – окремий вендор має свій сенс.
Трирівневий стек, до якого все йде
Найкорисніша рамка з цієї новини – не «яку модель купити», а як виглядатиме здорова архітектура рішень:
- Deterministic rules – там, де ознаки формальні. Безкоштовно, пояснювано, миттєво.
- Decision model – там, де рішення залежить від сенсу неструктурованого вводу, але простір відповідей скінченний.
- Reasoning/generative model – там, де потрібні міркування, план або текст.
Просити frontier-LLM вирішувати кожен boolean у системі – це рівень зрілості «у нас є молоток». Трирівневий стек – рівень «ми знаємо вартість кожного удару». Ширший контекст про те, де AI в роботі розробника доречний взагалі, – у базовій статті про AI-інструменти.
Три передчасні рішення
- Мігрувати на beta-API критичний шлях. Public beta означає: семантика й ціни можуть змінитись. Пілот – так, критичний роутинг платежів – зарано.
- Вірити слайду замість власного eval. «10x швидше» виміряно вендором на вендорській задачі. Твоя задача – інша.
- Викидати правила. Decision model не замінює детерміновану бізнес-логіку – вона замінює LLM-виклики там, де тексту не треба.
- Ігнорувати калібровку. Якщо API не віддає впевненість або вона некалібрована – у тебе немає сигналу «віддати людині», і це архітектурна діра.
Порахуй свої приховані класифікатори
Відкрий свій код і знайди всі місця, де ти викликаєш LLM, а потім парсиш із відповіді одне слово чи категорію. Порахуй їх. Кожне з них – кандидат на decision model, і тепер у тебе два вендори на вибір і один чесний спосіб обрати: виміряти самому.