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، كل فقرة زيادة من التعليمات ليها تكلفة وفايدة، والفايدة بتقل أسرع.

الحركة العملية على نموذج صغير إنك تقصّر الـprompt وتقيس إيه اللي بيتكسر. شيل الـpolite framing. شيل إعادة الذكر المكررة. خلّي example الـformat، شيل شرح الـformat. النموذج محتاج نثر أقل؛ محتاج signal أحكم.

ما تاخدش نسبة تقصير ثابتة من حد، ولا منّنا إحنا. قد إيه تقدر تقص بيعتمد على النموذج، وعلى المهمة، وعلى قد إيه من الـprompt بتاعك كان بيشتغل فعلاً. قصّه للنص، شغّل الـeval set بتاعك، ورجّع بس اللي رجوعه بيحسّن الدقة بشكل تقدر تقيسه. الحلقة دي بتاخد عصرية وبتديك رقم عن الـprompt بتاعك، وده يستاهل أكتر من قاعدة عامة عن نموذج إنت مش مشغّله أصلاً.

النماذج الـopen-weight الأكبر بتقفل أغلب الفجوة دي وهتشغّل حاجة قريبة من الـfrontier prompt بتاعك حرفياً. الصغيرة لأ. وفين الخط بالظبط اتحرّك مع كل release، فتعامل معاه كحاجة تختبرها مش حاجة تدوّر عليها.

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

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

شكل التوفير على scale: افترض 10 مليون request في الشهر بـ1500 input + 500 output token لكل واحد. على نموذج frontier مستضاف ده bill per-token بيكبر خطياً مع الـvolume. self-hosted، ده إيجار GPU تقريباً ثابت مع الـvolume — إنت بتدفع للـinstance سواء شغّالة 10% ولا 90%. الفرق في الشكل ده، مش أي زوج أرقام معيّن، هو السبب إن الـvolume العالي هو الشرط اللي بيقلب القرار. تحت نقطة تقاطع معيّنة الـAPI المستضاف أرخص؛ فوقها الإيجار أرخص. احسب نقطة التقاطع بأسعار النهارده وأسعار الـinstances النهارده وإنت بتاخد القرار.

تكلفتين بيتنسوا من المقارنة دي والمفروض ما يتنسوش: وقت الـengineering للـmigration وصيانة serving stack، والـutilisation اللي بتوصله فعلاً — الـGPU الفاضية بتتحاسب زي المشغولة.

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

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