گردش کارهای کدنویسی عامل‌گرا با مدل‌های کوچک

بسیار خوب.

سلام به همه.

من خوزه هستم و با ایان و زوئی اینجا هستم.

همه ما درباره مدل‌های زبانی بزرگ می‌دانیم.

ما از آن‌ها برای همه چیز استفاده می‌کنیم: پیدا کردن دستور غذا، خلاصه کردن ویدیوهای YouTube، و کدنویسی.

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

آن‌ها هم مدل زبانی بزرگ هستند چون چیزی که ۴ میلیارد از چیزی را دارد نمی‌تواند کوچک باشد، اما از این به بعد این تمایز را قائل می‌شویم: مدل‌های مرزشکن و مدل‌های زبانی کوچک، موشک و دوچرخه.

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

ما همه مزایای مدل‌های زبانی کوچک را بررسی خواهیم کرد، به‌ویژه زمانی که باز و با وزن‌های باز و قابل‌بارگیری باشند، اما بیایید برای لحظه‌ای به هزینه نگاه کنیم.

برای این سخنرانی، من معیارهای زیادی را اجرا کرده‌ام و یکی از آن‌ها مجموعه داده‌ای از ۲۰۰ تکلیف متوسط و سخت بود که از تقریباً ۱۳۱ میلیون نشانه با هزینه کمتر از ۹ دلار استفاده می‌کرد.

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

بنابراین، هزینه یک مدل مرزشکن چقدر خواهد بود؟

حدود ۲۰ تا ۲۰۰ برابر بیشتر، بسته به ذخیره‌سازی مؤلفه در حافظه نهان و عوامل دیگر.

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

حقیقت دارد.

بنابراین اکنون سؤال واضح این است که تفاوت در کیفیت و دقت چیست؟

در این مجموعه داده خاص، Gemma 4 می‌تواند ۵۳٪ از تکالیف را حل کند.

این یعنی دو چیز.

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

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

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

زویی شما را در انتخاب یک مدل کوچک راهنمایی می‌کند و ایان درباره مدل‌های Gemma صحبت خواهد کرد تا متوجه شوید چگونه می‌توانید درباره آنچه این مدل‌ها می‌توانند فعال کنند فکر کنید.

سپس به‌سرعت به شما نشان خواهم داد که چگونه Gemma 4 را در Android Studio امتحان کنید، و درنهایت، به شما نشان خواهیم داد که چگونه مدل‌های کوچک را در گردش‌های کاری روزانه خود بگنجانید و همچنین معیارهای واقعی توسعه Android را به شما نشان خواهیم داد تا به شما کمک کنیم درکی شهودی از آنچه می‌توانند انجام دهند به‌دست آورید.

با این مقدمه، نوبت Zoe است.

بسیار سپاس‌گزارم، خوزه.

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

کارآمد است، اما کمی نامتناسب است.

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

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

بنابراین، برای انتخاب مدل‌های کوچک، باید مدل‌های کوچک را بشناسید.

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

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

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

بنابراین، می‌توانیم به‌صورت غیرخطی کار کنیم.

مدل انتشار رویکرد مشابهی دارد، اما در هر بار روی یک بلوک از نشان‌ها کار می‌کند.

تقریباً مثل طرحی است که دارد واضح می‌شود.

و در این مورد، DiffusionGemma هربار روی تکه‌های ۲۵۶ تایی از تراشه‌ها کار می‌کند.

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

بسیار خوب، مجموعه ابزار ما مدل‌هایی دارد که می‌توانند بنویسند، درست است؟

اشتباه است.

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

بنابراین، این به ما یک نگاشت از مثلاً مختصات به یک فضای با ابعاد بالا می‌دهد که به ما امکان می‌دهد دو چیز را از نظر مفهومی مقایسه کنیم.

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

به همین دلیل، توانایی بررسی اینکه آیا دو مفهوم با هم مرتبط هستند یا نه، به یک، بگذارید بگوییم، کمی ریاضیات تبدیل می‌شود، به‌جای یک گذر مدل، که البته آن هم کمی ریاضیات است، اما خب، این پارادایم حتی فراتر می‌رود، درست است؟

و مدل‌های کوچک‌تر و تخصصی‌تری وجود دارند که قادر به انجام یک کار هستند و آن را واقعاً خوب انجام می‌دهند.

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

بسیار خوب، پس گزینه‌های زیادی برای انتخاب وجود دارد، درست است؟

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

بنابراین، چگونه یک مدل کوچک را انتخاب می‌کنید؟

بیایید با باز کردن جعبه ابزار مدل‌های کوچک باز که می‌توانند به‌صورت محلی اجرا شوند، یعنی مدل‌های Gemma، شروع کنیم.

ادامه کار با شما است، ایان.

متشکرم، زوئی.

بنابراین، همان‌طور که خوزه در ابتدا اشاره کرد، یک مدل زبانی کوچک می‌تواند حدود ۵۰٪ از وظایف را به‌صورت آماده انجام دهد.

اما چرا ممکن است به‌طور خاص یک مدل محلی را انتخاب کنید؟

بنابراین، به حدود چهار چیز خلاصه می‌شود.

بنابراین، اولین مورد حریم خصوصی است.

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

مورد دوم تأخیر است.

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

بنابراین، زمان رفت‌وبرگشت به سرورها وجود ندارد و هزینه تأخیر اضافی در آنجا وجود ندارد.

مورد بعدی هزینه نهایی صفر است.

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

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

هیچ هزینه‌ای برای شما ندارد و هیچ هزینه غیرمنتظره‌ای برای میانای برنامه‌سازی کاربردی در آن بخش وجود ندارد.

و درنهایت، چهارمی دسترسی آفلاین است.

بنابراین، تصور کنید که می‌توانید از این در هواپیما، قطار، اتوبوس، یا در مترو استفاده کنید، اساساً هر جایی که مدل را روی سخت‌افزار خود اجرا می‌کنید.

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

بنابراین، یکی حافظه است و دومی سرعت است.

بنابراین، اگر به این نمودار در اینجا نگاه کنید، اگر به دو مدل پایینی، 26B و 31B، نگاه کنید، هر دو برای اجرا در BF16، که یک کوانتیزاسیون ۱۶ بیتی است، بیش از ۵۰ گیگابایت حافظه دسترسی تصادفی ویدیو مصرف می‌کنند.

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

بنابراین، کاری که ما انجام می‌دهیم این است که فرایندی به نام کوانتیزاسیون را انجام می‌دهیم که این دقت را به مثلاً یک عدد ۴ بیتی در یک عدد اعشاری کاهش می‌دهد.

اکنون کمی منطقی‌تر است.

درباره ۱۴ گیگابایت و ۱۷ گیگابایت صحبت می‌کنیم، درست است؟

این مدل اکنون می‌تواند در چیزی مثل Mac با حافظه یکپارچه جا شود.

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

به این کار آموزش آگاه از کوانتش می‌گویند.

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

بنابراین، ۷۵٪ کاهش در الزامات RAM داریم و اکنون می‌تواند در آن دستگاه‌ها جا شود.

و ما یک قدم فراتر می‌رویم.

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

بنابراین، ما نوعی کیسه کوانتش مختلط داریم.

بنابراین، از Gemma E2B با حجم ۱۱٫۴ گیگابایت به ۱٫۱ گیگابایت می‌رسیم.

بنابراین، اکنون در تلفن‌های میان‌رده تا رده‌بالا بسیار منطقی‌تر است.

مورد بعدی سرعت است.

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

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

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

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

و دلیل اینکه این در معماری Gemma 4 کار می‌کند این است که آن‌ها از حافظه پنهان KV یکسانی استفاده می‌کنند.

بنابراین، این را به‌عنوان نوعی حافظه کوتاه‌مدت مدل درنظر بگیرید.

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

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

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

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

بنابراین، چگونه یکی از این مدل‌ها را ارزیابی می‌کنید؟

بنابراین، واضح‌ترین کاری که ممکن است انجام دهید این است که به یک معیار مانند LiveCodeBench یا MMLU نگاه کنید و امتیاز را بررسی کنید.

اما این فقط نوعی نشانگر سطح بالا درباره توانایی مدل به شما می‌دهد.

کاری که واقعاً باید انجام دهید این است که کل پشته‌ای را که در آن اجرا می‌شود ارزیابی کنید.

بنابراین، این مدلی است که استفاده می‌کنید، وزن‌ها و رویکرد کوانتیزاسیون، استنتاج زمان اجرا است، بنابراین ممکن است از چیزی مانند llama.cpp یا Ollama یا LiteRT استفاده کنید، زیرساخت عاملی که استفاده می‌کنید، چه Pi باشد یا OpenCode یا Antigravity، و سپس پنجره زمینه، که نوعی فضا برای تمام داده‌هایی است که می‌خواهید مدل شما بتواند پردازش کند.

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

بنابراین، برای ارائه یک مثال سریع، ما درحال انجام برخی آزمایش‌ها با Gemma 4 در Android Bench بودیم و یک نسخه Ollama را با بافت پیش‌فرض 32k اجرا می‌کردیم.

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

بنابراین، فقط با افزایش بافت از ۳۲ هزار به ۲۵۶ هزار، اکنون می‌تواند آن را در حافظه نگه دارد و مدل می‌تواند آن آزمایش خاص را با موفقیت پشت سر بگذارد.

و شاهد دوبرابر شدن نرخ موفقیت در آن شغل خاص بودیم.

بنابراین، این نشان می‌دهد که حتی یکی از این عوامل کوچک می‌تواند تأثیر زیادی بر مناسب بودن یا نبودن این مدل داشته باشد.

پس، چگونه ارزیابی‌های خود را انجام می‌دهید؟

بنابراین، در اینجا سه پیشنهاد سریع وجود دارد.

بنابراین، یکی این است که می‌توانید یک سابقه Git بگیرید، بنابراین دسته‌ای از PRهایی که قبلاً موفق شده‌اید، و می‌توانید از آن‌ها به‌عنوان ورودی‌های پیام‌واره به مدل استفاده کنید و ببینید که چگونه روی آن‌ها عمل می‌کند.

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

دو نمونه خیلی خوب از این موضوع داریم.

ما یک کامپایلر داریم و آزمون‌های واحد داریم.

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

و سومین مورد، ثبت مسیرها است.

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

و می‌خواهم سعی کنید چارچوب سؤالتان را از، می‌دانید، «آیا این مدل به‌اندازه این مدل مرزشکن بزرگ هوشمند است؟» تغییر دهید.

تا «آیا این تکلیف در این سخت‌افزار با این پیکربندی خاص امکان‌پذیر است؟»

و برای اینکه به نوعی این موضوع را بفهمیم، چارچوبی به نام «آیا هنوز به آنجا رسیده‌ایم؟» اختراع کرده‌ایم.

یا AWTY.

و کل اصل این چارچوب این است که همه این وظایف مختلف را از نظر آمادگی در آن محور امتیازدهی کند.

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

و این به شما می‌گوید که آیا آماده هستید یا نه.

بنابراین، برای مثال، ممکن است به این نگاه کنید که آن تکلیف خاص چقدر قابل‌اعتماد است.

اگر آن را مثلاً ۱۰ بار پشت‌سرهم اجرا کنید، آیا هربار همان کار را انجام می‌دهد؟

شاید به تأخیر نگاه می‌کنید.

شاید لازم باشد پاسخ هم‌زمان باشد.

بنابراین، می‌دانید، آستانه‌های شما برای سرعت انجام کار چیست؟

و سپس ممکن است درواقع به الزامات RAM نگاه کنید.

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

بنابراین، آیا می‌توانید ۵۰٪ از RAM را اشغال کنید یا فقط می‌توانید ۱۰٪ از آن را اشغال کنید؟

و این نوع نهایی امتیاز آمادگی را دریافت می‌کنید.

بنابراین، اگر سبز باشد، یعنی پیکربندی آماده استفاده است.

اگر نارنجی، زرد، یا قرمز باشد، یعنی شاید لازم باشد چیزی را در پیکربندی تغییر دهید.

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

بنابراین، بله، پیشنهاد می‌کنم نگاهی به این بیندازید.

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

بنابراین، زوئی کمی بیشتر درباره نحوه راه‌اندازی برخی از ارزیابی‌ها در ادامه توضیح خواهد داد، اما اکنون کار را به خوزه می‌سپارم که روشی بسیار سریع برای شروع کار با Gemma 4 به شما نشان خواهد داد.

متشکرم، ایان.

بنابراین، بله، سریع‌ترین راه برای امتحان کردن Gemma 4 درحال‌حاضر احتمالاً ازطریق «استودیو Android» است.

بنابراین اجازه دهید به شما نشان دهم چگونه.

لطفاً به رایانه کیفی بروید.

بفرمایید.

بنابراین، اگر به صفحه ارائه‌دهندگان مدل در تنظیمات بروم و Gemma را انتخاب کنم، این به شما ایده نسبتاً واضحی از اندازه هر مدل می‌دهد.

فقط باید مدل‌ها را در دیسک سختم بارگیری کنم.

بنابراین، این کار یک سرور llama.cpp را باز یا راه‌اندازی می‌کند و از همان ابتدا به‌درستی برای شما پیکربندی شده است.

اما می‌توانید از سرور llama.cpp خودتان یا Ollama یا LM Studio یا هر چیز دیگری که می‌خواهید استفاده کنید.

برای این کار، فقط به اینجا می‌آیید و ارائه‌دهنده محلی اضافه می‌کنید.

و همچنین، استفاده از مدل‌های کوچک ازطریق ارائه‌دهنده راه دور بسیار منطقی است.

بنابراین، می‌توانید یکی را در اینجا اضافه کنید، تا زمانی که با OpenAI یا Anthropic سازگار باشد، می‌توانید به آن متصل شوید.

بسیارخوب، پس بیایید ببینیم.

بنابراین، اکنون، اوه، راستی، بنابراین، روشی که شما یک مدل را در Android Studio انتخاب می‌کنید، ازطریق این منو کرکره‌ای است، بدیهی است.

بنابراین، Gemma 4 26B را انتخاب کرده‌ام و می‌توانم بپرسم: «ViewModel چیست؟»

بسیارخوب.

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

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

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

خیلی ممنون، خوزه، و ممنون، ایان، برای نمای کلی مدل‌های Gemma، و اینکه آیا به آنجا رسیده‌ایم یا نه.

بنابراین، دیدیم که چه نوع مدل‌هایی وجود دارد، مشخصات آن‌ها چیست، و اکنون مسئله درک این است که چه نوع کارهایی را می‌توانید به آن‌ها بسپارید.

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

درست است؟

بنابراین، این‌ها، می‌دانید، برخی‌از چیزهایی هستند که من کاملاً مطمئنم همه درحال‌حاضر انجام می‌دهند، حتی، احتمالاً، بدون اینکه متوجه باشند.

ولی می‌خواهم شما را تشویق کنم، یا می‌خواهم شما را تشویق کنم که فراتر از آن فکر کنید، درست است؟

بنابراین، با توجه به اینکه مدل‌های کوچک می‌توانند وزن باز باشند و به‌صورت محلی اجرا شوند، چه چیزی می‌تواند زمان را به شما بازگرداند؟

درست است؟

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

بنابراین، اگر بتوانیم فراتر از آن برویم، مدل‌های کوچک چه کارهایی می‌توانند انجام دهند؟

چه گردش کارهایی وجود دارد که می‌توانید آن‌ها را وارد کنید تا زندگی‌تان را آسان‌تر کند و ظرفیت بیشتری به شما بدهد تا کارهایی را انجام دهید که شاید بخواهید بیشتر انجام دهید؟

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

خب، این‌ها چند مثال هستند، درست است؟

و در پایان روز، تا حدودی محدودیتی وجود ندارد، یا معماری محدودیت است، و چیزهای زیادی وجود دارد که می‌توانید به نحوه اجرای آن فکر کنید.

اما با داشتن مشخصات، ابزارها، و گردش‌های کاری، آیا هنوز مطمئن نیستید از کجا شروع کنید؟

خب، محک‌زنی برای همین است.

و همان‌طور که ایان گفت، یک جدول رده‌بندی عمومی، به‌ویژه برای Python، اطلاعات بسیار کمی درباره اینکه آیا یک مدل کوچک برای گردش‌های کاری Android شما مفید خواهد بود یا نه، به شما می‌دهد.

درست مثل اینکه دریل دیوار گچی ممکن است اطلاعات زیادی درباره دریل بتن به شما ندهد.

اما باید روی ارزیابی‌های خودتان سرمایه‌گذاری کنید.

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

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

و سه چیز وجود دارد که باید هر زمان که معیار را ارزیابی می‌کنید به آن‌ها نگاه کنید، درست است؟

کمی متا است، اما، اساساً، اولین چیز این است که، نوع وظیفه‌ای که این مدل انجام می‌دهد چیست، درست است؟

چقدر مشخص است.

آیا شبیه به نوع تکلیفی است که به آن خواهید داد؟

مورد دوم، دامنه تکلیف است.

آیا این کار نوشتن مستندات است، آیا حل کردن یک PR است، آیا چیزی است که شبیه به نوع شغلی است که شما دارید؟

و در نهایت، آیا پیچیدگی سیستم شبیه به پیچیدگی‌ای است که شما می‌خواهید ارائه دهید؟

و اینجا جایی است که می‌توانیم ببینیم چرا محک Python نماینده خوبی برای Android نیست.

به‌همین دلیل است که Android Bench را ساخته‌ایم، که معیاری است که بوم‌سازگان Android و کار Android را ثبت می‌کند.

نسخه اول دارای ۱۰۰ تکلیف Android در اندازه PR است و می‌توانید امروز آن را ازطریق Harbor اجرا کنید تا هر ترکیبی از عامل، مدل، و مهارت را بررسی کنید.

ما نسخه 2.0 را با کارهای پیچیده‌تر و طولانی‌تر راه‌اندازی می‌کنیم تا بفهمیم توانایی‌های مدل‌های مرزشکن برای کار در مشاغلی مانند کارهایی که امروز به آن می‌دهید چیست.

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

بسیارخوب، متشکرم، زوئی.

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

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

تکالیف چندگامی تکالیفی هستند که ممکن است تکمیل آن‌ها برای انسان روزها یا هفته‌ها طول بکشد.

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

حداقل در یک حرکت.

بعداً درباره آن صحبت خواهیم کرد.

بسیار خوب، تکالیف کوچک.

این کارها کارهایی هستند که شاید به خواندن و نوشتن یک یا دو فایل نیاز داشته باشند و به دانش زیادی نیاز ندارند.

برای مثال، مدل‌های کوچک در Compose، حداقل در اصول اولیه Compose، بسیار خوب هستند.

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

این‌ها برای مدل کوچک بسیار آسان است.

اما این یکی موضوع پیشرفته‌تری را پوشش می‌دهد، ولی تکلیف همچنان آسان است.

@Composable
 fun AnimatedDrawer() {
   val offsetX = remember { Animatable(0f) }
-  Box(modifier = Modifier.offset(x = offsetX.value.dp)) {}
+  Box(modifier = Modifier.graphicsLayer { translationX = offsetX.value }) {}
 }

مشکل در این مورد مربوط به دامنه است، نه دانش.

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

بنابراین، این کار را حتی برای مدل کوچکی مثل Gemma 4 بسیار آسان می‌کند.

در این مورد، ۳ دقیقه طول کشید و تغییر یک‌خطی است.

بسیار خوب.

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

بیایید ببینیم یک ریز- ببخشید، یک تکلیف کوچک چیست.

بیایید به تکالیف متوسط نگاه کنیم.

مدل‌های کوچک باید بتوانند بیشتر آن‌ها را انجام دهند.

در این تکلیف، از برنامه Pocket Casts، نماینده کاربر در درخواست وجود ندارد و همچنین خطایی در منطق تکرار وجود دارد.

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

ولی گذشت.

۱۰ دقیقه طول کشید.

سه فایل را اصلاح کرد.

و ضمناً، هزینه آن ازطریق OpenRouter‏ ۶ سنت بود.

اکنون، بیایید به یک تکلیف ناموفق از همان مجموعه داده نگاه کنیم.

این نمونه‌ای از Now in Android با گزارش یا پیام‌واره‌ای نسبتاً جامع است، اما نام کلاس یا فایل را ذکر نمی‌کند، بنابراین عامل باید تلاش بیشتری برای درک معماری برنامه، لایه داده، سازوکار همگام‌سازی و در این مورد، غیره انجام دهد. بنابراین، در این اجرای خاص، ناموفق بود.

همه چیز تقریباً به‌درستی پیاده‌سازی شده بود، اما فرض بر این بود که مقدار همگام‌سازی اولیه ۱- باشد، درحالی‌که درواقع ۰ است.

val isInitialSync = currentVersion == -1

val isInitialSync = currentVersion == 0

همین.

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

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

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

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

به‌زودی درباره آن هم صحبت خواهیم کرد.

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

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

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

اما مواردی هم وجود دارد که وقتی به آنچه واقعاً اتفاق افتاده نگاه می‌کنید، متوجه می‌شوید که مدل ۹۰ درصد یا بیشتر درست عمل کرده است.

پس بیایید یکی از آن‌ها را انتخاب کنیم.

من این یکی را انتخاب کردم چون پوسته پوسته است.

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

بنابراین، من این را در مرز آنچه یک مدل کوچک می‌تواند انجام دهد می‌دانم.

یا حداقل مدلی از آوریل.

این آسیب‌پذیری مربوط به تجزیه نشانی‌های وب ناقص در کتابخانه Coil است.

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

پس بیایید سریع به آن نگاه کنیم.

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

آن‌هایی که این کار را نکردند در ارزیابی رد شدند.

بنابراین، همه اجراها تقریباً بی‌نقص هستند، اما این نشان می‌دهد که مدل‌های کوچک همیشه گام اضافی را برنمی‌دارند.

آن‌ها دستورالعمل‌ها را دنبال می‌کنند، اما مانند مدل‌های مرزشکن سعی نمی‌کنند شما را تحت‌تأثیر قرار دهند.

می‌دانید این روزها چطور می‌توانید میزان تلاش را در یک عامل تنظیم کنید؟

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

بنابراین، بیایید تکالیف بزرگ را به‌عنوان تکالیفی تعریف کنیم که ممکن است توسط مدل‌های کوچک در حدود ۵۰٪ مواقع تکمیل شوند، که همان چیزی است که Gemma 4 31B می‌تواند دربرابر مجموعه داده Android Bench v1 به آن دست یابد، چیزی که Zoe قبلاً درباره آن صحبت کرد.

بنابراین، قبل‌از صحبت درباره تکالیف چندگامی، آیا می‌توانیم کاری انجام دهیم تا به مدل‌های کوچک در انجام این تکالیف کمک کنیم؟

قطعاً، و این کارها اصلاً به هیچ تلاشی نیاز ندارند.

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

برای مثال، اگر از Ollama برای ارائه Gemma 4 استفاده کنید، به‌طور پیش‌فرض از پنجره بافت ۳۲٬۰۰۰ داده‌واحدی استفاده می‌کند، درحالی‌که درواقع هشت برابر بیشتر را پشتیبانی می‌کند.

البته اگر از Gemma 4 ازطریق Android Studio استفاده می‌کنید، نیازی به پیکربندی آن ندارید.

این ویژگی به‌طور پیش‌فرض به‌درستی پیکربندی شده است.

در مجموعه ارزیابی‌های ما، فعال کردن بافت کامل باعث شد نتایج از ۲۶ به ۵۳ درصد برسد.

سپس، از Android CLI، ابزار Android CLI، به‌ویژه برای جستجوی اسناد استفاده کنید.

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

طبق تجربه ما، بسیار بهتر از استفاده از ابزارهای جستجوی وب است.

سپس، راهنمایی‌های درستی‌سنجی را اضافه کنید.

درباره این موضوع صحبت کردیم.

به مدل بگویید چگونه آزمایش‌ها را اجرا کند، چه نوع آزمایش‌هایی دردسترس است، چگونه شبیه‌سازها را مدیریت کند، و غیره. می‌توانید این کار را در فایل AGENTS.md انجام دهید که باعث می‌شود دستورالعمل‌ها برای همه عامل‌ها دردسترس باشد، اما، منظورم این است که این چیز خوبی است، به‌هرحال.

باید آن را داشته باشید.

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

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

سپس، مهارت‌ها را اضافه کنید، اما مهارت‌ها را نیز بردارید.

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

خب، تکالیف چندگامی چطور؟

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

نمونه‌هایی از تکالیف چندگامی عبارتند از انتقال کل برنامه از XML به Compose، ایجاد برنامه پیچیده از ابتدا، یا تبدیل برنامه‌های چندسکویی به Android بومی.

اگر به نتایج Android Bench V2 نگاه کنیم که منحصراً بر چندگامی تمرکز دارد، می‌بینیم که مدل‌های مرزشکن امتیاز ۳ تا ۴۰٪ را کسب می‌کنند.

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

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

بیایید ببینیم چطور می‌توانیم این کار را انجام دهیم.

برگشتن به Zoe.

بسیار سپاس‌گزارم، خوزه.

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

بنابراین، هماهنگ‌سازی می‌تواند، برای مثال، به شما کمک کند که هرگز مسدود نشوید، درست است؟

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

The other thing that you could do is through orchestration is get better answers.

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

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

همچنین می‌توانید از مدل جداگانه‌ای به‌عنوان مثلاً آزمایش‌ها استفاده کنید.

بنابراین، مثل بازبینی همتا است.

و شما می‌توانید آن را از این طریق ببینید.

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

اساساً می‌توانید آن را به‌صورت دستی راه‌اندازی کنید، بنابراین می‌توانید یک مدل را برای برنامه‌ریزی، مدل دیگری را برای اجرا، و مدل دیگری را برای آزمایش‌ها تنظیم کنید.

راه‌های متعددی برای انجام این کار وجود دارد، چه در فضای ابری یا اینکه می‌توانید یک پراکسی LiteLLM راه‌اندازی کنید تا این کار را به‌صورت محلی انجام دهید.

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

پس بیایید با برگشتن به سؤالی که خوزه در ابتدای صحبت پرسید، بحث را تمام کنیم: تفاوت کیفیت و دقت بین مدل‌های کوچک و مدل‌های مرزشکن چیست؟

و پاسخ به این سؤال، مانند بسیاری از چیزها در علوم رایانه، این است که بستگی دارد.

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

این چیزی است که می‌توانید در آن تفاوت ایجاد کنید، بسته به اینکه چگونه آن را تنظیم کنید و بسته به اینکه چگونه با قطعات بازی کنید.

بنابراین، اولین بخش در اینجا، انتخاب ابزار مناسب است، درست است؟

انواع مختلفی از ابزارها وجود دارد.

با آن‌ها آشنا شوید، آن‌ها را کاوش کنید، درست است؟

و سپس بفهمند که برای چه مشاغلی مناسب هستند یا حتی چه مشاغلی را می‌توانند انجام دهند.

مورد دوم این است که حتماً دامنه‌ای را که مدل برای انجام کار دریافت می‌کند تنظیم کنید.

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

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

و در پایان روز، باید روی راه‌اندازی یا ایجاد ارزیابی‌های خودتان کار کنید.

و درنهایت، می‌توانید دوچرخه و موشک را هماهنگ کنید تا هرگز مجبور نباشید بین یکی از آن‌ها انتخاب کنید و با این کار به‌طور مؤثر هزینه کنید.

اما مهم‌تر از همه، می‌توانید به کاوش، ساختن، و لذت بردن ادامه دهید، درست است؟

و می‌توانید این کار را امروز با تنظیم فهرست کوتاهی از مدل‌ها ازطریق Android Bench و یافته‌هایی که در آنجا دارید شروع کنید، یا امروز با Gemma 4 در «استودیو Android» شروع کنید.

بنابراین، بسیار سپاس‌گزارم.