ابنِ بتكلفة عالية وشغّل بتكلفة منخفضة: كيف تُخفَّض تكلفة المهارات كل ليلة

أي فريق يشغّل وكلاء ذكاء اصطناعي يرى المشهد نفسه في فاتورة كل شهر. الجزء الأكبر من تكلفة الرموز (tokens) يأتي من النماذج الطليعية، لكن كثيرًا مما تقوم به هذه النماذج ليس تحديًا إبداعيًا حقيقيًا. غالبًا ما يكون تصنيف الرسائل، ومطابقة الأخبار، وعرض الجداول، والتحقق من التزام المخرجات بالمواصفات. هذا المقال موجّه لقادة الهندسة وفرق الذكاء الاصطناعي. نتناول فيه كيفية الحكم على ما إذا كانت الجودة تبقى ثابتة عند بناء مهارة بنموذج مكلف ثم تشغيلها بنموذج أرخص، وكيف يُنفَّذ هذا الحكم تلقائيًا كل ليلة، مدعومًا بقياسات فعلية.

الخلاصة هي التالية: النموذج المكلف ضروري فقط في مرحلة بناء المهارة أول مرة. بمجرد أن يُنقل تنسيق المهارة المكتملة إلى الكود، يصبح تشغيلها الفعلي ممكنًا بنموذج أرخص بكثير. و”الكفاية” هنا لا تُقاس بحدس بشري، بل يجب أن تُحسم بنتيجة يقيسها الكود.

معظم المهام لا تحتاج نموذجًا طليعيًا

حين نُحلّل ما يقوم به وكيل الذكاء الاصطناعي يوميًا، نجد أن طبيعة العمل تنقسم إلى نوعين. في جانب، يوجد استدلال صعب حقيقي: قرارات معمارية غامضة، تصحيح أخطاء دقيق، وتفكيك مشكلات لم يسبق مواجهتها. وفي الجانب الآخر، توجد مهام روتينية متكررة: التوجيه، والتصنيف، والتلخيص، والعرض، والتحقق من المواصفات. المشكلة أن النوعين يُدفعان معًا إلى النموذج الطليعي نفسه، وتُسدَّد الفاتورة الأعلى في كل مرة.

جودة المهام الروتينية في الحقيقة لا يحددها ذكاء النموذج بقدر ما تحددها حواجز الحماية. سبب تذبذب تنسيق المخرجات ليس غباء النموذج، بل أن التنسيق طُلب منه بأسلوب نثري، أي أنه “تُرجّي” لا فُرض. حين يفرض الكود سقف الطول، والقيم المسموح بها (enum)، ومواصفات العرض، ومعايير النجاح، يخرج العمل بثبات حتى من نموذج رخيص. الحارس الحقيقي للجودة ليس نموذجًا أغلى، بل بوابة كود.

ابنِ بتكلفة عالية، انقل التنسيق إلى الكود، شغّل بتكلفة منخفضة

النمط الذي نتّبعه فعليًا يتكوّن من ثلاث خطوات.

أولًا، تُبنى المهارة بنموذج مكلف. في المرحلة الأولى يوجد هامش كبير للحكم ولا بد من استخراج حالات الفشل وتصفيتها، فيثبت النموذج الجيد قيمته هنا. ثانيًا، يُستخرج الجزء الحتمي (deterministic) من المهارة إلى كود: العرض، وتوحيد القيم المسموحة، والتحقق من الطول، وإزالة التكرار، وتجميع JSON — أي كل ما لا حاجة لأن يحلّه النموذج بطريقة مختلفة في كل مرة. ثالثًا وأخيرًا، يُخفَّض نموذج العامل (worker) إلى مستوى أرخص. الآن يقتصر دور النموذج على توليد المحتوى فقط، بينما يملك الكود الأرقام والتنسيق والحكم النهائي.

سنُظهر لماذا هذا النمط آمن من خلال كود فعلي. فيما يلي نتيجة تشغيل بوابة التحقق الخاصة بمهارة تُلخِّص خط زمن تويتر إلى Slack، على مخرجات حقيقية. هذه المهارة تعمل خمس مرات يوميًا، وأنتجت أكثر من 1000 سجل تراكمي، وكانت تعتمد سابقًا على Opus لكل تغريدة، أما الآن فتعمل بـSonnet.

$ tweet_validate.py --dir outputs/twitter/hjguyhan
validated: 2/2 passed; decisions=1 (code-capped)
{"status": "ok", "passed": 2, "total": 2, "decisions": 1, "failed_ids": []}

هنا، عدد الأحرف وعدد الروابط وحالة الـenum ونتيجة النجاح ليست قيمًا زعمها النموذج، بل قيمًا أعاد الكود حسابها فعليًا من النص نفسه. وحتى أعلام القرار (decision flags) قصّها الكود إلى أعلى عدد محدد. هذه البوابة تعمل بالطريقة نفسها بغض النظر عن النموذج الذي كتب المحتوى. لهذا لم تهتز الجودة عند خفض العامل من Opus إلى Sonnet.

الموجز اليومي الخاص بفريق مبيعات CRM يتبع البنية ذاتها. فيما يلي مخرجات فعلية من عارض (renderer) يستقبل JSON البيانات ويُخرج تنسيق Slack مباشرة عبر الكود.

$ sales_crm_render_brief.py --data brief.json --print-slack
:sunny: *ThakiCloud 영업 데일리 브리프* — 2026-07-03 (목)
*③ 긴급 액션*
1. [A사] GPU 증설 RFP 마감 임박 <전자신문 2026-07-02>
...

أرقام العناوين، وصياغة الروابط، وبنية السلاسل النصية (threads) — كلها يضيفها الكود. وبذلك انتقلت الأرشفة والتنسيق إلى Sonnet والكود، بينما احتُفظ عمدًا بمستوى نموذج أعلى فقط لتوليد النص الموجَّه مباشرة إلى العميل. لا يختلط ما يُخفَّض بما يُبقى كما هو.

مهارة تحسين التكلفة: قِس، خفّض، تراجع

بعد نقل التنسيق إلى الكود، يصبح السؤال التالي: “هل يمكن فعلًا خفض هذه المهارة إلى نموذج أرخص؟” وهذا سؤال لا يجوز أن يُحسم بتقدير بشري. لذلك بنينا مهارة لتحسين التكلفة تُشغّل مهمة فعلية على كل من المستوى الأرخص والمستوى الحالي، ثم يُقيّم الكود النتيجة ويصدر الحكم.

الآلية بسيطة. تُختار مهمة تمثيلية واحدة وتُنفَّذ على النموذج الرخيص والنموذج الحالي كليهما، ثم يمنح نموذج حَكَم درجات لكل بُعد فقط، ويحسب الكود من هذه الدرجات القرار النهائي. إن لم توجد فجوة استدلال حقيقية وكان فرق الدرجة الإجمالي ضمن الحد المسموح، يُخفَّض المستوى؛ وإن وُجدت فجوة استدلال، يبقى كما هو. تُسجَّل عملية الخفض في ملف سياسة مركزي، وإن فشلت المهارة لاحقًا بشكل متكرر تُرقَّى تلقائيًا مرة أخرى إلى النموذج الأعلى. سياسة ثنائية الاتجاه: توفير في التكلفة، لكن ارتفاع فوري إلى النموذج الأغلى عند أول اهتزاز في الجودة.

المهم هنا أن هذه البوابة ليست “آلة خفض”، بل “آلة حقيقة”. قِسنا فعليًا إمكانية خفض مهارة humanizer (المهارة التي تُزيل آثار الكتابة الآلية) المستخدمة كثيرًا، من Sonnet إلى Haiku. وكانت النتيجة كالتالي:

$ cost_evolve.py evolve --skill humanizer
{ "skill": "humanizer", "current": "sonnet", "candidate": "haiku",
  "headline_gap": 2.0, "reasoning_gaps": 1, "decision": "hold",
  "reason": "1 reasoning gap(s): rephrasing_naturalness",
  "recommend": "먼저 포맷 갭을 코드로 프로그램화하라" }

رفضت البوابة الخفض، لأن Haiku تراجع فعليًا في القدرة على إعادة صياغة الجمل بأسلوب طبيعي. وفي الوقت نفسه أشارت إلى ثلاث فجوات تنسيقية وأوصت بأن “هذا يمكن نقله إلى الكود”. هذا بالضبط الحكم الذي نريده. لا يُخفَّض أي شيء عشوائيًا، بل يُنتقى فقط ما يثبت البيانات أنه قابل للخفض بأمان.

Paxis يُنفّذ هذا القرار تلقائيًا كل ليلة

التحسين اليدوي مرة واحدة لا يدوم طويلًا، لأن عدد المهارات يستمر في التزايد والنماذج تتغير باستمرار. لذلك يُنفّذ Paxis هذا القرار تلقائيًا كل ليلة. كل ليلة يُكتشف مرشحو الخفض، ويُتحقَّق منهم عبر بوابة الكود، ويُخفَّض ما هو آمن فقط، ويُبلَّغ عن الباقي مع الأسباب.

وهذا يعمل فعليًا الآن. مخرجات المرشحين لآخر ثلاثة أيام لا تزال محفوظة كما هي.

# cost-evolve candidates — 2026-07-03
10 candidate(s), ranked by est. savings.
| lever            | target   | action                              |
| model-deescalate | sod-ship | opus -> sonnet, apply only if PASS  |
| model-deescalate | eod-ship | opus -> sonnet, apply only if PASS  |
| mcp-prune        | codegraph| 미사용 MCP 서버 비활성화             |
| format-determinism | ...    | 포맷을 코드로 추출 후 강등 재시도    |

ثمة نقطة نودّ الإشارة إليها بصراحة هنا: هذا النظام لا يخفّض التكلفة بعدوانية. sod-ship وeod-ship أعلاه كانا قد رُقّيا إلى نموذج أعلى قبل يوم واحد فقط، فقررت البوابة تأجيل الخفض بحجة أن “التراجع الآن مبكر جدًا”. النظام لا يخفّض فعليًا إلا حين يتوفر يقين كافٍ. في المقابل، القيمة الافتراضية لمعظم المهارات هي أصلًا المستوى الرخيص. المهارات القليلة المثبَّتة على نموذج أعلى هي فقط تلك التي تكون الجودة فيها حاسمة (تحسين المقالات، الرسوم الكاريكاتورية الإخبارية، النصوص الموجهة مباشرة للعملاء)، أما الباقي فيصعد مؤقتًا فقط حين تتطلب البيانات ذلك.

خلاصة الوضع كالتالي:

المهارة	الحالة الحالية	القرار	السبب
twitter-timeline	Sonnet	تم الخفض	بعد نقل التنسيق إلى الكود، Opus→Sonnet، يعمل بشكل طبيعي يوميًا
humanizer	Sonnet	مؤجَّل	Haiku أضعف في إعادة الصياغة الطبيعية
sod/eod-ship	Opus	مؤجَّل	رُقّي بالأمس فقط، التراجع مبكر
الغالبية الافتراضية	Sonnet	كما هي	المستوى الرخيص افتراضي أصلًا

النموذج المكلف هو الاستثناء، والنموذج الرخيص هو الأصل. وهذه الحدود تُعاد رسمتها بالبيانات كل ليلة.

إن كان لديك GPU محلي، يمكنك تشغيل المستوى الرخيص بنفسك

كل ما سبق يتناول خفض المستوى ضمن واجهات برمجة التطبيقات (API) التجارية، لكن الفرق التي تمتلك وحدات معالجة رسومية (GPU) محلية يمكنها أن تذهب خطوة أبعد، إذ يمكنها تشغيل جزء كبير من المستوى الرخيص مباشرة عبر نماذج مفتوحة الأوزان صغيرة الحجم. ارتقت مؤخرًا قدرة النماذج المفتوحة الأوزان الصغيرة والمتوسطة على استدعاء الأدوات إلى مستوى صالح للاستخدام العملي.

نموذج Gemma 4 من Google مُتاح بترخيص Apache 2.0، وتعمل نسخه الصغيرة مثل E2B وE4B على الأجهزة المحمولة أو اللوحات من فئة Jetson مباشرة على الجهاز نفسه (on-device). هذا الحجم مناسب تمامًا للتوجيه والتصنيف واستدعاء الأدوات البسيط كعامل. ونموذج GLM 5.2 من Zhipu مفتوح الأوزان برخصة MIT، ويُبرز استخدامًا وكيليًا للأدوات يجعله يقترب في الأداء من النماذج الطليعية المغلقة. أما Kimi K2.7-Code من Moonshot فهو نموذج مفتوح الأوزان متخصص في البرمجة وتنفيذ الأدوات متعدد الخطوات. وقد ترسّخ في الصناعة بالفعل نمط يُوجَّه فيه 60 إلى 80 بالمئة من حركة مرور الوكلاء إلى هذه النماذج المفتوحة الأوزان، بينما تُرفَع فقط النسبة الصعبة فعلًا، أي نحو 20 بالمئة، إلى واجهات النماذج الطليعية.

ما نريد قوله بسيط: معظم عمل الفريق ليس إبداعًا عالي الصعوبة، لذا يكفيه نموذج صغير يعمل محليًا. أما النموذج الطليعي فيُبقى جانبًا ليُستخدم فقط في الحالات القليلة الصعبة فعلًا.

إن احتجت مساعدة

إن كنت تدير فريقًا يريد تحسين التكلفة عبر الجمع بين أحدث النماذج المفتوحة الأوزان مثل GLM 5.2 وKimi K2.7-Code، تواصل معنا. سنساعدك في تصميم أي المهام تُخفَّض إلى أي مستوى، وما الذي يجب أن يحرسه الكود.

وإن كان لديك أي قدر من GPU محلي، نوصيك باستخدام منصة الاستدلال Metis الخاصة بنا. فهي تُحسّن الاستدلال وفق العتاد المتوفر لديك، ما يتيح لك تشغيل النماذج الصغيرة المفتوحة الأوزان بأعلى كفاءة ممكنة على أجهزتك الخاصة.

البنية التي يكون فيها النموذج الرخيص هو الأصل والنموذج المكلف هو الاستثناء لا تكتمل بإعداد واحد. تحتاج إلى حلقة تقيس كل ليلة، وتخفّض فقط حين يكون ذلك آمنًا، وتتراجع عند أي اهتزاز. Paxis يقدّم هذه الحلقة كنظام متكامل.