ServiceNow روش AutoSynthData را برای ساخت داده آموزشی عامل‌های سازمانی معرفی کرد

داده مصنوعی عامل‌های سازمانی موضوع روش تازه‌ای است که ServiceNow CoreAI در AutoSynthData شرح داده است؛ سامانه‌ای که از خطاهای یک مدل در محیط سازمانی برای ساخت وظایف آموزشی تازه استفاده می‌کند. به گفته این تیم، یک مدل ممکن است توانایی عمومی بالایی داشته باشد، اما در کار با ابزارها، رعایت محدودیت‌ها یا اجرای جریان کاری مشخص یک سازمان ناکام بماند. AutoSynthData می‌کوشد این ضعف‌ها را به نمونه‌هایی قابل اجرا و قابل ارزیابی برای آموزش تبدیل کند. شرح این روش در وبلاگ Hugging Face در ۲ اکتبر ۲۰۲۶ منتشر شده است.

چرا عامل‌های سازمانی به داده‌های اختصاصی نیاز دارند؟

عامل هوش مصنوعی سامانه‌ای است که برای انجام کار، وضعیت یک محیط را مشاهده می‌کند و با ابزارها یا رابط‌های برنامه‌نویسی آن تعامل دارد. در محیط سازمانی، موفقیت چنین عاملی فقط به دانش عمومی مدل وابسته نیست؛ ابزارهای در دسترس، قواعد داخلی، اطلاعات موجود و وضعیت جاری سامانه نیز در نتیجه اثر می‌گذارند.

یک مدل ممکن است در یک کار مشخص از ابزار نادرستی استفاده کند، بخشی از یک فرایند را اشتباه پیش ببرد یا محدودیتی را نادیده بگیرد. این ناکامی‌ها به‌تنهایی نشان می‌دهند چه چیزی درست پیش نرفته، اما برای آموزش کافی نیستند. مدل به مجموعه‌ای از وظایف تازه نیاز دارد که همان توانایی را در وضعیت‌ها و صورت‌بندی‌های متفاوت تمرین دهد.

به روایت ServiceNow CoreAI، این وظایف باید هم در محیط قابل انجام باشند، هم شبیه درخواست‌هایی باشند که کاربران واقعاً مطرح می‌کنند و هم راهی مطمئن برای تشخیص موفقیت داشته باشند. وظیفه‌ای که به ابزار ناموجود وابسته باشد یا معیار موفقیت نادرستی داشته باشد، داده آموزشی قابل اتکایی تولید نمی‌کند.

داده مصنوعی عامل‌های سازمانی چگونه ساخته می‌شود؟

AutoSynthData ابتدا مدل هدف را با وظایف تشخیصی در محیط موردنظر ارزیابی می‌کند تا الگوهای شکست آن مشخص شود. سپس عملکرد مدل با عملکرد یک «معلم» قوی‌تر مقایسه می‌شود. معلم در این فرایند نشان می‌دهد کدام وظایف شدنی‌اند و رفتار موفق چه شکلی دارد. سامانه از این اطلاعات برای مشخص‌کردن توانایی‌هایی استفاده می‌کند که مدل هدف باید بیاموزد.

در آزمایش شرح‌داده‌شده، این فرایند با EnterpriseOps Gym انجام شده است؛ محیطی که مقاله به آن استناد می‌کند. پژوهشگران بررسی می‌کنند وظیفه چه قابلیتی را می‌سنجد، چه ابزارها و چه ترتیبی از کارها در آن دخیل‌اند، مدل هدف کجا شکست می‌خورد و معلم چگونه موفق می‌شود. همچنین ویژگی‌هایی را مشخص می‌کنند که باید در وضعیت نهایی درست باشند و بخش‌هایی را که می‌توان تغییر داد، بی‌آن‌که توانایی مورد سنجش عوض شود.

این یافته‌ها در کارت‌های مشخصات توانایی خلاصه می‌شوند. طبق توضیح تیم، مولد وظایف به کارت‌ها دسترسی دارد، نه به متن اصلی درخواست‌های ارزیابی، موجودیت‌ها، مسیرهای اجرا یا جزئیات ارزیاب آن‌ها. به این ترتیب، نمونه‌های آموزشی جدید با درخواست‌ها، وضعیت‌های اولیه و مسیرهای حل متفاوت ساخته می‌شوند، اما همچنان همان قابلیت هدف را می‌سنجند.

برای هر وظیفه، سه جزء تعریف می‌شود: مشخصات سامانه، درخواست کاربر و ارزیاب. مشخصات سامانه قواعد و محدودیت‌هایی را تعیین می‌کند که عامل باید رعایت کند. درخواست کاربر کار موردنظر و محدودیت‌های آن را بیان می‌کند. ارزیاب نیز بررسی می‌کند که آیا مسیر اجرا واقعاً به نتیجه مطلوب رسیده است یا نه.

اعتبارسنجی وظیفه؛ از راه‌حل تا ارزیاب

به گفته نویسندگان، وظیفه مناسب باید شدنی، واقع‌گرایانه و دشوار باشد. شدنی‌بودن یعنی دست‌کم یک مسیر در محیط وجود داشته باشد که بدون نقض قواعد به خواسته کاربر برسد. واقع‌گرایانه‌بودن یعنی درخواست، کاری را توصیف کند که در آن محیط به‌طور معقول ممکن است مطرح شود. دشواربودن هم به این معناست که مدل هدف هنوز آن را با اطمینان حل نمی‌کند؛ وظیفه‌ای که مدل از قبل به‌طور پایدار انجام می‌دهد، ارزش آموزشی کمتری دارد.

ارزیاب نیز باید با درخواست کاربر، قواعد سامانه و وضعیت اولیه سازگار باشد. این سازوکار باید پاسخ‌های نادرست را رد کند، اما راه‌حل‌های معتبر را صرفاً به این دلیل که با یک مسیر مرجع خاص تفاوت دارند، مردود نکند. ارزیاب بیش از حد سهل‌گیر ممکن است رفتار غلط را موفق اعلام کند و ارزیاب بیش از حد سخت‌گیر ممکن است راه‌حل درست را نپذیرد.

هر نمونه پیش از ورود به مجموعه آموزشی از چند بررسی می‌گذرد. سامانه مسیر مرجع را در محیط اجرا می‌کند و نتیجه را با معیار موفقیت می‌سنجد. در کنار این آزمون مثبت، بررسی منفی هم انجام می‌شود: بخش‌هایی از نتیجه مورد انتظار تغییر می‌کنند تا معلوم شود وضعیت‌های نادرست دیگر از فیلتر ارزیاب عبور نمی‌کنند.

آزمایش دشواری نیز بخشی از این فرایند است. در پیکربندی گزارش‌شده، وظایفی ترجیح داده می‌شوند که مدل هدف حداکثر در یکی از سه تلاش موفق به حل آن‌ها شود، درحالی‌که حل‌گر قوی‌تر دست‌کم در دو تلاش از سه تلاش به پاسخ برسد. نمونه‌ای که در بررسی‌ها شکست بخورد، به منتقد سپرده می‌شود تا مشکلاتی مانند ناسازگاری وضعیت، مسیر ناممکن، پاسخ مرجع نادرست یا معیار موفقیت ضعیف را شناسایی کند. پس از اصلاح، نمونه باید دوباره بررسی شود و تعداد تلاش‌های اصلاح محدود است.

گسترش مجموعه و حرکت به‌سوی ضعف‌های باقی‌مانده

AutoSynthData داده‌ها را در دو مرحله می‌سازد. در مرحله نخست، نمونه‌های اصلی بر پایه کارت‌های مشخصات تولید و اعتبارسنجی می‌شوند. کارگران تولید به‌صورت موازی وظایف مستقل می‌سازند و هر نمونه پس از ارزیابی، اجرا و در صورت لزوم اصلاح، می‌تواند پذیرفته شود. در مرحله دوم، نمونه‌های پذیرفته‌شده با تغییر درخواست کاربر، وضعیت محیط، موجودیت‌ها، ترکیب جریان کاری، ابزارها و سطح دشواری به گونه‌های تازه گسترش می‌یابند.

هر گونه تازه مسیر مرجع و ارزیاب خود را دارد و باید همان آزمون‌های اعتبارسنجی را بگذراند. طبق طراحی گزارش‌شده، یک نمونه تکثیرشده مبنای ساخت نمونه تکثیرشده دیگری نمی‌شود؛ گسترش مجموعه از نمونه‌های اصلی تأییدشده آغاز می‌شود تا فاصله گرفتن تدریجی از داده معتبر محدود بماند.

بررسی کیفیت تنها به تک‌نمونه‌ها محدود نیست. بازبینی دسته‌ای می‌سنجد آیا بعضی خانواده‌های وظایف بیش از حد تکرار شده‌اند، قابلیتی از قلم افتاده یا الگوی خاصی پی‌درپی در تولید شکست می‌خورد. سامانه بر اساس این بازبینی می‌تواند تولید را از بخش‌های پرتکرار به‌سوی شکاف‌های پوشش‌داده‌نشده هدایت کند و دستورالعمل‌های دور بعد را تغییر دهد.

پس از آموزش نظارت‌شده، مدل به‌روزشده دوباره در همان محیط ارزیابی می‌شود. وظایفی که اکنون به‌طور قابل اعتماد حل می‌شوند، برای دور بعد ارزش کمتری دارند؛ شکست‌های باقی‌مانده می‌توانند نشان دهند چه قابلیت‌هایی هنوز نیازمند تمرین‌اند. مقاله آزمایش‌ها را بر آموزش نظارت‌شده متمرکز می‌داند و می‌گوید سازوکار مشابه می‌تواند برای یادگیری تقویتی نیز به کار رود؛ روشی که در آن مدل از بازخورد درباره عملکرد خود یاد می‌گیرد.

این خبر برای چه کسانی اهمیت دارد

روش AutoSynthData بیش از همه برای تیم‌هایی اهمیت دارد که عامل‌های هوش مصنوعی را در فرایندهای اختصاصی سازمان‌ها به کار می‌گیرند یا آموزش می‌دهند. برای آن‌ها، مسئله فقط تولید تعداد زیادی درخواست مصنوعی نیست؛ هر نمونه باید با ابزارها و قواعد محیط سازگار باشد و معیار سنجش آن نیز رفتار درست را تشخیص دهد.

این چارچوب همچنین برای پژوهشگران داده مصنوعی و ارزیابی عامل‌ها قابل توجه است، چون توجه را از تولید متن‌های ظاهراً معقول به تولید وظایف اجرایی و آزمون‌پذیر می‌برد. بااین‌حال، شرح منتشرشده بر طراحی خط لوله و کنترل کیفیت تمرکز دارد و نتیجه کمی درباره میزان بهبود مدل‌ها ارائه نمی‌کند. بنابراین، ارزش اصلی گزارش در توضیح روشی برای پیوند دادن خطاهای مدل به چرخه‌ای از تولید، اعتبارسنجی و آموزش دوباره است.