OpenAI је објавио нове одлуке API у јавној бета верзији, дајући програмерима засебну крајњу тачку за откуцане одлуке уместо за генерисање целог текста. Бета верзија је стигла 6. октобра са подршком за GPT-6 Луна и позиционирана је за радна оптерећења где је излазни простор познат унапред: предикати, избори и резултати.
То звучи уско, али је важно. Велики удео производног АИ саобраћаја није отворено писање. То је класификација, рутирање, провере суседних смерница модерације, откривање намере, избор алата и логика заштитне ограде. Ти позиви често траже од модела да произведе мали структурирани одговор, а затим приморавају апликацију да га рашчлани или потврди. OpenAI сада третира тај образац као сопствену површину API.
Шта се променило
Одлуке API претвара текст и слике у откуцане одговоре. OpenAI каже да може бити до 10 пута бржи од одговора API за подржана радна оптерећења одлучивања. У јавној бета верзији, програмери могу да дефинишу излазне резултате као предикате, изборе или резултате, уместо да подстичу модел да генерише произвољан текст, а затим ограничава резултат након чињенице.
Модел одређивања цена је такође другачији. OpenAI наводи GPT-6 коришћење Луна за Одлуке API на 0,10 УСД за 1 милион улазних токена, без наплате читања, кеширања или излазног токена. То чини економију јединице лакшим за моделирање за слојеве одлучивања великог обима јер је рачун везан само за улазни обим.
Издање не замењује ћаскање, одговоре или АПИ-је оријентисане на агенте. Он ствара специјализованију путању за случајеве у којима је апликацији потребан поуздан откуцани одговор, а не пасус. За тимове који већ деле оптерећење на величине модела, слојеве кашњења и руте добављача, ово додаје још једну категорију архитектури: позиве за одлучивање.
Зашто би програмери требало да брину
Многе АИ апликације већ користе мале позиве модела као логику интерне контроле. Помоћник за подршку може да класификује карту пре него што одабере ток посла. Агент за кодирање може одлучити који алат да позове следеће. Систем за обраду докумената може оценити да ли запис испуњава праг политике. Производ окренут клијентима може усмеравати захтеве између јефтинијих и способнијих модела.
До сада су ти обрасци често примењивани као нормални позиви генерисања са стриктним упитима, JSON шемама, поновним покушајима и слојевима валидације. Тај приступ функционише, али носи додатне трошкове. Програмери плаћају излазне токене, управљају неуспешним рашчлањивањем и често прихватају више кашњења него што би сама одлука требало да захтева.
Укуцана крајња тачка одлуке мења тај компромис. Ако се излаз може представити као логички, ограничени избор или резултат, тимови могу померити позив из опште генеративне путање. То може смањити кашњење и поједноставити код апликације. Такође може да смањи двосмисленост у евиденцији и аналитици јер је сврха позива експлицитна.
Најнепосреднији случајеви коришћења ће вероватно бити интерне провере високе фреквенције: усмеравање захтева, капије квалификованости садржаја, правила ескалације, кораци за избор алата и смернице за избор модела. На тим местима, мала побољшања у кашњењу и трошковима могу бити битна јер се позив одлуке може догодити пре сваког захтева већег модела.
Импликације на трошкове и управљање
Цена само за унос је комерцијални детаљ за гледање. За тимове који користе велике количине заштитних ограда или одлука о рутирању, елиминисање наплате излазних токена мења поређење са малим моделима ћаскања, машинама правила и крајњим тачкама класификатора специфичних за провајдера. Такође чини прогнозе трошкова мање осетљивим на обимност излаза или поновне покушаје шеме.
То не значи да сваки класификатор треба да пређе на Одлуке API. Детерминистичка правила ће и даље бити јефтинија и лакша за ревизију када је логика једноставна. Постојећи филтери за уграђивање, претрагу или базе података могу бити прикладнији за неке проблеме са рутирањем. Али тамо где се модел већ користи за тумачење неуредног текста или слика у ограничени одговор, нови API даје тимовима чистију опцију набавке и инжењеринга.
За платформске тимове, већи проблем је таксономија. Ако се сви АИ позиви третирају као довршетак ћаскања или генерички одговори на интерним контролним таблама, тешко ће се управљати радним оптерећењем одлучивања. Имају различита очекивања кашњења, понашање наплате и режиме неуспеха. Организације са зрелим програмима ЛЛМ за управљање трошковима ће морати да одвоје саобраћај одлучивања од саобраћаја генерисања тако да рутирање, буџети и упозорења одражавају како се радно оптерећење заправо понаша.
Исто важи и за мрежне пролазе. Мулти-модел АИ API пролаз који само нормализује позиве у стилу ћаскања можда неће бити довољан ако добављачи наставе да праве специјализоване крајње тачке за одлуке, алате, групе, звук уживо и агенте. B2B LLM платформама и интерним нивоима контроле вештачке интелигенције ће можда бити потребне првокласне категорије крајњих тачака за укуцане одлуке уместо да се све намеће кроз апстракцију ћаскања.
Ко је погођен
Програмери апликација добијају најдиректнију корист ако одржавају брзу класификацију или код за рутирање. Нови API може да им омогући да замене крхке токове брзих порука и рашчлањивања са откуцаним излазима који се боље подударају са интерном машином стања апликације.
Тимови АИ платформе су погођени јер ће морати да одлуче да ли ће Одлуке API бити изложене као посебна одобрена способност, како се евидентира и који тимови могу да је користе. Рецензенти безбедности и усклађености ће желети да знају да ли се резултати одлука користе за контролу приступа, квалификованост корисника, токове рада у здравству, запошљавање, финансијске одлуке или друге осетљиве процесе.
Тимови за финансије и операције такође треба да обрате пажњу. Позиви за доношење одлука могу бити невидљиви у извршном извештавању ако су повезани у ширу употребу модела. Једном када апликације почну да користе позиве модела као логику контролне равни, а не само генерацију окренуту кориснику, ЛЛМ API атрибуција трошкова треба да обухвати пословну функцију позива, а не само назив модела.
Шта остаје неизвесно
Бета најава утврђује основни облик API, али важним детаљима производње и даље је потребна валидација. OpenAI није пружио независне референтне доказе за тврдњу „до 10к брже“ у стварним радним оптерећењима предузећа. Програмери ће морати да тестирају кашњење помоћу сопствених улазних величина, носивости слике, региона и образаца истовремености.
Такође је нејасно колико ће бета интерфејс бити стабилан, како ће се ограничења брзине упоређивати са другим површинама OpenAI API и како ће се одлуке API развијати заједно са одговорима и будућим АПИ-јима агената. Цене су атрактивне за слојеве одлучивања великог обима, али бета цене и понашање крајње тачке не би требало да се третирају као трајни без прегледа уговора.
Међутим, стратешки сигнал је јасан: OpenAI раздваја још један уобичајени образац ЛЛМ апликације од генерисања опште намене. За предузећа то значи да архитектура вештачке интелигенције постаје све мање везана за одабир једне крајње тачке модела, а више на усклађивање сваког радног оптерећења са правим API примитивом.