بیشتر برنامه‌های حاکمیت در یک نقطه مشترک شکست می‌خورند.
سیاست نوشته می‌شود. تأیید می‌شود. منتشر می‌شود. بعد زمان اجرا تصمیمی می‌گیرد که هیچ‌وقت آن سیاست را ارزیابی نکرده است.
این همان حلقه مفقوده‌ای است که حاکمیت هرگز آن را به اجرا وصل نمی‌کند.
یک سیاست می‌تواند دقیق نوشته شده، از نظر حقوقی بازبینی شده و از نظر فنی منطقی باشد؛ اما اگر مسیر اجرا نتواند پیش از اقدام ایجنت آن را ارزیابی کند، در عمل بر هیچ چیز حاکم نیست.
این مقاله بخش چهارم از مجموعه ده‌قسمتی حاکمیت هوش مصنوعی در یک شرکت نرم‌افزاری مبتنی بر هوش مصنوعی است. بخش سوم، چرا بیشتر تیم‌ها در کنترل‌های اقدام متوقف می‌شوند، دانش، اجرا و ارزیابی را به‌عنوان زیرساخت لایه‌های عمیق‌تر معرفی کرد. این بخش سراغ مرز بعدی می‌رود: تبدیل سیاست به رفتار زمان اجرا.
اگر سیاست در مستندات متوقف شود، حاکمیت هوش مصنوعی ندارید. فقط قالب‌بندی دارید.
شکاف اجرای دستی
بیشتر سازمان‌ها سیاست دارند.
قواعد استفاده مجاز، الزامات کار با داده، ماتریس‌های تأیید، کنترل دسترسی به محیط عملیاتی، استانداردهای امنیتی و رویه‌های ارجاع وجود دارند. مشکل، نبود نیت و سیاست نیست.
مشکل، تبدیل این سیاست‌ها به تصمیم اجرایی است.
انسان می‌تواند قاعده‌ای مانند «تغییرات محیط عملیاتی که بر داده مشتری اثر می‌گذارند باید به تأیید مالک سرویس برسند» را با توجه به زمینه تفسیر کند. نمی‌توان با اطمینان از ایجنت انتظار داشت در هر اقدام همان برداشت را از متن آزاد بازسازی کند.
اجرای همان قاعده ممکن است به واقعیت‌های جاری گوناگونی وابسته باشد:
- کدام ایجنت در حال عمل است
- کدام نسخه قابلیت فعال است
- کدام کاربر درخواست را به ایجنت سپرده است
- کدام ابزار فراخوانی می‌شود
- اقدام فقط خواندن است یا وضعیت را تغییر می‌دهد
- هدف کدام محیط است
- طبقه‌بندی داده چیست
- دامنه اثر ممکن چقدر است
- چه مقدار بودجه باقی مانده
- آیا استثنا فعالی وجود دارد
- کدام نسخه سیاست لازم‌الاجراست
این وضعیت از یک درخواست به درخواست بعدی تغییر می‌کند.
صفحه‌ای در ویکی این واقعیت‌ها را ارزیابی نمی‌کند.
یک دستور سیستمی نیز آن‌ها را به‌طور قطعی اعمال نمی‌کند.
وقتی ایجنت‌ها پیوسته کار می‌کنند، صف تأیید انسانی هم توان رسیدگی به تک‌تک اقدامات کم‌ریسک را ندارد.
به همین دلیل حاکمیت پیش از رسیدن به اجرا از کار می‌افتد. سازمان نیت سیاستی دارد، اما میان آن نیت و اثر جانبی، مرز تصمیم‌گیری اجرایی وجود ندارد.
سیاست اجرایی واقعاً چیست
سیاست اجرایی به این معنا نیست که تمام اسناد حاکمیتی را به کد تبدیل کنیم.
یعنی قواعدی را که باید رفتار ماشین را تغییر دهند مشخص کنیم و آن‌ها را در قالبی قرار دهیم که زمان اجرا بتواند به‌شکل یکنواخت ارزیابی کند.
یک سیاست اجرایی مفید هفت ویژگی دارد.
خارج از مدل است. مدل می‌تواند اقدام را پیشنهاد دهد، اما نباید مرجع نهایی صدور مجوز برای همان اقدام باشد.
ساخت‌یافته است. تصمیم باید بر پایه ویژگی‌های صریح و نیت نوع‌دار گرفته شود، نه بندی از متن آزاد که مدل ناچار باشد هر بار آن را دوباره تفسیر کند.
از وضعیت جاری آگاه است. یک نیت ممکن است در محیط آزمایشی مجاز و در محیط عملیاتی ممنوع باشد؛ یا تا وقتی بودجه کافی است اجازه اجرا بگیرد و با نزدیک‌شدن به سقف بودجه نیازمند تأیید شود.
نسخه‌بندی‌شده است. هر تصمیم باید به نسخه دقیقی از سیاست که آن را تولید کرده قابل انتساب باشد.
در مرزهای حساس قطعی است. مدل احتمالاتی می‌تواند برنامه پیشنهاد کند، اما مرز سخت مجوز نباید به میزان اطمینان مدل وابسته باشد.
قابل اعمال است. تصمیم رد باید واقعاً فراخوانی ابزار یا تغییر وضعیت را متوقف کند.
شواهد تولید می‌کند. سامانه باید ثبت کند چه چیزی ارزیابی شد، کدام قاعده منطبق بود، چه تصمیمی صادر شد و پس از آن چه رخ داد.
هدف این نیست که پاسخ همه پرسش‌های حاکمیتی قطعی شود. بسیاری از تصمیم‌های کسب‌وکار همچنان به قضاوت انسانی نیاز دارند.
هدف این است که مرز اعمال کنترل صریح باشد.
استدلال احتمالاتی می‌تواند پیشنهاد بدهد؛ کنترل قطعی تعیین می‌کند چه چیزی اجازه وقوع دارد.
معماری سیاست در زمان اجرا
معماری از زبان پیچیده حاکمیت ساده‌تر است.
یک جریان مفید:
درخواست ← نیت ساخت‌یافته ← تصمیم سیاستی ← اعمال کنترل ← اقدام ← شواهد
ایجنت یا لایه هماهنگ‌سازی ابتدا اقدام مورد نظر را به داده ساخت‌یافته تبدیل می‌کند. نقطه تصمیم‌گیری سیاست، این نیت را با هویت، دامنه، محیط، وضعیت جاری و مجموعه قواعد فعال می‌سنجد. سپس نقطه اعمال سیاست، پیش از وقوع اثر جانبی تصمیم را اجرا می‌کند.
خروجی تصمیم‌گیری سیاست نباید فقط بله یا خیر باشد.
تصمیم‌های مفید عبارت‌اند از:
- اجازه: داخل دامنه مصوب ادامه بده
- رد: اقدام را با دلیل ساخت‌یافته متوقف کن
- نیازمند تأیید: تا تأیید مرجع مشخص، اجرا را متوقف کن
- تعویق: چون یکی از شرایط لازم در زمان اجرا فراهم نیست، فعلاً اقدام نکن
- تنزل سطح: اگر سیاست اجازه می‌دهد از مسیر کم‌ریسک‌تر یا کم‌هزینه‌تر ادامه بده
- قرنطینه: مصنوع تولید شود، اما تا زمان بازبینی وارد مسیر عملیاتی نشود
نام این تصمیم‌ها ممکن است در هر سازمان متفاوت باشد. مهم این است که رفتار متناظر با هر تصمیم پیش از وقوع رخداد تعریف شده باشد.
تصمیمی که فقط در گزارش ثبت شود و جلوی اقدام را نگیرد، کنترل اجرایی نیست.
نقطه تصمیم‌گیری باید چه چیزهایی بداند
ارزیاب سیاست فقط به اندازه وضعیت و داده‌ای که می‌بیند قابل اعتماد است.
برای اقدامات مهم ایجنت معمولاً چند گروه ویژگی لازم است.
هویت و تفویض اختیار
- هویت ایجنت
- هویت و نسخه قابلیت
- انسان یا سرویس درخواست‌دهنده
- اختیار تفویض‌شده
- انقضا و دامنه تفویض اختیار
اقدام
- ابزار درخواستی
- عملیات
- منبع هدف
- اثر جانبی مورد انتظار
- رده‌های داده‌ای که خوانده یا نوشته می‌شوند
محیط
- محیط توسعه، محیط آزمایشی یا محیط عملیاتی
- دامنه مستأجر سامانه یا مشتری
- منطقه
- اهمیت سرویس
ریسک و اختیار
- رده اقدام
- سطح اختیار
- حداکثر دامنه اثر
- سطح شواهد الزامی
- الزامات تأیید انسانی
وضعیت زمان اجرا
- بودجه باقی‌مانده هزینه و توکن
- بودجه باقی‌مانده زمان یا تعداد گام
- ظرفیت باقی‌مانده تا سقف نرخ
- وضعیت جاری رخداد یا نگهداری
- نشانه‌های اخیر خودداری یا ناهنجاری
وضعیت حاکمیت
- مجموعه سیاست‌های فعال
- رکوردهای استثنا
- زمان انقضا
- کنترل‌های الزامی
- مالک سیاست
به همین دلیل حاکمیت هنگام اجرا نمی‌تواند فقط در یک دستور متنی جا بگیرد. دستور به همه این وضعیت‌ها دسترسی قابل اتکا ندارد و حتی اگر آن‌ها را ببیند، نباید بتواند مرز کنترلی خودش را کنار بگذارد.
دستور مرز مجوز نیست
یک پیاده‌سازی رایج با دستور شروع می‌شود:
«بدون تأیید به محیط عملیاتی استقرار نکن.»
این دستور مفید است، اما سازوکار اعمال کنترل نیست.
مدل ممکن است آن را بد بفهمد، دستور دیگری با آن تعارض پیدا کند، ابزاری مسیر دورزدن آن را باز کند، محتوای بازیابی‌شده ایجنت را فریب دهد یا به‌روزرسانی میزبان ترتیب اولویت دستورها را تغییر دهد.
هیچ‌یک از این موارد نباید مرز محیط عملیاتی را به یک توصیه اختیاری تبدیل کند.
تفکیک درست:
- دستور و مهارت رفتار را هدایت می‌کنند
- ابزار قابلیت را ارائه می‌کند
- سیاست مشخص می‌کند قابلیت در زمینه فعلی قابل استفاده هست یا نه
- اعمال کنترل جلوی اثر جانبی غیرمجاز را می‌گیرد
این تفکیک، آزمون‌پذیری سامانه را هم بهتر می‌کند.
می‌توانید ارزیابی کنید مدل معمولاً دستور را رعایت می‌کند.
جداگانه می‌توانید ثابت کنید زمان اجرا حتی وقتی مدل رعایت نمی‌کند اقدام ممنوع را متوقف می‌کند.
این‌ها دو تضمین متفاوت‌اند و حاکمیت به هر دو نیاز دارد.
سیاست باید در چند دروازه حضور داشته باشد
زمان اجرا آخرین مرز اعمال کنترل است، اما نباید اولین جایی باشد که سیاست ظاهر می‌شود.
یک سامانه بالغ، سیاست را در سراسر چرخه تحویل به کار می‌گیرد.
تدوین
سیاست باید بر آنچه ایجنت اجازه پیشنهاد آن را دارد اثر بگذارد.
ایجنت کدنویس باید از ابتدا بداند افزودن وابستگی تأییدنشده، دسترسی به قلمرو داده محدود یا تغییر مسیر اسرار محیط عملیاتی خارج از اختیار اوست. بازخورد زودهنگام از کار بیهوده جلوگیری می‌کند.
درخواست ادغام و CI
خط لوله باید سیاست‌های قابل بررسی ماشینی را قبل از ادغام ارزیابی کند.
مرزهای معماری، محدودیت وابستگی‌ها، الزامات شواهد، کنترل‌های امنیتی و بازبینان الزامی در این مرحله بررسی می‌شوند.
استقرار
سیاست باید تعیین کند که آیا مصنوع تولیدشده اجازه ورود به آن محیط را دارد یا نه.
طبقه‌بندی ریسک، شواهد آزمون، راهبرد انتشار، تأیید مالک و آمادگی بازگشت می‌توانند ورودی این تصمیم باشند.
زمان اجرا
زمان اجرا اقدام واقعی را با وضعیت فعلی ارزیابی می‌کند.
اینجاست که هویت، هدف، بودجه، محیط، ابزار، استثنا و شرایط زنده عملیاتی در یک تصمیم به هم می‌رسند.
زبان بیان سیاست لازم نیست در همه لایه‌ها یکسان باشد، اما مدل سیاست‌گذاری باید منسجم بماند.
اگر قواعد مرحله تدوین اقدامی را ممنوع کنند اما سامانه هنگام اجرا آن را مجاز بداند، با تعارض سیاستی روبه‌رو هستید.
اگر سامانه هنگام اجرا چیزی را متوقف کند که CI تأیید کرده است، شواهد باید نشان دهند کدام وضعیت تغییر کرده است.
رفتار نیز یکی از سطوح استقرار است
سیاست باید بداند کد تنها چیزی نیست که رفتار را تغییر می‌دهد.
در یک سامانه ایجنت‌محور، هر یک از موارد زیر می‌تواند رفتار محیط عملیاتی را تغییر دهد:
- نسخه مدل
- دستور سیستمی
- فایل‌های دستور
- مهارت
- قاعده
- طرحواره ابزار
- مجوزهای ابزار
- منطق مسیریابی
- پیکربندی بازیابی
- منابع دانش
- مجموعه سیاست‌ها
- نسخه میزبان زمان اجرا
تعویض مدل رفتار را تغییر می‌دهد.
به‌روزرسانی مهارت رفتار را تغییر می‌دهد.
مجوز جدید رفتار را تغییر می‌دهد.
مجموعه سیاست‌ها نیز رفتار را تغییر می‌دهد.
هر تغییر رفتار، نوعی استقرار است.
پس خود مصنوعات سیاستی نیز به انضباط انتشار نیاز دارند.
آن‌ها به نسخه، مالک، آزمون، مراحل ارتقا، مسیر بازگشت و قابلیت ردیابی نیاز دارند.
تغییر سیاستی که رفتار زمان اجرا را عوض کند، یک تغییر محیط عملیاتی است.
مهارت‌ها، قواعد و دستورها خودِ سامانه حاکمیت نیستند
چارچوب‌های ایجنتی مصنوعاتی با نام‌هایی مانند مهارت، قاعده، دستور، حفاظ کنترلی یا سیاست ارائه می‌کنند.
این مصنوعات مفیدند، زیرا نیت انسانی را به راهنمایی قابل استفاده برای ماشین تبدیل می‌کنند.
اما نامیدن یک دستور به‌عنوان «سیاست»، آن را به مرز اعمال کنترل تبدیل نمی‌کند.
سؤال مفید این نیست:
«آیا فایل قواعد داریم؟»
سؤال‌های مفید:
- مالک آن کیست؟
- نسخه‌بندی‌شده است؟
- چگونه آزمون می‌شود؟
- آیا ایجنت می‌تواند آن را نادیده بگیرد؟
- آیا ابزار می‌تواند آن را دور بزند؟
- زمان اجرا قبل از اثر جانبی آن را ارزیابی می‌کند؟
- رد واقعاً اجرا را متوقف می‌کند؟
- می‌توانیم ثابت کنیم کدام نسخه فعال بوده؟
- بازگشت داریم؟
مهارت‌ها، قواعد، دستورهای ایجنت و محدودیت‌های ابزار بخشی از سطح رفتار سامانه‌اند.
حاکمیت، نظام عملیاتی پیرامون این مصنوعات است.
استثناها باید جزء اصلی سامانه باشند
هر سامانه سیاست‌گذاری جدی در نهایت به استثنا نیاز دارد.
اشتباه این است که استثنا را مجوز دورزدن غیررسمی بدانیم.
«برای این رخداد موقتاً دسترسی بده» به پیامی در Slack تبدیل می‌شود.
«برای این مهاجرت اجازه استفاده از ابزار را بده» به یک ویرایش مستقیم در پیکربندی تبدیل می‌شود.
«این بار تأیید را حذف کن» می‌شود دورزدنی که بعداً کسی نمی‌تواند توضیح دهد.
استثنای تحت حاکمیت باید یک رکورد صریح با این مشخصات باشد:
- درخواست‌دهنده
- تأییدکننده
- دلیل
- سیاست متأثر از استثنا
- دامنه دقیق
- زمان آغاز
- زمان انقضا
- رده اقدام مجاز
- الزامات شواهد
- مسیر لغو
دامنه استثنا باید از قاعده‌ای که موقتاً کنار می‌گذارد محدودتر باشد.
باید به‌طور خودکار منقضی شود.
سامانه هنگام اجرا باید استثنا را مانند هر ورودی سیاستی دیگری ارزیابی کند.
استثنای بدون تاریخ انقضا، تغییری دائمی در سیاست است که موقت جلوه داده شده.
تغییرات سیاستی به تحویل تدریجی نیاز دارند
یک سیاست اجرایی بد می‌تواند به اندازه کد معیوب به محیط عملیاتی آسیب بزند.
قاعده رد بیش از حد گسترده می‌تواند گردش‌کارهای حیاتی را متوقف کند.
شرط ناقص می‌تواند راه یک اقدام خطرناک را باز بگذارد.
تغییر آستانه می‌تواند سیلی از درخواست‌های تأیید ایجاد کند.
پس سیاست نباید مستقیم از تدوین به اعمال کامل کنترل برود.
ترتیب امن‌تر:
- آزمون روی سناریوهای شناخته‌شده
- بازپخش روی ردهای اخیر
- اجرای آزمایشی بدون اعمال: سیاست جدید را بدون اثرگذاری بر اجرا ارزیابی کنید
- مقایسه رأی قدیم و جدید
- انتشار محدود: کنترل را ابتدا در دامنه‌ای محدود اعمال کنید
- ارتقا وقتی شواهد قابل قبول است
- بازگشت وقتی خودداری، ارجاع یا نشانه رخداد بدتر شد
این همان تحویل تدریجی است که برای حاکمیت به کار می‌رود.
مصنوع تغییر کرده است، نه اصل مهندسی.
هر تصمیم باید شواهد بر جا بگذارد
سیاست بدون شواهد، شکل دیگری از ابهام می‌سازد.
سامانه باید برای اقدامات مهم در زمان اجرا یک رکورد تصمیم فشرده تولید کند.
یک رکورد مفید شامل این موارد است:
- شناسه رد ریشه
- شناسه تصمیم سیاستی
- هویت ایجنت و قابلیت
- نیت ساخت‌یافته
- وضعیت ویژگی‌های مرتبط
- مجموعه سیاست و نسخه آن
- قاعده منطبق یا دلیل تصمیم
- رأی
- نتیجه اعمال کنترل
- ارجاع تأیید انسانی، در صورت نیاز
- ارجاع استثنا در صورت نیاز
- مهر زمانی
لازم نیست همه زمینه را ثبت کنید.
فقط به‌اندازه‌ای ثبت کنید که بتوان علت مجازشدن، توقف یا ارجاع هر اقدام را بازسازی کرد.
این شواهد باید به همان الگوی ردیابی اجرا و تغییر متصل شوند.
در بازبینی رخداد، پرسش از این عبارت:
«چه شد؟»
تبدیل می‌شود به:
«کدام سیاست، با توجه به چه وضعیتی و به چه دلیل این اقدام را مجاز دانست؟»
این سؤال بسیار مفیدتر است.
الگوهای شکست تکراری‌اند
وقتی سیاست اجرایی وجود ندارد، الگوهای شکست معمولاً آشنا هستند.
The policy-in-a-wiki failure: قاعده وجود دارد و همه آن را پذیرفته‌اند، اما هیچ بخش اجرایی پیش از اقدام آن را ارزیابی نمی‌کند.
The policy-in-a-prompt failure: قاعده وجود دارد، اما همان سامانه‌ای که باید مهار شود مسئول تفسیر و رعایت آن نیز هست.
The split enforcement failure: یک مسیر سیاست را بررسی می‌کند، اما مسیر دیگری بدون همان بررسی به همان اثر جانبی می‌رسد.
The stale-state failure: تصمیم بر پایه اطلاعات ناقص یا قدیمی، ظاهراً منطقی صادر می‌شود.
The silent exception failure: مجوز کنارگذاشتن قاعده، مالک، تاریخ انقضا یا رد قابل پیگیری ندارد.
The mutable policy failure: قاعده بدون ثبت نسخه عوض می‌شود و کسی نمی‌تواند ثابت کند تصمیم دیروز بر پایه کدام نسخه بوده است.
The evidence-free deny: سامانه کار را متوقف می‌کند اما نمی‌تواند قاعده فعال‌شده را توضیح دهد؛ در نتیجه فشار برای دورزدن کنترل بالا می‌رود.
The evidence-free allow: اقدام انجام می‌شود اما مدرکی برای علت صدور مجوز وجود ندارد.
الگوی مشترک روشن است.
سیاست در حد نیت وجود داشته است.
اما به‌صورت کنترل اجرایی وجود نداشته است.
ترتیب عملی ساخت
کار را با تبدیل کل راهنمای حاکمیت به قواعد ماشینی آغاز نکنید.
یک مسیر اقدام مهم را انتخاب و کنترل آن را واقعی کنید.
۱. نیت ساخت‌یافته تعریف کنید
یک اقدام مهم، مانند استقرار، نوشتن داده مشتری، چرخش یک راز یا فراخوانی ابزار محیط عملیاتی را انتخاب کنید.
اقدام را با فیلدهای نوع‌دار نمایش دهید، نه با متن آزاد.
۲. نقطه تصمیم‌گیری سیاست را بیرون از مدل قرار دهید
مدل پیشنهاد می‌دهد.
ارزیاب تصمیم می‌گیرد.
اختیار اعمال کنترل را بیرون از مؤلفه احتمالاتی نگه دارید.
۳. نقطه اعمال کنترل را قبل از اثر جانبی بگذارید
رد باید اجرا را متوقف کند.
به خودداری داوطلبانه مدل تکیه نکنید.
۴. حداقل وضعیت لازم در زمان اجرا را اضافه کنید
هویت، اقدام، هدف، محیط، سطح اختیار، وضعیت بودجه، نسخه سیاست و وضعیت استثنا برای شروع کافی‌اند.
ویژگی جدید را وقتی اضافه کنید که تصمیم واقعی به آن نیاز دارد.
۵. شواهد تصمیم را تولید کنید
به هر تصمیم مهم یک شناسه بدهید و آن را به رد اجرا متصل کنید.
تصمیم‌های اجازه، رد و نیاز به تأیید باید توضیح‌پذیر باشند.
۶. مجموعه سیاست‌ها را نسخه‌بندی و آزمون کنید
آزمون‌های قطعی سیاست را اجرا و ردهای اخیر را بازپخش کنید.
مجموعه سیاست را یک مصنوع محیط عملیاتی بدانید.
۷. اجرای آزمایشی بدون اعمال، انتشار محدود و ارتقا
قبل از اینکه سیاست جدید همه‌چیز را کنترل کند ببینید چه خواهد کرد.
انتشار را تدریجی انجام دهید و بازگشت را ساده و قابل پیش‌بینی نگه دارید.
این ترتیب عمداً کوچک است.
هدف، ساختن امپراتوری سیاست‌گذاری نیست.
هدف، ایجاد پیوندی قابل اعتماد میان نیت حاکمیتی و رفتار زمان اجرا و سپس گسترش تدریجی آن است.
جمع‌بندی
سخت‌ترین بخش حاکمیت هوش مصنوعی نوشتن قاعده نیست.
سخت‌ترین بخش این است که قاعده از تماس با اجرا جان سالم به در ببرد.
سیاست‌ها، اصول، هیئت‌های بازبینی و ماتریس‌های تأیید همگی مهم‌اند؛ اما تنها زمانی به حاکمیت واقعی تبدیل می‌شوند که سامانه بتواند پیش از اقدام، آن‌ها را با وضعیت جاری بسنجد، تصمیم را اعمال کند و شواهد را نگه دارد.
این همان لایه سیاست اجرایی است.
این لایه میان رفتار احتمالاتی و اثر جانبی واقعی قرار می‌گیرد.
وضعیت جاری را وارد تصمیم‌گیری می‌کند.
استثناها را آشکار می‌کند.
تغییرات سیاستی را قابل استقرار و بازگشت‌پذیر می‌کند.
و به سازمان اجازه می‌دهد در رخداد به سؤال اصلی پاسخ دهد:
«چرا اجازه داده شد این اقدام اتفاق بیفتد؟»
اگر جواب «چون به ایجنت گفته بودیم درست رفتار کند» باشد، لایهٔ سیاست هنوز وجود ندارد.
اگر پاسخ به قاعده‌ای نسخه‌بندی‌شده، وضعیت ثبت‌شده، اعمال کنترل پیش از اثر جانبی و رد قابل پیگیری اشاره کند، حاکمیت سرانجام به اجرا رسیده است.
حاکمیت نه آن چیزی است که در سیاست نوشته شده، بلکه آن چیزی است که سامانه هنگام اجرا می‌تواند اعمال و اثبات کند.
مقاله بعدی یک گام به خود ایجنت نزدیک‌تر می‌شود: دستورهای متنی برای تعریف کامل رابطه میان انسان، ایجنت و ابزار بیش از حد مبهم‌اند.
قسمت بعدی: ایجنت‌های هوش مصنوعی به قرارداد نیاز دارند، نه دستورهای بهتر.
نسخه اصلی این مقاله در ۱۸ مه ۲۰۲۶ توسط Reza Arani در Medium منتشر شده است. این نسخه برای Aipolix به‌عنوان بخش چهارم مجموعه حاکمیت هوش مصنوعی در یک شرکت نرم‌افزاری مبتنی بر هوش مصنوعی بازنویسی و بومی‌سازی شده است.
دیدگاهها
هنوز دیدگاهی ثبت نشده است. اولین نفر باشید.
ثبت دیدگاه