A vállalat második agya: a wikitől a készségekig minden a kontextustól függ10 min read

Sokat gondolkodtam a „második agy” körüli felhajtáson. Megbeszéltem ezt másokkal a területen és kollégáimmal, akik vagy egy második agyat építenek, vagy annak egy verziója van.

Az ismeretlenek számára a második agymozgás Andrej Karpathy „Wiki” ötletével indult: az ügynök személyes tudását a helyi MD-fájlok egyfajta összekapcsolt Wiki-struktúrájába rendezték. Ez később a személyes adatok sokkal szélesebb formátumba történő rendszerezésére is kiterjedt, a felhasználók gyakran Obsidian-t használnak a jegyzetek rendszerezésére és megjelenítésére, valamint az értekezletek adatait (Granola/Whisperflow/Zoom átiratok) a Wikibe.

rakéta-karpátia-tudásbázisok:start

rakéta-karpátia-tudásbázisok:vége

Ahogy ez a „Wiki” bővült, nyilvánvalóvá vált, hogy a benne található információk megosztása valóban értékes. Így virágzásnak indult a „cég második agya” projektje. A második agy utópiás változata mindent átír: zoom hívást, F2F megbeszéléseket, még alkalmi interakciókat is, e-maileket, laza üzeneteket, dokumentumokat – mindezt egy hatalmas adatbázisba, mint például a Snowflake. Képzelje el, hogy a cég bármely tagja bármit feltehet ennek a Snowflake-példának, és azonnal minden kérdésére választ kap.

Hoppá, nem jó ötlet. Először is, ez nagyon drága. Az ilyen dolgokba bekerülő adatmennyiség egyszerűen őrült, és az adatok lekérése rendkívül nehézzé, lassúvá és költségessé válik. A biztonság és az adatok elkülönítése problémát jelent. Hogyan akadályozhatja meg, hogy egy 1:1 arányú személyes adat, pénzügyi adat, vezetői döntés, HR-adat vagy akár valakit felmondó döntés becsússzon az átiratokba és hozzáférhető legyen. Nem mindenki kellene mindent tudni…

Illetve kinek van erre szüksége, mit ment meg, és egyáltalán jó ötlet?

Általánosságban azt mondanám, hogy ennek egy zárt változata jó ötlet. A középvezetés létezésének oka nagyrészt az, hogy a kérdéseket felfelé terelgeti, és a későbbiekben tisztázza a döntéseket. Ennek nagy része most egy második aggyal is elvégezhető.

Második agy a technikai csapatok számára

A technikai második agy sokkal könnyebben karbantartható. Sok vállalat csak egy Dropbox/Google meghajtó/OneDrive könyvtárat használ, amely a Claude/Codex által megosztott tudást tartalmazza. Ennek a Git-repóba való átküldésének automatizálása meglehetősen egyszerű, vagy valóban használhatja a Githubot is a kezeléséhez (azt hiszem, nagyon kis erőfeszítés a OpenAI/Anthropic számára, hogy támogassa ezt a forgatókönyvet anélkül, hogy egyéni készségeket kellene telepítenie az ilyen típusú dolgok kezeléséhez). Az igazság forrása most a Github repo lesz, a helyi másolatok pedig helyi git repók.

Ez olyan tudást és képességeket adhat hozzá, mint a megosztott készségek, megosztott döntések, építészeti tervek, látványtervek (például tervezési rendszerekkel kapcsolatos döntések) és számos más vállalati termékdöntés.

A kis csapatoknak valójában nincs szükségük egy egyszerű szinkronizálásra a repo körül, de a nagyobb, sok nagyobb csapattal rendelkező vállalatok nagyon gyorsan súlyos korlátozásokba ütköznek. A legsúlyosabb problémák a kontextusmérgezést jelentik, amikor egy adott felhasználó olyan helyi döntéseket hozhat, amelyek ütköznek a második agyi adatokkal, akár ellentmondó adatokat vezetnek be, akár véletlenül (egyes esetekben szándékosan?) felülírják a vállalati döntéseket.

A git-ben tartása és az összevonás egy dedikált ügynök segítségével végezhető el, amely az ütközéseket keresi, és figyelmezteti a felhasználót, ha a módosításaik ütköznek, feloldja az ütközéseket és egyesíti az eredményeket.

Vegye figyelembe, hogy ez nem jó módszer a projektdokumentáció karbantartására. Ehhez a legjobb módszer, ha a wikit magának a projektnek a szerves részét képezi. Nagyon könnyű létrehozni. Csak félre kell tenni egy kódoló ügynököt, és megkérni, hogy nézze át a projektet, alaposan dokumentálja egy docs mappába, felosztva architektúra, guba, termékdöntések, műszaki döntések és egyéb dolgok szerint, amelyekről azt a következtetést vonja le, hogy hasznosak lehetnek a kis, befogadható md-fájlokban. A kulcs az, hogy mondd meg neki, hogy a kód és a readme.md mind a dokumentumok könyvtárára mutassanak, hogy mindenhol hivatkozzanak rá, és a projekt részének tekintsenek, és ne külső erőforrásnak. A legfontosabb tudnivaló az ügynök számára, hogy a cél az, hogy lehetővé tegyük egy másik ügynök gyors bevonását a projektbe, elkerülve ezzel a buktatókat, kátyúkat és műszaki süllyedéseket…

Miután magába a repo projekt struktúrájába integrálták, a kódoló ügynök úgy fogja karbantartani, mintha kód lenne. Úgy olvassa be, mintha a kód része lenne, és ha valami megváltozik, módosítja vagy módosítja a dokumentációt (ne feledje, hogy „a dokumentáció az, hogy a kód könnyen olvasható és áttekinthető” vagy „a dokumentáció abban a pillanatban elavulttá válik, amikor elhagyja a billentyűzetet” – bízza a mesterséges intelligenciára, hogy karbantartja ezeket, így ezek többé nem igazak).

Második agy a termék-, marketing- és nem műszaki csapatok számára

Ez a fajta második agy nagyon klassz lehet a technikai csapatok számára, de ugyanezt a nem technikai csapatok számára rendkívül nehéz lesz.

Vegyünk például egy ügyvédi csapatot, akik nagyon specifikus tudáskészlettel rendelkeznek, és kiterjednek az e-mailekre, a laza, Word-fájlokra és egyéb dokumentumokra. Ugyanez vonatkozik a könyvelőkre, az értékesítésre, az ügyfelek sikerére stb. Mindegyiküknek megvan a saját második agyi tudása.

Ezen túlmenően a menedzsment valószínűleg azt akarja, hogy az adatok felbuborékosodjanak (a középvezetésen keresztül szűrés nélkül), és a csapatnak szüksége lehet a menedzsment által generált információkra. Hogyan készítsünk biztonságos és elkülönített, méretezhető tudásgráfot?

Van néhány megközelítés, amely megkönnyítheti a dolgokat, legalábbis addig, amíg a nagyfiúk meg nem oldják ezt a problémát, remélhetőleg nyíltan, de inkább egy drága zárt megoldással.

1. Személyes második agy – minden ember, aki ezt akarja, leírhatja saját találkozóit és fenntarthatja saját második agyát. Az Obszidián elég jól használható erre, alapvetően bármelyik szer képes szétválogatni és kitakarítani. Használja a REM alvási mechanizmust az optimalizáláshoz – az ügynöknek éjszaka fel kell ébrednie, azonosítania kell a napközben gyűjtött összes információt, meg kell találnia minden olyan információt, amely kritikus és fontos, hogy megőrizze a jövőre nézve, és könnyen visszakereshető módon rendezze azokat mappákban és MD-fájlokban. Ez azt jelenti, hogy ha beszélt egy adott ügyféllel, az adott ügyfélnek frissítve lesz egy md fájlja, amely olyan információkat tartalmaz, amelyeket fontos megjegyezni róluk, mivel foglalkoznak együtt, stb. Ugyanez vonatkozik a projektekre is. Lesz átfedés: jó az átfedés – rendben van, ha egy adott projektről szóló információ mind a beszélt személy fájljában, mind a cégben, mind a projektfájlokban benne van. Hagyja, hogy az ügynök intézze ezt Ön helyett. Ha kérdései vannak, tegye ezt elsődleges adatforrásként ügynöke számára. Megjelentheti ügynökét e-mailjeinek/beszélgetéseinek/stb. – csak ügyeljen arra, hogy ne írjon át olyan dolgokat, amelyeket nem szeretne dokumentálni (ne legyen ebből valóságshow vagy szappan).

2. Csapatszintű második agy – a második adatréteg olyan adatokat tartalmaz, amelyek vagy a személyes második agyban vannak, amelyekben az ügynök 100%-ban biztos, hogy relevánsak az egész csapat számára, vagy olyan adatokat, amelyek a természetüknél fogva csapatalapú megbeszéléseken származnak. Egy ügynök is gyűjthet adatokat ehhez a második agyhoz a csapat laza csatornáiról – ez nem lehet az Ön 1:1 csatornáiban vagy a nagyítási hívásokban. Miután lekérte az adatokat, az ügynök valós időben vagy éjszaka rendszerezheti azokat, és rámutathat azokra a következetlenségekre, amelyekben a döntéseket hatályon kívül helyezték, vagy amelyek nem felelnek meg a személyes vagy vezetői döntéseknek. Ezeket ki kell emelni, és figyelmeztetni kell az összeegyeztethetetlen döntést hozó személyt, hogy tájékozottan dönthessen.

3. Menedzsment szintű második agy – ez alapvetően egy csapatszintű második agy, de az adatok és a meghozott döntések érzékenysége miatt sokkal árnyaltabban kell kezelni. Itt csak a végső döntéseket és a nyilvános adatokat szabad megosztani, hogy elkerüljük az esetleges szivárgást a vállalat többi részébe. Jó ötlet lehet, ha az ember legalább az elején átnézi az adatok egy részét az adatbiztonság biztosítása érdekében. Az is jó ötlet, hogy a vezetői agyat kihagyjuk a vállalat második agyából.

4. Vállalat széles második agy – ez a legkeményebb, és csak olyan konkrét, információs adatot szabad tárolni, amely az egész cég számára releváns lehet. Csak a jelentett pénzügyi eredmények, például a személyzetre vonatkozó információk (ki milyen pozíciót tölt be).

Ez sok adatot hagy ki, beleértve például a hangulati adatokat, amelyeket a vezetés hallani szeretne az egész csapattól. Ezt külön-külön be lehet gyűjteni, vagy be lehet takarítani laza és egyéb forrásokból. Nem jó ötlet az ilyen típusú adatokat közvetlenül a vállalati agyból gyűjteni.

Szóval, mit keresel egy második agyban vagy egy vállalati agyban, volt-e kísérleted egy ilyen felépítésére, és mi volt a következtetésed?