Sef: "Neko je napravio snimak ekrana!" Bezbednosni tim: "Primljeno, odmah proveravamo nevidljivi vodeni zig."
Video sam jedan veoma zanimljiv članak mog prijatelja why-ja, o nevidljivom vodenom zigu. Zaposleni, obavezno pazite kada pravite snimke ekrana.
Nastojte da ne šaljete originalnu sliku.
Možete je preraditi.
Na primer, fotografisanjem telefonom, a zatim pretvaranjem u jednokadrovski GIF; ili dajte snimak ekrana AI-ju, napišite HTML stranicu koja reprodukuje sadržaj snimka ekrana, a zatim napravite snimak ekrana te HTML stranice.
Šta je zapravo nevidljivi vodeni zig?
Kako radi nevidljivi vodeni zig?
Zašto pretvaranje u jednokadrovski GIF i reprodukcija HTML stranice uklanjaju nevidljivi vodeni zig?
Verujem da su mnogi znatiželjni, uključujući i mene, želim da istražim. U ovom članku ćemo preći temu iz ugla intervjua. Takođe sam prikupio nekoliko pitanja sa NetEase intervjua za razvoj AI aplikacija, i delim vam ih sa odgovorima.
(Tekst je prilično opsežan, garantujem da ćete naučiti mnogo. Vežite sigurnosne pojaseve, krećemo.)
content
01. Šta je zapravo nevidljivi vodeni zig?
Prvo pitanje starog Vanga je bilo prilično direktno: „Da li znate šta je nevidljivi vodeni zig?"
Odgovorio sam: „Nevidljivi vodeni zig, jednostavno rečeno, jeste skrivanje informacija u slici koje ljudsko oko ne može da vidi."
„Glavna svrha je praćenje porekla snimka ekrana — u internim sistemima (alatkama za razgovor) svaki zaposleni dobija jedinstveni identifikator. Ako dođe do curenja, jednim pregledom se otkrije ko je odgovoran."
Stari Vang je nastavio: „Kako šef zna da je neko napravio snimak ekrana?"
„Prvo, detekcija akcije snimanja ekrana u realnom vremenu. Interni sistemi preduzeća mogu na frontendu da otkriju ponašanje snimanja ekrana. Čim se otkrije akcija snimanja, frontend odmah prijavljuje backendu, a backend obaveštava administratora."
„Naravno, ako ne koristite interni softver za snimak ekrana, već snimite telefonom, to se ne može otkriti."
„Drugo je naknadno praćenje porekla. Neki zaposleni napravi snimak ekrana i pošalje ga u WeChat grupu, Moments, ili Maimai. Sistem za praćenje javnog mnjenja to uhvati. Bezbednosni tim dobije tu procurilu sliku, zatim koristi odgovarajući algoritam za dekodiranje da uradi inverznu transformaciju — radi DCT ili DWT transformaciju slike, izdvaja ugrađene informacije iz koeficijenata učestanosti i dekodira ID zaposlenog. Ceo proces je sličan šifrovanju i dešifrovanju — samo sa ključem se može izvući. Kada se izvuče i uporedi, odmah je jasno ko je napravio snimak."
Stari Vang klimnu glavom: „Da li razumete princip nevidljivog vodenog ziga?"
Najklasičniji je metod zasnovan na transformaciji frekvencijskog domena, kao što su diskretna kosinusna transformacija DCT i diskretna talasna transformacija DWT.
Princip je prevođenje slike iz prostornog u frekvencijski domen i ugrađivanje informacija vodenog ziga u koeficijente srednje učestanosti.
Zato što niske učestanosti nose glavni vizuelni sadržaj slike, izmene bi bile uočljive golim okom; visoke učestanosti lako se gube pri kompresiji i skaliranju; srednje učestanosti ne utiču na vizuelni efekat, a imaju i izvesnu otpornost na napade.
Postoji i klasa metoda zasnovana na najnižem značajnom bitu LSB. Najniži bit RGB vrednosti svakog piksela ima gotovo nikakav vizuelni uticaj; ugradnjom informacija vodenog ziga u najniži bit, golim okom se to uopšte ne vidi. Ali ovaj metod nestaje već pri blagoj kompresiji.
„Da upotrebim poređenje, LSB je kao kada na papiru olovkom napišete jedan red 'Chenmo Wang Er je ljut', a gumicom se obriše i nestane. Vodeni zig u frekvencijskom domenu je više kao da u čašu vode kapnete nekoliko kapi tinte — ne možete da odvojite tintu od vode."
02. Zašto pretvaranje u jednokadrovski GIF i HTML reprodukcija uklanja nevidljivi vodeni zig?
Stari Vang je odmah postavio: „Zašto pretvaranje u jednokadrovski GIF i HTML reprodukcija uklanja nevidljivi vodeni zig?"
„Prvo o GIF-u. GIF format ima jedno kobno ograničenje — podržava samo 256 boja. Originalni snimak ekrana je 24-bitna boja, oko 16,77 miliona boja. Prilikom konverzije u GIF, sistem mora da komprimuje tih 16,77 miliona boja na 256."
„Ovaj proces se zove kvantizacija boja. Razlog zašto je vodeni zig frekvencijskog domena nevidljiv jeste što menja razlike u koeficijentima učestanosti. Kvantizacija boja direktno uklanja te razlike, pa vodeni zig prirodno prestaje da važi."
Stari Vang razmisli: „A HTML reprodukcija?"
Rekao sam: „HTML reprodukcija je još brutalnija — ne dira originalnu sliku."
„Preduslov za detekciju nevidljivog vodenog ziga je da podaci originalnih piksela moraju postojati. Koliko god algoritam bio genijalan, detekciona strana uvek mora da dobije matricu piksela slike ili tok karaktera, a zatim u tim podacima traži karakteristike vodenog ziga. Ali HTML reprodukcija ponovo opisuje sadržaj slike na HTML/CSS način, generišući nešto novo što izgleda isto kao original, ali je potpuno drugačije ispod površine."
„Ekvivalentno falsifikatu, koji nema nikakve veze sa nevidljivim vodenim zigom originala."
Stari Vang udari po stolu: „U redu, ovo je prilično jasno. Promenimo pravac. Da li znate razliku između SSE i Streamable HTTP?"
03. Koja je razlika između SSE i Streamable HTTP?
„SSE je mehanizam kojim server šalje podatke klijentu. Njegova suština je duga konekcija — klijent pošalje HTTP zahtev, server drži tu konekciju otvorenom i neprekidno šalje podatke klijentu. Format podataka koristi data: prefiks, razdvaja se sa \n\n. Pretraživač koristi EventSource API za prijem."
„Streamable HTTP je prenosni metod koji definiše MCP protokol, on nema direktne veze sa SSE-om. Njegove ključne karakteristike su:"
„Prvo, arhitektura sa jednim endpointom. Jedan HTTP endpoint istovremeno podržava POST i GET. POST se koristi za slanje zahteva, GET za prijem strimovanog odgovora."
„Drugo, strimovani odgovor koristi HTTP chunked transfer encoding. U zaglavlju odgovora se postavlja Transfer-Encoding: chunked, server šalje podatke u blokovima, a klijent ih obrađuje tokom prijema."
„Treće, podržava stateless primenu. Svaki zahtev je nezavisna HTTP konekcija, server ne mora da održava dugu konekciju."
04. Kada duge konekcije prestaju da važe?
Stari Vang nastavi: „Kada duge konekcije prestaju da važe?"
„Prvo, Keep-Alive ograničenje. Podrazumevano, konekcija prestaje da važi nakon 5 sekundi mirovanja, ili se prisilno zatvara nakon 100 zahteva."
Keep-Alive: timeout=5, max=100
„Drugo, server je aktivno zatvara. Kada su resursi servera ograničeni, on aktivno čisti konekcije u mirovanju. Na primer, u upravljanju bazom konekcija, LRU strategija će prvo osloboditi one koje najduže nisu korišćene."
Stari Vang reče: „Dobro, razmišljate prilično sveobuhvatno. Kada radite AI aplikacije, kako dizajnirate šemu autentifikacije?"
05. Kako dizajnirati šemu autentifikacije, u vezi sa Claude Code
„Kompletna šema autentifikacije mora da reši tri problema: ko ste vi (autentifikacija), šta možete da radite (autorizacija) i kako se vaši akreditivi prenose i osvežavaju."
„Konkretno za Claude Code, on koristi OAuth 2.0 tok autorizacionog koda. Pri prvom pokretanju CLI-ja, korisnik može izabrati da otvori pretraživač i pređe na Anthropic-ovu stranicu za autorizaciju. Nakon što odobri pristup, CLI dobija kratkoročni autorizacioni kod, koji zatim zamenjuje za access token i refresh token."
„Claude Code ima dve vrste akreditive: OAuth Token počinje sa sk-ant-oat01- i vezan je za Pro/Max pretplatu naloga Claude.ai, pozivi se uračunavaju u pretplatnički limit. API Key počinje sa sk-ant-api03-, dolazi iz Anthropic Console i naplaćuje se po potrošnji tokena."
Stari Vang reče: „Pošto pominjete HTTP, koje delove sadrži HTTP zahtev?"
06. Šta sadrži HTTP? Koja polja imaju zaglavlje zahteva?
Rekao sam: „HTTP poruke se dele na poruke zahteva i poruke odgovora, struktura je tri dela: početni red, zaglavlje i telo."
„Početni red poruke zahteva sadrži tri stvari: metodu zahteva (GET, POST, PUT, DELETE itd.), URL zahteva i verziju HTTP-a."
„Zaglavlje je parovi key-value, evo nekoliko ključnih polja zaglavlja zahteva:"
„Host je obavezan, navodi domen i port ciljnog servera. Content-Type govori serveru format tela zahteva, kao što su application/json, multipart/form-data. Authorization nosi informacije o autentifikaciji, najčešće u formatu Bearer <token>."
„Accept govori serveru koje formate odgovora klijent može da obradi. User-Agent identifikuje tip klijenta. Cookie nosi kolačiće koje je server prethodno postavio. Cache-Control kontroliše strategiju keširanja."
„Polje Connection je zanimljivo, HTTP/1.1 je podrazumevano keep-alive."
„Telo je stvarno preneti podatak; GET zahtev obično nema telo, telo POST/PUT zahteva su podaci koji se šalju."
Stari Vang upita: „Da li poznajete JWT?"
07. Od čega se sastoji JWT? Koje probleme Cookie-a i Session-a rešava?
Rekao sam: „JWT je skraćenica za JSON Web Token, sastoji se od tri dela, razdvojena tačkom: Header.Payload.Signature."
„Header je zaglavlje, deklariše tip tokena (fiksno JWT) i algoritam potpisa (na primer HS256 ili RS256). Payload je sadržaj, sadrži stvarne podatke, kao što su ID korisnika, vreme isteka, informacije o dozvolama. Signature je potpis, koristi algoritam deklarisan u Header-u da potpiše Header i Payload, sprečavajući izmenu."
„I Header i Payload su Base64 kodirani. Bezbednost leži u Signature-u — sve dok ključ servera ne procuri, token se ne može falsifikovati."
Stari Vang nastavi: „Zbog čega je JWT nastao?"
Rekao sam: „Suštinski, da reši bolne tačke Session-a u distribuiranim scenarijima."
„Tradicionalno rešenje je Cookie+Session: nakon što se korisnik prijavi, server kreira Session objekat u memoriji i vraća Session ID kroz Cookie pretraživaču. Pri svakom sledećem zahtevu, pretraživač automatski šalje Cookie, a server pronalazi odgovarajući Session prema Session ID-u."
„Ovo rešenje je u redu u jednostrukom okruženju, ali u distribuiranom postaje problem. Korisnikov prvi zahtev ide na server A, Session se čuva na A; drugi zahtev ide na server B, B nema taj Session i korisnik biva odjavljen."
„Rešenja su dve vrste, kao što su deljenje Session-a pomoću Redis centralizovanog skladišta, ili Nginx koji fiksira zahteve istog korisnika na isti server."
„Pristup JWT-a je potpuno drugačiji — direktno kodira korisničke informacije u token, server ne mora da čuva nikakvo stanje. Pri svakom zahtevu, server samo proverava da li je potpis legalan i da li je token istekao. Prirodno podržava distribuirano okruženje, ne zahteva deljeno skladište."
„Ali JWT ima i cenu: prvo, token se ne može aktivno poništiti, osim ako se ne uvede mehanizam crne liste; drugo, u Payload se ne smeju stavljati osetljivi podaci, jer svako može da ga dekoduje."
08. U Multi-Agent projektima, kako se implementira poziv alata?
Stari Vang promeni pravac: „Kako se implementira poziv alata u Multi-Agent projektima?"
„Suštinski proces je četiri koraka: definisanje alata → odlučivanje LLM-a → izvršenje alata → vraćanje rezultata."
„Prvi korak, definisanje alata. Svaki alat zahteva JSON Schema koja opisuje naziv, funkciju i tipove ulaznih parametara alata. Na primer, alat za pretragu — name je web_search, description je 'pretraživanje informacija na internetu', inputSchema definiše polje query, tip je string."
„Drugi korak, odlučivanje LLM-a. Pitanje korisnika i opisi svih dostupnih alata šalju se zajedno LLM-u; LLM procenjuje da li treba pozvati alat, koji alat i sa kojim parametrima. LLM ne vraća tekst, već strukturu tool_call koja sadrži naziv alata i parametre."
„Treći korak, izvršenje alata. Agent okvir preuzima tool_call, rutira ga do odgovarajuće funkcije alata i izvršava stvarnu operaciju — to može biti slanje HTTP zahteva, upit u bazu podataka, čitanje datoteke, bilo šta."
„Četvrti korak, vraćanje rezultata. Rezultat izvršenja alata ubacuje se nazad u kontekst razgovora, ponovo se poziva LLM i na osnovu rezultata alata generiše konačan odgovor. Ako jednom nije dovoljno, LLM može uzastopce pozivati više alata, formirajući ReAct petlju."
Stari Vang nastavi: „Kako se koordinira više Agenta u Multi-Agent scenariju?"
Rekao sam: „U Multi-Agent scenariju postoje dva uobičajena paterna. Jedan je hijerarhijski — postoji Agent-koordinator koji prima zahtev korisnika, raščlanjuje zadatak i distribuira ga različitim izvršnim Agentima. Svaki izvršni Agent ima svoj nezavisni skup alata, na primer jedan je zadužen za pretragu, jedan za izvršavanje koda, jedan za analizu podataka."
„Drugi je peer-to-peer — više Agenta komunicira preko magistrale poruka, bez jasne hijerarhije. Svaki Agent objavljuje šta može da uradi, drugi ga pozivaju po potrebi. Ovo je fleksibilnije, ali je i trošak koordinacije veći."
09. koje protokole podržava MCP?
Stari Vang upita: „Upravo ste pomenuli MCP. koje protokole prenosa podržava MCP?"
Rekao sam: „Trenutna specifikacija MCP-a definiše dva standardna načina prenosa: stdio i Streamable HTTP."
„stdio je najjednostavniji i najčešći, pogodan za lokalne alate. Agent i MCP Server rade na istoj mašini i komuniciraju preko standardnog ulaza/izlaza. Prednosti su nula konfiguracije i snažna interakcija; nedostaci su da ne podržava udaljene pozive niti istovremenost."
„Streamable HTTP je preporučeno rešenje za udaljene scenarije."
Stari Vang zadovoljno klimnu glavom: „Da li poznajete RAG?"
10. Da li poznajete tok rada RAG-a?
Rekao sam: „Poznajem, RAG je Retrieval-Augmented Generation."
„Tok rada je u dve faze: faza indeksiranja i faza upita."
„U oflajn fazi se rade tri stvari: prikupljanje dokumenata → segmentacija teksta → vektorizacija i skladištenje. Originalni dokumenti (PDF, Word, web stranice itd.) se dele na chunk-ove odgovarajuće veličine, svaki chunk se pomoću Embedding modela pretvara u vektor i čuva u vektorskoj bazi podataka."
„U fazi upita su takođe tri koraka: vektorizacija upita → pretraga po sličnosti → poboljšana generacija. Nakon što korisnik postavi pitanje, pitanje se takođe pretvara u vektor, u vektorskoj bazi podataka se radi ANN (približni najbliži sused) pretraživanje, pronalazi se nekoliko najrelevantnijih chunk-ova, oni se kao kontekst ubacuju u prompt i zajedno šalju velikom modelu radi generisanja odgovora."
„U stvarnom inženjerskom radu postoji nekoliko ključnih tačaka optimizacije. Strategija segmentacije Chunk-a je veoma važna — preveliki chunk gubi semantiku i pretraga je neprecizna, premali chunk gubi kontekst. Obično se koristi 512-1024 tokena po chunk-u, sa 20% preklapanja."
„Takođe, Rerank. Rezultati vektorske pretrage nisu nužno optimalni, jer semantička sličnost nije isto što i relevantnost pitanja. Dodavanje Reranker modela za sekundarno sortiranje može efikasno poboljšati kvalitet odziva."
11. Zašto se pojavio Transformer?
Stari Vang reče: „Razgovarajmo o osnovama. Zašto se pojavio Transformer?"
Rekao sam: „Mora se krenuti od prethodnika velikih modela."
„Pre pojave Transformera, glavni metod obrade teksta bio je RNN (rekurentna neuronska mreža). Njegova ideja je: rečenica se čita reč po reč, nakon što se pročita prethodna, tek onda sledeća — kao čovek koji čita knjigu."
„Ovaj pristup ima jedan kobni problem — previše je spor. Zato što mora redom, ne može paralelno. GPU je najbolji u paralelnom računanju, RNN uopšte ne može da iskoristi tu prednost."
„Postoji i veći problem: kada se pročita dalje, sadržaj od ranije se uglavnom zaboravi. Na primer, članak od nekoliko hiljada reči — kada se pročita poslednja rečenica, informacija iz prve rečenice je odavno razblažena u procesu prenosa. To je takozvani 'problem zavisnosti na velikoj udaljenosti'."
„Kasnije je neko predložio LSTM (mreža dugog i kratkoročnog pamćenja), dodao 'mehanizam kapije' — jednostavno rečeno, model je dobio prekidač za pamćenje, važne informacije se zadržavaju duže, nevažne se mogu ranije zaboraviti. To je do izvesne mere ublažilo zavisnost na velikoj udaljenosti, ali suštinski je i dalje obrada po redosledu, pa problem brzine nije rešen."
„2017. godine Google je objavio rad pod naslovom 'Attention is All You Need' i predložio Transformer arhitekturu. Suština je u jednoj rečenici: odbacimo rekurentnu strukturu, zadržimo samo mehanizam pažnje."
Stari Vang reče: „Šta je zapravo mehanizam pažnje?"
Rekao sam: „Da upotrebim poređenje, RNN je kao učenik koji vodi beleške — nastavnik kaže šta, on to zapisuje, a do kraja zaboravi početak. Mehanizam pažnje je kao odličan učenik koji podrvljava glavno — nakon što pročita ceo članak, zna koje su rečenice ključne i posvećuje im posebnu pažnju."
Kako se konkretno implementira?
„Svaka reč generiše tri vektora:"
„- Query (vektor upita): šta tražim"
„- Key (vektor ključa): šta imam za podudaranje"
„- Value (vektor vrednosti): stvarni sadržaj koji nosim"
„Zatim se Query svake reči podudara sa Key svake reči, izračunava se rezultat relevantnosti, i oni sa visokim rezultatom se više prate. Na kraju se koriste ti rezultati za izračunavanje ponderisanog zbira svih Value-a."
„Ovo donosi tri prednosti: prvo, sve reči se mogu obraditi istovremeno, GPU paralelizam je maksimalno iskorišćen, brzina obuke polete. Drugo, bez obzira na dužinu rečenice, udaljenost između bilo koje dve reči je jedan korak, nema problema 'prenosim-prenosim pa zaboravim'. Treće, nakon vizualizacije težina pažnje može se viditi na koje reči model obraća pažnju, što olakšava otklanjanje grešaka."
„Sada su svi veliki modeli zasnovani na Transformer arhitekturi."
12. Visoka cena primene modela za uzak domen — destilacija ili kvantizacija?
Stari Vang postavi poslednje pitanje: „Pretpostavimo da imate model za uzak domen i da je cena primene veoma visoka; da biste smanjili troškove, da li biste izabrali destilaciju ili kvantizaciju?"
Rekao sam: „Ove dve stvari rešavaju različite probleme."
„Destilacija znači da veliki model 'podučava' mali. Veliki model (koji se zove Teacher) ne govori malom modelu (koji se zove Student) samo koji je tačan odgovor, već mu takođe govori 'smatram da je opcija A 80% verovatno tačna, opcija B 15%, opcija C 5%'. Ova distribucija verovatnoće zove se 'meke oznake' i sadrži način razmišljanja velikog modela."
„Da upotrebim poređenje, veliki model je kao nastavnik — ne samo da kaže učeniku da je odgovor A, već mu i objasni zašto treba izabrati A, a ne B. Učenik razume pristup i sledeći put kada naiđe na slično pitanje, takođe može da odgovori tačno."
„Efekat kompresije destilacije je veoma dobar — može se komprimovati sa 70 milijardi parametara na 7 milijardi, obim se direktno smanji za jedan red veličine. Cena je da zahteva ponovno treniranje, potrebni su podaci, računarska snaga i vreme. Destilovana verzija DeepSeek-a nastala je tako, koristili su DeepSeek-R1 kao Teacher za treniranje malog modela."
„Kvantizacija, jednostavno rečeno, jeste 'smanjenje preciznosti'. Parametri modela se inače čuvaju kao 32-bitni brojevi u pokretnom zarezu, menjaju se u 8-bitne cele brojeve ili čak 4-bitne cele brojeve. Smanjenjem preciznosti brojeva, smanjuju se i troškovi skladištenja i izračunavanja."
„Na primer, model Llama 3 8B:"
„- FP32 (32-bitni pokretni zarez): zahteva oko 32GB memorijske"
„- Int8 (8-bitni celi broj): zahteva samo oko 8GB"
„- Int4 (4-bitni celi broj): zahteva samo oko 4GB"
„Stepen kompresije može dostići 75%-90%, i nije potrebno ponovno treniranje, dovoljno je direktno konvertovati gotov model. Nedostatak je pad preciznosti — što je manji broj bitova, to je pad veći."
Stari Vang nastavi: „Kako onda izabrati?"
Rekao sam: „Gledam tri dimenzije."
„Vremenska dimenzija: za hitno lansiranje izaberite kvantizaciju, brzo je."
„Dimenzija preciznosti: za medicinu, pravo i slično gde mora biti apsolutno tačno, destilacija je stabilnija. Za opšte odgovore na pitanja, korisničku podršku i sl., gubitak precizne Int8 kvantizacije je uglavnom prihvatljiv."
„Dimenzija resursa: sa GPU klasterom i označenim podacima, odnos uloženog i dobijenog je povoljniji za destilaciju. Sa samo serverom za izvođenje, kvantizacija je jedina opcija."
„Optimalno rešenje je kombinovana upotreba: prvo destilacijom dobiti model odgovarajuće veličine, a zatim kvantizacijom dalje kompresovati."
Kraj
Ranije smo pisali CRUD, sada moramo da razumemo protokole, modele, Agente i inženjerstvo.
[Trebalo bi naučiti sve više i više stvari, ali sve dok zadržimo radoznalost i želju za znanjem prema ovom svetu, preći ćemo iz straha u uživanje.]
Imamo priliku da stojimo na talasu razvoja AI-ja, svedočimo i učestvujemo u najuzbudljivijoj tehnološkoj revoluciji ovog doba. Iako izazova nije malo, mogućnosti su neograničene.
Napred, prijatelji.
Vidimo se u sledećem.