Copilot Studio eller Vertex AI? Datagrænsen bestemmer agentvalget

|Forfatter: QUASA's redaktion|6 min. læsning| 2
Copilot Studio eller Vertex AI? Datagrænsen bestemmer agentvalget

Vælg Copilot Studio som første pilot, hvis en intern agent skal bruge medarbejdernes eksisterende Microsoft-identitet og viden i Microsoft 365. Vælg Vertex AI Agent Builder som første pilot, hvis agenten skal udvikles og drives tæt på virksomhedens data og tjenester i Google Cloud. I begge tilfælde afgør datagrænsen, hvilken identitet der må hente oplysninger og udføre handlinger; først derefter giver en prissammenligning mening.

Googles dokumentation for Vertex AI Agent Builder beskriver en suite til at bygge, skalere og styre agenter i produktion og peger på både Agent Development Kit og Agent Engine. Copilot Studio og Googles løsning kan begge indgå i en intern vidensagent og en ekstern serviceagent. De to opgaver skal dog vurderes hver for sig, fordi medarbejderens adgang til interne dokumenter og kundens adgang til egne oplysninger bygger på forskellige rettigheder.

Identiteten afgør, hvilke svar agenten må give

For den interne vidensagent er det afgørende, om et svar følger den enkelte medarbejders rettigheder. Microsofts oversigt over videnskilder omfatter blandt andet SharePoint, Dataverse og virksomhedsdata via Copilot-connectors. For disse kilder kræves brugerautentificering, og agenten skal kun vise indhold, som den autentificerede bruger kan tilgå. Det gør Copilot Studio til et oplagt udgangspunkt, når både viden og adgangsregler allerede ligger i Microsoft-miljøet.

Det er stadig nødvendigt at skelne mellem kilderne. Et offentligt websted kræver ikke den samme brugerautentificering som SharePoint, og et dokument, der er uploadet direkte til agenten, har ikke automatisk medarbejderens SharePoint-rettigheder. Hvis vidensagenten skal besvare spørgsmål fra begge typer kilder, må pilotens adgangstest afspejle forskellen. Et korrekt svar på et internt spørgsmål er en fejl, hvis medarbejderen ikke havde ret til at se grundlaget.

På Google-siden bør kortet over adgang begynde med agentens projekt, identitet, datakilder og de API'er, den kalder. En virksomhed med egne tjenester i Google Cloud kan bygge forbindelserne dér, mens viden i SharePoint kræver en særskilt integration og en beslutning om, hvordan slutbrugerens rettigheder føres med. Ingen af platformenes produktnavne afgør i sig selv, om en bestemt bruger må se en bestemt oplysning.

To ens opgaver giver en brugbar sammenligning

En intern pilot kan bruge det samme udvalg af politikker, de samme spørgsmål og de samme medarbejderprofiler på begge platforme. Nogle spørgsmål bør vedrøre dokumenter, som testbrugeren må læse; andre bør vedrøre dokumenter, som vedkommende ikke må læse. Registrér både svarenes korrekthed, brugbare kildehenvisninger og afvisninger ved manglende adgang. Dermed bliver det synligt, om agenten løser opgaven inden for den tilsigtede datagrænse.

Den eksterne pilot kan besvare identiske spørgsmål om levering og returnering. Hvis den også skal slå en ordre op, må begge løsninger få det samme godkendte opslag og den samme kontrol af kundens identitet. Et opslag i en offentlig returregel og et opslag i en anden kundes ordre er forskellige adgangssituationer, selv om begge begynder med et spørgsmål i en chat.

For begge piloter bør køberen indsamle andelen af korrekte svar, uberettigede opslag, gennemførte handlinger, svartid, fejl og gentagne kørsler. Mål også arbejdet med at oprette forbindelser, vedligeholde rettigheder og ændre agenten efter en fejl. Det er målinger fra virksomhedens egen konfiguration; offentlig produktdokumentation giver ikke en reproducerbar vinder på svarkvalitet eller hastighed for netop disse opgaver.

Styring omfatter også det, agenten kan ændre

En videnskilde lader typisk agenten læse. Et værktøj kan desuden oprette eller ændre en sag, sende en besked eller kalde en ordretjeneste. Derfor bør pilotens handlingsoversigt vise, hvilken identitet der kalder hvert værktøj, hvilke data det kan læse eller ændre, og hvem der kan standse adgangen. Den eksterne serviceagent har særligt brug for en tydelig grænse mellem at forklare en returregel og at ændre en konkret ordre.

Udviklingsformen påvirker, hvem der ejer den styring i praksis. Et team, der allerede administrerer Microsoft 365 og Power Platform, kan lægge agentens videnskilder og publicering ind i kendte arbejdsgange. Et team, der bygger med Googles Agent Development Kit, må tilsvarende eje kode, udrulning og integrationer. De forskellige arbejdsgange er en del af anskaffelsesprisen, også når selve forbruget senere måles i kreditter eller cloudressourcer.

Microsofts kreditter er kapacitet, ikke en medarbejderpris

Microsofts prisside for Copilot Studio angiver en pakke med 25.000 Copilot Credits til 200 dollar pr. måned samt mulighed for forbrugsafregning. Pakken er kapacitet på organisationsniveau. Prissiden skelner desuden mellem intern brug for licenserede Microsoft 365 Copilot-brugere og den selvstændige løsning, som kan publiceres til eksterne kanaler. Pakkeprisen kan derfor ikke uden videre divideres med antallet af medarbejdere eller bruges som pris for den eksterne serviceagent.

Microsofts kreditsatser angiver to kreditter for et generativt svar, fem for en agenthandling og ti for tenant graph grounding; flere satser kan indgå i samme interaktion. Som betinget regneeksempel bruger 1.000 interne spørgsmål med ét generativt svar og én graph grounding hver 12.000 kreditter. Hvis 1.000 eksterne spørgsmål hver udløser ét generativt svar og én afregnet agenthandling, bliver det 7.000 kreditter. Eksemplerne forudsætter netop de angivne hændelser og er ikke målt forbrug fra en pilot.

For den interne agent kan fakturaen være anderledes end kreditregnestykket: relevant medarbejdervendt brug er inkluderet, når brugeren har Microsoft 365 Copilot-licens, og agenten arbejder med den autentificerede brugers identitet. Den betingelse må holdes adskilt fra et eksternt kundescenarie. Køberen bør desuden aflæse agentens faktiske hændelser, fordi flere svar, handlinger eller modelvalg ændrer kreditforbruget.

Google måles i runtime og særskilte tjenester

Googles opdatering om Agent Builder beskriver en registrering af godkendte værktøjer og afregning af Agent Engine-runtime efter vCPU-timer og hukommelsestimer; lagrede sessionshændelser og hentede minder har særskilte satser. Det forbinder styring og pris: et ekstra værktøjskald kan både udvide agentens adgang og ændre ressourceforbruget. Modelkald og eventuelle søgetjenester skal også med i den samlede opgørelse.

Bruges 1.000 interne henvendelser som betinget eksempel, og antages én vCPU og én GB hukommelse aktiv i 20 sekunder pr. henvendelse, svarer det til cirka 5,6 vCPU-timer og 5,6 GB-timer. Ved 30 sekunder pr. ekstern henvendelse bliver det cirka 8,3 af hver. Tre lagrede sessionshændelser pr. ekstern henvendelse giver yderligere 3.000 hændelser. Tallene er regnede forudsætninger, ikke en prognose for, hvor længe en udrullet agent faktisk holder ressourcer aktive.

Det samlede køb afhænger derfor af mere end den laveste enhedspris. Den interne pilot kan tale for Copilot Studio, hvis eksisterende Microsoft-rettigheder dækker opgaven og licenserne omfatter brugen. Vertex AI Agent Builder kan være det bedre udgangspunkt, hvis data, API'er og udviklerdrift allerede ligger i Google Cloud. Den afgørende sammenligning er, om begge løsninger holder samme adgangsgrænse og løser samme opgave, når udviklingsarbejde, faktisk forbrug og fejl er regnet med.

Læs også:

Del:

Tilmeld dig vores nyhedsbrev

Få de seneste nyheder om Web3, AI og krypto direkte i din indbakke.

0