few-shot بينقذك إمتى على النماذج الأصغر

few-shot prompting (إنك تدّي للنموذج مثالين أو 3 شغّالين قبل المهمة الفعلية) كان مفيد على الـfrontier APIs ولازم على الـopen-weight models الأصغر. السبب ميكانيكي: النماذج الأصغر عندها zero-shot generalisation أضعف. بتوصل للإجابة الصح لما تورّيها الـpattern، مش لما توصفها ليها.

حالتين few-shot فيهم الفرق بين الشغل وعدم الشغل

الحالة 1 — التزام الـformat على نموذج صغير. Llama أو Mistral 7B parameter لما تسأله "استخرج الـentity في JSON" أحياناً بيطلّع JSON، أحياناً نثر، أحياناً list مرقّمة. نفس الـprompt بـ3 أمثلة شغّالة — input → exact JSON output — بيطلّع JSON كل مرة. الـfrontier API equivalent بيشتغل zero-shot؛ النموذج الصغير الـopen-weight غالباً لأ.

الحالة 2 — مصطلحات خاصة بـdomain. النماذج الأصغر بترجع افتراضياً لصياغة عامة. لو المهمة بتاعتك "صنّف الـsupport ticket ده كـbilling / technical / sales / other"، والـtickets فيها jargon خاص بالصناعة (مثلاً، "the merchant terminal won't auth"، اللي هي مشكلة billing في مصطلحات المدفوعات)، النموذج محتاج أمثلة تأسّس الـmapping. 3 أو 4 أمثلة بتغطّي الحالات الصعبة بترفع الـaccuracy بشكل ملحوظ.

إزاي تبني few-shot examples فعّالة

4 قواعد بتسري عبر كل الـopen-weight models:

1. غطّي الحالات الشائعة الأول، وبعدين الحالات الصعبة. لو عندك مكان لـ3 أمثلة، اتنين المفروض يبقوا مباشرين وواحد يضرب على edge case معروف. النموذج بياخد الـpattern المركزي من السهلة والـboundary من الصعبة.

2. طابق توزيع الـinput. الأمثلة المفروض تبان زي الـinputs الحقيقية اللي هتيجي — نفس الطول، نفس الـvocabulary، نفس مستوى الـpolish أو الـnoise. مثال academic نضيف ما بينتقلش لـsupport tickets فوضوية.

3. ورّي شكل الـoutput بالظبط. لو الـoutput المفروض يبقى {"category": "billing"}، الـoutput بتاع المثال المفروض يبقى ده بالظبط — نفس اسم الـfield، نفس الـcasing، نفس الـJSON structure. النموذج بينسخ اللي بيشوفه بحرفية أكتر من اللي إنت متوقعه.

4. استخدم separator النموذج عارفه. --- أو ### بسيط بين الأمثلة بيشتغل على Llama و Mistral. بعض النماذج بتفضّل framing Input: ... Output: .... اختبر الاتنين على المهمة بتاعتك.

تكلفة الـfew-shot

few-shot بتضيف tokens. 3 أمثلة كويسة ممكن تبقى 200-400 token لكل واحد، يعني 600-1200 input token زيادة لكل request. على open-weight models شغّالة على GPU بتاعك، الـtokens الزيادة دي بتكلّف compute، مش دولارات API. على Llama 4 70B، تكلفة الـlatency لـ3 أمثلة حوالي 50-100ms — غالباً مقبول.

لو الـapp بتاعك بيعمل requests متشابهة كتير، تقدر توزّع تكلفة few-shot عبر prompt caching. Anthropic، OpenAI، وأغلب inference servers الـopen-weight (vLLM، TGI) بيدعموا شكل ما من prefix caching. لو الـfew-shot block بتاعك نفسه عبر كل الـrequests لمهمة معيّنة، النموذج بيدفع compute cost مرة واحدة بس وبيستخدم الـcached prefix تاني. الـlatency بيقل، الـthroughput بيرتفع.

few-shot ما بيساعدش إمتى

لو النموذج بيفشل أصل ما عندوش القدرة الأساسية — multi-step reasoning، long-context tracking، لغة متخصصة — أمثلة few-shot مش هتفتح القدرة دي. بتخلّي النموذج يقلّد الـpattern؛ مش بتعلّمه الـskill. للحالات دي، اطلع لنموذج أكبر (أو لـthinking mode على frontier API)، مش لأمثلة أكتر.

التالي: fallback strategy — إزاي تركّب نماذج كتير عشان فشل واحد ما يكسرش الـapp بتاعك. :::