حاکمیت داده در پروژه‌های هوش مصنوعی سازمانی

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

داده آموزش از کجا می‌آید و مال کیست

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

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

خروجی عملی ساده است: برای هر مجموعه داده یک سطر در یک جدول، با نام منبع، مالک داده (یک نفر، نه یک واحد)، مبنای استفاده و تاریخ تأیید. اگر نتوانید این سطر را پر کنید، آن داده هنوز آماده ورود به پروژه نیست.

اقامت داده و چرا در ایران اهمیت دارد

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

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

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

کمینه‌سازی: کمتر جمع کنید، کمتر نگه دارید

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

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

کیفیت برچسب‌گذاری، یک مسئله حاکمیتی است

در بیشتر پروژه‌ها برچسب‌گذاری به ارزان‌ترین منبع ممکن سپرده می‌شود و بعد تیم مدل‌سازی هفته‌ها با نتایج عجیب سر و کله می‌زند. اما برچسب، تعریفِ درست و غلط برای مدل است. اگر دو برچسب‌گذار روی این‌که یک تیکت «شکایت» است یا «درخواست» در سی درصد موارد اختلاف داشته باشند، هیچ مدلی از سی درصد خطا بهتر نمی‌شود و هیچ‌کس نخواهد فهمید مشکل از مدل نبوده.

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

ارزیابی مدل، یک تعهد مستمر

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

ارزیابی مستمر یعنی سه چیز. اول، مجموعه آزمون ثابتی که در طول زمان نمونه‌های جدید می‌گیرد، به‌ویژه نمونه‌هایی که مدل در محیط واقعی روی آن‌ها اشتباه کرده. دوم، تفکیک معیارها به زیرگروه: مدلی که در کل ۹۴ درصد دقت دارد ممکن است روی مشتریان یک استان ۷۰ درصد باشد و میانگین این را پنهان می‌کند. سوم، تعیین این‌که چه کسی نتایج را می‌بیند و اختیار توقف مدل را دارد. اگر این نفر مشخص نباشد، مدل خراب تا وقتی مشتری شکایت کند به کار ادامه می‌دهد.

پایش رانش

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

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

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

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

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

حداقل چیزی که باید وجود داشته باشد

اگر همه این‌ها را به یک فهرست تقلیل دهیم، به جدول زیر می‌رسیم. این کف است، نه سقف؛ اما پروژه‌ای که همین شش سند را با مسئول مشخص داشته باشد، از اکثر پروژه‌هایی که دیده‌ایم جلوتر است.

جمع‌بندی

هیچ‌کدام از این‌ها به ابزار خاصی نیاز ندارد: یک جدول، چند سند کوتاه، و مهم‌تر از همه چند نام. سازمان‌هایی که این کار را از روز اول انجام می‌دهند، پروژه‌شان کندتر شروع می‌شود و سریع‌تر تمام می‌شود. این همان بررسی‌ای است که در ابتدای هر پروژه هوش مصنوعی انجام می‌دهیم.

خدمات هوش مصنوعی نیک‌تاز

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

اعتماد صفر، بدون شعار: از کجا شروع کنیم