آیا همهٔ این کارها، تولید پاسخ می‌خواهند؟
مدیر منابع انسانی هنوز به فهرست قابلیت‌های پیشنهاد نگاه می‌کرد.
گفت: «اینجا برای دسته‌بندی درخواست‌ها هم نوشته از دستیار مولد استفاده می‌کنیم. ما می‌خوایم معلوم بشه درخواست مربوط به آموزش، مرخصی یا مزایاست. آخرش چه چیزی باید تولید کنه؟»
مدیر فناوری گفت: «خروجی اون قسمت می‌تونه فقط یک دسته و مقصد رسیدگی باشه.»
مدیر عملیات پرسید: «برای پیش‌بینی اینکه کدوم درخواست‌ها احتمالاً دیر رسیدگی می‌شن چی؟»
«اون هم یک کار جداست. باید سابقه و وضعیت رسیدگی رو بررسی کنیم.»
مدیر مالی یکی از نمونه‌های پاسخ را باز کرد. «ولی چیزی که به ما نشون دادن، این متن چندپاراگرافیه. خوب نوشته شده، اما از روی این نمی‌فهمیم دسته‌بندی یا پیش‌بینی هم درست کار می‌کنه.»
مدیرعامل فهرست را از اول خواند: پاسخ به پرسش، دسته‌بندی درخواست، پیش‌بینی تأخیر، تهیهٔ پیش‌نویس و پیشنهاد ارجاع.
گفت: «تا اینجا همه رو زیر اسم دستیار جمع کرده بودیم. برای هرکدوم بنویسیم چه خروجی‌ای می‌خوایم و از کجا می‌فهمیم درست انجام شده.»
در درس نهم دیدیم که انتخاب شیوهٔ ساخت و تأمین، بر کنترل دارایی‌ها، مسئولیت اجزا و امکان تغییر مسیر اثر دارد. برای مقایسهٔ پیشنهادها باید بدانیم چه چیزی تحویل می‌گیریم و چه مسئولیتی می‌پذیریم.
پرسش مدیر منابع انسانی، حالا فهرست قابلیت‌های همان پیشنهاد را باز کرده است. دسته‌بندی درخواست و پیش‌بینی تأخیر، خروجی و معیار موفقیت خود را می‌خواهند؛ متن چندپاراگرافیِ خوش‌خوان، موفقیت آن‌ها را اثبات نمی‌کند. باید کارهایی را که زیر نام «دستیار» جمع شده‌اند جدا کنیم و برای هرکدام قابلیت، داده، ارزیابی و مسئولیت متناسب بخواهیم.
این درس، اسلایدهای ۵۵ تا ۵۸ را به ترتیب دنبال می‌کند: دامنهٔ راهکارهای غیرمولد، مقایسه با هوش مصنوعی مولد، ریسک‌های تولید محتوا و سه الگوی پیشنهادی برای ادارهٔ دستیار سازمانی.
هوش مصنوعی، کارهای زیادی فراتر از تولید محتوا دارد
مدیر هنگام انتخاب راهکار با دامنه‌ای از قابلیت‌ها روبه‌روست: پیش‌بینی، پردازش زبان و گفتار، شناخت تصویر، سیستم‌های خبره، برنامه‌ریزی، بهینه‌سازی و رباتیک. هدف این است که هنگام تعریف راهکار، همهٔ نیازها را به گفت‌وگو و تولید متن تقلیل ندهیم.
ممکن است سازمان بخواهد تقاضای ماه آینده را برآورد کند، درخواست‌ها را دسته‌بندی کند، اطلاعات مشخصی را از اسناد بیرون بکشد یا یک وضعیت غیرعادی را تشخیص دهد. در هر مورد باید بدانیم چه نتیجه‌ای به کار سازمان می‌آید.
در پروندهٔ دستیار، دسته‌بندی درخواست باید به رسیدن آن به مرجع درست کمک کند. پیش‌بینی تأخیر باید امکان رسیدگی زودتر یا تخصیص منابع را فراهم کند. استخراج مبلغ و تاریخ از یک سند نیز باید اطلاعات درست و قابل بررسی در اختیار فرایند بگذارد.
هیچ‌کدام از این نتیجه‌ها با دیدن یک متن خوش‌خوان اثبات نمی‌شوند. برای هرکدام، نمونه‌های مرتبط و معیار پذیرش لازم است. حتی ممکن است بخشی از کار با قاعدهٔ روشن یا قابلیت موجود سازمان انجام شود؛ همان پرسشی که در درس‌های صورت‌بندی مسئله مطرح کردیم.
پس در مقایسهٔ پیشنهادها، از تأمین‌کننده می‌خواهیم کار مورد انتظار را توضیح دهد: کدام قابلیت چه خروجی‌ای می‌سازد، به کدام داده نیاز دارد و نتیجهٔ آن چگونه سنجیده می‌شود؟
مدیر عملیات گفت: «برای دسته‌بندی، نمونهٔ درخواست‌های قبلی رو داریم. می‌تونیم ببینیم به واحد درست می‌رسن یا نه.»
مدیر منابع انسانی گفت: «مواردی هم داریم که بین دو واحد مرزشون روشن نیست. اون‌ها رو هم باید ببینیم.»
مدیر فناوری گفت: «پس فقط چند مثال واضح برای نمایش انتخاب نکنیم.»
مدیرعامل کنار قابلیت دسته‌بندی نوشت: «مقصد درست؛ موارد مبهم؛ مسیر ارجاع.»
برای اولین بار، این قابلیت معیار خودش را پیدا کرده بود.
نوع خروجی، انتظار از ارزیابی را تغییر می‌دهد
پیش‌بینی تقاضا، قیمت‌گذاری و بهینه‌سازی، در کنار نوشتن و ویرایش، تهیهٔ پیش‌نویس، تولید طرح و گفت‌وگو، نیازهای متفاوتی را پوشش می‌دهند. بعضی کاربردها، مانند توصیه‌گری و تشخیص تقلب، می‌توانند از ترکیب روش‌های مولد و غیرمولد استفاده کنند.
در کاربرد مولد، تولید محتوا بخشی از کار است؛ برای نمونه، تهیهٔ پیش‌نویس نامه یا خلاصهٔ جلسه. در کارهای دیگری مانند پیش‌بینی یا دسته‌بندی، ممکن است خروجی مطلوب یک برآورد، یک دسته یا یک امتیاز باشد. انتخاب روش انجام کار باید با نیاز و شواهد ارزیابی آن تناسب داشته باشد.
برای پروندهٔ ما، می‌توان انتظارها را این‌گونه جدا کرد:
| کار مورد انتظار | خروجی مورد نیاز | چه چیزی باید بررسی شود؟ |
|---|---|---|
| دسته‌بندی درخواست | دسته و مقصد رسیدگی | آیا درخواست به مرجع درست می‌رسد و موارد مبهم چگونه رسیدگی می‌شوند؟ |
| پیش‌بینی تأخیر | برآورد احتمال یا زمان تأخیر | آیا برآورد در عمل به شناسایی و رسیدگی به موارد مهم کمک می‌کند؟ |
| تهیهٔ پیش‌نویس پاسخ | متن پیشنهادی | آیا متن درست، مرتبط، متناسب با مخاطب و قابل تأیید است؟ |
| پیشنهاد ارجاع | پیشنهاد همراه با مبنا | آیا دلیل پیشنهاد معتبر است و مسئول تأیید مشخص است؟ |
همین پرسش‌ها در پیش‌بینی خرابی چه شکلی دارند؟
برای مقایسه، یک پروندهٔ فرضی دیگر را در نظر بگیریم: سامانه‌ای از دادهٔ حسگرها و سابقهٔ تعمیر، احتمال خرابی تجهیزات را برآورد می‌کند. خروجی، متن پاسخ‌گو نیست؛ هشدار یا امتیازی است که در برنامهٔ تعمیر اثر می‌گذارد.
| موضوع | دستیار اسنادی | پیش‌بینی خرابی تجهیزات |
|---|---|---|
| دادهٔ مهم | سند معتبر، نسخه و مجوز استفاده | دادهٔ حسگر، وضعیت تجهیز و سابقهٔ معتبر خرابی و تعمیر |
| خطای مهم | پاسخ نامعتبر، افشای اطلاعات یا ارجاع نامناسب | خرابیِ کشف‌نشده یا هشدار بی‌مورد |
| ارزیابی | صحت و اعتبار پاسخ، ارجاع و رعایت دسترسی | کشف خرابی با فرصت اقدام، هشدار کاذب و بار رسیدگی |
| حد اختیار | توضیح، پیشنهاد یا اقدام در دامنهٔ مصوب | هشدار به مسئول تعمیر یا توقف تجهیز، فقط در صورت تصویب جداگانه |
| تغییر مهم | تغییر سند، مدل یا دامنهٔ استفاده | تغییر حسگر، نوع تجهیز، الگوی کار یا سیاست تعمیر |
در پروندهٔ تجهیزات، واکنش به هشدار می‌تواند جلوی خرابی را بگیرد. بنابراین نبود خرابی پس از مداخله، به‌تنهایی ثابت نمی‌کند هشدار غلط بوده است. ثبت اقدام تعمیر و بررسی مستقل موارد، بخشی از شناخت نتیجه است. تغییر سیاست تعمیر نیز می‌تواند داده‌های بعدی را تغییر دهد.
اصول حق تصمیم، مسئولیت، شواهد و بازبینی میان دو پرونده مشترک‌اند؛ اما پیکرهٔ آزمون، معیارها، منشأ خطا و کنترل عملیاتی آن‌ها یکسان نیست. چک‌لیست دستیار اسنادی را نباید بدون تغییر به این کاربرد منتقل کرد.
این جدول، نوع خروجی را روشن می‌کند؛ تصمیم دربارهٔ روش انجام هر کار، به بررسی جداگانه نیاز دارد. ممکن است یک راهکار، دسته‌بندی، جست‌وجو و تولید متن را کنار هم داشته باشد.
این تفکیک در انتخاب اندازهٔ مدل هم اثر دارد. در برای هر کاربرد واقعاً چه اندازه مدلی لازم داریم؟ دسته‌بندی، استخراج اطلاعات، پاسخ مستند و تحلیل پیچیده را با نیازهای متفاوتشان مقایسه کرده‌ام.
غیرمولدبودن یک قابلیت، آن را از حکمرانی بی‌نیاز نمی‌کند. اگر دسته‌بندی، دسترسی فرد به رسیدگی را تغییر دهد یا یک امتیاز مبنای تصمیم حساس شود، همان پرسش‌های اثر، اختیار و امکان اعتراض مطرح‌اند.
مدیر مالی گفت: «پس در پایلوت، برای هر ردیف نتیجهٔ خودش رو می‌خوایم. کیفیت پیش‌نویس رو به حساب درست‌بودن پیش‌بینی نذاریم.»
مدیر فناوری گفت: «و اگر یک قابلیت رو برای شروع لازم نداریم، می‌تونیم از دامنهٔ این مرحله خارجش کنیم.»
مدیرعامل پرسید: «کدوم قسمت الان بیشترین کمک رو به مسئلهٔ منتخب می‌کنه؟»
این بار، گفت‌وگو به‌جای بلندترکردن فهرست قابلیت‌ها، دربارهٔ اولویت آن‌ها بود.
تولید محتوای روان، به کنترل‌های مشخص نیاز دارد
تولید محتوا با ریسک‌هایی همراه است که شدت آن‌ها را باید در همان کاربرد مشخص سنجید؛ با توجه به مخاطب، داده، حدود استفاده و پیامد اتکا به خروجی.
برای پروندهٔ دستیار، هر موضوع ریسک به پرسشی مدیریتی دربارهٔ پذیرش و ادارهٔ خدمت تبدیل می‌شود:
| موضوع ریسک | پرسشی برای پذیرش و ادارهٔ دستیار |
|---|---|
| اطلاعات نادرست | درستی اطلاعات پاسخ چگونه بررسی می‌شود و اصلاح آن به چه کسی می‌رسد؟ |
| پاسخ ساختگی | اگر سامانه عدد، بند یا مرجعی بدون پشتوانه بسازد، چگونه آشکار و رسیدگی می‌شود؟ |
| محتوای نامناسب | چه محتوایی برای محیط و مخاطب سازمان قابل قبول است و موارد نامناسب چگونه پیگیری می‌شوند؟ |
| سوگیری | آیا کیفیت یا نحوهٔ پاسخ‌گویی برای گروه‌ها و شرایط مختلف بررسی شده است؟ |
| مالکیت فکری | استفاده و انتشار محتوای ورودی و خروجی، چه بررسی و تأییدی می‌خواهد؟ |
| حریم خصوصی | چه اطلاعاتی مجاز است وارد سامانه شود و چه کسی مجاز است آن را در خروجی ببیند؟ |
| دستکاری و جعل هویت | چگونه روشن می‌ماند متن را چه کسی تولید و چه مرجعی تأیید کرده است؟ |
| پیامد ناخواسته | کاربر ممکن است از خروجی چه برداشتی کند و بر اساس آن چه اقدامی انجام دهد؟ |
یکی از مسائل مهم، پاسخی است که نادرست است اما با اطمینان و ظاهری موجه ارائه می‌شود. وجود توضیح یا ارجاع در متن نیز به‌تنهایی پشتوانهٔ آن را ثابت نمی‌کند. نمایهٔ ریسک هوش مصنوعی مولد NIST نیز به تولید محتوای نادرست و حتی استدلال یا ارجاع ساختگی توجه می‌دهد.
برای دستیار خرید، باید بتوانیم بررسی کنیم عدد اعلام‌شده از کدام منبع معتبر آمده و آیا توضیح پاسخ واقعاً با آن منبع سازگار است. در پیش‌نویس نامه نیز لازم است وضعیت «پیشنهاد برای بررسی» با «متن تأییدشدهٔ سازمان» روشن بماند.
این پرسش‌ها باید در معیار پذیرش و مسئولیت ادارهٔ خدمت وارد شوند. عبارت کلی «کاربر خروجی را بررسی کند» کافی نیست، مگر آنکه معلوم باشد چه کسی، چه چیزی را، با چه اطلاعات و اختیاری بررسی می‌کند.
مدیر مالی یکی از پاسخ‌های نمونه را خواند: «اینجا به یک بند مقررات اشاره کرده. خود بند رو هم داریم؟»
مدیر فناوری سند را باز کرد. «باید متن پاسخ رو با همین منبع تطبیق بدیم.»
مدیر منابع انسانی گفت: «در پیش‌نویس‌ها هم ممکنه متن، رسمی و قطعی به نظر بیاد. باید معلوم باشه هنوز تأیید نشده.»
مدیرعامل گفت: «این رو جزو معیار تحویل بیاریم: منبع قابل بررسی، وضعیت تأیید روشن و مسئول رسیدگی به خطا.»
سه الگوی ادارهٔ دستیار را چگونه مقایسه کنیم؟
پس از انتخاب قابلیت‌ها، باید دربارهٔ شیوهٔ هماهنگی منابع و ادارهٔ خدمت تصمیم بگیریم. سه الگو را برای دستیار سازمانی مقایسه می‌کنیم. برای مدیر، تفاوت اصلی در محل کنترل، مسئولیت مشترک و نیاز به هماهنگی است.
| الگو | منطق استفاده | نیاز مدیریتی و محدودیت |
|---|---|---|
| لایه‌ای | شروع با یک دستیار و دسترسی به منابع اطلاعاتی، با دامنهٔ محدود | شروع سریع‌تر و ساده‌تر؛ نیازمند روشن‌کردن اعتبار منابع، دسترسی و محدودیت کنترل جریان اطلاعات |
| متمرکز | هماهنگی منابع و خدمت‌ها از طریق یک درگاه مشترک سازمانی | کنترل هماهنگ‌تر و ارتباط با سامانه‌های سازمان؛ نیازمند تیم و مسئولیت روشن برای ادارهٔ خدمت مشترک |
| فدراتیو | هماهنگی دستیارها و منابع واحدهای تخصصی در چارچوب سیاست‌های مشترک | حفظ مسئولیت و کنترل محلی همراه با هماهنگی سازمانی؛ نیازمند بلوغ، همکاری و هزینهٔ ادارهٔ بیشتر |
در الگوی لایه‌ای، تأکید بر شروع سریع و کاربردهای عمومی‌تر است. اگر سازمان بخواهد از آن در موضوع حساس یا برای اقدام استفاده کند، باید دوباره بسنجد آیا کنترل‌های موجود پاسخ‌گوی نیاز تازه هستند.
در الگوی متمرکز، سازمان یک نقطهٔ مشترک برای هماهنگی استفاده، منابع و خدمت‌ها دارد. باید مشخص باشد چه کسی آن را اداره می‌کند، تغییرات واحدها چگونه پذیرفته می‌شود و دسترسی و سوابق کاربران چگونه مدیریت می‌شوند.
در سطح اجزای فنیِ دستیار اسناد نیز همین تقسیم کار ادامه دارد. انتخاب مدل زبانی، embedding و reranker برای دستیار سازمانی توضیح می‌دهد چرا یافتن سند، مرتب‌کردن نتایج و نوشتن پاسخ، ارزیابی‌های جداگانه می‌خواهند.
در الگوی فدراتیو، واحدهای تخصصی منابع و دستیارهای خود را دارند و در چارچوب مشترکی هماهنگ می‌شوند. این استقلال به توافق دربارهٔ مسئولیت محتوا، قواعد دسترسی، رسیدگی به تعارض و ارجاع میان واحدها نیاز دارد.
سطح کنترل هر الگو، به امکانات و مسئولیت‌های آن وابسته است. در انتخاب واقعی باید ببینیم آن‌ها چگونه اجرا می‌شوند. نام یک الگو، به‌تنهایی شاهد رعایت سیاست‌ها یا حفظ محرمانگی نیست.
برای پروندهٔ ما، مقایسه باید از نیازهای ثبت‌شده شروع شود: چه کسی منبع معتبر را تعیین می‌کند، دسترسی را چه کسی کنترل می‌کند، پاسخ متعارض کجا ارجاع می‌شود و حدود اختیار چگونه اجرا می‌شوند؟ از هر گزینه، شواهد و توضیح متناسب با همین پرسش‌ها می‌خواهیم.
یک درگاه، با مسئولیت‌های روشن
مدیر منابع انسانی گفت: «ممکنه کاربر یک دستیار ببینه، ولی اعتبار محتوای منابع انسانی همچنان با ما باشه.»
مدیر مالی گفت: «برای مقررات خرید هم همین‌طور. باید معلوم باشه چه چیزی رو تأیید کردیم.»
مدیر فناوری گفت: «پس در مقایسهٔ گزینه‌ها، ادارهٔ منابع هر حوزه و هماهنگی بین اون‌ها رو جدا بررسی می‌کنیم.»
مدیر عملیات پرسید: «اگر یک سؤال به دو واحد مربوط باشه چی؟»
مدیرعامل گفت: «باید مسیر رسیدگی مشترک داشته باشیم. نباید دستیار خودش اختلاف دو واحد رو تعیین تکلیف کنه.»
مسئول ریسک و انطباق به فهرست منابع نگاه کرد: «یک پرسش دیگه هم داریم. اگر منابع واحدها در دسترس دستیار باشن، از کجا مطمئن می‌شیم هر کاربر فقط اطلاعاتی رو می‌بینه که مجازه؟»
مدیرعامل گفت: «این رو قبل از گسترش استفاده روشن کنیم. هماهنگ‌شدن منابع، قرار نیست مرز دسترسی افراد رو برداره.»
با این درس، بحث مدیریتی بخش چهارم به انتخاب قابلیت، ریسک و شیوهٔ ادارهٔ دستیار رسید. در درس یازدهم، از اسلاید ۸۵ وارد بخش پنجم، «امنیت، مسئولیت و نظارت انسانی»، می‌شویم: چگونه حدودی که تصویب کرده‌ایم، در استفادهٔ واقعی حفظ و قابل بررسی شوند؟
این درس، دهمین درس مجموعهٔ «حکمرانی هوش مصنوعی در سازمان» و تشریح اسلایدهای ۵۵ تا ۵۸ دوره است. درس قبل: ساخت یا خرید هوش مصنوعی؛ کنترل چه چیزی باید دست سازمان بماند؟؛ اسلایدهای کامل دوره
در مسیر این مجموعه، اسلایدهای ۵۹ تا ۸۴، مربوط به «پرانتز فنی» ارائه، پوشش داده نمی‌شوند و ادامه از بخش پنجم است.
منبع تکمیلی بحث ریسک تولید محتوا: نمایهٔ هوش مصنوعی مولد NIST، سند AI 600-1.