از زمانی که مدل‌های هوش مصنوعی متنی یا همان مدل‌های بزرگ زبانی (Large Language Model) مثل ChatGPT ارائه شدند، همیشه یک مشکل بزرگ داشتند، این که زبان‌نفهم بودند! در واقع این زبان نفهمی در مدل‌های کوچک‌تر مثل مارال شاید بیش‌تر دیده می‌شد اما منظور و مقصود این مطلب، هذیان‌گویی یا درک نکردن مطالب ورودی نیست، بلکه عدم درک درست از ابزارهاییه که به خورد مدل‌ها داده میشه. این مساله، در ابتداء با عوامل هوش مصنوعی یا همان ایجنت‌ها حل شد. ساخت یک ایجنت کار بسیار ساده‌ایه و خب این موضوع اینجا پوشش داده شده و می‌تونید اون رو بخونید.

اما در سال گذشته شرکت Anthropic که سازنده مدل Claudeئه ابزاری ارائه کرد به اسم MCP که باید ببینیم چیه و چطور کار می‌کنه. در این پست، تمام تلاشم اینه که به ساده‌ترین زبان ممکن، MCP Serverها و این که چطور مشکل زبان‌نفهمی رو حل کردند رو برای شما توضیح بدم چون تا جایی که گشتم مطالب فارسی خوبی در موردش نبود یا اگر هم بود، در صفحات اینستاگرامی و تلگرامی بود که در وب قابل دسترسی نیستند.

اصلا MCP چیه و چطور کار می‌کنه؟

خب این یک سوال خیلی مهمه. ابتدا باید ببینیم MCP یعنی چی و چطور کار می‌کنه و چرا انقدر مهمه. پس اول بیایید یک فرض داشته باشیم. این فرض ممکنه خیلی شبیه به تست اتاق چینی (یکی از تست‌های مطرح و مشهور هوش مصنوعی) به نظر بیاد و خب تا حد زیادی همونه. اول اتاق چینی رو توضیح میدم و بعد یک مثال ملموس‌تر می‌زنم و بعد می‌ریم سراغ ادامه ماجرا.

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

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

حالا MCP دقیقا همینه، یک راهنماست که مدل هوش مصنوعی بتونه از اتاق چینی بیاد بیرون. چطوری؟ با کمک Context. در واقع اسمش روشه Model Context Protocol یا «شیوه‌نامه متن مدل». و حتی چیز خیلی جدیدی هم نیست، فقط یک روش متفاوت از روش‌های پیشینه که برای اجرای ایجنت‌ها داشتیم.

ساز و کار  MCP زیر ذره‌بین

به جای این که این قسمت رو با دیاگرام‌های غیرقابل فهم پر کنم، خیلی ساده در مورد یک مساله فرضی توضیح می‌دم و MCP رو بیشتر می‌شکافم.

اول از همه، اگر دقت کنید اکثر MCP ها عنوان Server رو یدک می‌کشن، یعنی یک خدمتی ارائه میدن. پس کلاینت ما اینجا، خود مدل هوش مصنوعیمونه. مثلا Claude, ChatGPT یا حتی مدلی که توسط Ollama داریم روی کامپیوتر شخصیمون ران می‌کنیم.

یک سناریوی فرضی داریم. مثلا شما می‌خواهید از جایی مثل «اسنپ‌فود» سفارش ثبت کنید. وارد رابط هوش مصنوعی می‌شید و بهش می‌گید «برای من از رستوران X یک کارامل ماکیاتو ۱۰۰٪ عربیکا سفارش بده».

حالا چه اتفاقاتی در پشت صحنه رخ می‌ده؟

• اول، MCP Server لیست ابزارهای خودش رو برمی‌گردونه. اینجا می‌تونه list_cafes باشه، می‌تونه get_order باشه و … . هرکدوم از این ابزارها، همراه یک توضیح ریزی بر می‌گردند. شبیه به چیزی که در Open API یا همون Swagger داریم.
• اینجا مطابق ابزارها و توضیحاتشون، مدل ما باید درخواست رو بشکنه. پس چه کار می‌کنه؟
  • طبق پرامپت اولیه ما، اسم رستوران رو تشخیص میده و منوش رو از ابزار مورد استفاده، دریافت می‌کنه.
  • با ابزار جست و جو در منو، درک می‌کنه آیا کارامل ماکیاتو به صورت ۱۰۰ عربیکا موجود دارند یا نه. ممکنه اینجا از ابزار «بررسی موجودی» هم استفاده کنه.
  • در صورت موجود بودن، ممکنه به ما بگه موجوده و قیمتش ۱۰۰ هزار تومان به ازای هر فنجانه. ۲۰ هزار تومان هم هزینه ارسالش به آدرس شماست.
  • اینجا شما می‌گید «بسیار عالی سفارش رو ثبت کن».
  • بعد اینجا، ابزار ثبت سفارش رو صدا می‌زنه. بعد از اون، به شما یک سفارش تایید نشده میده، همراه لینک پرداخت. بعد از پرداخت شما، احتمالا یک ریکوئست دیگه میره سمت سرور که چک کنه پرداخت شده یا نه. حتی اینجا ممکنه شماره پرداخت و … هم از شما دریافت بشه که با ابزار متناسب، چک کنند آیا این پرداختی انجام شده که سفارش انجام شه یا خیر.
  • بعد از اون شما صرفا با «چت کردن» می‌تونید از وضعیت سفارشتون آگاه شید.
• پس از این، هربار بخواهید سفارشی ثبت کنید، یک MCP بین شما و اسنپ‌فود هست که سفارشتون رو مثل سابق (زنگ زدن به رستوران و درخواست یک سفارش خاص) ثبت و پردازش کنه.

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

مزایا و معایب MCP ها

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

مزایای MCPها

• استانداردسازی ارتباط با ابزارها: از اونجایی که MCP یک پروتکل یا شیوه‌نامه به حساب میاد، میشه گفت که همه چیز رو به شکل استانداردی درمیاره. پس این موضوع، موضوع مهم و حائز اهمیتی خواهد بود. در واقع می‌دونیم که یک استاندارد جامع داریم که مدل‌های زبانیمون بتونن بفهمنشون.
• کنترل بهتر روی جریان داده: از اونجایی که وظیفه اصلی مدل زبانی ما میشه تبدیل محتوای «قابل خواندن برای انسان» یا Human Readable به محتوای «قابل خواندن برای کامپیوتر» یا Machine Readable (محتوایی مثل XML, JSON, YAML و …) کنترل بهتری روی جریان داده‌ها هم خواهیم داشت. در واقع می‌تونیم اینجا داده‌های ورودی کاربر رو هم ذخیره کنیم و مورد بررسی قرار بدیم (طبیعتا با اطلاع کاربر).
• مقیاس‌پذیری: یکی از بزرگترین گلوگاه‌های بیزنس‌های هوش مصنوعی، همیشه مقیاس‌پذیری نسبتا پایینیه که دارند. تقریبا هرجایی که مانی رو پرزنت می‌کردم، بعد از این سوال کلیشه‌ای مسخره که با میدجرنی چه فرقی داره می‌پرسیدند شما چطوری اسکیل می‌کنید؟ خب MCPها این مساله رو هم حل می‌کنند. در واقع می‌تونن برای چند مدل، چندین و چند کاربر و … همزمان کار کنند و مشکلات مرتبط رو به راحتی کاهش بدن.

معایب MCPها

• پیچیدگی در پیاده‌سازی اولیه: از اونجایی که میشه MCPها رو نوعی از IaC یا Infrastructure as Code دونست، میشه گفت این مشکل جهان‌شمول پیاده‌سازی اولیه طولانی رو همه ابزارهای این‌چنینی دارند. حداقل روی خوب ماجرا اینه که این کار «فقط یک بار» انجام داده میشه و بعدش نیاز به تکرار مکررات نیست.
• وابستگی به کیفیت مدل: طبیعتا مدلی مثل Gemma 27B با مدلی مثل OpenAI GPT 5 در کیفیت یکسان نیست و باید این رو هم خودتون و هم مشتری‌های احتمالیتون در نظر بگیره. حالا باز با استفاده از مدل‌های بزرگتر، این مشکل تا حد زیادی پوشش داده میشه. یعنی رفتن سمت مدلی مثل GLM یا Kimi K2 یا DeepSeek V3.1 و …، این مسائل رو می‌تونیم تا حد بسیار خوبی حل کنیم.
• استفاده زیاد از توکن: در نهایت، از اونجایی که هربار مدل رو در نقش «کلاینت» قرار می‌دیم، تعداد زیادی توکن مصرف میشه که البته این موضوع هم تا حد خیلی خوبی، توسط شرکت‌هایی مثل Cloudflare یا حتی خود آنتروپیک، در حال حل شدنه که در آینده نه چندان دور در موردش خواهم نوشت.

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

سخن پایانی

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

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

مدت زیادی می‌شد که هرجا برای جذب سرمایه یا حتی حمایتی برای پلتفرم هوش مصنوعی مانی می‌رفتم، سوال اصلی این بود «چرا یک API از دالی یا میدجرنی نمی‌گیری خودتو راحت کنی؟» و حتی با این که خیلی هم حرف بی‌راهی نیست و تولیدکننده تصویر چیز خاصی نیست که بابت دیتا بخواهیم نگرانی بزرگی داشته باشیم، پاسخ‌های متعددی می‌دادم.

و خب طبیعیه که در طی چند سال گذشته سرویس‌های زیادی مانند اول‌ای‌آی اومدند که به شما امکان ساخت wrapper روی APIهای مدل‌های زبانی و تصویری متعددی رو میدن. در این مطلب، میخواهیم یک بررسی جامعه داشته باشیم که چرا این API wrapper ها می‌تونن ما و کسب و کارمون رو به ته دره هدایت کنند 🙂

اصلا API Wrapper یعنی چی؟

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

فعل wrap در زبان انگلیسی یعنی چیزی که به چیز دیگر احاطه پیدا می‌کنه و اون رو می‌پوشونه. یعنی ما ابزاری بسازیم که در واقع فقط فرانت‌اند یک API معروف (مثل OpenAI) باشه.

حالا خیلی‌ها این API رو مستقیم از OpenAI یا DeepSeek یا MiniMax تهیه می‌کنند، یا از واسطه‌های خارجی مثل UseAPI و OpenRouter و یا این که از واسطه داخلی مثل اول‌ای‌آی و لیارا.

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

چرا ساخت API Wrapper ایده خوبی نیست؟

در اینجا مواردی رو میارم که ساخت API Wrapper ایده خوبی نیست. شاید در پستی در آینده، مواردی رو برشمردم که اتفاقا می‌تونه ایده خوبی هم باشه.

در حال حاضر، تمرکز ما روی اون دوستانیه که با API دمو می‌کنند و مدعی میشن مدل خودشونه و این داستانا که اتفاقا عمدتا هم وقتی به سیستم‌های Air Gap یا لوکال میان، تازه مشخص میشه دموشون چقدر دروغ و دغل بوده.

خلاقیت رو ازمون می‌گیره

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

اینجا، اگر خودم دست به Google Colab و Stable Diffusion نمی‌بردم، قاعدتا امکان این که بتونم پروسه میدجرنی رو تا حد زیادی مهندسی معکوس کنم، وجود نداشت.

جریان داده دست خودمون نیست

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

یا اگر هم سراغ API ها می‌رین، برید سراغ خود تامین‌کننده‌های رسمی. به جز خود OpenAI و Anthropic و DeepSeek معمولا Open Router و Together AI هم جزء تامین‌کنندگان رسمی مدل‌های زبانی هستند. همچنین Fal AI, Runware و Replicate هم جزء تامین‌کنندگان رسمی مدل‌های ویدئویی و تصویری هستند و می‌تونید از این دوستان هم API رو تهیه کنید.

آفلاین نیست

آخرین و شاید یکی از مهم‌ترین ارکان APIها – بخصوص برای مایی که در ایران زندگی می‌کنیم – این موضوعه. این موضوع یک عیب بزرگه و خب میشه با ابزارهایی مانند Ollama تا حدی از پسش بر اومد.

چطور ممکنه API Wrapper به کشتنمون بده؟

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

• تعطیلی ارائه‌دهنده
• قطع و وصل شدن API (چیزی که بخصوص در APIهای واسط مثل اول‌ای‌آی کاملا پیش میاد)
• هک شدن API و لو رفتن دیتا
• ارسال دیتا به واسطه‌هایی که ازشون مطمئن نیستیم
• عدم کنترل روی محصول وقتی اینترنت با مشکل مواجه می‌شه.

ممکنه مشکلات دیگری هم در میان باشه، اگر شما هم چیزی به ذهنتون رسید می‌تونید همینجا در بخش نظرات بهم بگید.

جمع‌بندی

در کل API Wrapper نوشتن برای پروژه‌های عام‌منظوره، کار عجیب و بدی نیست و خب هزینه خروج و شکست رو به وضوح کمتر می‌کنه، در حالی که برای انجام کار جدی و حساس، گزینه مناسبی نیست. اگر هرکدوم از معایبی که برشمرده شد رو تونستید برطرف کنید، احتمالا گزینه مناسبی برای شما، پروژه یا کسب و کارتونه؛ در غیر اینصورت باید کمی Local تر فکر کنید.

در نهایت، ازتون ممنونم که وقت گذاشتید و این مطلب رو خوندید. باز هم اگر نظر و پیشنهادی پیرامونش داشتید، ممنون میشم در بخش نظرات همین بلاگ یا بخش گفتگوی کانال تلگرام به من بگید.

مدتی پیش، پروژه‌های مختلفی مثل مارال یا جبیر رو با هدف انتشار و ساخت یک مدل زبانی بزرگ با همون LLM (مخفف Large Language Model) شروع کرده بودم اما بحث این مدل‌ها و شاید همزمان شدن انتشار این‌ها با نسخه‌های جدیدی از پلتفرم‌های مانی و آتلیه، کمی باعث شده بود که از هدف اصلی دور بشیم.

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

اما هرمز شد بخشی از یک پروژه بزرگتر، چرا که کمی دقت به بزرگان این حوزه، نشون از این بود که تقریبا همه شرکت‌های خوب و موفق در این حوزه، به جای این که «یک مدل» منتشر کنند «یک خانواده مدل» منتشر کردند که خب باید از این قضیه تا حدی الگوگیری می‌شد.

تصمیم به ساخت یک خانواده از مدل‌ها

از تولیدکنندگان بزرگ و تجاری مدل‌های جنریتیو که بگذریم، بسیاری از شرکت‌هایی که مدل‌های اوپن سورس تولید می‌کنن و نام‌داران این عرصه هم هستند (مثل Alibaba Cloud, DeepSeek, Mistral و حتی Meta) عموما به یک عدد مدل کفایت نمی‌کنند.

مدل‌هایی که این شرکت‌ها تولید می‌کنند عموما در یک «خانواده» قرار داره و این خانواده هم بر اساس تعداد پارامتر، توانایی استنتاج (یا همون Reasoning) توانایی بینایی ماشین (یا همون vision) و …، تعیین می‌شن. برای مثال یکی از مدل‌های معروف این حوزه که LLaMA نام داره و توسط شرکت متا ساخته شده، معمولا در یک نمونه کوچک (۷ یا ۸ میلیارد پارامتری)، یک نمونه متوسط (۱۱ یا ۱۳ پارامتری) و نمونه‌های بزرگ (۷۰ میلیارد پارامتر و بیشتر) تولید میشه.

اما خب یک مورد دیگری هم که به چشمم خورد، کاری بود که DeepSeek با R1 کرده بود. در واقع اومده بودن مدل‌های کوچکتر (از یک و نیم میلیارد تا هفتاد میلیارد پارامتر) رو با روش Distillation درست کرده بودند.

در واقع مدل‌هایی مثل LLaMA, Qwen, Mistral و … رو با داده‌هایی که از مدل دیپ‌سیک ۶۷۱ میلیارد پارامتری به دست آورده بودند، مجدد آموزش دادند که در اختیار افراد بیشتری قرار بگیره.

همین موضوع، باعث شد که به این فکر بیفتیم که در سال ۱۴۰۴ به جای این که هفته‌ای یک LLM ریلیز کنیم 😁 یک خونواده خوب از LLMها برای تمام فصول ریلیز کنیم که باز هم از DeepSeek V3 و ترین‌ کردن QLoRA و مرج کردن روی اون شروع شد.

اسم Xei از کجا میاد؟

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

ریاضیدانان ایرانی مثل خوارزمی، موقعی که معادلات خاصی رو حل می‌کردند از عبارت «شیء» بعنوان مجهول استفاده می‌کردند. وقتی اروپایی‌ها آثار این دانشمندان رو به زبان‌های خودشون ترجمه کردند، درک کردند که این «شیء» در واقع مجهوله و به جای این که Object (یا چیزی معادلش) ترجمه‌ش کنند، برای حفظ حالت مجهولش از عبارت xei استفاده کردند که بعدا شد xای که در معادلات مختلف استفاده می‌کنیم.

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

اما حالا مدل‌ها چی هستند؟ چرا انقدر این خونواده از مدل‌ها مهم بود؟

اهمیت خانواده مدل Xei

یکی از دلایل اصلی ساخته شدن Xei این بود که این مدل‌ها بتونن هم روی دستگاه‌های کاربر نهایی مثل من و شما اجرا شن هم روی زیرساخت‌های بزرگ و صنعتی.

در واقع هم تعدادی مدل On Device داشته باشیم و هم تعداد زیادی مدل برای استفاده Enterprise و به همین خاطر ۷ تا مدل در این خونواده، قرار گرفته که در ادامه بررسی می‌کنیم.

مدل‌های Xei

• مدل ۰.۱ میلیارد پارامتری، مبتنی بر لاماست و صرفا زبان انگلیسی می‌فهمه و می‌تونه در کارهایی مثل کدنویسی به شما کمک کنه.
• مدل ۰.۵ میلیارد پارامتری، مبتنی بر Qwen ساخته شده. با این که از دیتای چندزبانی درش استفاده شده ولی بهترین عملکرد رو روی انگلیسی داره و همچنان برای کارهایی مثل کدنویسی و نوشتن ایمیل، مناسبه.
• مدل ۲ میلیارد پارامتری که مبتنی بر Gemma 2 ساخته شده و محمد شجاعی عزیز زحمت ساختش رو کشیده، اولین مدلیه که به خوبی فارسی رو درک می‌کنه و می‌تونه به زبان فارسی به شما پاسخ‌های درست بده.
• مدل ۸ میلیارد پارامتری که در واقع همون هرمز قدیمی خودمونه و مبتنی بر Command-R از Cohere ساخته شده.
• مدل ۳۲ میلیارد پارامتری که باز هم مبتنی بر Command-R ساخته شده و نتایج بهتر و دقیق‌تری می‌تونه تولید کنه.
• مدل ۱۰۰ میلیارد پارامتری که باز هم مبتنی بر Command-R ساخته شده 😁
• و در نهایت مدل ۶۷۱ میلیارد پارامتری که مبتنی بر DeepSeek V3 ساخته شده و از معماری MoE بهره می‌بره.

و خب همونطوری که می‌بینید، تا مدل ۸ میلیارد پارامتری به سادگی روی اکثر رایانه‌های شخصی حتی بدون کارت گرافیک NVIDIA قابل اجراست ولی نمونه ۳۲ و ۱۰۰ و ۶۷۱ نیاز به منابع بیشتری دارند که در ادامه به اون‌ها هم می‌پردازیم.

چطوری به Xei دسترسی پیدا کنیم؟

اگر می‌خواهید مستقیما به سمت مدل ۶۷۱ میلیارد پارامتری بریم، کافیه که به این سرویس برید، یک حساب کاربری بسازید و شروع به چت کنید.

ولی اگر دوست دارید که این مدل رو روی سیستم شخصی خودتون اجرا کنید، می‌تونید از کتابخونه Ollama نسخه مناسب رو دانلود کنید (با کارت ۲۰۵۰ تا مدل ۳۲ میلیاردی قابل اجراست، گرچه بهترین نتیجه مربوط به همون ۸ میلیاردیه).

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

جمع‌بندی و سخن آخر

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

اما کل داستان این نیست و به زودی با سورپرایزهای جدید‌تری، در خدمت شما خواهیم بود. امیدوارم تا اون موقع با Xei کارهای خفنی کرده باشید 😎

پاییز دو سال پیش بود که ChatGPT آمد و به شکل خاصی بازار همه چیز رو عوض کرد یا بهتره بگم که به هم ریخت 😁 در این مدت نه فقط OpenAI که هزاران شرکت دیگر هم دست به کار شدند و شروع کردند به ارائه مدل‌های زبانی بزرگ یا همون LLMها و خواستند که به شکلی با OpenAI رقابت کنند.

الان که دو سالی از اون روزها گذشته منتها موضوع کمی تفاوت داره و بیش از این که سمت ارائه مدل بریم، بهتره به سمت agent یا «عامل» بریم که خب خودش یک بحث مفصله.

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

ایجنت‌ها، عملگرایی به LLMها اضافه می‌کنند.

اگر دنبال‌کننده بلاگ و در کل محتوای من باشید، احتمالا می‌دونید که من هم در بازی LLM بودم و مثلا یکی از LLMهای اوپن سورسی که روش کار کردم مدل مارال هفت میلیارد پارامتری بود که روی Alpaca Persian تمرین داده شد.

اما آیا یک مدلی که سوال-جواب کنه کافیه یا به چیزی بیشتر نیاز داریم؟ در واقع برای این که LLMها بتونن موثر واقع بشن، باید بتونن با ابزارهای مختلف تعامل کنند. حالا شما فرض کنید که بخواهیم این تعامل رو در سطح فاین‌تیون کردن، به مدل اضافه کنیم.

یعنی فرض کنید که ما APIهایی از دیجی‌کالا، اسنپ، دیوار و مثلا ابر آروان بگیریم. سعی کنیم با کمک تعدادی API Call نمونه، مدل رو تیون کنیم. حالا فرض کنید یک نفر بخواد این مدل رو برای استفاده از تپسی یا باسلام به کار بگیره. چی میشه؟ هیچی! مجددا بار فاین‌تیون با APIهای جدید میفته روی دوش کاربر.

برای حل این مشکل، ما نیاز به agentها داریم. در واقع در مثال‌های فوق هر API و ابزاری که لازم داریم رو برمیداریم، می‌بریم یک جایی براشون توابع درستی می‌نویسیم و سپس با کمک LLMها خروجی رو «انسانی» یا Humanize می‌کنیم. به این شکل بار فاین‌تیون کردن LLMهم به دوش نمی‌کشیم و همه چیز هم عالی پیش خواهد رفت.

ساخت ایجنت بدون استفاده از فریمورک

دقیقا از زمانی که OpenAI و سایر شرکت‌هایی که LLM ارائه دادند APIهای چت و یا Instruction Following خودشون رو هم ارائه کردند، فریمورک‌های زیادی مثل Flowise یا Crew AI ساخته شدند که به شما کمک کنند تا ایجنت بسازید.

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

نتیجه این شد که شخصا به دنبال روشی گشتم که بتونم بدون استفاده از فریمورک خاصی، به راحتی بتونیم یک ایجنت بسازیم. برای همین لازم بود که درک کنم ایجنت اصلا چی کار می‌کنه؟ چرا انقدر مهمه که ما بتونیم ایجنت رو درک کنیم؟ و صدالبته از هر ایجنتی که اسمش «اسمیت» باشه دوری بجوییم 😂

ایجنت‌ها یک سری «وظیفه» و «ورودی مناسب هر وظیفه» رو درک می‌کنند. این وظایف یا تسک‌ها در واقع توابعی هستند که در برنامه‌مون قرار ادادیم که بتونن یک کاری رو انجام بدن (مثلا بره رخداد n ام سری فیبوناچی رو حساب کنه) و ورودی‌هاشون هم دیتاییه که ایجنت باید با هوش خودش تشخیص بده و بسازه.

در نهایت نیاز به مکانیزمی داریم که بیاد این وظایف و ورودی‌ها رو اجرا کنه، خروجیشون رو دوباره بده به LLM و ازش بخواد که Humanizeش کنه. گذشته از این بد نیست که ایجنت ما یک حافظه کوچکی هم داشته باشه.

نمونه یک ایجنت ساده با پایتون

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

اولین گام ما برای ساخت ایجنت باید این باشه که یک LLM مناسب انتخاب کنیم. شما مختارید هر LLMای که یک OpenAI Compatible API ارائه می‌ده انتخاب کنید اما من شخصا دارم از پروژه جبیر خودم استفاده می‌کنم 😁

بعد از اون، لازم داریم که بیاییم یک کلاینت ساده OpenAI درست کنیم که بتونه با API مورد نظر ما کار کنه:

from openai import OpenAI

client = OpenAI(api_key="FAKE", base_url="https://openai.jabirpoject.org/v1")

همونطور که قبلا در این پست توضیح داده بودم، کتابخونه OpenAI در پایتون نیازمند یک API Keyئه که اینجا ما از FAKE استفاده کردیم براش.

حالا یک کلاس ایجنت ساده درست می‌کنیم که حافظه هم داشته باشه:

class Agent:
    
    def __init__(self, system=""):
        self.system = system
        self.messages = []
        if self.system:
            self.messages.append({"role" : "system", "content" : system})
    
    def __call__(self, message):
        self.messages.append({"role" : "user", "content" : message})
        result = self.execute()
        self.messages.append({"role" : "assistant", "content" : result})
        return result
    
    def execute(self):
        completion = client.chat.completions.create(
            model = "jabir-400b",
            messages = self.messages,
            temperature = 0.0
        )
        
        return completion.choices[0].message.content

همونطوری که می‌بینید، این ایجنت می‌تونه یک تاریخچه از چیزهایی که بهش گفتیم (و بهمون گفته) نگه داره و کم کم باید بریم سراغ این که بهش اکشن‌های مورد نظر رو اضافه کنیم.

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

sample_agent = Agent("You are a helpful assistant")
print(sample_agent("What is 1+1?"))

کد نمونه با اکشن

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

جمع‌بندی

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

این علاقه، کم کم به سمت Generative AI رفت و خب طبیعتا همین علاقه باعث ساخته‌شدن پلتفرم مانی و همچنین آتلیه شد. اما خب در سال ۲۰۲۵ احتمالا بیش از این که به مدل‌های جدید نیاز داشته باشیم، نیاز داریم که مدل‌ها رو به سمت agentic شدن بیاریم و اپلیکیشن‌ها رو به شکل AI agent داشته باشیم.

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

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

هوش مصنوعی در خدمت انگلیسی‌زبان‌ها

در سال‌های اخیر، با ارائه مدل‌های زبانی که در تولید متن (Text Generation) و طبقه‌بندی متن (Text Classification) و خلاصه‌سازی متن (Text Summerization) می‌تونن به ما کمک کنند یک ویژگی کاملا مشهوده. این مدل‌ها عموما عمده داده‌ای که دیدن، به زبان انگلیسی بوده. مگر این که مدل، از مدل‌های بسیار بزرگ (مثل GPT-3 یا BLOOM) بوده باشه که باز هم چیزی در حدود ۹۶-۹۷ درصد این داده ورودی، انگلیسی بوده.

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

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

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

مشکلاتی که انگلیسی‌زبان‌ها مطرح کردند

سانسورشدگی در خروجی‌های مدل

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

گرچه این مورد به ذات می‌تونه خوب باشه (با توجه به نداشتن محدودیت سنی در استفاده) اما خب من رو شدیدا یاد رمان ۱۹۸۴ میندازه، اونجایی که زبان انگلیسی رو طوری تغییر داده بودن که اگر کسی خلافش صحبت می‌کرد مجرم بود. بخواهیم یا نخواهیم، این ابزارها مثل اینترنت و سایر رسانه‌های اجتماعی در شکل‌گیری و جهت‌گیری افکار ما می‌تونن موثر باشند. به همین خاطر این حد از سانسورشدگی که هم در چت‌جی‌پی‌تی، هم در لاما (مدل بزرگ مِتا) و هم در بارد (مدل بزرگ گوگل) شاهدیم، عاقبت خوبی نداره.

جهت‌دار بودن خروجی‌های مدل‌های زبانی بزرگ

بیایید فرض کنیم که کودکی وجود داره که هر روز به اسم «ناهار» بهش یک غذای خاص داده شده و نتونسته غذایی جز اون رو در وعده «ناهار» تجربه کنه. مثلا هرروز ساعت ۱۲ ظهر به این کودک شما یک عدد ساندویچ هات‌داگ دادید. حالا نتیجه چی میشه؟

کافیه به این کودک لیستی از غذاها نشان بدیم و ازش بخواهیم که برای وعده ناهار امروز یکی رو انتخاب کنه. به نظرتون این کودک چه چیزی رو انتخاب می‌کنه؟

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

به همین خاطر هم مدل‌های زیادی وجود داره که افراد روی داده کمتر جهت‌دار (مثل داده‌هایی که از بریتانیکا و ویکی‌پدیا میشه به دست آورد) آموزش دادند. حتی مدل‌هایی مثل Pygmalion دقیقا به خاطر همین موضوع جهت‌دار نبودن و سانسور نداشتن، از فضاهایی مثل Google Colab منع شدن!

برای زبان فارسی چه کاری می‌تونیم بکنیم؟

و حالا بحث ما می‌رسه به زبان شیرین فارسی و این که چه کاری از دستمون برای این زبان برمیاد؟ ابتدا باید ببینیم که این مدل‌ها چطوری کار می‌کنن!

یک مدل زبانی بزرگ مثل LLaMa یا GPT-3 یا هر مدل دیگری (که این روزها حسابی سر و صدا کردند) کارکردشون اینطوریه که حجم زیادی از داده شامل متن می‌بینن. این داده می‌تونه مطلب بلاگ، اخبار یا مدخل‌های ویکی‌پدیا باشه. بعد این داده رو که می‌بینن، تلاش می‌کنن ارتباط بین کلمات رو بفهمن. در بعضی موارد قادر به استخراج و تشخیص context هم هستند که اگر کلمات مشابهی رو دریافت کنند، چه پاسخی بدن.

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

حالا سوال اینه که ما با این دانش، باید چی کار کنیم تا بتونیم زبان فارسی رو به چنین مدل‌هایی وارد کنیم؟

جمع‌آوری/تولید داده

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

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

راه دیگر، استفاده از روش جمع‌سپاری و درخواست از یک جامعه‌ست برای تولید داده مورد نظر. یعنی مثلا یک پلتفرم ایجاد کنیم و از مردم بخواهیم که مثلا هرکسی یک پاراگراف در مورد یه موضوعی بنویسه. به این شکل در مدت کوتاهی، می‌تونیم به یک حجم خوبی از داده برسیم (مثل کاری که Mozilla Common Voice انجام می‌ده).

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

مدل‌های پایه

بعد از جمع‌آوری داده‌های مکفی، لازمه ذکر کنم که ما به مدل پایه هم نیاز داریم. مدل‌هایی مثل GPT-3 که امکان بازآموزی ندارند (چون اوپن سورس نیستند) و اگر داشته باشند هم این بازآموزی باید روی بستر OpenAI انجام بشه که طبیعتا خیلی گزینه منطقی و مناسبی نیست. مدل‌هایی مثل BLOOM یا Falcon 40B هم بسیار بزرگتر از این هستند که بتونیم حتی با داشتن حساب کاربری روی Google Colab Pro Plus آموزششون بدیم.

پس چی می‌مونه؟ مدل‌های کوچکتر که دقت خوبی دادند. مدل‌هایی مثل GPT-J, GPT-NeoX, LLaMa, … می‌تونن پرفرمنس خوبی در این زمینه داشته باشند. تلاش‌هایی در این جهت داره میشه و به زودی در موردش در همین بلاگ خواهم نوشت 🤩

سخن آخر

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

اما نکته اینه که در دنیای امروز، در سال ۱۴۰۲ خورشیدی، در ۲۰۲۳ میلادی یا هرچی که شما قبول دارید، حفظ زبان‌ها، خواه فارسی خواه عربی، خواه ترکی خواه کردی، مستلزم اینه که ماشین‌ها درک خوبی از اون زبان داشته باشند. به همین خاطر این پست بلاگ نوشته شد تا این نگرانی به گوش سایر افرادی که ممکنه دغدغه مشابه داشته باشند، برسه.

امیدوارم شاد و خندون و موفق باشید 🙂

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

پروژه پلاک‌خوان یا Automated Number Plate Recognition که بهش ANPR هم می‌گن، من رو تشویق و تحریک کرد که یک پروژه نویسه‌خوان نوری یا همون OCR فارسی هم پیش ببرم. اما پیش‌برد پروژه OCR تا حد زیادی به تعویق افتاد چرا که درگیر توسعه محصول در استارتاپی بودم. اما از عید نوروز ۱۴۰۱ خیلی جدی‌تر به پیاده‌سازی یک OCR فارسی درست و حسابی فکر کردم. گرچه این پروژه رو تا حد زیادی به عبارتی Hold کردم، اما خب نتایج جالبی تا الان ازش به دست آمده که حیف بود در این مطلب وبلاگ در موردش ننویسم.

شروع پروژه: درک کارکرد OCR

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

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

خب، الان فهمیدیم OCR چیه و چی کار می‌کنه. حالا وقتشه که بریم سراغ پروژه من. این که پروژه چی شد و به کجا رسید. یک مسیر جذاب طی شد اما خب این مسیر جذاب یه جاهایی هم تو دست‌انداز افتاده. چون پروژه هنوز تمام نشده و خیلی مونده تا به نتیجه خوبی برسه، ترجیح دادم «هرچی که تا الان انجام شده» رو در این مطلب باهاتون به اشتراک بذارم.

پروسه انجام پروژه OCR فارسی

فاز اول: تصمیم‌گیری

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

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

حالا که می‌دونم یکی از دلایلی که OCR فارسی رو توسعه می‌دم، اینه که از زبان فارسی حفاظت و صیانت کنم (و قطعا وقتی از حروف فارسی استفاده کنم برای زبان‌های دیگری مثل کُردی، عربی و … هم قابل استفاده خواهد بود) نیاز بود بررسی کنم که چه ابزارهایی در اختیار دارم. اولین ابزاری که به نظرم رسید، بهترین زبان برنامه‌نویسی دنیا بود (😁) یعنی پایتون! خب بررسی پایتون رو در یک بخش جداگانه توضیح میدم ولی فعلا پایتون رو در نظر داشته باشید. در پایتون PyTorch و OpenCV هم داریم که خب یعنی هر آنچه برای کارهام نیاز بود در یک پکیج داشتم.

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

فاز دوم: ابزارهای مورد استفاده برای پیاده‌سازی پروژه OCR فارسی

در این بخش با هم بررسی خواهیم کرد که چه ابزارهایی برای پیاده‌سازی OCR نیاز بود. در واقع، این پلنی بود که من چیدم برای استفاده از ابزارها.

• پایتون: همونطور که گفتم پایتون، بهترین زبان برنامه‌نویسی دنیا؛ حداقل در این قسمت ماجرا بود. پایتون زبان راحتیه و رسیدن به نتیجه درست و حسابی بهش نسبتا آسون. به همین خاطر پایتون رو انتخاب کردم. گذشته از این بسیاری از ابزارهای هوش مصنوعی و یادگیری ماشین هم در پایتون قابل استفاده هستند.
• OpenCV: ابزار OpenCV یا Open Computer Vision که معرف حضور همه هست. این ابزار، کلی تابع و کلاس و … برای پردازش تصویر با متدهای کلاسیک یادگیری ماشین رو در خودش جای داده و گذشته از اون، پایه بسیاری از کتابخانه‌های مدیریت و ویرایش تصاویر دیگر مانند Pillow هم هست.
• زرنویس: ابزار زرنویس (لینک) ابزاری بود که چند وقت پیش برای نوشتن متن فارسی روی تصاویر به کمک Pillow نوشتم.
• PyTorch: کتابخانه PyTorch هم که باز معرف حضور هست. یکی از بهترین ابزارها برای پیاده‌سازی پروژه‌های یادگیری عمیق.
• الگوریتم YOLOv5: الگوریتم YOLOv5 (لینک) هم یکی از بهترین الگوریتم‌های تشخیص اشیا یا Object Detection محسوب میشه و خب با کارهای Ultralytics کار باهاش شدیدا راحت هم شده.
• ابزار LabelImg: ابزار LabelImg (لینک) هم یک ابزار مناسب برای برچسب زدن به تصاویر برای YOLOv5 (و در کل الگوریتم یولو) به حساب میاد.

فاز سوم: جمع‌آوری داده‌های مناسب برای پروژه و آموزش مدل

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

• بخش اول – تشخیص اعداد فارسی: در این بخش تا حد زیادی تنبلی کردم و به جای استخراج اعداد از متون، با استفاده از زرنویس و چند فونت فارسی آزاد، حدود صدتا تصویر که در هر کدوم اعداد ۴-۵ رقمی بودند تولید کردم. بعد از اون، اعداد رو لیبل کردم و بعد از لیبل کردن اون‌ها، رفتم سراغ ترین کردن مدل YOLOv5 با استفاده از داده‌ای که از اعداد به دست آورده بودم. این مدل خوب کار کرد، گرچه روی چندین فونت خاص خیلی خوب کار می‌کرد و روی چندین فونت اصلا کار نمی‌کرد. این موارد رو بعدتر در قسمت های آتی توضیح خواهم داد.
• بخش دوم – تشخیص حروف فارسی: این بخش، یکم چالشی‌تر شد. چطور؟ از اونجا که رندم تولید کردن کلمات فارسی که تمامی حالات حروف درشون باشه (مثلا هم ک توش باشه هم کـ هم ـکـ) کار آسونی نبود. به همین خاطر کاری که کردم چه بود؟ این بود که از دیتاست شتر (لینک) استفاده کردم و حدود ۱۰۰ تا تصویر رو جدا کردم و شروع کردم لیبل زدن و ترین کردن مدل. اینجا نتیجه بهتر بود و می‌تونست فونت‌های بیشتری رو تشخیص بده. گرچه در این مورد خاص، یک سری حروف مثل ث و ژ با دقت کمتری شناخته می‌شدند.
• بخش سوم – تشخیص بلاک‌های کلمات: دقیقا جایی که چالش داشتم، اینجا بود. لیبل زدن متون طولانی یکم دردسرش زیاد بود. به همین خاطر ابتدا اومدم متون رو «خط به خط» لیبل زدم و خط‌ها رو جدا کردم. بعد از اون با استفاده از Contour های موجود در عکس کلمات رو جدا کنم و به مدل تشخیص حروف بدم که خب اون هم خودش یکم داستان‌های خاص خودش رو داشت. به هرحال، تا اینجای کار، مدل تشخیص اعداد و حروف به خوبی کار می‌کرد و نیاز بود این اتفاق هم بیفته. اما خب متاسفانه این اتفاقه افتادنش یکم سخت بود. نمی‌گم ناممکن اما خب سخته. به همین خاطر، فعلا پروژه در همین مرحله hold شده.

جمع‌بندی و نتایج پروژه

در نهایت ببینیم چه چیزهایی الان داریم و چه چیزهایی نداریم؟ تا نتایج پروژه رو بتونیم بهتر و بهتر و بهتر بررسی کنیم 😁 اول از همه ببینیم چیا رو داریم؟ خب در حال حاضر دو مدل خوب برای تشخیص اعداد و حروف فارسی داریم. این مدلها دارن با دقت‌های خوبی کار می‌کنن اما نیاز دارند که یکم بهتر بشن (یعنی در اینجا نیاز داریم که کمی Fine Tuning روی مدل‌های فعلی یا مدل‌های YOLOv5 و … انجام بدیم) و مدلی برای تشخیص خط و کلمه داریم که درست کار نمی‌کنه. در واقع بخواهیم بهتر ببینیم: چیزی که داریم تشخیص نسبتا با دقت حروف و اعداده و چیزی که نداریم تشخیص کلمات به صورت بلاکه.

کارهای آینده

در این بخش بهتره به این فکر کنیم که چه کارهایی در آینده میشه برای بهبود این پروژه انجام داد. در لیست زیر به این مسائل می‌پردازیم که دقیقا چه کارهایی لازمه انجام بشه.

• تغییر مدل: یا نوشتن مدل از بتدا با روش‌های Probabilistic یا استفاده از متدهای Instance segmentation
• تشخیص بهتر بلاک‌های کلمات و شماره (یا با استفاده از Object Detection یا استفاده از سایر متدها)
• اضافه کردن هسته این کار به یکی از OCR های مشابه مانند EasyOCR یا PaddleOCR

سخن نهایی

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