مایکروسافت چطور ایجنتها رو تو مقیاس سازمانی به پروداکشن میرسونه
هوش مصنوعیخلاصهٔ کاملتر
تو این گفتوگوی ByteByteGo با مارکو کازالاینا، معاون محصول Core AI مایکروسافت، تصویری از اجرای ایجنتها تو مقیاس واقعی ارائه میشه. الان بیش از ۸۰ هزار سازمان روی Microsoft Foundry ایجنت و اپلیکیشن میسازن و کوپایلتهای خود مایکروسافت هم روی همین پلتفرم اجرا میشن؛ فقط Microsoft 365 Copilot بیشتر از ۲۰ میلیون کاربر داره.
به گفتهٔ کازالاینا، صنعت داره از فاز پرسشوپاسخ و دوران چتبات عبور میکنه و تو ۲۰۲۶ خیلی از مشتریها صدا رو بهعنوان فرانتاند به کار میگیرن. شکل جدید کار، ایجنتیه که جلسه رزرو میکنه، تحلیل اجرا میکنه و تیکت ثبت میکنه. همین تفاوت، مهندسی مسئله رو عوض میکنه: جواب غلط یه چتبات فقط تجربهٔ بدیه، ولی اقدام غلط یه ایجنت یه حادثهٔ کسبوکاریه.
نویسنده میگه فاصلهٔ پروتوتایپ تا پروداکشن دقیقاً همینجا باز میشه. اولین نسخه رو میشه یه بعدازظهره ساخت، ولی تو پروداکشن کاربرها چیزهای پیشبینینشده میپرسن، سندها بیات میشن، آپدیت مدل رفتار ایجنت رو نامحسوس عوض میکنه و بدون هویت و رصد، هیچکس نمیفهمه کیفیت داره افت میکنه. مهمترین درس تیم Foundry هم همینه: هارنس بهاندازهٔ مدل اهمیت داره.
هارنس یعنی هر چیزی که دور مدله: رانتایم، ابزارها، بازیابی کانتکست، لایهٔ هویت، گاردریلها، ارزیابها و پایپلاین دیپلوی. مدلها رو نمیشه مثل نسخههای دیتابیس عوض کرد؛ نمونهش اینکه وقتی Claude Opus 4.8 منتشر شد، تیم GitHub Copilot CLI مجبور شد هارنسش رو دوباره تنظیم و ارزیابیها رو از نو اجرا کنه. لایههای این هارنس از پایین به بالا اینان: اینفرنس (بیش از ۱۱ هزار مدل)، رانتایم ایجنت با بیطرفی نسبت به فریمورک، رصد و حاکمیت، هویت و در نهایت کانتکست.
سختترین بخش، کانتکسته. مشکل نبودِ داده نیست، پخشبودنشه: سندهای بدون ساختار تو شیرپوینت و ویکی، جدولهای ساختیافته تو OneLake و انبار داده، و اپهای بهرهوری مثل اوتلوک و تیمز. تو مقاله اومده که RAG کلاسیک یه الگوی تکشاته و بهمحض اینکه سؤال مبهم باشه یا جواب نیاز به ترکیب چند منبع داشته باشه میشکنه، چون ایجنت هیچ راهی برای جبران یه بازیابی بد نداره.
جواب مایکروسافت، بازیابی بهعنوان سابایجنته: بهجای یه فراخوانی ساده که یه کوئری رو روی یه ایندکس میزنه، بازیابی خودش یه ایجنت کوچیک میشه که منبعها رو پلن میکنه، نتیجه رو با سؤال اصلی میسنجه و اگه لازم شد سراغ منبع دیگه میره. Foundry IQ وقتی به بنبست بخوره، بهجای جواب سرهمبندیشده یه «نمیدونم» ساختیافته برمیگردونه. همین حلقه برای ابزارها هم هست: ایجنت بهجای حمل لیست همهٔ ابزارها، موقع نیاز دنبال ابزار درست میگرده.
برای اقدامکردن هم دو چیز لازمه: هویت و سطح عمل. ایجنت باید مثل کارمند، تو همون دایرکتوری سازمان رول و ردّ ممیزی داشته باشه — تو مایکروسافت این کار با Entra انجام میشه و سطح عمل هم Work IQ ـه. نکتهٔ امنیتی مهم اینکه گاردریلها باید به مرز ابزار منتقل شن، چون ایجنت خروجی ابزارها و سندهای بازیابیشده رو هم میخونه و یه دستور پنهان داخل یه سند میتونه به تزریق غیرمستقیم پرامپت منجر شه.
نیمهٔ دوم ماجرا ارزیابیه. مقاله میگه تست پیش از انتشار برای نرمافزار قطعی جواب میده ولی برای ایجنت نه، چون خروجی غیرقطعیه و داده هر روز عوض میشه. راهحل، ارزیابی مداوم روی ترافیک واقعی بهعلاوهٔ روبریکه: چکهای بله/خیرِ گرهخورده به همون کاربرد خاص — مثلاً برای ایجنت رزرو رستوران، اینکه قبل از اعلام یه ساعت خالی واقعاً موجودی رو چک کرده یا نه. ابزار Agent Optimizer وقتی روبریکی رد شه، خودش چند نسخهٔ اصلاحی موازی میسازه، امتیازشون میده و بهترین رو جایگزین میکنه.
نکات کلیدی:
- مدل بهتنهایی تعیینکننده نیست؛ لایههای دور مدل کیفیت پروداکشن رو میسازن
- بازیابی باید حلقهای و چندمنبعی باشه، نه یه کوئری تکشات روی یه ایندکس
- ایجنتی که اقدام میکنه باید هویت مستقل و ردّ ممیزی داشته باشه
- گاردریل رو باید سر مرز ابزار گذاشت تا جلوی تزریق غیرمستقیم پرامپت گرفته شه
- ارزیابی یه مرحلهٔ قبل از انتشار نیست، یه لایهٔ همیشهدرحالاجراست
