Generativna veštačka inteligencija objašnjena: modeli, pretraga, alati i aplikacije nisu ista stvar

Generativna veštačka inteligencija nije jedna komponenta. Produkcijski generativni AI sistem obično kombinuje generativni model sa aplikativnim kodom koji obezbeđuje instrukcije i kontekst, pronalazi eksterno znanje kada je potrebno, izlaže alate za čitanje ili menjanje eksternih sistema, upravlja stanjem izvršavanja i dozvolama i pretvara rezultat u upotrebljiv proizvod. Tretiranje modela, pronalaženja, alata, konteksta, izvršnog okruženja i aplikacije kao iste stvari skriva granice koje određuju svežinu, bezbednost, pouzdanost, cenu i kontrolu.

Šta zapravo znači „generativna veštačka inteligencija“?

Na nivou modela, generativna veštačka inteligencija odnosi se na AI modele koji generišu izvedeni sintetički sadržaj kao što su tekst, slike, zvuk, video, kod ili drugi digitalni izlaz. NIST AI 600-1 koristi ovo značenje usmereno na model i odvojeno razmatra rizike na nivou modela, sistema, aplikacije i slučaja upotrebe.

Ta razlika je važna jer AI model nije isto što i kompletan AI sistem. NIST-ov trenutni rečnik definiše AI model kao komponentu koja proizvodi izlaze iz ulaza koristeći računske, statističke ili tehnike mašinskog učenja, dok AI sistem može uključivati softver, hardver, aplikacije, alate ili uslužne programe koji rade koristeći AI.

Najjednostavniji korisni model generativnog AI sistema

Za prvi mentalni model, zamislite korporativnog asistenta koji odgovara: „Može li ovaj kupac danas dobiti povraćaj?“ Koristan odgovor može zahtevati nekoliko različitih odgovornosti. Jezički model može interpretirati pitanje i napisati objašnjenje, ali trenutno stanje porudžbine može doći iz alata baze podataka, politika povraćaja može doći iz pronalaženja dokumenata, dozvole može sprovoditi aplikacija, a konačna radnja može zahtevati kontrolisani API poziv.

Stvarni sistemi ne prate uvek tačno ovaj redosled. Pronalaženje se može desiti pre prvog poziva modela, alati se mogu birati tokom agentske petlje, deterministička aplikativna logika može potpuno zaobići model, a validacija se može desiti u nekoliko faza. Poenta je razdvojiti odgovornosti, a ne nametnuti jedan univerzalni tok rada.

Šest granica koje su važne

1. Model: generisanje je njegova osnovna odgovornost

Generativni model preslikava dostavljene ulaze u generisane izlaze. Za jezički model to može uključivati tekst na prirodnom jeziku, strukturirani JSON, kod, klasifikacije, rezimee, planove ili argumente poziva alata. Multimodalni generativni modeli mogu raditi sa dodatnim tipovima ulaza i izlaza.

Model može sadržati značajno naučeno znanje u svojim parametrima, ali parametrizovano znanje nije živa baza podataka. Model ne zna automatski za dokument kreiran pre pet minuta, trenutni nivo zaliha, privatni zapis kupca ili stanje aplikacije osim ako se ta informacija ne dostavi kroz trenutnu ulaznu putanju.

Zato promena modela ne rešava automatski zastarelo znanje, nedostajuće dozvole, pokvareno pronalaženje, pogrešno vlasništvo nad stanjem ili nesigurno izvršavanje alata. Ti kvarovi često pripadaju drugim slojevima.

2. Pretraga: pronalaženje spoljnih dokaza je zasebna operacija

Pretraga bira informacije iz spoljnog izvora pre ili tokom generisanja. Rad o generisanju uz pomoć pretrage iz 2020. godine autora Lewis i saradnika učinio je tu razdvojenost eksplicitnom kombinovanjem parametarskog generativnog modela sa preuzetom neparametarskom memorijom. Savremeni produkcioni sistemi koriste mnoge varijante pretrage, ali arhitektonska ideja ostaje: korisni dokazi mogu se dohvatiti u vreme izvođenja zaključivanja umesto da se oslanjamo samo na ono što je model naučio tokom obuke.

Pretraga može koristiti leksičku pretragu, ugrađivanja, vektorsku pretragu, hibridnu pretragu, SQL, grafove znanja, filtere metapodataka, API-je ili druge mehanizme selekcije. Vektorska baza podataka je stoga jedna moguća komponenta pretrage, a ne definicija RAG-a.

3. Alati: pristup i radnja nisu znanje modela

Alat je interfejs preko kojeg AI okruženje za izvršavanje može zatražiti funkcionalnost izvan modela. Alat može upitovati bazu podataka, pretraživati veb, čitati datoteku, izračunati vrednost, pozvati interni servis, kreirati tiket, poslati poruku, izmeniti zapis ili pokrenuti drugu kontrolisanu operaciju.

OpenAI-jeva trenutna dokumentacija o pozivanju funkcija eksplicitno ističe ovu granicu: pozivanje funkcija omogućava modelima da se povežu sa spoljnim sistemima i pristupe podacima ili radnjama koje pruža aplikacija. Model može predložiti ili izabrati poziv, ali spoljni sistem obavlja stvarnu operaciju.

Upotreba alata stoga stvara dva odvojena pitanja: Može li model zatražiti ovu sposobnost? i Hoće li aplikacija odobriti i izvršiti je? Produkcioni sistem ne bi trebalo da meša nameru modela sa dozvolom da izazove sporedni efekat.

4. Kontekst: šta model može videti upravo sada

Kontekst su informacije dostupne modelu za određeni korak zaključivanja. Anthropic-ove smernice za inženjering konteksta opisuju kontekst kao skup tokena uključenih pri uzorkovanju iz LLM-a. U praksi, taj skup može sadržati sistemska uputstva, korisničke poruke, istoriju razgovora, preuzete dokaze, definicije alata, rezultate alata, sažetke memorije i izabrano stanje aplikacije.

Kontekst stoga nije ni kompletna baza znanja ni dugoročna memorija. Kompanija može čuvati deset miliona dokumenata dok samo nekoliko odlomaka ulazi u jedan poziv modela. Okruženje za izvršavanje može čuvati godinu dana istorije razgovora dok izlaže samo delove potrebne za trenutni zadatak.

Kontekstni prozor takođe stvara inženjersko ograničenje. Dodavanje više teksta ne garantuje bolji odgovor; irelevantne, zastarele, kontradiktorne ili informacije niskog autoriteta mogu razblažiti dokaze koji su zaista važni.

5. Okruženje za izvršavanje i orkestracija: koordinisanje petlje

Sloj okruženja za izvršavanje ili orkestracije koordinira kako model učestvuje u zadatku. U zavisnosti od arhitekture, može upravljati sesijama, zahtevima modela, otkrivanjem alata, petljama pozivanja alata, ponovnim pokušajima, predajama, događajima strimovanja, istekima vremena, kontrolnim tačkama, sažimanjem ili okruženjima za izvršavanje.

Neka okruženja za izvršavanje su tanki aplikacijski kod oko API-ja modela. Druga su potpuni agentni okviri. Upravljano okruženje dobavljača može posedovati deo petlje dok aplikacija i dalje poseduje domen istine, autorizaciju, poslovne sporedne efekte i životni ciklus proizvoda.

Ova granica je važna jer su to gde se izvršava okruženje i gde se izvršava zaključivanje odvojene odluke. Lokalno pokrenut klijent ili agentni proces i dalje može pozivati udaljeni model, dok udaljena aplikacija može pozivati model hostovan na infrastrukturi pod kontrolom organizacije.

6. Aplikacija: gde AI postaje proizvod

Aplikacija je granica proizvoda oko AI komponenti. Ona poseduje korisničko iskustvo, domenski model, trenutno stanje, identitet, opseg zakupca, dozvole, perzistenciju, integracije servisa, validaciju, observabilnost, logiku naplate ili kvota gde je relevantno, i pravila koja određuju šta AI sme da vidi ili radi.

Ovo je sloj koji pretvara „model može da proizvede koristan izlaz“ u „sistem može da isporuči pouzdanu sposobnost.“ Isti model može da učestvuje u privatnom istraživačkom asistentu, korisničkom toku podrške, kodnom agentu ili aplikaciji za trgovinu jer okolna aplikacija menja podatke, alate, politike, stanje i ugovor o izvršavanju.

Kako delovi rade zajedno u stvarnom zahtevu

Razmotrimo asistenta za podršku upitanog: „Refundiraj porudžbinu 4711 ako je još uvek podobna, i objasni zašto.“ Zahtev kombinuje znanje, trenutno stanje, autorizaciju, rezonovanje i sporedni efekat.

Ako asistent ima samo jezički model, može da diskutuje o refundacijama ali ne može bezbedno da zna da li je porudžbina 4711 trenutno podobna ili da izvrši transakciju. Ako ima samo preuzimanje, može da pronađe politiku ali mu i dalje nedostaje stanje porudžbine uživo. Ako ima alate bez autorizacije aplikacije, može postati sposoban ali nesiguran. Pouzdanost dolazi iz komponovanja slojeva sa eksplicitnim vlasništvom.

Različiti AI proizvodi koriste različite kombinacije

Ovo su arhitektonski obrasci, a ne rangiranje zrelosti. Funkcija samo sa modelom može biti ispravan dizajn kada zadatak ne zahteva spoljne činjenice ili radnje. Dodavanje preuzimanja, alata, memorije ili agentne petlje opravdano je samo kada zadatak zahteva te sposobnosti.

Dokaz implementacije: Aaasaasa AI Client

Aaasaasa AI Client je lokalno-prvenstveni desktop AI radni prostor izgrađen sa Nuxt 4, Electron i TypeScript. Njegov AI Hub namerno razdvaja agenta/klijenta, provajdera, model, lokaciju izvršavanja, dozvole i web klijenta umesto da ih tretira kao jedno „AI“ podešavanje.

To razdvajanje stvara konkretno ponašanje. Direct Chat može da razgovara sa modelima bez alata za fajl sistem ili shell. Codex agent može da koristi izabrani radni prostor i profil dozvola. Ollama može da obezbedi direktno lokalno zaključivanje, dok LM Studio i konfigurabilni OpenAI-kompatibilni endpointi predstavljaju druge putanje provajdera. Lokalno pokrenut Codex proces i dalje može da koristi cloud model, tako da UI i arhitektura ne izjednačavaju lokalno izvršavanje sa lokalnim zaključivanjem.

Implementacija takođe sadrži Qdrant/vektorsku podršku, mogućnosti ekstrakcije dokumenata i autentifikovani direktorijum MCP broker. Te komponente ilustruju još jednu granicu: infrastruktura za preuzimanje i pristup alatima mogu živeti u istom proizvodu a da ne postanu svojstva samog modela.

Česte greške u kategorizaciji

Načini otkaza kada se granice uruše

Greške u granicama nisu samo terminološki problemi. One stvaraju različite produkcione otkaze koji zahtevaju različita rešenja.

Šta je stabilno, a šta zavisi od verzije?

Arhitektonske razlike u ovom članku su namerno neutralne prema dobavljaču. Trenutni primeri ispod su činjenice o implementaciji koje treba ponovo proveriti kada se API-ji razviju.

Članak koji je izvor istine treba stoga da očuva oba nivoa: stabilne koncepte za arhitekturu i datirane dokaze za trenutne implementacije. Mešanje ova dva čini da članak nepotrebno brzo zastari.

Test granica AI komponenti

Kada procenjujete AI funkciju, postavite sledeća pitanja po redu. Odgovori otkrivaju koje komponente sistem zapravo ima i koje su odgovornosti još uvek implicitne.

Šta generativna AI nije

Generativna AI nije sinonim za LLM, iako su LLM-ovi glavna klasa generativnih modela. Takođe nije sinonim za RAG, vektorsku bazu podataka, agenta, protokol alata, chat UI ili aplikaciju.

Ti koncepti mogu biti povezani, ali svaki odgovara na drugo arhitektonsko pitanje. LLM pita kako se proizvodi jezički izlaz. Pronalaženje pita odakle dolaze eksterni dokazi. Alati pitaju kako se izlažu eksterne sposobnosti. Kontekst pita šta model može da vidi. Runtime pita kako se koordinira izvršavanje. Aplikacija pita kako sposobnost postaje kontrolisan proizvod.

Gde dalje u grafu znanja

Kada su ove granice jasne, dublje teme postaje lakše smestiti. RAG pripada pronalaženju i konstrukciji konteksta. Retrieval Trigger odlučuje kada su eksterni dokazi potrebni. Memorija agenta se tiče onoga što se održava kroz vreme. Pozivanje alata i MCP pripadaju pristupu sposobnostima. Agent harnesses pripadaju runtime orkestraciji. RBAC, izolacija zakupaca i autorizacija domena pripadaju aplikaciji i bezbednosnoj granici platforme.

Ograničenja

Model sa šest slojeva je mapa odgovornosti, a ne zahtev da svaki proizvod implementira šest odvojenih servisa. Mala aplikacija može implementirati konstrukciju konteksta, pretragu i orkestraciju unutar jednog procesa. Upravljana platforma može objediniti nekoliko odgovornosti iza jednog API-ja. Fizičko postavljanje može biti kombinovano dok semantičko vlasništvo ostaje različito.

Terminologija se takođe razlikuje među dobavljačima i u istraživanjima. „Agent“, „runtime“, „memorija“, „alat“, „konektor“ i „kontekst“ mogu biti definisani na različite načine. Definicije ovde su izabrane da učine operativno vlasništvo i dijagnostiku kvarova eksplicitnim, a ne da tvrde da svaki okvir koristi identičan rečnik.

Odeljak Aaasaasa AI Client dokumentuje jedan obrazac implementacije. On pokazuje da su eksplicitne granice praktične, ali ne dokazuje da je isti raspored komponenti optimalan za svaki AI proizvod.

Šta bi promenilo ovaj odgovor?

Mapa odgovornosti bi zahtevala reviziju ako bi same arhitekture modela počele da poseduju autoritativno eksterno stanje, dozvole, trajne transakcione sporedne efekte i verifikovan pristup izvorima kao intrinzične osobine, a ne kao sposobnosti koje pruža okolni sistem. Trenutne produkcijske arhitekture to ne čine bezbednom opštom pretpostavkom.

Pojedinačni primeri implementacije će se promeniti mnogo ranije. Hostovani alati za pretragu, agent API-ji, MCP integracije, funkcije za upravljanje kontekstom i mogućnosti dobavljača se brzo razvijaju. Te detalje treba ažurirati bez urušavanja osnovnih razlika između generisanja, dokaza, pristupa sposobnostima, konteksta, izvršavanja i kontrole aplikacije.

Zaključak

Generativnu AI je lakše dizajnirati kada „AI“ prestane da se tretira kao jedna crna kutija. Model je generativna komponenta, a ne kompletan proizvod. Pretraga pruža eksterne dokaze. Alati izlažu sposobnosti. Kontekst nosi izabrane informacije u trenutnu inferenciju. Runtime koordinira izvršavanje. Aplikacija poseduje autoritativnu granicu proizvoda.

Ta razdvojenost je korisna za više od objašnjenja. Ona govori inženjerima odakle potiču zastarele činjenice, gde pripada autorizacija, zašto lokalni runtime i dalje može da koristi cloud inferenciju, zašto RAG nije isto što i vektorska baza podataka, zašto pozivi alata zahtevaju validaciju i zašto promena modela ne može da popravi svaki sistemski kvar.

Trajno arhitektonsko pitanje stoga nije „Koji AI model koristimo?“ Već: Koju odgovornost poseduje svaka komponenta, koji dokazi prelaze svaku granicu i koji sloj sme da menja stvarno stanje?

Često postavljana pitanja

Pojmovnik

Primarni izvori i dokazi o implementaciji

Stabilne definicije u nastavku su zasnovane na standardima/istraživanjima; primeri implementacije koji se brzo menjaju koriste aktuelnu zvaničnu inženjersku dokumentaciju. Aaasaasa AI Client je dokaz originalne implementacije i proveren je u odnosu na stanje svoje baze koda/dokumentacije od 26. jula 2026.