مهندسی داده و مدل بدون مشاهدهٔ دادهٔ محرمانه

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

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

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

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

شناخت داده را از دیدن مصداق جدا کنیم

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

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

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

قرارداد داده؛ چیزی بیشتر از فهرست ستون‌ها

شمای داده یا Schema مشخص می‌کند چه فیلدهایی با چه نوع و ساختاری وجود دارند. قرارداد داده باید توضیح دهد این فیلدها چه معنایی دارند، چگونه تولید می‌شوند، چه کیفیتی از آن‌ها انتظار می‌رود و در صورت نقض انتظار چه اتفاقی می‌افتد. یک فیلد عددی با نام temperature بدون واحد، محل حسگر و معنای زمان ثبت، برای مهندسی قابل اتکا نیست.

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

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

پروژهٔ Open Data Contract Standard نمونه‌ای از صورت‌بندی ماشین‌خوانِ شِما، کیفیت، مسئولیت و سطح خدمت است. در معرفی نسخهٔ ۳٫۱٫۰، رابطهٔ میان فیلدها و زمان‌بندی بررسی تعهدهای سطح خدمت نیز برجسته شده است. استفاده از چنین قالبی، به‌خودی‌خود کنترل امنیتی را اجرا نمی‌کند؛ قرارداد باید به آزمون و تصمیم پذیرش متصل شود.

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

محیط توسعه به کدام داده نیاز دارد؟

دادهٔ عمومی، دادهٔ آزمایشی و دادهٔ مصنوعیِ آموخته‌شده از منبع محرمانه، سه چیز متفاوت‌اند.

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

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

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

در صورت استفاده از حریم خصوصی تفاضلی، واحد حفاظت، حدود مشارکت هر واحد، پارامترها و حسابداری انتشارهای مرتبط باید مشخص باشند. حفاظت از «یک ردیف» با حفاظت از «یک شخص با هزار ردیف» یکسان نیست. راهنمای نهایی NIST SP 800-226، منتشرشده در ۶ مارس ۲۰۲۵، دقیقاً برای ارزیابی معنای چنین تضمین‌هایی و خطرهای پیاده‌سازی آن‌ها تدوین شده است. حریم خصوصی تفاضلی نیز لزوماً اسرار جمعی سازمان، مانند ظرفیت تولید یا الگوی عملیاتی یک مجموعه، را پنهان نمی‌کند.

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

تحول تازه‌تر نیز همین احتیاط را تقویت می‌کند. پیش‌چاپ «آیا برای این کار باید از دادهٔ مصنوعی استفاده کنم؟» در ۳ فوریهٔ ۲۰۲۶ کاربردهای اشتراک‌گذاری و افزایش داده را از هم جدا کرده و محدودیت‌های تناسب روش با مسئله را بررسی می‌کند. برداشت مهندسی برای این بحث روشن است: دادهٔ مصنوعی می‌تواند رابط توسعه باشد، اما جای آزمون نهایی روی دادهٔ واقعی را نمی‌گیرد.

پروفایل آماری، یک محصول کنترل‌شده است

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

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

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

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

تشخیص کیفیت و سوگیری، بدون نمایش رکورد خام

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

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

جدول زیر، طراحی پیشنهادی این رابط شواهد است؛ نه تضمین آمادهٔ یک محصول خاص:

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

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

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

برچسب‌گذاری و ارزیابی باید از مدل استقلال داشته باشند

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

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

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

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

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

عیب‌یابی باید داخل مرز طراحی شود

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

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

گزارش خطا، نام فایل، stack trace و core dump بی‌خطر فرض نمی‌شوند. حتی شناسهٔ مبهمِ پایدار می‌تواند پیوند گزارش‌های متعدد را ممکن کند. دادهٔ خام تشخیصی، اگر نگهداری آن ضروری و مجاز باشد، در مرز امن با عمر محدود می‌ماند. در مدل تهدید سخت‌گیرانه‌تر، زمان اجرا، اندازهٔ نتیجه و نوع توقف نیز مسیر بالقوهٔ انتقال اطلاعات‌اند.

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

مشاهدهٔ انسانی، استثنایی با مرز روشن

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

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

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

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

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

از تعریف مسئله تا بستهٔ توسعه

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

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

اجرای واقعی و ساخت برچسب

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

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

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

آموزش، اعتبارسنجی و آزمون مستقل

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

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

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

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

تحویل و نگهداری، بدون بازشدن مسیر داده

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

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

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

این سناریو کجا ممکن است متوقف شود؟

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

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

آنچه تجربهٔ عملی تأیید می‌کند؛ و آنچه نمی‌کند

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

محدودیت روز این مثال اهمیت بیشتری دارد: سیاست روش‌های تحلیلی، به‌روزشده در ۲۴ ژوئیهٔ ۲۰۲۶، روش‌هایی مانند شبکه‌های عصبی، جنگل تصادفی، گرادیان‌بوستینگ و مدل‌های زبانی را در فهرست روش‌های پشتیبانی‌نشدهٔ بررسی افشا قرار می‌دهد. اجرای آن‌ها بدون مجوز استثناییِ قبلی مجاز نیست، حتی اگر قرار نباشد فایل مدل خارج شود. این محدودیت را نمی‌توان به ناممکن‌بودن ریاضی این روش‌ها تعمیم داد؛ سیاست، ظرفیت محاسباتی، امکان بررسی خروجی و خطرهای حریم خصوصی را نیز در نظر می‌گیرد. اما نمی‌توان OpenSAFELY را شاهد آماده‌بودن هر نوع آموزش محرمانه معرفی کرد.

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

معیار موفقیت، حذف نیاز است؛ نه صرفاً حذف مجوز

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

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

در این صورت‌بندی از ZTAI، انسان از مسئولیت کنار نمی‌رود. مسئولیت او از اصلاح دستی مصداق‌ها به طراحی قواعد، سنجش شواهد و تعیین حدود کاربرد منتقل می‌شود. معماری موفق باید هم نشان دهد چه دانشی برای انجام کار به انسان می‌رساند و هم توضیح دهد چرا آن دانش، بیش از مجوز تعیین‌شده چیزی از دادهٔ محرمانه آشکار نمی‌کند.

مسیر پیشنهادی مطالعه

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

مکمل مستقیم این یادداشت، «وقتی انسان داده را نمی‌بیند؛ آیا واقعاً دسترسی او حذف شده است؟» است: آن مقاله مسیرهای غیرمستقیم دسترسی را بررسی می‌کند و این متن، ابزار لازم برای ادامهٔ مهندسی پس از محدودکردن آن مسیرها را. فصل‌های منتشرشدهٔ مجموعه نیز در راهنمای ZTAI در دسترس‌اند.