Blitzy برای کدنویسی خودکار در مقیاس بزرگ به گراف دانش تکیه می‌کند

Blitzy می‌گوید برای آن‌که عامل‌های هوش مصنوعی بتوانند در پروژه‌های نرم‌افزاری بزرگ و به‌هم‌پیوسته تغییر ایجاد کنند، باید پیش از نوشتن کد، ساختار و وابستگی‌های آن را درک کنند. این شرکت از گراف دانش Neo4j برای نمایش ارتباط میان اجزای کد استفاده می‌کند؛ رویکردی که به گفته مدیر مهندسی Blitzy می‌تواند زمینه در دسترس عامل‌ها را دقیق‌تر و محدود به نیاز هر کار تغییر دهد. این موضوع در گفت‌وگویی منتشرشده در ۲۸ سپتامبر ۲۰۲۶، در جریان رویداد GraphSummit مطرح شد.

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

چالش اصلی، فهم کدبیس‌های بزرگ است

Neeraj Deshmukh، مدیر مهندسی Blitzy، در گفت‌وگو با John Furrier از theCUBE گفت مهم‌ترین دشواری در خودکارسازی تغییرات نرم‌افزاری این است که هوش مصنوعی تا چه اندازه سامانه‌ای را که قرار است در آن دست ببرد می‌شناسد. به توضیح او، اصلاح یک خط کد ممکن است پیامدهایی در جایی دورتر از محل تغییر داشته باشد؛ بنابراین عامل باید بتواند ارتباط آن خط با دیگر بخش‌های نرم‌افزار را دنبال کند.

این چالش در کدهای سازمانی پرحجم‌تر می‌شود. Deshmukh برآورد کرد زمینه مؤثر در اختیار عامل‌ها معمولاً حدود ۲۰۰ تا ۳۰۰ هزار توکن است؛ ظرفیتی که او آن را تقریباً معادل ۲۰ تا ۳۰ هزار خط کد دانست. توکن واحدی است که مدل‌های زبانی برای پردازش متن به کار می‌برند. در کدبیس‌هایی با حدود ۱۰۰ میلیون خط، عامل نمی‌تواند همه محتوا را هم‌زمان در این محدوده نگه دارد.

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

چرا کد از نگاه Blitzy یک گراف است

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

پلتفرم Blitzy ابتدا محیط موجود مشتری را مهندسی معکوس می‌کند و از کدبیس یک گراف پویا می‌سازد. این گراف به سامانه‌های کنترل نسخه مانند GitHub و GitLab متصل می‌شود؛ ابزارهایی که تغییرهای کد را ثبت و مدیریت می‌کنند. به‌گفته شرکت، هر بار که توسعه‌دهندگان یا عامل‌ها کد را تغییر دهند، گراف نیز به‌روزرسانی می‌شود تا بازتاب‌دهنده وضعیت تازه کدبیس باشد.

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

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

تأیید انسانی و کنترل کیفیت

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

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

یکی دیگر از اجزای این رویکرد، استفاده از زبان پرس‌وجوی Cypher در Neo4j است. عامل‌های Blitzy به‌طور مداوم با این زبان از گراف پرس‌وجو می‌گیرند. Deshmukh گفت ساختار سخت‌گیرانه Cypher می‌تواند نقش حفاظتی داشته باشد: اگر عامل پرس‌وجوی نامعتبر بسازد، نتیجه‌ای دریافت نمی‌کند. به گفته او، این ویژگی قرار است عامل‌ها را به اطلاعات موجود در گراف محدود کند، نه داده‌هایی که صرفاً به نظرشان محتمل می‌آید.

البته این توضیحات، ادعای مدیر مهندسی Blitzy درباره طراحی سامانه است و به‌تنهایی تضمین نمی‌کند که همه خطاهای عامل‌ها حذف می‌شوند. شرکت برای سنجش عملکرد خود به امتیاز ۸۴٫۹۵ درصد در SWE-Bench Pro اشاره کرده که در ژوئن اعلام شده است. متن گزارش، جزئیات بیشتری درباره شرایط آزمون یا نحوه مقایسه این امتیاز با سامانه‌های دیگر ارائه نمی‌کند؛ بنابراین این عدد باید به‌عنوان نتیجه‌ای که خود شرکت ذکر کرده در نظر گرفته شود.

سرمایه‌گذاری و جایگاه گراف‌های دانش

توجه به این مسئله در بازاری شکل می‌گیرد که سرمایه‌گذاران برای ساخت ابزارهای عامل‌محور هزینه می‌کنند. طبق گزارش SiliconANGLE، Blitzy در ماه مه ۲۰۰ میلیون دلار جذب سرمایه کرد و ارزش‌گذاری آن به ۱٫۴ میلیارد دلار رسید. این شرکت می‌گوید پلتفرمش برای به‌کارگیری هزاران عامل کدنویسی به‌صورت موازی طراحی شده است. بااین‌حال، مقیاس اجرای هم‌زمان عامل‌ها فقط بخشی از مسئله است؛ هرچه تعداد عامل‌ها و حجم کد افزایش یابد، هماهنگی و دسترسی به زمینه درست اهمیت بیشتری پیدا می‌کند.

Neo4j نیز در GraphSummit گراف‌های دانش را به‌عنوان زمینه مشترک برای عامل‌های هوش مصنوعی مطرح کرد. گراف در این کاربرد صرفاً راهی برای ذخیره اطلاعات نیست؛ ساختار آن روابط میان اجزای یک سامانه را آشکار می‌کند و امکان پرس‌وجو درباره آن روابط را فراهم می‌آورد. در توسعه نرم‌افزار، این ویژگی می‌تواند برای یافتن وابستگی‌هایی مفید باشد که با جست‌وجوی ساده در متن کد به‌راحتی دیده نمی‌شوند.

گفت‌وگوی Deshmukh با theCUBE بخشی از پوشش GraphSummit بود. در توضیح منتشرشده همراه گزارش آمده است که theCUBE برای پوشش این رویداد شریک رسانه‌ای پولی بوده و Neo4j حامی آن بوده است؛ همچنین اعلام شده که حامیان بر محتوای theCUBE یا SiliconANGLE کنترل تحریریه‌ای نداشته‌اند. بیان این رابطه برای ارزیابی زمینه انتشار گفت‌وگو اهمیت دارد، به‌ویژه چون بخشی از توضیحات درباره مزایای فنی، از سوی مدیری در شرکت ارائه‌دهنده پلتفرم مطرح شده است.

این خبر برای چه کسانی اهمیت دارد

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

توسعه‌دهندگان ابزارهای هوش مصنوعی و مدیران زیرساخت نیز می‌توانند از این نمونه برای بررسی نقش گراف دانش در اتصال عامل‌ها به اطلاعات ساختاریافته استفاده کنند. بااین‌حال، ارزیابی چنین راهکاری به شواهدی درباره کیفیت کد، نرخ خطا، هزینه اجرا و عملکرد در کدبیس‌های واقعی نیاز دارد؛ اطلاعاتی که در گزارش مطرح‌شده به‌طور کامل ارائه نشده است. آنچه فعلاً روشن است، تأکید Blitzy بر این نکته است که در کدنویسی خودکار در مقیاس بزرگ، فهم رابطه‌های درون نرم‌افزار ممکن است به‌اندازه توانایی تولید کد اهمیت داشته باشد.