مدت زیادی می‌شد که هرجا برای جذب سرمایه یا حتی حمایتی برای پلتفرم هوش مصنوعی مانی می‌رفتم، سوال اصلی این بود «چرا یک 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 داشته باشیم.

حدود بهمن یا اسفند سال ۱۳۹۹ بود که من، یک عدد رزبری پای ۴ مدل B (لینک) خریداری کردم که باهاش یه سری ایده رو عملی کنم. از وقتی که این دستگاه رو خریدم، مدت زیادی تقریبا گذشته اما خب چند هفته اخیر، شدیدا با این دستگاه در حال کشتی گرفتن و تست ایده‌های مختلف هستم. یکی از ایده‌های من پروژه‌ای بود که تا حد زیادی به هوش مصنوعی (و بخصوص tensorflow) نیازمند بود. مشکلی که داشتم این بود که در خود مخازن PyPi ای که روی رزبری پای در دسترسه، هیچ ساخت درستی از tensorflow وجود نداره.

اما خب، نمیشه در دنیای تِک ناامید شد؛ به همین خاطر دنبال راهکار و راه حلی گشتم که بتونم تنسرفلو رو روی رزبری پای داشته باشم. یکم سخت‌تر از حالت عادی (که استفاده از pip بود) شد اما ارزشش رو داشت. چون تونستم بدون مشکل مدلی که مدنظر داشتم رو لود و استفاده کنم. همچنین لازمه ذکر کنم که در این مطلب قراره یاد بگیریم چطور خود تنسرفلو رو نصب کنیم و به TFLite کاری نداریم.

رزبری پای چیه؟

رزبری پای (Raspberry Pi) یک کامپیوتر تک‌برد (SBC یا Single Board Computet) محسوب می‌شه که توسط یک بنیاد غیرانتفاعی به همین اسم در بریتانیا طراحی شده (البته تولیدش مثل عمده محصولات دیگر، در کشور چین انجام میشه). این بردها معمولا یک پردازنده ARM دارند و می‌شه روی اونها سیستم‌عامل نصب کرد. خیلی‌هاشون هم ورودی/خروجی عام‌منظوره (General Purpose Input/Output) یا همون GPIO دارند که می‌تونن رابطی بین این کامپیوتر و قطعات الکترونیکی دیگر باشند.

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

تنسرفلو چیه؟

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

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

نصب Tensorflow روی Raspberry Pi

قبل از هرچیزی باید بگم که من این پروسه رو روی Raspberry Pi 4 Model B (با رم ۲ گیگابایت) و سیستم عامل Raspberry Pi OS نسخه Bullseye (بله درست حدس زدید، سیستم‌عامل رزبری پای دبیانه 😁 و صدالبته که می‌تونید توزیع‌های دیگری هم روش نصب کنید) و ویرایش ۶۴ بیتی طی کردم. بسته به مدل رزبری شما و سیستم‌عاملتون، این پروسه می‌تونه متفاوت باشه.

نصب نرم‌افزارهای پایه

ما برای این که بتونیم تنسرفلو رو نصب کنیم، نیاز به نصب تعداد زیادی نرم‌افزار روی خود سیستم‌عامل داریم. به نظر بهتره که ابتدا، لیست بسته‌های مخازن رو بروزرسانی کنیم:

sudo apt update

و صدالبته بهتره که خود سیستم‌عامل هم بروزرسانی‌های آخرش رو دریافت و نصب کنه:

sudo apt full-upgrade

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

sudo apt install gfortran libhdf5-dev libc-ares-dev libeigen3-dev libatlas-base-dev libopenblas-dev libblas-dev liblapack-dev

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

نصب و بروزرسانی بسته های پایتونی

خب ما تعدادی پیش‌نیاز پایتونی هم داریم (که این‌ها رو اکثرا حتی در وبسایت تنسرفلو هم می‌شه پیدا کرد) که با دستورات زیر نصبشون می‌کنیم:

pip3 install pybind11
pip3 install Cython==0.29.21
pip3 install h5py==2.10.0

و سپس بسته setuptools رو هم بروزرسانی می‌کنیم:

pip3 install --upgrade setuptools

و این یکی رو هم نصب می‌کنیم (چرا که باید فایل تنسرفلو رو با این بزرگوار دانلود کنیم)

pip3 install gdown

دانلود و نصب Tensorflow

خب ابتدا به کمک gdown فایل wheel (فایل‌های wheel فایل‌هایی هستند که pip می‌فهمه باید نصبشون کنه) مربوط به نسخه مورد نظر تنسرفلو رو دانلود می‌کنیم:

gdown https://drive.google.com/file/d/1YpxNubmEL_4EgTrVMu-kYyzAbtyLis29

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

سپس کافیه که با اجرای این دستور:

pip3 install <TENSORFLOW WHL FILE>.whl

نصب رو انجام بدید.

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

جمع‌بندی

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

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

در پایان، ضمن تشکر از این که وقت گذاشتید و این مطلب رو خوندید، باید بگم که هنوز می‌تونید من رو به یک فنجان قهوه مهمان کنید 🙂

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

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

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

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

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

عکس‌برداری و آموزش مدل هوش مصنوعی

برای این که پروژه هوش مصنوعی به خوبی بتونه از پس کاری که می‌خواهیم بربیاد، نیازمند داده‌های زیادی هستیم. اصولا این دید وجود داره که «هرچی داده بیشتر، بهتر». این دید گرچه بعضی جاها می‌تونه خطرناک باشه (مثل زمانی که overfit می‌شیم و …) اما عموما دید درستیه. به همین خاطر، ماشین رو راه انداختم و با استفاده از اون کدی که نوشته بودم، شروع کردم عکس برداری. نمونه‌ای از این عکس‌ها رو در اینجا می‌بینید:

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

نمونه عملکرد خودران

جمع‌بندی

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

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

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

شاسی مورد نیاز

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

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

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

درایور موتور

وقتی از موتورهای DC و بخصوص موتورهای Brushed استفاده می‌کنیم، نیازمند درایور هستیم (اگر براتون سواله که چرا، می‌تونید این ویدئو رو ببینید). به همین جهت، چیزی که نیاز داشتم یک درایور مناسب برای چنین موتوری بود. تصمیم من این شد که از L298N استفاده کنم. این درایور رو یادمه که در درس ریزپردازنده بهمون درس داده بودند و گزینه آشنایی برام بود. علاوه بر این، چندتایی از این درایور در وسایل الکترونیکیم داشتم. پس همه چیز تحت کنترل بود و کل مجموعه رو شروع کردم سوار کردن. اما مساله مهم دیگر چی بود؟ درسته؛ کنترل از راه دور 🙂

کنترل از راه دور

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

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

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

دوربین

همونطور که در بخش قبلی گفتم، به ESP8266 به این راحتیا نمیشه دوربین متصل کرد. نتیجه این شد که تصمیم گرفتم از یک گوشی اندرویدی استفاده کنم. اول کمی در فروشگاه‌های اینترنتی و … جست و جو کردم و دنبال گوشی‌های اندرویدی ارزون قیمت گشتم. اما یادم افتاد که گوشی قبلی خودم یعنی Samsung Galaxy J7 ای که دارم، دوربین خوبی داره. گذشته از اون، میشه با استفاده از Droid Cam و نرم‌افزارهای مشابه، تصویر رو به کد پایتونی فرستاد و اونجا پردازش‌های لازم رو روش انجام داد.

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

در آینده چه خواهیم خواند؟

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

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

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