Na na Výkonový architekt Sudhakar Reddy Narra demonštroval, ako konvenčné nástroje na testovanie výkonu vynechávajú všetky spôsoby, akými sa AI agenti skutočne rozpadajú pod záťažou. Testovacia konferencia v Istanbule Testovacia konferencia v Istanbule Keď výkonní inžinieri testujú tradičné webové aplikácie, metriky sú jednoduché: doba odozvy, priepustnosť a miera chybovosti. Dotknite sa systému tisíckami súbežných požiadaviek, pozrite sa na grafy a identifikujte nedostatky. Ale systémy AI sa nerozpadajú rovnakým spôsobom. Na minuloročnej konferencii TestIstanbul, výkonový architekt Sudhakar Reddy Narra vytiahol jeden z najväčších davov podujatia, 204 účastníkov z celkového počtu 347 účastníkov, aby vysvetlil, prečo tradičné prístupy k testovaniu zaťaženia sú zásadne slepé na to, ako agenti AI zlyhávajú vo výrobe. „Agent AI môže vrátiť perfektné odpovede HTTP 200 za menej ako 500 milisekúnd a zároveň poskytnúť úplne zbytočné odpovede,“ povedala Narra divákom. „Vaše monitorovacie dosky sú zelené, ale používatelia sú frustrovaní. Rozdiel v inteligencii Základným problémom, podľa Narra, je, že systémy AI sú nedeterministické. Kŕmte rovnaký vstup dvakrát a môžete získať rôzne výstupy, obaja technicky správne, ale líšia sa v kvalite. Zákaznícka služba AI by mohla brilantne vyriešiť dotaz jeden okamih, potom dať generickú, zbytočnú odpoveď ďalší, aj keď obe transakcie vyzerajú identické so štandardným monitorovaním výkonu. Táto variabilita vytvára testovacie výzvy, ktoré konvenčné nástroje neboli navrhnuté tak, aby sa vyrovnali.Metriky času odozvy neodhaľujú, či AI skutočne pochopila zámer používateľa.Hromadné čísla neukazujú, že systém horí cez svoje "kontextové okno", modely pracovnej pamäte AI používajú na udržanie súdržnosti konverzácie a začínajú strácať stopu z toho, čo používatelia pýtajú. "Meriame rýchlosť, keď by sme mali merať inteligenciu pod zaťažením," argumentoval Narra. Nové metriky pre nový problém Prezentácia Narra predstavila niekoľko metrík výkonu špecifických pre AI, ktoré testovacie rámce v súčasnosti ignorujú: Čas zamýšľaného riešenia: Ako dlho trvá, kým AI identifikuje, čo používateľ skutočne chce, oddelene od latencie surovej odpovede. Miera neistoty systému pri vytváraní odpovedí.Vysoké zmätenie počas zaťaženia často predchádza zhoršeniu kvality, ktoré si užívatelia všimnú, ale monitorovacie nástroje nie. Tokenový prienik: Namiesto merania požiadaviek za sekundu sledujte, koľko tokenov sú základné jednotky spracovania textu, ktoré systém spracováva. Použitie kontextového okna: Ako blízko je systém k vyčerpaniu svojej pracovnej pamäte. Agent, ktorý pracuje pri 90% kontextovej kapacite, je jedna konverzácia, ktorá sa odvráti od zlyhania, ale tradičné monitorovanie nevidí žiadne varovné signály. Hranica degradácie: Úroveň zaťaženia, pri ktorej kvalita reakcie začína klesať, aj keď časy reakcie zostávajú prijateľné. Na rozdiel od tradičných aplikácií, kde každá požiadavka stojí približne to isté na spracovanie, interakcie AI sa môžu líšiť od centov po doláre v závislosti od toho, koľko počítačového „myslenia“ sa vyskytuje. Testovanie nepredvídateľného Jedna praktická výzva Narra zdôraznila: generovanie realistických testovacích údajov pre systémy AI je oveľa ťažšie ako pre konvenčné aplikácie. Test prihlásenia potrebuje užívateľské meno a heslo. Testovanie agenta služieb zákazníkom AI si vyžaduje tisíce rozmanitých, nepredvídateľných otázok, ktoré napodobňujú spôsob, akým skutoční ľudia kladú otázky, kompletné s nejednoznačnosťou, typom a jazykovou variáciou. Jeho prístup zahŕňa extrahovanie vzorcov zámerov z výrobných denníkov, potom programaticky generovanie variácií: synonymá, prefrázovanie, prípady hraníc. Cieľom je vytvoriť syntetické súbory údajov, ktoré simulujú ľudskú nepredvídateľnosť v rozsahu bez toho, aby jednoducho opakovali rovnaké dotazy opakovane. "Nemôžete nahrať test AI s 1000 kópiami tej istej otázky," vysvetlil. "Systém zaobchádza s opakovaním inak ako s skutočnou odrodou. Problémy s modelovaním Ďalšia zložitosť Narra zdôraznila: systémy AI nezostávajú statické. Keď sa modely preštudujú alebo aktualizujú, ich výkonnostné charakteristiky sa menia aj vtedy, keď okolitý kód zostáva nezmenený. Agent, ktorý minulý mesiac pohodlne zaobchádzal s 1 000 súčasnými používateľmi, by mohol po aktualizácii modelu bojovať s 500, nie kvôli chybám, ale preto, že nový model má rôzne vzorce spotreby zdrojov. "To znamená, že testovanie výkonu nemôže byť jednorazovou validáciou," povedal Narra. "Potrebujete nepretržité testovanie, keď sa AI vyvíja." Popísal rozšírenie tradičných nástrojov na testovanie zaťaženia, ako je Apache JMeter, s AI-vedomými schopnosťami: vlastné pluginy, ktoré merajú rýchlosť spracovania tokenov, sledujú využitie kontextu a monitorujú sémantickú presnosť počas zaťaženia, nielen rýchlosť. Odolnosť na okraji Prezentácia tiež pokrývala testovanie odolnosti pre systémy AI, ktoré závisia od externých API, záverových motorov a špecializovaného hardvéru, z ktorých každý predstavuje potenciálny bod zlyhania. Tradičné systémy buď fungujú, alebo hádžu chyby. systémy AI často zlyhávajú postupne, degradujú sa z užitočných na všeobecné na zmätené bez toho, aby sa technicky „zlomili“. "Najťažšie problémy na zachytenie sú tie, kde všetko vyzerá dobre v denníkoch, ale užívateľská skúsenosť je strašná," poznamenal. Priemyselné adopčné otázky Trh s testovaním umelej inteligencie je na vzostupe a väčšina organizácií stále zisťuje základné nasadenie umelej inteligencie, nehovoriac o sofistikovanom inžinierstve výkonu. Niektorí odborníci tvrdia, že existujúce nástroje pozorovateľnosti môžu byť jednoducho rozšírené o nové metriky namiesto toho, aby si vyžadovali úplne nové testovacie paradigmy. Narra uznal, že pole je skoro: "Väčšina tímov si neuvedomuje, že to potrebujú, kým už neodosielajú niečo, čo narúša výrobu. Pozerať dopredu Vysoká účasť na zasadnutí Narra TestIstanbul, ktoré prilákalo takmer 60% účastníkov konferencie, naznačuje, že testovacia komunita uznáva, že existuje medzera medzi tým, ako fungujú systémy AI a ako sú v súčasnosti validované.Či už vyhrávajú konkrétne prístupy Narra alebo konkurenčné metodiky, širšia výzva zostáva: keďže AI prechádza od experimentálnych funkcií k výrobnej infraštruktúre, testovacie postupy sa musia podľa toho vyvíjať. Zatiaľ je otázka, ktorej čelia inžinierske tímy, ktoré nasadzujú AI vo veľkom meradle, jednoduchá: Ako testujete niečo, čo je navrhnuté tak, aby bolo nepredvídateľné? Podľa Narra, odpoveď začína priznať, že tradičné metriky nezaznamenávajú to, čo skutočne záleží a budovať nové, ktoré robia.

This story contains new, firsthand information uncovered by the writer.

Read My Stories

Tento zvuk je vyrobený v pôvodnom jazyku príbehu!

Prečo tradičné testovanie zaťaženia zlyháva pre moderné systémy AI

About Author

KOMENTÁRE

ZAVISTE ŠTÍTKY

TENTO ČLÁNOK BOL PREDSTAVENÝ V

Related Stories

Code Smell 298 - How to Fix Microsoft Windows Time Waste

112 Stories To Learn About Hackernoon Community

Behavior of a shapely Spider

Mutmut: a Python mutation testing system

Code Smell 298 - How to Fix Microsoft Windows Time Waste

112 Stories To Learn About Hackernoon Community

Behavior of a shapely Spider

Mutmut: a Python mutation testing system

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps