مغز دوم شرکت: از ویکی گرفته تا مهارت ها، همه چیز مربوط به زمینه است1 min read

من در مورد تمام هیاهوهای پیرامون “مغز دوم” بسیار فکر کرده ام. من این موضوع را با دیگران در این زمینه و همکارانم که یا در حال ساختن مغز دوم هستند یا نسخه ای از آن دارند، بحث کردم.

برای کسانی که آشنایی ندارند، دومین حرکت مغز با ایده “ویکی” توسط آندری کارپاتی آغاز شد: سازماندهی دانش شخصی عامل در نوعی ساختار ویکی به هم پیوسته از فایل های MD محلی. این بعداً به سازمان‌دهی داده‌های شخصی در قالبی بسیار گسترده‌تر گسترش یافت، به طوری که کاربران اغلب از Obsidian برای سازماندهی و تجسم یادداشت‌ها استفاده می‌کردند و داده‌های جلسات (رونوشت‌های Granola/Whisperflow/Zoom) را به ویکی اضافه می‌کردند.

موشک-کارپاتی-پایه های دانش:شروع

‏Rocket-karpathy-knowledge-bases:end

همانطور که “ویکی” گسترش یافت، آشکار شد که اشتراک گذاری اطلاعات در آن ارزش واقعی دارد. بنابراین پروژه های “مغز دوم شرکت” شروع به شکوفایی کردند. نسخه Utopic یک مغز دوم همه چیز ممکن را رونویسی می کند: تماس زوم، جلسات F2F، حتی تعاملات معمولی، ایمیل ها، پیام های شل، اسناد – همه در یک پایگاه داده عظیم مانند Snowflake. تصور کنید که هر کسی در شرکت می تواند هر چیزی را که می خواهد از این نمونه برف ریزه بپرسد و بلافاصله به هر سوالی پاسخ داده شود.

اوه، ایده خوبی نیست. اولاً این بسیار گران است. حجم داده‌هایی که به چنین چیزی وارد می‌شوند بسیار دیوانه‌کننده است و بازیابی داده‌ها از آن بسیار دشوار، کند و پرهزینه می‌شود. امنیت و تفکیک داده ها به یک مسئله تبدیل شده است. چگونه می‌توانید از ورود داده‌های شخصی، داده‌های مالی، تصمیم‌های مدیریت، داده‌های منابع انسانی یا حتی تصمیمات برای خاتمه دادن به شخصی در رونوشت‌ها و در دسترس بودن 1:1 جلوگیری کنید. نه همه باید همه چیز را بداند…

همچنین، چه کسی به این نیاز دارد، چه چیزی ما را نجات می دهد و آیا این ایده خوبی است؟

من به طور کلی می گویم، یک نسخه حاوی این ایده خوبی است. بسیاری از دلایل وجود مدیریت میانی این است که مسائل را در بالادست مطرح کرده و تصمیمات را در پایین دست روشن می کند. بسیاری از این کارها اکنون با مغز دوم قابل انجام است.

مغز دوم برای تیم های فنی

نگهداری مغز دوم فنی می تواند بسیار ساده تر باشد. بسیاری از شرکت‌ها فقط از دایرکتوری Dropbox/Google Drive/OneDrive استفاده می‌کنند که دانش مشترکی را که Claude/Codex می‌تواند به اشتراک بگذارد را در خود نگه می‌دارد. اتوماسیون برای فشار دادن این به یک مخزن Git بسیار ساده است، یا واقعاً می‌توانید از Github برای مدیریت آن نیز استفاده کنید (من حدس می‌زنم این تلاش بسیار کوچکی برای OpenAI/Anthropic برای پشتیبانی از این سناریو بدون نیاز به نصب مهارت‌های سفارشی برای مدیریت این نوع چیزها است). منبع حقیقت اکنون به مخزن Github تبدیل می شود و نسخه های محلی مخازن git محلی هستند.

این می‌تواند دانش و قابلیت‌هایی مانند مهارت‌های مشترک، تصمیم‌های مشترک، طرح‌های معماری، طرح‌های بصری (مثلاً تصمیم‌گیری‌های سیستم طراحی) و تصمیم‌های مختلف محصولات شرکت را اضافه کند.

تیم‌های کوچک واقعاً به چیزی فراتر از یک همگام‌سازی ساده در اطراف مخزن نیاز ندارند، اما شرکت‌های بزرگ‌تر با تعداد تیم‌های بزرگ‌تر خیلی سریع با محدودیت‌های شدید مواجه می‌شوند. شدیدترین مسائل مربوط به مسمومیت با زمینه است که در آن یک کاربر خاص ممکن است تصمیمات محلی اتخاذ کند که با داده های مغز دوم در تضاد باشد، یا داده های متناقض را معرفی کند یا تصمیمات شرکت را به طور سهوی لغو کند (در برخی موارد شاید عمدا؟).

نگه‌داشتن آن در git و ادغام می‌تواند با استفاده از یک عامل اختصاصی انجام شود که به دنبال تداخل می‌گردد و می‌تواند در صورت تداخل تغییرات به کاربر هشدار دهد، تضادها را حل کند و نتایج را ادغام کند.

توجه داشته باشید که این روش مناسبی برای نگهداری اسناد پروژه نیست. برای آن، راه بهتر این است که ویکی را به عنوان بخشی جدایی ناپذیر از خود پروژه قرار دهیم. ایجاد آن بسیار آسان است. شما فقط یک عامل کد نویسی را کنار می گذارید و از آن می خواهید که پروژه را بررسی کند، آن را به طور کامل در یک پوشه اسناد مستند کند، تقسیم بر اساس معماری، گوچاها، تصمیمات محصول، تصمیمات فنی، و چیزهایی که نتیجه می گیرد ممکن است در فایل های md کوچک قابل نگهداری مفید باشد. نکته کلیدی این است که به آن بگویید مطمئن شود که کد و readme.md همه به دایرکتوری اسناد اشاره می کنند تا اطمینان حاصل شود که در همه جا ارجاع داده شده و بخشی از پروژه در نظر گرفته می شود و نه یک منبع خارجی. نکته کلیدی که عامل باید بداند این است که هدف در اینجا اجازه ورود سریع یک عامل دیگر به پروژه است تا از دام ها، چاله ها و فروچاله های فنی جلوگیری شود.

هنگامی که در خود ساختار پروژه مخزن ادغام شد، عامل کد نویس آن را به گونه ای حفظ می کند که گویی کد است. آن را طوری می خواند که گویی بخشی از کد است و اگر چیزی تغییر کند، اسناد را تطبیق یا تغییر می دهد (به یاد داشته باشید که “اسناد، کدی است که به راحتی خوانده می شود و پاک می شود” یا “اسناد در لحظه ای که صفحه کلید شما را ترک می کند کهنه می شود” – به هوش مصنوعی اعتماد کنید که آنها را حفظ کند، بنابراین دیگر درست نیستند).

مغز دوم برای محصول، بازاریابی و تیم های غیر فنی

این نوع مغز دوم می تواند برای تیم های فنی واقعا جالب باشد، اما انجام همین کار برای تیم های غیر فنی بسیار دشوار خواهد بود.

به عنوان مثال تیمی از وکلا را در نظر بگیرید، آنها مجموعه های دانش بسیار خاصی دارند و در سراسر ایمیل، اسلک، فایل های word و سایر اسناد را شامل می شود. همین امر در مورد حسابداران، فروش، موفقیت مشتری و غیره نیز صدق می کند. آنها هر کدام دانش مغز دوم خود را دارند.

علاوه بر این، مدیریت احتمالاً می خواهد داده ها حباب شوند (فیلتر نشده از طریق مدیریت میانی) و تیم ممکن است به اطلاعاتی که مدیریت تولید کرده است نیاز داشته باشد. چگونه یک نمودار دانش مقیاس پذیر تولید کنیم که ایمن و جدا شده باشد؟

چند رویکرد وجود دارد که می‌تواند کارها را آسان‌تر کند، حداقل تا زمانی که پسران بزرگ این مشکل را حل کنند، امیدوارم به روشی باز، اما به احتمال زیاد از طریق یک راه‌حل بسته گران قیمت.

1. مغز دوم شخصی – هر فردی که این را می خواهد، می تواند جلسات خود را رونویسی کند و مغز دوم خود را حفظ کند. Obsidian برای این کار کاملاً مفید است، هر عاملی می تواند اساساً آن را مرتب و تمیز کند. از مکانیسم خواب REM برای بهینه سازی آن استفاده کنید – یک عامل باید در شب از خواب بیدار شود، تمام اطلاعاتی را که در طول روز جمع آوری کرده است شناسایی کند، هر اطلاعاتی را که برای آینده نگه داری شود حیاتی و مهم است بیابد و به روشی به راحتی قابل بازیابی در پوشه ها و فایل های MD سازماندهی کند. این بدان معناست که اگر با یک مشتری خاص صحبت کردید، آن مشتری یک فایل md به‌روزرسانی می‌کند که منعکس‌کننده اطلاعاتی است که مهم است در مورد آنها به خاطر بسپارید، روی آن چه با هم کار می‌کنید و غیره. همین امر در مورد پروژه‌ها نیز صدق می‌کند. همپوشانی وجود خواهد داشت: همپوشانی خوب است – اشکالی ندارد که اطلاعات مربوط به یک پروژه خاص هم در پرونده شخصی که با او صحبت کرده اید، هم در شرکت و هم در پرونده های پروژه وجود داشته باشد. اجازه دهید نماینده این را برای شما مدیریت کند. وقتی سؤالی دارید، این را منبع داده اصلی خود برای نماینده خود قرار دهید. شما می توانید نماینده خود را در معرض ایمیل / مکالمات / و غیره خود قرار دهید. – فقط مطمئن شوید که چیزهایی را که نمی خواهید مستندسازی کنید رونویسی نکنید (بیایید این را یک نمایش واقعی یا یک صابون نسازیم).

2. مغز دوم سطح تیم – لایه دوم داده شامل داده هایی است که یا در مغز دوم شخصی وجود دارد که نماینده 100% مطمئن است که به کل تیم مربوط است یا داده هایی که از جلسات سطح تیمی که طبیعتاً مبتنی بر تیم هستند منشاء گرفته اند. یک نماینده همچنین می‌تواند داده‌های این مغز دوم را از کانال‌های شل تیم شما جمع‌آوری کند – این اطلاعات نباید در کانال‌های 1:1 یا تماس‌های زوم شما باشد. هنگامی که داده ها را بازیابی می کند، یک نماینده می تواند آن ها را در زمان واقعی یا هر شب سازماندهی کند و به ناهماهنگی هایی که تصمیمات لغو شده است یا با تصمیمات شخصی یا مدیریتی مطابقت ندارد، اشاره کند. این موارد باید برجسته شوند و به فردی که تصمیم ناسازگار می گیرد هشدار داده شود تا بتواند انتخاب های خود را به شیوه ای آگاهانه انجام دهد.

3. سطح مدیریت مغز دوم – این اساساً یک مغز دوم در سطح تیم است، اما به دلیل حساسیت داده‌ها و تصمیم‌گیری‌ها، باید به شیوه‌ای بسیار ظریف‌تر مدیریت شود. فقط تصمیمات نهایی و داده های عمومی باید در اینجا به اشتراک گذاشته شود تا از نشت احتمالی به بقیه شرکت جلوگیری شود. ممکن است ایده خوبی برای انسان باشد که حداقل در ابتدا برخی از داده ها را بررسی کند تا از امنیت داده ها اطمینان حاصل کند. همچنین ایده خوبی است که مغز مدیریت را از مغز دوم شرکت خارج کنید.

4. مغز دوم گسترده شرکت – این سخت‌ترین مورد است و باید فقط داده‌های ملموس و اطلاعاتی را در خود داشته باشد که می‌تواند به کل شرکت مرتبط باشد. فقط نتایج مالی گزارش شده، به عنوان مثال، اطلاعات در مورد پرسنل (چه کسی چه موقعیتی دارد).

این باعث می‌شود بسیاری از داده‌ها، از جمله داده‌های احساسی، که مدیریت می‌خواهد از کل تیم بشنود، کنار بگذارد. این را می توان به طور جداگانه جمع آوری کرد یا از منابع دیگر برداشت کرد. برداشت مستقیم این نوع داده ها از مغز شرکت ایده خوبی نیست.

بنابراین، در مغز دوم یا یک مغز شرکتی به دنبال چه چیزی هستید، آیا تلاشی برای ساختن آن داشته اید و نتیجه گیری شما چه بوده است؟