OpenAI пусна нови решения API в публична бета версия, предоставяйки на разработчиците отделна крайна точка за въведени решения, вместо за генериране на пълен текст. Бета версията пристигна на 6 октомври с поддръжка за GPT-6 Luna и е позиционирана за работни натоварвания, където изходното пространство е известно предварително: предикати, избори и резултати.

Звучи ограничено, но има значение. Голям дял от производствения AI трафик не е писане с отворен край. Това е класифициране, маршрутизиране, проверки на правилата, свързани с модерирането, откриване на намерения, избор на инструменти и логика на защитната парапет. Тези обаждания често изискват от модела да произведе малък структуриран отговор, след което принуждават приложението да го анализира или валидира. OpenAI вече третира този шаблон като своя собствена API повърхност.

Какво се промени

The Decisions API превръща текста и изображенията във въведени отговори. OpenAI казва, че може да бъде до 10 пъти по-бързо от отговорите API за поддържани работни натоварвания за вземане на решения. В публичната бета версия разработчиците могат да дефинират изходните резултати за решения като предикати, избори или резултати, вместо да подканват модел да генерира произволен текст и след това да ограничават резултата след факта.

Моделът на ценообразуване също е различен. OpenAI изброява GPT-6 използването на Luna за Решенията API на $0,10 за 1 милион входни токени, без такси за четене в кеша, запис в кеша или изходни токени. Това улеснява моделирането на икономиката на единицата за слоеве на решения с голям обем, тъй като сметката е обвързана само с входящия обем.

Изданието не замества чат, отговори или ориентирани към агенти API. Той създава по-специализиран път за случаите, когато приложението се нуждае от надежден въведен отговор, а не от параграф. За екипи, които вече разделят натоварванията между размери на модели, нива на латентност и маршрути на доставчици, това добавя друга категория към архитектурата: извиквания за вземане на решения.

Защо разработчиците трябва да ги е грижа

Много AI приложения вече използват извиквания на малки модели като вътрешна контролна логика. Асистент по поддръжката може да класифицира билет, преди да избере работен процес. Кодиращият агент може да реши кой инструмент да извика следващия. Система за обработка на документи може да оцени дали даден запис отговаря на прага на политиката. Продукт, ориентиран към клиента, може да насочва заявки между по-евтини и по-мощни модели.

Досега тези модели често се прилагаха като нормални повиквания за генериране със стриктни подкани, JSON схеми, повторни опити и слоеве за валидиране. Този подход работи, но носи допълнителни разходи. Разработчиците плащат за изходни токени, управляват грешки при анализиране и често приемат повече забавяне, отколкото самото решение трябва да изисква.

Въведена крайна точка за решение променя този компромис. Ако изходът може да бъде представен като булево, ограничен избор или резултат, екипите могат да преместят повикването извън общ генеративен път. Това може да намали забавянето и да опрости кода на приложението. Може също така да намали двусмислието в регистрационните файлове и анализите, тъй като целта на повикването е ясна.

Най-непосредствените случаи на употреба вероятно ще бъдат високочестотни вътрешни проверки: маршрутизиране на заявки, пропуски за допустимост на съдържанието, правила за ескалация, стъпки за избор на инструменти и политики за избор на модел. На тези места малките подобрения в латентността и разходите могат да имат значение, тъй като извикването на решение може да се случи преди всяка заявка за по-голям модел.

Последствия за разходите и управлението

Цената само за въвеждане е търговският детайл, който трябва да наблюдавате. За екипи, които изпълняват големи обеми от предпазни средства за агенти или решения за маршрутизиране, елиминирането на таксуването с изходен токен променя сравнението с малки модели за чат, машини за правила и крайни точки на класификатор, специфичен за доставчика. Освен това прави прогнозите за разходите по-малко чувствителни към многословност на изхода или повторни опити за схема.

Това не означава, че всеки класификатор трябва да премине към Решения API. Детерминистичните правила все още ще бъдат по-евтини и по-лесни за одит, когато логиката е проста. Съществуващите филтри за вграждане, търсене или база данни може да са по-подходящи за някои проблеми с маршрутизирането. Но когато моделът вече се използва за интерпретиране на разхвърлян текст или изображения в ограничен отговор, новият API дава на екипите по-чиста опция за доставка и инженеринг.

За екипите на платформата по-големият проблем е таксономията. Ако всички обаждания на AI се третират като завършвания на чат или общи отговори във вътрешните табла за управление, натоварванията за вземане на решения ще бъдат трудни за управление. Те имат различни очаквания за латентност, поведение при таксуване и режими на повреда. Организациите със зрели програми LLM за управление на разходите ще трябва да отделят трафика за вземане на решения от трафика за генериране, така че маршрутизирането, бюджетите и сигналите да отразяват как действително се държи работното натоварване.

Същото важи и за шлюзовете. Многомоделен AI API шлюз, който нормализира само обаждания в стил чат, може да не е достатъчен, ако доставчиците продължат да създават специализирани крайни точки за решения, инструменти, партиди, аудио на живо и агенти. B2B LLM платформите и вътрешните равнини за управление на AI може да се нуждаят от първокласни категории крайни точки за въведени решения, вместо да налагат всичко чрез абстракция на чат.

Кой е засегнат

Разработчиците на приложения получават най-директна полза, ако поддържат код за класифициране или маршрутизиране, изискващ много бързи съобщения. Новият API може да им позволи да заменят крехките потоци за подкана и анализ с въведени изходи, които по-добре съответстват на вътрешната машина на състоянието на приложението.

Екипите на платформата за изкуствен интелект са засегнати, тъй като те ще трябва да решат дали решенията API са изложени като отделна одобрена възможност, как се регистрират и кои екипи могат да я използват. Проверяващите сигурността и съответствието ще искат да знаят дали резултатите от решенията се използват за контрол на достъпа, допустимост на потребителите, работни процеси в здравеопазването, наемане, финансови решения или други чувствителни процеси.

Екипите по финанси и операции също трябва да обърнат внимание. Обажданията за вземане на решения могат да бъдат невидими в докладването на изпълнителен директор, ако са включени в по-широко използване на модела. След като приложенията започнат да използват моделни повиквания като логика на контролната равнина, а не само генериране, обърнато към потребителя, LLM API приписване на разходите трябва да улови бизнес функцията на повикването, а не само името на модела.

Какво остава несигурно

Съобщението за бета версия установява основната форма на API, но важни производствени детайли все още се нуждаят от валидиране. OpenAI не е предоставил независими сравнителни доказателства за твърдението „до 10 пъти по-бързо“ при реално корпоративно работно натоварване. Разработчиците ще трябва да тестват латентността със собствени входни размери, полезни натоварвания на изображения, региони и модели на едновременност.

Също така не е ясно колко стабилен ще бъде бета интерфейсът, как ще се сравнят ограниченията на скоростта с други OpenAI API повърхности и как решенията API ще се развиват заедно с отговорите и бъдещите API на агентите. Ценообразуването е привлекателно за нива на вземане на решения с голям обем, но бета ценообразуването и поведението на крайната точка не трябва да се третират като постоянни без преглед на договора.

Стратегическият сигнал обаче е ясен: OpenAI отделя друг често срещан модел на приложение за LLM от генерирането с общо предназначение. За бизнеса това означава, че AI архитектурата става все по-малко свързана с избора на една крайна точка на модела и повече със съпоставянето на всяко работно натоварване с правилния API примитив.