LLM-wiki mittakaavassa: Token-kustannukset, hallusinaatiokontaminaatio ja second brain -hautausmaa

Viidessä päivässä sen jälkeen kun Andrej Karpathy julkaisi "LLM Knowledge Base"-työnkulkunsa X:ssä, ketju keräsi yli kuusitoista miljoonaa katselua. Viikon sisällä GitHubissa oli viisitoista plus toteutusta nimillä kuten llm-wiki-compiler ja karpathy-wiki. DAIR.AI ilmoitti virtuaalisen tapahtuman mallin leikkelemiseksi. Obsidian-foorumiketjut täyttyivät itseään ylläpitävien vaultien kuvakaappauksista. Idea — että LLM voi kompiloida raakainputtisi linkitetyksi, lintataviksi, kyseltäväksi markdown-wikiksi — muuttui hetkellisesti virtuaaleimmaksi tiedonhallinnan konseptiksi sitten kun Roam julkaisi block referencet 2020.

Suurin osa tähän mennessä kirjoitetusta on juhlintaa. Kirjoitimme yhden niistä kappaleista itse, ja seisomme sen takana: arkkitehtuuri on aidosti kiinnostava, ja anti-RAG-löydös ansaitsee huomiota.

Mutta juhlinta ei ole analyysiä. On kolme asiaa joita melkein kukaan ei sano Karpathyn mallista, ja jos olet aikeissa viettää viikonloppua rakentaen yhtä itse, ansaitset kuulla ne ennen kuin aloitat. Tämä on skeptikon briiffaus — ei kyyninen, ei rimanalitus, vain ne osat keskustelusta jotka hype-sykli on sivuuttanut.

1. Hallusinaatiokontaminaatio-ongelma

Aloita syvimmästä teknisestä huolenaiheesta, koska se on myös se joka heitetään sivuun nopeimmin.

Kun LLM kompiloi wikiä, se ei vain transkriboi. Se tekee toimituksellisia päätöksiä — mitkä konseptit linkittyvät mihinkin, mitkä väitteet yleistyvät, mitä yksityiskohtia säilytetään. Jokainen näistä päätöksistä on paikka jossa hallusinaatio voi tulla rekisteriin. Ja kun se kerran on siellä, se ei enää ole merkitty hallusinaatioksi. Se on merkitty riviksi muistiinpanoissasi.

Sebastian Raschkan Antigravity-tiimi sanoi sen suoraan kirjoituksessaan mallista: "If the LLM hallucinates a connection between two concepts, that false link now lives in your wiki and could influence future queries." Sergey Lyapustinin Your Second Brain Has Amnesia -essee meni pidemmälle: "When an LLM makes up a meeting that didn't happen, or puts the wrong words in someone's mouth from your own notes, the failure mode is not that you catch it — it's that you might actually believe it."

Vakiovastaus on: "Siihen lint-ajo on." Karpathyn työnkulku sisältää lint-askeleen, jossa LLM käy wikin läpi etsien ristiriitoja ja aukkoja. Teoriassa kontaminoitunut väite tulee kiinni seuraavalla ajolla.

Käytännössä linteri on sama malliluokka joka esitteli hallusinaation. Itsetarkistuksella on todellisia rajoja. Meillä on useiden vuosien tutkimusta joka osoittaa, että LLM:t ovat huonompia nappaamaan omia virheitään kuin toisen järjestelmän kirjoittamia virheitä, ja jopa ristikkäinen mallitarkistus jättää pitkiä häntiä havaitsemattomia virheitä. Jos Claude kirjoittaa uskottavan-mutta-väärän ristiviittauksen maanantaina, on todennäköistä että Claude keskiviikkona lukee sen, löytää sen sisäisesti johdonmukaiseksi ja sertifioi sen.

Tämän kaiken alla on myös ratkaisematon ongelma: lainaustarkkuus. Hyvä ihmisen wiki antaa sinun jäljittää väite takaisin "sivu 47, kappale 3" lähteeseen. LLM-kompiloidulla wikillä ei ole sisäänrakennettua mekanismia tuon linkin tuottamiseen. Voit pyytää sitä liittämään siteerauksia, ja se tekee sen — mutta siteeraus itse voi olla väärin, ja siinä vaiheessa auditoit tarkastajaa.

Steph Ango, Obsidianin perustajakumppani, antoi neuvon joka luetaan eri tavalla kun istut kontaminaatio-ongelman kanssa. Hän ehdotti, että kaikki AI-generoidut sisällöt pidetään erillisessä vaultissa, jotta AI voi "make a mess in their own space". Se ei ole omituinen preferenssi. Se on joku joka ymmärtää markdown-tietopankkeja syvästi ja kertoo sinulle, että näiden järjestelmien tuotos ei ole vielä tarpeeksi luotettava sekoitettavaksi oikeisiin muistiinpanoihisi.

Käytännön seuraus on tärkeä ja usein unohdettu: kontaminaatioriski on suurin piirtein ok henkilökohtaiselle tietotyölle, jossa yhden hairahduksen haittapuoli on pieni. Se on merkityksellisesti vaarallinen missä tahansa kontekstissa, jossa joku myöhemmin toimii wikin perusteella kuin se olisi totuutta — juridinen tutkimus, lääketieteelliset muistiinpanot, säädellyt liiketoimintapäätökset, mikä tahansa johon liittyy muiden rahaa tai turvallisuutta. Karpathyn malli ei ole korkean panoksen tietosäilö. Ei vielä.

2. Token-kustannus jota kukaan ei julkaise

Tässä on outo aukko diskurssissa. Karpathyn viesti mainitsee, että hänen wikinsa on kasvanut noin sataan artikkeliin ja neljäänsataantuhanteen sanaan. Se ei sano mitään siitä mitä sen ylläpitäminen maksaa. Eivät myöskään useimmat innokkaat kirjoitukset. Eivätkä GitHub-repot.

Tehdään se matematiikka jota kukaan muu ei näytä haluavan tehdä, selkeällä varauksella että tämä on kuoren-taustaa ja numerosi tulevat vaihtelemaan.

Tyypillinen ingest tässä mallissa ei ole halpa. Kun uusi dokumentti saapuu, LLM:n täytyy lukea dokumentti, vetää esiin kymmenestä viiteentoista olemassa olevaa wiki-sivua joihin todennäköisimmin vaikuttaa, päättää mitä ristiviittauksia päivitetään, kirjoittaa kyseiset osiot uudelleen, ja lähettää diff. Jos jokainen koskettu sivu on keskimäärin noin kolme tuhatta tokenia, plus viiden tuhannen tokenin system prompt, plus päättelyn overhead, katselet noin 35 000 tokenia yhtä ingestiä kohti. Se on yhdelle uudelle inputille.

Lisää nyt lint-ajo. Linting on koko wikin pyyhkäisy Karpathyn kehyksessä, mikä tarkoittaa että se skaalautuu wikisi koon mukaan. Sadan artikkelin wiki 3 000 tokenilla per artikkeli on 300 000 tokenia per lint, ennen mitään päättelyä. Aja se viikoittain ja olet monimiljoonaisen tokenin alueella pelkkää hygieniaa varten.

Claude Opus -hinnoilla (~15 dollaria per miljoona input, ~75 dollaria per miljoona output) aktiivinen wiki-käyttäjä, joka tekee päivittäisiä ingestejä ja viikoittaisia linttejä, voisi uskottavasti käyttää viidestä viiteenkymmeneen dollariin kuukaudessa riippuen siitä kuinka aggressiivinen hän on. Sonnet leikkaa sitä merkittävästi. Haiku tai Gemini Flash leikkaavat enemmän. Mutta pointti on että kukaan ei julkaise oikeita lukuja. Community toimii uskolla.

Ainoa olemassa oleva benchmark — "84 % token-vähennys per sessio" -luku ussumant/llm-wiki-compiler:stä — on todellinen, mutta se mittaa jotain muuta kuin useimmat luulevat sen mittaavan. Se on per-kysely-tehokkuusväite: kun wiki on rakennettu, siihen kysely käyttää vähemmän tokeneita kuin saman kyselyn ajaminen raakalähteiden yli. Se on totta ja hyödyllistä. Se ei sano mitään wikin rakentamisen ja ylläpidon kustannuksesta ensinnäkin, joka on kustannus joka tosiaan skaalautuu elämäsi kanssa.

Paikalliset LLM:t ovat ilmeinen varakulku. Ollama, LM Studio, llama.cpp — aja 30B- tai 70B-malli omalla koneellasi ja marginaalinen token-kustannus menee nollaan. Ongelma on laatu. Kompilointitehtävät ovat vaikeita. Ne tarvitsevat pitkää kontekstia, huolellista ohjeiden seuraamista ja johdonmukaista muotoilua monien ajojen yli. Nykyiset avoimen painon mallit voivat tehdä sen, mutta laadun pudotus Sonnetista tai Opuksesta on havaittava juuri niissä ulottuvuuksissa, joilla on eniten merkitystä wikille — hallusinaatiotaajuus, ristiviittauksen tarkkuus ja tyylin johdonmukaisuus.

Rehellinen yhteenveto on, että kukaan ei vielä tiedä mitä tämä malli maksaa kestävässä henkilökohtaisessa mittakaavassa, ja ne jotka rakentavat äänekkäimpiä toteutuksia eivät ole niitä jotka maksavat laskun kuukauden lopussa. Jos rakennat yhden, aseta budjettikatto API-avaimellesi ennen kuin aloitat. Opit enemmän katon osumisesta kuin mistään blogipostauksesta.

3. Second brain -hautausmaa

Tämä on osio joka pitäisi hillitä eniten intoa, koska se on keskustelun osa jonka takana on eniten näyttöä. Historia "tallenna kaikki, löydä mitä tahansa" -työkaluista ei ole voiton historia. Se on vaikuttavien julkaisujen, suurten rahoituskierrosten, innostuneiden varhaisten käyttäjien ja hitaan romahduksen historia.

Evernote. Kerran arvostettiin yli miljardiin dollariin, kerran palveli kahtasataamiljoonaa käyttäjää, kerran oli koko second brain -aikakauden lippulaivatuote. Bending Spoons -yritysosto leikkasi ilmaispaketin viiteenkymmeneen muistiinpanoon ja pakotti läpi lähes sadan prosentin hinnankorotukset. Vuonna 2026 tuote on yhä olemassa, mutta se kuolee julkisesti, eikä kukaan knowledge management -communityssa kohtele sitä enää määränpäänä.

Roam Research. Yhdeksän miljoonaa dollaria kerätty. "Tools for thought" -tähti 2020:ssa ja 2021:ssä. Block references, kaksisuuntaiset linkit, intohimoinen kultti. Vuoteen 2024 mennessä momentum oli poissa. Viisitoista dollaria kuukaudessa välinpitämättömällä mobiilikokemuksella ja perustaja joka oli kiinnostuneempi filosofiasta kuin julkaisemisesta. Aktiiviset käyttäjämäärät trendasivat alaspäin. Se on yhä olemassa. Se ei enää voita.

Skiff. Neljätoista miljoonaa kerätty, kaksi miljoonaa käyttäjää, yksityisyys-edellä, aidosti hyvä tuote. Notion osti helmikuussa 2024. Kokonaan lopetettu elokuuhun 2024 mennessä. Kuusi kuukautta ostosta poissaolemiseen.

Limitless (ent. Rewind). Always-on -kontekstikerros. Riipus, Mac-sovellus, kunnianhimo nauhoittaa koko elämäsi ja antaa AI:n tehdä siitä järkeä. Meta osti heidät 5. joulukuuta 2025. Riipuksen laitteistomyynti pysähtyi samana päivänä. Mac-sovellus lopetettiin pysyvästi 19. joulukuuta. Palvelu lakkasi kokonaan EU:ssa, Britanniassa ja Brasiliassa — viimeinen detalji luetaan hiljaisena myöntymisenä siitä, että GDPR:ää ei koskaan oikein ratkaistu "nauhoita kaikki" -tuotteelle.

Mem.ai. 29 miljoonaa dollaria OpenAI:n rahaston johdolla. Positioitiin AI-natiivina muistiinpanotyökaluna joka vihdoin murtaisi automaattisen organisoinnin. Kriitikot alkoivat kutsua sitä "neljäntoistamiljoonan dollarin second brain -epäonnistumiseksi" kun se ei löytänyt retentiota. Uudelleenjulkaistu Mem 2.0:na lokakuussa 2025. Parempi. Ei korjattu.

Tämä ei ole lista huonoista tuotteista. Useimmat näistä olivat hyvin rakennettuja, hyvin rahoitettuja ja ihmisten ajamia jotka ymmärsivät knowledge managementia syvästi. Ne epäonnistuivat silti, ja epäonnistumismalli on tarpeeksi johdonmukainen nimettäväksi.

Tuottavuusansa

Glaspin analyysi knowledge management -epäonnistumisista, joka kaiutteli aiempaa APQC:n työtä, tunnistaa tool hoppingin yksittäisenä yleisimpänä epäonnistumistapana. Käyttäjät kiertävät Notionin, Obsidianin, Logseqin, Capacitiesin, Tanan, Memin, päätyen "viiteen puolitäyteen järjestelmään ilman käyttökelpoista tietopankkia". Toinen tappaja on yli-insinööröinti: käyttäjät viettävät enemmän aikaa järjestelmän rakentamiseen ja säätämiseen kuin tietotyön tekemiseen jota järjestelmän oli tarkoitus tukea. "Järjestelmästä tulee projekti, eikä varsinainen tietotyö koskaan tapahdu."

Laajempi konteksti on synkkä. Noin 92 % SaaS-startupeista epäonnistuu kolmen vuoden sisällä (myICORin pitkittäinen analyysi, 2024). Erityinen "henkilökohtainen knowledge management" -startupien osajoukko epäonnistuu samalla tai korkeammalla nopeudella. Markkina on yrittänyt ja epäonnistunut ratkaisemaan tätä ongelmaa noin kaksikymmentä vuotta.

Mikään tästä ei ole syy olla yrittämättä. Mutta jos luet viraalia ketjua Karpathyn wikistä ja tunnet tarvetta rakentaa koko informaatioelämäsi uudestaan sen ympärille, tuon tarpeen pitäisi istua aivan Roamin, Memin, Skiffin, Limitlessin ja Evernoten muistin vierellä. Ne kaikki tuntuivat myös väistämättömiltä.

Miksi tällä kertaa voi todella olla erilaista

Nyt steel-man-argumentti, koska skeptinen tapaus ei ole suljettu argumentti.

Yksittäinen selkein ero Karpathyn mallin ja jokaisen aiemman second brain -työkalun välillä on tämä: vanhat työkalut vaativat, että ylläpidit tietopankkia. Se oli se seinä johon käyttäjät iskivät. Kaappasit Evernoteen päivänä yksi, järjestelit kuumeisesti kaksi viikkoa, ja kuusi kuukautta myöhemmin sinulla oli kolmetuhatta merkitsemätöntä muistiinpanoa ja epämääräinen syyllisyyden tunne. Ylläpitotaakka, ei kaappauksen taakka, oli se joka tappoi nämä järjestelmät.

Karpathyn malli on perustavalla tavalla erilainen juuri tässä ulottuvuudessa. LLM tekee ylläpidon. Se lukee, se linkittää, se linttaa, se kirjoittaa uudelleen. Et ole enää vastuussa tietopankin muodosta — olet vastuussa inputeista ja satunnaisesta auditoinnista. Se on merkityksellisesti erilainen työ.

Tool hopping oli, jälkikäteen, rationaalinen käyttäytyminen. Käyttäjät etsivät työkalua joka tekisi työn heidän puolestaan, eikä sellaista työkalua ollut olemassa. AI-agentit ovat ensimmäinen asia joka uskottavasti voi. Ei ole niin että käyttäjät olivat oikullisia. Se on niin että heidän haluamansa ei vielä ollut olemassa.

Hallusinaatio-ongelma on todellinen mutta rajallinen. Jos pidät raakalähteesi muuttumattomina ja kohtelet kompiloitua wikiä väliaikaisena ja uudelleen generoitavana — olennaisesti välimuistina luotetun lähdekerroksen päällä — tietyn hallusinaation vaikutussäde on pieni. Voit rakentaa wikin uudelleen alusta kun menetät luottamuksesi siihen. Se on ominaisuus jota millään aiemmalla muistiinpanotyökalulla ei ollut.

Kustannusongelma voi ratketa itsestään lyhyemmässä horisontissa kuin ihmiset odottavat. Paikalliset mallit Gemma 3-, Llama 4- ja Qwen 3 -sukupolvessa sulkevat kuilua kompilointityyppisissä tehtävissä nopeammin kuin useimmat kustannusanalyysit olettavat. Kahdeksantoista kuukauden päästä matematiikka tämän ajamiseen paikallisesti voi yksinkertaisesti olla erilaista.

Ja arvolupauksen muutos merkitsee. Edellinen aalto oli tiedon tallentamisesta ja toivomisesta että se maksaisi itsensä takaisin myöhemmin. Tämä aalto on kyselemisestä strukturoituun versioon inputeistasi pyynnöstä, ja rakenteen uudelleenrakentamisesta kun se rapistuu. Se on erilainen sopimus käyttäjän kanssa, ja se saattaa olla parempi.

Rehellinen kysymys joka ratkaisee asian

Kuori hype ja historia pois, ja avoin kysymys on kapeampi kuin miltä se näyttää.

Ratkaiseeko AI-ylläpidetty tieto todella ylläpitotaakan, vai siirtääkö se vain taakan "muistiinpanojen järjestämisestä" "lähteiden kuratointiin ja terveystarkastusten ajamiseen"?

Optimistinen vastaus: lähteiden kuratointi on rajallista työtä. Sinulla on vain niin monta lähdettä joista aidosti välität. Muistiinpanojen organisointi sen sijaan on ääretöntä — jokainen uusi muistiinpano luo uusia organisatorisia päätöksiä jotka kumuloituvat.

Pessimistinen vastaus: lähteiden kuratointi on myös ääretöntä jos otat sen tosissasi. Sinusta tulee oman mikro-Wikipediasi toimittaja, ja toimittaminen on kokopäivätyö syystä.

Realistinen vastaus on, että se riippuu täysin siitä ovatko inputtisi rajallisia vai rajoittamattomia. Jos suuntaat Karpathyn mallin "kaikkeen mitä luen internetistä", hukut. Jos suuntaat sen tiettyyn tutkimusprojektiin, yhteen alueeseen jota yrität hallita, tai luonnollisesti rajattuun paloletkuun kuten omiin kokouksiisi, sillä on todellinen mahdollisuus toimia — koska ylläpito-ongelma on suhteellinen input-volyymiin, ja input-volyymi on tosiaan rajoitettu.

Mihin tämä jättää kokoustranskriptit erityisesti

Kokouksilla sattuu olemaan ominaisuus joka suoraan käsittelee yhden "second brain -hautausmaan" epäonnistumistavoista: inputit ovat luonnollisesti rajallisia. Sinun ei tarvitse päättää mitä kaapata. Kokoukset tapahtuvat haluatpa tai et, ja kokousten joukko josta välität on rajallinen tavalla jolla "mielenkiintoiset artikkelit" tai "ajatukset joita minulla oli tänään" eivät koskaan ole.

Tämä tekee ylläpitotaakasta aidosti pienemmän kuin kaappaa-kaikki-mitä-luet -wikillä. Se tekee myös hallusinaatioriskistä pienemmän hienovaraisella tavalla: täydet keskustelutranskriptit sisältävät paljon kontekstia per token, joten LLM:n poiminta on maadoittuneempaa kuin poiminta tiiviistä muistiinpanosta. Mallilla on enemmän signaalia pideltäväksi. Yksityisyys- ja kustannuskysymykset jäävät, eivätkä ne ole pieniä. Mutta rakenteellinen sopivuus on parempi kuin useimmissa domeeneissa.

Proudfrog on rakennettu tämän hypoteesin ympärille — että kokoukset ovat oikea laajuus AI-ylläpidetylle tietopankille juuri siksi että input on luonnollisesti rajattu. Onko tämä hypoteesi oikea, on yhä avoin kysymys, emmekä aio teeskennellä muuta skeptisessä artikkelissa juuri tämänkaltaisesta hypoteesista. Jos haluat yksityiskohtaisemman version argumentista, kokous-wiki-kuilu ja täydellinen työnkulkuopas kaivavat syvemmälle. Jos haluat nähdä tapauksen kokouksille knowledge worker -työnkulkuna, se asuu siellä.

Mitä fiksun skeptikon pitäisi tehdä

Jos olet lukenut tähän asti ja yhä haluat yrittää, tässä versio kokeesta joka opettaa sinulle eniten vähimmällä hukkaan menetetyllä ajalla.

• Aloita rajatusta käyttötapauksesta. Yksi tietty tutkimusprojekti, kokouksesi, yhden tiimin dokumentaatio. Älä aloita "kaikella tiedollani". Häviät.
• Pidä raakalähteet muuttumattomina ja Git-versioituina. Wiki on johdettu artefakti. Sinun pitäisi voida poistaa se kokonaan ja regeneroida se menettämättä mitään tärkeää.
• Kohtele wikiä uudelleen generoitavana, ei arvokkaana. Siinä hetkessä kun tunnet olevasi suojeleva kompiloitua versiota kohtaan, olet alkanut rakentaa samaa ansaa jonka edellinen sukupolvi rakensi.
• Aseta kova budjettikatto LLM-API-avaimellesi ennen aloitusta. Ei jälkikäteen. Katon osuminen on dataa. Yllätyslaskut eivät ole.
• Auditoi hallusinaatioita viikoittain ensimmäisen kuukauden ajan. Valitse viisi väitettä satunnaisesti joka viikko ja jäljitä ne takaisin lähteeseen. Jos et pysty, se on mitä opit.
• Päätä etukäteen milloin lopetat. Kirjoita muistiin mikä todistaisi kokeen epäonnistuneen — kontaminaatiotaajuus, kuukausikustannus, ylläpitoaikabudjetti — ja kunnioita sitä kun saavutat sen. Muuten sunk cost pitää sinut järjestelmässä kauan sen hyödyllisen elämän ulkopuolelle, mikä on juuri se miten edellinen sukupolvi second braineja päätyi hautausmaiksi.

Tämä ei ole kyynisyyttä. Se on kuri jota edellisellä työkalujen aallolla ei ollut. Karpathyn malli saattaa olla ensimmäinen knowledge management -arkkitehtuuri joka aidosti selviää ylläpitoseinästä. Se saattaa myös olla olemattakaan. Ainoa tapa ottaa selvää on kokeilla sitä tavalla jolla skeptikko kokeilee asioita — rajatusti, auditoitavasti, halvalla ja ennalta päätetyllä poistumisella.

Katso miten Proudfrog lähestyy kokoustietoa jos tämän argumentin rajattu-input-versio kiinnostaa sinua.

---

Usein kysytyt kysymykset

Onko LLM-wiki-lähestymistapa oikeasti uusi, vai vain RAG uudelleenpakattuna?

Se ei ole RAG. RAG hakee chunkkeja kyselyaikaan samankaltaisuuden perusteella; Karpathyn malli kompiloi strukturoidun artefaktin etukäteen ja kyselee artefaktia suoraan. Ne ratkaisevat eri ongelmia. RAG skaalautuu paremmin miljooniin dokumentteihin. Kompilointi toimii paremmin henkilökohtaisessa mittakaavassa koska se säilyttää päättelyn ja eksplisiittiset ristiviittaukset jotka samankaltaisuushaku heittää pois. Uutuus ei ole wiki-muoto — markdown-wikit ovat kolmekymmentä vuotta vanhoja — se on LLM:n käyttäminen wikin jatkuvana ylläpitäjänä pikemminkin kuin kyselymoottorina raakalähteiden päällä.

Kuinka paljon Karpathyn tyylisen wikin pyörittäminen todella maksaa?

Kukaan ei ole julkaissut uskottavaa numeroa. Kuoren-taustamatematiikka vihjaa, että aktiivinen käyttäjä joka tekee päivittäisiä ingestejä ja viikoittaisia koko-wikin linttejä voisi käyttää noin viidestä viiteenkymmeneen dollariin kuukaudessa frontier-mallissa kuten Claude Sonnet tai Opus, riippuen wikin koosta ja käytön intensiteetistä. Halvemmat mallit leikkaavat sitä merkittävästi, paikalliset mallit eliminoivat marginaalisen kustannuksen mutta maksavat laadussa. Aseta budjettikatto API-avaimellesi ennen aloitusta. Kohtele kaikkia blogipostauksissa näkemiäsi numeroita arvioina kunnes joku julkaisee oikean tutkimuksen.

Mitä tapahtuu kun LLM hallusinoi faktan ja kirjoittaa sen wikiini?

Se pysyy siellä kunnes nappaat sen. Lint-ajon on tarkoitus löytää ristiriidat, mutta linteri on sama malliluokka joka esitteli virheen, ja itsetarkistuksella on todellisia rajoja. Paras nykyinen puolustus on pitää raakalähteet muuttumattomina ja kohdella kompiloitua wikiä uudelleen generoitavana — jos menetät luottamuksen wikiin, rakenna se uudelleen lähteistä. Korkean panoksen konteksteissa (juridiset, lääketieteelliset, taloudelliset päätökset) hallusinaatioriski on tällä hetkellä tarpeeksi korkea, ettet saisi käyttää tätä mallia ensisijaisena tietosäilönä.

Miksi niin monet "second brain" -tuotteet ovat kuolleet?

Johdonmukainen epäonnistumistapa on se, että ylläpitotaakka lopulta painaa enemmän kuin arvo. Käyttäjät kaappaavat innoissaan, organisoivat muutaman viikon ja sitten ajautuvat pois. Tool hopping pahentaa ongelmaa — käyttäjät kiertävät järjestelmien välillä etsien sitä joka tekee työn heidän puolestaan. Evernote, Roam, Mem, Skiff ja Limitless iskivät kaikki johonkin versioon tuosta seinästä. Karpathyn malli on kiinnostava juuri siksi, että se kohdistuu ylläpitoseinään suoraan, antamalla LLM:n tehdä ylläpidon. Onko se tarpeeksi mallin rikkomiseen, on yhä avoin kysymys.

Onko tämä turvallisempi paikallisten LLM:ien kanssa?

Turvallisempi yksityisyydelle ja kustannukselle, kyllä. Turvallisempi hallusinaatiolle, ei oikeastaan — avoimen painon mallit nykyisessä sukupolvessa hallusinoivat enemmän kompilointitehtävissä kuin Claude Sonnet tai GPT-luokan mallit, eivät vähemmän. Oikea vastaus useimmille käyttäjille vuonna 2026 on hybridi: käytä frontier-mallia kompilointi- ja lint-ajoihin, käytä paikallista mallia rennon kyselyyn valmista wikiä vastaan. 12–18 kuukauden sisällä paikalliset mallit ovat todennäköisesti tarpeeksi hyviä käsittelemään myös kompilointiajot, ja kustannuslaskelma muuttuu.

Pitäisikö minun edes yrittää tätä jos en ole kehittäjä?

Luultavasti ei vielä, jos tarkoitat rakentaa sellaisen itse Karpathyn kuvauksesta. Community-työkalut ovat varhaisia, työnkulut hauraita ja debuggaus vaatii mukavuutta markdownin, shell-skriptien ja prompt engineeringin kanssa. Jos haluat arvon ilman rakentamista, odota muutama kuukausi että ensimmäinen tuotteistettujen versioiden aalto selkiintyy — tai käytä domeenispesifistä työkalua joka jo toteuttaa mallin rajatulle inputille kuten kokouksille, tutkimuspapereille tai tietylle koodikannalle. Ideat ovat yhä täällä kun työkalut tulevat perässä.