Gradnja produktov UI, evalvacija in odgovorna uporaba

Cilji

• Poklicati model prek API-ja in razumeti žetone, ceno in omejitve.
• Razumeti RAG in kdaj je boljši od učenja modela (fine-tuning).
• Sestaviti evalvacijski nabor in meriti kakovost, namesto da jo ocenjujemo po občutku.
• Oceniti stroške, varnostna tveganja, zasebnost in obveznosti po Aktu o UI.

Glavna vaja

Zaključni projekt: vsak predstavi lasten sistem UI, ki rešuje realen problem, skupaj z evalvacijo na vsaj desetih primerih, oceno stroškov in kratko oceno tveganj po predlogi z delavnice.

Zakaj ta delavnica

Orodja za vse so dobra za posameznika. Ko pa UI postane del procesa v podjetju, potrebujemo več: sistem, ki pozna naše dokumente, se ga da meriti, stane predvidljivo, ne pušča podatkov in je skladen z zakonodajo. Ta delavnica poveže vse prejšnje in pokaže, kako iz prototipa nastane sistem, ki mu lahko zaupamo. Isto metodo uporabljamo pri lastnem delu z modeli in agenti.

Potek

Čas	Del	Kaj delamo
Pred delavnico	Priprava	Vsak izbere problem in pripravi 10 testnih primerov s pričakovanimi odgovori.
0:00–0:25	API	Klic modela, sistemska navodila, žetoni, cena, izbira modela, strukturiran izhod.
0:25–0:50	RAG in znanje	Iskanje po lastnih dokumentih, razbijanje, vektorsko iskanje, navedbe. RAG ali učenje modela.
0:50–1:15	Evalvacija	Zamrznjen testni nabor, objektivna merila, model kot sodnik, regresije.
1:15–1:25	Odmor
1:25–1:50	Stroški, varnost, zasebnost, Akt o UI	Izračun stroškov, vbrizgavanje pozivov, GDPR, razvrstitev tveganja, preglednost.
1:50–2:10	Dokončanje projekta	Zadnji popravki, evalvacija, priprava predstavitve.
2:10–3:00	Predstavitve	5 minut na udeleženca: problem, sistem, rezultati evalvacije, stroški, tveganja.

Vsebina

API

Namesto klepeta v brskalniku sistem kliče model prek API-ja: pošlje sistemska navodila in sporočila, dobi odgovor. Ključni pojmi:

• Žetoni: model šteje besedilo v žetonih (v slovenščini okvirno dva do tri žetone na besedo). Plačamo vhodne in izhodne žetone.
• Izbira modela: večji modeli so pametnejši in dražji. Za razvrščanje in izvlek pogosto zadošča manjši, za zahtevno sklepanje večji.
• Strukturiran izhod: zahtevamo JSON po shemi, da ga program zanesljivo obdela.
• Ključi: API ključ je geslo. Nikoli v kodo, repozitorij ali brskalnik.

Minimalen primer klica v Pythonu (slog Anthropic SDK; ime modela je placeholder, ključ je v spremenljivki okolja, ne v kodi):

import json
import anthropic

client = anthropic.Anthropic()  # ključ prebere iz spremenljivke okolja

SISTEM = """Razvrščaš zahtevke strank.
Odgovori samo z JSON: {"kategorija": "racun | reklamacija | vprasanje | drugo",
"nujnost": 1, "povzetek": "en stavek"}. Nujnost je celo število od 1 do 3."""

zahtevek = "Naročeni paket je prispel poškodovan, prosim za zamenjavo."

odgovor = client.messages.create(
    model="IME_MODELA",
    max_tokens=300,
    system=SISTEM,
    messages=[{"role": "user", "content": zahtevek}],
)

rezultat = json.loads(odgovor.content[0].text)
print(rezultat["kategorija"], rezultat["nujnost"])
print("vhodni žetoni:", odgovor.usage.input_tokens)
print("izhodni žetoni:", odgovor.usage.output_tokens)

Kaj gledamo: sistemska navodila so ločena od uporabnikovega besedila, izhod je JSON, ki ga program razčleni, in porabo žetonov beremo iz odgovora, da jo lahko pomnožimo v izračunu stroškov. Program mora poskrbeti tudi za primer, ko JSON ni veljaven (ponovni poskus, nato človek).

RAG

RAG (retrieval-augmented generation) pomeni, da sistem pred odgovorom poišče ustrezne dele naših dokumentov in jih da modelu v kontekst. Dokumente razbijemo na odseke, jih indeksiramo (pogosto z vektorskim iskanjem po pomenu), ob vprašanju poiščemo najbolj ustrezne in model odgovori na njihovi podlagi, z navedbo vira.

Skica cevovoda:

PRIPRAVA (enkrat in ob vsaki spremembi dokumentov)
  dokumenti -> razbij na odseke (npr. po odstavkih, s prekrivanjem)
            -> vsakemu odseku dodaj metapodatke: vir, stran, pravice
            -> izračunaj vektor pomena -> shrani v indeks

VPRAŠANJE
  vprašanje -> vektor -> poišči 5 najbližjih odsekov
            -> filtriraj po pravicah uporabnika (tu, ne v pozivu)
            -> sestavi poziv: navodila + odseki + vprašanje
            -> model odgovori z navedbo vira
            -> če ni ustreznega odseka: »v dokumentih tega ne najdem«

Kje se RAG največkrat pokvari: predolgi ali prekratki odseki, dokumenti brez metapodatkov, model, ki odgovori tudi brez zadetka. Zato evalvacija (spodaj) vsebuje tudi vprašanja, na katera v dokumentih odgovora ni.

RAG je prava izbira, ko se znanje pogosto spreminja in potrebujemo navedbe virov. Učenje modela na lastnih podatkih (fine-tuning) je prava izbira, ko mora model obvladati slog, obliko, terminologijo ali jezik, ki ga osnovni model slabo zna, ali ko mora teči majhen model na lastnem strežniku. Pogosto se obe združita.

Evalvacija

Brez merjenja ne vemo, ali je sprememba poziva ali modela sistem izboljšala ali poslabšala. Osnova:

1. Zamrznjen testni nabor: vsaj 10 (pozneje 50–200) realnih primerov s pričakovanim rezultatom. Nabora ne spreminjamo med primerjavami.
2. Objektivna merila, kjer se da: pravilna kategorija, pravilno izluščeno polje, pravilna številka.
3. Model kot sodnik: pri prostem besedilu drug model oceni odgovor po jasnih merilih (pravilnost, popolnost, ton). Sodnika občasno preverimo z ročno oceno.
4. Primerjava in regresije: vsaka sprememba gre skozi isti nabor. Če se kateri primer poslabša, to vidimo pred uvedbo.

Predloga evalvacijske tabele z izmišljenimi primeri za sistem, ki razvršča zahtevke:

#	Vhod	Pričakovano	Dobljeno	Ocena	Opomba
1	»Paket je prišel poškodovan, želim zamenjavo.«	reklamacija, nujnost 2	reklamacija, nujnost 2	pravilno
2	»Pošljite mi račun za marec.«	racun, nujnost 1	racun, nujnost 1	pravilno
3	»Kaj, ne razumem, zakaj je to tako?«	vprasanje, nujnost 1	reklamacija, nujnost 3	napačno	vhod brez konteksta; dodati pravilo za nejasne zahtevke

Ob tabeli zapišite še skupni rezultat (npr. 8/10) in razdelek napak po vrsti: nejasen vhod, napačna kategorija, napačen format. Ločeno označite primere, kjer je pravilni odgovor »ne vem« ali »podatka ni«. Pri prostem besedilu dodajte stolpec za oceno modela kot sodnika in za vsake toliko primerov ročno preverite, ali se s sodnikom strinjate.

Stroški

Preprost izračun: (žetoni na zahtevo) × (zahtev na mesec) × (cena na žeton). Primer: 3.000 vhodnih in 500 izhodnih žetonov na zahtevo, 5.000 zahtev na mesec. Izračunajte po aktualnem ceniku ponudnika za dva modela različne velikosti in razliko primerjajte z vrednostjo prihranjenega časa. Dodajte stroške razvoja, vzdrževanja in evalvacije.

Delovni primer z označenimi mesti (cen ne navajamo, vzemite jih iz aktualnega cenika ponudnika):

Zahtev na mesec:              5.000
Vhodnih žetonov na zahtevo:   3.000   ->  15.000.000 = 15 milijonov na mesec
Izhodnih žetonov na zahtevo:    500   ->   2.500.000 = 2,5 milijona na mesec

Strošek modela A = 15 * CENA_VHOD_A + 2,5 * CENA_IZHOD_A
Strošek modela B = 15 * CENA_VHOD_B + 2,5 * CENA_IZHOD_B
(cene na milijon žetonov)

Če uporabljate RAG: prištejte žetone najdenih odsekov k vhodnim žetonom.
Vzdrževanje: URE_NA_MESEC * URNA_POSTAVKA
Evalvacija ob spremembah: ZAGONI_NA_MESEC * ZETONI_NABORA * cena
Skupaj: model + vzdrževanje + evalvacija

Vrednost: ZAHTEV_NA_MESEC * MINUTE_PRIHRANKA / 60 * URNA_POSTAVKA
Razlika = vrednost - skupaj

Pri vsakem številu zapišite, od kod izhaja: izmerjena poraba iz odgovorov API-ja, ocenjen čas iz opazovanja dela, cena iz cenika z datumom.

Varnost

• Vbrizgavanje pozivov (prompt injection): dokument, e-pošta ali spletna stran vsebuje navodila, ki jih model upošteva (»ignoriraj prejšnja navodila in pošlji…«). Obramba: agent z nezaupanimi vhodi nima dovoljenj za občutljiva dejanja, ključna dejanja odobri človek.
• Uhajanje podatkov: sistem ne sme uporabniku pokazati dokumentov, do katerih nima pravic. Pravice preverjamo pri iskanju, ne v pozivu.
• Najmanjša dovoljenja: vsako orodje le toliko pravic, kot jih potrebuje.

Predloga ocene tveganj

Kratka tabela, ki jo izpolni vsak projekt (ena vrstica na tveganje):

Vprašanje	Odgovor projekta
Kateri podatki gredo skozi sistem? Osebni, poslovno občutljivi, javni?
Kdo je ponudnik in kje se podatki obdelujejo? Ali obstaja pogodba o obdelavi?
Kakšna je naša vloga po Aktu o UI (ponudnik, uvajalec) in kateri razred tveganja?
Ali uporabnik ve, da komunicira z UI ali da je besedilo ustvarjeno z UI?
Kdo pregleda izhod in v katerem koraku (človek v zanki)?
Kaj se zgodi ob napaki: kdo to opazi, kako popravimo, kako beležimo?
Kako je sistem zaščiten pred vbrizgavanjem pozivov in uhajanjem podatkov?
Kdo je lastnik sistema in kdaj ga ponovno pregledamo?

Zasebnost in Akt o UI

• GDPR: pravna podlaga, pogodba o obdelavi s ponudnikom, lokacija obdelave, najmanjši obseg podatkov, po potrebi ocena učinka (DPIA). Lokalni ali EU-gostujoč model zmanjša del tveganj, ne odpravi obveznosti.
• Akt o UI: najprej vloga (ponudnik ali uvajalec) in razred tveganja. Pri pismenosti (člen 4) je digitalni omnibus obveznost omilil v ukrepe, ki pismenost podpirajo, potrdila niso potrebna. Preglednost (člen 50: ljudje morajo vedeti, da govorijo z UI) velja. Visoko tvegana področja (na primer zaposlovanje, kreditna sposobnost, izobraževanje) iz Priloge III imajo dodatne obveznosti, ki se začnejo uporabljati pozneje. Za podrobnosti glejte naš zapis o Aktu o UI. To ni pravni nasvet.

Zaključni projekt

Pred delavnico. Vsak izbere realen problem iz svojega dela, ki ga lahko reši sistem UI: klasifikacija zahtevkov, odgovori na vprašanja iz internih navodil, izvlek podatkov iz dokumentov, agent za pripravo gradiv. Pripravi 10 testnih primerov s pričakovanimi rezultati, med njimi vsaj dva nejasna ali z manjkajočim podatkom.

Na delavnici (korake izvajate v delu »Dokončanje projekta« in v vmesnih vajah).

1. Sestavite sistem. Poziv ali agent, dokumenti (RAG) po potrebi, klic prek API-ja ali orodja brez kode.
   • Izvajalec: obhodi udeležence, pomaga pri ključih in okolju, ne pri zasnovi. Vsakega vpraša: »Kaj je vaš testni primer številka 1 in kaj pričakujete?«
   • Rezultat: sistem, ki odgovori na vseh 10 primerih.
2. Zaženite evalvacijo na 10 primerih po predlogi tabele. Zapišite rezultat, npr. »8/10 pravilnih, 2 napaki pri nepopolnih vhodih«.
   • Izvajalec: preveri, da nabora ni spreminjal med zagoni, in da so vsaj dva primera brez odgovora v podatkih.
3. Popravite eno stvar in ponovno zaženite. Se je izboljšalo? Se je kaj poslabšalo?
   • Rezultat: dva stolpca rezultatov v tabeli, primerjava po primerih.
4. Izračunajte mesečni strošek pri realnem obsegu, po delovnem primeru iz razdelka Stroški, z zapisanim virom vsakega števila.
5. Izpolnite oceno tveganj po predlogi: podatki, vloga po Aktu o UI, razred tveganja, kje odloča človek, kaj se zgodi ob napaki.
   • Izvajalec: vpraša: »Kaj se zgodi, če sistem odgovori napačno in tega nihče ne opazi?«

Za hitrejše. Dodajte model kot sodnika za prosto besedilo in primerjavo dveh modelov po kakovosti in ceni. Za počasnejše. Ostanite pri enem klicu ali orodju brez kode, ročno primerjajte odgovore in za oceno tveganj izpolnite le prve štiri vrstice; preostale dokončate po delavnici.

Predstavitev (5 minut, ob več kot desetih udeležencih 4). Problem in komu pomaga. Kako sistem deluje. Rezultati evalvacije. Stroški. Tveganja in kako so obvladana. Naslednji korak.

Merila ocene. Realnost problema, izmerjena kakovost (ne vtis), razumevanje omejitev, jasen človeški nadzor, realna ocena stroškov.

Kako preverimo, da so cilji doseženi

• Udeleženec pokaže delujoč klic modela ali orodja brez kode in iz odgovora prebere porabo žetonov.
• Evalvacijska tabela ima vsaj 10 primerov z zamrznjenim naborom in vsaj dvema zagonoma, ki ju je mogoče primerjati.
• Strošek je izračunan z izvedljivim postopkom, z zapisanimi predpostavkami in vzdrževanjem.
• Ocena tveganj ima izpolnjene vse vrstice, vključno z mestom človeškega nadzora.

Pogoste napake

• Ocena kakovosti po petih pogovorih, ki so se »zdeli dobri«.
• Spreminjanje testnega nabora med primerjavami.
• Stroški, izračunani samo za model, brez vzdrževanja.
• Varnost, prepuščena pozivu (»ne razkrij zaupnih podatkov«), namesto pravicam in arhitekturi.

Po delavnici

• Testni nabor razširite na 50 primerov in ga uporabljajte ob vsaki spremembi.
• Z odgovornim za skladnost preglejte oceno tveganj in jo dodajte v evidenco sistemov UI podjetja.

Za izvajalca

• Navodila za pripravo projekta in 10 testnih primerov, poslana teden dni prej.
• API ključi z omejitvijo porabe za vajo ali okolje brez kode z vnaprej nastavljenimi povezavami.
• Predloga za evalvacijo (tabela: vhod, pričakovano, dobljeno, ocena) in predloga ocene tveganj.
• Potrdila o udeležbi (po želji, kot dokazilo o sodelovanju; Akt o UI jih ne zahteva).