MLOps vs LLMOps: Šta se menja kada je model LLM

MLOps je inženjerska disciplina za pouzdan razvoj, implementaciju, verzionisanje i upravljanje sistemima mašinskog učenja; LLMOps proširuje tu disciplinu na aplikacije izgrađene oko velikih jezičkih modela, gde ponašanje u produkciji zavisi ne samo od artefakta modela već i od upita, konteksta, pretraživanja, verzija provajdera/modela, poziva alata, sigurnosnih kontrola i pipeline-ova za evaluaciju. LLMOps ne zamenjuje MLOps. On menja operativnu jedinicu sa „model plus pipeline za serviranje“ na „LLM aplikaciju koja se razvija i čije ponašanje proizlazi iz nekoliko nezavisno promenljivih komponenti“.

Šta MLOps zaista znači

MLOps primenjuje softversko-inženjersku i operativnu disciplinu na sisteme mašinskog učenja. Produkcijski izazov je širi od treniranja modela: prikupljanje podataka, validacija podataka, eksperimentisanje, reproduktivnost, evaluacija modela, implementacija, infrastruktura i monitoring moraju da rade zajedno.

Google-ove smernice za MLOps arhitekturu definišu disciplinu oko kontinuirane integracije, kontinuirane isporuke i kontinuiranog treniranja. CI validira ne samo kod već i podatke, šeme i modele; CD implementira ML pipeline-ove i servise za predikciju; CT može ponovo da trenira i implementira modele kada se podaci ili implementacije promene.

AWS smernice dodaju iste operativne brige iz drugog ugla: poreklo modela, sledljivost modela/verzija, praćenje drifta i praćenje produkcijskog kvaliteta su ključni delovi održavanja pouzdanosti ML sistema nakon implementacije.

Šta se menja kada je model LLM

Veliki jezički modeli menjaju produkcijski problem jer aplikacija često ne poseduje kompletan životni ciklus treniranja modela. Tim može da poziva hostovanu API uslugu modela, pokreće otvoreni model lokalno, menja provajdere ili koristi nekoliko modela za različite zadatke.

Model je stoga samo jedna verzionisana zavisnost unutar većeg bihevioralnog sistema. Upiti, rezultati pretraživanja, redosled konteksta, alati, snimak modela, podešavanja temperature/zaključivanja, sigurnosni filteri i runtime orkestracija mogu svi da promene izlaz.

To stvara šire operativno pitanje: koja kombinacija modela, konteksta, podataka, upita, alata i runtime-a je proizvela ovo ponašanje? LLMOps postoji da učini to pitanje odgovorivim, a odgovor dovoljno reproduktivnim za inženjerski rad.

Najjednostavniji primer

Pretpostavimo da aplikacija odgovara na pitanja o internim politikama.

U klasičnom ML okviru, mogli biste da verzionirate trenirani klasifikator, implementirate ga i pratite kvalitet predikcije. U LLM aplikaciji, odgovor može da zavisi od snimka hostovanog modela, sistemskog upita, modela za ugrađivanje, vektorskog indeksa, filtera pretraživanja, rerankera i konačno izabranog konteksta.

Promena bilo koje od tih komponenti može da promeni konačni odgovor iako krajnja tačka aplikacije i korisničko pitanje ostaju identični.

Gde se jednostavan primer zaustavlja

Neki LLM sistemi i dalje treniraju ili fino podešavaju sopstvene modele, tako da tradicionalne MLOps prakse kao što su pipeline-ovi za treniranje, registar modela i poreklo podataka ostaju direktno relevantne.

Drugi sistemi koriste samo eksterne API-je foundation modela i nikada ne pokreću kontinuirano treniranje. Njihov glavni operativni teret je evaluacija aplikacije, upravljanje promenama modela/provajdera, verzionisanje prompta/konteksta, kvalitet pretrage i observabilnost.

Zato ne postoji jedinstveni univerzalni „LLMOps pipeline“. Tačan životni ciklus zavisi od toga da li trenirate, fino podešavate, samostalno hostujete, preuzimate eksterno znanje, pokrećete agente ili zavisite od upravljanih API-ja modela.

MLOps vs LLMOps

LLMOps proširuje MLOps, a ne zamenjuje ga

Osnovni operativni principi ne nestaju: kontrola izvornog koda, CI/CD, reproduktivnost, poreklo, kontrole implementacije, praćenje, vraćanje i merljivi kriterijumi prihvatanja ostaju suštinski.

Proširenje je u tome što više artefakata koji definišu ponašanje sada stoji izvan težina modela. Upravljani foundation model može promeniti ponašanje kroz nadogradnje snimaka, dok se izlaz aplikacije može promeniti kroz izmene prompta ili pretrage bez ikakvog ponovnog treniranja modela.

Zato je korisna hijerarhija obično DevOps → MLOps → LLMOps/GenAIOps kao sve specijalizovanije operativne brige, a ne tri međusobno isključive prakse.

Šta se mora verzionisati u LLMOps-u?

Snimci modela postaju zavisnosti izdanja

Sa hostovanim LLM-ovima, tim možda ne kontroliše treniranje modela, ali i dalje kontroliše koji model ili snimak aplikacija poziva.

OpenAI-jeva trenutna API smernica eksplicitno upozorava da se ponašanje prompta može promeniti između snimaka modela i preporučuje fiksiranje produkcijskih aplikacija na određene snimke gde je konzistentnost važna, a zatim pokretanje evaluacija prilikom nadogradnje.

Operativna posledica je jasna: nadogradnje modela treba tretirati kao izdanja aplikacije, a ne kao nevidljivo održavanje infrastrukture.

Životni ciklus provajdera postaje deo operacija

LLM aplikacije često zavise od ograničenja brzine provajdera, rasporeda ukidanja, API semantike, ograničenja konteksta, pravila rukovanja podacima i cena.

Provajder može ukinuti model dok vaš aplikacijski kod ostaje nepromenjen. OpenAI-jev trenutni raspored ukidanja, na primer, uključuje datume povlačenja 2026. za starije snimke modela i platforme.

LLMOps stoga zahteva praćenje životnog ciklusa provajdera, testiranje migracije i odluke o rezervnim rešenjima pored praćenja kvaliteta modela.

Promptovi se ponašaju kao produkcioni kod

Promptovi su izvršna bihevioralna konfiguracija. Male izmene mogu promeniti kvalitet izlaza, izbor alata i tumačenje politike.

OpenAI-jeva trenutna uputstva preporučuju čuvanje produkcionih promptova u aplikacijskom kodu, pregled izmena promptova kroz pull zahteve, korišćenje tipizovanih ulaza i pokrivanje izmena testovima i proverama evaluacije.

To čini verzionisanje promptova manje sličnim uređivanju marketinškog teksta, a više sličnim menjanju funkcije čiji je izlaz probabilistički i zavisi od modela.

Inženjering konteksta postaje operativna briga

Produkcioni model retko prima samo statički prompt. Može primiti istoriju razgovora, preuzete dokumente, izlaze alata, memoriju, trenutno stanje aplikacije i instrukcije politike.

LLMOps stoga mora posmatrati sastavljanje konteksta: koji dokazi su izabrani, koja verzija stanja je bila aktuelna, da li je došlo do skraćivanja i da li su važne instrukcije preživele sažimanje.

Regresija modela i regresija konteksta mogu izgledati identično u konačnom odgovoru. Praćenje stvarne putanje konteksta je ono što omogućava timu da ih razdvoji.

RAG stvara sopstveni operativni životni ciklus

RAG sistem uvodi drugi produkcioni pipeline pored inferencije modela: unos, ekstrakcija, deljenje na delove, metapodaci, ugrađivanja, indeksi, pretraga, ponovno rangiranje i izbor konteksta.

Korpus znanja može se menjati svakog dana čak i kada se model i prompt ne menjaju. Zastareo indeks ili neispravan filter metapodataka može stoga pogoršati kvalitet odgovora bez ikakvog odstupanja modela.

LLMOps za RAG treba da prati verziju korpusa/indeksa, model ugrađivanja, politiku deljenja na delove, konfiguraciju pretrage, svežinu izvora i metrike pretrage odvojeno od kvaliteta generisanja.

Evaluacije zamenjuju „izgleda dobro“ dokazima o izdanju

Generativni izlazi su često otvoreni, pa su testovi tačnog poklapanja nedovoljni za mnoge zadatke. LLMOps dodaje skupove podataka za evaluaciju i ocenjivače koji mogu meriti uspeh zadatka, tačnost, bezbednost, utemeljenost, stil ili kriterijume prihvatanja specifične za domen.

MLflow-ov trenutni GenAI stack za evaluaciju podržava verzionisane skupove podataka za evaluaciju, poređenja promptova/modela, prilagođene ocenjivače i evaluaciju nad kompletnim tragovima.

Najjača praksa je razvoj vođen evaluacijom: definišite reprezentativne slučajeve i kriterijume prihvatanja pre ili uporedo sa izmenama, a zatim uporedite izdanja sa istim dokazima.

LLM kao sudija je koristan, ali nije osnovna istina

LLM sudije mogu da skaliraju evaluaciju za kvalitete koje je skupo kodirati kao determinističke tvrdnje, kao što su relevantnost, ton ili utemeljenost.

Međutim, sudija je drugi model sa sopstvenom pristrasnošću, verzijom i promptom. Konfiguracija sudije stoga treba da bude verzionisana i kalibrisana prema ljudskim ili determinističkim referentnim slučajevima tamo gde su posledice važne.

Produkciona evaluacija može da kombinuje determinističke provere, metrike zasnovane na referencama, model sudije i ljudski pregled, umesto da zahteva da jedna metrika predstavlja svaku dimenziju kvaliteta.

Praćenje postaje važnije od logova krajnjih tačaka

Tradicionalni API logovi mogu da vam kažu da je zahtev trajao dve sekunde i vratio HTTP 200. Ne mogu da vam kažu koji su izvučeni delovi izabrani, koji je alat agent pozvao ili koji je model segment potrošio najviše tokena.

MLflow-ovo trenutno GenAI praćenje beleži promptove, pretrage, pozive alata i segmente aplikacije, a njegov tok produkcione evaluacije može da ocenjuje informacije o srednjoj putanji, a ne samo konačni tekst.

Ovo je veliki pomak u LLMOps-u: observabilnost prati graf ponašanja aplikacije, a ne samo servisnu krajnju tačku.

Agenti proširuju LLMOps na operacije u vreme izvršavanja

Agentna aplikacija može da izvrši nekoliko poziva modela, poziva alata i prelaza stanja pre nego što proizvede rezultat.

Operativni agenti stoga zahtevaju brojanje koraka, tragove poziva alata, odbijanja dozvola, ponovne pokušaje, detekciju petlji, ljudska odobrenja i verifikovano konačno stanje pored uobičajenih metrika latencije modela i tokena.

Tačan konačni odgovor može da sakrije lošu putanju, pa evaluacija agenta mora da pregleda i putanju i rezultat.

Tokeni, pozivi modela i kontekst postaju varijable troškova

Trošak klasičnog ML zaključivanja često je dominiran infrastrukturom za serviranje ili računanjem po predikciji. LLM aplikacije mogu da dodaju cene tokena provajdera, ponovljene pozive agenata, pozive za ugrađivanje, ponovno rangiranje i troškove alata/vremena izvršavanja.

Trošak se stoga mora pripisati zadatku ili tragu, a ne samo jednom endpointu. Radni tok koji pravi osam skrivenih poziva modela može biti funkcionalno ispravan, ali operativno neprihvatljiv.

Latencija se ponaša na isti način: latencija modela, pretraga, rerangiranje i eksterni alati se kombinuju u end-to-end latenciju za korisnika.

Keširanje postaje semantičko, ne samo tehničko

LLM sistemi mogu keširati promptove, embeddinge, rezultate pretrage ili pune odgovore, ali ključ keša mora odražavati semantiku koja može promeniti rezultat.

Keš odgovora koji ignoriše verziju modela, tenanta, dozvole ili svežinu izvora može vratiti tehnički validan, ali semantički nevalidan odgovor.

LLMOps stoga tretira invalidaciju keša kao deo verzionisanja modela/konteksta/podataka, a ne samo kao infrastrukturnu optimizaciju.

Bezbednost i dozvole postaju kriterijumi za izdanje

Generativni sistemi mogu proizvesti neograničen tekst, a agenti mogu pokrenuti eksterne akcije. Testiranje bezbednosti stoga je bliže običnom CI/CD-u nego u mnogim klasičnim sistemima prediktivnog ML-a.

Provere dozvola, testovi prompt-injection-a, testovi izolacije tenanta i odobrenja za sporedne efekte treba da budu reproduktivni regresioni testovi tamo gde ti rizici postoje.

Model može predložiti operaciju, ali runtime i dalje mora sprovesti autorizaciju. LLMOps poseduje dokaze da ti kontroli nastavljaju da rade nakon promena modela, prompta ili alata.

Kako CI izgleda u LLMOps-u

Kako CD izgleda u LLMOps-u

Produkcijsko izdanje možda uopšte neće deploy-ovati novi artefakt modela. Može jednostavno isporučiti novi prompt, konfiguraciju pretrage, skup alata ili mapiranje provajdera.

Paket izdanja stoga treba da identifikuje kompletnu konfiguraciju koja definiše ponašanje, a ne samo sliku kontejnera aplikacije.

Feature flag-ovi, postepeno uvođenje, shadow evaluacija, canary saobraćaj i rollback su korisni jer LLM ponašanje može regresirati na načine koje statički testovi ugovora ne detektuju.

Kontinuirano treniranje postaje opciono; kontinuirana evaluacija postaje centralna

Tradicionalni MLOps često naglašava kontinuirano treniranje kada novi podaci ili drift opravdavaju ponovno treniranje.

Mnoge LLM aplikacije nikada ne treniraju osnovni model. Njihova ekvivalentna neprekidna petlja je kontinuirana evaluacija: prikupljaju neuspehe i reprezentativne produkcijske slučajeve, dodaju ih u skupove podataka za evaluaciju, testiraju izmene kandidata za prompt/model/pretragu i ponovo objavljuju samo kada se dokazi poboljšaju.

Fino podešavanje može ponovo uvesti životni ciklus treniranja, ali treba da bude deo istog šireg procesa evaluacije i objavljivanja.

Šta treba pratiti u produkciji?

Produkcijski tragovi mogu postati podaci za evaluaciju

Jedan od najkorisnijih modernih LLMOps obrazaca je pretvaranje uzorkovanih produkcijskih tragova u zapise za evaluaciju.

MLflow trenutno podržava preuzimanje produkcijskih tragova i ocenjivanje ne samo izlaza već i međukoraka kao što su pretraga ili putanje poziva alata.

Ovo zatvara petlju između observabilnosti i razvoja: stvarni neuspesi mogu postati regresioni slučajevi u sledećem izdanju umesto da nestanu u logovima.

Reproduktivnost postaje uslovna, a ne egzaktna

Klasična ML reproduktivnost često ima za cilj da ponovo stvori model iz verzionisanog koda, podataka, okruženja i parametara treniranja.

Hostovane LLM aplikacije ne mogu uvek da reprodukuju identičan izlaz token po token jer je generisanje probabilističko, a provajderi mogu kontrolisati infrastrukturu.

LLMOps stoga teži bihevioralnoj reproduktivnosti: beleži dovoljno modela/provajdera/verzije, prompta, kontekstualnih ulaza, stanja pretrage i konfiguracije izvršavanja da bi se reprodukovali uslovi i validiralo ponašanje u okviru očekivanih tolerancija.

Loza se širi od loze modela do loze aplikacije

AWS-ove MLOps smernice tretiraju lozu modela kao istoriju artefakata koda, podataka, modela i infrastrukture potrebnih za dijagnostiku i reproduktivnost.

Za LLM aplikacije, loza treba dodatno da poveže promptove, skupove podataka za evaluaciju, verzije pretrage/indeksa, šeme alata, konfiguraciju agenta/vremena izvršavanja i snimke provajdera/modela.

Ciljno pitanje postaje: Koja tačno konfiguracija aplikacije je proizvela ovaj trag?

Usmeravanje ka više provajdera i modela stvara operativnu politiku

Kada aplikacija može da koristi nekoliko provajdera ili lokalnih modela, usmeravanje postaje operativna politika, a ne jednostavan string modela.

Rutiranje može zavisiti od sposobnosti, latencije, cene, privatnosti, dužine konteksta, dostupnosti, podrške za alate ili lokaliteta. Rezervna opcija može očuvati vreme rada dok menja kvalitet odgovora ili pretpostavke obrade podataka.

LLMOps bi stoga trebalo da beleži koja je ruta zaista izabrana i da nezavisno procenjuje rute, umesto da svaku kompatibilnu krajnju tačku tretira kao bihevioralno zamenljivu.

Dokazi iz originalne implementacije

Aaasaasa AI Client: provajder, model i runtime su odvojeni operativni objekti

Aaasaasa AI Client razdvaja agenta/klijenta, provajdera, model, lokaciju runtime-a i dozvole. Njegov AI Hub podržava Ollama, LM Studio/OpenAI-kompatibilne krajnje tačke i druge protokole provajdera, umesto da „model“ tretira kao jedno globalno podešavanje.

Implementacija uključuje dinamičko otkrivanje lokalnih modela, strimovanje, izlaz razmišljanja i eksplicitne Ollama kontrole zagrevanja/učitavanja i istovara. To je operativni dokaz da lokalno serviranje LLM-a uvodi brige o životnom ciklusu resursa koje prevazilaze ime API modela.

Status provajdera se dobija preko adaptera provajdera, a tipovi veze razlikuju lokalne, cloud API, putanje vezane za nalog, udaljene agente i web klijente. To su konkretne operativne dimenzije koje platforma svesna LLM-a mora da izloži.

Repozitorijum takođe čuva važnu granicu: lokalni runtime nije automatski lokalna inferencija. Lokacija provajdera/modela/runtime-a su pitanja koja se verzioniraju ili konfigurišu i koja utiču na privatnost, latenciju, cenu i dostupnost.

Source of Truth Research Engine: stanje LLM aplikacije se proteže izvan modela

Source of Truth Research Engine kombinuje leksičku pretragu, opcione embedding-e, snimke izvora, SHA-256 identitet, tvrdnje, poreklo i praćenje kontradikcija oko istraživanja uz pomoć lokalnog modela.

Ovo je koristan LLMOps dokaz jer samo promena modela ne definiše istraživački sistem. Pretraga, pribavljanje izvora, klasifikacija dokaza i trajno poreklo su nezavisni operativni artefakti.

Implementacija namerno tretira semantičku sličnost kao otkrivanje, a ne kao dokaz, pokazujući zašto LLMOps observabilnost treba da razlikuje ponašanje pretrage od validnosti tvrdnji.

Uobičajeni režimi neuspeha u LLMOps-u

Uobičajene zablude

Praktičan redosled dizajna LLMOps-a

Kontrolna lista arhitekture LLMOps-a

Rubni slučajevi i ograničenja

Jednostavna aplikacija koja poziva jedan fiksni hostovani model bez pretrage ili alata može zahtevati samo lagani LLMOps: verzionisani kod uputstava, evaluacije, fiksiranje modela, osnovno praćenje i nadgledanje provajdera.

Samostalno hostovani fino podešeni model može zahtevati skoro pun klasični MLOps stek plus LLM-specifičnu evaluaciju aplikacije, čineći granicu između MLOps-a i LLMOps-a namerno zamućenom.

Platforma agenata može imati minimalne operacije obuke modela, ali značajne runtime operacije jer se neuspesi javljaju u izboru alata, stanju i orkestraciji.

Sistem sa puno RAG-a može biti operativno dominiran unosom dokumenata i kvalitetom pretrage, a ne posluživanjem modela.

Terminologija će nastaviti da se razvija. Trajno arhitektonsko pitanje nije koja oznaka „Ops“ pobeđuje, već koji artefakti proizvode ponašanje i stoga moraju biti verzionisani, evaluirani, posmatrani i upravljani.

Šta bi promenilo ovaj odgovor?

Ako provajderi osnovnih modela standardizuju savršeno stabilno ponašanje modela i dugoročnu podršku verzijama, upravljanje provajderima/snimcima moglo bi postati operativno manje značajno.

Ako aplikacije sve više preuzimaju fino podešavanje ili obuku, klasične MLOps brige ponovo postaju centralne.

Operativni princip bi ostao: svaka komponenta koja može materijalno da promeni produkcijsko ponašanje pripada lozi, testiranju, observabilnosti i kontroli promena.

Povezano kanonsko znanje

LLMOps se nalazi ispod AI upravljanja i arhitekture preduzeća AI: upravljanje definiše koje promene zahtevaju dokaz i odobrenje, dok LLMOps pruža operativnu mašineriju za verzionisanje, evaluaciju, raspoređivanje i posmatranje tih promena.

Inženjering konteksta i RAG su operativni poddomeni unutar mnogih LLM aplikacija jer kontekst i pretraga mogu promeniti ponašanje nezavisno od modela.

Agentni AI proširuje LLMOps dalje u operacije trajektorije, dozvola i runtime-a alata.

Često postavljana pitanja

Pojmovnik

Zaključak

MLOps i LLMOps dele isti inženjerski cilj: učiniti AI sisteme dovoljno reproduktivnim, dovoljno testabilnim i dovoljno opservabilnim da pouzdano rade u produkciji.

Razlika je u obliku sistema. Klasični MLOps se često fokusira na obuku i serviranje artefakata modela; LLMOps mora upravljati bihevioralnim stekom u kojem se snimci modela, promptovi, kontekst, pretraga, alati, dozvole i provajderi mogu menjati nezavisno.

Najkraće korisno pravilo je: verzionisati, evaluirati i posmatrati sve što može materijalno promeniti ponašanje LLM aplikacije — ne samo model.

Primarni izvori i trenutna dokumentacija

Izvori u nastavku postavljaju MLOps osnovu i trenutne operativne obrasce za LLM i agentske aplikacije. Projektni odeljci su originalni dokazi implementacije i namerno su uži od tvrdnji o kompletnoj LLMOps platformi.