Xlera8

Zgradite notranjo storitev SaaS s sledenjem stroškov in uporabe za temeljne modele na Amazon Bedrock | Spletne storitve Amazon

Podjetja si prizadevajo hitro sprostiti potencial generativne umetne inteligence z zagotavljanjem dostopa do temeljnih modelov (FM) različnim poslovnim linijam (LOB). Ekipe IT so odgovorne za pomoč LOB pri inovacijah s hitrostjo in agilnostjo, hkrati pa zagotavljajo centralizirano upravljanje in opazovanje. Na primer, morda bodo morali slediti uporabi FM-jev med ekipami, stroškom povratnih bremenitev in zagotoviti preglednost ustreznega stroškovnega mesta v LOB. Poleg tega bodo morda morali urediti dostop do različnih modelov na ekipo. Na primer, če so lahko za uporabo odobreni samo določeni FM.

Amazon Bedrock je popolnoma upravljana storitev, ki ponuja izbiro visoko zmogljivih temeljnih modelov vodilnih podjetij AI, kot so AI21 Labs, Anthropic, Cohere, Meta, Stability AI in Amazon prek enega samega API-ja, skupaj s širokim naborom zmogljivosti za ustvarjanje generativnega AI aplikacije z varnostjo, zasebnostjo in odgovorno umetno inteligenco. Ker Amazon Bedrock deluje brez strežnika, vam ni treba upravljati nobene infrastrukture in lahko varno integrirate in uvedete generativne zmogljivosti AI v svoje aplikacije z uporabo storitev AWS, ki jih že poznate.

Plast programske opreme kot storitve (SaaS) za temeljne modele lahko zagotovi preprost in dosleden vmesnik za končne uporabnike, hkrati pa ohranja centralizirano upravljanje dostopa in porabe. Prehodi API lahko zagotovijo ohlapno povezavo med porabniki modela in storitvijo končne točke modela ter prilagodljivost za prilagajanje spreminjajočemu se modelu, arhitekturam in metodam klicanja.

V tej objavi vam pokažemo, kako zgraditi notranjo plast SaaS za dostop do temeljnih modelov z Amazon Bedrock v arhitekturi z več najemniki (ekipo). Posebej se osredotočamo na spremljanje uporabe in stroškov na najemnika ter tudi na nadzor, kot je omejevanje uporabe na najemnika. Opisujemo, kako se rešitev in načrti porabe Amazon Bedrock preslikavajo v splošni okvir potovanja SaaS. Koda za rešitev in an Komplet za razvoj oblaka AWS (AWS CDK) predloga je na voljo v GitHub repozitorij.

Izzivi

Skrbnik platforme AI mora zagotoviti standardiziran in enostaven dostop do FM za več razvojnih skupin.

Sledi nekaj izzivov pri zagotavljanju nadzorovanega dostopa do temeljnih modelov:

  • Spremljanje stroškov in uporabe – Sledite in revidirajte stroške posameznih najemnikov in uporabo temeljnih modelov ter zagotovite stroške povratne bremenitve na določena stroškovna mesta
  • Nadzor proračuna in uporabe – Upravljajte kvoto API-ja, proračun in omejitve uporabe za dovoljeno uporabo temeljnih modelov v določeni pogostosti na najemnika
  • Nadzor dostopa in upravljanje modela – Določite nadzor dostopa za posamezne dovoljene modele na najemnika
  • Standardiziran API za več najemnikov – Zagotovite dosleden dostop do modelov temeljev z OpenAPI standardi
  • Centralizirano upravljanje API-ja – Zagotovite eno plast za upravljanje ključev API za dostop do modelov
  • Različice in posodobitve modela – Upravljajte z uvajanji novih in posodobljenih različic modelov

Pregled rešitev

V tej rešitvi se sklicujemo na a večnajemnik pristop. A najemnik tukaj se lahko giblje od posameznega uporabnika, določenega projekta, skupine ali celo celotnega oddelka. Ko razpravljamo o pristopu, uporabljamo izraz skupina, ker je najpogostejši. Uporabljamo ključe API za omejevanje in spremljanje dostopa API za ekipe. Vsaki ekipi je dodeljen ključ API za dostop do FM-jev. V organizaciji so lahko razporejeni različni mehanizmi za preverjanje pristnosti uporabnikov in avtorizacijo. Zaradi poenostavitve jih v to rešitev ne vključimo. S to rešitvijo lahko integrirate tudi obstoječe ponudnike identitet.

Naslednji diagram povzema arhitekturo rešitve in ključne komponente. Ekipe (najemniki), dodeljene ločenim stroškovnim mestom, uporabljajo Amazon Bedrock FM prek storitve API. Za spremljanje porabe in stroškov na ekipo rešitev beleži podatke za vsak posamezen priklic, vključno s priklicanim modelom, številom žetonov za modele generiranja besedila in dimenzijami slike za večmodalne modele. Poleg tega združuje klice na model in stroške vsake ekipe.

Rešitev lahko uvedete v svojem računu z uporabo AWS CDK. AWS CDK je odprtokodno ogrodje za razvoj programske opreme za modeliranje in zagotavljanje virov vaših aplikacij v oblaku z uporabo znanih programskih jezikov. Koda AWS CDK je na voljo v GitHub repozitorij.

V naslednjih razdelkih podrobneje obravnavamo ključne komponente rešitve.

Zajemanje uporabe osnovnega modela na ekipo

Potek dela za zajemanje uporabe FM na ekipo je sestavljen iz naslednjih korakov (kot so oštevilčeni v prejšnjem diagramu):

  1. Aplikacija ekipe pošlje zahtevo POST na Amazon API Gateway z modelom, ki ga je treba priklicati v model_id poizvedbeni parameter in uporabniški poziv v telesu zahteve.
  2. API Gateway usmeri zahtevo na AWS Lambda funkcija (bedrock_invoke_model), ki je odgovoren za beleženje informacij o uporabi ekipe amazoncloudwatch in priklic modela Amazon Bedrock.
  3. Amazon Bedrock zagotavlja končno točko VPC, ki jo poganja AWS PrivateLink. V tej rešitvi funkcija Lambda pošlje zahtevo Amazon Bedrock prek PrivateLink za vzpostavitev zasebne povezave med VPC v vašem računu in računom storitve Amazon Bedrock. Če želite izvedeti več o PrivateLink, glejte Uporabite AWS PrivateLink za nastavitev zasebnega dostopa do Amazon Bedrock.
  4. Po invokaciji Amazon Bedrock, Amazon CloudTrail ustvarja a Dogodek CloudTrail.
  5. Če je klic Amazon Bedrock uspešen, funkcija Lambda zabeleži naslednje informacije glede na vrsto priklicanega modela in vrne ustvarjeni odgovor aplikaciji:
    • team_id – Enolični identifikator za skupino, ki je izdala zahtevo.
    • requestId – Enolični identifikator zahteve.
    • model_id – ID modela, ki ga želite priklicati.
    • inputTokens – Število žetonov, poslanih modelu kot del poziva (za generiranje besedila in modele vdelav).
    • outputTokens – Največje število žetonov, ki jih mora generirati model (za modele generiranja besedila).
    • višina – Višina zahtevane slike (za večmodalne modele in modele z večmodalnimi vstavitvami).
    • širina – Širina zahtevane slike (samo za večmodalne modele).
    • koraki – Zahtevani koraki (za modele Stability AI).

Spremljanje stroškov na ekipo

Drugačen tok združuje informacije o uporabi, nato pa dnevno izračuna in shrani stroške na zahtevo na ekipo. Z ločenim tokom zagotavljamo, da sledenje stroškov ne vpliva na zakasnitev in prepustnost toka priklica modela. Koraki poteka dela so naslednji:

  1. An Amazon EventBridge pravilo sproži funkcijo Lambda (bedrock_cost_tracking) dnevno.
  2. Funkcija Lambda pridobi informacije o uporabi iz storitve CloudWatch za prejšnji dan, izračuna povezane stroške in shrani podatke, ki jih združi team_id in model_id in Preprosta storitev shranjevanja Amazon (Amazon S3) v formatu CSV.

Za poizvedovanje in vizualizacijo podatkov, shranjenih v Amazon S3, imate na voljo različne možnosti, vključno z S3 Izberitein Amazon Athena in Amazon QuickSight.

Nadzor uporabe na ekipo

Načrt uporabe določa, kdo lahko dostopa do enega ali več razporejenih API-jev, in po želji nastavi ciljno stopnjo zahtev za začetek dušenja zahtev. Načrt uporablja ključe API za prepoznavanje odjemalcev API, ki lahko dostopajo do povezanega API-ja za vsak ključ. Uporabite lahko API Gateway načrti uporabe za dušenje zahtev, ki presegajo vnaprej določene pragove. Uporabite lahko tudi Ključi API-ja in omejitve kvot, ki vam omogočajo, da nastavite največje število zahtev na ključ API-ja, ki jih sme posamezna ekipa izdati v določenem časovnem intervalu. To je poleg Kvote storitve Amazon Bedrock ki so dodeljeni samo na ravni računa.

Predpogoji

Preden uvedete rešitev, se prepričajte, da imate naslednje:

Razmestite sklad AWS CDK

Sledite navodilom v README datoteko repozitorija GitHub za konfiguracijo in uvedbo sklada AWS CDK.

Sklad uporablja naslednje vire:

  • Zasebno omrežno okolje (VPC, zasebna podomrežja, varnostna skupina)
  • Vloga IAM za nadzor dostopa do modela
  • Lambda plasti za potrebne module Python
  • Lambda funkcija invoke_model
  • Lambda funkcija list_foundation_models
  • Lambda funkcija cost_tracking
  • Rest API (API Gateway)
  • Načrt uporabe prehoda API
  • Ključ API, povezan z načrtom uporabe

Na krovu nove ekipe

Za zagotavljanje dostopa do novih ekip lahko isti ključ API delite z različnimi ekipami in sledite porabi modela z zagotavljanjem drugačnega team_id za priklic API-ja ali ustvarite namenske ključe API-ja, ki se uporabljajo za dostop do virov Amazon Bedrock, tako da sledite navodilom v README.

Sklad uporablja naslednje vire:

  • Načrt uporabe prehoda API, povezan s predhodno ustvarjenim API-jem REST
  • Ključ API-ja, povezan z načrtom uporabe za novo ekipo, z rezerviranimi konfiguracijami za dušenje in razpoke za API

Za več informacij o dušenju prehoda API in konfiguracijah zapletov glejte Zahteve API-ja za plin za boljšo prepustnost.

Ko uvedete sklad, lahko vidite, da je novi ključ API za team-2 je tudi ustvarjen.

Konfigurirajte nadzor dostopa modela

Skrbnik platforme lahko dovoli dostop do določenih temeljnih modelov z urejanjem pravilnika IAM, povezanega s funkcijo Lambda invoke_model.

Dovoljenja IAM so definirana v datoteki setup/stack_constructs/iam.py. Glej naslednjo kodo:

self.bedrock_policy = iam.Policy( scope=self, id=f"{self.id}_policy_bedrock", policy_name="BedrockPolicy", statements=[ iam.PolicyStatement( effect=iam.Effect.ALLOW, actions=[ "sts:AssumeRole", ], resources=["*"], ), iam.PolicyStatement( effect=iam.Effect.ALLOW, actions=[ "bedrock:InvokeModel", “bedrock:ListFoundationModels", ], resources=[ "arn:aws:bedrock:*::foundation-model/anthropic.claude-v2.1", "arn:aws:bedrock:*::foundation-model/amazon.titan-text-express-v1", "arn:aws:bedrock:*::foundation-model/amazon.titan-embed-text-v1"
], ) ], ) … self.bedrock_policy.attach_to_role(self.lambda_role)

Prikličite storitev

Ko uvedete rešitev, lahko storitev pokličete neposredno iz svoje kode. Naslednji

je primer v Pythonu za uporabo invoke_model API za ustvarjanje besedila prek zahteve POST:

api_key=”abcd1234” model_id = "amazon.titan-text-express-v1" #the model id for the Amazon Titan Express model model_kwargs = { # inference configuration "maxTokenCount": 4096, "temperature": 0.2
} prompt = "What is Amazon Bedrock?" response = requests.post( f"{api_url}/invoke_model?model_id={model_id}", json={"inputs": prompt, "parameters": model_kwargs}, headers={ "x-api-key": api_key, #key for querying the API "team_id": team_id #unique tenant identifier }
) text = response.json()[0]["generated_text"] print(text)

Rezultat: Amazon Bedrock je notranja tehnološka platforma, ki jo je razvil Amazon za izvajanje in upravljanje številnih njihovih storitev in izdelkov. Nekaj ​​ključnih stvari o Bedrocku …

Sledi še en primer v Pythonu za uporabo invoke_model API za ustvarjanje vdelav prek zahteve POST:

model_id = "amazon.titan-embed-text-v1" #the model id for the Amazon Titan Embeddings Text model prompt = "What is Amazon Bedrock?" response = requests.post( f"{api_url}/invoke_model?model_id={model_id}", json={"inputs": prompt, "parameters": model_kwargs}, headers={ "x-api-key": api_key, #key for querying the API "team_id": team_id #unique tenant identifier, "embeddings": "true" #boolean value for the embeddings model }
) text = response.json()[0]["embedding"]

Izhod: 0.91796875, 0.45117188, 0.52734375, -0.18652344, 0.06982422, 0.65234375, -0.13085938, 0.056884766, 0.092285156, 0.06982422 , 1.03125, 0.8515625, 0.16308594, 0.079589844, -0.033935547, 0.796875, -0.15429688, -0.29882812, -0.25585938, 0.45703125, 0.044921875 0.34570312, XNUMX …

Dostop do temeljnih modelov zavrnjen

Sledi primer v Pythonu za uporabo invoke_model API za ustvarjanje besedila prek zahteve POST z odgovorom zavrnjen dostop:

model_id = " anthropic.claude-v1" #the model id for Anthropic Claude V1 model model_kwargs = { # inference configuration "maxTokenCount": 4096, "temperature": 0.2
} prompt = "What is Amazon Bedrock?" response = requests.post( f"{api_url}/invoke_model?model_id={model_id}", json={"inputs": prompt, "parameters": model_kwargs}, headers={ "x-api-key": api_key, #key for querying the API "team_id": team_id #unique tenant identifier }
) print(response)
print(response.text)

»Traceback (najnovejši klic zadnji):n Datoteka ”/var/task/index.py“, vrstica 213, v odgovoru lambda_handlern = _invoke_text(bedrock_client, model_id, body, model_kwargs)n Datoteka ”/var/task/index.py ”, vrstica 146, v _invoke_textn raise en datoteka ”/var/task/index.py”, vrstica 131, v _invoke_textn response = bedrock_client.invoke_model(n datoteka ”/opt/python/botocore/client.py”, vrstica 535, v _api_calln vrne self._make_api_call(operation_name, kwargs)n Datoteka ”/opt/python/botocore/client.py”, vrstica 980, v _make_api_calln dvig error_class(parsed_response, operation_name)nbotocore.errorfactory.AccessDeniedException: Pri klicanju operacije InvokeModel je prišlo do napake (AccessDeniedException): vaš račun ni pooblaščen za klic te operacije API-ja.n”

Primer ocene stroškov

Pri priklicu modelov Amazon Bedrock s cenami na zahtevo se skupni stroški izračunajo kot vsota vhodnih in izhodnih stroškov. Vhodni stroški temeljijo na številu vhodnih žetonov, poslanih v model, izhodni stroški pa na ustvarjenih žetonih. Cene veljajo za 1,000 vhodnih žetonov in za 1,000 izhodnih žetonov. Za več podrobnosti in specifične cene modelov glejte Cene Amazon Bedrock.

Oglejmo si primer, kjer dve ekipi, team1 in team2, dostopajo do Amazon Bedrock prek rešitve v tej objavi. Podatki o uporabi in stroških, shranjeni v Amazon S3 v enem dnevu, so prikazani v naslednji tabeli.

Stolpci input_tokens in output_tokens shrani skupne vhodne in izhodne žetone v priklicih modela na model oziroma na ekipo za določen dan.

Stolpci input_cost in output_cost shranite zadevne stroške na model in na ekipo. Ti se izračunajo po naslednjih formulah:

input_cost = input_token_count * model_pricing["input_cost"] / 1000
output_cost = output_token_count * model_pricing["output_cost"] / 1000

team_id model_id vhodni_žetoni izhodni_žetoni prikliki vhodni_strošek izhodni_strošek
Team1 amazon.titan-tg1-large 24000 2473 1000 0.0072 0.00099
Team1 anthropic.claude-v2 2448 4800 24 0.02698 0.15686
Team2 amazon.titan-tg1-large 35000 52500 350 0.0105 0.021
Team2 ai21.j2-grande-instruct 4590 9000 45 0.05738 0.1125
Team2 anthropic.claude-v2 1080 4400 20 0.0119 0.14379

Pogled od konca do konca funkcionalnega okolja SaaS brez strežnika z več najemniki

Razumejmo, kako bi lahko izgledalo funkcionalno okolje SaaS z več najemniki brez strežnika od konca do konca. Sledi diagram referenčne arhitekture.

Ta arhitekturni diagram je pomanjšana različica prejšnjega arhitekturnega diagrama, razloženega prej v objavi, kjer prejšnji arhitekturni diagram pojasnjuje podrobnosti ene od omenjenih mikrostoritev (storitev temeljnega modela). Ta diagram pojasnjuje, da morate imeti poleg storitve temeljnega modela tudi druge komponente v svoji platformi SaaS z več najemniki, če želite implementirati funkcionalno in razširljivo platformo.

Pojdimo skozi podrobnosti arhitekture.

Prijave najemnikov

Najemniške aplikacije so sprednje aplikacije, ki komunicirajo z okoljem. Tukaj prikazujemo več najemnikov, ki dostopajo iz različnih lokalnih okolij ali okolij AWS. Sprednje aplikacije je mogoče razširiti tako, da vključujejo registracijsko stran za nove najemnike, da se registrirajo sami, in skrbniško konzolo za skrbnike sloja storitev SaaS. Če aplikacije najemnika zahtevajo implementacijo logike po meri, ki potrebuje interakcijo z okoljem SaaS, lahko implementirajo specifikacije mikrostoritve vmesnika aplikacije. Primeri scenarijev bi lahko bili dodajanje avtorizacijske logike po meri ob upoštevanju avtorizacijskih specifikacij okolja SaaS.

Skupne storitve

To so skupne storitve:

  • Storitve upravljanja najemnikov in uporabnikov –Te službe so odgovorne za registracijo in vodenje najemnikov. Zagotavljajo medsektorsko funkcionalnost, ki je ločena od aplikacijskih storitev in jo delijo vsi najemniki.
  • Storitev modela fundacije – Diagram arhitekture rešitve, pojasnjen na začetku te objave, predstavlja to mikrostoritev, kjer se interakcija od API Gateway do funkcij Lambda dogaja znotraj obsega te mikrostoritve. Vsi najemniki uporabljajo to mikrostoritev za priklic temeljnih modelov Anthropic, AI21, Cohere, Stability, Meta in Amazon ter natančno nastavljenih modelov. Zajame tudi informacije, potrebne za sledenje uporabi v dnevnikih CloudWatch.
  • Storitev sledenja stroškov – Ta storitev spremlja stroške in uporabo za vsakega najemnika. Ta mikrostoritev deluje po urniku, da poizveduje po dnevnikih CloudWatch in izpiše združeno sledenje uporabe in ugotovljene stroške v shrambo podatkov. Storitev sledenja stroškov je mogoče razširiti za izdelavo dodatnih poročil in vizualizacije.

Storitev aplikacijskega adapterja

Ta storitev predstavlja niz specifikacij in API-jev, ki jih lahko najemnik implementira, da integrira svojo logiko po meri v okolje SaaS. Glede na to, koliko integracije po meri je potrebna, je ta komponenta lahko izbirna za najemnike.

Shramba podatkov z več najemniki

Storitve v skupni rabi hranijo svoje podatke v shrambi podatkov, ki je lahko ena skupna raba Amazon DynamoDB tabela s particijskim ključem najemnika, ki povezuje elemente DynamoDB s posameznimi najemniki. Skupna storitev za sledenje stroškov pošilja združene podatke o sledenju uporabe in stroškov v Amazon S3. Glede na primer uporabe lahko obstaja tudi shramba podatkov, specifična za aplikacijo.

Okolje SaaS z več najemniki ima lahko veliko več komponent. Za več informacij glejte Gradnja rešitve SaaS z več najemniki z uporabo brezstrežniških storitev AWS.

Podpora za več modelov uvajanja

Ogrodja SaaS običajno opisujejo dva modela uvajanja: bazen in silos. Pri modelu bazena vsi najemniki dostopajo do FM-jev iz skupnega okolja s skupno shrambo in računalniško infrastrukturo. V modelu silosa ima vsak najemnik svoj niz namenskih virov. O izolacijskih modelih si lahko preberete v Bela knjiga o strategijah izolacije najemnikov SaaS.

Predlagano rešitev je mogoče sprejeti za oba modela uvedbe SaaS. Pri pristopu bazena centralizirano okolje AWS gosti API, shranjevanje in računalniške vire. V silosnem načinu vsaka ekipa dostopa do API-jev, pomnilnika in računalniških virov v namenskem okolju AWS.

Rešitev se ujema tudi z razpoložljivimi načrti porabe, ki jih ponuja Amazon Bedrock. AWS ponuja izbiro dveh načrtov porabe za sklepanje:

  • Na zahtevo – Ta način vam omogoča uporabo temeljnih modelov na osnovi doplačila, ne da bi morali sprejemati kakršne koli časovne obveznosti.
  • Zagotovljena prepustnost – Ta način vam omogoča zagotavljanje zadostne prepustnosti za izpolnjevanje zahtev glede zmogljivosti vaše aplikacije v zameno za časovno vezavo

Za več informacij o teh možnostih glejte Cene Amazon Bedrock.

Referenčna rešitev SaaS brez strežnika, opisana v tej objavi, lahko uporabi načrte porabe Amazon Bedrock, da končnim uporabnikom zagotovi osnovne in vrhunske možnosti razporeditve. Osnovno bi lahko vključevalo porabo Amazon Bedrock na zahtevo ali predvideno prepustnost in bi lahko vključevalo posebne omejitve uporabe in proračuna. Omejitve najemnikov je mogoče omogočiti z dušenjem zahtev na podlagi zahtev, velikosti žetonov ali dodelitve proračuna. Najemniki na ravni Premium bi lahko imeli lastne namenske vire z zagotovljeno porabo prepustnosti Amazon Bedrock. Ti najemniki bi bili običajno povezani s proizvodnimi delovnimi obremenitvami, ki zahtevajo visoko prepustnost in nizko zakasnitev dostopa do Amazon Bedrock FM.

zaključek

V tej objavi smo razpravljali o tem, kako zgraditi notranjo platformo SaaS za dostop do temeljnih modelov z Amazon Bedrock v nastavitvi z več najemniki s poudarkom na sledenju stroškov in uporabe ter omejevanju omejitev za vsakega najemnika. Dodatne teme, ki jih je treba raziskati, vključujejo integracijo obstoječih rešitev za preverjanje pristnosti in avtorizacijo v organizaciji, izboljšanje sloja API za vključitev spletnih vtičnic za dvosmerne interakcije odjemalskega strežnika, dodajanje filtriranja vsebine in drugih zaščitnih ograj upravljanja, oblikovanje več stopenj uvajanja, integracijo drugih mikrostoritev v SaaS arhitektura in še veliko več.

Celotna koda za to rešitev je na voljo v GitHub repozitorij.

Za več informacij o okvirih, ki temeljijo na SaaS, glejte SaaS Journey Framework: izgradnja nove rešitve SaaS na AWS.


O avtorjih

Hasan Poonawala je višji arhitekt za rešitve za AI/ML pri AWS, ki dela s strankami v zdravstvu in znanosti o življenju. Hasan pomaga pri oblikovanju, uvajanju in prilagajanju aplikacij Generative AI in Machine learning na AWS. Ima več kot 15 let kombiniranih delovnih izkušenj na področju strojnega učenja, razvoja programske opreme in podatkovne znanosti v oblaku. V prostem času Hasan rad raziskuje naravo in preživlja čas s prijatelji in družino.

Anastasia Tzeveleka je višji strokovnjak za rešitve AI/ML pri AWS. Kot del svojega dela pomaga strankam po Evropi, Bližnjem vzhodu in Afriki zgraditi temeljne modele in ustvariti razširljive generativne rešitve umetne inteligence in strojnega učenja z uporabo storitev AWS.

brubrez Pistone je Generative AI in ML Specialist Solutions Architect za AWS s sedežem v Milanu. Sodeluje z velikimi strankami in jim pomaga poglobljeno razumeti njihove tehnične potrebe ter oblikovati rešitve umetne inteligence in strojnega učenja, ki najbolje izkoristijo oblak AWS in sklad strojnega učenja Amazon. Njegovo strokovno znanje vključuje: strojno učenje od konca do konca, industrializacijo strojnega učenja in generativno umetno inteligenco. Rad preživlja čas s prijatelji in raziskuje nove kraje ter potuje na nove destinacije.

Vikesh Pandey je arhitekt Generative AI/ML Solutions, specializiran za finančne storitve, kjer finančnim strankam pomaga zgraditi in razširiti platforme in rešitve Generative AI/ML, ki se prilagajajo na stotine do celo tisoče uporabnikov. V prostem času Vikesh rad piše na različnih blogih in s svojim otrokom sestavlja lego kocke.

Klepetajte z nami

Zdravo! Kako vam lahko pomagam?