برای هوش مصنوعی سازمان، مدل بومی بخریم یا اول داده و زیرساخت را اصلاح کنیم؟

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

این تصمیم برای سازمان‌های بزرگ‌تر هزینه‌ی اشتباه بالایی دارد. اگر زودتر از موعد سراغ مدل بروید، ممکن است بعداً مجبور شوید هم مدل را عوض کنید، هم داده را پاک‌سازی کنید، هم مسیرهای عملیاتی را بازنویسی کنید.

چرا این تصمیم در سازمان ایرانی به‌سادگیِ خرید یک ابزار نیست

در سازمان‌های فارسی‌زبان، مسئله فقط «مدل» نیست. داده‌ها معمولاً در چند سامانه‌ی داخلی، فایل‌های اکسل، اتوماسیون اداری، ERPهای بومی و گزارش‌های دستی پخش شده‌اند. اگر این داده‌ها یکدست، قابل‌ردیابی و قابل‌دسترسی نباشند، ارزیابی هر مدل می‌تواند خوش‌بینانه و گمراه‌کننده شود ^[۱].

از طرف دیگر، در بسیاری از پروژه‌ها فرایند تصمیم‌گیری مستند نیست. یعنی حتی اگر مدل روی کاغذ خوب به‌نظر برسد، معلوم نیست خروجی قرار است در کدام مرحله تأیید انسانی بگیرد، چه کسی مسئول خطاست، و چه لاگی برای بازبینی باقی می‌ماند. چارچوب‌های رسمی مدیریت ریسک هم دقیقاً روی همین نکته تأکید دارند: حاکمیت، پایش و مسئولیت‌پذیری باید هم‌زمان با طراحی و استقرار دیده شوند، نه بعد از آن ^{[۲، ۳]}.

اگر این پایه‌ها آماده نباشد، مدل بومی لزوماً انتخاب مناسب‌تری از مدل عمومی نیست. گاهی مسئله‌ی اصلی نه انتخاب مدل، بلکه اصلاح داده، فرایند و زیرساخت است ^{[۴، ۵]}.

سه معیار که قبل از خرید مدل باید جداگانه بسنجید

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

برای تیم فنی

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

سناریوی فرضی: وقتی سه گزینه روی میز است

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

حالا این سه گزینه را با همان سه معیار بالا می‌سنجیم:

• اگر داده‌ها در چند سامانه پخش‌اند، برچسب‌ها یکسان نیستند، و لاگ‌ها کامل نیستند، خرید مدل بومی در قدم اول ریسک خطای ارزیابی را بالا می‌برد ^[۱].
• اگر مسئله‌ی اصلی شما پاسخ‌گویی به متن‌های عمومی است و داده‌ی حساس وارد جریان نمی‌شود، مدل عمومی با کنترل دسترسی و سیاست‌نامه‌ی روشن می‌تواند شروع کم‌اصطکاک‌تری باشد ^{[۲، ۳]}.
• اگر داده‌ی قابل‌اعتماد ندارید، دسترسی‌ها کنترل نشده‌اند، و زیرساخت پایدار برای اجرا و پایش ندارید، اولویت با اصلاح داده و زیرساخت است؛ چون در غیر این صورت، هر مدل جدیدی روی پایه‌ی ناپایدار سوار می‌شود ^{[۴، ۵]}.

این جدول تصمیم را ساده می‌کند: شما به‌جای پرسیدن «کدام مدل بهتر است؟» می‌پرسید «کدام گلوگاه الان مانع ارزش‌آفرینی است؟»

چه زمانی مدل بومی، چه زمانی مدل عمومی، و چه زمانی اصلاح پایه‌ها

اگر داده‌ی شما حساس است، مسیرهای خروج داده باید محدود باشد، و استفاده از سرویس بیرونی با سیاست‌های امنیتی شما نمی‌خواند، مدل بومی می‌تواند گزینه‌ی قابل‌بررسی باشد؛ اما فقط وقتی که داده و زیرساخت هم آماده باشند ^{[۲، ۴]}.

اگر مسئله‌ی شما عمومی‌تر است، داده‌ی حساس وارد نمی‌شود، و هدف شما آزمودن سریع یک کاربرد مشخص است، مدل عمومی با کنترل انسانی و محدودیت دسترسی می‌تواند شروع منطقی‌تری باشد. این انتخاب به‌معنای «کم‌اهمیت بودن» حاکمیت نیست؛ برعکس، چارچوب‌های رسمی می‌گویند مدیریت ریسک باید از همان ابتدا طراحی شود ^{[۲، ۳]}.

اگر هنوز نمی‌دانید داده‌ها کجا هستند، چه کسی مالک آن‌هاست، و خروجی مدل قرار است در کدام فرایند مصرف شود، اول باید داده و زیرساخت را سامان دهید. در این وضعیت، خرید مدل بومی معمولاً فقط تصمیم را جلو می‌اندازد، نه مسئله را ^{[۴، ۵]}.

پیش‌نیازهای واقعی برای یک پایلوت کوچک

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

داده‌ی لازم معمولاً شامل نمونه‌های واقعی از همان فرایندی است که می‌خواهید بهبود دهید؛ مثلاً نامه‌ها، تیکت‌ها، صورت‌جلسه‌ها یا رکوردهای پشتیبانی. اما مهم‌تر از حجم داده، کیفیت و قابلیت ردیابی آن است ^{[۱، ۶]}.

معیار موفقیت هم نباید فقط دقت مدل باشد. باید ببینید آیا زمان پاسخ کم شده، آیا خطای انسانی کمتر شده، آیا تأییدکننده‌ی انسانی هنوز می‌تواند خروجی را بازبینی کند، و آیا ریسک عملیاتی قابل‌قبول مانده است یا نه ^{[۲، ۳]}.

ریسک‌ها و اشتباه‌های رایج در این تصمیم

• اشتباه گرفتن «بومی» با «امن»: مدل بومی لزوماً امن‌تر نیست. اگر کنترل دسترسی، ثبت رویداد و سیاست نگه‌داری ندارید، صرف بومی‌بودن ریسک را حذف نمی‌کند. پیشگیری: سیاست دسترسی، لاگ‌برداری و بازبینی را قبل از استقرار تعریف کنید ^{[۲، ۴]}.
• نشت داده و دسترسی بیش‌ازحد: اگر داده‌های حساس، برچسب‌ها یا لاگ‌ها بدون کنترل در اختیار تیم‌ها یا ابزارهای بیرونی قرار بگیرند، هم حریم داده آسیب می‌بیند و هم ارزیابی مدل آلوده می‌شود ^{[۱، ۲]}. پیشگیری: سطح‌بندی دسترسی، جداسازی محیط آزمایش و تولید، و ثبت رویداد را از ابتدا اجرا کنید.
• خرید مدل قبل از پاک‌سازی داده: اگر داده‌ها نشت دارند یا برچسب‌ها و لاگ‌ها ناقص‌اند، ارزیابی مدل می‌تواند بیش‌ازحد خوش‌بینانه شود ^[۱]. پیشگیری: یک ارزیابی کوچک روی داده‌ی تمیز و جداگانه انجام دهید و نشت را صریح بررسی کنید.
• نادیده گرفتن فرایند انسانی: اگر معلوم نباشد چه کسی خروجی را تأیید می‌کند، مدل در عمل وارد فرایند می‌شود بدون اینکه مسئولیتش روشن باشد ^{[۲، ۳]}. پیشگیری: «انسان در حلقه» را از ابتدا تعریف کنید.
• اتکا به زیرساخت ناپایدار: اگر محیط اجرا، مانیتورینگ و پشتیبان‌گیری ندارید، حتی مدل خوب هم در بهره‌برداری مشکل‌ساز می‌شود ^{[۴، ۵]}. پیشگیری: پیش از خرید، وضعیت استقرار، پایش و بازیابی را بررسی کنید.
• ارزیابی با داده‌ی آلوده به آموزش: اگر همان داده‌ای که برای ساخت استفاده شده، برای سنجش هم به‌کار برود، نتیجه قابل اتکا نیست ^[۱]. پیشگیری: مجموعه‌ی ارزیابی جدا و مستند داشته باشید.

چک‌لیست شروع: هفت قدم از فردا

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

جمع‌بندی: اول گلوگاه را پیدا کنید، بعد مدل را انتخاب کنید

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