این روز ها کمتر جایی هست که در مورد هوش مصنوعی و استفاده از LLM ها صحبت نشود . LLM ها نه تنها مورد استفاده ی دانشجویان و افراد متخصص قرار میگیرد بلکه مردم عادی هم از این مدل ها استفاده میکنند . در بحث سرمایه گذاری هم اکثر شرکت های بزرگ سعی دارند مدل های زبانی بزرگ خودشان را اموزش و عرضه کنند . این موضوع به قدری داغ است که مدیر عامل شرکت بزرگ اینتل وارد نشدن در این عرصه را دلیل شکست اینتل میداند .
امروزه LLM ها در تولید محتوا ، آموزش و یادگیری ، خودکار سازی فرایند ها و خیلی حوزه های دیگر به کار میرود . در مهندسی نرم افزار و خصوصا نوشتن کد تلاش های زیادی توسط شرکت های آموزش دهنده ی مدل ها و همینطور محققان انجام شده است . یکی از عامل های اصلی برای ارزیابی مدل های زبانی بزرگ قدرت آنها برای درک و نوشتن کد و باقی موضوعات زیر مجموعه ی مهندسی کامپیوتر است .
تحقیقاتی که در زمینه ی معماری نرم افزار انجام شده است میگویند LLM ها نه یک ابزار مهندسی است و نه یک متودولوژی . بلکه یک عامل الهام بخش است که گاهی اوقات میتواند پیشنهاداتی بدهد که شما دیدگاه جدیدی به دست بیاورید .
مشکلات بزرگی که تحقیقات و استفاده های شخصی از LLM ها در معماری نرم افزار میگویند این است که اگر مدل ها نمیتوانند خروجی قابل استفاده برای معماران بسازند و اتوماتیک شدن در این زمینه شدنی نیست . هر چند میتوانند یک ابزار کمکی باشند اما حتما نیاز به برسی یک معمار متخصص را دارند . معمار باید مرحله به مرحله ایرادات را به مدل بازگو کند و با برسی فراوان و یک پرامپت دقیق مدل را یک مرحله جلو تر ببرد تا تغیرات مد نظر او اعمال شود.
مشکل دیگر که حتی باعث پدید امدن مشکل قبلی هم میشود و یکی از ایرادات اصلی مدل ها است مشکل توهم یا Hallucination است . به این معنی که مدل با اعتماد به نفس کامل کار اشتباهی انجام میدهد و اگر کسی در ان زمینه اطلاعاتی نداشته باشد متوجه اشتباه مدل نمیشود .
اگر چک کردن پاسخ های مدل را به یک مدل قدرتمند دیگر بسپاریم تا حد بسیار زیادی این مشکل حل خواهد شد . یک مدل قدرتمند دیگر که در ان زمینه هم آموزش دیده است میتواند اگر ایراداتی ناشی از توهم در خروجی مدل اول وجود داشت ان را کشف کنند . طبق تجربه ی شخصی و مقالاتی که در این زمینه وجود دارد عامل ها در برسی و اشکال زدایی میتوانند عملکرد بهتری از تولید داشته باشند .
این موضوع باعث شد که یک سیستم چند عاملی پیاده سازی شود که در این زمینه تلاش کند تا بتوان خروجی بهتر و قابل اعتماد تری به دست آورد . این سیستم چند عاملی یک سند معماری مینویسد و چون سند معماری بخش ها مختلفی دارد که تمامی آن بخش ها از ارتباط نسبی برخوردار هستن و متن و تصاویر زیادی دارند برای ارزیابی این سیستم میتوانند مناسب باشند .
روش انجام به این صورت است که یکبار خروجی توسط سیستم چند عاملی تولید میشود و یکبار هم توسط یک مدل بسیار قوی تر و سپس خروجی آنها با هم مقایسه میشود تا نتیجه بگیریم که سیستم چند عاملی با مدل ضعیف تر بهتر است یا مدل تک عامله با مدل قوی تر.
میتوانید فایل کد و خروجی سیستم چند عامل و خروجی سیستم تک عامله و همینطور گزارش پروژه را در لینک زیر دانلود و استفاده کنید:
https://github.com/mahhyar/multiagent
همانطور که در کد ارائه شده قابل مشاهده است در این قسمت که متغیر PROJECT_BRIEF تعریف شده است در واقع پرامپت ورودی است که ما به سیستم میدهیم . میتوانیم با تغییر دادن مقدار این متغیر پروژه را عوض کنیم .
در این سیتم از چند عامل زیر استفاده شده است :
DraftAgent (عامل پیشنویس): اولین متن خام سند معماری را تولید میکند.
ReviewerAgent (عامل بازبین): متن خام را بازبینی و از نظر فنی و کیفی آن را تکمیل میکند.
DiagramAgent (عامل طراح نمودار): متن معماری را دریافت و چهار نمودار اصلی UML را بر اساس آن میسازد.
SyntaxCorrectionAgent (عامل اصلاح کد): کدهای PlantUML را بررسی میکند تا اگر خطای نوشتاری دارند آنها را اصلاح کند.
ConsistencyAgent (عامل بررسی سازگاری): مهمترین وظیفه را بر عهده دارد یعنی بررسی اینکه آیا بین متن سند و نمودارها تناقض منطقی وجود دارد یا خیر.
RefinementAgent (عامل اصلاح نهایی): گزارش عامل سازگاری را دریافت و بر اساس آن، کل سند را برای رفع مشکلات بازنویسی میکند.
طبق تصویر بالا عامل ها با یکدیگر در تولید این سند همکاری میکردند. حلقه ای که در تصویر هم مشاهده میکنید سه بار اجرا میشد تا نقص هایی که دارد بر طرف شود .
خروجی سیستم چندعاملی شامل یک سند Word و چهار نمودار UML بود. سند بخشهای اصلی معماری (مقدمه، اهداف، میکروسرویسها، فناوریها، امنیت و استقرار) را پوشش داد اما در بعضی قسمتها محتوای آن سطحی و کلی باقی ماند (مثل CI/CD و مستندات API). نمودارهای UML تولیدشده در سطح مفهومی مفید بودند، ولی جزئیات و انطباق کامل با متن را نداشتند مثلا برخی کلاسها یا سناریوهای مهم غایب بودند. با این حال، وجود خودکار هر چهار نمودار یک دستاورد مثبت محسوب میشود.
و در مقابل برای تست مدل تک عاملی از مدل قدرتمند GROK استفاده شده است که پرامپت زیر به آن داده شده است:
لطفا برای من یک سند معماری برای یک فروشگاه آنلاین بنویس.
این فروشگاه باید قابلیتهایی مانند مدیریت کاربران، سبد خرید، پرداخت آنلاین و جست و جوی محصولات داشته باشد.
لطفا سند شامل بخشهای مهم معماری باشد و به زبان فارسی نوشته شود.
خروجی که به ما داد یک فایل word نبود و فقط متنی بود که داخل سایت رسمی گراک برایم ارسال شد . برای نمایش بهتر من ان را داخل ورد کپی پیست کردم که در لینک فایل ها هم قابل مشاهده است. این خروجی نشان داد که متن آن گرچه روان و رسمی است اما فاقد نمودار و بازبینی چندمرحلهای است.
این پروژه نشان داد با وجود اینکه مدل چند عامله از مدل بسیار ضعیف تر gemini 1.5 استفاده کرد اما خروجی بهتری نسبت به مدل تک عامله ی قوی تر ساخت که این ارزشمند است . اما همانگونه که مشاهده کردید هنوز نمیشود این خروجی را به عنوان خروجی که هیچ ایراد فنی و مفهومی ندارد حساب کرد . اما اگر از مدل های قوی تر مثل جمنای 2.5 یا gpt 5 به صورت چند عامله استفاده کنیم خروجی خیلی بهتری به ما میدهد . همچنین به دلیل کمبود اعتبار api key سعی بر این شد که مراحل کمتری را در سیستم داشته باشیم . اگر تعداد اجرای حلقه ی بازخورد را اضافه کنیم و همچنین از دو مدل مختلف قدرتمند تر استفاده کنیم خروجی بسیار بهتری میگیریم. باز با این حال خروجی که گرفتیم بسیار بهتر از خروجی سیستم تک عامله هست.
"این مطلب ، بخشی از تمرینات درس معماری نرم افزار دانشگاه شهید بهشتی است"
منابع:
Will Generative AI Fill the Automation Gap in Software Architecting?
State of practice: LLMs in software engineering and software architecture
Transforming Software Architecture Design With Intelligent Assistants-A Comparative Analysis
