هوش مصنوعی در ایران — وضعیت زیرساخت و محدودیت‌ها

محدودیت‌ها را باید مثل مشخصات فنی دید

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

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

دسترسی و پرداخت

اولین قید، دسترسی پایدار به API‌های خارجی است. دو مسئله‌ی جدا اینجا با هم قاطی می‌شوند و بهتر است جدا نگه داشته شوند:

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

پیامد طراحی روشن است: هر کدی که به یک ارائه‌دهنده‌ی بیرونی وصل می‌شود باید از روز اول timeout صریح، retry با backoff، و مسیر جایگزین داشته باشد. اگر یک درخواست ناموفق به کاربر نهایی به شکل خطای خام برسد، مشکل از طراحی است نه از شبکه. اینکه کل منطق سیستم به فرض «API همیشه در دسترس است» نوشته شده باشد، پرهزینه‌ترین اشتباه رایج در این حوزه است.

تأخیر و اثر مرکب آن در ایجنت‌ها

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

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

چند تصمیم معماری که این اثر را کم می‌کند:

• کم کردن تعداد دورها. ابزارهای درشت‌دانه بهتر از ابزارهای ریزدانه‌اند وقتی هر فراخوانی یک رفت‌وبرگشت بین‌المللی است. طراحی خوب ابزار را در function calling بیشتر توضیح داده‌ایم.
• موازی‌سازی جایی که ترتیب لازم نیست. اگر مدل می‌تواند چند ابزار مستقل را هم‌زمان صدا بزند، تأخیرها روی هم جمع نمی‌شوند.
• استریم کردن خروجی. تأخیر تا اولین توکن را کاربر حس می‌کند؛ زمان کل تولید را کمتر.
• کش کردن هر چیز تکراری. بخش ثابت prompt، نتیجه‌ی جست‌وجوها، embedding اسناد. prompt caching دقیقاً برای همین است.

کشش به سمت استقرار محلی

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

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

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

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

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

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

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

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

چه چیزی از این قیدها در می‌آید

اگر بخواهیم این چهار قید را به یک الگوی معماری ترجمه کنیم، چیزی شبیه این می‌شود:

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

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