کلود گیت را به زانو درآورد! آنتروپیک بعد از انفجار ۱۲ برابری کدهای هوش مصنوعی، سیستم Scion را ساخت

انفجار کدهای هوش مصنوعی؛ وقتی آنتروپیک مجبور شد با گیت خداحافظی کند

شرکت آنتروپیک (Anthropic) گیت (Git) را در مونو‌ریپوی (Monorepo) داخلی خود کنار گذاشت و سامانه اختصاصی Scion را جایگزین آن کرد؛ سیستم کنترل نسخه‌ای که به‌طور ویژه برای ایجنت‌های تولیدکننده کد و اتوماسیون‌های عظیم مقیاس‌بزرگ مهندسی شده است. بر اساس گزارش فنی آنتروپیک، تنها هفت مهندس موفق شدند این سامانه را بسازند و کل زیرساخت مونو‌ریپو را ظرف حدود پنج ماه به آن منتقل کنند.

عامل اصلی این تغییر رادیکال، سیل خروشان کدهایی بود که توسط هوش مصنوعی کلود (Claude) تولید می‌شد. نرخ ثبت تغییرات و مرج (Merge) در آنتروپیک بین ماه‌های می تا سپتامبر بیش از ۱۲ برابر جهش کرد؛ رقمی جنون‌آمیز که کل زیرساخت سنتی شرکت را که بر پایه مخازن محلی، صف‌های ترتیبی مرج و چرخه‌های کاری توسعه‌دهندگان انسانی بنا شده بود، زیر فشار کمرشکن خود مدفون کرد.

وقتی مدل محلی گیت به سد محکم ۳۰ هزار مرج روزانه برخورد کرد

معماری و مدل داده‌ای گیت طوری طراحی شده که ترجیح می‌دهد یک نسخه کامل و محلی از کل مخزن را نگهداری کند؛ البته قابلیت‌هایی مثل Shallow Clone، Sparse Checkout و Partial Clone وجود دارند که حجم دیتای دانلودی کلاینت را کاهش می‌دهند، اما وقتی پای میلیون‌ها جابِ کوتاه‌عمر و موقت در میان باشد که هرکدام فقط به بخش کوچکی از یک مونو‌ریپوی عظیم نیاز دارند، این مدل سنتی هزینه‌های سرسام‌آوری به بار می‌آورد.

دریافت یک نسخه کاری فشرده‌شده به ازای هر عملیات چک‌اوت در پایپ‌لاین‌های CI (ادغام مداوم)، می‌توانست روزانه بیش از ۶۰۰ پتابایت ترافیک در شبکه تولید کند! آنتروپیک در ابتدا تلاش کرد با تکنیک‌هایی مثل کلون‌های کم‌عمق، چک‌اوت‌های تنک (Sparse)، ریموت‌های وعده‌دهنده (Promisor Remotes)، اسنپ‌شات‌های اولیه در حافظه ابری و صدها سرور بازتابی (Mirror) داخلی این فشار را مهار کند.

اما این راه‌حل‌های موقت، خودشان دردسرهای هماهنگی تازه‌ای درست کردند. با بالا رفتن سرعت مرج کدهای جدید، همگام‌سازی سرور‌های میرور عملاً غیرممکن شد؛ در حالی که تسک‌های CI، محیط‌های ایزوله ایجنت‌ها، سیستم‌های توسعه‌دهندگان و بارهای پردازشی تحقیقاتی بی‌وقفه خواهان دریافت آخرین وضعیت به‌روز مخزن بودند.

از طرفی، تقریباً تمام کلاینت‌ها و سیستم‌های آنتروپیک از قبل به شبکه پرسرعت متصل هستند. در نتیجه، تمرکز سنتی گیت روی «کارکرد آفلاین» عملاً هزینه‌های سنگین ذخیره‌سازی و همگام‌سازی را تحمیل می‌کرد، بدون اینکه در تسک‌ها و ورک‌لودهای اصلی هیچ ارزش افزوده‌ای داشته باشد.

سامانه Scion؛ تبدیل کنترل نسخه از نرم‌افزار به یک سرویس ابری تمام‌عیار

سیستم Scion با الهام از ایده‌های پایپر (Piper) در گوگل و سپلینگ (Sapling) در شرکت متا توسعه یافته، اما معماری‌اش کاملاً برای ایجنت‌های آنلاین و جاب‌های پردازشی یک‌بارمصرف بهینه‌سازی شده است. در این سیستم، کلاینت‌ها کم‌ترین وضعیت محلی (State) را نگه می‌دارند و سرور‌ها همان کار‌هایی را انجام می‌دهند که گیت قبلاً درون سیستم توسعه‌دهنده به دوش می‌کشید.

• کلاینت‌های کاملاً آنلاین: کلاینت‌ها به جای کلون کردن کل تاریخچه پروژه، فقط دیتای مورد نیاز لحظه‌ای را از مخزن درخواست می‌کنند.
• حداقل وضعیت در سیستم محلی: کلاینت فقط یک کش محدود از اشیاء را مدیریت می‌کند، فایل‌های نسخه کاری را می‌نویسد، تغییرات فایل‌سیستم را رصد می‌کند و دستورها را به کاربران و ابزار‌ها تحویل می‌دهد.
• عملیات تماماً سرورمحور: عملیات‌هایی نظیر Commit، Merge، Rebase، Diff، بررسی تاریخچه شاخه‌ها و محاسبات Blame همگی در سمت سرور اجرا می‌شوند.
• رابط‌های برنامه‌نویسی کنترل نسخه (APIs): ابزار‌ها بدون نیاز به ساخت یک مخزن محلی، متدهای RPC (فراخوانی رویه از راه دور) را صدا می‌زنند؛ یعنی یک درخواست ساده تحت شبکه که از سرور می‌خواهد عملیات را انجام دهد.
• فضای ذخیره‌سازی توزیع‌شده: داده‌های مخزن بین سرویس‌هایی پخش شده‌اند که هرکدام مستقل مقیاس‌پذیر هستند و هیچ سروری نسخه کامل و یک‌تکه از مونو‌ریپو را نگه نمی‌دارد.
• محدود کردن ارجاعات سراسری: سامانه Scion ساخت شاخه‌ها و برچسب‌های پراکنده خارج از شاخه‌های اصلی و انتشار را به حداقل می‌رساند؛ چون نشانگرهای مشترک نیاز به هماهنگی سنگین میان نویسندگان دارند.
• نسخه‌های کاری تنک (Sparse): فرایند چک‌اوت به صورت مجازی‌سازی‌شده انجام می‌شود و فایل‌ها تنها زمانی روی دیسک متولد می‌شوند که یک پروسس صراحتاً به آن‌ها نیاز داشته باشد.

علاوه بر این، Scion بسته‌های فشرده پک‌فایل (Packfile) در گیت را که اشیاء مخزن را برای ذخیره و جابه‌جایی دسته‌بندی می‌کرد، کاملاً حذف کرده است. حذف این بسته‌ها نیاز به تعمیر و نگهداری مداوم مخزن را از بین برده و به لایه‌های مختلف ذخیره‌سازی اجازه می‌دهد اشیای تغییرناپذیر (Immutable) را به شکل مستقیم سرو کنند.

چنج‌ست‌ها؛ کلید عبور از گلوگاه عملیات نوشتن

عملیات نوشتن در سامانه Scion از طریق یک لاگ پیش‌نویس (Write-Ahead Log) انجام می‌شود؛ یک رکورد مرتب که عملیات را قبل از پردازش توسط سیستم‌های بعدی ثبت دائمی می‌کند. کوچک‌ترین واحد ثبت‌شده در این لاگ، یک «چنج‌ست» (Changeset) است.

در گیت، هر کامیت به درختی اشاره می‌کند که اسنپ‌شات کاملی از کل دایرکتوری را نمایش می‌دهد. اما در Scion، یک چنج‌ست تنها فایل‌های تغییریافته نسبت به والد اول خود را فهرست می‌کند و ارجاعات آدرس‌دهی‌شده بر اساس محتوا (Content-Addressed) را برای دیتای فشرده فایل در حافظه Blob نگه می‌دارد. سیستم آدرس‌دهی مبتنی بر محتوا، هر شیء را بر اساس هش محتوایش شناسایی می‌کند؛ بنابراین محتواهای تکراری و یکسان می‌توانند یک شیء ذخیره‌شده مشترک داشته باشند.

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

البته از آنجا که هر چنج‌ست فقط فایل‌های تغییریافته را نگه می‌دارد، کوئری‌های بررسی تاریخچه نیاز به ایندکس‌های مجزا دارند. Scion ساختارهای داده‌ای هوشمندی برای نسبت دادن خطوط (Blame)، تاریخچه مسیرها و لیست‌های جهشی گراف کامیت استخراج می‌کند که به سرویس اجازه می‌دهد بدون نیاز به بررسی تک‌تک کامیت‌های میانی، مستقیماً میان اجداد تاریخی بپرد.

هرکدام از این ایندکس‌ها را می‌توان بر اساس داده‌های والد و چنج‌ست فعلی محاسبه کرد؛ چه در لحظه ورود تغییر و چه زمانی که یک کوئری برای اولین بار به آن نیاز پیدا کند. نکته جذاب اینجاست که کلاینت‌ها هرگز به ساختار بازنمایی داخلی وابسته نیستند؛ این استقلال به آنتروپیک اجازه می‌دهد ایندکس‌ها را جایگزین کند یا قابلیت‌هایی مثل ردیابی کپی و جستجوی مسیرها را بدون تغییر در عملکرد کلاینت‌ها اضافه نماید.

دریافت دیتا؛ فرآیندی سریع و روان درست مثل جستجو در CDN

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

کلاینت کارش را با درخت ریشه (Root Tree) شروع می‌کند، حافظه محلی خود را بررسی کرده و درخت‌های فرزندِ ناموجود را به شکل بازگشتی درخواست می‌دهد. سپس همین مسیر را برای بلاب‌های فایل تکرار می‌کند. از آنجا که تک‌تک اشیاء تغییرناپذیر هستند و با هش محتوا آدرس‌دهی می‌شوند، هر سرور کِشی که این شیء را داشته باشد، فوراً می‌تواند به درخواست پاسخ دهد.

درخواست‌ها ابتدا به دیمون محلی هر نود به نام scion-daemon می‌رسند، سپس راهی کِش منطقه‌ای scion-cache می‌شوند و در صورت نیاز، به سرور‌های مرجع scion-server که متکی به دیتابیس Spanner گوگل و فضاهای ابری ذخیره شیء هستند هدایت می‌گردند. جالب اینکه تمام این لایه‌ها از متدهای RPC کاملاً یکسانی پشتیبانی می‌کنند.

سرور‌های کِش، اشیاء را مستقیماً با همان فرمتی روی دیسک استریم می‌کنند که دیمون به آن نیاز دارد. این ترفند هوشمندانه، بار پردازشی سنگین پردازنده (CPU) و پیچیدگی پروتکل‌های انتقال فشرده دلتا (Delta-Compression) را برای هر کلاینت از میان برداشته است.

آنتروپیک گزارش داده که نرخ موفقیت کِش (Cache Hit Rate) در تمام لایه‌ها به بالای ۹۹ درصد رسیده است، آن هم بدون نیاز به حفظ دائمی وضعیت کِش. پیاده‌سازی Scion تنها حدود یک دویستم پردازنده و حافظه رم ناوگان قبلی سرور‌های میرور گیت را مصرف می‌کند! عملیات چک‌اوت در CI و بارهای تحقیقاتی حالا به جای چند دقیقه، ظرف چند ثانیه تمام می‌شوند و همین سرعت بالا، ۲۵ درصد از ظرفیت پردازشی کل ناوگان را آزاد کرده است.

اعتراف جالب مهندسان: بیش‌تر کدهای Scion را خودِ کلود نوشت!

آنتروپیک فاش کرده که هوش مصنوعی کلود بخش اعظم کدهای پیاده‌سازی Scion را نوشته است، در حالی که مهندسان انسانی روی طراحی معماری کلان، اهداف مقیاس‌پذیری و اصول پایدار سیستم نظارت می‌کردند. حتی یک بیلد داخلی اولیه از پیش‌نمایش کلود میتوس (Claude Mythos Preview) پایپ‌لاین دستی انتقال اطلاعات از گیت به Scion را بدون هیچ دستورالعمل اضافی بازنویسی کرد؛ بازنویسی شگفت‌انگیزی که مصرف حافظه را ۲۰ برابر کاهش داد و سرعت اجرا را ۴ برابر بیش‌تر کرد، در حالی که تمام قوانین انتقال دیتا دست‌نخورده باقی ماند.

تک‌تک مهندسان حاضر در این پروژه به آنتروپیک اعلام کردند که در مهارت کدنویسی خالص، نمره کلود را بالا‌تر از خودشان ارزیابی می‌کنند! تمرکز اصلی این تیم روی طراحی بین‌سیستمی، سبک و سنگین کردن راهکارها و بازبینی کدها بود. آن‌ها بارها تغییرات پیشنهادی ایجنت‌ها را رد کردند؛ به‌ویژه در مواردی که کد در ظاهر نیاز اولیه را برطرف می‌کرد اما یکی از اصول بنیادین سیستم را نقض می‌نمود، یا مواردی که ایجنت دفاعیه‌های پیچیده و غیرضروری در برابر کامنت‌های فرضی بازبینی اضافه کرده بود.

آنتروپیک سیستمی به نام «سوپرفن‌ها» (Superfans) را هم راه‌اندازی کرده است؛ نمونه‌هایی اختصاصی از کلود که در کانال‌های اسلَک مربوط به هر بخش مستقر شده‌اند. هر نمونه داده‌های تله‌متری و لاگ‌های سیستم‌هایی مانند scion-daemon، scion-cache و صف مرج داخلی Antique را به طور مداوم پایش می‌کند. به گفته شرکت، این ایجنت‌های هوشمند خطاهای ظریف و عجیبی را شکار می‌کنند که هشدارهای سنتی مبتنی بر آستانه (Threshold) به راحتی از کنار آن‌ها رد می‌شوند.

درس‌های مهمی که سایر تیم‌های فنی می‌توانند یاد بگیرند

سامانه Scion برای مونو‌ریپوهایی ساخته شده که به ده‌ها هزار مهندس یا ناوگان عظیمی از ایجنت‌های تولیدکننده کد سرویس می‌دهند. آنتروپیک هنوز برنامه‌ای برای انتشار عمومی آن اعلام نکرده و شرکت اذعان دارد که هزینه توکن‌های مصرفی‌اش برای ابزار‌های داخلی، از کل بودجه مورد قبول اکثر سازمان‌ها فراتر می‌رود.

1. حذف صف‌های ترتیبی در سطح کل مخزن: صف مرجی که کل مخزن را قفل می‌کند، با افزایش همزمانی تغییرات عملاً گلوگاه بازدهی می‌شود. آنتروپیک فرآیند اعتبارسنجی را به مراحل پس از مرج و قبل از استقرار منتقل کرده تا اجازه دهد تغییرات همزمان ثبت شوند و سپس از کلود برای حل تعارض‌ها (Conflicts) کمک می‌گیرد.
2. مدیریت نتایج تاریخ‌گذشته در پایپ‌لاین‌های CI: ممکن است در زمان اجرای یک تست، هزاران تغییر جدید به مخزن اضافه شوند. سیستم‌های CI باید دقیقاً ردیابی کنند که نتیجه تست مربوط به کدام وضعیت مخزن بوده و چه زمانی تغییرات جدید نیازمند اجرای دوباره تست هستند.
3. جداسازی معماری سرور از رفتار کلاینت: سرویس‌های سازگار با گیت می‌توانند از متدهای RPC سرورمحور، سیستم‌های کِش هوشمند، مذاکره بهینه‌تر و چک‌اوت‌های تنک منعطف استفاده کنند، بدون اینکه مجبور باشند پیاده‌سازی محلی گیت را کپی نمایند. آنتروپیک در همین راستا به پتانسیل همکاری با پروژه Sapling، گیتهاب (GitHub) و گیت‌لب (GitLab) اشاره کرده است.

بیش‌تر سازمان‌های نرم‌افزاری هنوز فاصله‌ای نجومی با حجم کاری اعلام‌شده آنتروپیک دارند. اما درس اصلی کاملاً روشن است: وقتی ایجنت‌های هوش مصنوعی به تولیدکنندگان اصلی کد تبدیل می‌شوند، سیستم‌های کنترل نسخه، هماهنگی مرج و پایپ‌لاین‌های CI باید بر اساس سرعت و همزمانی ماشین‌ها مقیاس‌بندی شوند، نه ریتم آرام ثبت کد توسط توسعه‌دهندگان انسانی!