Otak kedua syarikat: daripada wiki kepada kemahiran, semuanya mengenai konteks7 min read

Saya telah banyak berfikir tentang semua gembar-gembur yang mengelilingi “otak kedua”. Saya membincangkan perkara ini dengan orang lain di lapangan dan rakan sekerja saya yang sama ada membina otak kedua atau mempunyai versinya.

Bagi mereka yang tidak dikenali, pergerakan otak kedua bermula dengan idea “Wiki” oleh Andrej Karpathy: mengatur pengetahuan peribadi ejen dalam sejenis struktur Wiki yang saling berkaitan bagi fail MD tempatan. Ini kemudiannya berkembang kepada menyusun data peribadi dalam format yang lebih luas, dengan pengguna sering menggunakan Obsidian untuk menyusun dan menggambarkan nota dan menambah data daripada mesyuarat (transkripsi Granola/Whisperflow/Zoom) ke dalam Wiki.

rocket-karpathy-knowledge-bases:start

rocket-karpathy-knowledge-bases:end

Apabila “Wiki” itu berkembang, menjadi jelas bahawa terdapat nilai sebenar untuk berkongsi maklumat di dalamnya. Oleh itu projek “otak kedua syarikat” mula berkembang. Versi Utopik otak kedua mempunyai segala yang mungkin ditranskripsikan: panggilan zum, mesyuarat F2F, malah interaksi kasual, e-mel, mesej kendur, dokumen – semuanya ke dalam pangkalan data data yang besar seperti Snowflake. Bayangkan sesiapa sahaja dalam syarikat itu boleh bertanyakan contoh Snowflake ini apa sahaja yang mereka mahu dan serta-merta setiap soalan dijawab.

Alamak, bukan idea yang bagus. Pertama, ini sangat mahal. Jumlah data yang masuk ke dalam sesuatu seperti ini adalah gila dan mendapatkan semula data daripadanya menjadi sangat sukar, perlahan dan mahal. Keselamatan dan pengasingan data menjadi isu. Bagaimanakah anda menghalang data peribadi 1:1, data kewangan, keputusan pengurusan, data HR atau bahkan keputusan untuk menamatkan seseorang daripada tergelincir ke dalam transkrip dan boleh diakses. Bukan semua orang sepatutnya tahu segalanya…

Juga, siapa yang memerlukan ini, apakah yang menyelamatkan kita dan adakah ini idea yang baik?

Saya akan mengatakan secara umum, versi yang terkandung ini adalah idea yang baik. Sebahagian besar sebab wujudnya pengurusan pertengahan adalah untuk mengapungkan isu ke hulu dan menjelaskan keputusan di hiliran. Kebanyakan perkara ini kini boleh dilakukan dengan otak kedua.

Otak kedua untuk pasukan teknikal

Otak kedua teknikal boleh menjadi lebih mudah untuk dikekalkan. Banyak syarikat hanya menggunakan direktori Dropbox/Google drive/OneDrive yang menyimpan pengetahuan kongsi yang boleh dikongsi oleh Claude / Codex. Automasi untuk menolak ini ke repo Git agak mudah, atau anda benar-benar boleh menggunakan Github untuk mengurus ini juga (saya rasa ini adalah usaha yang sangat kecil untuk OpenAI/Anthropic untuk menyokong senario ini tanpa perlu memasang kemahiran tersuai untuk menguruskan perkara jenis ini). Sumber kebenaran kini menjadi repo Github dan salinan tempatan adalah repo git tempatan.

Ini boleh menambah pengetahuan dan keupayaan seperti kemahiran berkongsi, keputusan bersama, reka bentuk seni bina, reka bentuk visual (keputusan sistem reka bentuk, contohnya) dan pelbagai keputusan produk syarikat yang lain.

Pasukan kecil tidak benar-benar memerlukan lebih daripada sekadar penyegerakan mudah di sekitar repo, tetapi syarikat yang lebih besar dengan banyak pasukan yang lebih besar akan menghadapi had yang teruk dengan cepat. Isu paling teruk melibatkan keracunan konteks di mana pengguna tertentu mungkin membuat keputusan setempat yang bercanggah dengan data otak kedua, sama ada memperkenalkan data bercanggah atau mengatasi keputusan syarikat secara tidak sengaja (dalam sesetengah kes mungkin dengan sengaja?).

Menyimpannya dalam git dan penggabungan boleh dilakukan menggunakan ejen khusus yang mencari konflik dan boleh memaklumkan pengguna jika perubahan mereka bercanggah, menyelesaikan konflik dan menggabungkan hasilnya.

Ambil perhatian bahawa ini bukan kaedah yang baik untuk mengekalkan dokumentasi projek. Untuk itu, cara yang lebih baik ialah memasukkan wiki sebagai bahagian penting dalam projek itu sendiri. Ia agak mudah untuk dibuat. Anda hanya mengetepikan ejen pengekodan dan memintanya menyemak projek, mendokumentasikannya dengan teliti ke dalam folder dokumen, dipecah mengikut seni bina, gotcha, keputusan produk, keputusan teknikal dan perkara lain yang disimpulkan mungkin berguna dalam fail md kecil yang boleh dikawal. Perkara utama ialah memberitahunya untuk memastikan bahawa kod dan readme.md semua menunjuk ke direktori dokumen untuk memastikan ia dirujuk di mana-mana dan dianggap sebagai sebahagian daripada projek dan bukan sumber luaran. Perkara utama yang perlu diketahui oleh ejen ialah tujuan di sini adalah untuk membenarkan kemasukan ejen lain dengan pantas ke projek untuk mengelakkan perangkap, lubang dan lubang benam teknikal…

Sebaik sahaja ia disepadukan dalam struktur projek repo itu sendiri, ejen pengekodan akan mengekalkannya seolah-olah ia adalah kod. Ia akan membacanya seolah-olah ia adalah sebahagian daripada kod dan jika sesuatu berubah, ia akan menyesuaikan atau mengubah suai dokumentasi (ingat “dokumentasi ialah kod yang mudah dibaca dan jelas” atau “dokumentasi menjadi basi sebaik sahaja ia meninggalkan papan kekunci anda” – percayakan AI untuk mengekalkannya, jadi ia tidak benar lagi).

Otak kedua untuk pasukan produk, pemasaran dan bukan teknikal

Otak kedua jenis ini boleh menjadi sangat keren untuk pasukan teknikal, tetapi melakukan perkara yang sama untuk pasukan bukan teknikal akan menjadi sangat sukar.

Ambil satu pasukan peguam sebagai contoh, mereka mempunyai set pengetahuan yang sangat khusus dan ia merangkumi e-mel, slack, fail perkataan dan dokumen lain. Perkara yang sama berlaku untuk pemegang buku, jualan, kejayaan pelanggan, dll. Mereka masing-masing mempunyai pengetahuan otak kedua mereka sendiri.

Selain itu, pihak pengurusan mungkin mahu data menggelembung (tidak ditapis melalui pengurusan pertengahan) dan pasukan mungkin memerlukan maklumat yang dijana oleh pengurusan. Bagaimana untuk menghasilkan graf pengetahuan berskala yang selamat dan diasingkan?

Terdapat beberapa pendekatan yang boleh membuat perkara lebih mudah, sekurang-kurangnya sehingga budak besar menyelesaikan masalah ini, mudah-mudahan secara terbuka, tetapi lebih cenderung melalui penyelesaian tertutup yang mahal.

1. Otak kedua peribadi – setiap orang yang mahukan ini, boleh menyalin mesyuarat mereka sendiri dan mengekalkan otak kedua mereka sendiri. Obsidian agak berguna untuk ini, mana-mana ejen pada dasarnya boleh menyusun dan membersihkannya. Gunakan mekanisme tidur REM untuk mengoptimumkannya – ejen harus bangun pada waktu malam, mengenal pasti semua maklumat yang dikumpul pada siang hari, mencari sebarang maklumat yang penting dan penting untuk disimpan untuk masa hadapan dan menyusunnya dengan cara yang mudah diperoleh semula dalam folder dan fail MD. Ini bermakna jika anda bercakap dengan pelanggan tertentu, pelanggan tersebut akan mengemas kini fail md yang mencerminkan maklumat yang penting untuk diingati tentang mereka, perkara yang anda sedang usahakan bersama, dsb. Begitu juga dengan projek. Akan ada pertindihan: pertindihan adalah baik – tidak mengapa maklumat tentang projek tertentu disimpan dalam kedua-dua fail orang yang anda bercakap, syarikat dan fail projek. Biarkan ejen menguruskan ini untuk anda. Apabila anda mempunyai soalan, jadikan ini sebagai sumber data utama anda untuk ejen anda. Anda boleh mendedahkan ejen anda kepada e-mel/perbualan/dll. – cuma pastikan anda tidak menyalin perkara yang anda tidak mahu didokumenkan (jangan jadikan ini rancangan realiti atau sabun).

2. Otak kedua peringkat pasukan – lapisan kedua data termasuk data yang sama ada dalam otak kedua peribadi yang ejen pasti 100% berkaitan dengan keseluruhan pasukan atau data yang berasal dari mesyuarat peringkat pasukan yang, mengikut sifat mereka, berasaskan pasukan. Ejen juga boleh mengumpul data untuk otak kedua ini daripada saluran slack pasukan anda – ia tidak sepatutnya berada dalam saluran 1:1 anda atau panggilan zum. Sebaik sahaja ia mendapatkan semula data, ejen boleh mengaturnya dalam masa nyata atau setiap malam dan menunjukkan ketidakkonsistenan di mana keputusan telah dibatalkan, atau tidak sepadan dengan keputusan peribadi atau pengurusan. Perkara itu harus diserlahkan dan dimaklumkan kepada orang yang membuat keputusan yang tidak serasi supaya mereka boleh membuat pilihan mereka dengan cara yang termaklum.

3. Otak kedua peringkat pengurusan – ini pada asasnya otak kedua peringkat pasukan tetapi kerana sensitiviti data dan keputusan yang dibuat, ia harus dikendalikan dengan cara yang lebih bernuansa. Hanya keputusan akhir dan data awam harus dikongsi di sini untuk mengelakkan potensi kebocoran ke seluruh syarikat. Mungkin idea yang baik untuk manusia menyemak beberapa data, sekurang-kurangnya pada mulanya, untuk memastikan keselamatan data. Ia juga merupakan idea yang baik untuk meninggalkan otak pengurusan daripada otak kedua syarikat.

4. Otak kedua syarikat luas – ini adalah yang paling sukar dan hanya perlu menyimpan data yang konkrit, bermaklumat yang mungkin berkaitan dengan keseluruhan syarikat. Keputusan Kewangan yang dilaporkan sahaja, contohnya, maklumat tentang kakitangan (yang memegang jawatan apa).

Ini meninggalkan banyak data, termasuk data sentimen, contohnya, yang ingin didengar oleh pengurusan daripada seluruh pasukan. Ini boleh dikumpulkan secara berasingan atau dituai daripada sumber yang kendur dan lain-lain. Bukan idea yang baik untuk menuai data jenis ini terus dari otak syarikat.

Jadi, apa yang anda cari dalam otak kedua atau otak syarikat, adakah anda mempunyai sebarang percubaan untuk membina satu dan apakah kesimpulan anda?