Vercel добави Microsoft Decision-1 към AI Gateway, разширявайки малката, но важна категория модели, създадени за типизирана класификация, маршрутизиране и точкуване, вместо генериране на отворен текст.
Изданието от 9 октомври означава, че разработчиците могат да извикват модела чрез AI SDK решение API на Vercel, OpenAI-съвместими решения API или Съвместим с TypeSafe API, използвайки името на модела microsoft/microsoft-decision-1. Vercel казва, че потребителите се нуждаят само от ключ за AI Gateway API, без отделен акаунт или внедряване в Azure.
Промяната е тясна по отношение на продукта, но сочи към по-широка промяна в начина, по който инфраструктурата на приложенията за AI се разделя. Все по-голям дял от производствената работа на AI не е чат. Той решава дали даден билет за поддръжка е свързан с таксуване или технически, дали работният процес трябва да премине към следващата стъпка, дали AI отговорът отговаря на рубрика или кой модел надолу по веригата трябва да обработи заявка. Decision-1 дава на тези работни натоварвания по-ясен интерфейс.
Какво се промени
Decision-1 е проектирано да отговаря на въведени въпроси относно текста. Вместо да връща обяснение в свободна форма, Vercel казва, че може да връща вероятности, избори и резултати. Това го прави подходящ за задачи, при които приложението се нуждае от структуриран отговор, който може да използва незабавно.
Vercel изброява класификацията на заявките за поддръжка, изборът на стъпки от работния процес и оценката на рубриката за отговор на AI като примерни употреби. Това не са бляскави приложения, но са често срещани в корпоративните AI системи. Те също така са склонни да седят в критичния път на решенията за разходи, забавяне и качество.
Опаковката на портала има значение. Излагайки Decision-1 през AI Gateway, Vercel прави модела достъпен чрез същия вид контролна повърхност, която разработчиците вече използват за други AI повиквания. За екипи, които стандартизират OpenAI-съвместим API шлюз, което намалява оперативното триене при тестване на модел за вземане на решения, без да създава друг път към акаунта на доставчика.
Също така следва неотдавнашния ход на OpenAI за отделяне на извиквания за въведени решения от общи генеративни повиквания. Въпросът не е само, че има друг модел. Това е, че категорията на интерфейса става все по-видима сред доставчиците и шлюзовете.
Защо въведените извиквания за вземане на решения имат значение
Повечето LLM платформи първоначално бяха организирани около чат с генериране на токени и извиквания за завършване. Тази форма не винаги е идеална за класифициране, маршрутизиране, оценка и проверки на правилата. Една система може да се нуждае от ограничен отговор, оценка на доверието или малък набор от разрешени избори, а не абзац.
Въведените модели на решение могат да направят тези повиквания по-лесни за разсъждение. Ако дадено приложение попита дали входящо съобщение принадлежи към една от петте категории, структурираният отговор с вероятности е по-лесен за регистриране, сравняване и одит, отколкото отговор на естествен език, който трябва да бъде анализиран след факта.
Това разграничение става по-важно, тъй като AI системите стават все по-автоматизирани. Решението за маршрутизиране може да определи дали дадена заявка отива към евтин модел, първокласен модел, опашка за човешки преглед или блокиран път. Оценката на рубрика може да определи дали отговор, генериран от AI, се показва на клиент. Класификатор може да реши кой екип да получи заявка за поддръжка.
За разработчиците практическата последица е архитектурна. Обажданията за вземане на решение не трябва да се третират просто като кратки подкани за чат. Те са отделен тип работно натоварване с различни очаквания за латентност, детерминизъм, наблюдаемост и приписване на разходите. В зрял стек тези обаждания трябва да се виждат в таблата за управление заедно с чат, изображения, видео, вграждане и трафик на агенти.
Кой е засегнат
Непосредствената аудитория са разработчици, които вече използват Vercel AI Gateway или AI на Vercel SDK.Те могат да тестват Decision-1, без да настройват отделно внедряване на Azure, което намалява усилията, необходими за сравняването му с други модели с възможност за вземане на решения.
Екипите на продуктите и платформите може да почувстват въздействието по-широко. Ако една компания има десетки работни потоци с изкуствен интелект, обажданията за класифициране и маршрутизиране често се превръщат в скрита инфраструктура. Те могат да бъдат вградени в автоматизация на поддръжката, операции по продажби, модериране на съдържание, вътрешни агенти или канали за оценка. След като тези обаждания се прехвърлят към шлюз, екипите могат да започнат да ги управляват като първокласен клас трафик.
Това има ясни последици за LLM API приписване на разходите. Обажданията за вземане на решения може да са поотделно по-евтини от дългите генеративни обаждания, но могат да работят с много по-висок обем. Платформа за поддръжка може да класифицира всяко входящо съобщение. Агентна система може да оцени няколко възможни следващи стъпки за всяка задача. Конвейерът за контрол на качеството може да оцени всеки генериран отговор преди пускането.
За фирми, използващи вътрешни платформи в стил B2B LLM, урокът е ясен: трафикът на решения трябва да бъде маркиран, измерван и управляван отделно, когато е възможно. Ако всички заявки за AI са групирани в една обща кофа за разходи за LLM, екипите губят способността да видят дали разходите идват от генериране, насочено към потребителя, фоново маршрутизиране, оценка или автоматизирани проверки на правилата.
Практически последици за екипите на платформи за AI
Добавянето на Decision-1 трябва да накара екипите на платформите да преразгледат как вътрешно моделират натоварванията на AI. Многомоделен AI API шлюз вече не е само за смяна на един модел на чат с друг. Той все повече трябва да поддържа различни класове задачи: генериране, извличане, създаване на изображения и видео, използване на агентски инструмент, пакетна обработка и вече въведени извиквания за вземане на решения.
Това засяга регистрирането. Проследяванията на заявките трябва да обхващат не само доставчик и модел, но и тип задача, входен клас, върнат избор, увереност, латентност и действие надолу по веригата. Ако модел на решение насочи неправилно клиентски проблем, екипите се нуждаят от начин да реконструират случилото се.
Това се отразява и на оценката. Точността за въведен модел на решение се измерва по различен начин от качеството на отговора за чатбот. Екипите ще се нуждаят от етикетирани набори от данни, матрици на объркване, тестване на прагове и планове за връщане назад. Модел, който работи добре за сортиране на билети за таксуване, може да не е надежден за чувствителна към съответствие класификация.
Той също така засяга доставките и правилата. Ако моделите за вземане на решения станат по-евтини или по-бързи алтернативи на пълните LLM разговори, инженерните екипи може да се изкушат да ги използват широко. Това може да е разумно, но само ако администраторите могат да видят използването по проект, ключ, среда и работен процес. В противен случай евтина функция за контролна равнина може да се превърне в друга непроследена зависимост.
Какво остава несигурно
Съобщението на Vercel установява наличността и поддържаните пътища за достъп, но не отговаря на всеки производствен въпрос. Публичните подробности все още са ограничени относно сравнителната производителност, режимите на отказ, поведението на ценообразуването при различни работни натоварвания и как Decision-1 се сравнява с други опции за въведени решения в реални корпоративни набори от данни.
Има и въпрос за управлението. Моделите за вземане на решения често се използват на места, където резултатът предизвиква действие. Това прави праговете на доверие и политиките за човешки преглед по-важни от самото име на модела. Бизнесът трябва да тества Decision-1 спрямо собствените си данни, преди да разчита на тях за маршрутизиране, правила или работни потоци за оценка, които засягат клиенти или регулирани процеси.
По-големият сигнал е по-ясен: извикванията за въведени решения стават част от основната AI инфраструктура. Тъй като шлюзовете добавят модели като Microsoft Decision-1, компаниите ще трябва да управляват трафика на решения със същата дисциплина, която вече прилагат за достъп до генериращ модел, отчитане на разходите и API-ключово управление.