Случаят срещу магическата оркестрация

AI оркестрацията става опасна, когато скрива състоянието, инструментите, политиката, повторните опити и правомощията зад самоуверена графика. Сериозните...

Случаят срещу магическата оркестрация

Графиката, която изглеждаше интелигентна

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

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

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

AI оркестрацията е мястото, където вероятността среща работния процес. Това кръстовище не прощава. Моделът може да избере план. Инструментът може да върне резултат. Политиката може да позволи действие. Повторният опит може да промени контекста. Човек може да одобри. Долна система може да действа. Ако тези преходи не са назовани, ограничени и записани, организацията получава система, която изглежда интелигентна, но чието поведение е трудно да се възпроизведе и още по-трудно да се управлява. Тя не е автономна. Просто е уклончива с по-добър брандинг.

Графиката изглежда интелигентна от публиката. Липсващото инженерство е зад кулисите: изрична собственост, трайно състояние и доказателства за неуспешните клонове.

Оркестрацията не е интелигентен прах

Думата оркестрация може да накара обикновеното инженерство да звучи новоомагьосано. Последователността става верига. Условният оператор става рутер. Извикването на функция става инструмент. Цикълът while става агент. Опашката става памет, ако осветлението е подходящо. Част от този речник е полезна, защото AI системите наистина въвеждат нови проблеми с координацията. Част от него е опаковка. Опаковката не е зло. Тя става скъпа, когато екипите забравят какво има вътре в кутията.

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

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

Дисциплинираният дизайн на оркестрация не премахва гъвкавостта. Той поставя гъвкавостта в релси. Моделът може да предложи план, но изходът на планировчика има схема. Системата може да извиква инструменти, но инструментите имат обхвати и бюджети. Работният процес може да прави повторни опити, но причините за повторните опити са класифицирани. Паметта може да помага, но авторитетното състояние се съхранява другаде. Човек може да одобрява, но одобрението вижда съответните клонове и доказателства. Гъвкавостта оцелява. Мистерията не получава правото да управлява.

Проблемът със скритото състояние

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

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

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

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

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

Извикванията на инструменти не са безобидни

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

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

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

Страничните ефекти заслужават особено внимание. План, генериран от модел, може да бъде изхвърлен. Изпратен имейл не може да бъде оттеглен със същата увереност. Променен запис може да задейства downstream системи. Разгръщане може да засегне потребители. Възстановяване на сума може да премести пари. Оркестрацията трябва да разделя предложението от действието и да изисква изрични порти за необратими или значими стъпки. Ако една система може да прави реални неща, тя се нуждае от повече от агентски цикъл. Тя се нуждае от спирачки, ключове и някой, който знае къде е резервният.

Повторните опити са политика в маскировка

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

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

Без тази дисциплина оркестрацията създава учтиви цикли. Системата продължава да опитва, защото опитването е евтино в код. Тя може да изгори бюджет, да напълни логове, да обърка потребители и в крайна сметка да произведе отговор, който изглежда по-добър главно защото по-ранните доказателства за нестабилност са скрити. В производствена среда цикъл, който крие собствените си неуспешни опити, не е упоритост. Той е амнезия с лента за напредък.

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

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

Верификацията не е декоративен възел

Много диаграми на оркестрация включват верификатор. Добре. След това верификаторът е помолен да провери дали отговорът е правдоподобен, добре оформен или съобразен с инструкциите. По-малко добре. Верификатор, който чете само крайния отговор, може да пропусне грешките, които имат значение: слаб източник, забранен вход, неуспешен инструмент, конфликт на политики, опасно действие или план, променен без одобрение. Може да полира входната врата, докато кухнята гори.

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

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

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

Паметта не трябва да се представя за авторитет

Паметта на агента е полезна, когато носи предпочитания, предишен контекст и знания за повтарящи се задачи. Тя е опасна, когато се представя за авторитетно състояние. Запомнено предпочитание не е политика. Предишен отговор не е запис. Резюме на случай не е самият случай. Успешен минал план не е доказателство, че следващата задача позволява същите инструменти. Паметта помага за непрекъснатост. Не трябва да ѝ се позволява да пренася авторитет от вчера в днес.

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

Паметта също се нуждае от изтриване и коригиране. Погрешно предположение не трябва да продължава да съществува, защото е било полезно веднъж. Временно условие на проект трябва да изтече. Потребителска корекция трябва да се прилага в определен обхват. Промяна на политика трябва да обезсили старата памет. Резюме, генерирано от модел, не трябва да се превръща в пряк път, който замества първичен източник. Системата трябва да показва каква памет е повлияла на плана и да позволява на потребителите да я оспорят. В противен случай паметта се превръща в учтиво преследване.

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

Простото побеждава магическото по-често, отколкото екипите очакват

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

Скучната алтернатива често печели. Фиксирана последователност се тества по-лесно от отворен цикъл. Типизиран портал за инструменти е по-безопасен от свободен избор на инструменти. Опашка с изрични състояния се управлява по-лесно от рекурсивен агент. Базирана на правила защита е по-евтина от моделен оценител, когато правилото е ясно. Път за ескалация към човек е по-добър от нов опит, когато последствията са големи. Това не са позиции срещу AI. Това са позиции в полза на системата.

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

Полезен въпрос при проектирането е: какво никога не трябва да бъде избирано от модела. Авторитет на източника. Права на потребителите. Лимити на бюджета. Необратими действия. Задължения за съхранение. Правно основание. Прагове за безопасност. Някои от тях могат да бъдат предлагани или обяснявани от моделите. Те не трябва да бъдат тихо задавани от тях. Модел може да помогне за навигиране в работна поредица. Той не трябва да се превръща в конституция, защото е било удобно да се сложи всичко в контекста.

Практическият въпрос не е дали агентите са позволени. Той е кои контроли са твърде важни, за да бъдат тихо избирани от модела.

Проектирайте оркестрацията като операционен модел

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

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

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

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

Урокът

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

Добрата оркестрация е по-малко мистична и по-полезна. Тя именува състоянията. Ограничава инструментите. Записва доказателства. Разделя предложението от действието. Класифицира повторните опити. Проверява спрямо договорите за задачите. Отнася се към паметта като към помощна, а не като към авторитетна. Дава на хората състояния за преглед вместо непрозрачни записи. Избира прости конвейери, когато простите конвейери са достатъчни. Добавя агенти там, където неяснотата оправдава оперативната цена.

Магията скрива механизма. Сериозният изкуствен интелект се нуждае от механизми, които могат да бъдат инспектирани, спирани, коригирани и подобрявани. Целта не е да се премахне удивлението от софтуера. Целта е удивлението да не попада в доклада за инцидента.