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

این موضوع پرسش حرفه‌ای را از «آیا این پاسخ درست است؟» به «این سیستم پیش از آنکه مجبور شود از من سؤال کند، اجازه دارد چه کارهایی انجام دهد؟» تغییر می‌دهد.

Zapier، ChatGPT Work را حالتی عامل‌محور توصیف می‌کند که می‌تواند برای دوره‌های زمانی طولانی با فایل‌ها و برنامه‌های متصل کار کند، در حالی که حالت Plan آن پیش از اجرا، راهبردی را برای تأیید پیشنهاد می‌دهد. Microsoft نیز Copilot، دانش سازمانی و حکمرانی را به‌عنوان بخش‌های مکمل یک پشته عملیاتی هوش مصنوعی مطرح می‌کند. این نمونه‌ها به یک تمایز عملی اشاره دارند: هوش مصنوعی از یک شریک گفت‌وگو به یک مجریِ واگذارشده تبدیل می‌شود.

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

به‌جای درخواست‌ها، به اقدامات فکر کنید

نخستین گام مفید، فهرست‌کردن اقداماتی است که یک سیستم هوش مصنوعی می‌تواند در یک گردش‌کار انجام دهد. «رسیدگی به ورود مشتری» برای حکمرانی بیش از حد کلی است. فهرست مفیدتر ممکن است شامل این موارد باشد:

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

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

یک دسته‌بندی ساده، از وعده مبهمِ نظارت یک انسان بر همه‌چیز، عملی‌تر است:

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

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

در جاهایی که پیامدها تغییر می‌کنند، دروازه‌های تأیید قرار دهید

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

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

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

درخواست تأیید باید اقدام پیشنهادی، هدف دقیق، ورودی‌های مهم و پیامد احتمالی را نشان دهد. «ادامه؟» کنترل ضعیفی است. «این پیام را با استفاده از فهرست پیوست‌شده، برای 2,400 مشتری ارسال کن؛ هزینه تخمینی کارزار $X است» چیزی معنادار برای بررسی در اختیار فرد می‌گذارد.

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

دامنه عملیاتی عامل را تعریف کنید

متخصصان برای تعیین مرزهای مفید لازم نیست همه جزئیات مدل را درک کنند. اما باید دامنه عملیاتی سیستم را مشخص کنند:

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

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

مرز را با زبان عملیاتی بنویسید. «از قضاوت خود استفاده کن» یک کنترل نیست. «بدون تأیید، ایمیل خارجی ارسال نکن؛ پایگاه داده مشتریان را تغییر نده؛ فقط از جدول قیمت‌گذاری تأییدشده با تاریخ [date] استفاده کن؛ اگر دو منبع با هم تعارض داشتند، متوقف شو» قابل آزمون است.

برنامه‌ها را پیش از اجرا قابل بازرسی کنید

برنامه‌ریزی یکی از قابلیت‌های مفید هوش مصنوعی واگذارشده است، اما برنامه، دلیل درستی آن نیست. آن را به‌عنوان توالی پیشنهادی اقدامات بررسی کنید.

چهار پرسش بپرسید:

  1. سیستم در پی دستیابی به چه نتیجه‌ای است؟
  2. چه فرض‌هایی را در نظر گرفته است؟
  3. چه ابزارهایی را فراخوانی خواهد کرد و با چه مجوزهایی؟
  4. در کدام مرحله ممکن است یک اشتباه پرهزینه یا بازگرداندنش دشوار شود؟

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

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

فرض کنید زمینه ممکن است از بین برود

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

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

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

برای توقف و بازیابی طراحی کنید

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

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

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

نردبان عملی واگذاری

می‌توانید یک عامل را مرحله‌به‌مرحله وارد کنید:

  1. مشاهده: سامانه اطلاعات تأییدشده را می‌خواند و توضیح می‌دهد که چه کاری انجام خواهد داد.
  2. پیش‌نویس: خروجی‌ها را آماده می‌کند، اما یک فرد هر اقدام بیرونی را اجرا می‌کند.
  3. اقدام در محیط آزمایشی: در یک فضای کاری ایزوله، رکوردها، شاخه‌ها یا فایل‌های آزمایشی ایجاد می‌کند.
  4. اقدام با مجوزهای محدود: اقدامات برگشت‌پذیر و کم‌خطر را با محدودیت‌های حجمی و زمانی انجام می‌دهد.
  5. اقدام بر اساس سیاست: دسته‌ای از کارهای به‌خوبی آزموده‌شده را انجام می‌دهد و در درگاه‌های تأیید مشخص متوقف می‌شود.

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

این موضوع برای مسیر شغلی شما چه معنایی دارد

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

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

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

مایا چن ویراستار انسانی پاسخ‌گوی AI Career Brief است و مهارت‌ها، نقش‌ها و حرکت‌های هوشمندانه برای کار کردن در عصر هوش مصنوعی را پوشش می‌دهد.