LLM pagrįstų produktų mastelio paslaptis: papildinių architektūros per monolitus

Ei, vaikinai

Pavaizduokite tai: Jūsų komanda ką tik išleido naują LLM varomą programą-galbūt tai yra apibendrinantis įrankis, įmontuotas jūsų prietaisų skydelyje, arba intelektualioji pokalbių programa, skirta klientų aptarnavimui.

Tai apakino demonstracines versijas. Lyderystė buvo sužavėta. Tačiau po savaitės vartotojas suaktyvina keistą kraštą. Tu pataisai. Tada kita komanda nori pakartotinai naudoti modelį naujam naudojimo atvejui. Jūs pataisote logiką, perverskite šiek tiek API ir… bumo. „Chatbot“ nutrūksta. Vėl.

Sveiki atvykę

Kadangi dideli kalbų modeliai (LLM) yra įterpiami į daugiau produktų, inžinerijos komandos atranda atšiaurią tiesą: LLMS magija nelabai didėja tvirtai sujungtoje architektūroje. Vieno komponento modifikavimas gali turėti nenuspėjamą poveikį kitiems komponentams, todėl funkcijos, kurios pirmą kartą pasirodė lengvai pergalės į trapias sistemas, pertvarkymas. Derinimo posūkiai tampa absoliučiu košmaru. Eksperimentas sulėtėja. Pasitikėjimas erodes.

Bet yra geresnis būdas.

Nuo monolitų iki modulių: papildinių architektūros kilimas

Papildinių architektūros gali revoliucionizuoti LLM pagrįstus produktus taip, kaip „Microservices“ sukūrė žiniatinklio programų kūrimą. Komandos naudoja modulinį požiūrį, kai kiekviena AI talpa (pvz., Sandarizavimas, vertimas, klausimų keitimas ir klasifikacija) yra įtraukta kaip atskiras, prijungiamas vienetas, užuot sukuriantis vieną, tarpusavyje priklausomą kodų bazę, kur visos funkcijos yra susipynusios.

Galima, kad šie „papildiniai“ būtų savarankiškai sukurti, išbandyti, įgyvendinti, sekti ir patobulinti.

Jie bendrauja su API sluoksniu arba centriniu orkestratoriumi, kuris nukreipia užklausas pagal sistemos būseną, vartotojo ketinimus ar kontekstą. Be to, papildiniai gali būti keičiami arba pakoreguoti, nesijaudinant dėl to, kad visa sistema neveikia, nes jie yra laisvai prijungti.

Apsvarstykite galimybę statyti „Lego“ plytas, o ne vieną medienos gabalą drožybai. Tai mąstysenos poslinkis.

Kodėl monolitai greitai žlunga LLM eroje

Monolitiniai LLM produktai dažnai prasideda kaip vidiniai eksperimentai arba laimi „Hackathon“. Čia keletas užkoduotų raginimų, ten esanti protinga grandinės logika. Ilgai trukus produkto logika, modelio skambučiai, verslo taisyklės ir UI įrišimai yra susieti.

Problemos iškyla greitai:

Tvirtumas: Naujų naudojimo atvejų pridėjimas dažnai reiškia esamos logikos perrašymą.

Greitas chaosas: Vieno greito šablono pakeitimai daro įtaką keliems srautams.

Versija pragaras: Nėra švaraus kelio į A/B testo raginimą ar modelio atnaujinimus.

Saugumo rizika: Greitas įpurškimas ar duomenų nutekėjimas tampa sunkiau atskirti.

Tai panašu į bandymą įtraukti važiavimus į pramogų parką, kuriame visa elektra veikia per vieną senovinę saugiklių dėžę. Viena perkrova, ir visa tai tamsu.

Kokia papildinio architektūra atrodo praktiškai

Tarkime, kad jūsų „SaaS“ platforma naudoja LLMS penkioms pagrindinėms funkcijoms: apibendrinimas, sentimentų analizė, pokalbių programa, dokumentų klausimai ir atsakymai ir atitikties patikrinimai. Su papildiniu pagrįsta architektūra:

• Kiekvienas iš jų yra atskiras modulis, turintis savo greitą logiką, bandymo strategiją, greičio apribojimus ir atsarginį.

• Centrinis orkestratorius (pritaikytas ar naudojantis įrankius, tokius kaip „Langchain“ ar „LlamainDex“), vartotojo užklausas išsiunčia į reikiamą papildinį pagal metaduomenis ar vartotojo ketinimus.

• Kiekvienas papildinys gali naudoti skirtingus modelius (pvz., „Openai“ klausimams ir atsakymams, „Cohere“ klasifikavimui) ir net hibridinius metodus (LLM + taisyklės).

• Testavimas ir stebėjimas yra apžvelgiami: galite stebėti, kaip kiekvienas papildinys veikia savarankiškai.

• Jei vienas papildinys sugenda arba tampa brangus, galite jį atskirti ir patobulinti neliesdami kitų.

Kaip tai pagreitina mastelį

Greitas eksperimentas: Norite išbandyti naują apibendrinimo strategiją? Diegkite lygiagrečią papildinį ir palyginkite išvestis.

Specializuotas domenasJonai: Raginimo raginimai arba tikslinimo modeliai tampa lengvesni, kai jie yra pritaikyti prie konkretaus papildinio.

Rizikos sulaikymas: Klaidos, haliucinacijos ar saugumo problemos išlieka izoliuotos.

Lanksčiai atnaujinimai: Išjunkite modelius, sureguliuokite logiką arba įdiegkite talpyklos kaupimą – visa tai nekreipdami į programą.

Ir turbūt kritiškai papildinių architektūros „Foster Team Aligility“. Skirtingi būriai gali turėti skirtingus papildinius, dislokuoti savarankiškai ir judėti savo greičiu. Nebereikia koordinavimo pridėtinės vertės kiekvieną kartą, kai norite pakartoti.

Bet tai susiję ne tik su technologijomis – kalbama apie dizaino discipliną

Visa tai skamba puikiai. Tačiau būkime aiškūs: įskiepių architektūros neatsiranda automatiškai. Jie reikalauja:

• Aiškios abstrakcijos ribos

• Tvirtos sąsajos apibrėžimai (API, schemos, sutartys)

• Kruopštus greitas inžinerija atsižvelgiant į konteksto apribojimus

• Nuoseklus medienos ruoša, stebėjimas ir stebėjimas

Tokie rėmai, kaip „Langchain“, padeda, tačiau jie nevykdys disciplinos. Štai kur atsiranda patyrusių partnerių, tokių kaip „Spritle Software“. Mes matėme, kas nutinka, kai komandos pasidaro pasidaryk pats arba pasikliauja šablonais, esančiais ne architektūriniu planavimu. Taip, jūs gaunate greitas demonstracines versijas, bet ne tvarias sistemas.

Mes dirbame su produktų komandomis ne „parduoti AI“, o architektui tolimam laikui: padedant kurti modulines sistemas, įvertinti papildinių ribas, saugiai integruoti su išorinėmis API ir duomenų sluoksniais ir nustatyti valdymo bėgelius. Mūsų misija nėra pastatyti vieną kartą – tai padės jums toliau statyti nesulaužant.

Metaforos Svarbi: pagalvokite apie pilotus, o ne orakules

LLM papildiniai yra tarsi ekspertų kopilo. Jie neskraido visu lėktuvu, tačiau jie tvarko atskiras, kritines funkcijas: skaityti orą, sureguliuoti maršrutą, versti oro eismo valdymo instrukcijas. Norite, kad kiekvienas pilotas būtų gerai išmokytas, patikimas ir pritvirtintas prie jų juostos. Ne vienas žinojimas, kuris gali haliucinuoti aukštį.

Ir pasaulyje, kuriame AI produktai tampa svarbūs misijai, ši disciplina nėra neprivaloma. Tai strateginė.

Žvilgsnis į priekį: kompozicija yra AI ateitis

PG produktai vis dažniau bus sistemų sistemos. Kompozicija. AUDITINAMAS. Išplėsti. Bendrovės, kurioms pavyks, nebus tos, kurios 2024 m. Išsiuntė „The Exkemest Chatbot“-jos bus tos, kurios laikui bėgant galės saugiai išsiųsti dešimtis LLM varomųjų galimybių, kurių kiekvienas yra patobulintas, atsakingas ir vystosi.

Ta ateitis nėra sukurta ant magijos. Jis pastatytas ant architektūros.

Taigi prieš kitą AI sprintą paklauskite savęs:

Ar mūsų LLM loginė modulinė?

Ar galime atskirti, išbandyti ir pakeisti dalis?

Ar mes kuriame ne tik demonstracinę versiją, bet ir „Scale“?

Ir jei atsakymas dar nėra „ne“ – mes norėtume padėti.

Padarykime AI keičiamą, tvarią ir protingai suprojektuotą. Kartu.

Reikia pagalbos, architektūros jūsų LLM produkto mastui? Pasitarkite su „Spritle Software“ AI komanda. Mes kalbame laisvai ir praktine inžinerija.