AWS agentų architektūra be tiekėjo spynos: verslui reikia išėjimo plano

AWS agentų architektūra be tiekėjo spynos skamba techniškai. Bet verslui čia labai paprasta tema: ar galėsite išeiti, jei pasirinktas kelias nebetiks?

AWS rugpjūčio 20 d. aprašė agentinio DI įmonių modelius, kur svarbu nesusirišti su vienu tiekėju per daug stipriai.

Čia kaip su nuoma. Kol viskas gerai, sutarties beveik neskaitai. Kai reikia kraustytis, staiga kiekviena eilutė svarbi.

SPYNA ATSIRANDA NEPASTEBIMAI

Tiekėjo priklausomybė retai prasideda blogu sprendimu. Ji prasideda patogumu: čia greičiau, čia integruota, čia viskas vienoje vietoje.

Po metų agentai jau naudoja konkrečias API, duomenų formatus, leidimų modelius, stebėseną ir vidinius įrankius. Tada keisti tiekėją tampa brangu.

Kartais verta mokėti už patogumą. Bet reikia žinoti kainą.

KĄ PLANUOTI IŠ ANKSTO

Prieš statant agentų platformą, susitarkite dėl kelių dalykų: kur saugoma atmintis, kaip aprašomi įrankiai, kaip keičiami modeliai, kaip eksportuojami logai.

Jeigu viskas užrakinta viename tiekėjo formate, turite ne platformą, o priklausomybę.

Geras klausimas komandai: jeigu rytoj reikėtų pakeisti modelį, kiek savaičių skaudėtų?

NE VISKĄ REIKIA DARYTI UNIVERSALIAI

Čia nereikia perspausti. Mažam eksperimentui galima rinktis paprastą kelią ir nesukti galvos dėl architektūros.

Bet kai agentai pradeda liesti klientus, duomenis, finansus ar operacijas, reikia daugiau tvarkos.

Išėjimo planas nereiškia, kad išeisite. Jis reiškia, kad nesate įkalinti.

FAQ

Kas yra tiekėjo spyna DI projektuose?

Tai situacija, kai DI sistema taip priklauso nuo vieno tiekėjo įrankių, kad ją sunku perkelti ar pakeisti.

Kaip jos išvengti?

Aiškiai aprašyti įrankius, duomenis, logus, atmintį ir modelių keitimo būdą.

Ar visada reikia vengti vieno tiekėjo?

Ne. Kartais patogumas vertas kainos, bet riziką reikia suprasti iš anksto.

Šaltinis: AWS Machine Learning Blog.

Jeigu norite DI įrankius įsivesti praktiškai, pradėkite nuo vieno darbo proceso. MasterSprint tam duoda aiškų startą.