Žinutės

AI tiesiog pushina/updatina is sesijos visa dokumenta 🙂

yra skilsas kuris rašo dokumentaciją, kitas kuris daro screenshotus ir deda pics į dokumentaciją

pvz mano inžinierių užpiso daryti paveiksliukus į dokumentaciją, per 2h padariau, kad per discordą duoda linką į psl ir parašo kokio picture kur reikia, bam ir ai padaro

taip, jei didelis daiktas ir daug compute'o tam sunaudota, tai kažkoks tinkamai struktūrizuotas memory (net jei tai tiesiog dokumentacija) turi būti

paskaityk apie temporal ir taxonomies kas tai yra per duomenu strukturos

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ų.

api nepasikeite , duomenys irgi ne

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

č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

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

tai BDAR gali download savo duomenis 🙂

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

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ų.

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

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

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..

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).

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? :)

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

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

ir dar BDAR 🙂 gali atsisiust visus savo duomenis 😉

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?

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

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

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

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.