https://virgool.io/feed/@m_98739531 fa 2026-06-16 22:01:22 https://static.virgool.io/images/default-avatar.jpg https://virgool.io/@m_98739531 https://virgool.io/@m_98739531/%D8%AA%D9%85%D8%B1%DB%8C%D9%86-%D8%A7%D9%88%D9%84-%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-ckganjp6hamd کیانوش آرین 404443009تمرین اول معماری نرم‌افزار 1. Chaos Engineeringدر Chaos Engineering، برای این که عملکرد سیستم را تحت شرایط خاص بررسی کنیم خودمان مشکلات مختلفی در آن ایجاد می‌کنیم و بررسی می‌کنیم که سیستم چه واکنشی نشان می‌دهد. مثلا درگاه های خارجی (مثلا درگاه پرداخت، پیامک و ...) را قطع می‌کنیم، دیتابیس را قطع می‌کنیم، سرعت اینترنت سرور را کم می‌کنیم، یا سیستم را تحت فشار ترافیک بالا قرار می‌دهیم. پس از بررسی رفتار سیستم، می‌توانیم چاره هایی بیاندیشیم تا اگر زمانی این مشکلات واقعا در پروداکشن پیش آمدند، سیستم Resilience و Robustness بیشتری داشته باشد. از معروف ترین ابزار هایی که برای Chaos Engineering پدید آمده اند می‌توان Chaos Monkey را نام برد که توسط Netflix ایجاد شده که به طور رندوم VM های مختلف در محیط Production را از کار می‌اندازد تا بتوانیم رفتار سیستم را در آن شرایط بررسی کنیم. 2. Backend for Frontendدر بسیاری از اپلیکیشن های تحت وب، تنها یک بک اند توسعه می‌دهیم و در تمام فرانت اند هایمان (مثلا اپ سمت کاربر، اپلیکیشن سمت ادمین، در گوشی، دسکتاپ،...) از همان یک بک اند استفاده می‌کنیم. از جایی که منطق مورد نیاز در فرانت اند های مختلف تا حد زیادی شبیه به یکدیگر است توسعه ی یک بک اند برای تمامی آنها منطقی به نظر می‌رسد. اما مشکل آنجاست که نیازمندی های non-functional در فرانت اند های مختلف، مثلا سمت کاربر و ادمین، با یکدیگر متفاوت هستند و ممکن است اپ سمت کاربر هزاران درخواست در ساعت داشته باشد درحالی که اپ سمت ادمین تنها چند صد درخواست در روز دارد، یا فرانت اند های مختلف از نظر سطح امنیت با یکدیگر متفاوت باشند. بنابراین، معماری Backend for Frontend پیشنهاد می‌دهد که برای هر frontend مختلف، یک سرویس backend مخصوص به خودش ایجاد کنیم تا متناسب با نیاز های آن front-end به آن سرویس ارائه کند. این معماری چهار مزیت کلیدی دارد.1. داده های ارائه شده به هر فرانت اند دقیقا به اندازه نیازش است، بنابراین باعث کاهش استفاده از اینترنت، شارژ موبایل و ... می‌شود.2. وابستگی بین تیم های توسعه مختلف به دلیل جداسازی دغدغه ها کاهش می‌یابد.3. پیچیدگی در فرانت اند های مختلف کاهش می‌یابد زیرا دیگر لازم نیست با بک اند بزرگ و کلی ارتباط برقرار کنند.4. به دلیل اضافه کردن یک لایه BFF میانی، امنیت را افزایش می‌دهد. 3. AI4SEبه طور کلی هر گاه که از هوش مصنوعی برای کمک در قسمتی از مهندسی نرم‌افزار استفاده کنیم، به آن AI4SE گفته می‌شود. امروزه با پیشرفت های مدل های بزرگ زبانی ابزار های بسیاری از جمله Cursor, Windsurf, Claude Code و ... ایجاد شده که توانایی انجام کار هایی از جمله تولید کد، دیباگ کردن، ایجاد داکیومنتیشن، و حتی اجرای دستورات در shell و تست کردن نرم‌افزار را دارا هستند. به غیر از کمک در برنامه نویسی، می‌توان از این ابزار ها در مراحل دیگر مهندسی نرم‌افزار از جمله تولید و بررسی مورد های کاربری، نیازمندی ها و ... استفاده کرد. 4. SE4AISE4AI به هنگامی گفته می‌شود که از اصول مهندسی نرم افزار برای ایجاد یا بهبود و مدیریت سیستم های هوش مصنوعی استفاده کنیم. برای مثال، میدانیم که سیستم های هوش مصنوعی غیر قابل پیش بینی هستند، و این غیر قابل پیش بینی بودن تست کردن عملکرد آنها را دشوار می‌کند. یکی از سوال های زمینه SE4AI این است که چگونه سیستمی طراحی کنیم که بتواند عملکرد ایجنت های هوش مصنوعی را تست کند. یا ممکن است نیاز داشته باشیم تا Guardrail هایی را بر روی مدل های هوش مصنوعی نصب کنیم تا پاسخ های غیرقابل قبول یا محرمانه به کاربران ندهند. این Guardrail ها باید سیستم های قابل اعتماد نرم‌افزاری باشند تا مطمئن باشیم در صورت تولید پاسخ های نامناسب، این پاسخ ها به کاربران نمایش داده نشود. یا مثلا برای تولید، آزمایش و مقایسه Prompt هایی که برای استفاده از مدل های هوش مصنوعی استفاده می‌کنیم نیاز به یک سیستم مدیریت متن داریم که باید تحت اصول مهندسی نرم‌افزار تولید شود. به این گونه کارکرد های مهندسی نرم‌افزار برای بهبود و مدیریت سیستم های هوش مصنوعی، SE4AI گفته می‌شود. 5. MLOpsایجاد سیستم های مبتنی بر یادگیری ماشین شامل مراحل مختلفی از جمله جمع آوری داده، pre-process، یادگیری، ارزیابی، دیپلوِی، و مانیتورینگ می‌باشد. در MLOps، به طراحی pipeline هایی می‌پردازیم که قسمت هایی از این فرایند را خودکار کنند. برای مثال، با وارد شدن داده های جدید، به طور خودکار مدل را دوباره train کرده و دیپلوی و ارزیابی کنند. این کار CT (Continuous Training) نام دارد. همچنین، ورژنینگ نسخه های مختلف مدل، پارامتر ها و وزن های مدل به همراه مانیتور کردن عملکرد مدل ها و تشخیص Data Drift و Concept Drift از جمله کار هایی هستند که در MLOps انجام می‌شوند. 6. Infrastructure as Codeدر Infrastructure as Code، بجای آن که سرور، دیتابیس، یا شبکه را به صورت دستی مدیریت و کانفیگ کنیم، برای انجام آن اسکریپت هایی می‌نویسیم تا آن عملیات را به طور خودکار انجام دهند. مثلا هر بار بعد از تعویض سرور، برای انجام تنظیمات اولیه بجای انجام دستی این تنظیمات، برای آنها اسکریپت و کانفیگ های آماده ای ایجاد می‌کنیم تا این تنظیمات راحت تر انجام شوند. از مزایای IaC می‌توان امکان خودکار سازی، مستند سازی تنظیمات، عدم وابستگی به یک شخص خاص برای انجام تنظیمات، و مقیاس پذیری ساده تر را نام برد. Ansible و Terraform از معروف ترین ابزار ها جهت انجام این کار هستند. برای ایجاد IaC ها، دو روش Imperative و Declarative وجود دارد. در روش Imperative به ترتیب Command هایی که باید انجام شوند را بیان می‌کنیم، در حالی که در روش Declarative یک توصیف از وضعیت مطلوب سیستم (مثلا یک فایل yml) به ابزار های IaC ارائه می‌کنیم و این ابزار ها، عملیات مورد نیاز برای رسیدن به وضعیت مطلوب را برای ما انجام می‌دهند. 7. API Gateway and Service Meshدر روش ارتباط API Gateway، یک Gateway کلی داریم که کلاینت ها برای تمامی عملیات خود به آن Gateway مراجعه کرده و API مورد نیاز خود را فراخوانی می‌کنند. این مدل یک مدل client to service است که در آن کلاینت ها به سرویس (همان API Gateway) مراجعه می‌کنند. درحالی که Service Mesh، یک مدل service to service می‌باشد و معمولا برای مدیریت ارتباطات میان میکروسرویس ها استفاده می‌شود. در این مدل، در کنار هر میکروسرویس یک پروکسی به نام Sidecar قرار می‌دهیم (که به آن Data Plane نیز گفته می‌شود) و این پروکسی، تمامی ارتباطات ورودی و خروجی میکروسرویس را مدیریت می‌کند. همچنین یک Control Plane داریم که پروکسی ها را مدیریت کرده و به هر Sidecar می‌گوید که چگونه ارتباطات را مدیریت کند، پروتکل های امنیتی را اعلام کرده و آنها را مانیتور می‌کند. این مدل ارتباطی سبب می‌شود تا مدیریت ارتباطات بین سرویس ها ساده تر شده، امنیت افزایش پیدا کرده و قابلیت مشاهده سیستم بالا برود. 8. Command Query Responsibility Segregationمعماری CQRS عملیاتی که در داده ها تغییر ایجاد می‌کنند (update, delete, create) را از عملیاتی که تغییری ایجاد نمی‌کنند (read) جدا کرده و دسته اول را command ها و دسته دوم را query ها نام‌گذاری می‌کند. همچنین، این معماری دیتامدل های مورد استفاده توسط کامند ها و کوئری ها را کاملا از یکدیگر جدا کرده و حتی این قابلیت را به ما می‌دهد که برای هر کدام از دیتابیس های مختلفی استفاده کنیم. این کار به پرفورمنس ما کمک می‌کند زیرا می‌توان از دیتابیس های مختلف بهینه شده برای هر کدام از عملیات های خواندن و تغییر داده ها استفاده کرد. همچنین این معماری به ما قابلیت scalability زیادی برای دیتابیس کوئری ها می‌دهد زیرا این دیتابیس ها معمولا از سرعت بسیار بالا تری برخوردارند. همچنین با استفاده از این معماری می‌توان می‌توان مدیریت امنیت و پیچیدگی را بیشتر در سمت command ها نگاه داشت و آنها را از قسمت query ها جدا کرد. 9. Event-Driven Architectureدر معماری Event-Driven، کامپوننت های مختلف از طریق تولید و واکنش دادن به Event های مختلف با یکدیگر ارتباط برقرار می‌کنند. در این معماری، سه عضو کلیدی وجود دارند. اولین عضو، Event Producer ها هستند که همان کامپوننت های تولید کننده Event هستند و پس از ایجاد شرایط خاصی، یک Event تولید کرده و ارسال می‌کنند. این کامپوننت ها اطلاعی از دریافت کنندگان ایونت ندارند و تنها آنرا تولید کرده و ارسال می‌کنند. دومین عضو، Event Router ها هستند که در واقع middleware هایی هستند که ایونت ها را دریافت کرده و ایونت های متناسب با نیاز هر کامپوننت مصرف کننده را به آن هدایت می‌کنند. سومین عضو، Event Consumer ها هستند که ایونت ها را دریافت کرده و متناسب با آنها واکنش نشان می‌دهند. هر consumer به تعدادی Event خاص Subscribe کرده و هر گاه آن Event منتشر شود، از آن مطلع می‌شوند. این معماری مزایایی از جمله Loose Coupling و ارتباط Async میان کامپوننت ها را به ما می‌دهد زیرا کامپوننت ها برای مطلع شدن از یکدیگر، نیازمند به ارسال درخواست و دریافت پاسخ ندارند. همچنین، این معماری Scalability و Flexibility سیستم را افزایش می‌دهد. 10. Serverless Architectureدر معماری Serverless، بجای این که توسعه دهنده یک سرور خریداری کرده و تمام زیرساخت های لازم را روی آن سرور بالا بیاورد، از سرویس های Cloud مانند آمازون، گوگل، و یا Azure برای اجرای کد ها استفاده می‌کند. در این معماری، توسعه دهنده Function های مختلفی را تعریف می‌کند و آنها را بر روی Cloud قرار می‌دهد. این فانکشن ها به صورت Event-Driven اجرا شده و در ابتدا غیر فعال بوده، و پس از یک ایونت (مثلا درخواست کاربر، آپلود فایل، ...) فراخوانی شده و وظایف خود را انجام داده و دوباره خاموش می‌شوند. در این روش توسعه دهندگان لازم نیست هزینه کامل سرور را پرداخت کنند و می‌توانند تنها به اندازه فراخوانی شدن فانکشن هایشان پول بپردازند. همچنین، Scaling و هندل کردن کاهش و افزایش بار درخواست ها توسط ارائه دهنده سرویس Cloud به طور خودکار انجام شده و از دغدغه های توسعه کننده حذف می‌شود. 11. API-first Approachدر این روش پیش از آغاز توسعه، ابتدا API ها به طور کامل طراحی شده و endpoint های آنها، فرمت و داده های درخواست و پاسخ و مستندات API ها به طور کامل مشخص می‌شوند تا تمام تیم ها از کارکرد آنها کاملا مطلع باشند. این به تیم های مختلف توسعه کمک می‌کند تا از فرمت نهایی درخواست ها آگاه باشند، و بتوانند توسعه بخش مربوط به خود را (مثلا front-end) با کمک داده های mock که از مستندات API استخراج شده پیش ببرند و به طور موازی کار کنند. 12. Domain Driven Designدر DDD، سعی می‌کنیم تا ساختار کلاس ها و کدمان تا جای ممکن شبیه به ساختار کسب و کار باشد. برای مثال، اگر برای یک فروشگاه دارای موجودیت های "مشتری"، "کالا" و "پرداخت" یک سیستم طراحی می‌کنیم، تقسیم بندی و نامگذاری کلاس های این سیستم را نیز به شکل "مشتری"، "کالا" و "پرداخت" انجام می‌دهیم. این روش یک زبان مشترک به تیم های مختلف از جمله افراد کسب و کار و افراد فنی می‌دهد، برای مثال وقتی کسی از "مشتری" صحبت می‌کند، همه می‌فهمند که منظور از این مشتری چه موجودیتی است. همچنین، در حوزه های گسترده ای که یک کلمه ممکن است در چندین مکان به معانی مختلف استفاده شود، context های مختلف تعریف می‌شوند. مثلا context انبار و context فروشگاه می‌توانند هر دو دارای موجودیت "مشتری" باشند اما معنی این مشتری در این دو context متفاوت تعریف می‌شود. به این عمل، Bounded Context می‌گویند. 13. Hexagonal Architectureدر معماری Hexagonal، منطق کسب و کار با استفاده از تعدادی Adapter به طور کامل از دیگر قسمت ها محافظت می‌شود. در واقع بجای این که منطق کسب و کار به طور مستقیم با UI و DB در ارتباط باشد، تعدادی Adapter در میان این ارتباط قرار می‌گیرند و به عنوان واسط بین منطق کسب و کار و دیگر اجزا نقش ایفا می‌کنند. همچنین، تعدادی Port تعریف می‌شوند که قوانین و شرایطی که Adapter ها برای ارتباط با خارج باید از آنها پیروی کنند را مشخص می‌کنند. به دلیل Decouple شدن قسمت های مختلف نرم‌افزار، می‌توان هر قسمت را به طور جداگانه و بدون نگرانی از تغییرات خارجی تست کرد، و یا کامپوننت های مختلف از جمله دیتابیس را بدون نگرانی از خراب کردن دیگر قسمت های نرم‌افزار تعویض کرد. همچنین، این معماری امکان توسعه جداگانه قسمت های مختلف نرم‌افزار توسط تیم های مختلف را فراهم می‌کند. 14. Event Sourcingدر سیستم های عادی، داده ها را به شکل یک مقدار عددی یا متنی نگه داری می‌کنیم. اما در Event Sourcing، بجای این که تنها یک عدد یا متن برای مقدار فعلی داده ها داشته باشیم، یک لیست نگهداری می‌کنیم که تمامی تغییرات داده از ابتدا تا انتها در آن نگهداری می‌شوند. مثلا، برای آدرس کاربران مقدار لیست می‌تواند اینگونه باشد:address.added (Tehran)address.updated (Shiraz)این گونه بجای تنها مقدار فعلی، سابقه تمامی تغییرات داده ها را داریم و این به ما امکان انجام انواع تحلیل های داده، دیباگ با کمک بازسازی استیت گذشته برنامه و ... می‌دهد. همچنین، با استفاده از این روش عملیات update بجای تغییر ویرایش مقدار قبلی تنها لازم است یک مقدار جدید به لیست Append کند که از نظر پرفورمنس عملکرد بهتری دارد. 15. Low-Code / No-Code Platformsاین پلتفرم ها، با ایجاد زیر ساخت های تصویری و منطقی به کاربران امکان ایجاد برنامه هایی بدون کد نویسی یا با مقدار بسیار کم کد نویسی می‌دهند. ایجاد برنامه در این پلتفرم ها بسیار ساده تر از برنامه نویسی سنتی است و می‌تواند توسط هر شخصی که لزوما با اصول برنامه نویسی آشنا نیست با هزینه کمتر انجام شود. در مقابل، این برنامه ها انعطاف پذیری کمتری به توسعه دهنده می‌دهند و امکان انجام هر عملی را برای افراد فراهم نمی‌کنند. از این پلتفرم ها برای ایجاد و آزمایش دمو های اولیه و کاهش هزینه ها استفاده می‌شود. از جمله این پلتفرم ها می‌توان Bubble, Zapier, Glide و Webflow را نام برد. 16. Business Process Management SystemsBPMS ها سیستم هایی هستند که فرایند های سازمانی را کامپیوتری و خودکار می‌کنند. برای مثال، اگر یک فرایند سازمانی شامل مراحلی از جمله ارسال نامه، بررسی توسط بخش مالی، امضای مدیر عامل، اعلام تایید هست، این فرایند ها داخل نرم افزار BPMS به شکل فایل های BPMN (Business Process Model and Notation) تعریف شده و مراحل آن هر بار به طور سیستماتیک به ترتیب اجرا می‌شود و به طور خودکار برای افراد مختلف از جمله مدیر عامل، بخش مالی، و ... ارسال می‌شوند. این برنامه ها معمولا در سازمان های بزرگ استفاده شده و به خودکار سازی فرایند ها، نظارت بر آنها، مانیتورینگ و گزارش گیری کمک فراوانی می‌کنند. از معروف ترین برنامه های BPMS میتوان به Camunda, jBPM, Bizagi اشاره کرد. 17. Message Queue (Kafka, RabbitMQ)Message Queue ها واسط هایی هستند که در میان دو سیستمی که می‌خواهند با یکدیگر ارتباط برقرار کنند قرار می‌گیرند و بجای این که این سیستم ها به طور مستقیم با یکدیگر ارتباط برقرار کنند، پیام ها را به این Queue داده و یا از آن دریافت می‌کنند. این Queue ها در مدیریت ارتباطات مثلا هنگام شلوغ بودن و یا در دسترس نبودن سیستم ها کمک می‌کنند تا ارتباط به شکل Async انجام شده و سیستم ها بتوانند طبق زمان بندی خودشان و هر وقت که بخواهند پیام ها را دریافت و به آنها رسیدگی کنند. Kafka یکی از این ابزار هاست که به طور خاص برای سیستم های بزرگ با حجم بالای ارتباطات مثلا چندین میلیون پیام تولید شده و RabbitMQ یکی دیگر از این ابزار هاست که برای ارتباطات Reliable ایجاد شده است. 18. Containers (Docker) and Container Orchestration (Kubernetes)کانتینر ها محیط هایی برای اجرای نرم‌افزار هستند که تمامی سورس کد، Dependency ها، تنظیمات، و محیط اجرای نرم‌افزار ها را در خود جمع آوری کرده و قابلیت اجرای آنها را بر روی هر سیستمی با Virtualization فراهم می‌کنند. با کمک کانتینر ها، اجرای برنامه در یک محیط جدید بدون نیاز به ورژن کنترل و انجام دوباره تنظیمات محیط برقرار می‌شود. Docker معروف ترین ابزار Containerization است که تمامی مولفه های مورد نیاز برای اجرای نرم‌افزار را در Docker Image ها جمع آوری می‌کند. هنگامی که تعداد زیادی کانتینر (صد ها و یا هزاران) داشته باشیم که به صورت توزیع شده برنامه را اجرا می‌کنند، به یک ابزار نیاز داریم که مدیریت لود، اسکیل کردن، ریکاوری از مشکلات، و به روز رسانی نرم‌افزار را برای این تعداد از کانتینر ها انجام دهد. به این کار Container Orchestration گفته می‌شود و توسط ابزار هایی از جمله Kubernetes به طور خودکار انجام می‌شود. این ابزار، هر کانتینر (یا تعدادی کانتینر به شدت مرتبط با یکدیگر) را در یک Pod قرار داده، و Pod ها را بین Node ها که سرور های اجرا کننده هستند پخش می‌کند. به تمامی Node هایی که برای اجرای نرم‌افزار با یکدیگر همکاری کرده و کار می‌کنند Cluster گفته می‌شود. 19. Multi-Tenacy Architectureدر معماری Multi-Tenacy، تعدادی گروه کاربر مختلف از یک نرم‌افزار استفاده می‌کنند، بدون این که داده ها و تنظیمات هر گروه بر استفاده از نرم‌افزار گروه دیگر تاثیر بگذارد. برای مثال، ممکن است که چندین شرکت از یک نرم‌افزار CRM (مدیریت ارتباطات با مشتری) استفاده کنند. در این صورت، داده های هر شرکت، باید به روشی از داده های دیگر شرکت ها جداسازی شود. چند روش برای انجام این کار وجود دارد. روش اول جداسازی کامل دیتابیس ها است، به طوری که نرم افزار مورد استفاده توسط هر گروه کاربر از یک دیتابیس کاملا جداگانه استفاده می‌کند. روش دوم، جداسازی Schema هاست، به طوری که نرم افزار همیشه از یک دیتابیس استفاده کرده، اما هر گروه کاربر Schema مخصوص به خود را دارد. روش سوم، استفاده از دیتابیس و Schema مشترک، و جداسازی رکورد های مربوط به هر گروه کاربر با استفاده از ستونی مانند TenantId می‌باشد. این روش کمترین هزینه را دارد اما از نظر امنیت و ایزوله سازی، ضعیف تر از روش های دیگر است. 20. Data MigrationData Migration هنگامی است که می‌خواهیم داده ها را از یک پایگاه داده به یک پایگاه داده دیگر منتقل کنیم. برای مثال، ممکن است بخواهیم دیتابیس خود را از PostgresSQL به MongoDB تغییر دهیم یا بجای ذخیره سازی داده ها در یک دیتابیس Cloud، آنها را در یک دیتابیس جدید در سرور و کنار خود اپلیکیشن نگهداری کنیم. در این موارد، ممکن است به دلیل تفاوت های موجود در دیتابیس های مبدا و مقصد، مانند SQL و no-SQL بودن، تفاوت در دیتا مدل ها و یا قوانین پایگاه داده، مجبور شویم عملیاتی برای هماهنگ سازی داده ها با نوع جدید ذخیره سازی انجام دهیم که به این کار Data Transform گفته می‌شود. منابع:geeksforgeeksaws amazonbytebytegoredhatwikipediasamnewmanmediumگفت و گو با Chatgpt و Gemini کیانوش آرین کیانوش آرین Sun, 31 May 2026 18:40:35 +0330 https://virgool.io/@m_98739531/%DA%A9%D8%A7%D8%B1%DA%A9%D8%B1%D8%AF-knowledge-graphs-%D8%AF%D8%B1-%D8%A8%D8%A7%D8%B2%DB%8C%D8%A7%D8%A8%DB%8C-%D8%A7%D8%B7%D9%84%D8%A7%D8%B9%D8%A7%D8%AA-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%AD%D8%A7%D9%81%D8%B8%D9%87-%D9%85%D8%AF%D9%84-%D9%87%D8%A7%DB%8C-%D8%B2%D8%A8%D8%A7%D9%86%DB%8C-dpvv0yocu300 کارکرد Knowledge Graphs در بازیابی اطلاعات برای حافظه مدل های زبانیکیانوش آرین 404443009 چکیدهبا پیشرفت و قدرتمند تر شدن مدل های زبانی، استفاده از آنها در حوزه های مختلف افزایش یافته است. اما این مدل های زبانی بی نقص نیستند و ممکن است پاسخ های غیرصحیح و ساختگی تولید کنند. همچنین، هزینه‌ی به روز رسانی و ساخت مجدد این مدل ها بسیار بالاست و امکان به روزرسانی داده های آنها به سادگی وجود ندارد. برای حل این مشکلات، راهکاری به نام Retrieval-Augmented Generation پیشنهاد شده که در آن LLM را به یک پایگاه داده خارجی متصل می‌کنند تا بتواند طبق نیاز خود از پایگاه داده اطلاعات بازیابی کند. این امر دسترسی مدل زبانی به اطلاعات جدید را فراهم می‌کند و به آن کمک می‌کند تا پاسخ هایش را بر اساس اطلاعات واقعی تولید کند. Knowledge Graph ها یک ساختار برای ذخیره سازی داده ها هستند که موجودیت ها و روابط میان آنها را در گراف ذخیره سازی می‌کنند و برخی عملیات از جمله جستجو، استدلال و پیمایش در اطلاعات را ساده تر می‌کنند. در این تحقیق، به بررسی نحوه استفاده از Knowledge Graph ها به عنوان منبع دانش برای استفاده مدل های زبانی می‌پردازیم و تحقیقات موجود در این زمینه را بررسی می‌کنیم. همچنین، این روش را با روش های سنتی بازیابی اطلاعات مقایسه کرده، و نقاط ضعف و قوت آن را نسبت به این روش ها بیان می‌کنیم. 1 مقدمهمدل های زبانی در بسیاری از عملیات‌های مربوط به زبان عملکرد قابل توجهی از خود نشان داده اند ]9[، به طوری که امروزه، از مدل های زبانی در زمینه های مختلف از جمله حوزه های پزشکی، اقتصادی و ... استفاده می‌شود ]8[. بنابراین مطالعات در زمینه بهبود کارکرد این مدل ها از اهمیت ویژه ای برخوردار است. مدل های زبانی هنگام تولید پاسخ از مشکلاتی همچون تولید توهم، دشواری پردازش متن های طولانی، و فراموش کردن تدریجی رنج می‌برند. همانطور که انسان ها می‌توانند از ابزار های خارجی، مانند دفترچه یادداشت، کامپیوتر، و... برای بهبود عملکرد مغز خود استفاده کنند، مدل های زبانی نیز می‌توانند از افزونه های خارجی برای بهبود توانایی های شناختی خود استفاده کنند ]8[. یکی از مهم ترین این ابزار ها، RAG است که با کمک آن مدل زبانی بجای اتکای کامل به حافظه درونی و پارامتر های خود، به از یک منبع دانش خارجی استفاده می‌کند تا پاسخ های مناسب تری را تولید کند. Knowledge Graph ها به دلیل ماهیت ساختارمندشان گزینه ی مناسبی برای استفاده به عنوان یک حافظه خارجی برای LLM هستند.در ادامه این مقاله، با ساختار فوق به بررسی این موارد می‌پردازیم. در قسمت دوم به معرفی و توضیح Knowledge Graph ها و کاربرد های آن می‌پردازیم. در قسمت سوم به توضیح Information Retrieval و به ویژه کاربرد آن برای توانمند سازی LLM ها می‌پردازیم و به روش های استفاده شده کنونی در این زمینه می‌پردازیم. در قسمت چهارم، به بررسی کارکرد Knowledge Graph ها در بازیابی اطلاعات برای LLM پرداخته، چندین روش معرفی شده در تحقیقات بدین منظور را شرح داده و نقاط قوت و ضعف این روش در مقایسه با روش های پیشین بررسی می‌کنیم. در انتها، در قسمت پنجم به جمع‌بندی و نتیجه گیری کلی پرداخته و یافته های تحقیق در این حوزه را با تمرکز بر نقاط قوت و ضعف، بیان می‌کنیم. 2 مروری بر ادبیات Knowledge Graph هاKnowledge Graph گراف جهت داری است که از تعداد راس و یال تشکیل شده، به طوری که هر راس یک موجودیت در جهان واقعی را نشان می‌دهد و یال های بین رئوس، رابطه معنایی بین دو موجودیت را نشان می‌دهد [1]. بنابراین Knowledge Graph را می‌توان با یک سه تایی (موجودیت اول، رابطه، موجودیت دوم) نمایش داد. برای مثال، رابطه بین دانشجو و رشته تحصیلی‌اش را می‌تواند به صورت (کیانوش آرین، تحصیل می‌کند، مهندسی کامپیوتر) نمایش داد. 2.1 ساخت Knowledge Graph هابرای ایجاد یک Knowledge Graph، ابتدا باید دانش (موجودیت ها و روابط میان آنها)، از منابع استخراج شود. این منابع می‌توانند ساختارمند (structured) یا بدون ساختار باشند [3]، برای مثال، یک صفحه کتاب منبعی بدون ساختار است، در حالی که یک فایل Excel می‌تواند حاوی اطلاعات ساختارمندی درباره یک موضوع باشد. استخراج دانش را می‌توان به روش‌ انسانی یا اتوماتیک انجام داد. روش انسانی بسیار هزینه‌بر است، در حالی که نتایج روش اتوماتیک به دلیل اجرای خودکار توسط کامپیوتر قابل اعتماد نیست و باید ارزیابی شود. چالش های ساخت Knowledge Graph عبارتند از قابل اعتماد بودن روش استخراج دانش و ارزیابی آن، محدود بودن روش های استخراج دانش به یک زبان، و ایجاد گراف های دانش چند وجهی (متن، تصویر، …) [3]. 2.2 کارکرد هاKnowledge Graph ها کاربرد وسیعی در بسیاری از زمینه‌ها از جمله پاسخ به query ها، جستجوی معنایی، به اشتراک گذاری دانش، سیستم های پیشنهاد‌دهی، مدیریت دانش و فیلد های مختلف از جمله پزشکی، آموزش و اقتصاد دارند [2] و از این جهت، تحقیق بر روی آنها از ارزش قابل توجهی برخوردار است. در بخش های بعدی این تحقیق به بررسی کاربرد این گراف ها در پاسخ به سوال، جستجوی معنایی و بازیابی اطلاعات می‌پردازیم. برخی از مهم ترین زمینه‌های تجقیقاتی مربوط به Knowledge Graph ها به شرح زیر هستند [3]:Knowledge Graph Embeddings:انتقال گراف به یک فضای برداری. معمولا این انتقال به گونه ای انجام می‌شود که نمایش برداری رئوس و یال ها با ساختار گراف رابطه داشته باشد.Knowledge Acquisition:نحوه استخراج دانش از منابع و ایجاد گراف از آنKnowledge Graph Completion:بهبود کیفیت گراف های موجود، پیش‌بینی رئوس و یال هایی که در گراف نمایش داده نشده اندKnowledge Fusion:ترکیب دانش استخراج شده از چندین منبع و استفاده از آنها برای ایجاد یک گراف واحدKnowledge Reasoning:استدلال بر روی گراف جهت پیدا کردن اطلاعات غلط، یا پیش‌بینی روابطی که یال های فعلی آنها را نمایش نداده استکارکرد در سیستم های هوش مصنوعی:مطالعه بر کارکرد Knowledge Graph ها در سیستم های پیشنهاد، پاسخ به سوال، و یا بازیابی اطلاعاتکارکرد های عملی:استفاده در فیلد هایی از جمله آموزش، پزشکی، فضای مجازی و … 3 مروری بر ادبیات بازیابی اطلاعات برای LLM هابا پیشرفت های اخیر در توانایی مدل های زبانی، استفاده از این مدل ها در انواع کارهای روزمره و حرفه ای افزایش پیدا کرده. اما پاسخ تولید شده توسط این مدل ها همیشه قابل اعتماد نیست، و به خصوص در کاربرد های مختص دامنه های خاص که اطلاعات کمتری در آن زمینه موجود است ممکن است پاسخ های اشتباه یا نامربوط تولید کنند. به این امر، توهم گفته می‌شود [4]. علاوه بر این، قدیمی بودن داده های Train مدل های زبانی و نیاز به اطلاعات به روز، و همچنین بدون منبع بودن پاسخ های مدل زبانی از محدودیت هایی است که استفاده گسترده از مدل های زبانی را دشوار می‌کند [5]. برای بهبود این مشکلات، روش جدید معرفی شد که در آن LLM ابتدا در یک منبع داده خارجی جستجو می‌کند تا اطلاعات مربوط را بازیابی کند، و سپس با کمک اطلاعات بازیابی شده، به سوال پاسخ دهد [5]. این روش که Retrieval-Augmented Generation یا به اختصار RAG نام دارد، می‌تواند عملکرد LLM ها در انواع کار ها را بهبود بخشد، چرا که به ما اطمینان می‌بخشد خروجی های LLM بر اساس اطلاعات بازیابی شده تولید شده اند و باعث ایجاد پاسخ های دقیق تر و قابل اعتماد تر می‌شود [6]. از جمله زمینه هایی که RAG در آن کاربرد دارد می‌توان به پاسخ‌دهی به سوالات، تولید متن و خلاصه سازی، بازیابی اطلاعات، بررسی متن، تولید و نگهداری نرم‌افزار، و تصمیم گیری اشاره کرد [6]. 3.1 نحوه بازیابی اطلاعاتبازیابی اطلاعات ممکن است از سه نوع منبع انجام شود دسته اول متن های بدون ساختار هستند، مثلا فایل text که به شکل ساده نوشته شده است. دسته دوم منبع های نیمه-ساختارمند مانند فایل PDF هستند که ترکیبی از متن و جدول ها هستند. دسته سوم منبع های کاملا ساختارمند مانند Knowledge Graph هستند که برای دستیابی به اطلاعات با دقت بالا استفاده می‌شوند [5]. برای بازیابی، مدل زبانی ابتدا یک Query تولید می‌کند، که عبارتی‌ست که میخواهیم آن را در متن جستجو کنیم، و سپس به روش های جستجوی متن مختلف مانند Embedding Search، BM25، یا روش ترکیبی، Query را در منابع جستجو می‌کند [5]. 4 کارکرد Knowledge Graph در بازیابی اطلاعات برای LLM هااستفاده از Knowledge Graph برتری های زیادی بر روش‌های Unstructured و Semi-Structured برای بازیابی اطلاعات دارد. تحقیقات نشان داده که روش های جستجوی Dense Vector Similarity مانند Embedding Search در پاسخ به سوالات پیچیده از سطح عملکرد کافی برخوردار نیستند [5]. همچنین، استفاده از Knowledge Graph ها در موقعیت هایی که توضیح و تفسیر پاسخ های داده شده از اهمیت برخوردار است ضروری می‌باشد [7]. برخی مثال های دیگر از این برتری ها عبارتند از [3]:افزایش بازدهی جستجو: با توجه به این که رئوس و یال های گراف از منابع متنی بسیار بزرگ استخراج شده اند، Knowledge Graph ها می‌توانند فضای جستجو را نسبت به کل منابع متنی کاهش دهند و عملیات را بهینه تر کرده و زمان جستجو را بهبود دهند.نتایج جستجوی دقیق تر: جستجو در Knowledge Graph ها بر اساس روابط بین موجودیت های گراف انجام می‌شود، که روشی دقیق تر از صرفا پیدا کردن شباهت بین Query و Document در روش های عادی بازیابی است.نمایش معنایی مفاهیم: در Knowledge Graph، مفاهیم به صورت مدل های Formal و متصل نمایش داده می‌شوند و قابلیت جستجوی معنایی، استدلال و گسترش Query دارند. این امر عموما سبب می‌شود موارد بیشتری بازیابی شوند و قابلیت توضیح سیستم را افزایش می‌دهد. در ادامه این بخش، به بررسی نمونه‌هایی از نحوه پیاده سازی بازیابی اطلاعات با کمک Knowledge Graph ها در تحقیقات پرداخته و نقاط قوت و ضعف آنها را بررسی می‌کنیم. 4.1.1 روش KG-RAG برای پاسخ‌دهی به پرسش هامحققان در این تحقیق [8] با پیاده سازی مدلی به نام KG-RAG به مقایسه عملکرد Knowledge Graph و روش های سنتی RAG برای پاسخگویی مدل های زبانی به پرسش هایی در دیتاست ComplexWebQuestions پرداختند. در روش KG-RAG ابتدا با استفاده از LLM ها یک Knowledge Graph از منابع متنی بدون ساختار ایجاد می‌شود. بدین منظور، LLM رئوس و یال های گراف را از منابع متنی با روش Few-Shot Learning استخراج می‌کند و گراف به طور اتوماتیک ایجاد می‌شود. همچنین، برای نمایش روابط پیچیده، سه‌تایی های موجودیت-رابطه-موجودیت خودشان می‌توانند به عنوان رئوس گراف در نظر گرفته شوند و با یک رابطه به رئوس دیگر متصل شوند. پس از ایجاد گراف، embedding های تمامی رئوس و یال های گراف محاسبه شده و در دیتابیس ذخیره می‌شود. این تحقیق، برای بازیابی اطلاعات روشی نوین به نام Chain of Explorations معرفی می‌کند که روش اجرای آن به طور فوق است:ابتدا به کمک Embedding Search، تعدادی از رئوس مشابه با Query را پیدا می‌کنیم و روابط متصل به آنها را بازیابی می‌کنیم. سپس، هر کدام را ارزیابی کرده و با کمک LLM تصمیم می‌گیریم که آیا تا این مرحله به پاسخ مورد نظر رسیده ایم یا نه. اگر به پاسخ رسیده بودیم، اطلاعات کسب شده را باز گردانده و پاسخ نهایی را تولید می‌کنیم. در صورتی که هنوز به پاسخ نرسیده بودیم، دوباره یال ها و رئوس را در سطح بعدی بازیابی کرده و عملیات را بر روی روابط جدید تکرار می‌کنیم. 4.1.2 مقایسه نتایج روش KG-RAG برای پاسخ‌دهی به پرسش ها با روش های پیشیننتیجه ی تست این پیاده‌سازی بر روی دیتاست ComplexWebQuestions نشان می‌دهد که استفاده از Knowledge Graph برای پاسخ‌دهی به سوالات به مقدار F1-Score 25% منجر می‌شود در حالی که استفاده از embedding-rag عادی مقدار F1-Score 37% به ما می‌دهد. همچنین، مقدار توهم های تولید شده توسط Knowledge Graph مقدار %15 می‌باشد، در حالی که روش embedding-rag عادی %30 توهم تولید می‌کند. این امر نشان‌دهنده آن است که با وجود این که Knowledge Graph عملکرد ضعیف تری در بازگرداندن پاسخ صحیح سوالات دارد، اما اطلاعات غلط بسیار کمتری نیز تولید می‌کند. این امر می‌تواند در کارکرد های خاصی که به شدت به پاسخ های غلط حساس هستند، مفید باشد. همچنین، نویسنده مقاله محدودیت توان پردازشی را مانعی در راه ایجاد Knowledge Graph از دیتاست به شکل کامل و همچنین تست تمام نمونه های دیتاست بیان می‌کند. 4.2.1 روش KRAGEN برای حل مسائل پیچیده و پاسخ‌دهی در حوزه پزشکیمحققان در این روش [10] برای کاهش توهم ها و اطمینان از صحت پاسخ های مدل زبانی در حوزه پزشکی، از Knowledge Graph ها برای بازیابی اطلاعات و از Graph of Thoughts برای تحلیل و استدلال بهره گرفته اند. هدف این تحقیق این بود که ببینند آیا افزودن Graph of Thoughts به فرایند بازیابی اطلاعات با Knowledge Graph ها سبب بهبود آن می‌شود یا نه. در این روش مسئله‌ای که مدل سعی در حل آن را دارد به تعدادی زیر مسئله مستقل شکسته شده و ارتباطات میان آنها (وابستگی های اطلاعاتی و پیش نیاز ها) به شکل یک گراف جهت دار نمایش داده می‌شوند (Graph of Thoughts). سپس، اطلاعات مورد نیاز برای هریک از زیر مسئله های داخل گراف با بازیابی اطلاعات از پایگاه داده استخراج می‌شود. بدین منظور، یک دیتاست با ساختار Knowledge Graph از اطلاعات پزشکی (بیماری ها، دارو ها، ویروس ها و ...) را انتخاب کرده، و آنرا به Embeddings تبدیل کرده، و در آن به صورت هیبرد Keyword Search و Embedding Search کردند. انجام Keyword Search به این دلیل اهمیت دارد که در حوزه پزشکی، اصطلاحات کمیاب و خاص بیشتر وجود دارد و Embedding Search به تنهایی، برای این نوع اطلاعات عملکرد ضعیف تری دارد. سپس، مدل با استفاده از پاسخ هر زیر مسئله و با توجه ارتباط زیر مسائل مختلف در گراف برای رسیدن به جواب صحیح استدلال کرده و جواب نهایی مسئله را تولید می‌کند. 4.2.2 نتایج روش KRAGENنویسندگان برای ارزیابی تاثیر این روش، آنرا بر روی دیتاست Alzheimer's Knowledge Graph پیاده سازی کرده و نتایج دو حالت زیر را مقایسه کردند:در حالت اول مطابق شرح بالا، از Graph of Thoughts به همراه بازیابی اطلاعات از Knowledge Graph استفاده شد.در حالت دوم، بدون استفاده از Graph of Thoughts و تنها با بازیابی اطلاعات به همراه Knowledge Graph به سوالات پاسخ داده شد.نتایج آزمایش نشان داد که افزودن Graph of Thoughts به بازیابی اطلاعات سبب بهبود نتایج در پاسخ‌دهی به سوالات چهار گزینه‌ای و صحیح / غلط می‌شود. در سوالات چند گزینه ای تک مرحله ای (یک بار بازیابی از Knowledge Graph) عملکرد از 56.6% به 70.4% بهبود یافته و در سوالات دو مرحله ای (دو بار بازیابی از Knowledge graph) عملکرد از 53.1% به 71.8% بهبود می‌یابد. در سوالات صحیح / غلط تک مرحله ای، accuracy از 68.6% به 80.3% و در سوالات دو مرحله ای، از 62.4% به 62.9% بهبود یافتند. بنابراین، نتایج نشان می‌دهند که افزودن Graph of Thoughts به بازیابی اطلاعات توسط Knowledge Graph ها سبب بهبود قابل توجه در نتایج این روش می‌شود. 4.3.1 LLAMAREC، سیستم پیشنهاد فیلم با کمک LLM و Knowledge Graphنویسندگان این تحقیق [11] در ابتدا بیان می‌کنند که روش های سنتی RAG که برای سیستم های توصیه استفاده می‌شوند تنها بر پایه شباهت معنایی کلمات بازیابی را انجام می‌دهد و ارتباطات ساختاری میان سلیقه کاربر و آیتم های توصیه شده را در نظر نمی‌گیرند. برای مثال، برای پیشنهاد فیلم سینمایی به کاربران عوامل زیادی از جمله کارگردان، بازیگران، ژانر، خلاصه، سال انتشار، و ... می‌تواند در تصمیم‌گیری موثر باشند که بسیاری از این ارتباطات در جستجوی معنایی از دست می‌روند. بنابراین، نویسندگان یک Knowledge Graph از فیلم ها ایجاد کرده، و می‌کوشند با یافتن ارتباطات میان فیلم های مورد علاقه کاربران با فیلم های کاندید برای معرفی، فیلم های کاندید را بر حسب علایق کاربران اولویت بندی کنند. بدین منظور، ابتدا با یک مدل سبک وزن مانند LRURec تعدادی کاندید برای پیشنهاد به کاربر استخراج می‌شود. سپس، زیر گرافی شامل فیلم های مورد علاقه کاربر به همراه کاندید های پیشنهادی برای بررسی بیشتر از Knowledge Graph استخراج می‌شود. در این مرحله، Knowledge Graph به یک شبکه عصبی داده می‌شود تا به کمک آن، مهم ترین عوامل در علایق کاربر (کارگردان، ژانر، ...) پیدا شده و قوی ترین ارتباطات میان علایق و فیلم های پیشنهادی کاندیدا یافت شود. خروجی این مرحله، این ارتباطات هستند که به شکل زیر نمایش داده می‌شوند.Alex -> Likes -> Christopher Nolan -> Directed -> Dunkirkسپس، این ارتباطات برای هر یک از فیلم های کاندید به مدل زبانی داده شده و از آن خواسته می‌شود تا یک عدد به عنوان احتمال تماشای این فیلم توسط کاربر خروجی بدهد. فیلم ها، بر اساس احتمالات داده شده توسط مدل زبانی، اولویت بندی می‌شوند. 4.3.2 مقایسه نتایج LLAMAREC به همراه Knowledge Graphبرای ارزیابی این روش، نویسندگان مدل LLAMAREC را در دو حالت با استفاده از Knowledge Graph و شبکه عصبی و بدون استفاده از آنها بر روی دو دیتاست فیلم ها و محصولات آرایشی آمازون مقایسه کرده اند.نتایح مقایسه در دیتاست فیلم ها بهبود قابل توجه 22.5% در پیشنهاد اولویت اول (NDCG@1)، و بهبود 7% در 5 اولویت اول (NDCG@5) را نشان می‌دهد، در حالی که در دیتاست محصولات آرایشی آمازون بهبود کمتر 5% در پیشنهاد اولویت اول و بدون بهبود در 5 اولویت اول دیده می‌شود. نویسندگان بهبود کمتر در پیشنهاد لوازم آرایشی را به دلیل sparse تر بودن گراف محصولات آرایشی و ارتباطات کمتر میان آیتم ها در این گراف می‌دانند.همچنین، مقاله یک آزمایش دیگر برای مشاهده تاثیر شبکه عصبی بر بهبود پیشنهادات انجام می‌دهد و نتایج، نشان‌دهنده اهمیت بیشتر شبکه عصبی هستند به طوری که بدون وجود آن، Knowledge Graph به تنهایی عملکرد بسیار ضعیفی از خود نشان می‌دهد. 4.4.1 KRGAR-SC، انتقال معنایی و بازسازی پیام در محیط های با پهنای باند کم و نویز بالا به کمک Knowledge Graph هادر این مقاله، سیستم ارتباطی ای با بازدهی بالا به کمک Knowledge Graph ها و LLM ها طراحی شده است تا در محیط هایی که به دلیل نویز و یا محدودیت های مختلف از جمله پهنای باند امکان ارسال پیام های طولانی موجود نیست، بتوان با حداقل انتقال اطلاعات و رساندن مفهوم، ارتباط برقرار کرد. بدین منظور، لازم است که فرستنده و گیرنده هر دو یک Knowledge Graph یکسان از entity ها و relation های میان آنها و توضیحات برای هر entity ای که در پیام مورد بحث قرار می‌گیرد را در اختیار داشته باشند. عملکرد این مدل بدین صورت است که ابتدا پیام اصلی که احتمالا طول بلندی دارد در نظر گرفته می‌شود و با Named Entity Recognition، رئوس گراف مرتبط با مفاهیم موجود در پیام، به همراه ارتباط این مفاهیم (یال های گراف) از پیام استخراج می‌شوند. کامیونیتی های داخل Knowledge Graph اصلی، به جهت پیدا کردن Entity های مناسب تر با مفاهیم داخل پیام جستجو می‌شوند و Entity های استخراج شده توسط یک LLM بررسی می‌شوند. سپس، بجای این که کل پیام برای مقصد ارسال شود، یک زیرگراف مینیمم از Knowledge Graph اصلی که از پیام استخراج شده برای مقصد ارسال می‌شود که به عنوان استخوان بندی اصلی پیام در نظر گرفته می‌شود. هنگام ارسال، به Entity های مرکزی تر (Centrality) اولویت بالاتری داده می‌شود و هنگام ارسال برای آنها سیستم پیشگیری از خطای بیشتری در نظر گرفته می‌شود تا اگر نویز محیط ارسال را خراب کرد، نود های مهم تر با احتمال کمتری خراب شوند. در نهایت، گیرنده Entity های گراف را دریافت کرده، توضیحات این نود ها را از گراف استخراج کرده و به LLM می‌دهد تا با توجه به روابط گراف، پیام را بازسازی کند. 4.4.2 مقایسه عملکرد KGRAG-SC با روش های پیشین از جمله Huffman Codingبرای بررسی عملکرد این روش، نویسندگان از دیتاست WebNLG استفاده کرده و معیار ارزیابی صحت انتقال پیام ها را Semantic Similarity میان پیام ارسال شده و دریافت شده با استفاده از مدل AllMiniLM-L6-v2 در نظر گرفته اند. نتایج ارزیابی نشان می‌دهد که در شرایط نویز بسیار بالا، روش KGRAG-SC بهبود قابل توجه‌ی نشان می‌دهد، به طوری که در نویز 4db، شباهت معنایی این روش 0.78 است در حالی که روش Huffman شباهت 0.285 به ما می‌دهد. در نویز بالاتر از 8db، روش Huffman به عملکرد تقریبا بی نقص 0.997 می‌رسند که کمی بیشتر از روش ابداعی این تحقیق در 0.882 است. بنابراین نتیجه این آزمایش به ما نشان می‌دهد که روش KGRAG-SC در شرایط محیطی با نویز بسیار بالا، به ما بهبود قابل توجهی در انتقال پیام می‌دهد در حالی که با بهبود شرایط و کاهش نویز، روش های سنتی برای انتقال پیام عملکرد بهتری از خود نشان می‌دهند. 4.4.1 روش Graph-RAG برای پاسخ‌دهی به کوئری های سطح بالابازیابی اطلاعات به روش های سنتی مانند embedding search تنها تعداد محدودی از قطعات اطلاعات متن اصلی را به ما می‌دهند درحالی که برای برخی تسک ها مانند خلاصه سازی متنهای طولانی و استخراج مفهوم از متن، به کل متن نیاز داریم و قطعات محدود بازیابی شده توسط روش های سنتی کافی نیستند. بنابراین، نویسندگان این تحیق [13] یک فریمورک سطح بالا برای فهم تمامی محتوای متن پیشنهاد کرده اند که حتی برای متن های بسیار طولانی با بازدهی مناسبی عمل می‌کند. این فریمورک، ابتدا با استخراج Entity ها و Relation ها از متن اصلی، یک Knowledge Graph ایجاد کرده و سپس با الگوریتم Leiden بر روی آن Community Detection انجام می‌دهد. Community های ایجاد شده در سه سطح Top-Level، Sub-Communities و Leaf-Level ایجاد می‌شوند. سپس، برای هر Community یک خلاصه توسط LLM تولید می‌شود. این خلاصه برای کامیونیتی های سطح برگ توسط رئوس و یال های گراف ایجاد شده، و ای کامیونیتی های سطح بالا تر توسط خلاصه های کامیونیتی های سطح پایین زیرمجموعه شان تولید می‌شود. در این مرحله، آماده سازی داده ها به پایان می‌رسد. هر بار که از مدل زبانی پرسشی درباره متن صورت بگیرد، مدل پاسخ را بر حسب خلاصه هر یک از Community ها تولید کرده، و در نهایت ترکیب این پاسخ ها به پاسخ کلی مسئله می‌رسد. 4.4.2 نتایج ارزیابی روش KG-RAGبرای ارزیابی، مدل پیشنهادی با دو مدل Vector RAG (بازیابی اطلاعات سنتی) و Source Text Summarization (خلاصه سازی مستقیم متن توسط LLM) مقایسه شده و معیار های Comprehensiveness و Diversity پاسخ های تولید شده ارزیابی می‌شود. در مقالات خبری، روش Vector RAG عملکرد 25.23 (تعداد فکت هایی از مقالات خبری مختلف استخراج شده) داشت در حالی که روش Graph RAG با مقدار 34.18 فکت، عملکرد بهتری در پاسخگویی به سوالات نشان داد. روش Text Summarization عملکرد کمی ضعیف تر از مدل Graph RAG داشته، اما مصرف توکن آن 26% تا 97% بیشتر از آن بوده. این نتایج نشان می‌دهند که GraphRAG، هم از لحاظ بهینه بودن در استفاده از منابع و هم از لحاظ عملکرد، بر روش های پیشین برتری دارد و می‌تواند بهتر به Query های جامع پاسخ دهد. همچنین، عملکرد پاسخ‌دهی GraphRAG با استفاده از سطوح مختلف Community ها مقایسه شده و نتایج نشان دادند که سطوح پایین تر Community ها (ریز دانه تر)، عملکرد بهتری نسبت به سطوح بالا دارند اما توکن بیشتری نیز برای تولید جواب استفاده می‌کنند 5 نتیجه گیری و جمع‌بندیLLM ها با وجود توانایی قابل توجه در انجام عملیات های مربوط به زبان طبیعی، از مشکلاتی همچون توهم، دشواری استدلال و فراموش کردن رنج می‌برند. استفاده از Knowledge Graph برای بازیابی اطلاعات می‌تواند به بهبود این مشکلات کمک کند. Knowledge Graph ها با ارائه اطلاعات به صورت ساختارمند، امکان بازیابی دانش مورد نیاز را فراهم می‌کنند تا LLM ها بتوانند پاسخ هایی مناسب تر با نیاز کاربر تولید کنند. در این مقاله، نحوه پیاده سازی بازیابی اطلاعات با کمک Knowledge Graph ها به این منظور شرح داده شد و همچنین برتری های آنها بر روش های سنتی بازیابی اطلاعات ذکر شد. همچنین، چند مثال از پیاده سازی های موردی Knowledge Graph برای بازیابی اطلاعات شرح و بررسی شد. نتایج تحقیقات به ما نشان دادند که استفاده از Knowledge Graph ها نسبت به روش های بازیابی اطلاعات سنتی، می‌تواند منجر به کاهش توهمات مدل های زبانی شود ]8[. این درحالی‌ست که دیگر تحقیقات نشان می‌دهند چگالی روابط داخل Knowledge Graph می‌تواند بر کیفیت پیشنهاد‌ها در سیستم های پیشنهاد کننده به کمک LLM تاثیر مستقیم بگذارد و هر چقدر روابط کامل تر باشند، پیشنهادات بهتری دریافت می‌کنیم ]11[. این گراف ها با وجود این که در برخی موارد در عین بهبود عملکرد استفاده از منابع را برای پاسخ‌گویی کاهش می‌دهند ]13[، اما به نیروی اولیه ای برای ساخت گراف نیاز دارند که ممکن است در نهایت سبب هزینه بیشتری شود. همچنین، این گراف ها ما را در خلاصه سازی و استخراج معنا از پیام های بلند یاری می‌کنند و به ویژه در محیط های با نویز بالا، امکان ارتباط سبک وزن را به کمک LLM ها را برای ما فراهم می‌کنند. همچنین، چندین مورد از تحقیقات بررسی شده از الگوریتم های Community Detection برای بهبود بازیابی اطلاعات از این گراف ها استفاده کرده اند که نشانگر اهمیت مفهوم Community ها در این حوزه می‌باشد. 6 منابع[1] Bordes A, Weston J, Collobert R et al (2011) Learning structured embeddings of knowledge bases. In: Twenty-fifth AAAI conference on artificial intelligence[2] Zou X (2020) A survey on application of knowledge graph. JPhCS 1487(1):012016[3] Peng, C., Xia, F., Naseriparsa, M. et al. Knowledge Graphs: Opportunities and Challenges. Artif Intell Rev 56, 13071–13102 (2023).[4] Kandpal, N., Deng, H., Roberts, A., Wallace, E., & Raffel, C. (2023). “Large language models struggle to learn long-tail knowledge,” In International Conference on Machine Learning. PMLR: 5696-15707.[5] Gao, Y., Xiong, Y., Gao, X., Jia, K., Pan, J., Bi, Y., ... & Wang, H. (2023). “Retrieval-augmented generation for large language models: A survey,” arXiv preprint arXiv:2312.10997.[6] Arslan, M., Ghanem, H., Munawar, S., & Cruz, C. (2024). “A survey on RAG with LLMs,” Procedia Computer Science, 246, 3781–3790.[7] Jiaoyan Chen, Freddy Lecue, Jeff Z. Pan, Ian Hor rocks, and Huajun Chen. Knowledge-based Transfer Learning Explanation. In KR, pages 349–358, 2018.[8] Sanmartin, D. (2024). “KG-RAG: Bridging the Gap Between Knowledge and Creativity,” arXiv preprint arXiv:2405.12035.[9] Pan, J. Z., Razniewski, S., Kalo, J.-C., Singhania, S., Chen, J., Dietze, S., Jabeen, H., Omeliyanenko, J., Zhang, W., Lissandrini, M., Biswas, R., de Melo, G., Bonifati, A., Vakaj, E., Dragoni, M., & Graux, D. (2023). Large language models and knowledge graphs: Opportunities and challenges. Transactions on Graph Data and Knowledge, 1(1), 2:1–2:38.[10] Matsumoto N, Moran J, Choi H, Hernandez ME, Venkatesan M, Wang P, Moore JH. KRAGEN: a knowledge graph-enhanced RAG framework for biomedical problem solving using large language models. Bioinformatics. 2024 Jun 3;40(6):btae353. doi: 10.1093/bioinformatics/btae353. PMID: 38830083; PMCID: PMC11164829.[11] Azizi, V., & Koochaki, F. (2025). LlamaRec-LKG-RAG: A Single-Pass, Learnable Knowledge Graph-RAG Framework for LLM-Based Ranking. arXiv preprint arXiv:2506.07449.[12] Fan, D., Meng, R., Gao, S., & Xu, X. (2025). KGRAG-SC: Knowledge Graph RAG-Assisted Semantic Communication. 2025 lEEE International Conference on Cloud Computing Technology and Science (CloudCom), 1-7.[13] Edge, D., Trinh, H., Cheng, N., Bradley, J., Chao, A., Mody, A.N., Truitt, S., & Larson, J. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. ArXiv, abs/2404.16130. کیانوش آرین کیانوش آرین Mon, 09 Feb 2026 22:22:38 +0330