توسعه محصولات تحت وب با هوش مصنوعی و بلاکچین

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

هوش مصنوعی (AI) در این بحث یعنی مدل‌هایی که ورودی را تحلیل می‌کنند و پیش‌بینی یا پاسخ می‌سازند. طبق تعریف نقل‌شده در توصیه‌نامه ITU-T Y.4227، بلاکچین (Blockchain) نوعی دفترکل توزیع‌شده با بلوک‌های مرتبط از طریق رمزنگاری و مقاوم در برابر دست‌کاری است. تمرکز بحث، معماری محصول و آزمون تصمیم‌های فنی است؛ نه آموزش سرمایه‌گذاری رمزارزی، انتخاب شبکه برای معامله یا دستور استقرار یک قرارداد مالی آماده.

کدام مسئله واقعاً به هوش مصنوعی و بلاکچین نیاز دارد؟

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

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

طبق مدل داده W3C، اعتبارنامه قابل‌راستی‌آزمایی (Verifiable Credential) مجموعه‌ای از ادعاهای صادرکننده با سازوکار محافظت در برابر دست‌کاری است. W3C برای ثبتگاه قابل‌راستی‌آزمایی گزینه‌هایی غیر از بلاکچین نیز در نظر می‌گیرد؛ بنابراین نیاز به اعتبارنامه، الزام به بلاکچین نیست. مثلاً در سامانه آموزش مهارت، ابتدا مشخص کنید دریافت‌کننده مدرک چه چیزی را باید بررسی کند: هویت صادرکننده، اعتبار مدرک یا توافق چند مؤسسه درباره سابقه صدور.

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

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

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

طبق چارچوب Microsoft Azure Well-Architected، استنتاج (Inference) یعنی اجرای مدل آموزش‌دیده برای تولید خروجی. راهنمای طراحی برنامه‌های هوش مصنوعی مایکروسافت، رابط کاربر، هماهنگی هوشمند، استنتاج، دانش و ابزارها را از هم تفکیک می‌کند و برای ابزارها سیاست امنیتی مستقل می‌خواهد. در طراحی محصول، برای هر لایه ورودی مجاز، خروجی مورد انتظار و مسئول خطا بنویسید؛ یک نمودار اتصال بدون این قراردادها برای بازبینی امنیت کافی نیست.

داده خصوصی را از ثبت مشترک جدا کنید

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

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

مسئول امضا را بیرون از اختیار مدل نگه دارید

قرارداد هوشمند (Smart Contract)، در تعریف نقل‌شده در توصیه‌نامه ITU-T Y.4227، منطق کدنویسی‌شده قواعد تراکنش است. در معماری پیشنهادی، مدل فقط اطلاعات مورد نیاز این منطق را پیشنهاد می‌دهد. سرویس برنامه باید هویت درخواست‌کننده، دامنه دسترسی و شرایط عملیات را کنترل کند؛ سپس مؤلفه امضاکننده فقط درخواست تأییدشده را بپذیرد. تأیید را به گیرنده، مبلغ، نوع عملیات و نسخه داده متصل کنید.

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

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

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

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

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

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

ثبت خروجی مدل با اثبات درستی پاسخ فرق دارد

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

در معماری پژوهش opML، خارج از زنجیره (Off-chain) یعنی محاسبه مدل بیرون از بلاکچین انجام شود. در همان پژوهش، روی زنجیره (On-chain) به ثبت نتیجه و اجرای سازوکار رسیدگی در بلاکچین اشاره دارد. طبق پژوهش opML، راستی‌آزمایی با امکان اعتراض نتیجه محاسبه را به سازوکار داوری قرارداد متصل می‌کند. اثبات تقلب (Fraud Proof) در این پژوهش سازوکاری برای نشان‌دادن نادرستی محاسبه ادعاشده در فرایند اختلاف است.

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

بازسازی محاسبه را از کیفیت مدل جدا بسنجید

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

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

خطاهای ورودی و انتظار کاربر را پیش از انتشار آزمایش کنید

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

داده خارجی را پیش از اجرای قواعد کنترل کنید

در راهنمای امنیت قرارداد هوشمند OWASP، اوراکل (Oracle) محل ورود داده خارجی به قرارداد است. طبق راهنمای OWASP درباره دست‌کاری اوراکل قیمت، داده کهنه، دست‌کاری قیمت یا پیکربندی نادرست قادر است رفتار قرارداد را منحرف کند. برای محصولی که نتیجه مدل را به اجرای قواعد وصل می‌کند، کنترل ورودی را مستقل طراحی کنید؛ تأیید ثبت تراکنش را نشانه سلامت منبع داده نگیرید.

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

سرعت صفحه را از زمان تکمیل عملیات جدا کنید

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

طبق راهنمای web.dev، Core Web Vitals مجموعه شاخص‌های سنجش بارگذاری، پاسخ‌گویی و پایداری دیداری صفحه است. LCP (بزرگ‌ترین ترسیم محتوایی) زمان نمایش بزرگ‌ترین محتوای قابل‌مشاهده را می‌سنجد و طبق web.dev، مرز وضعیت خوب آن حداکثر ۲٫۵ ثانیه است.

INP (تعامل تا ترسیم بعدی) پاسخ‌گویی صفحه به تعامل را می‌سنجد و طبق web.dev، مرز وضعیت خوب آن حداکثر ۲۰۰ میلی‌ثانیه است. CLS (جابه‌جایی تجمعی چیدمان) جابه‌جایی‌های غیرمنتظره عناصر را می‌سنجد و طبق web.dev، مرز وضعیت خوب آن حداکثر ۰٫۱ است. طبق web.dev، ارزیابی این شاخص‌ها باید در صدک ۷۵ بارگذاری‌ها و جداگانه برای موبایل و دسکتاپ انجام شود.

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

پذیرش معماری را به شواهد آزمون وابسته کنید

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

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

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

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

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