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

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

سه گره‌ای که هر پروژه به آن‌ها می‌رسد

• دسترسی: اتکای معماری به سرویسی که ممکن است فردا در دسترس نباشد، ریسک عملیاتی است، نه دشواری اداری.
• داده: داده در بسیاری از شرکت‌ها وجود دارد، اما در فایل‌های پراکنده، دفترهای دستی و ستون‌های آزادِ نرم‌افزار مالی؛ میان «داشتن» و «قابل استفاده بودن» فاصله‌ای است که باید صرف شود.
• نیرو: بازار کار برای مهندس باتجربه رقابتی است و انگیزهٔ مهاجرت هم واقعی؛ سازمانی که همهٔ دانش را در یک نفر متمرکز کند، ریسک را انبار کرده است.

گرهٔ دسترسی: از دور زدن تا جایگزینی

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

گرهٔ داده: دشوارتر، اما ارزشمندتر

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

گرهٔ نیرو: نگه‌داشتن مهم‌تر از جذب است

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

فرصت‌هایی که تنها در همین بستر معنا دارد

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

یک نمونهٔ عملی

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

مسیر ۹۰ روزهٔ شروع

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

خطاهای رایج

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

پرسش‌های پرتکرار

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

جمع‌بندی

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

واژه‌نامه

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

اقدام این هفته

این هفته، یک جلسهٔ ۹۰ دقیقه‌ای با تیم فنی و مسئول فرآیند انتخاب‌شده ترتیب دهید و سه مورد را روی یک صفحه بررسی کنید: (۱) فهرست داده‌های موجود برای آن فرآیند و میزان ساخت‌یافتگی آن‌ها، (۲) نقاط اتکای فعلی به سرویس‌های خارجی و امکان جمع‌کردن آن‌ها در یک لایهٔ قابل تعویض، (۳) مستندسازی حداقل یک تصمیم معماری که تا امروز فقط در ذهن یک نفر بوده است. خروجی جلسه، یک سند یک‌صفحه‌ای با سه ستون «وضعیت فعلی»، «شکاف» و «اقدام بعدی» باشد. این سند را به تأیید مدیر فنی برسانید تا مبنای شروع ماه نخست مسیر ۹۰ روزه قرار گیرد.

منابع

• چارچوب حاکمیت داده؛ راهنمای عملی برای سازمان‌ها (ISACA)
• طراحی سیستم‌های یادگیری ماشین؛ فصل معماری قابل تعویض (O'Reilly)
• مدل‌های متن‌باز فارسی؛ فهرست به‌روز Hugging Face
• پردازش زبان طبیعی و چالش‌های زبان‌های راست‌به‌چپ (IBM Think)
• وضعیت هوش مصنوعی در سازمان‌ها؛ گزارش مکنزی ۲۰۲۴