https://virgool.io/feed/@m_40397635 fa 2026-04-15 06:09:02 https://static.virgool.io/images/default-avatar.jpg https://virgool.io/@m_40397635 https://virgool.io/@m_40397635/%D8%AA%D8%AD%D9%82%DB%8C%D9%82-%D9%88-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D8%A2%D8%B1%D8%AA%DB%8C%D9%81%DA%A9%D8%AA-%D9%87%D8%A7%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%AA%D9%88%D8%AC%D9%87-%D8%A8%D9%87-%D8%B4%D9%86%D8%A7%D8%B3%D8%A7%DB%8C%DB%8C-%D8%B1%DB%8C%D8%B3%DA%A9-%D9%88-%D8%A8%D8%AF%D9%87%DB%8C-%D9%81%D9%86%DB%8C-pzdlshg6vjde گزارش پایانی درس معماری نرم‌افزاراین مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی استمقدمهمعماری نرم‌افزار، به عنوان ریشه اصلی توسعه سیستم‌های نرم‌افزاری پیچیده، نقشی حیاتی در تضمین کیفیت، مقیاس‌پذیری، نگهداری، امنیت و کارایی ایفا می‌کند. این حوزه، مسئول تعیین ساختار کلی یک سیستم، انتخاب فناوری‌ها، تعریف ارتباط بین مؤلفه‌ها و تصمیم‌گیری در مورد ویژگی‌های غیرکاربردی (non-functional requirements) است. آرتیفکت‌های معماری، که شامل انواع مدل‌های ساختاری، مستندات تصمیم‌گیری، دیاگرام‌ها، کد مستند شده، الگوها و مستندات طراحی می‌شوند، نمود عینی این تصمیمات معماری هستند. این آرتیفکت‌ها نه تنها پل ارتباطی بین نیازمندی‌ها و پیاده‌سازی محسوب می‌شوند، بلکه ابزارهایی قدرتمند برای مدیریت پیچیدگی، کنترل تغییرات، ارزیابی کیفیت و بهبود مستمر نرم‌افزار را فراهم می‌آورند.در پروژه‌های نرم‌افزاری مدرن، به ویژه آن‌هایی که در مقیاس بزرگ و با تیم‌های توسعه توزیع‌شده اجرا می‌شوند، قابلیت اطمینان به این آرتیفکت‌ها و به‌روز بودن آن‌ها از اهمیت ویژه‌ای برخوردار است. تولید و نگهداری صحیح و به‌موقع این آرتیفکت‌ها، نه تنها به عنوان یک گام ضروری در چرخه عمر توسعه نرم‌افزار (SDLC) تلقی می‌شود، بلکه به طور مستقیم بر موفقیت یا شکست پروژه تأثیر می‌گذارد. آرتیفکت‌های معماری با کیفیت، می‌توانند به کاهش سوءتفاهم‌ها، افزایش کارایی تیم، کاهش هزینه‌های نگهداری و تسریع فرآیند توسعه کمک کنند. در مقابل، آرتیفکت‌های ناقص، منسوخ یا نامفهوم، می‌توانند منجر به بروز مشکلات جدی از قبیل اشکالات طراحی، عدم همگام‌سازی بین بخش‌های مختلف سیستم و در نهایت، شکست پروژه شوند.اهمیت و چالش‌های بهبود و تولید آرتیفکت‌های معماریدر این بخش، به تفصیل به اهمیت حیاتی آرتیفکت‌های معماری در چرخه عمر توسعه نرم‌افزار، چالش‌های پیچیده مرتبط با تولید و نگهداری آن‌ها، و ضرورت بهبود مستمر این آرتیفکت‌ها برای اطمینان از موفقیت پروژه‌های نرم‌افزاری پرداخته می‌شود.اهمیت آرتیفکت‌های معماریآرتیفکت‌های معماری، بیش از صرف مستندات، ابزارهایی استراتژیک برای مدیریت پیچیدگی و اطمینان از کیفیت در پروژه‌های نرم‌افزاری هستند. اهمیت آن‌ها را می‌توان در چهار بعد کلیدی خلاصه کرد:مستندسازی تصمیمات کلیدی: معماری نرم‌افزار، نتیجه تصمیمات متعددی است که در طول فاز طراحی و توسعه گرفته می‌شوند. این تصمیمات شامل انتخاب الگوهای طراحی، فناوری‌ها، چارچوب‌ها و ساختار کلی سیستم است. آرتیفکت‌ها به عنوان سوابق دقیق این تصمیمات عمل می‌کنند و دلایل پشت انتخاب‌ها را ثبت می‌کنند. این امر نه تنها برای توسعه‌دهندگان فعلی مفید است، بلکه برای تیم‌های آینده که مسئول نگهداری یا توسعه سیستم هستند، مرجعی ارزشمند فراهم می‌کند. مستندسازی تصمیمات (Architecture Decision Records - ADRs) به ویژه در این زمینه حیاتی است و به جلوگیری از تکرار اشتباهات و حفظ یکپارچگی معماری کمک می‌کند.تسهیل ارتباط بین ذی‌نفعان فنی و غیرفنی: پروژه‌های نرم‌افزاری شامل ذی‌نفعان متعددی با پیش‌زمینه‌ها و سطوح دانش فنی متفاوت هستند. آرتیفکت‌های معماری، مانند دیاگرام‌های UML یا SysML، یک زبان بصری مشترک فراهم می‌کنند که به ذی‌نفعان مختلف، از جمله مدیران پروژه، تحلیل‌گران کسب‌وکار، توسعه‌دهندگان، آزمایش‌کنندگان و حتی کاربران نهایی، امکان درک ساختار و رفتار سیستم را می‌دهند. این ارتباط مؤثر، سوءتفاهم‌ها را کاهش داده و همسویی را در اهداف پروژه افزایش می‌دهد.پایه‌گذاری برای تحلیل و ارزیابی کیفیت نرم‌افزار: آرتیفکت‌های معماری، به خصوص مدل‌های ساختاری و رفتاری، بستری محکم برای تحلیل و ارزیابی ویژگی‌های کیفی سیستم (Quality Attributes) مانند کارایی، مقیاس‌پذیری، امنیت، قابلیت نگهداری و قابلیت اطمینان فراهم می‌کنند. تحلیل‌های مبتنی بر مدل (Model-Based Analysis) می‌توانند قبل از پیاده‌سازی، نقاط ضعف احتمالی معماری (ریسک ها، بدهی های فنی و ...) را شناسایی کرده و به تیم‌ها امکان می‌دهند تا قبل از صرف زمان و هزینه زیاد برای کدنویسی، تغییرات لازم را اعمال کنند. این رویکرد به ویژه در مدیریت ریسک و بهینه‌سازی منابع مؤثر است.کاهش پیچیدگی و مدیریت تغییر: با افزایش اندازه و پیچیدگی سیستم‌های نرم‌افزاری، مدیریت تغییرات به یک چالش بزرگ تبدیل می‌شود. آرتیفکت‌های معماری به تیم‌ها کمک می‌کنند تا تأثیر تغییرات را پیش‌بینی کنند، وابستگی‌ها را شناسایی کنند و تغییرات را به صورت کنترل‌شده و با حداقل اختلال پیاده‌سازی کنند. یک معماری خوب مستند شده، به عنوان نقشه‌ای عمل می‌کند که در صورت نیاز به اعمال تغییرات، راهنمایی‌های لازم را ارائه می‌دهد.چالش‌های اصلیبا وجود اهمیت فراوان، تولید و نگهداری آرتیفکت‌های معماری با چالش‌های متعددی روبرو است که در ادامه به برخی از مهم‌ترین آن‌ها اشاره می‌شود:همگام‌سازی میان مستندات و کد منبع: یکی از بزرگترین چالش‌ها، حفظ همگام‌سازی بین مستندات معماری و کد منبع واقعی سیستم است. با گذشت زمان و با اعمال تغییرات در کد، معمولاً مستندات به‌روز نمی‌شوند و این امر منجر به انحراف معماری (Architectural Drift) می‌شود. این انحراف می‌تواند باعث سردرگمی، تصمیم‌گیری‌های نادرست و افزایش هزینه‌های نگهداری شود. این مشکل اغلب به دلیل فشار زمانی، نبود ابزارهای مناسب برای به‌روزرسانی خودکار و عدم توجه کافی به مستندسازی در طول چرخه توسعه ایجاد می‌شود. از منظر ریسک، این وضعیت به‌طور مستقیم منجر به ریسک انحراف معماری و شکل‌گیری بدهی فنی همگام‌سازی می‌گردد که بازپرداخت آن در آینده بسیار پرهزینه است.هزینه بالا و نیاز به تخصص برای تولید و نگهداری مستندات: تولید آرتیفکت‌های معماری با کیفیت، به زمان، تلاش و تخصص قابل توجهی نیاز دارد. معماران نرم‌افزار باید دانش عمیقی از الگوهای طراحی، فناوری‌ها و استانداردهای مستندسازی داشته باشند. علاوه بر این، نگهداری مستمر این آرتیفکت‌ها نیز خود مستلزم هزینه است. کوتاهی در این بخش، سبب افزایش بدهی فنی ناشی از مستندسازی ناقص و ایجاد ریسک کاهش کیفیت تصمیم‌گیری معماری می‌شود.تفاوت سطوح انتزاعی و نیاز به مدل‌سازی چندلایه: معماری نرم‌افزار در سطوح مختلفی از انتزاع قابل بیان است، از سطح کلی سیستم گرفته تا جزئیات مربوط به مؤلفه‌ها و کلاس‌ها. ایجاد و حفظ مدل‌ها در این سطوح مختلف و اطمینان از سازگاری آن‌ها، نیازمند رویکردهای مدل‌سازی چندلایه و ابزارهایی است که بتوانند از این پیچیدگی پشتیبانی کنند. مدیریت این سطوح انتزاعی و ارتباط بین آن‌ها می‌تواند بسیار دشوار باشد .عدم مدیریت درست این سطوح منجر به ریسک ناسازگاری مدل‌ها و انباشته شدن بدهی فنی معماری (ATD) می‌شود که در آینده روند توسعه را کند و پرهزینه می‌کند.فقدان استانداردها و الگوهای ثابت در مستندسازی: با وجود استانداردهایی مانند UML، هنوز هم تنوع زیادی در نحوه مستندسازی معماری وجود دارد. فقدان یک استاندارد جهانی یکپارچه باعث ایجاد ریسک فهم‌پذیری پایین و سوءتفاهم تیمی شده و زمینه را برای بروز بدهی فنی در هماهنگی و مدیریت تغییرات فراهم می‌کند.اهمیت بهبود و بهینه‌سازیبا توجه به چالش‌های مطرح شده، بهبود و بهینه‌سازی فرآیندهای تولید و نگهداری آرتیفکت‌های معماری از اهمیت حیاتی برخوردار است. این بهبودها می‌توانند به نتایج زیر منجر شوند:دستیابی به معماری Agile و قابل توسعه: بهبود فرآیندهای تولید آرتیفکت، به ویژه با تمرکز بر اتوماسیون و ابزارهای پشتیبانی، می‌تواند به ایجاد معماری‌هایی کمک کند که نه تنها پایدار هستند، بلکه به سرعت و با انعطاف‌پذیری بالا می‌توانند با تغییرات سازگار شوند. این امر برای پیاده‌سازی رویکردهای چابک و DevOps بسیار مهم است. این رویکرد، ریسک انباشته شدن بدهی فنی ناشی از تغییرات سریع را کاهش می‌دهد و از شکل‌گیری بدهی‌های ناشی از نیاز به بازطراحی‌های گسترده در آینده جلوگیری می‌کند.کاهش خطاهای طراحی و افزایش قابلیت نگهداری: با داشتن آرتیفکت‌های دقیق و به‌روز، تیم‌ها می‌توانند خطاهای طراحی را در مراحل اولیه شناسایی و رفع کنند. این امر هزینه رفع اشکالات را کاهش داده و ریسک بروز بدهی فنی را به حداقل می‌رساند. ضمن آن‌که، با کاهش ابهام و ناسازگاری‌ها، بدهی فنی مستندات نیز کنترل شده و کیفیت نگهداری افزایش می‌یابد.کاهش هزینه تغییرات در طول چرخه عمر نرم‌افزار: تقویت کیفیت آرتیفکت‌های معماری کمک می‌کند تصمیمات کلیدی در مراحل ابتدایی اتخاذ شوند، جایی که اعمال تغییرات کم‌هزینه‌تر است. این اقدام، ریسک پیدایش بدهی فنی ناشی از تغییرات دیرهنگام را پایین آورده و همچنین مانع از رشد بدهی‌های پنهان می‌شود که ممکن است در فازهای عملیاتی آشکار شوند.افزایش درک مشترک و هم‌افزایی تیم: آرتیفکت‌های معماری که به خوبی نگهداری می‌شوند و به‌روز هستند، ابزاری قدرتمند برای افزایش درک مشترک بین اعضای تیم و ذی‌نفعان هستند. این درک مشترک، به هم‌افزایی بیشتر در تیم منجر شده و کارایی کلی توسعه را بهبود می‌بخشد. این موضوع احتمال سوءتفاهم‌های فنی را کاهش داده و بدهی فنی ناشی از ارتباطات ناقص و تصمیم‌گیری ناهماهنگ را محدود می‌کند. به همین ترتیب، ریسک بروز خطاهای تکرار شونده در طراحی نیز کاهش می‌یابد.به طور خلاصه، بهبود و بهینه‌سازی آرتیفکت‌های معماری نه تنها یک فعالیت مستندسازی، بلکه یک راهبرد مدیریتی برای کنترل و کاهش ریسک‌ها و بدهی‌های فنی است. اجرای این فرآیندها، نیازمند رویکردهای نوین، ابزارهای پیشرفته و تمرکز بر اتوماسیون برای مواجهه با پیچیدگی‌های روزافزون معماری نرم‌افزار است.رویکردهای نوین بهبود آرتیفکت‌های معماری نرم‌افزاربا پیشرفت فناوری و افزایش نیاز به سرعت و اتوماسیون در توسعه نرم‌افزار، رویکردهای نوین برای تولید و بهبود آرتیفکت‌ها ظهور کرده‌اند:تولید خودکار آرتیفکت‌ها با بهره‌گیری از مدل‌های زبانی (Language Models): با ظهور مدل‌های زبانی بزرگ (LLMs) و قابلیت‌های آن‌ها در تولید متن، کد و حتی دیاگرام‌ها، امکان تولید خودکار توضیحات معماری، ADRها، و حتی دیاگرام‌های ساده از ورودی‌های متنی یا کدهای موجود فراهم شده است. این رویکرد می‌تواند به کاهش بار مستندسازی دستی کمک کند.استخراج از کد منبع و DevOps pipelines: ابزارهای مهندسی معکوس (Reverse Engineering) می‌توانند از کد منبع سیستم، مدل‌های ساختاری مانند دیاگرام‌های کلاس یا کامپوننت را استخراج کنند. ادغام این فرآیندها در خطوط DevOps (CI/CD) می‌تواند به حفظ همگام‌سازی بین کد و مستندات کمک کند و آرتیفکت‌ها را به صورت خودکار به‌روز نگه دارد.استفاده از چارچوب‌های ارزیابی کیفیت (Quality Attribute Scenarios): این چارچوب‌ها (مانند ATAM - Architecture Tradeoff Analysis Method) به ارزیابی سیستم در برابر ویژگی‌های کیفی خاص کمک می‌کنند. با تعریف سناریوهای مشخص برای ویژگی‌هایی مانند کارایی یا امنیت، می‌توان معماری را در مقابل این سناریوها ارزیابی و نقاط ضعف احتمالی را شناسایی کرد.مدل‌سازی مبتنی بر کد (Code-Centric Modeling): به جای ایجاد مدل‌های جداگانه، این رویکرد بر استفاده از کد به عنوان منبع اصلی حقیقت تأکید دارد و ابزارهایی برای استخراج یا تولید آرتیفکت‌ها به صورت خودکار از کد ارائه می‌دهد. این رویکرد به خصوص در محیط‌های چابک محبوب است.شناسایی ریسک و بدهی‌های فنی (Risk & Technical Debt Identification): این رویکرد نوین، از ترکیب تحلیل داده‌محور (Data-Driven Analysis)، داده‌های Issue Trackerها (مانند GitHub Issues)، و روش‌های یادگیری ماشین برای شناسایی انواع بدهی‌های فنی، به‌ویژه بدهی فنی معماری (ATD)، استفاده می‌کند. با تحلیل الگوهای زبانی و ساختاری موجود در گزارش‌های مشکل، کامیت‌ها و ADRها، می‌توان ریسک‌های معماری را زودتر شناسایی و مدیریت کرد. مزیت اصلی این رویکرد شناسایی پیش‌دستانه نقاط ضعف و ریسک‌های معماری قبل از تبدیل‌شدن به بحران، کاهش هزینه رفع اشکال، و جلوگیری از انباشت بدهی فنی می‌باشد.این تنوع در انواع آرتیفکت‌ها و رویکردهای مرتبط، نشان‌دهنده پیچیدگی و پویایی حوزه معماری نرم‌افزار است. انتخاب آرتیفکت‌های مناسب و به کارگیری ابزارهای صحیح، نقش کلیدی در موفقیت پروژه‌های نرم‌افزاری ایفا می‌کند.در ادامه با تمرکز بر آخرین رویکرد گفته شده پیش می‌رویم و جزییات بیشتری را بیان می‌کنیم.شناسایی بدهی فنی معماری از آرتیفکت‌هابررسی‌ها نشان می‌دهد که بخشی از بدهی‌ها، به‌ویژه بدهی‌های مرتبط با معماری، نه‌تنها در کد منبع بلکه در سیستم‌های ردیابی خطا و وظایف مانند GitHub Issues نیز قابل شناسایی هستند.مطالعات متعددی این موضوع را تأیید کرده‌اند (مشاهده بیشتر در قسمت مراجع). این مطالعات نشان دادند که بسیاری از بدهی‌های فنی ثبت‌شده در Issue Trackerها ریشه در تغییرات یا تصمیمات معماری دارد و چرخه عمر آن‌ها معمولاً طولانی‌تر از سایر بدهی‌هاست. Zhang و همکاران (2023) با آموزش مدل BERT-base بر روی Issue حاوی Self-Admitted Technical Debt (SATD)، به دقت بالایی در طبقه‌بندی نوع بدهی فنی دست یافتند. در مقاله‌ای برای 2025 با ارائه دیتاست BEACon‑TD شامل ۱۳ نوع بدهی فنی استخراج‌شده از ۳۵ پروژه GitHub، نشان دادند که ترکیب داده‌های Issue با متادیتاهای ADR می‌تواند شناسایی بدهی معماری را بهبود دهد.معماری نرم‌افزار چارچوب بنیادینی است که ساختار، رفتار و تعاملات اجزا را در یک سامانه نرم‌افزاری تعیین می‌کند. کیفیت تصمیمات معماری به‌طور مستقیم بر کارایی، توسعه‌پذیری، قابلیت نگهداشت و مقیاس‌پذیری سیستم اثرگذار است. هرچند این تصمیمات بر اساس بهترین دانش و منابع موجود در زمان اخذ اتخاذ می‌شوند، اما محدودیت‌های زمانی، فشار بازار، کمبود منابع و تغییر نیازمندی‌ها سبب می‌شود برخی تصمیمات منجر به ایجاد بدهی فنی (Technical Debt – TD) شوند.بر اساس پژوهش‌های انجام شده بیش از نیمی از بدهی‌های فنی شناسایی‌شده در مخازن نرم‌افزاری ریشه در تصمیمات معماری دارد. این بدهی‌ها نه‌تنها در کد منبع بلکه در بایگانی Issue Tracker ها نیز مستند می‌شوند. داده‌های Issue Tracker (نظیر GitHub Issues) به دلیل انعکاس مستقیم تجربه توسعه‌دهندگان، یک منبع واقع‌گرایانه و کم‌هزینه برای شناسایی بدهی فنی محسوب می‌شود.به‌طور سنتی، شناسایی TD عمدتاً بر تحلیل کد و متریک‌های استاتیک متمرکز بوده است. رویکردهای جدیدتر – به ویژه بعد از سال ۲۰۱۸ – نشان داده‌اند که تحلیل متون موجود در Issues و Pull Requests می‌تواند موارد Self-Admitted Technical Debt (SATD) را آشکار کند؛ مواردی که خود توسعه‌دهندگان به‌صراحت به وجودشان اعتراف کرده‌اند.اهمیت موضوع شناسایی ریسک و بدهی فنیمدیریت بدهی فنی نه‌تنها در پروژه‌های متن‌باز که غالباً مشارکت‌کنندگان متعدد و توزیع شده دارند، بلکه در سامانه‌های صنعتی نیز اهمیت مضاعف دارد. وجود بدهی‌های معماری می‌تواند چرخه توسعه را کند، زمان رفع باگ را طولانی و خطر بروز اشکالات امنیتی یا افت کارایی را افزایش دهد. در مقابل، تصمیمات معماری مستندشده (Architectural Decision Records – ADRs) امکان رهگیری ریشه‌های بدهی و بررسی پیامدهای انتخاب‌ها را فراهم می‌کند.استفاده از اطلاعات ADR و داده‌های Issues برای:- شناسایی بدهی‌های معماری زودهنگام- پیش‌بینی نقاط بحرانی در توسعه آینده- مدیریت ریسکامکان ایجاد رویکردی داده‌محور در مدیریت معماری را فراهم می‌آورد. در دیتاست BEACon‑TD نشان دادند که تلفیق متادیتاهای معماری و توصیف Issues می‌تواند در شناسایی ۱۳ نوع مختلف TD کارایی بالایی داشته باشد.پیشینه پژوهش و کارهای مرتبطبدهی فنی نخستین بار به‌عنوان یک استعاره در مهندسی نرم‌افزار، مطرح شد، اما بعدتر رویکردهای سیستماتیک برای شناسایی و مدیریت آن مورد توجه جامعه علمی قرار گرفت. با گسترش پروژه‌های متن‌باز و استفاده وسیع از Issue Trackerها مانند GitHub Issues، محققان دریافتند که اطلاعات ارزشمندی درباره بدهی فنی در این داده‌ها نهفته است.پژوهش‌های اولیهFontana و همکاران (2015) نخستین مطالعات صنعتی را در شناسایی «ریشه‌های معماری» بدهی فنی ارائه کردند. آن‌ها در یک پروژه طول‌عمر بالا نشان دادند که عمده ATD ناشی از تصمیماتی است که بدون تحلیل اثرات بلندمدت اتخاذ شده‌اند و هیچ بازبینی‌ای روی پروژه‌ها صورت نگرفته است . نتیجه کلیدی این مطالعه: کد اسمل‌ها (Code Smells) می‌توانند نشانه‌هایی از فرسودگی کد و مشکلات بالقوه نگهداری باشند که با به‌کارگیری بازآرایی (Refactoring) مناسب قابل پیشگیری‌اند.در همین بازه، Maldonado و Shihab مفهوم Self-Admitted Technical Debt (SATD) را به Issue Trackerها تعمیم دادند. آن‌ها با تحلیل تعداد زیادی Issue در پروژه‌های متعدد، نشان دادند که توسعه‌دهندگان اغلب خود به وجود بدهی اذعان می‌کنند و این اطلاعات می‌تواند مبنای برچسب‌گذاری داده برای یادگیری ماشین باشد.گسترش رویکردهای NLP و یادگیری ماشین (۲۰۱۹–۲۰۲۲)با پیشرفت پردازش زبان طبیعی و مدل‌های یادگیری عمیق، پژوهشگران شروع به استفاده از مدل‌های word embedding و Transformer برای شناسایی TD در متون Issues کردند.در مطالعات اخیر رویکردی نوین برای شناسایی بدهی فنی اظهارشده که تلفیقی از مدل‌سازی برداری واژگان با Word2Vec و طبقه‌بندی با استفاده از ماشین بردار پشتیبان (SVM) بوده است. این روش با بهره‌گیری از نمایش‌های معنایی متراکم، توانست محدودیت رویکردهای سنتی مبتنی بر کلیدواژه را پشت سر بگذارد و در شاخص‌های دقت و recall عملکرد بالاتری ارائه کند. مزیت کلیدی این رویکرد در آن بود که مدل قادر شد حتی مواردی را که دارای اصطلاحات مستقیم بدهی فنی نبودند، ولی از نظر معنایی مشابه بودند، شناسایی کند.در ادامه محققان متعددی با روش‌های مختلف با ایجاد یک مجموعه‌ داده‌ی عمومی و بزرگ شامل ‌Issueهای برچسب‌گذاری‌شده از پروژه‌های متن‌باز، زیرساختی برای ارزیابی منسجم روش‌های شناسایی بدهی فنی فراهم کردند. آن‌ها با به‌کارگیری روش‌های نوین یادگیری ماشین از جمله شبکه‌های عصبی حافظه بلندمدت (LSTM) نشان دادند که مدل‌های توالی‌محور به‌واسطه‌ی توانایی در حفظ و تحلیل وابستگی‌های زمانی در متن، قادرند نشانه‌های پراکنده و غیرپیوسته بدهی فنی را که در طول چند جمله یا پاراگراف توزیع شده‌اند، به‌طور مؤثر شناسایی کنند.در یک مطالعه مهم دیگر، Parra و همکاران (2022) در مقاله «On the documentation of self‑admitted technical debt in issues» (Empirical Software Engineering) کارایی BERT-base را در طبقه‌بندی SATD با F1-score نزدیک به ۰.۸۵ گزارش کردند.از ۲۰۲۳ به بعد، مطالعات بیش‌ از پیش به ارتباط بین ADRs و TD توجه کرده‌اند.بررسی‌ها نشان داده‌اند که بخش قابل‌توجهی از بدهی‌های فنی ثبت‌شده در سامانه‌های ردیابی، ریشه در تصمیمات معماری دارد. به‌کارگیری روش‌های یادگیری عمیق توانسته عملکرد قابل قبولی در شناسایی این بدهی‌ها ارائه دهد، و ترکیب داده‌های مربوط به تصمیمات معماری با محتوای متنی Issues منجر به بهبود چشمگیر دقت شناسایی شده است.در یک جمع‌بندی کلی، روند پژوهش‌ها در حوزه بدهی فنی نشان می‌دهد که ابتدا تلاش‌ها بر تعریف مفاهیم و شناسایی پایه‌ای انواع بدهی، به‌ویژه بدهی‌های معماری و بدهی‌های فنی اظهارشده، متمرکز بوده است. به مرور زمان، استفاده از داده‌های سامانه‌های ردیابی مسئله‌ها به عنوان منبعی ارزشمند برای شناسایی و تحلیل این بدهی‌ها جایگاه ویژه‌ای پیدا کرده است. با ورود روش‌های پردازش زبان طبیعی و یادگیری ماشین، به‌ویژه مدل‌های مبتنی بر نمایش برداری اسناد و سپس معماری‌های پیشرفته‌تر مانند ترنسفورمرها، دقت و کارایی شناسایی به شکل قابل ملاحظه‌ای افزایش یافته و امکان تحلیل ابعاد مختلف از جمله ماهیت معماری بدهی‌ها فراهم شده است. این مطالعات همچنین به بررسی چرخه عمر بدهی‌ها، ارتباط تنگاتنگ آن‌ها با تصمیمات معماری، و کاربرد ابزارهای خودکار برای ردیابی و پیش‌بینی روندها پرداخته‌اند. در نهایت، ترکیب داده‌های معماری با اطلاعات متنی Issues به عنوان رویکردی نوین، نتایج بهتری در شناسایی و مدیریت بدهی فنی ارائه کرده است.جمع‌بندی شکاف‌ها و مسیر پژوهش حاضرطی یک دهه‌ی گذشته، مسیر پژوهش در حوزه شناسایی و تحلیل بدهی فنی اظهارشده (SATD) و بدهی فنی معماری (ATD) پیشرفت قابل‌توجهی داشته است. با این حال، مرور نظام‌مند مطالعات پیشین نشان می‌دهد که چند خلأ اصلی همچنان پابرجاست. نخست آن‌که، چارچوبی یکپارچه و عملیاتی که بتواند داده‌های حاصل از سامانه‌های ردیابی مسئله‌ها (Issue Trackers) و سوابق تصمیمات معماری (Architectural Decision Records – ADRs) را به صورت همزمان پردازش و تحلیل کند، هنوز شکل نگرفته است. دوم، بسیاری از پژوهش‌ها صرفاً بر یک نوع ویژگی( معمولاً ویژگی‌های متنی) تمرکز داشته‌اند و استفاده‌ی همزمان و هدفمند از ویژگی‌های متنی و ساختاری در مدل‌های یادگیری عمیق کمتر مورد توجه قرار گرفته است. سوم، نبود یک مجموعه داده‌ی عمومی و جامع که به طور خاص پیوند میان ATD و تصمیمات معماری را پوشش دهد و یا جامعیتی برای شناسایی، تحلیل و پیشنهاد برای حل ریسک‌ها و بدهی فنی را دارا باشد، باعث شده مطالعات مقایسه‌ای و بازتولید نتایج به سختی ممکن باشد؛ تنها در سال ۲۰۲۵ و با معرفی مجموعه داده و چارچوب BEACon‑TD بخشی از این نیاز پاسخ داده شد، ولی همچنان شکاف موجود به طور کامل پر نشده است.پیشنهادهای ادامه کاربرای توسعه این حوزه، چند مسیر کلیدی پیشنهاد می‌شود:گسترش دامنه داده به پروژه‌های صنعتی و تجاری برای بررسی الگوهای عملی ATD.پشتیبانی از چند زبان و ارزیابی عملکرد مدل در محیط‌های غیرانگلیسی.توسعه ماژول پیش‌بینی بدهی قبل از وقوع، بر پایه شاخص‌های فرآیندی (تعداد Pull Requestهای باز و بسته‌شده در ماه، مدت‌زمان بررسی کد (Code Review Time)، تعداد تغییرات در مستندات معماری در بازه‌های زمانی، میزان تأخیر در Merge یا پیاده‌سازی فیچرها، فاصله زمانی باز شدن یک issue تا بسته شدن آن و ...).تحلیل اثرات عوامل اجتماعی–فنی بر شکل‌گیری و رفع بدهی.ادغام چارچوب پیشنهادی با ابزارهای DevOps و ایجاد داشبورد نظارت بلادرنگ.گسترش دامنه داده به پروژه‌های صنعتی و تجاری برای بررسی بیشتر و بهتر Issue Tracker ها.با توجه به شکاف‌های شناسایی‌شده و نتایج به‌دست‌آمده، تحقیق حاضر بنیانی فراهم کرده که می‌تواند در مطالعات بعدی و بهبودهای عملی، گامی مهم در جهت مدیریت مؤثر بدهی‌های معماری و بهبود آرتیفکت های معماری نرم‌افزار باشد.سخن پایانیبا توجه به گسترش و پیچیدگی روزافزون سیستم‌های نرم‌افزاری، مدیریت فعالانه‌ی ATD نباید یک فعالیت جانبی باشد، بلکه باید بخشی بنیادین از چرخه توسعه تلقی شود. یافته‌های این پژوهش نشان می‌دهد که تحلیل متنی و ساختاری Issues و داده‌های ADR، می‌تواند حفره بسیاری از تلاش‌های مدیریت بدهی فنی را پر کند و در نتیجه موجب رشد بهتر و دقیق‌تر آرتیفکت‌های معماری نرم‌افزار شود. این مسیر، هم در حوزه‌ی پژوهشی و هم در کاربرد صنعتی، ظرفیتی برای بهبود کیفیت و پایداری محصولات نرم‌افزاری فراهم می‌آورد. مائده حشمتی مائده حشمتی Mon, 25 Aug 2025 21:10:59 +0330 https://virgool.io/@m_40397635/%D8%B9%D8%A8%D8%A7%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%DA%AF%D9%88%D9%87%D8%A7-%D9%88-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%87%D8%A7%DB%8C-%D9%85%D9%87%D9%85-%D8%AF%D8%B1-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1%D9%87%D8%A7-whjjnm5jhhtg Infrastructure as Code (IaC)زیرساخت به‌عنوان کد (IaC) یک روش خودکار برای مدیریت و تهیه زیرساخت‌ها با استفاده از فایل‌های متنی و به کمک ابزارهایی مانند Terraform یا Ansible یا فایل‌های JSON است. در این روش، به جای پیکربندی دستی سرورها، شبکه‌ها و سرویس‌ها، کد یا اسکریپت‌های مشخصی نوشته می‌شود که زیرساخت موردنیاز را ایجاد، تنظیم و مدیریت کند. این روش امکان استقرار سریع‌تر، سازگاری بیشتر، و قابلیت نسخه‌برداری از زیرساخت‌ها را فراهم می‌کند. همچنین می‌توان تغییرات زیرساخت را با استفاده از سیستم‌های مدیریت نسخه (Git) ردیابی کرد. در این روش می‌توان زیرساخت تعریف شده را بارها و بارها تکرار کرد و در محیط‌های مختلف (Development Testing، Production) بدون هیچ تفاوتی اجرا کرد. از جمله مزایای این روش می‌توان به موارد زیر اشاره کرد: کاهش خطای انسانی در پیکربندی دستی. امکان استقرار سریع‌تر و ساده‌تر. مدیریت نسخه زیرساخت و بازگشت به نسخه‌های قبلی در صورت لزوم و مقیاس‌پذیری بیشتر در مدیریت سیستم‌های بزرگ.API Gateway & Service Meshاین دو مفهوم ارتباط مستقیم با معماری‌های مدرن میکروسرویس دارند.API Gateway: در معماری‌های مدرن میکروسرویس، دروازه API یک نقطه کنترل مرکزی است که درخواست‌های کاربران را دریافت کرده و آن‌ها را به سرویس‌های مناسب هدایت می‌کند. این ابزار قابلیت‌های امنیتی، مدیریت نرخ درخواست (Rate Limiting)، ثبت خطا، احراز هویت و امکانات دیگری را نیز ارائه می‌دهد.Service Mesh: یک لایه ارتباطی مستقل است که مدیریت ارتباطات بین سرویس‌های مختلف را (معمولا در معماری میکروسرویس) انجام می‌دهد. ابزارهایی مانند Istio برای اضافه کردن قابلیت‌هایی مثل مانیتورینگ، امنیت، و مسیریابی به سرویس‌ها استفاده می‌شوند. Service Mesh اجازه می‌دهد تعاملات بین سرویس‌ها بدون تغییر در کد آن‌ها بهینه شود.CQRS (Command Query Responsibility Segregation)CQRS یک الگوی معماری است که در آن عملیات‌های مربوط به دستورات (نوشتن اطلاعات) و پرس‌وجوها (خواندن اطلاعات) از هم جدا می‌شوند. تفکیک مسئولیت دستورات و پرس‌وجوها (CQRS) یک الگوی طراحی است که در آن عملیات‌های نوشتن (Command: ثبت، حذف، به‌روزرسانی) از عملیات‌های خواندن (Query: دریافت اطلاعات) جدا می‌شوند. این معماری مقیاس‌پذیری دیتابیس را افزایش می‌دهد و همچنین امکان داشتن مدل‌های داده متفاوت برای خواندن و نوشتن را فراهم می‌کند. کاربرد اصلی CQRS در سیستم‌هایی است که بار زیادی از عملیات خواندن دارند و نیاز به عملکرد بالا در کنار مقیاس پذيری پیچیده دارند.Event-Driven Architecture (EDA)EDA یک معماری نرم‌افزار است که تعاملات بین اجزای سیستم را بر اساس رویدادها مدیریت می‌کند. درواقع معماری رویدادمحور به سیستمی اشاره دارد که تعامل‌ها و ارتباطات بین اجزایش بر اساس رویدادها صورت می‌گیرد. در این معماری، به‌جای درخواست مستقیم، اجزا رویدادهایی را تولید کرده و به یک Event Bus ارسال می‌کنند (انتشار) و در نهایت واکنش توسط مصرف کننده صورت می‌گیرد . این معماری برای سیستم‌هایی که نیاز به پاسخگویی سریع و پردازش غیرهم‌زمان دارند، بسیار مناسب است.از جمله مزایای این معماری:پردازش غیرهم‌زمان: بخش‌های مختلف سیستم می‌توانند مستقل از یکدیگر عمل کنند.مقیاس‌پذیری بالا: افزایش کاربران یا سرویس‌ها به‌راحتی قابل مدیریت است .انعطاف‌پذیری سیستم‌ها: سامانه‌ها بدون وابستگی مستقیم تعامل دارند.Serverless Architectureمعماری بدون سرور به ساختار نرم‌افزاری اشاره دارد که در آن توسعه‌دهنده نیازی به مدیریت مستقیم سرورها ندارد. طرز کار این مدل به اینصورت می‌باشد که، کد تنها زمانی اجرا می‌شود که درخواست برای اجرای آن داده شود. ارائه‌دهندگان خدمات (مانند AWS Lambda یا Google Cloud Functions) این فرآیندها را مدیریت می‌کنند. در این مدل از خدماتی مانند AWS Lambda، Azure Functions یا Google Cloud Functions استفاده می‌شود که کد تنها زمانی اجرا می‌شود که درخواست داده شود. این مدل باعث کاهش هزینه‌ها (از جمله تمرکز بیشتر تیم توسعه روی منطق کدنویسی به‌جای زیرساخت)، مقیاس‌پذیری بالا (مقیاس‌پذیری خودکار براساس تعداد درخواست‌ها) و مدیریت آسانتر (مسئولیت نظارت، نگهداری و مدیریت سرورها کاملاً بر عهده ارائه‌دهنده خدمات است) سیستم می‌شود.API-first Approachرویکرد API-اول به توسعه نرم‌افزاری اشاره دارد که در آن طراحی API به‌عنوان اولویت اصلی در نظر گرفته می‌شود و سایر قسمت‌های برنامه حول محور آن ساخته می‌شوند. تمرکز بر API به عنوان اولین مرحله توسعه:توسعه‌دهندگان و تیم طراحی ابتدا API را به عنوان قلب سیستم تعریف می‌کنند تا اجزای دیگر سیستم بتوانند به راحتی حول محور API ساخته شوند. استانداردهای جهانی در طراحی API: استفاده از استانداردهایی مثل Swagger و OpenAPI برای مستندسازی API و تعامل بهتر. این رویکرد تضمین می‌کند که API‌ ها از ابتدا قابل استفاده باشند و امکان ادغام آسان بین سیستم‌ها و پلتفرم‌های مختلف را فراهم می‌کنند.Domain Driven Design (DDD)طراحی دامنه محور یک رویکرد توسعه نرم‌افزاری است که تمرکز اصلی آن بر مدل کردن دقیق دامنه یا حوزه کسب‌وکار است. در این روش، همکاری نزدیک بین توسعه‌دهندگان و متخصصین دامنه کسب‌وکار برای ایجاد مدل‌هایی که مشکلات واقعی کسب‌وکار را حل کنند، انجام می‌شود. مفاهیم اصلی DDD شامل Entity، Value Object، Aggregate و Bounded Context می‌باشد. در ادامه توضیح مختصری از هرکدام داده می‌شود:Entity(موجودیت) :موجودیت‌ها اشیایی هستند که خصوصیات و رفتارهای مشخصی دارند و قادر به شناسایی مستقل هستند. مثلا: یک کاربر یا محصول.Aggregate: مجموعه‌ای از موجودیت‌ها و اشیاء ارزش که به عنوان یک واحد هماهنگ مدیریت می‌شوند.Value Object(اشیاء ارزش): اشیائی که تنها بر اساس مقدارشان شناخته می‌شوند و وابسته به هویت نیستند (مثلا یک آدرس).Bounded Context(محدوده‌های محدود): تقسیم دامنه به بخش‌های کوچکتر که هرکدام مستقل عمل می‌کنند و ارتباطات مشخصی با یکدیگر دارند.این روش مخصوص پروژه‌هایی با دامنه‌های پیچیده مثل سیستم‌های مالی، بیمه یا مدیریت زنجیره تامین استفاده می‌شود.Hexagonal Architectureمعماری شش‌ضلعی یک الگوی طراحی است که به نام پورت‌ها و آداپتورها نیز شناخته می‌شود. این معماری با هدف جدا کردن منطق کسب‌وکار از لایه‌های خارجی مانند پایگاه داده یا رابط کاربری ایجاد شده است.ایده اصلی معماری شش‌ضلعی:هسته مرکزی: لایه اصلی که شامل منطق کسب‌وکار و قوانین برنامه است.پورت‌ها: رابط‌هایی برای اتصال هسته اصلی به اجزای خارجی مانند پایگاه‌داده یا سایر سرویس‌ها.آداپتورها: اجزایی که رفتار موردنیاز را برای اتصال به اجزای خارجی فراهم می‌کنند.لایه مرکزی (یا هسته) حاوی منطق اصلی برنامه است و از طریق پورت‌ها و آداپتورها با سیستم‌های خارجی تعامل می‌کند. این مدل باعث انعطاف‌پذیری در توسعه و تست آسان‌تر می‌شود.Event Sourcingذخیره‌سازی رویداد (Event Sourcing) یک الگوی طراحی است که در آن تغییرات وضعیت سیستم به‌صورت توالی‌ای از رویدادها ذخیره می‌شود. به جای ذخیره وضعیت نهایی، تمام رویدادهایی که برای رسیدن به این وضعیت رخ داده‌اند، ثبت می‌شوند. این روش امکان بازسازی کامل وضعیت سیستم در هر لحظه را فراهم می‌آورد و برای سیستم‌هایی که نیاز به ثبت‌های دقیق و قابل ردیابی دارند مناسب است. طرز کار این معماری بدین صورت است که هر تغییر در سیستم (مانند ایجاد سفارش، پرداخت و …) به عنوان یک رویداد ذخیره می‌شود و بازسازی وضعیت فعلی سیستم از تجمیع رویدادهای گذشته به دست می‌آید.Low-code/No-code Platformsپلتفرم‌های کم‌کدنویسی/بدون‌کدنویسی ابزارهایی هستند که توسعه نرم‌افزار را با حداقل یا بدون نیاز به کدنویسی امکان‌پذیر می‌کنند. این پلتفرم‌ها با رابط‌های گرافیکی و قابلیت‌های کشیدن و رها کردن (Drag & Drop) توسعه‌دهندگان را قادر می‌سازند برنامه‌هایی با سرعت بالا بسازند. این مدل برای کسب‌وکارهایی که منابع و زمان محدود دارند مناسب است. از جمله میژکی های کلیدی این پلتفرم ها است که بعلت داشتن رابط کاربری ساده ، افراد غیره توسعه‌دهنده نیز میتوانند اپلیکیشن بسازند. دیگر ویژگی این پلتفرم ها امکان خودکارسازی برخی جنبه‌های توسعه مانند ساخت دیتابیس و مدیریت فرم‌ها می‌باشد. یکی از عیوب این پلتفرم ها عدم پشتیبانی مناسب از پروژه های بسیار پیچیده است.Business Process Management Systems (BPMS)سیستم‌های مدیریت فرآیند کسب‌وکار (BPMS) نرم‌افزارهایی هستند که طراحی، اجرا و بهینه‌سازی فرآیندهای کسب‌وکار را تسهیل می‌کنند و موجب افزایش چابکی سازمان ها می‌شوند. این ابزارها به سازمان‌ها کمک می‌کنند تا فرآیندهای کاری خود را خودکار کنند، کارایی را افزایش دهند و اهداف استراتژیک خود را بهتر محقق کنند. برخی از قابلیت‌ها و اجزای کلیدی شامل طراحی فرایند، اجزای فرایند، مدیریت قوانین کسب و کار و تحلیل و مانیتورینگ است.Message Queue (مثل Kafka و RabbitMQ)یک الگوی طراحی است که به منظور ارسال و دریافت پیام‌ها بین اجزای مختلف یک سیستم نرم‌افزاری استفاده می‌شود. این معماری برای سیستم‌های غیرهم‌زمان بسیار موثر است و به اجزای مختلف اجازه می‌دهد بدون نیاز به ارتباط مستقیم و زنده، با یکدیگر تعامل کنند. طرز کار این الگو به این صورت است: در این معماری، تولیدکننده پیام (Producer) پیامی را در صف قرار می‌دهد. مصرف‌کننده پیام (Consumer) این پیام را از صف خوانده و پردازش می‌کندو صف پیام، واسطی میان دو بخش از سیستم است که بر اساس اصل ارسال غیر هم‌زمان عمل می‌کند. یکی از مزایای اصلی این روش کاهش وابستگی‌های بین اجزا می‌باشد (decoupling).Container Orchestration (مثل Kubernetes)ارکستراسیون کانتینرهامجموعه‌ای از فرآیندها و ابزارهاست که به شما امکان مدیریت و هماهنگی کانتینرهای نرم‌افزاری در یک محیط توزیع‌شده را می‌دهد. کانتینرها واحد‌های مستقلی از نرم‌افزار هستند که همه اجزای مورد نیاز برای اجرا، مانند Dependency ها را در خود دارند. دلیل ضروری بودن به این علت است که در سیستم‌هایی با هزاران کانتینر که به صورت توزیع‌شده کار می‌کنند، هماهنگی و مدیریت آن‌ها بدون ابزارهای ارکستراسیون بسیار دشوار است. از جمله قابلیت‌های آن مقیاس پذیری، مانیتورینگ و خودکارسازی می‌باشد . از جمله ابزارهای پرکاربرد می‌توان به Kubernetes، Docker Swarm و OpenShift اشاره کرد.Multi-Tenancy Architectureدر معماری چندمستاجرهیک نرم‌افزار به گونه‌ای طراحی می‌شود که بتواند به چندین مشتری (Tenant) خدمات ارائه دهد، با این حال هر مشتری محیط اختصاصی خود را داشته باشد. این نوع معماری در سیستم‌های مبتنی بر SaaS(نرم‌افزار به‌عنوان سرویس) بسیار رایج است. به جای نصب نرم‌افزار جداگانه برای هر مشتری، یک نرم‌افزار به همه مشتریان خدمات مشترک ارائه می‌دهد، ولی داده‌ها و تنظیمات هر مشتری از دیگری جدا هستند. دو مدل دیتابیس جداگانه (هر مشتری دارای پایگاه‌داده مستقل است) و مشترک (مشتری‌ها داده‌های خود را در یک پایگاه داده مشترک ذخیره می‌کنند ولی دسترسی‌ها جداست) دارد. موجب کاهش هزینه‌های استقرار و ارائه سریع‌تر خدمات به مشتری‌ها می‌شود اما در عین حال وابستگی به زیرساخت های مشترک و پیچیدگی در مدیریت ایزوله سازی داده‌ها رادارد.Enterprise Integration Patternsالگوهای یکپارچه‌سازی سازمانیمجموعه‌ای از اصول و الگوهای طراحی هستند که به سازمان‌ها کمک می‌کنند سیستم‌های مختلف خود را به صورت هماهنگ و یکپارچه با یکدیگر متصل کنند. در نتیجه، داده‌ها و فرآیندها به روان‌ترین شکل ممکن بین سیستم‌ها جریان پیدا می‌کنند.مفاهیم کلیدی:Message Broker: استفاده از یک واسطه برای مدیریت انتقال پیام‌ها بین سرویس‌ها.Routing: هدایت پیام‌ها به مقصد مناسب.Transformation: تبدیل فرمت پیام‌ها برای سازگاری با سیستم‌های مختلف.از جمله مزایای این الگو همگام‌سازی سریع سیستم‌های قدیمی با فناوری‌های جدید، مدیریت جریان کاری بین سرویس‌ها و بهبود انعطاف‌پذیری سازمان در برابر تغییرات می‌باشد. یکی از ابزارهای پر کاربرد در این زمینه Camel(فریمورک تخصصی برای مدیریت الگوهای یکپارچه سازی) می‌باشد. مائده حشمتی مائده حشمتی Mon, 12 May 2025 21:56:26 +0330 https://virgool.io/@m_40397635/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D9%85%D8%AF%D9%84-%D9%87%D8%A7%DB%8C-%D8%AA%D9%88%D9%84%DB%8C%D8%AF-%D8%B4%D8%A8%DA%A9%D9%87-%D9%88-%D8%A8%D9%87%D8%A8%D9%88%D8%AF-%D8%B1%D9%88%D9%86%D8%AF-%D8%AA%D9%88%D9%84%DB%8C%D8%AF-%D8%A8%D8%A7-%DA%A9%D9%85%DA%A9-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D9%87%D9%88%D8%B4-%D9%85%D8%B5%D9%86%D9%88%D8%B9%DB%8C-%D9%88-%D8%B4%D8%A8%DA%A9%D9%87-%D9%87%D8%A7%DB%8C-%D8%B9%D8%B5%D8%A8%DB%8C-o64ouyvlxtl1 گرداورنده: مائده حشمتیچکیده:این مستند به بررسی تعدادی از مدل‌های تولید شبکه از ابتدا تا کنون و بهبود روند تولید با استفاده از ابزارهای هوش مصنوعی و شبکه‌های عصبی می‌پردازد. در این مطالعه، مدل‌های اولیه و پیشرفته‌تر شبکه‌ها مورد بررسی قرار گرفته‌اند تا شبکه‌هایی نزدیک به شبکه‌های دنیای واقعی تولید شوند. همچنین، مفاهیم کلیدی مورد استفاده در این مقاله و مراحل انجام مدل TagGen و Tigger به تفصیل شرح داده شده‌اند. در ادامه، با مطالعه منابع و جستجوی بیشتر، دیدگاه عمیق‌تری نسبت به موضوع ارائه شده است. درنهایت با معرفی مدل های زبانی بزرگ که یکی از پیشرفته‌ترین مدل های هوش مصنوعی می‌باشد به کاربردهای متنوع آن در تولید شبکه‌های پیچیده پرداخته می‌شود. مدل‌های زبانی بزرگ (LLMs) به عنوان یکی از پیشرفته‌ترین دستاوردهای هوش مصنوعی، توانایی‌های بی‌سابقه‌ای در پردازش زبان طبیعی و فراتر از آن از خود نشان داده‌اند. این مستند به بررسی جامع LLM ها، معماری آن‌ها، روش‌های آموزش، ویژگی‌های برجسته، محدودیت‌ها و کاربردهای آن‌ها در تولید و تحلیل شبکه‌های پیچیده می‌پردازد. همچنین، به یک مطالعه موردی در مورد کاربرد LLM ها در شبکه‌ها اشاره می‌شود. در نهایت، چالش‌های پیش رو و چشم‌انداز آینده این فناوری مورد بحث قرار می‌گیرد.مقدمه:شبکه‌های پیچیده (Complex Networks) شبکه‌هایی هستند که از مجموعه‌ای از نودها (گره‌ها) و یال‌ها (اتصالات بین گره‌ها) تشکیل شده‌اند و ساختار آن‌ها می‌تواند به صورت تصادفی یا با قواعد خاصی شکل بگیرد. این شبکه‌ها به دلیل ویژگی‌های خاص خود، کاربردهای فراوانی در علوم مختلف دارند.از جمله کاربردهای آن‌ها در تحلیل شبکه‌های اجتماعی٬ بیولوژیکی٬ حمل و نقل و شبکه‌های ارتباطی می‌باشد. تحلیل و تولید شبکه‌های پیچیده در زمینه‌های مختلفی مانند مدیریت و بهینه سازی منابع٬ شناسایی الگو و رفتارها٬ تشخیص ناهنجاری و پیشگیری از بحران ها و طراحی شبکه‌های پایدار مورد استفاده قرار می‌گیرند. تولید شبکه‌هایی که ویژگی‌های شبکه‌های دنیای واقعی را داشته باشند، یکی از چالش‌های اصلی در این حوزه است. در این مقاله، مدل‌های مختلف تولید شبکه از ساده‌ترین مدل‌ها تا مدل‌های پیشرفته‌تر مورد بررسی قرار گرفته‌اند. هدف اصلی این مطالعه، بهبود روند تولید شبکه‌ها با استفاده از ابزارهای هوش مصنوعی و شبکه‌های عصبی است.بررسی ادبیات و کارهای گذشته:در این بخش، مدل‌های مختلف تولید شبکه از جمله مدل‌های رندوم، مدل واتس اشترگاتز، مدل Configuration، شبکه‌های دوبخشی، مدل بلوک تصادفی و مدل‌های رشد ترجیحی مانند مدل پرایس و مدل باراباشی-آلبرت مورد بررسی قرار گرفته‌اند. هر یک از این مدل‌ها ویژگی‌های خاص خود را دارند و در زمینه‌های مختلفی کاربرد دارند.با شروع از ساده‌ترین مدل یعنی مدل های تولید شبکه رندوم که به نام های Erdos Renyi یا گراف تصادف پواسون است به سراغ دنیای مدل های شبکه می‌رویم. این مدل از ساده‌ترین مدل های شبکه است که در عمل به تنهایی کاربرد زیادی ندارد اما از خاصیت‌های آن در مدلهای دیگر استفاده می‌شود. این مدل ویژگی‌هایی همچون small world, Average Shortest Path و Small Compenents را داراست.با اقتباس از مدل اردوش رنی مدل واتس اشترگاتز ایجاد می‌شودکه در این مدل در کنارقطر کوچک (Small World)٬ شبکه ایجاد شده دارای Clustering بالایی می‌باشد. هدف تولید شبکه ای بود که از هردوی این ویژگی‌ها بهره مند باشد. با روش تغییر تصادفی یالها از گرافی که دارای clustering بالایی می‌باشد به گرافی خواهیم رسید که با حفظ تقریب خوبی از دسته بندی٬ به ویژگی small world نیز خواهد رسید.مدل بعدی مدل Configuration می‌باشد. در این مدل به جای توزیع درجه ها ما در ابتدا دنباله درجه ها را داریم. در این مدل با دانش درجه ها هر راس به صورت مجزا به درجه ی متناظر خود به یک نیم یال متصل میشود. سپس به صورت رندوم نیم یالها را به یکدیگر متصل می‌کنیم. در این مدل با رویکرد گفته شده هم توزیع درجه ی مورد نظرحفظ می‌شود و هم تمام ویژگی‌های تصادفی بودن را دارد. این مدل در مطالعات شبکه‌ها بسیار کارآمد و مفید است؛ همچنین برای شبیه سازی انواع شبکه‌های پیچیده نیز کاربرد دارد. این مدل در تعداد رئوس بالا ویژگی‌هایی همچون ٬ قطر کوچک شبکه و توزیع درجه Power Law داراست. این مدل به محققان این امکان را می‌دهد تا شبکه‌هایی با توزیع درجه خاصی تولید کرده و ویژگی‌های مطلوب خود را روی آن شبکه مورد بررسی قرار دهند.در ادامه به بررسی شبکه‌های دوبخشی پرداخته می شود. شبکه‌های دو بخشی نوع خاصی از شبکه‌ها هستند که در آنها گره‌ها به دو دسته متمایز تقسیم می‌شوند و یال ها تنها بین گره‌های این دو دسته ایجاد می‌شوند و نه درون آنها. می‌توان از شبکه‌های دو بخشی برای مدل‌سازی سیستم‌هایی مانند شبکه همکاری‌های علمی (دانشمندان و مقالات) بهره برد. در این مدل توزیع درجه برای هر بخش می‌تواند مستقل از یکدیگر باشد؛ بنابراین برای شبیه سازی مدلهایی که دو دسته مجزا از هم دارند بسیار مفید و کارآمد می‌باشد.در مدل های configuration ویژگی‌هایی همچون Assortativity به دلیل تصادفی بودن اتصالات زیاد مشاهده نمی شود. با وجود این راهکارهایی وجود دارد تا بتوان با حساب آوردن وابستگی‌های درجه‌ای٬ شبکه‌هایی با این خصوصیات ایجاد و تحلیل کرد. در مورد ویژگی‌های دیگر مانند transitivity و clustering نیز می‌توان با افزودن پارامترهای جدید به دنباله درجه ها و ساخت شبکه با در نظر گرفتن تمام پارامترهای جدید٬ به ساختارهای نزدیک تری نسبت به شبکه‌های دنیای واقعی از مدل پیکربندی برسیم.مدل بعدی به سراغ stochastic block model می‌رویم. این مدل آماری بیشتر به منظور مدل سازی ساختارهای اجتماعی (Community Structures) و مدل های لایه‌ای استفاده می‌شود. در مدل٬ما ماتریس احتمال اتصال بین درون بلوکی و برون بلوکی را داریم و دانستن تعداد بلوک ها به ساختن می پردازیم. حالت پویای این مدل برای شبکه‌هایی که در طول زمان تغییر می‌کنند نیز تعریف و بررسی شده است. مدل بلوک تصادفی به دلیل قابلیت زیاد در شناسایی و مدل‌سازی ساختارهای پیچیده شبکه، همچنان یکی از ابزارهای اصلی در تحلیل شبکه‌های پیچیده است.در بخشبعدی به سراغ تحلیل و بررسی دقیق‌تر ویژگی‌های شبکه‌های دنیای واقعی پرداخته می‌شود. در این بخش به مدل هایی پرداخته می‌شود که به ایجاد شبکه‌های واقعی می‌انجامد. بررسی دلیل وجود برخی ویژگی‌ها و سپس شبیه سازی مدل ها برای ویژگی‌های دیگر.در آغاز برای ایجاد و تکمیل شدن گراف با رویکرد preferential attachment یا cumulative advantage پیش می‌رویم. این رویکرد به این معنا می‌باشد که برای هر راس احتمالی در نظر گرفته می‌شود تا هر راس جدید متناسب با این احتمالات به رئوس موجود در گراف متصل شود. این احتمالات نیز بر اساس معیاری که در نظر می‌گیریم مانند درجه هر راس٬ محاسبه و نرمال می‌شود.اولین مدل: مدل price مدل پرایس یکی از مدل‌های اولیه برای توصیف رشد شبکه‌هایی است که با اضافه شدن گره‌ها و یال هابه مرور زمان توسعه می‌یابند. این مدل برای توضیح ساختار شبکه‌های استنادی (citationnetworks) علمی ارائه شد. در این مدل هر راس جدید تمایل به اتصال به گره‌های با درجه بالاتر دارد. همان مدلrich get richer. مدل پرایس پایه‌گذار بسیاری از تحقیقات مدرن در زمینه شبکه‌های پیچیده بوده و به توسعه مدل‌های دیگری مانند مدل باراباشی-آلبرت کمک کرده است٬ که پدیده رشد ترجیحی را به طور گسترده‌تری توضیح می‌دهند. ویژگی بارز و مورد توجه این مدل٬ توزیع درجه Power Law می‌باشد.دومین مدل: مدل باراباشی آلبرتروند تشکیل این مدل مانند مدل پاریس است با این تفاوت که فقط برای گراف های غیرجهت دار مناسب است و درجه راس جدید در مرحله ثابت است. یکی از ویژگی‌های جالب این مدل٬ Scale Free بودن آن می‌باشد. یعنی توزیع درجه ها از قانون توانی پیروی میکنند که موجب ایجاد نودهای هاب می‌شود.تفاوت این مدل با مدل پرایس٬ همانطور که پیش تر اشاره شد٬ در درجه راس ورودی می‌باشد. در‌واقع در مدل باراباشی مینیمم درجه هر راس بزرگ‌تر یا مساوی مقدار m است. هر دو مدل بر رشد ترجیحی تاکید دارند، اما با رویکردها و کاربردهای متفاوتی به مسئله شبکه‌های پیچیده می‌پردازند. مدل باراباشی-آلبرت به عنوان یک مدل پایه‌گذار و عمومی برای شبکه‌های پیچیده شناخته می‌شود، در حالی که مدل پرایس بیشتر به مباحث استنادی و اطلاعاتی پرداخته است.در بسیار موارد با اقتباس از مدل باراباشی آلبرت شروع به ایجاد مدل های دیگری با پارامترهای دیگری شده است. هدف این تغییرات نزدیک شدن بیشتر به ساختار شبکه‌های پیچیده ی دنیای واقعی بوده است.ازجمله مشکلاتی که مدل باراباشی آلبرت با آن‌ها مواجه بود می‌توان به نبودن clustering ٬ ثابت بودن مقدار توان در توزیع درجه و تکاملی نبودن ساخت گراف (فقط اضافه می شود) اشاره کرد. برای بهبود این مدل ها مدل های دیگری همچون Copying Model, Forest Fire, و گراف های Kronecker اشاره کرد که هرکدام سعی بر بهبود و افزودن ویژگی‌های ساختاری شبکه‌های واقعی بر مدل های مصنوعی مانند تکامل٬ قطر کوچک و چگالی بیشتر در طی زماندارند.در ادامه به تحلیل و بررسی ظهور هوش مصنوعی و یادگیری عمیق در تولید شبکه‌های پیچیده می‌پردازیم. در ابتدا اصطلاحاتی برای درک بهتر ادامه مطلب تشریح شده است.مفاهیم کلیدی:Graph generative modelمدل‌های تولیدی گراف روش‌هایی در یادگیری ماشین هستند که هدفشان تولید گراف‌های جدید است. این مدل‌ها تلاش می‌کنند ویژگی‌ها و ساختارهای آماری گراف‌های مشاهده شده را یاد بگیرند و از آن برای تولید گراف‌های جدید و مشابه استفاده کنند. از جمله‌ این مدل ها می‌توان به مدل های احتمالاتی مانند اردوش رنی٬ GANs , و شبکه‌های عصبی گراف ها اشاره کرد.Loss Functionتابع هزینه یا تابع زیان در علم آمار و بهینه‌سازی تابعی است که مقدار زیان را در یک رخداد نشان می‌دهد. تابع هزینه همچنین در علم اقتصاد، کنترل بهینه و مدیریت ریسک کاربرد دارد. درواقع این تابع برای هر داده بررسی میکند چه میزان هزینه ای لازم دارد. با توجه به مسأله ای که با آن رو به رو هستیم به دنبال مینمم کردن و بهینهکردن این تابع هستیم. تابع هزینه اندازه‌گیری می‌کند که مدل تا چه اندازه با داده‌های آموزشی موجود همخوانی دارد.stochastic gradient descentروش نزول گرادیان تصادفی (SGD) یک الگوریتم بهینه‌سازی است که به طور گسترده در زمینه یادگیری ماشین و به‌ویژه برای آموزش مدل‌های شبکه عصبی (Neural Networks) استفاده می‌شود. در یادگیری ماشین این روش به دنبال یافتن پارامترهای مسأله می‌باشد که تابع هزینه (Loss Function) را مینمم کند.تکنیک دیگری موجود است که یکی از پیشرفته‌ترین مکانیزم های پردازش اطلاعات است که به بهبود عملکرد مدل ها در فهم وابستگی‌های درونی و سلسه مراتبی در داده‌ها کمک می‌کند. در‌واقع این مکانیز دو سطح بررسی توجه درون گروهی و برون گروهی دارد. در درون گروهی توجه به داده‌های جزئی تر می‌باشد و هدف این نوع درک وابستگی‌های محلی و جزئی تر در بخش‌های کوچک‌تر می‌باشد. در سطح دوم توجه و تمرکز بر روی ارتباطات میان بخش‌های کوچک‌تری که در سطح اول بررسی شده٬ قرار دارد. در‌واقع این مکانیزم امکان درک وابستگی‌ها و تعاملات کلی‌تر و سطح بالاتر میان بخش‌های مختلف داده‌ها را فراهم می‌سازد.GANشبکه ­های مولد خصمانهبا استفاده از معماری شبکه های عصبی کانولوشنی قادرند تا از مجموعه ای از تصاویر ( دیتاست) یاد بگیرد و تصاویری مشابه تصاویر واقعی اما کاملاً جدیدی که در دیتاست موجود نیست را تولید کنند. این شبکه‌ها از موفق‌ترین و شناخته‌شده‌ترین معماری‌ها در یادگیری عمیق هستند که برای تولید داده‌های جدید از روی داده‌های موجود استفاده می‌شوند و شامل دو بخش مجزا که هرکدام یک شبکه عصبی می‌باشند و به صورت خصمانه با یکدیگر رقابت میکنند٬ می‌باشد. بخش اول مولد یا همان Generator و بخش دوم متمایزگر یا همان Discriminator می‌باشد. هدف اصلی مدل مولد تولید عکس مشابه داده‌های واقعی که تشخیص غیرواقعی بودن آن به صفر نزدیک باشد و مدل متمایزگر با هدف تشخیص عکس واقعی از غیرواقعی که توسطمولد تولید شده است در کنار مدل دیگرارتقا پیدا میکند. با علم نظریه بازی‌ها خواهیم داشت: مولد و متمایزگر در یک بازی با جمع صفر شرکت می‌کنند: مولد می‌خواهد متمایزگر را فریب دهد و متمایزگر می‌خواهد داده‌های جعلی مولد را شناسایی کند.NetGANتولید گراف های واقعی که شبکه‌های دنیای واقعی را با یادگیری الگوها و ویژگی‌های توپولوژیزیرین یک گرافورودی تقلید کنند. NetGAN به‌گونه‌ای طراحی شده است که به جای حفظ نمودار ورودی، آن را تعمیم دهد. این تعمیم‌دهی برای ایجاد نمودارهایی که واقعی و متنوع هستند، به‌جای اینکه کپی دقیقی از نمودار ورودی باشند، حیاتی است. مدل تلاش می‌کند تا ویژگی‌های کلیدی توپولوژیشبکه‌های دنیای واقعی مانند توزیع درجه، همگرایی و ضریب خوشه بندی را بدون تعریف صریح این ویژگی‌ها در مدل، به خود بگیرد. NetGan از چارچوب Wasserstein GAN (WGAN) برای آموزش استفاده می‌کند. WGAN فاصله Wasserstein بین توزیع پیاده‌روی‌های تصادفی تولید شده و توزیع پیاده‌روی‌های تصادفی واقعی از نمودار ورودی را به حداقل می‌رساند. این رویکرد پویایی‌های آموزشیپایداری را ارائه می‌دهد و از مشکلات رایج GAN مانند mode collapse (تولید خروجی‌هایی با تنوع محدود توسط مولد) جلوگیری می‌کند. استفاده از جریمه گرادیان تضمین می‌کند که خروجی تفکیک‌کننده به‌طور یکنواختبا توجه به ورودی آن تغییر کند و پایداری آموزش را بهبود می‌بخشد. فرآیند آموزش با نمونه‌برداری از پیاده روی رندوم (گرفتن ساختارهای محلی و جهانی نمودار) شروع می‌شود، با آموزش متوالی مولد و تفکیک‌کننده ادامه می‌یابد و با آموزش سرتاسری همراه با پس‌انتشار گرادیان‌ها به پایان می‌رسد.GraphRNNیک مدل مولد دیگریبرای تولید گراف‌ها است که با استفاده از شبکه‌های عصبی بازگشتی (RNNs) طراحی شده است. این مدل می‌خواهد به‌طور مؤثری اطلاعات ساختاری گراف‌ها را یاد بگیرد و گراف‌هایی جدید با ویژگی‌های مشابه گراف‌های آموزشی تولید کند. این مدل از دو بخش Node Level RNN و Edge Level RNN ایجاد شده است که هردو در تلاشند ساختار دل خواه خود را حفظ و بهبود دهند. یعنی مدل سازی رئوس و یالها تقریباً به صورت مستقل از هم تکامل می یابند. ابتدا سطح گره آموزش داده می‌شود و سپس سطح یال ها با رئوس ایجاد شده آموزش داده می‌شوند. برخلاف روش‌های سنتی مبتنی بر ماتریس مجاورت گراف، در Graph RNNها تعداد پارامترها زیاد وابسته به اندازه گراف نیست. این مدل‌ها طراحی شده‌اند تا بتوانند ساختارهای پیچیده و غنی از اتصالات مانند گراف‌ها را مدل کنند که در بسیاری از مسائل واقعی از جمله شبکه‌های اجتماعی، شبکه‌های بیولوژیکی و شبکه‌های ارتباطی حضور دارند.TagGenاساس کار این مدل با لاگ های سیستمی می‌باشد که به صورت سری زمانی در اختیار ما قرار دارند. در‌واقع در هر زمان (Timestamps) اطلاعاتی از داده‌های موجود را با کمک لاگ سیستم در اخیار می‌گیریم و سعی بر یادگیری با دانش در اختیار داریم. شروع این مدل با رویکردی نوآورانه به تولید شبکه می‌پردازد و سعی بر آن دارد که به صورت پیوسته با حفظ ساختار و ویژگی‌های مدل اولیه به تکامل و پیش روی شبکه بپردازد. این مدل با پارامتر کردن یک مکانیزم bi-level self-attention با عملیات محلی دیگر(حذف یا افزودن)٬ پیاده روی تصادفی زمانی ای تولید می‌کند. سپس یک متمایز کننده هریک از این random walk ها را بررسی میکند و از میان آن‌ها تعیین می‌کند کدام دسته از آن‌ها ساختار اولیه دیتای آموزشی را دارد و از توزیع درجه یکسانی برخوردار استتا مورد استفاده قرار بگیرند. روند اجرای این الگوریتم به صورت زیر است:sampling: با کمک random walk و کاوش محلی به دنبال مجموعه‌ای از دنباله هایی هستیم که موجب تولید همسایگی برای راس مورد مطالعه شده است. برای نمونه‌برداری منصفانه و مؤثر از همسایگی، باید از بین کل داده‌ها، رخداد های زمانی نماینده‌تری را به عنوان گره‌های اولیه انتخاب کنیم.Generation: از میان نمونه‌های انتخاب شده در بخش قبلی٬ با استفاده از عملیات افزودن و حذف به صورت تصادفی سعی بر شبیه سازی تکامل شبکه بر اساس شبکه‌های واقعی داریم. در این مرحله می‌توان از تکنیک های دیگری نیز برای بهبود و تغییر temporal random walks استفاده کرد.Discriminator: با بررسی likelihood برای graph context تولید شده بر اساس داده آموزشی بر اساس قیاس توزیع درجه تعیین می‌کند چقد خوب است و مجدد این روند تکرار می‌شود تا با افزودن و حدف های متوالی و کم کم در نهایت به گراف زمینه‌ای مناسب برسیم.Assembling: مونتاژ گراف با کمک تمام داده‌های اولیه و تولید شده توسط مراحل قبلی و افزودن یال در زمان های مختلف تا رسیدن به چگالی داده‌های اصلی اولیه.در تولید گراف‌های زمانی که هم ویژگی‌های ساختاری و هم زمانی داده‌های اصلی را حفظ می‌کند، بسیار موفق است. این مدل به خصوص در سیستم‌های دینامیک که تغییرات زمانی در آن‌ها بحرانی است، مانند مجموعه داده BITCOIN، مؤثر است.Tiggerالگوریتم TIGGER برای حل مشکلات موجود در مدل‌های مولد گراف‌های زمانی طراحی شده است. چالش‌های اصلی که در مدل‌های قبلی وجود داشت شامل:عدم مقیاس‌پذیری: بسیاری از مدل‌های قبلی نمی‌توانند به‌خوبی با افزایش تعداد نودها یا زمان‌ها مقیاس‌پذیر باشند.ماهیت ترانسداکتیو: مدل‌های قبلی توانایی انتقال دانش به گراف‌های جدید را نداشتند.نشت اطلاعات هویت رئوس: اغلب مدل‌ها اطلاعات هویت نودها را از گراف اصلی به گراف تولید شده منتقل می‌کنند که باعث کاهش کیفیت گراف‌های تولیدی می‌شود.این مدل با کمک شبکه‌های عصبی بازگشتی٬ داده‌های آموزشی را استخراج می‌کند و به صورت پویا تعاملات گره ها و timestamps را پیش بینی می کند و توانایی مدل را برای ثبت پویایی های زمانی افزایش می دهد. تفاوت این مدل با مدل tagGen در افزایش کیفیت گراف های تولیدی و در عین حال کاهش تکرار الگوریتم می‌باشد. مقیاس پذیری بهتری دارد و در مقایسه با سایر الگوریتم ها از خطای کمتری در حفظ ساختار و ویژگی شبکه‌های بزرگ برخوردار است.تا کنون، مدل‌های مختلف تولید شبکه بررسی شده‌اند و تلاش شده است تا با استفاده از ابزارهای هوش مصنوعی و شبکه‌های عصبی، روند تولید شبکه‌ها بهبود یابد. مدل TagGen به عنوان یک مدل نوآورانه، توانسته است با استفاده از مکانیزم‌های پیشرفته‌ای مانند bi-level self-attention و random walk، شبکه‌هایی با ویژگی‌های نزدیک به شبکه‌های دنیای واقعی تولید کند.اما در ادامه به سراغ یکی از پیشرفته‌ترین مدل های هوش مصنوعی رفته و به تحلیل بیشتر در این حوزه می‌پردازیم.مدل های نو ظهور و در حال گسترش :ظهور مدل‌های زبانی بزرگ (LLMs) انقلابی در حوزه پردازش زبان طبیعی و فراتر از آن ایجاد کرده است. این مدل‌ها با بهره‌گیری از معماری‌های پیچیده شبکه‌های عصبی و آموزش بر روی حجم عظیمی از داده‌های متنی، قادر به انجام طیف گسترده‌ای از وظایف زبانی هستند که تا پیش از این تنها در انحصار انسان بود.پیش از ظهور LLM ها، مدل‌های زبانی مبتنی بر شبکه‌های عصبی بازگشتی (RNNs) و شبکه‌های عصبی کانولوشنی (CNNs) برای پردازش زبان طبیعی استفاده می‌شدند. با این حال، این مدل‌ها با محدودیت‌هایی مانند مقیاس‌پذیری ضعیف و ناتوانی در پردازش متن‌های طولانی مواجه بودند. معرفی معماری ترانسفورمر (Transformer) در سال 2017 توسط گوگل، انقلابی در این حوزه ایجاد کرد و پایه‌ای برای توسعه LLM ها شد.Transformerمقاله Attention Is All You Need با معرفی معماری ترنسفورمر، یک تحول بزرگ در حوزه پردازش زبان طبیعی ایجاد کرد. این مدل به‌ویژه در زمینه پردازش زبان طبیعی (NLP) و ترجمه ماشینی به کار می‌رود و هدف اصلی آن این است که یک مدل بدون استفاده از لایه‌های بازگشتی (RNN) یا کانولوشنی (CNN) معرفی کند که قادر باشد عملکرد بهتری در تبدیل دنباله‌ها، به‌ویژه در ترجمه ماشینی، داشته باشد. در این معماری، تأکید اصلی بر مکانیزم توجه (Attention) به‌عنوان یک ویژگی اصلی در این مدل است.مکانیزم توجه : در مدل‌های ترانسفورمر، مکانیزم توجه به‌طور خاص نقش کلیدی دارد. برخلاف مدل‌های قبلی که از شبکه‌های بازگشتی استفاده می‌کردند و می‌بایست ورودی‌ها را به‌طور تدریجی پردازش می‌کردند، مدل ترانسفورمر قادر است که به‌طور موازی تمام توکن‌ها را پردازش کند. این امر باعث می‌شود که سرعت آموزش افزایش یابد و از طرفی، مدل قادر باشد وابستگی‌های بلندمدت میان کلمات مختلف را به‌خوبی یاد بگیرد. عملکرد مکانیزم توجه به‌ویژه در شناسایی وابستگی‌های بلندمدت مورد استفادهقرار گرفته است.توجه چندسر (Multi-Head): یکی دیگر از ویژگی‌های برجسته مدل ترنسفورمر، مولتی هداست. این ویژگیبه مدل این امکان را می‌دهد که هم‌زمان بر روی چندین بخش مختلف از ورودی تمرکز کند. این ویژگی باعث می‌شود که مدل بتواند اطلاعات مختلف را از ابعاد مختلف ورودی استخراج کند و نتایج بهتری در پردازش داده‌ها بدست آورد. به عنوان مثال، در لایه‌های مختلف مدل، توجه مولتی هدمی‌تواند به‌طور هم‌زمان وابستگی‌ها و ارتباطات مختلف میان کلمات را در یک زمانشناسایی کند.کدگذاری موقعیتی (Positional Encoding): از آنجایی که مدل ترانسفورمر از هیچ نوع شبکه بازگشتی یا کانولوشنی استفاده نمی‌کند، برای حفظ اطلاعات موقعیتی و ترتیبی توکن‌ها در دنباله، از کدگذاری موقعیتی استفاده می‌شود. این کدگذاری به‌طور سینوسی و کسینوسی و با فرکانس‌های مختلف پیاده‌سازی می‌شود. این کدگذاری‌ها به ورودی‌های مدل افزوده می‌شوند و به مدل این امکان را می‌دهند که موقعیت هر توکن در دنباله را تشخیص دهد.در نتیجه، مدل‌های ترنسفورمر قادرند وابستگی‌های بلندمدت را در یک جمله یا پاراگراف شناسایی کنند. این قابلیت به‌ویژه در پردازش جملات پیچیده که دارای روابط معنایی عمیق هستند، بسیار مفید است. به‌عنوان مثال، مدل می‌تواند بفهمد که در یک جمله مانند او کتاب را روی میز گذاشت و سپس از خانه رفت، کلمه «او» به شخصی خاص ارجاع دارد که به‌طور دقیق‌تری در متن قبلی ذکر شده است.این مدل در مقایسه با مدل های قبلی سرعت آموزش بالاتر و کیفیت خروجی بهتری طبق نتایج روی دیتاست های مختلف داراست. از دیگر کاربردهای مهم مدل ترانسفورمر می‌توان به تجزیه ساختاری جملات اشاره کرد. این مدل نه تنها در ترجمه ماشینی بلکه در کارهای دیگر مانند تجزیه و تحلیل ساختار جملات نیز عملکرد خوبی از خود نشان داده است. این ویژگی باعث می‌شود که مدل به کارهای مختلف تعمیم یابد و در زمینه‌های مختلف پردازش زبان طبیعی به‌طور مؤثر عمل کند. این مدل با حذف شبکه‌های بازگشتی و استفاده از مکانیزم توجه، علاوه بر بهبود کیفیت مدل‌ها، زمان آموزش را نیز به‌طور قابل توجهی کاهش داد. این معماری به‌عنوان پایه برای مدل‌های پیشرفته‌تر مانند BERT و GPT عمل کرده است و تأثیر زیادی بر تحقیقات و کاربردهای عملی در زمینه هوش مصنوعی داشته است.مدل‌های زبانی بزرگ (LLMs) مانند GPT (Generative Pre-trained Transformer) و BERT (Bidirectional Encoder Representations from Transformers) از معماری ترنسفورمر برای پردازش و تولید زبان استفاده می‌کنند. مدل GPT به‌طور خودکار متنی را تولید می‌کند که به سوالات و درخواست‌های مختلف پاسخ دهد. این مدل به‌طور معمول از یک معماری مبتنی بر Transformer Decoder استفاده می‌کند که به آن این امکان را می‌دهد تا یک دنباله متنی را به‌صورت تکمیلی تولید کند. مدل BERT نیز برخلاف GPT، از معماری Transformer Encoder بهره می‌برد و به‌طور خاص برای درک و پردازش متن‌های ورودی به‌صورت دوطرفه طراحی شده است. این مدل بیشتر در کاربردهایی مانند پاسخ به سوالاتو دسته‌بندی متنموثر است.مدل GPT3هدف اصلی مقاله‌ی Language Models are Few-Shot Learners بررسی قابلیت‌های مدل GPT-3 در یادگیری با تعداد کم نمونه (Few-Shot Learning) و ارزیابی عملکرد آن در شرایط مختلف یادگیری است. این مقاله، که توسط OpenAI منتشر شده، به معرفی و تحلیل GPT-3 پرداخته و نشان می‌دهد که چگونه این مدل می‌تواند بدون نیاز به تنظیم دقیق (Fine-Tuning) در طیف گسترده‌ای از وظایف پردازش زبان طبیعی (NLP) عملکردی عالی از خود نشان دهد. در اینجا، به طور مفصل‌تر و دقیق‌تر به جزئیات این مقاله پرداخته می‌شود.مدل GPT-3 (Generative Pre-trained Transformer 3) ازبزرگ‌ترین و پیشرفته‌ترین مدلهایزبانی است که توسط OpenAI توسعه داده شده و شامل ۱۷۵ میلیارد پارامتر می‌باشد. این مدل بر اساس معماری ترنسفورمر خودرگرسیو ساخته شده که هدف آن تولید پیش‌بینی‌های متنی به ازای ورودی‌های متنی است. این مدل برای آموزش به مجموعه‌های داده‌ بسیار وسیعی از متون وب و دیگر منابع دسترسی پیدا کرده است. مدل‌های GPT، مانند GPT-3، برخلاف مدل‌های قدیمی‌تر که نیاز به تنظیم دقیق داشتند، قادرند وظایف مختلف را با استفاده از روش یادگیری درون‌متنی (In-Context Learning) انجام دهند. در این روش، مدل می‌تواند با مشاهده‌ی چند نمونه از یک وظیفه، به انجام آن وظیفه بدون نیاز به به‌روزرسانی پارامترها یا آموزش اضافی بپردازد.مدل‌های زبانی بزرگ (LLMs) به عنوان یکی از مهم‌ترین دستاوردهای هوش مصنوعی در سال‌های اخیر، توانایی‌های بی‌سابقه‌ای در پردازش زبان طبیعی و کاربردهای مرتبط با آن از خود نشان داده‌اند. با وجود پیشرفت‌های چشمگیر، LLM ها هنوز با چالش‌هایی روبرو هستند که باید بر آن‌ها غلبه کرد. با این حال، آینده LLM ها بسیار روشن به نظر می‌رسد و انتظار می‌رود که در سال‌های آینده، شاهد پیشرفت‌های بیشتری در این حوزه باشیم.کاربردهای LLM ها در تولید شبکه‌های پیچیده:LLM ها به عنوان ابزاری قدرتمند برای تولید، تحلیل و پیش‌بینی رفتار شبکه‌های پیچیده، کاربردهای گسترده‌ای پیدا کرده‌اند. برخی از این کاربردها عبارتند از:تحلیل و شبیه‌سازی شبکه‌های پیچیده با داده‌های متنی: مدل‌های LLM می‌توانند به تحلیل و استخراج ویژگی‌های شبکه‌های پیچیده از داده‌های متنی کمک کنند. به‌عنوان مثال، می‌توانند ارتباطات میان گره‌ها را از داده‌های متنی استخراج کرده و ساختار شبکه‌های پیچیده را شبیه‌سازی کنند.تولید شبکه‌های پیچیده مبتنی بر زبان: مدل‌های مولد زبان می‌توانند شبکه‌های پیچیده‌ای را که ویژگی‌های خاصی دارند (مانند شبکه‌های اجتماعی یا شبکه‌های علمی) تولید کنند. برای این کار، از داده‌های متنی (مثل مقالات علمی، پست‌های شبکه‌های اجتماعی یا گفتگوها) به‌عنوان ورودی استفاده می‌شود تا شبکه‌ای مبتنی بر این اطلاعات تولیدشود.به‌طور مثال، یک مدل LLM می‌تواند برای شبیه‌سازی شبکه‌های اجتماعی خاص، توضیحات متنی در مورد نوع ارتباطات یا تعاملات میان افراد ایجاد کند و سپس شبکه‌ای پیچیده تولید کند که شبیه به این نوع تعاملات باشد.مدیریت و تحلیل شبکه‌های اجتماعی: شبکه‌های اجتماعی و تحلیل رفتارهای کاربران در این شبکه‌ها نیازمند مدل‌هایی هستند که بتوانند همزمان با داده‌های متنی و ساختار شبکه‌ای کار کنند. مدل‌های LLM می‌توانند به تحلیل و استخراج اطلاعات از داده‌های متنی موجود در شبکه‌های اجتماعی بپردازند و مدل‌های مولد می‌توانند شبکه‌های جدیدی شبیه‌سازی کنند که ویژگی‌های مشابه شبکه‌های اجتماعی واقعی را دارند.شبیه‌سازی و مدل‌سازی رفتارهای پیچیده: در بسیاری از مواقع، شبکه‌های پیچیده به‌ویژه در سیستم‌های اقتصادی، زیستی، یا اجتماعی، ویژگی‌هایی دارند که از نظر گراف‌های کلاسیک قابل مدل‌سازی نیستند. ترکیب مدل‌های LLM و مولد شبکه‌های پیچیده می‌تواند به شبیه‌سازی رفتارهای پیچیده انسان‌ها یا تعاملات بین اجزای سیستم‌های بزرگ کمک کند.شبیه‌سازی شبکه‌های ارتباطی و محاسباتی: در علوم کامپیوتر و مخابرات، مدل‌های مولد می‌توانند برای شبیه‌سازی شبکه‌های پیچیده ارتباطی استفاده شوند. این شبکه‌ها ممکن است برای برنامه‌ریزی زیرساخت‌های اینترنت، پشتیبانی از شبکه‌های ارتباطی پیچیده یا حتی برای بهینه‌سازی کارکردهای شبکه‌های عصبی پیچیده مورد استفاده قرار گیرند.چالش‌های ترکیب مدل‌های LLM با شبکه‌های پیچیدهتعامل میان ساختارهای گراف و زبان: یکی از چالش‌های اصلی در ترکیب این دو مدل، تعامل میان ساختارهای گراف و زبان است. این به‌ویژه در شبکه‌های پیچیده‌ای که ساختارهای درختی یا پیچیده دارند، مشکل‌ساز است. نیاز به مدل‌هایی است که قادر باشند به‌طور مؤثر داده‌های متنی و گراف‌ها را به‌صورت هم‌زمان پردازش کنند.بهینه‌سازی منابع محاسباتی: ترکیب مدل‌های LLM با مدل‌های مولد شبکه‌های پیچیده به منابع محاسباتی زیادی نیاز دارد. به‌ویژه در مقیاس‌های بزرگ، این امر می‌تواند چالش‌هایی از نظر زمان پردازش و هزینه‌های محاسباتی ایجاد کند.دقت در شبیه‌سازی شبکه‌ها: در مدل‌سازی شبکه‌های پیچیده، مهم است که مدل‌های مولد بتوانند ویژگی‌های دقیق و واقعی شبکه‌ها را شبیه‌سازی کنند. از آنجا که شبکه‌های پیچیده ویژگی‌های خاصی دارند (مثل مقیاس‌پذیری، معیارهای مرکزیت، و ساختارهای خوشه‌ای)، تولید شبکه‌هایی که دقیقاً این ویژگی‌ها را داشته باشند، چالش‌برانگیز است.از دیگر کاربردهای مدل های LLM بهترکیب با ABM می‌توان اشاره کرد. که در این راستا مقاله LLM-Augmented Agent-Based Modelling for Social Simulations: Challenges and Opportunities مورد بررسی قرار می گیرد. هدف اصلی این مقاله بررسی چالش‌ها و فرصت‌های استفاده از مدل‌های زبانی بزرگ (LLM) در شبیه‌سازی‌های اجتماعی است. این مقاله به‌ویژه به چگونگی استفاده از مدل‌های زبانی پیشرفته برای تقویت شبیه‌سازی‌های مبتنی بر عامل (ABM) و نقش آن‌ها در تحلیل سیستم‌های اجتماعی پیچیده و پویای انسانی پرداخته است.مدل‌های زبانی بزرگ به دلیل توانایی‌های فوق‌العاده‌شان در پردازش زبان طبیعی، در حال تبدیل شدن به ابزاری قدرتمند برای تحلیل سیستم‌های اجتماعی پیچیده‌اند. این مدل‌ها می‌توانند شبیه‌سازی‌های انسانی و اجتماعی را با دقت بالاتری انجام دهند و رفتارهای انسانی، تعاملات اجتماعی و پویایی‌های گروهی را به‌طور واقع‌گرایانه‌تری مدل‌سازی کنند. در شبیه‌سازی‌های اجتماعی، این مدل‌ها به‌عنوان ابزاری برای تولید داده‌های غنی و پیش‌بینی تعاملات میان افراد یا گروه‌ها می‌توانند به‌کار روند.یکی از بزرگترین چالش‌ها در این زمینه، مفاهیم و فرضیات پایه‌ایبرای ادغام LLMها با مدل‌های مبتنی بر عامل است. این مدل‌ها به‌طور خودکار نتایج و فرضیات را تولید می‌کنند، اما درک و تحلیل آن‌ها در زمینه شبیه‌سازی‌های اجتماعی به دلیل پیچیدگی بالای رفتارها و تعاملات اجتماعی دشوار است. به‌علاوه، یک مشکل اساسی دیگر در این ادغام، عدم توانایی در تحلیل داده‌های پیچیدهاست که LLM‌ها تولید می‌کنند. شبیه‌سازی‌های مبتنی بر عامل معمولاً داده‌های زیادی تولید می‌کنند که تحلیل و تفسیر آن‌ها بسیار پیچیده است.یکی از مشکلات عمده در شبیه‌سازی‌های اجتماعی، جمع‌آوری داده‌هااست. این فرایند می‌تواند زمان‌بر و هزینه‌بر باشد و همچنین با مسائل مختلفی مانند کیفیت پایین داده‌ها، نبود دسترسی به منابع معتبر و مسائل اخلاقی مواجه است. استفاده از LLMها می‌تواند به بهبود این فرآیندها کمک کند. این مدل‌ها قادرند حجم زیادی از داده‌های متنی و اطلاعات مختلف را پردازش کنند و به تحلیل آن‌ها بپردازند تا مدل‌های دقیق‌تری ایجاد کنند.نویسندگان مقاله به معماری‌های پیشنهادیبرای بهبود شبیه‌سازی‌ها اشاره می‌کنند. به‌ویژه، معماری‌هایی مانند Retrieval Augmented Generation (RAG) می‌تواند نقش مؤثری در بهبود عملکرد شبیه‌سازی‌ها ایفا کند. در این معماری، داده‌ها به‌صورت قطعات کوچک تقسیم می‌شوند و سپس به‌عنوان ورودی به مدل‌های زبانی بزرگ ارسال می‌شوند. این می‌تواند منجر به شبیه‌سازی‌های دقیق‌تر و بهینه‌تر شود.مقاله به‌طور کلی نشان می‌دهد که استفاده از مدل‌های زبانی بزرگ در شبیه‌سازی‌های اجتماعی می‌تواند به‌طور چشمگیری کیفیت، دقت و قابلیت پیش‌بینی مدل‌ها را افزایش دهد. با این حال، این رویکرد با چالش‌هایی مواجه است که نیاز به تحقیقات بیشتر برای رفع آن‌ها دارد. با پیشرفت‌های بیشتر در زمینه LLM‌ها، این فناوری می‌تواند به ابزاری تحول‌آفرین در تحلیل و مدل‌سازی سیستم‌های اجتماعی تبدیل شود.جمع‌بندی و چشم‌انداز آیندهمدل های زبانی بزرگبا وجود پیشرفت‌های چشمگیر، هنوز با چالش‌هایی مانند نیاز به منابع محاسباتی عظیم، سوگیری، عدم درک واقعی، توهم و ملاحظاتیروبرو هستند. با این حال، آینده LLM ها بسیار روشن به نظر می‌رسد و انتظار می‌رود که در سال‌های آینده، شاهد پیشرفت‌های بیشتری در این حوزه باشیم. بدین ترتیب در تولید شبکه‌های پیچیده نیز همواره در حال پیشرفت و بهبود روش‌های قدیمی تر خواهیم بود و با استفاده از LLM ها و بهبود آن‌ها به تولید شبکه‌های واقعی‌تر و نزدیکتر به دنیای واقعی خواهیم رسید.مراجعA generative model for time evolving networksGraph Generation with Recurrent and Graph Neural NetworksGraphRNN: Generating Realistic Graphs with Deep Autoregressive ModelsA Survey of Large Language ModelsNetGAN: Generating Graphs via Random WalksA Comprehensive Overview of Large Language ModelsA Data-Driven Graph Generative Model for Temporal Interaction NetworksTIGGER: Scalable Generative Modeling for Temporal Interaction GraphsLanguage Models are Few-Shot LearnersGenerative Pre-trained Transformer: A Comprehensive Review on Enabling Technologies, Potential Applications, Emerging Challenges, and Future DirectionsAttention Is All You NeedLLM-Augmented Agent-Based Modelling for Social Simulations: Challenges and Opportunities مائده حشمتی مائده حشمتی Sat, 08 Feb 2025 23:30:38 +0330