تصور کنید برنامهای دارید که هر بار در اجرای یک دستور شکست میخورد، بهجای نمایش خطا، متوجه اشتباهش شود و تا رسیدن به نتیجه درست، مسیر خود را اصلاح کند. اگر توسعهدهندهای هستید که از استقرار مدلهای زبانی در محیط عملیاتی خسته شده است، باید بدانید که عصر «تلاش و خطا» با دخالت انسان در حال به پایان رسیدن است. کلید تبدیل خروجیهای احتمالی و تصادفی (Stochastic) مدلهای زبانی بزرگ به یک فرآیند قطعی (Deterministic)، پیادهسازی یک «قشر سنتتیک» است؛ یک خط لوله هوش مصنوعی در سطح تولید که با استفاده از Semantic Kernel میتواند بهطور خودکار توهمات خود را شکار کرده و تکالیف را تا زمان تطابق کامل با یک «اصل حقیقت» (Truth Principle) سختگیرانه تکرار کند.
بیشتر عاملهای هوش مصنوعی (AI Agents) امروزی، چتباتهای ایستا هستند که با انباشت باگها و تغییر پنجرههای زمینه، بهمرور کیفیت خود را میبازند. این راهنما بهطور خاص برای توسعهدهندگان، بنیانگذاران و سازندگان هوش مصنوعی در اکوسیستم مایکروسافت طراحی شده است که آمادهاند از دموهای ساده «Hello World» فراتر روند. هدف این است که سیستمی ساخته شود که دقیقاً برعکس برنامههای استاندارد عمل کند: یک «دارایی تکاملی» (Compounding Asset) که از هر خطا درس میگیرد و مسیرهای عملیاتی خود را از طریق حلقههای بازخورد بازگشتی (Recursive Feedback Loops) بهینه میکند.
یک برنامه سنتی را مانند ابزاری تصور کنید که با هر بار استفاده فرسوده میشود. در مقابل، یک دارایی تکاملی بیشتر شبیه به یک ورزشکار حرفهای است که بعد از هر تلاش ناموفق، قویتر میشود. این تغییر رویکرد، هوش مصنوعی را از یک رابط ساده برای API (API Wrapping) به یک سیستم معماری تبدیل میکند که قادر به استدلال مستقل، اجرا و مهمتر از همه، اصلاح خود بدون دخالت انسان است.
معماری سهلایه برای خودترمیمی
بر اساس مستندات و طرح Nexus Forge، این سیستم برای دستیابی به قابلیتهای خودترمیمی بر سه لایه متمایز متکی است:
- لایه ارکستراسیون (Orchestration Layer): توسط Azure Functions و Semantic Kernel هدایت میشود. این لایه بهعنوان مغز سیستم عمل میکند که وظیفه مدیریت قصد کاربر (Intent) و برنامهریزی مراحل اجرا را بر عهده دارد.
- لایه حافظه (Memory Layer): از Azure Cosmos DB با قابلیت جستوجوی برداری (Vector Search) استفاده میکند تا حافظه بلندمدت و حافظه کاربردی را که از تعاملات گذشته میآموزد، بهصورت پایدار ذخیره کند.
- لایه ارزیابی (Evaluation Layer): مدل Azure OpenAI GPT-4 Turbo (نسخه با پنجره متنی ۱۲۸ هزار توکنی برای استدلالهای عمیق) در اینجا بهعنوان یک منتقد داخلی عمل میکند. وظیفه این لایه بررسی خروجیها در برابر «اصل حقیقت» و فعالسازی چرخه خوداصلاحی است.
جزئیات پیادهسازی و هسته مرکزی
برای ساخت این سیستم، از .NET 8 و Semantic Kernel (SK) استفاده شده است. در این معماری، SK مانند چسبی برای هوش مصنوعی عمل میکند و به مدلهای زبانی بزرگ (LLM) — شبیه کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — اجازه میدهد تا بهجای اینکه صرفاً به عنوان رابط چت عمل کنند، توابع کد بومی را از طریق پلاگینها ارکستر کنند.
به توسعهدهندگان توصیه میشود که از کلاینتهای عمومی Azure.AI.OpenAI اجتناب کرده و در عوض بستههای زیر را نصب کنند:
Microsoft.SemanticKernelMicrosoft.SemanticKernel.Connectors.OpenAIMicrosoft.SemanticKernel.Connectors.Memory.AzureCosmosDBNoSQL
به نقل از توسعهدهندگان این طرح، برای تضمین مقیاسپذیری افقی در Azure، هسته سیستم با الگوی تزریق وابستگی (Dependency Injection) پیکربندی شده است. در این روش، Kernel.CreateBuilder() با استقرار gpt-4-turbo تنظیم میشود و EndPointها و کلیدهای API برای تضمین امنیت در محیط تولید، از متغیرهای محیطی یا Azure Key Vault فراخوانی میشوند.
سازوکار حلقه خودترمیمی (Critic Chain)
قلب تپنده این سیستم، «زنجیره منتقد» (Critic Chain) است. عامل بهجای ارسال فوری پاسخ به کاربر، خروجی خود را به یک پرامپت تضمین کیفیت اختصاصی میفرستد. این منتقد داخلی که دقیقاً مانند یک «مهندس QA هوش مصنوعی» عمل میکند، موارد زیر را بهطور سختگیرانه بررسی میکند:
- ارتباط مستقیم و دقیق پاسخ با درخواست اولیه کاربر.
- وجود نشانگرهای دادهای خاص و مورد نیاز در خروجی.
- ثبات و انسجام منطقی کلی پاسخ.
اگر ارزیاب پاسخ را رد کند، یک شیء JSON بازمیگرداند که شامل یک مقدار Boolean برای isAcceptable (که در حالت خطا False است)، دلیل شکست (reasoning) و یک دستورالعمل اصلاحی دقیق (correctionInstruction) است. سپس عامل این دستورالعمل را دوباره به پرامپت خود تزریق میکند — در واقع به خودش میگوید که چگونه پاسخ را بهبود بخشد — و تکالیف را مجدداً تلاش میکند. این فرآیند که ExecuteWithHealingAsync نام دارد، تا زمان پذیرش پاسخ یا رسیدن به حد مجاز تکرار (که معمولاً ۳ بار است) ادامه مییابد.
مبنیسازی با پلاگینهای بومی
برای کاهش بیشتر خطاها، این معماری بهجای تکیه صرف بر دانش داخلی مدل (Internal Weights)، از توابع کد بومی یا پلاگینها استفاده میکند. با ثبت ابزارهای خاص مانند TimePlugin و DataAnalyticsPlugin در هسته، مدل مجبور میشود برای تأیید دادهها و استخراج اطلاعات دقیق، این ابزارها را فراخوانی کند.
نویسنده طرح گزارش میدهد که با مبنیسازی (Grounding) استدلالها بر اساس یک منبع حقیقت خارجی بهجای تکیه بر احتمالات مدل، نرخ توهم (Hallucination) — یعنی وقتی مدل با اطمینان چیزی میگوید که اصلاً وجود ندارد — در محیط تست حدود ۴۰٪ کاهش یافته است. این امر تضمین میکند که عامل بهجای یک فرآیند احتمالی، مانند یک فرآیند قطعی رفتار کند.
یکپارچهسازی حافظه بادوام
برای اینکه یک عامل واقعاً تکاملی باشد و بتواند «ضریب رشد» ایجاد کند، باید مسیرهای موفقیتآمیز را به خاطر بسپارد. این طرح از Azure Cosmos DB NoSQL API با قابلیتهای جستوجوی برداری برای ایجاد یک گراف دانش تحت عنوان «NexusKnowledgeGraph» در مجموعهای به نام «LongTermMemory» استفاده میکند.
برای دستیابی به دقت بالا در ابعاد زیاد، سیستم از مدل text-embedding-3-large از طریق Azure OpenAI استفاده میکند. این قابلیت به عامل اجازه میدهد تا:
- پیش از تولید پاسخهای جدید، جستوجوهای معنایی روی تعاملات و تجربیات گذشته انجام دهد.
- الگوهای موفق را زمانی که یک
SelfHealingPipelineبه وضعیت موفقیت دست یافت، ذخیره کند. - پایگاهداده را بهعنوان یک حافظه در حال رشد از راهکارهای اثباتشده و تستشده ببیند.
تحلیل: تغییر پارادایم در مهندسی هوش مصنوعی
این معماری تمرکز را از «مهندسی پرامپت» (Prompt Engineering) به «مهندسی سیستم» (System Engineering) منتقل میکند. با تبدیل LLM به یکی از اجزای یک حلقه بازخورد بزرگتر، توسعهدهندگان میتوانند غیرقابلپیشبینی بودن ذاتی هوش مصنوعی زاینده را مهار کنند. در حالی که این معماری بر دقت تمرکز دارد، بهینهسازی سرعت پاسخدهی نیز در لایههای زیرساختی حیاتی است؛ برای example، معماری ناهمگام Stormchaser توانسته است تأخیر عاملهای هوش مصنوعی را به ۲۰۰ میلیثانیه کاهش دهد تا تجربه کاربر در سیستمهای پیچیده بهبود یابد. این یک گام حیاتی برای پذیرش در سطح سازمانی است؛ جایی که نرخ موفقیت ۶۰٪ یک شکست مطلق تلقی میشود، اما نرخ ۹۹٪ (که از طریق خوداصلاحی به دست میآید) یک محصول تجاری viable و قابل عرضه است.
برای توسعهدهنده، این بدان معناست که چالش اصلی دیگر نوشتن یک پرامپت بینقص نیست، بلکه طراحی یک «منتقد» بینقص است. در این مدل، ارزش سیستم از «تولید محتوا» به «تأیید حقیقت» تغییر مکان داده است.
گام بعدی شما
توسعهدهندگان باید SDK مربوط به Semantic Kernel برای .NET 8 را برای پیادهسازی این لایههای انتزاعی بررسی کنند. گامهای عملیاتی پیشنهادی عبارتند از:
- طراحی یک «پرامپت منتقد» سختگیرانه برای سناریوهای حساس دادهای در کسبوکار خود.
- تست جایگزینی پاسخهای مستقیم مدل با چرخه
ExecuteWithHealingAsyncبرای کاهش نرخ خطای عملیاتی.
تکامل منطقی بعدی، ارکستراسیون چندعاملی (Multi-agent Orchestration) است که در آن عاملهای مجزا در یک حلقه مبتنی بر نظریه بازیهای رقابتی، نقش «خالق» و «حسابرس» را بهطور همزمان ایفا میکنند؛ تحولی که در گزارشهای آتی بررسی خواهیم کرد.
گفتگو