prompt budget — التعليمات الطويلة بتتدهور إزاي

الـfrontier APIs بتتعامل مع prompts طويلة معقدة كويس. تقدر تدّي Claude system prompt 5000 كلمة بقواعد بـdetails، متطلبات formatting، و few-shot examples، و Claude هيتتبّع أغلبهم للإجابة النهائية. الـopen-weight models، حتى الأكبر فيهم، بتتعامل مع ده بشكل مختلف. الـprompts الطويلة بتتدهور بطرق متوقعة.

"التدهور" ده شكله إيه

3 patterns بتتكرر عبر عيلة الـopen-weight:

Pattern 1 — last-instruction bias. لما الـprompt فيه تعليمات كتير، الـopen-weight models الأصغر بتميل توزن التعليمة الأحدث بقوة أكتر من الأقدم. لو ذكرت 10 قواعد بالترتيب والقاعدة 1 هي "always reply in 3 sentences"، بس القاعدة 10 هي "include an explanation"، النموذج غالباً بيتبع القاعدة 10 ويطلّع 6 جمل. الـfrontier APIs أقل عرضة لده — بتعامل الـlist بتاعت القواعد بشكل أكتر مساواة.

Pattern 2 — system-prompt fade. الـopen-weight models ممكن تفقد تتبّع قواعد الـsystem prompt لما الـuser message تطوّل. user message 200 كلمة بـinput data بـdetails ممكن تطلع الـsystem prompt من الـeffective attention. الـmitigation: كرّر القواعد المهمة في الـuser message ("Remember: respond only with JSON, no markdown.")، أو انقل القواعد للـuser message كلها.

Pattern 3 — format drift عبر المحادثة. في multi-turn chats، الـopen-weight models بتبعد عن الـformat اللي قفلته في الـturn الأول. الـfrontier APIs بتمسك الـformat أحسن. الـmitigation: كرّر الـformat في الـsystem prompt أو في أحدث user message كل كم turn.

كفاءة الـtokens بتفرق أكتر

على الـfrontier APIs، إنت بتدفع per-token بس تقدر تبقى مسهب أصل الـprompt-following موثوق. على الـopen-weight models، كل فقرة زيادة من التعليمات ليها تكلفة وفايدة، والفايدة بتقل أسرع.

قاعدة عملية: لـopen-weight model 8B parameters، الـprompt بتاعك المفروض يبقى 1/3 لـ1/2 من طول الـprompt المكافئ لـClaude أو GPT. شيل الـpolite framing. شيل إعادة الذكر المكررة. خلّي example الـformat، شيل شرح الـformat. النموذج محتاج نثر أقل؛ محتاج signal أحكم.

لنماذج 70B+، الـgap بتقفل. Llama 4 70B و Mistral Large 3 بيتعاملوا مع prompts طويلة بشكل كافي عشان يشغّلوا حاجة قريبة من الـfrontier-prompt بتاعك حرفياً. الـvariants 8B وأصغر لأ.

سؤال الـCTO بتاع هاجر بيقع فين

لو تكلفة الـper-prompt للفريق هي الـconstraint الملزم، الحركة الصح مش "حوّل من Claude لـGPT-4o-mini". الحركة الصح "للمهمة عالية الـvolume، حوّل من Claude لـLlama 4 70B self-hosted بـprompt مشدود".

حسبة التوفير على scale: افترض 10 مليون request في الشهر، 1500 input token + 500 output token لكل request. على Claude Sonnet 4.5 الـAPI bill بالآلاف من الدولارات في الشهر على الـvolume ده. على Llama 4 70B self-hosted على instance g5.12xlarge AWS (أو ما يكافئها)، الـbill هو إيجار الـGPU — عادةً كم مية دولار في الشهر لـinstance بيتعامل مع الـthroughput ده. التوفير، حتى بعد engineering time للـmigration، حقيقي.

الـrisk إن 5-10% من الـrequests دي محتاجين النموذج الـfrontier على أي حال. ابني الـfallback في طبقة الـrouting من اليوم الأول. الدرس الجاي بيغطي إمتى few-shot بينقذك، اللي هي الـtechnique اللي بتخلّي نموذج أصغر يتعامل مع مهمة كان هيفشل فيها.

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