product updates

Yrityksen toiset aivot: wikistä taitoihin, kaikki riippuu kontekstista7 min read

Reading Time: 4 minutesOpi kuinka yrityksen toiset aivot kehittyvät staattisista wikeistä tekoälyn ylläpitämäksi kontekstiksi, taidoiksi ja jaetuksi tiedoksi teknisille ja ei-teknisille tiimeille.

Company Second Brain represented as a shared AI knowledge network

Yrityksen toiset aivot: wikistä taitoihin, kaikki riippuu kontekstista7 min read

Reading Time: 4 minutes

Olen ajatellut paljon kaikkea ”toisiin aivoihin” liittyvää hypeä. Keskustelin tästä muiden alan ammattilaisten ja kollegoideni kanssa, jotka joko rakentavat toisia aivoja tai joilla on versio niistä.

Tuntemattomille toinen aivoliike alkoi Andrej Karpathyn ”Wiki”-ideasta: agentin henkilökohtaisen tiedon järjestäminen eräänlaiseksi toisiinsa linkitetyksi paikallisten MD-tiedostojen Wiki-rakenteeksi. Myöhemmin tämä laajeni henkilötietojen järjestämiseen paljon laajempaan muotoon, jolloin käyttäjät käyttävät usein Obsidiania muistiinpanojen järjestämiseen ja visualisoimiseen sekä kokoustietojen (Granola/Whisperflow/Zoom-transkriptioiden) lisäämiseen Wikiin.

raketti-karpatia-tietokannat:aloitus

Andrej Karpathy -postaus LLM-tietokannoista ja tekoälyn ylläpitämistä wikeistä
Andrej Karpathy LLM:ien käyttämisestä henkilökohtaisen tietopohjan rakentamiseen ja ylläpitämiseen.

raketti-karpatia-tietokannat:loppu

Kun tuo ”Wiki” laajeni, kävi selväksi, että siinä olevan tiedon jakamisessa on jotain todellista arvoa. Siten ”yrityksen toisten aivojen” projektit alkoivat kukoistaa. Toisten aivojen utooppisessa versiossa kaikki mahdollinen litteroidaan: zoomauspuhelu, F2F-kokoukset, jopa satunnaiset vuorovaikutukset, sähköpostit, löysät viestit, asiakirjat – kaikki valtavaksi tietokantaksi, kuten Snowflake. Kuvittele, että kuka tahansa yrityksessä voi kysyä tältä Snowflake-esiintymältä mitä tahansa ja saada välittömästi vastauksen kaikkiin kysymyksiin.

Hups, ei hyvä idea. Ensinnäkin tämä on erittäin kallista. Tällaisiin tietoihin menevä datamäärä on aivan hullua, ja tietojen hakeminen siitä tulee erittäin vaikeaa, hidasta ja kallista. Tietoturvasta ja tietojen erottelusta tulee ongelma. Kuinka estät 1:1 henkilötietojen, taloustietojen, johdon päätöksien, HR-tietojen tai jopa jonkun irtisanomista koskevien päätösten luiskahtamisen pöytäkirjaan ja olemaan tavoitettavissa. Ei kaikki pitäisi tietää kaiken…

Lisäksi kuka tätä tarvitsee, mitä se säästää ja onko tämä edes hyvä idea?

Yleisesti ottaen sanoisin, että sisäinen versio tästä on hyvä idea. Suurin osa keskijohdon olemassaolosta on asioiden ajaminen ylävirtaan ja päätösten selkeyttäminen loppupäässä. Suuri osa tästä voidaan nyt tehdä toisilla aivoilla.

Toiset aivot teknisille joukkueille

Tekniset toiset aivot voivat olla paljon helpompi ylläpitää. Monet yritykset käyttävät vain Dropbox-/Google-asema-/OneDrive-hakemistoa, jossa on jaettua tietoa, jonka Claude / Codex voi jakaa. Automaatio tämän siirtämiseksi Git-reposaan on melko yksinkertaista, tai voit todella käyttää myös Githubia tämän hallintaan (luulen, että OpenAI/Anthropic:lle on hyvin pieni vaiva tukea tätä skenaariota ilman, että tarvitsee asentaa mukautettuja taitoja tämän tyyppisten asioiden hallitsemiseksi). Totuuden lähteeksi tulee nyt Githubin repo ja paikalliset kopiot ovat paikallisia git repoja.

Tämä voi lisätä tietoa ja valmiuksia, kuten yhteisiä taitoja, yhteisiä päätöksiä, arkkitehtonisia suunnitelmia, visuaalisia suunnitelmia (esimerkiksi suunnittelujärjestelmäpäätöksiä) ja monia muita yrityksen tuotepäätöksiä.

Pienet tiimit eivät todellakaan tarvitse paljon muuta kuin yksinkertaisen synkronoinnin repon ympärillä, mutta suuret yritykset, joissa on useita suurempia tiimejä, törmäävät vakaviin rajoituksiin hyvin nopeasti. Vakavimpiin ongelmiin liittyy kontekstimyrkytys, jossa tietty käyttäjä saattaa tehdä paikallisia päätöksiä, jotka ovat ristiriidassa toisen aivodatan kanssa, joko ottamalla käyttöön ristiriitaisia ​​tietoja tai ohittamalla yrityksen päätökset vahingossa (joissakin tapauksissa ehkä tarkoituksella?).

Sen pitäminen gitissä ja yhdistäminen voidaan tehdä käyttämällä omistettua agenttia, joka etsii ristiriitoja ja voi varoittaa käyttäjää, jos hänen muutokset ovat ristiriidassa, ratkaista ristiriidat ja yhdistää tulokset.

Huomaa, että tämä ei ole hyvä tapa ylläpitää projektidokumentaatiota. Tätä varten parempi tapa on sisällyttää wiki kiinteäksi osaksi itse projektia. Se on melko helppo luoda. Varaat vain koodausagentin ja pyydät sitä käymään läpi projektin, dokumentoimaan sen perusteellisesti docs-kansioon, jaettuna arkkitehtuurin, hankkeiden, tuotepäätösten, teknisten päätösten ja muiden seikkojen mukaan, joista se päättelee, että ne voivat olla hyödyllisiä pienissä sisältävissä md-tiedostoissa. Tärkeintä on kertoa sille varmistaaksesi, että koodi ja readme.md osoittavat kaikki asiakirjahakemistoon varmistaaksesi, että siihen viitataan kaikkialla ja että niitä pidetään osana projektia eikä ulkoisena resurssina. Tärkein asia agentin tiedossa on, että tarkoituksena on mahdollistaa toisen agentin nopea liittyminen projektiin, jotta vältytään sudenkuoilta, kuoppilta ja teknisiltä ujoilta…

Kun se on integroitu itse repoprojektirakenteeseen, koodausagentti ylläpitää sitä ikään kuin se olisi koodia. Se lukee sen ikään kuin se olisi osa koodia, ja jos jokin muuttuu, se mukauttaa tai muokkaa dokumentaatiota (muista, että ”dokumentaatio on koodin helppolukuinen ja selkeä” tai ”dokumentaatio vanhenee heti, kun se lähtee näppäimistöltä” – luota tekoälyyn, jotta ne pitävät yllä, joten ne eivät enää pidä paikkaansa).

Toiset aivot tuote-, markkinointi- ja ei-teknisille tiimeille

Tämän tyyppiset toiset aivot voivat olla todella siistejä teknisille joukkueille, mutta saman tekeminen ei-teknisille joukkueille on erittäin vaikeaa.

Otetaan esimerkiksi lakimiehiä, joilla on hyvin erityisiä tietokokonaisuuksia ja se kattaa sähköpostin, slack-, Word-tiedostot ja muut asiakirjat. Sama koskee kirjanpitäjiä, myyntiä, asiakkaiden menestystä jne. Heillä jokaisella on oma toisen aivotietonsa.

Tämän lisäksi johto todennäköisesti haluaa tietojen kuplivan (suodattamattomana keskijohdon kautta) ja tiimi saattaa tarvita johdon tuottamia tietoja. Kuinka tuottaa skaalautuva tietograafi, joka on suojattu ja erotettu?

On olemassa muutamia lähestymistapoja, jotka voisivat helpottaa asioita ainakin siihen asti, kunnes isot pojat ratkaisevat tämän ongelman, toivottavasti avoimesti, mutta todennäköisemmin kalliin suljetun ratkaisun kautta.

  1. Henkilökohtaiset toiset aivot – jokainen, joka haluaa tämän, voi litteroida omat tapaamisensa ja ylläpitää omia toisia aivojaan. Obsidiaani on varsin hyödyllinen tähän, mikä tahansa agentti voi periaatteessa lajitella ja puhdistaa sen. Optimoi se REM-lepotilamekanismin avulla – agentin tulee herätä yöllä, tunnistaa kaikki päivän aikana keräämänsä tiedot, löytää kaikki tärkeät ja tärkeät tiedot säilytettäväksi tulevaisuutta varten ja järjestellä ne helposti noudettavalla tavalla kansioihin ja MD-tiedostoihin. Tämä tarkoittaa, että jos puhuit tietyn asiakkaan kanssa, kyseiselle asiakkaalle päivitetään md-tiedosto, joka sisältää tiedot, jotka on tärkeää muistaa hänestä, mitä työskentelette yhdessä jne. Sama pätee projekteihin. Tulee päällekkäisyyksiä: päällekkäisyys on hyvä – on ok, että tiedot tietystä projektista säilyvät sekä keskustelukumppanisi tiedostossa, yrityksessä että projektitiedostoissa. Anna agentin hoitaa tämä puolestasi. Jos sinulla on kysyttävää, aseta tämä edustajasi ensisijaiseksi tietolähteeksi. Voit paljastaa agenttisi sähköpostillesi/keskusteluillesi/ jne. – Varmista, ettet litteröi asioita, joita et halua dokumentoida (älkäämme tehkö tästä tosi-showta tai saippuaa).

  2. Joukkuetason toiset aivot – Toinen tietokerros sisältää tietoja, jotka ovat joko henkilökohtaisissa toisissa aivoissa, että agentti on 100% varma, että se on relevanttia koko tiimille, tai dataa, joka on peräisin ryhmätason kokouksista, jotka ovat luonteeltaan tiimipohjaisia. Agentti voi myös kerätä tietoja näille toisille aivoille tiimisi löysiltä kanavilta – sen ei pitäisi olla 1:1-kanavissasi tai zoomauspuheluissasi. Kun se on hakenut tiedot, agentti voi järjestää ne reaaliajassa tai öisin ja osoittaa epäjohdonmukaisuuksia, joissa päätökset kumottiin tai eivät vastaa henkilökohtaisia ​​tai johdon päätöksiä. Ne tulisi korostaa ja varoittaa henkilölle, joka tekee yhteensopimattoman päätöksen, jotta hän voi tehdä valintansa tietoisella tavalla.

  3. Johdon tason toiset aivot – Tämä on pohjimmiltaan tiimitason toisia aivoja, mutta datan ja tehtävissä olevien päätösten herkkyyden vuoksi niitä tulisi käsitellä paljon vivahteemmin. Vain lopulliset päätökset ja julkiset tiedot tulisi jakaa tänne, jotta vältetään mahdolliset vuodot muulle yritykselle. Ihmisen voi olla hyvä idea käydä läpi osa tiedoista ainakin alussa tietoturvan varmistamiseksi. On myös hyvä idea jättää johdon aivot pois yrityksen toisista aivoista.

  4. Yrityksen laajat toiset aivot – Tämä on vaikein ja sisältää vain konkreettista tietoa, joka voi olla merkityksellistä koko yritykselle. Raportoidut taloudelliset tulokset vain, esimerkiksi tiedot henkilöstöstä (kuka on missäkin tehtävässä).

Tämä jättää paljon dataa pois, mukaan lukien esimerkiksi mielipidetiedot, joita johto haluaa kuulla koko tiimiltä. Tämä voidaan kerätä erikseen tai korjata löysästä ja muista lähteistä. Ei ole hyvä idea kerätä tällaista dataa suoraan yrityksen aivoista.

Joten mitä etsit toisista aivoista tai yrityksen aivoista, oliko sinulla yrityksiä rakentaa niitä ja mitkä olivat johtopäätöksesi?