سامانه تحویل شده است. دمو هم کار میکند. مدیر پروژه چند پرسش از چتبات میپرسد و پاسخهای قابل قبولی میگیرد. صورتجلسه امضا میشود و چند هفته بعد نخستین اختلاف آغاز میشود:
- در داده واقعی پاسخها آن دقتی را ندارند که در جلسه دیده شد
- با افزایش کاربران زمان انتظار بالا میرود
- نسخه مدل عوض میشود و کیفیت بعضی کارها افت میکند
- هزینه سرویس از برآورد اولیه بیشتر میشود
- هیچکس دقیق نمیداند کدامیک از این موارد نقص پیمانکار است و کدامیک خارج از تعهد او.
مشکل لزوما بد بودن مدل یا کمکاری مجری نیست. گاهی از ابتدا روشن نشده که «تحویل پروژه هوش مصنوعی» دقیقا یعنی چه. عبارتهایی مانند «دقت بالا»، «پاسخگویی هوشمند»، «پشتیبانی از زبان فارسی»، «مقیاسپذیر» یا حتی «دقت ۹۵ درصد» تا وقتی روی داده، کاربر، شرایط اجرا و هزینه خطا تعریف نشدهاند، معیار تحویل نیستند. این عبارتها بیشتر شبیه وعدهاند تا تعهد قابل سنجش.
قرارداد حقوقی باید با نظر متخصص حقوقی و متناسب با قوانین، صنعت و ریسک همان سازمان تنظیم شود. موضوع این یادداشت نوشتن بندهای حقوقی نیست؛ موضوع آن بسته فنی و مدیریتیای است که باید پیش از امضا تعریف شود تا حقوقدان بتواند تعهد را دقیق بنویسد، مدیر بتواند درباره ادامه یا توقف تصمیم بگیرد و تیم فنی بتواند نتیجه را آزمایش کند.
مدل، محصول نهایی نیست
در یک پروژه نرمافزاری متعارف نیز تحویل کد بدون مستندات، آزمون، پیکربندی و راه بهرهبرداری کافی نیست. در پروژه هوش مصنوعی این فاصله بیشتر است. یک مدل میتواند روی داده آزمایش خوب باشد اما در فرایند واقعی شکست بخورد. ممکن است پاسخ درست باشد اما دیر برسد؛ ممکن است میانگین دقت مناسب باشد اما خطای آن دقیقا در موارد پرهزینه رخ دهد؛ ممکن است سامانه در روز تحویل کار کند اما با تغییر مدل، داده یا پرامپت رفتارش عوض شود.
بنابراین موضوع قرارداد نباید صرفا «یک مدل» یا «یک چتبات» باشد. آنچه خریداری میشود یک خدمت درون یک فرایند واقعی است. این خدمت داده میگیرد، تصمیم یا پیشنهاد تولید میکند، به سامانههای دیگر متصل میشود، گاهی به انسان ارجاع میدهد، هزینه ایجاد میکند و در طول زمان تغییر میکند. بسته تحویل نیز باید همین چرخه کامل را پوشش دهد.
راهنمای خرید هوش مصنوعی دولت بریتانیا توصیه میکند نیاز بر اساس مسئله و خروجی تعریف شود، ارزیابی داده پیش از خرید انجام گیرد، محدودیتهای فنی و اخلاقی در ارزیابی دیده شوند و مدیریت چرخه عمر از ابتدا جزو خرید باشد. چارچوب مدیریت ریسک هوش مصنوعی NIST نیز طراحی، توسعه، استفاده و ارزیابی را یک چرخه پیوسته میبیند. این چارچوبها جای قرارداد را نمیگیرند، اما یک هشدار مشترک دارند: خرید هوش مصنوعی با خرید یک قابلیت نمایشی تمام نمیشود.
نخست باید معلوم باشد چه مسئلهای تحویل گرفته میشود
پیش از هر بحثی درباره مدل، GPU یا معماری، سه جمله باید بدون واژههای مبهم نوشته شوند:
- چه کسی در چه مرحلهای از کار از سامانه استفاده میکند؟
- سامانه دقیقا کدام تصمیم یا فعالیت را بهتر، سریعتر یا کمهزینهتر میکند؟
- اگر سامانه وجود نداشته باشد، خط مبنای فعلی چیست؟
برای نمونه، «ساخت دستیار هوشمند منابع انسانی» موضوع قابل تحویل نیست. در مقابل، «پاسخ به پرسش کارکنان درباره آییننامه مرخصی بر اساس آخرین نسخه اسناد مصوب، همراه با ارجاع به بند و ارجاع موارد نامطمئن به کارشناس» به یک خدمت قابل آزمون نزدیک شده است. کاربر، منبع، نوع پاسخ، مرز اطمینان و مسیر استثنا در همین یک جمله دیده میشوند.
خط مبنا نیز ضروری است. اگر اکنون کارشناس در ۸۰ درصد موارد پاسخ درست میدهد اما دو روز زمان میبرد، پروژه شاید برای کاهش زمان پاسخ ارزش داشته باشد. اگر یک قاعده ساده همان مسئله را با هزینه کمتر و خطای قابل پیشبینی حل میکند، استفاده از مدل پیچیده مزیت محسوب نمیشود. در یادداشت سرمایهگذاری در هوش مصنوعی درباره ارزش مسئله و تناسب سرمایهگذاری بحث شده است؛ قرارداد باید این منطق را به شاخص قابل سنجش تبدیل کند.
«دقت» را به یک مجموعه آزمون و هزینه خطا تبدیل کنید
عدد دقت بدون تعریف نمونهها، توزیع داده و نوع خطا تقریبا بیمعناست. برای پذیرش، باید یک مجموعه آزمون توافقشده وجود داشته باشد که نمونههای عادی، مرزی، دشوار و خارج از دامنه را پوشش دهد. بهتر است بخشی از این مجموعه تا زمان ارزیابی نهایی در اختیار سازنده نباشد تا سامانه فقط برای همان مثالهای شناختهشده بهینه نشود.
برای هر نمونه دستکم این موارد ثبت شوند:
- ورودی و شرایط اجرای آزمون؛
- پاسخ یا رفتار قابل قبول؛
- نوع و شدت خطا؛
- روش داوری و فرد یا نقش مسئول داوری؛
- نسخه داده، مدل، پرامپت و نرمافزار؛
- نتیجه خط مبنا و نتیجه سامانه پیشنهادی.
همه خطاها همارزش نیستند. از دست دادن یک خرابی خطرناک با تولید یک هشدار اضافی یکسان نیست. افشای سندی که کاربر اجازه دیدنش را ندارد با یک پاسخ ناقص یکسان نیست. عدد نهایی باید در کنار نرخ خطاهای بحرانی، موارد ارجاع به انسان و هزینه بررسی انسانی خوانده شود. مطلب بعدی این مجموعه، «دقت ۹۵ درصد برای کارخانه چه معنایی دارد؟»، همین مسئله را با یک سناریوی صنعتی باز میکند.
در سامانههای مولد، مجموعه آزمون فقط چند پرسش و پاسخ طلایی نیست. باید بررسی شود سند درست بازیابی شده یا نه، پاسخ به منبع وفادار مانده یا نه، استناد واقعا ادعا را پشتیبانی میکند یا نه، سامانه در نبود پاسخ چه رفتاری دارد و آیا قالب و محدودیتهای عملیاتی را رعایت میکند. مقاله مدل خوب برای فارسی را چگونه بسنجیم؟ میان کیفیت خود مدل و کیفیت سامانه نهایی تفکیک قائل میشود؛ قرارداد نیز باید همین تفکیک را حفظ کند.
داده نیز بخشی از تحویل است
بسیاری از اختلافها زمانی آشکار میشوند که پروژه برای آموزش، بازیابی یا ارزیابی به داده سازمان وابسته شده است. باید روشن باشد:
- داده اولیه را چه کسی فراهم میکند و کیفیت آن بر عهده چه کسی است؟
- چه نسخهای از داده برای آموزش، ارزیابی و بهرهبرداری استفاده شده است؟
- منشأ، مجوز، رضایت و محدودیت استفاده هر مجموعه چیست؟
- داده در کجا پردازش و نگهداری میشود و چه کسانی به آن دسترسی دارند؟
- داده مشتقشده، برچسبها، نمونههای خطا و بازخورد کاربران متعلق به چه کسی است؟
- پس از پایان قرارداد کدام نسخهها باید تحویل، بازگردانده یا حذف شوند؟
عبارت «داده برای آموزش استفاده نمیشود» پاسخ همه این پرسشها نیست. داده ممکن است برای تولید پاسخ، ثبت رویداد، کش، پشتیبانی یا ارزیابی به سامانههای دیگری منتقل شود. در حفظ محرمانگی داده در استفاده از APIهای عمومی مرزهای پردازش و محدودیت راهحلهای متداول توضیح داده شده است. قرارداد باید جریان واقعی داده را توصیف کند، نه فقط نیت کلی تأمینکننده را.
شناسنامه فنی سامانه را تحویل بگیرید
نام تجاری مدل کافی نیست. یک خدمت هوش مصنوعی از اجزای متعددی ساخته میشود که هرکدام ممکن است نتیجه را تغییر دهند. شناسنامه تحویل باید دستکم شامل این موارد باشد:
- نام و نسخه دقیق مدلها، وزنها و آداپترها؛
- مدل embedding و reranker در سامانههای بازیابی؛
- قالب و نسخه پرامپتها و سیاستهای سیستمی؛
- نسخه کد، کتابخانهها، موتور اجرا و تنظیمات مؤثر؛
- روش قطعهبندی، نمایهسازی و انتخاب سند؛
- وابستگیهای بیرونی و APIهای مورد استفاده؛
- پیکربندی محیطهای توسعه، آزمون و تولید؛
- محدودیتهای شناختهشده و مواردی که خارج از دامنهاند.
هدف این فهرست مطالبه افشای همه اسرار تجاری نیست. هدف آن است که سازمان بداند چه چیزی آزموده شده و پس از تغییر کدام جزء باید دوباره آزمون انجام شود. اگر پیمانکار مجاز است مدل را بدون اطلاع عوض کند، نتیجه آزمون پذیرش امروز تضمینی برای رفتار فردا نیست. اگر هر تغییر کوچک نیازمند اجازه رسمی باشد نیز بهرهبرداری فلج میشود. راه حل، طبقهبندی تغییر است: کدام تغییر صرفا وصله عملیاتی است، کدام تغییر به آزمون رگرسیون نیاز دارد و کدام تغییر باید دوباره پذیرفته شود.
امنیت، دسترسی و ثبت رویداد تحویلدادنی هستند
در یک دستیار اسناد، پاسخ درست برای کاربر غیرمجاز همچنان یک شکست است. در یک Agent، انجام صحیح کاری که اجازهاش صادر نشده موفقیت محسوب نمیشود. قرارداد باید مشخص کند هویت کاربر چگونه منتقل میشود، دسترسی پیش از بازیابی یا اجرا کجا کنترل میشود، چه رویدادهایی ثبت میشوند، داده حساس چگونه در لاگ و حافظه مدیریت میشود و در رخداد امنیتی چه کسی مسئول توقف، بررسی و اطلاعرسانی است.
آزمون امنیت نیز نباید به اسکن آسیبپذیری نرمافزار محدود بماند. تزریق دستور از سند، دور زدن مرز دسترسی، نشت اطلاعات میان نشستها، اجرای تکراری ابزار، سوءاستفاده از ورودی بلند و رفتار سامانه در قطع سرویسهای وابسته نمونههایی از آزمونهای مخصوص این معماریاند. دامنه آزمون باید با اختیار واقعی سامانه متناسب باشد. Jev و Laya؛ وقتی هوش مصنوعی بهجای حرف زدن تصمیم میگیرد نشان میدهد هرچه سامانه از پیشنهاد به اجرا نزدیکتر شود، ثبت تصمیم و مرز اختیار مهمتر میشوند.
کیفیت بدون ظرفیت و هزینه کامل نیست
سامانهای که در دموی تککاربره پاسخ مناسبی میدهد ممکن است در بار واقعی صف طولانی بسازد یا هزینه غیرقابل قبولی ایجاد کند. در تحویل باید شرایط آزمون بار ثبت شود:
- تعداد کاربران و درخواستهای همزمان؛
- طول معمول و حداکثر ورودی و خروجی؛
- زمان شروع پاسخ، زمان تکمیل و نرخ خطا؛
- رفتار صف، لغو درخواست و محدودیت ظرفیت؛
- هزینه به ازای درخواست یا خروجی قابل قبول؛
- مصرف زیرساخت و وابستگی به ظرفیت تأمینکننده بیرونی؛
- رفتار سامانه هنگام اشباع یا خرابی.
میانگین بهتنهایی کافی نیست؛ صدکهای زمان پاسخ و بدترین حالتهای توافقشده نیز اهمیت دارند. همچنین هزینه باید برای خروجی قابل قبول سنجیده شود، نه صرفا برای هر هزار توکن یا هر ساعت GPU. اگر خروجی ارزان اما نیازمند بازبینی طولانی باشد، بخشی از هزینه به نیروی انسانی منتقل شده است. برای چارچوب این محاسبه میتوان به هزینه واقعی اجرای مدل زبانی؛ خرید، اجاره یا API مراجعه کرد.
مسیر انسان و استثنا را مکتوب کنید
«نظارت انسانی» وقتی معنا دارد که انسان زمان، اطلاعات و اختیار لازم برای مداخله داشته باشد. در بسته تحویل باید روشن باشد:
- چه خروجیهایی بدون تأیید انسان قابل استفادهاند؟
- کدام موارد باید به بازبین ارجاع شوند؟
- بازبین چه شواهدی میبیند؟
- چه زمانی میتواند تصمیم سامانه را رد یا اصلاح کند؟
- اصلاح او چگونه ثبت و در بهبود بعدی استفاده میشود؟
- اگر بازبین در دسترس نبود، رفتار امن سامانه چیست؟
اگر همه پاسخها باید دوباره از ابتدا توسط متخصص بررسی شوند، ممکن است پروژه فقط رابط تازهای به همان کار قبلی اضافه کرده باشد. اگر هیچ خروجی پرریسکی بازبینی نشود نیز سازمان عملا اختیار را به سامانه واگذار کرده است. معیار پذیرش باید هزینه و زمان نظارت انسانی را نیز اندازه بگیرد.
بهرهبرداری از روز بعد از تحویل آغاز میشود
مدل و داده ثابت نمیمانند. زبان کاربران، ترکیب درخواستها، آییننامهها، تهدیدها و سرویسهای بیرونی تغییر میکنند. بنابراین قرارداد باید برای دوره بهرهبرداری پاسخ داشته باشد:
- چه شاخصهایی پایش میشوند و آستانه هشدار چیست؟
- نمونه خطا چگونه ثبت، اولویتبندی و رفع میشود؟
- چه کسی مجاز است مدل، داده یا پرامپت را تغییر دهد؟
- نسخه قبلی چگونه نگهداری یا بازگردانی میشود؟
- آزمون رگرسیون با کدام مجموعه و در چه فاصلهای اجرا میشود؟
- رخداد، افت کیفیت و تغییر مهم چگونه گزارش میشوند؟
- پشتیبانی، بهروزرسانی و نگهداری تا چه زمانی ادامه دارد؟
ISO/IEC 42001 هوش مصنوعی را در قالب یک نظام مدیریتی با نگهداری و بهبود مستمر میبیند. حتی اگر سازمان قصد اخذ گواهی نداشته باشد، این نگاه برای قرارداد مفید است: بهرهبرداری مرحله پس از پروژه نیست؛ بخشی از خود سامانه است.
امکان خروج را پیش از ورود بسنجید
آخرین تحویلدادنی، توان ادامه کار بدون تأمینکننده فعلی است. این به معنی الزام همیشگی به تحویل همه کدها یا وزنهای اختصاصی نیست؛ مدل کسبوکار و مالکیت فکری میتوانند متفاوت باشند. اما سازمان باید بداند در پایان قرارداد چه چیزی نزد او میماند و تعویض تأمینکننده چه هزینهای دارد.
فهرست خروج میتواند شامل داده پاک و نسخهبندیشده، شِمای داده، پرسشها و نتایج ارزیابی، تنظیمات و پرامپتهای متعلق به سازمان، مستندات رابطها، گزارش رخدادها، فهرست وابستگیها، روش پشتیبانگیری و زمان همکاری برای مهاجرت باشد. اگر تاریخچه ارزیابی، بازخورد کاربران و قواعد کسبوکار فقط در سامانه پیمانکار باقی بمانند، سازمان حتی با دریافت داده خام نیز دانش پروژه را از دست میدهد.
راهنمای خرید هوش مصنوعی دولت بریتانیا نیز اجتناب از قفلشدگی در تأمینکننده، توجه به استانداردهای باز، مالکیت فکری، انتقال دانش و نیازهای نگهداری را از مسائل اصلی خرید میداند. این موضوع را نباید به پایان قرارداد موکول کرد؛ قدرت مذاکره برای خروج، پیش از ورود بیشتر است.
پرداخت را به شواهد پیوند دهید، نه فقط به تاریخ
در پروژههای پرابهام بهتر است پرداخت و تصمیم ادامه بر اساس دروازههای قابل ارزیابی انجام شوند:
| مرحله | تحویلدادنی اصلی | پرسش تصمیم |
|---|---|---|
| کشف مسئله | تعریف خدمت، خط مبنا، داده قابل دسترس، ریسک و گزینه سادهتر | آیا مسئله ارزش ادامه دارد؟ |
| نمونه اولیه | مسیر فنی محدود و قابل تکرار روی داده نمونه | آیا اصل راهحل ممکن است؟ |
| پایلوت | آزمون روی جریان واقعی محدود، مجموعه آزمون مستقل، هزینه و نظارت انسانی | آیا راهحل در عمل ارزش ایجاد میکند؟ |
| تولید | امنیت، ظرفیت، پایش، پشتیبانی، بازیابی و مسئولیتها | آیا سامانه آماده بهرهبرداری کنترلشده است؟ |
| خروج یا انتقال | داده، مستندات، تاریخچه ارزیابی و همکاری مهاجرت | آیا سازمان میتواند خدمت را ادامه دهد؟ |
نمونه اولیه موفق، پذیرش تولید نیست. پایلوت نیز نباید با چند کاربر همراه و داده انتخابشده به جای آزمون واقعی معرفی شود. هر مرحله باید ابهام مشخصی را کم کند و امکان توقف یا اصلاح مسیر را باقی بگذارد.
برگه حداقلی تحویل پروژه هوش مصنوعی
اگر قرار باشد همه این بحث در یک صفحه خلاصه شود، پیش از امضا برای این دوازده مورد پاسخ مکتوب لازم است:
- مسئله، کاربر و نتیجه مورد انتظار چیست؟
- خط مبنا و گزینه غیرهوشمصنوعی کدام است؟
- دامنه و موارد خارج از دامنه چیست؟
- مجموعه آزمون پذیرش و روش داوری کدام است؟
- خطاها چگونه بر اساس هزینه و شدت تفکیک میشوند؟
- داده از کجا میآید و حقوق، نسخه و محل پردازش آن چیست؟
- شناسنامه مدلها، نرمافزار، پرامپت و پیکربندی چیست؟
- امنیت، دسترسی و ثبت رویداد چگونه آزموده میشوند؟
- ظرفیت، زمان پاسخ و هزینه در چه شرایطی سنجیده میشوند؟
- انسان کجا و با چه اختیاری مداخله میکند؟
- تغییر نسخه، پایش، رخداد و بازآزمایی چگونه مدیریت میشوند؟
- در پایان قرارداد چه چیزهایی تحویل میشوند و مسیر خروج چیست؟
این فهرست جای پیوست فنی تفصیلی، ارزیابی امنیت، توافق سطح خدمت یا متن حقوقی را نمیگیرد. ارزش آن در این است که اجازه نمیدهد پروژه با عبارتی مانند «سامانه هوشمند با دقت بالا» آغاز شود و در روز تحویل تازه معلوم شود خریدار و مجری دو چیز متفاوت را تصور کردهاند.
قرارداد خوب، اختلاف را حذف نمیکند؛ موضوع اختلاف را روشن میکند
هیچ قراردادی همه تغییرات فناوری و همه رفتارهای یک مدل را پیشبینی نمیکند. حتی کاملترین مجموعه آزمون نیز نماینده تمام آینده نیست. هدف واقعبینانه این است که طرفین بدانند چه چیزی را ساختهاند، چگونه آن را میسنجند، چه تغییری نیازمند بازآزمایی است، چه کسی در بهرهبرداری مسئول است و اگر نتیجه کافی نبود چگونه مسیر را اصلاح یا متوقف میکنند.
مدل ممکن است در طول قرارداد عوض شود. داده میتواند کاملتر شود. روش سادهتر شاید جای معماری اولیه را بگیرد. این تغییرها شکست قرارداد نیستند، اگر مسئله، معیار پذیرش و فرایند تغییر روشن باشند. شکست واقعی زمانی رخ میدهد که یک دموی خوب به جای یک خدمت قابل سنجش تحویل گرفته شود و همه طرفها پس از امضا تازه درباره معنای «موفقیت» مذاکره کنند.