Žinutės

Labai priklauso nuo to, kaip aplink paslaptis infrastruktūra sutvarkyta ir nuo „threat model“ – kokios grėsmės labiausiai tikėtinos, nuo ko pirmiausia saugomės. Šiais laikais skirtingi žmonės turi labai skirtingą toleranciją tam, ką gali matyti agentas. Vieni paduoda visus API raktus ir YOLO – svarbu, kad į git nepatektų (būna ir kas į git commit'ina, bet to jau nepateisinu). Kiti agentui duoda tik pavyzdinius duomenis ir prie tikrų duombazių, log'ų, etc. neprileidžia dėl GDPR ir panašių atsakomybių. Yra ir baimės, kad duomenis mokymuisi panaudos Anthropic/OpenAI.
Tad reikia apsibrėžti ko bijai ir kiek patogumo dėl to nori paaukoti 🙂
Pas mane asmeniškai – labai priklauso nuo projekto. Ar tai asmeninis, ar kliento, kiek jautrių duomenų.

(Yra dar vienas paranojos tipas – baimė, kad modeliai, staiga įgavę „sąmonę“ ar „norą išlikti“ ims reketuoti, šantažuoti, šiaip grobstyti pinigus norėdami apmokėti serverius, kuriuose gyvena. Ne nulinė tikimybė! 😁)

Nuo agentų slapti duomenys saugomi SOPS. Užšifruoti, iššifruojami tik turint raktą, kuris egzistuoja production servery ir tavo youbikey (arba faile, kuris agentui nepasiekiamas). Gali būti keli raktai, keliems serveriams (staging, etc.).
Duomenys, kurie agentui turi būti pasiekiami, bet neturi būti git, saugomi su gitcrypt – užšifruojami ir iššifruojami git hook'ais.
Visa tai suponuoja, kad agentas lokaliai veikia kažkokiam sandbox'e (docker/podman/bwrap ar pan.) ir neturi laisvos prieigos prie serverių, kuriuose gyvena raktai. Deployment'as daromas tarpiniu būdų – paruošiant žmogaus patikrinamus ansible script'us arba nixos konfigūraciją (ar ką jau ten benaudotum), arba kažkokio kito (lokaliai leidžiamo) modelio, kuriam prie paslapčių prieiti leidžiama.

Šiandien 11:00 online DIA (DI - Automatizacijos) bendruomenės teminis susitikimas: DI produktai ir teisė.

Šiandien jau gana paprasta sukurti DI automatizaciją, agentą ar su LLM po kapotu valdomą produktą.
Tačiau veikiantis sprendimas dar nebūtinai reiškia, kad jį galima teisiškai ir saugiai paleisti klientams ar pradėti naudoti įmonėje.
Kai į automatizacijas patenka realūs klientų ar darbuotojų duomenys, kai jie siunčiami į skirtingas sistemas ir LLM tiekėjus, o DI sugeneruoti atsakymai naudojami realiame verslo procese, atsiranda visai kitas klausimų sluoksnis.
Situacija dar sudėtingesnė, kai produktą pradeda naudoti klientai skirtingose šalyse.
Būtent apie tai ir diskutuosime šiame DIA susitikime.

Svečias - Martynas Nikolavjevas
Martynas su komanda vysto vasara.ai - DI pagrįstą teisinį produktą, kuris padeda atlikti teisines paieškas, analizuoti dokumentus ir rengti atsakymus remiantis Lietuvos teisės šaltiniais. Jau virš 300 teisininkų Lietuvoje naudojasi Vasara.ai

dar iki relyzo toli bet kas netingit gali paskaityt visai neblogai sugeneravo is duomenu kuriuos pateikiau 🙂

api nepasikeite , duomenys irgi ne

Man dar visada kyla klausimas dėl duomenų saugumo su vibecoding, dauguma pradeda app kurti, bet manau, kad dabar duomenų saugumas turėtų būti vienas iš pagrindinių prioritetų (visada buvo), bet DI įrankiai gali padėti rasti įvairių spragų.

paskaityk apie temporal ir taxonomies kas tai yra per duomenu strukturos

tai va, lokaliai išvis bėda – gerai, kad neatiduodi niekam duomenų, bet reikia gero hardware'o, o ir ant to gero vis tiek modelis prastesnis bus..

tada rag'as ir ragas, bet jo, jei rimti duomenis, vistiek ne tiek brangiai

pergeneruot, jei daug duomenų, gali būtų brangoka..

Aš tai tokius video mielai duodu savo agentams ir paskui tik perskaitau jų išvadas:

Geras video kavai — ir tiesiai į mūsų daržą. Santrauka ir verdiktas:
Apie ką. Autorius — Open Brain (SQL atminties sistemos) kūrėjas, lygina savo požiūrį su Karpathy wiki idėja (41k žmonių pasižymėjo). Esminė skirtis paprasta: kada AI galvoja. Karpathy wiki — galvojama ĮDEDANT: kiekvienas naujas šaltinis iškart įsintezuojamas į prižiūrimą wiki, klausimai paskui pigūs. Open Brain — galvojama KLAUSIANT: viskas krenta į struktūrizuotą bazę be sintezės, AI dirba tik kai paklausi. Wiki laimi giliam vieno žmogaus tyrinėjimui; bazė — kai reikia tikslių užklausų („visos SF virš 50k už Q1"), daug agentų ir apimčių (wiki lubos ~10k dokumentų).
Rimčiausi jo perspėjimai apie wiki kelią: pasenusi sintezė skaitosi užtikrintai ir virsta aktyvia dezinformacija (bazės spraga atrodo kaip spraga, o wiki klaida — kaip tiesa); AI redakciniai sprendimai iškepa klaidas visam laikui; keli rašytojai vienoje wiki = chaosas; ir pavojingiausia — wiki mėgsta „išlyginti" prieštaravimus, kurie kaip tik yra signalas (inžinieriai sako 12 savaičių, pardavimai pažadėjo 8 — wiki parašo „apie 10" ir problemos nebesimato).
Kodėl įdomu MUMS — trys sutapimai su tuo, ką jau darom:
1. Jo „wiki lūžta nuo kelių rašytojų" — mūsų single-writer principas tą išsprendęs nuo pirmos dienos.
2. Jo „prieštaravimų neišlyginti" — mūsų „pilniausia versija" (UNION, ne intersection) taisyklė.
3. Jo finalinis receptas — struktūra = tiesos šaltinis, wiki = generuojamas vaizdas, klaidą taisai šaltinyje ir pergeneruoji — tai tiksliai mūsų naujo agentų registro dizainas (JSON kortelės → kompiliuotas manifestas → vaizdai). Priėjom tą pačią išvadą nepriklausomai — geras ženklas.
Verdiktas: PASIIMTI principą, ne įrankį. Open Brain produkto mums nereikia — savo bazę turim. Bet vieną jo mintį verta įsirašyti: mūsų ZINIU-BAZE yra wiki-tipo, tad jos senėjimas = užtikrintai skambanti klaida; tai argumentas ilgainiui daugiau faktų laikyti struktūrizuotai (kaip registro kortelės), o sintezes generuoti, ne rašyti ranka. STEBĖTI — jo „prieštaravimų audito" įskiepio idėją, pigu pasidaryti patiems.
Įsirašau į atradimų registrą vienu sakiniu, kad mintis nepasimestų.

ne, kad tie sukaupti memory duomenys būtų transferinami tarp skirtingų įrankių, jei kada prireiktų

tai BDAR gali download savo duomenis 🙂

dokumentacija yra tas ~wiki, o visi agentsmemory ir pan. – antras tipas, tai realiai projekte abiejų tipų žinios turėtų gyventi

čia apie du approach'us – kai AI priima duomenis ir aprodojęs sukiša juos į ~wiki vs kai yra raw doc'ai ir AI skaito, apdoroja gyvai

nu, mano atveju, visas sandbox'inimas yra tam, kad:
a) apsisaugoti nuo galimų injection atakų, jei agentas perskaito ką nors web'e ir patampa evil
b) jei jis patampa evil, nes nesuprato užduoties arba tapo sąmoningas ir bando pavergti visus planetos žmones
c) GDPR, teisiniai dalykai sutartyse su klientais, kad jų duomenys tinkamai apsaugoti

galima pipeline prisukt ocr visu doku aka turini istraukt irgi rag kad eitu pagal doku turini ieskot

pasidairiau truputį po repozitorijas, tai kita tema truputį klausimas, Mindaugas:
https://github.com/atvirokodosprendimai/webmail – šitas daiktas kažkur gyvai naudojamas, realioj įmonėj su realiais duomenim? Kokiu tikslu sukurtas buvo?

ir dar BDAR 🙂 gali atsisiust visus savo duomenis 😉

bet jei čia toks globalus memory visiems projektams kartu, tai gali leak'intis duomenys

Bet tai pats agentas gali padaryti tą „context konspektą“. Pas mane, pabaigęs užduotį, jis pamodifikuoja dokumentaciją kaip reikia, ir tiek.

tai jis stebi kas imama iš atminties? Kaip suprasti „ant karšto“?
Tarkim turiu docs folderį „nuo pirmos dienos“. Ten patys agentai atnaujina duomenis ir tas visai ok veikia kol doc'ai iki ~200k token'ų, pasak Anthropic. Tik virš 200k rekomenduoja RAG naudot.
Jei 300Mb atvejis, tai suprantu.. Bet jei 3Mb? :)

Nuo kiek maždaug duomenų apsimoka naudoti šitą vs tiesiog sukraunant viską į kontekstą paprastuoju būdu (md failų hierarchija)?
Esu https://github.com/tobi/qmd pasižymėjęs su ta pačia paskirtimi, bet dar nepriėjau prie realaus bandymo-įgyvendinimo. Max ką dabar turiu projektuose – žinyną su ~400k token'ų (~300 psl. knyga).
Šiaip kyla jausmas, kad industrija ima pintis įvairiausiais over-engineered sprendimais (kurie gal ir reikalingi, bet priklausomai nuo masto, o ne by default visiems).

aha, žiūriu tą pdf'ą ;)

nedauk duomenu net laptopo nvidia 3gb vram susitvarkytu 😉

Na, „verta“ buvo tik tiek, kiek padėjo susipažinti su tuo OKF. Pačiam projektui įtakos neturėjo ir, greičiausiai, nelabai turės. Gal log'as kažkiek padės agentams susigaudyti geriau nei naršymai po git istoriją.
Ketinu prisiruošti perkelti kitą ~wiki formato dalyką į AI-apdorotą grafą, tai ten OKF padės tiek, kiek taps galima standartizuotu būdu pajungti vizualizacijos įrankius. Jau dabar yra visokių ~wiki apvalkalų, kurie priima OKF dokumentų repozitoriją ir ją sugeba gražiai atvaizduoti. Bet šiaip pats formatas labai lankstus, paprastas (md+yaml+conventions). Nežiūrėčiau į tai kaip į rimtą standartizaciją – čia tik mažas žingsnelis; pirmieji susitarimai kaip viską daryti, kad būtų lengviau susišnekėti. Įtariu, kad labai greitai skirtingi įrankiai ims lipdyti daug custom metadata ir išlaikyti OKF vientisumą/suderinamumą taps sunku, panašiai kaip HTML3.2/HTML4.0 ir modernėjančių web browserių eroj, jei kas tuos laikus patyrė ir prisimena.

12 ir 14 metų (6 ir 8 klasė bus). Kol kas ten duomenys iš jų (Kauno Jėzuitų Gimnazijos) dienyno – mokytojų pastabos, įvertinimai, pamokų planai, namų darbai. Taip pat duomenys iš Google Classroom – papildoma medžiaga, komentarai ir įvertinimai. Prijungiau ir eduka.lt su elicejus.lt, bet kol mokslo metai neprasidėję, nėra licencijų, tad tušti tie resursai. Turėjau įvairių užduočių (tiek AI generuotų, tiek šiaip iš interneto, paties sugalvotų, etc.), kurias irgi sudaviau analizei. Tai šiuo metu esam „diagnostinių testų“ stadijoje, kur AI iš turimų duomenų surinko ~galimas problemines vietas, sugeneravo klausimus skirtingų temų „supratimo lygio“ vertinimui. Atostogos vis dar, tad lėtokai čia viskas sprendžiasi, bet mintis ilgainiui yra sistemingai išvynioti supratimo-nesupratimo raizgalynę ir pamažu padaryti „žinių grafą“ be esminių skylių, kur vienos žinios jungiasi su kitomis (nežinau kiek tai bus praktiška, bet teoriškai kol kas gal visai gražu 😁).
Nežinau ką galėčiau rodyti – iš esmės, visas projektas labai personalizuotas ir daugiausia vedamas paties AI (Fable 5 ir Opus 5) bei to, ką diktuoja realūs duomenys. Smagu, kad tam tikras vietas iš duomenų jis tinkamai įvertino ir tas vertinimas sutampa su maniškiu (priežastys dėl prastesnių pažymių). Vadinasi, greičiausiai kryptis teisinga.
Iš techninių dalykų, atsimušiau į bot protection ir Google Classroom API ribojimą iš KJG Google Workspace pusės, tad viską teko apeiti leidžiant desktop'inį Google Chrome su atskirais profiliais, kurį agentai valdo per --remote-debugging-port. Kol kas niekas neužbanino, nors random delays dariau labai primityvius.
Šiuo metu stabdis yra patys vaikai, kurie lėtai (ir, nemeluokim, nenoriai) daro diagnostines užduotis. Mąstau pakurti kažkokį online įrankį, kad galėtų po valandą per dieną paskirti net nebūdami su manim, bet čia gal kitai savaitei. Jei pavyks padaryti kažką verto dėmesio, galėsiu pasidalinti per DIA pokalbį.. sorry, kad prirašiau čia paklodę 🤭

Skirtinguose loginiuose sluoksniuose. Atskirtos vartotojo sasajos, verslo logikos ir duomenu dalys, nors visa tai veikia kaip viena pagrindine aplikacija.

Kadangi @… žadėjo resetą (ir savo pažadą įvykdė), tai vienas iš projektų pas mane yra stebėti OS darbą, nes būna lūžimų (dėl hardwaro). Tai prie miegą daviau sukalti tokį dashboardą ir jau turimų duomenų, kad biški gražiau matyti, visas tas ataskaitas. Visai smagų žaislą padarė.

Pasidalinu, jei kam kyla kartais minčių, o ką čia dar pasidaryti naudingo

Pastarosiom dienom ruošiu du sūnėnus grįžimui į mokyklą; gaminam čia tokį „knowledge graph“, kur jų žinios, spragos ir pasiekimai gauna dokumentus Obsidian vault'e. Pabandžiau patyrinėti kiek OKF padėtų/tiktų. Iš esmės, turimi Obsidian failai jau yra tas pats, kas OKF. Iš OKF pritaikiau log.md concept'ą ir perėjau prie Markdown links formato vietoj default'inio Wikilinks (esminio skirtumo nėra). Wikilink formatas liko frontmatter properčiuose, kitaip būtų sugriuvę Obsidian dalykai (OKF tą leidžia).
Taigi, konvertavau visą Obsidian vault į OKF formato md failus – teko pamodifikuot kelis md generatorius ir pan. Nieko smarkaus. Dabar vaikų „knowledge graph“ yra OKF v0.2 formato. Realaus skirtumo tarp Obsidian nėra, išskyrus log.md, kuriame saugomi pokyčiai. Realiai, pokyčiai ir taip buvo saugomi git'e, bet gražus log'as su visais pipeline run'ais prideda turinio. Visa repozitorija vis dar yra validi Obsidian vault, tad jokio UI nepraradau.

esu užsistar'inęs tokį https://github.com/tobi/qmd, kur kažkiek į temą, bet neturėjau dar laiko atidžiau pažiūrėti (čia offline, kas yra gerai – galima gal ir labiau sensitive info dėti, ypač jei kokie įmonės duomenys)

tai gali but labai riebus irankis, kaip kad pvz libreoffice cli 🙂 kuris konvertuoja bet koki doka i pdf or so

na pvz convertdocxtopdf i kurio stdin paduodi blob ir pasiimi is stdout blob, pvz cat file | cdoctopdf —stdio > out.pdf arba kad butu ir zmogui tinkamas - cdoctopdf -i file.doc -o out.pdf

na buvo apsas, kuris kas kelias sekundes duomenis trauke is serverio, kad rodytu statistika

vietinis hardware atsiperka per 1-2 metus paprastai, jei labai high-availability nereikia.
Jei statai duomenų centre (VPS), gauni užtikrintumą – stabilią elektrą, virtualizuotą hw, ryšį, bet finansiškai tikrai brangiau, jei pats sugebi viską administruoti.

kai ne tą diską formatavau, tai visa laimė, kad 90+% visko buvo git ir duomenų bazių kopijose

kodas turi but reproducable build - github, clone, ir is backup atstacius duomenis - turi viskas veikt

uzkuriau blyn toki dokumentu skaityma ir info strukturizavima, suede savaites limita chatgpt, baigia asmenini claude code, liko darbinis claude ir dar kimi gal biski :D

Kaip bebuvę esmė padaryta ji buvo būtina, tik pats duomenų laikymo sprendimas tikėtina buvo be reikalo kuriamas nuo 0

Tai šį savaitgalį imsiuos jų dokumentacijos, ką pavyks surast, ir adaptuoti, jei ne visiškai atsisakyt kam buvo milijardais tokenų sudeginta .. 🤣

Kuo mažiau netvarkingų duomenų ir visokių užkampių su custom exceliukais, neraportuojamais skambučiais, tuo mažiau problemų ateity.
Dėl CRM (ypač Odoo) – variantas geras, nors ir didelis+lėtas. Neaišku kol kas ar išvis interface'ų reikės – gal pakanka postgresql + obsidian + metabase ar pan. grafikams/lentelėms (read only)