Java je ponovo mrtva. Iskreno, prestala sam da brojim koji joj je ovo put. Taj narativ se redovno ponavlja negde između teza da svi prelaze na Kotlin, da će Node pojesti backend, da je Python budućnost svega, da će Go zameniti enterprise sisteme, da je Spring dinosaur, pa sve do najnovije epizode u kojoj se tvrdi da će veštačka inteligencija sada sve pisati sama i da nam Java developeri više nisu potrebni.
I onda Java, kao istinski Isus enterprise sveta, uradi ono što radi najbolje. Vaskrsne u novoj verziji, obuče malo moderniji kaput, doda records, pattern matching, virtual threads, još jedan Spring Boot starter i nastavi da stabilno vrti banke, osiguranja, državne sisteme, logistiku, e-commerce i pola onoga što ljudi svakodnevno koriste dok po LinkedInu pišu da je tehnologija zastarela.
Sada smo, prirodno, stigli do faze u kojoj dominira veštačka inteligencija. Ako je verovati internetu, više niko neće pisati kod. Svi ćemo samo izdati glasovnu komandu da nam se napravi aplikacija koja radi sve, sistem će klimnuti glavom i samostalno izgenerisati savršen sistem, testove, dokumentaciju, deployment pipeline, security model, observability i rollback strategiju. Možda će nam usput skuvati i kafu, jer kada već haluciniramo, hajde da haluciniramo do kraja.
Realnost, naravno, nema veze sa tim vizijama. Tehnologija nije zamenila Spring Boot aplikacije, već se integriše u njih. I dalje je neophodan inženjer koji suštinski razume backend, HTTP protokol, bezbednost, podatke, permisije, konfiguraciju, exception handling, rate limit, troškove, arhitekturu i onu malu, neprijatnu stvar koju zovemo ponašanje sistema kada ode na production.
Dobra vest je da ti za najjednostavniju LLM integraciju ne treba doktorat iz mašinskog učenja, tri data scientist stručnjaka i server soba koja zvuči kao avion pred poletanje. Dovoljni su Spring Boot aplikacija, dependency, API ključ, malo konfiguracije i klijent. Loša vest je da to što stvar radi u lokalnom okruženju ne znači da odmah smeš da je pustiš stvarnim korisnicima.
Kako izgleda najprostiji primer u praksi?
Ako se koristi Spring AI, cela priča može da krene prilično jednostavno. Dodaš spring-ai-starter-model-openai dependency, podesiš konfiguraciju, napišeš kontroler koji koristi ChatClient i proces je završen.
Ipak, upravo tada dolazimo do momenta kada pogledaš kod i zapitaš se da li je to zaista sve. Za potrebe demo verzije, odgovor je potvrdan. Za ozbiljan feature u produkciji, naravno da nije i nemojmo se praviti ludi. Ovo je ekvivalent situaciji kada napraviš bazični GET hello endpoint i ponosno izjaviš da imaš gotovu aplikaciju. Imaš je, ali u istom smislu u kom je tvrdnja da poseduješ šporet identična izjavi da si otvorila restoran.
Termini koje moraš znati da zvučiš “AI-smart”
U razvoju ovakvih sistema koristi se nekoliko ključnih koncepata koje svaki backend developer mora da razume pre nego što krene u implementaciju.
Grounding označava proces u kome modelu daješ konkretne podatke iz svog sistema, umesto da ga pustiš da odgovara na osnovu opšte kulture i nasumičnih informacija sa interneta.
RAG koncept predstavlja strategiju gde aplikacija prvo pronalazi relevantne informacije, najčešće iz interne dokumentacije ili baze znanja, pa model generiše odgovor isključivo na osnovu tih selektovanih materijala.
Tool calling ili funkcija poznata kao function calling omogućava modelu da zatraži pozivanje određene funkcije iz tvoje aplikacije, na primer getCustomerStatus ili createTicket. Veoma je važno naglasiti da samu funkciju i dalje izvršava tvoj backend, a ne eksterni model.
Temperature parametar određuje nivo kreativnosti modela. Za zadatke kao što je support ticket classification tebi nije potreban pesnik, već dosadan, predvidiv i stabilan činovnik, zbog čega poslovne aplikacije uglavnom zahtevaju nižu temperaturu rada.
Observability u ovom kontekstu znači da u svakom trenutku tačno znaš koji model je pozvan, koji prompt je poslat, koliko je proces trajao, koliko je tokena potrošeno, koliko je to koštalo, gde je sistem pukao i šta je model vratio kao odgovor. AI poziv je eksterni dependency, a dependency se nikada ne pušta u mrak kao dete na ekskurziju.
Spring AI ili LangChain4j?
Ako već operišeš u Spring Boot svetu, Spring AI se nameće kao najprirodniji prvi izbor. Kroz njega dobijaš prepoznatljivu Spring-style konfiguraciju, ChatClient, strukturisani output, tool calling, RAG sisteme, integracije sa vektorskim bazama podataka i opšti osećaj da se i dalje nalaziš u svom poznatom ekosistemu.
Sa druge strane, LangChain4j predstavlja alternativnu, izuzetno ozbiljnu Java opciju. Ona postaje posebno zanimljiva ako preferiraš deklarativni pristup kroz AI Services, gde definišeš interfejs i opišeš željeno ponašanje, dok framework samostalno kreira implementaciju koja iza scene komunicira sa modelom.
Ako bismo to definisali narodskim jezikom, Spring AI je pokušaj da se veštačka inteligencija uvede u specifičan Spring način razmišljanja. LangChain4j je sa druge strane kreiran sa idejom da Java kao jezik dobije svoj autentičan i ozbiljan LLM toolbox. Oba rešenja imaju jasan smisao na tržištu, ali nijedno od njih ne menja činjenicu da backend i dalje mora savesno da obavlja svoj primarni posao.
Kardinalne greške koje treba izbegavati
Postoji nekoliko stvari koje nikako ne treba raditi prilikom integracije. Ne treba slati modelu celu bazu podataka za svaki slučaj sa idejom da on sam piše i izvršava SQL upite. Ne treba tretirati prompt kao bezbednosni security layer. Ne treba slepo verovati modelu da samostalno donosi odluke o tome šta konkretan korisnik sme da vidi na sistemu. Takođe, nikako ne treba praviti agente koji mogu da izvršavaju akcije bez jasno postavljenih limita, audit loga i obavezne ljudske potvrde za sve osetljive operacije.
Na kraju, ne treba svaki postojeći problem rešavati veštačkom inteligencijom. Nekada ti je u sistemu potreban samo najobičniji, normalan filter. Nekada je rešenje u boljem korisničkom iskustvu i dizajnu interfejsa. Nekada ti prosto treba indeks u bazi podataka da ubrza stvar. Nekada je rešenje da neko konačno sedne i napiše valjanu dokumentaciju. To zvuči dosadno i neprivlačno, ali je živa istina.
Backend kao čuvar granica determinizma
LLM integracija u Spring Boot aplikaciji definitivno više nije naučna fantastika. U svojoj bazičnoj varijanti, ona se svodi na dependency, konfiguraciju, API ključ i ChatClient. Međutim, ozbiljna implementacija se ne ogleda u tome da model samo vrati nekakav odgovor.
Ozbiljna implementacija leži u tome što tačno znaš šta smeš da mu pošalješ, a šta je strogo zabranjeno. Ogleda se u načinu na koji validiraš dobijeni odgovor, kako štitiš osetljive podatke, kako precizno meriš troškove, kako pratiš neočekivane greške i kako sprečavaš da pametni asistent postane najskuplji bug u tvom sistemu.
Nova tehnologija nije zamenila backend developere. Samo nam je donela još jedan specifičan, nedeterministički dependency koji ume da priča, ume drastično da poskupi, ume da zakasni sa odgovorom, izmisli nepostojeće činjenice i napravi ozbiljan incident ako se ostavi bez adekvatnog nadzora. To zvuči kao nešto što nam je baš falilo u životu.
Ipak, ako se koristi pametno, ovaj alat može uspešno da ukloni ogromnu količinu trenja iz poslovnih aplikacija. Može korisnički, prirodni jezik efikasno da prevede u strukturisan zahtev, da obimnu dokumentaciju pretvori u precizan odgovor, sirove podatke u smisleno objašnjenje, a dosadne draftove u upotrebljiv materijal koji čovek posle može lako da doradi.
U toj postavci stvari, backend je tu da računa, validira i čuva čvrste granice sistema, dok je LLM tu da komunicira. Za početak nove ere razvoja, to je sasvim dovoljno.
0 komentara