product updates

Bedriftens andre hjerne: fra wiki til ferdigheter, det handler om kontekst7 min read

Reading Time: 5 minutesLær hvordan bedriftens andre hjerner utvikler seg fra statiske wikier til AI-opprettholdt kontekst, ferdigheter og delt kunnskap for tekniske og ikke-tekniske team.

Company Second Brain represented as a shared AI knowledge network

Bedriftens andre hjerne: fra wiki til ferdigheter, det handler om kontekst7 min read

Reading Time: 5 minutes

Jeg har tenkt mye på all hypen rundt «second brain». Jeg diskuterte dette med andre i feltet og mine kolleger som enten bygger en andre hjerne eller har en versjon av den.

For de som ikke er kjente, startet den andre hjernebevegelsen med «Wiki»-ideen av Andrej Karpathy: organisering av agentens personlige kunnskap i en slags sammenkoblet Wiki-struktur av lokale MD-filer. Dette utvidet seg senere til å organisere personlige data i et mye bredere format, med brukere som ofte brukte Obsidian for å organisere og visualisere notater og legge til data fra møter (Granola/Whisperflow/Zoom-transkripsjoner) inn i Wiki.

rakett-karpathy-kunnskapsbaser: start

Andrej Karpathy-innlegg om LLM-kunnskapsbaser og AI-opprettholdte wikier
Andrej Karpathy om å bruke LLM-er for å bygge og vedlikeholde personlige kunnskapsbaser.

rakett-karpathy-kunnskapsbaser: slutt

Etter hvert som «Wiki» utvidet seg, ble det åpenbart at det er en viss verdi å dele informasjonen i den. Dermed begynte «company second brain»-prosjektene å blomstre. Utopisk-versjonen av en andre hjerne får alt mulig transkribert: zoom-anrop, F2F-møter, til og med tilfeldige interaksjoner, e-poster, slake meldinger, dokumenter – alt til en enorm datadatabase som Snowflake. Tenk deg at hvem som helst i selskapet kan spørre denne Snowflake-forekomsten hva de vil og umiddelbart få svar på alle spørsmålene.

Uff, ikke en god idé. For det første er dette veldig dyrt. Mengden data som går inn i noe sånt som dette er bare sprø og å hente data fra det blir ekstremt vanskelig, sakte og kostbart. Sikkerhet og datasegregering blir et problem. Hvordan forhindrer du at 1:1 personlige data, økonomiske data, ledelsesbeslutninger, HR-data eller til og med beslutninger om å stoppe noen glir inn i utskriftene og er tilgjengelige. Ikke alle bør vet alt…

Også, hvem trenger dette, hva sparer det oss og er dette til og med en god idé?

Generelt vil jeg si at en inneholdt versjon av dette er en god idé. Mye av grunnen til at mellomledelsen eksisterer er å flyte saker oppstrøms og avklare beslutninger nedstrøms. Mye av dette kan nå gjøres med en andre hjerne.

Andre hjerne for tekniske team

En teknisk andre hjerne kan være mye lettere å vedlikeholde. Mange selskaper bruker bare en Dropbox/Google Drive/OneDrive-katalog som inneholder delt kunnskap som Claude/Codex kan dele. Automatisering for å skyve dette til en Git-repo er ganske enkel, eller du kan virkelig bruke Github til å administrere dette også (jeg antar at det er en veldig liten innsats for OpenAI/Anthropic å støtte dette scenariet uten å måtte installere egendefinerte ferdigheter for å administrere denne typen ting). Sannhetens kilde blir nå Github-reposen og de lokale kopiene er lokale git-reposer.

Dette kan legge til kunnskap og evner som delte ferdigheter, delte beslutninger, arkitektoniske design, visuelle design (for eksempel designsystembeslutninger) og ulike andre bedriftsproduktbeslutninger.

Små team trenger egentlig ikke mye utover bare en enkel synkronisering rundt repoen, men større selskaper med mange større team vil komme inn i alvorlige begrensninger veldig raskt. De mest alvorlige problemene involverer kontekstforgiftning der en bestemt bruker kan ta lokale beslutninger som er i konflikt med andre hjernedata, enten ved å introdusere motstridende data eller overstyre bedriftsbeslutninger utilsiktet (i noen tilfeller kanskje med vilje?).

Å holde den i git og slå sammen kan gjøres ved å bruke en dedikert agent som ser etter konflikter og kan varsle en bruker hvis endringene deres er motstridende, løse konflikter og slå sammen resultatene.

Merk at dette ikke er en god metode for å vedlikeholde prosjektdokumentasjon. For det er den bedre måten å inkludere wikien som en integrert del av selve prosjektet. Det er ganske enkelt å lage. Du setter bare til side en kodeagent og ber den gå gjennom prosjektet, dokumentere det grundig i en docs-mappe, delt opp etter arkitektur, gotchas, produktbeslutninger, tekniske beslutninger og andre ting som den konkluderer med kan være nyttig i små md-filer som kan inneholdes. Nøkkelen er å fortelle den for å sørge for at koden og readme.md alle peker til dokumentkatalogen for å sikre at den blir referert overalt og betraktet som en del av prosjektet og ikke en ekstern ressurs. Nøkkelen for agenten å vite er at hensikten her er å tillate en rask introduksjon av en annen agent til prosjektet for å unngå fallgruver, jettegryter og tekniske synkehull…

Når den er integrert i selve repo-prosjektstrukturen, vil kodeagenten opprettholde den som om den var kode. Den vil lese den som om den var en del av koden, og hvis noe endres, vil den tilpasse eller modifisere dokumentasjonen (husk at «dokumentasjonen er koden som er lett å lese og tydelig» eller «dokumentasjonen blir foreldet i det øyeblikket den forlater tastaturet ditt» – stol på at AI vedlikeholder disse, så de er ikke sanne lenger).

Andre hjerne for produkt-, markedsførings- og ikke-tekniske team

Denne typen andre hjerne kan være veldig kul for tekniske team, men å gjøre det samme for ikke-tekniske team vil være ekstremt vanskelig.

Ta for eksempel et team av advokater, de har veldig spesifikke kunnskapssett og det spenner over e-post, slack, word-filer og andre dokumenter. Det samme gjelder bokholdere, salg, kundesuksess osv. De har hver sin andre hjernekunnskap.

På toppen av dette vil ledelsen sannsynligvis at data skal boble opp (ufiltrert via mellomledelsen), og teamet kan trenge informasjon som ledelsen genererte. Hvordan produsere en skalerbar kunnskapsgraf som er sikret og separert?

Det er noen få tilnærminger som kan gjøre ting enklere, i hvert fall inntil de store guttene løser dette problemet, forhåpentligvis på en åpen måte, men mer sannsynlig gjennom en dyr lukket løsning.

  1. Personlig andre hjerne – hver person som ønsker dette, kan transkribere sine egne møter og vedlikeholde sin egen andre hjerne. Obsidian er ganske nyttig for dette, hvilket som helst middel kan i utgangspunktet sortere og rydde opp. Bruk REM-søvnmekanismen for å optimalisere den – en agent skal våkne om natten, identifisere all informasjonen den har samlet inn i løpet av dagen, finne all informasjon som er kritisk og viktig å beholde for fremtiden og organisere den på en lett gjenfinnbar måte i mapper og MD-filer. Dette betyr at hvis du snakket med en bestemt kunde, vil denne kunden ha en md-fil oppdatert som gjenspeiler informasjon som er viktig å huske om dem, hva dere jobber med sammen, osv. Det samme gjelder for prosjekter. Det vil være overlapping: overlapping er bra – det er greit at informasjonen om et bestemt prosjekt finnes både i filen til personen du snakket med, selskapet og prosjektfilene. La agenten administrere dette for deg. Når du har spørsmål, gjør dette til din primære datakilde for agenten din. Du kan eksponere agenten din for e-post/samtaler/osv. – bare pass på å ikke transkribere ting du ikke vil ha dokumentert (la oss ikke gjøre dette til et realityprogram eller en såpe).

  2. Andre hjerne på lagnivå – et andre lag med data inkluderer data som enten er i den personlige andre hjernen som agenten er 100 % sikker på er relevant for hele teamet, eller data som stammer fra teamnivåmøter som i sin natur er teambaserte. En agent kan også samle inn data for denne andre hjernen fra teamets slappe kanaler – det skal ikke være i 1:1-kanalene dine eller zoom-anrop. Når den har hentet dataene, kan en agent organisere dem i sanntid eller nattlig og påpeke inkonsekvenser der beslutninger ble omgjort, eller ikke samsvarer med personlige eller ledelsesmessige beslutninger. Disse bør fremheves og varsles til personen som tar den uforenlige avgjørelsen, slik at de kan ta sine valg på en informert måte.

  3. Ledernivå andre hjerne – Dette er i utgangspunktet en andre hjerne på teamnivå, men på grunn av sensitiviteten til dataene og beslutningene som tas, bør den håndteres på en mye mer nyansert måte. Kun endelige beslutninger og offentlige data skal deles her for å unngå potensielle lekkasjer inn i resten av selskapet. Det kan være en god idé for et menneske å gå gjennom noen av dataene, i det minste i begynnelsen, for å sikre datasikkerhet. Det er også en god idé å utelate lederhjernen fra selskapets andre hjerne.

  4. Selskapets andre hjerne – Dette er den tøffeste og bør kun inneholde data som er konkrete, informative som kan være relevante for hele selskapet. Rapporterte økonomiske resultater kun, for eksempel informasjon om personell (hvem har hvilken stilling).

Dette utelater mye data, inkludert sentimentdata, for eksempel, som ledelsen ønsker å høre fra hele teamet. Dette kan samles separat eller høstes fra slakk og andre kilder. Det er ikke en god idé å høste denne typen data direkte fra bedriftens hjerne.

Så, hva leter du etter i en andre hjerne eller en bedriftshjerne, hadde du noen forsøk på å bygge en og hva var konklusjonene dine?