Multi-tenant DI agentai: kai vienas produktas aptarnauja daug klientų
AWS aprašė, kaip kurti multi-tenant DI agentus su Amazon Bedrock AgentCore.
Šiame straipsnyje · 6 dalys
- Kas yra multi-tenant agentas? Tai agentas arba agentų sistema, aptarnaujanti kelis klientus vienoje platformoje.
- Kodėl tai svarbu? Nes kiekvieno kliento duomenys, teisės ir nustatymai turi būti izoliuoti.
- Ar pakanka prompto taisyklių? Ne. Reikia techninių prieigos ir duomenų atskyrimo mechanizmų.
multi-tenant DI agentai skamba kaip techninis terminas. Bet kai pažiūri praktiškai, čia yra labai žemiškas klausimas: kiek darbo darome rankomis tik todėl, kad niekas neprisėdo sutvarkyti proceso?
AWS aprašė, kaip kurti multi-tenant DI agentus su Amazon Bedrock AgentCore. Paprastai: vienas produktas, daug klientų, atskiri duomenys, atskiros teisės ir jokio „oi, ne tam parodėme“.
Man tokiose naujienose visada įsijungia mažas vidinis buhalteris. Ne tas, kuris skaičiuoja sąskaitas, o tas, kuris klausia: kiek tai kainuos, kas prižiūrės ir kur gali lūžti?
Kas nutiko
Multi-tenant architektūra leidžia vienai platformai aptarnauti daug organizacijų, bet kiekvienai išlaikyti savo duomenų ribas, konfigūraciją ir prieigas. DI agentams tai ypač jautru, nes jie gali veikti per įrankius ir sistemas.
Čia kaip daugiabutis. Laiptinė bendra, bet raktas į butą turi būti tik jūsų. Jei kaimynas netyčia atsidaro jūsų duris, jau nebe technologinė smulkmena, o rimtas pokalbis.
Kodėl tai svarbu
Kai agentai pradeda skaityti dokumentus, jungtis prie CRM ar vykdyti veiksmus, tenantų atskyrimas tampa būtinas. Kitaip vieno kliento klaida gali paliesti kitą klientą.
DI jau nebe vien langelis, į kurį įmetame tekstą. Jis jungiasi prie įrankių, moka kviesti servisus, gali veikti keliais žingsniais ir pradeda liesti tikrus verslo pinigus. Čia romantika baigiasi. Prasideda tvarka.
Ką tai reiškia verslui
SaaS įmonėms ir agentūrų produktams tai labai praktinė tema. Jeigu norite DI funkciją parduoti keliems klientams, reikia ne tik demo, bet ir architektūros su ribomis.
- atskirti klientų duomenis techniniu, ne tik sutartiniu lygiu
- turėti skirtingas agentų teises pagal klientą
- loguose matyti, kuris tenantas ką darė
- testuoti ribinius atvejus, kai agentas bando pasiekti ne savo duomenis
Pradėkite nuo duomenų žemėlapio: kur saugomi klientų failai, kas juos gali skaityti, kokie įrankiai kviečiami ir kas matosi loguose.
Kur pasislėpusi rizika
Rizika – sukurti vieną galingą agentą visiems ir tikėtis, kad promptas gražiai laikys ribas. Promptas nėra spyna.
Blogiausia DI klaida dažnai neatrodo kaip klaida. Ji ateina gražiai parašytu sakiniu, mandagiu tonu ir labai užtikrintu veidu. Todėl verslui reikia ne tik įrankių, bet ir įpročio tikrinti.
Ką pasidaryti šią savaitę
Jei kuriate DI funkciją keliems klientams, paprašykite komandos parodyti, kur tiksliai sistemoje atskiriami tenantai.
Rašome apie dirbtinį intelektą lietuviškai. Kiekvienas straipsnis parengtas pagal nurodytą šaltinį, o nuorodą į originalą rasite kortelėje „Šaltinis“.
