ثلاثية تعظيم الرموز · الجزء الأول من 3: تعظيم الرموز هو المقياس الجديد لعدد أسطر التعليمات البرمجية

ما هو توكن ماكسينج؟

توكن ماكسينج /ˈtoʊkənˌmæksɪŋ/ — ممارسة تحسين سير عمل الذكاء الاصطناعي لاستهلاك التوكنات بدلاً من تحقيق النتائج التجارية.

يحدث هذا عندما تتعامل الفرق مع عدد التوكنات كمقياس للإنتاجية: حيث تستدعي الوكلاء أنفسهم بشكل متكرر، وتتضخم المطالبات لإرسال "سياق" لا يُقرأ أبدًا، وتفضل منطق التوجيه النماذج باهظة الثمن لأنه لا أحد يفقد وظيفته لاختيار Opus بدلاً من Haiku. المهندسون الأذكياء يفعلون ما يفعله المهندسون الأذكياء دائمًا — إنهم يحسنون الرقم المرئي.

في عام 2026، كل لوحة تحكم داخلية للذكاء الاصطناعي، وكل عرض تقديمي للعائد على الاستثمار من الموردين، وكل مراجعة ربع سنوية تظهر نفس العنوان الرئيسي: التوكنات المستهلكة. تتناول هذه المقالة أنماط الفشل الأربعة على مستوى المؤسسة التي تختبئ داخل هذا الرقم الواحد — الإفراط في استخدام النماذج المتميزة، حشو السياق، حلقات الوكيل، وانحراف أداة تقسيم التوكنات — والضوابط المحددة للبوابة التي تمنع كل منها من التراكم لتصبح بند فاتورة بمئات الآلاف.

TL;DR  التوكنات هي تكلفة مدخلات، وليست قيمة مخرجات. قم ببناء الضوابط التي تتيح لك القياس والحوكمة لكليهما.

كيف يتم التلاعب بمقاييس استخدام الذكاء الاصطناعي

في عام 1976، لاحظ الاقتصادي البريطاني تشارلز جودهارت: "عندما يصبح المقياس هدفًا، فإنه يتوقف عن أن يكون مقياسًا جيدًا." أعادت هندسة البرمجيات اكتشاف هذا في الثمانينيات من خلال مقاييس إنتاجية عدد سطور التعليمات البرمجية، والتي أنتجت برامج أطول، وليست أفضل. تجاوزت الصناعة هذه المرحلة. ومع ذلك، في عام 2026، تظهر كل لوحة تحكم داخلية للذكاء الاصطناعي، وكل عرض تقديمي للعائد على الاستثمار من الموردين، وكل مراجعة ربع سنوية نفس المقياس في ثوب جديد قليلاً: التوكنات المستهلكة.

الرموز ليست سيئة. حجم الرموز ليس سيئًا. السيء هو التعامل مع عداد الرموز كلوحة صدارة. لحظة أن يصبح "أكثر الرموز هذا الأسبوع" مرئيًا اجتماعيًا، يفعل المهندسون الأذكياء ما يفعله المهندسون الأذكياء دائمًا: تحسين الرقم المرئي. يلصقون سياقات أكبر. يوجهون الطلبات إلى نماذج مميزة بينما يكفي نموذج أصغر. يبنون وكلاء يستدعون أنفسهم بشكل متكرر. يتلاعبون بالمقياس. لدينا اسم لهذا الآن: tokenmaxxing.

"Tokenmaxxing" هو ما يحدث عندما يصبح "استخدام الذكاء الاصطناعي" بديلاً لـ "قيمة الذكاء الاصطناعي" — ويتم التلاعب بهذا البديل. الحل الدائم الوحيد هو عدم السماح للبديل بأن يصبح الهدف في المقام الأول.

كيف يعمل تسعير رموز نماذج اللغة الكبيرة (LLM) في الواقع

قبل مناقشة أوضاع الفشل، يستحق هيكل التكلفة الأساسي نظرة فاحصة. اعتبارًا من أبريل 2026، تبدو أسعار واجهة برمجة التطبيقات (API) من Anthropic للنماذج الرائدة كالتالي:

تبرز حقيقتان هيكليتان. أولاً، تكلف رموز الإخراج خمسة أضعاف تكلفة رموز الإدخال عبر جميع النماذج الرائدة. سير العمل الذي ينتج محتوى طويلاً هو في الأساس أكثر تكلفة من ذلك الذي ينتج تصنيف JSON، حتى مع إدخال متطابق. ثانيًا، نسبة Opus إلى Haiku هي 5 أضعاف في الإدخال و 5 أضعاف في الإخراج. توجيه مهمة تصنيف النية إلى Opus بدلاً من Haiku ليس تحسينًا هامشيًا — بل هو دفع 5 أضعاف السعر لقدرة لا تستخدمها.

هناك حقيقة ثالثة، يسهل إغفالها: نفس المطالبة لا تنتج نفس عدد الرموز عبر إصدارات النموذج المختلفة. يأتي Opus 4.7 من Anthropic مع مُحلل رموز جديد يمكنه إنتاج ما يصل إلى 35% رموزًا إضافية مقارنة بـ Opus 4.6 لنفس النص المدخل — ويظهر هذا بشكل أوضح في التعليمات البرمجية والبيانات المنظمة واللغات غير الإنجليزية. تظل أسعار الرموز الفردية دون تغيير، ولكن التكلفة الفعلية لكل طلب يمكن أن ترتفع بنسبة تصل إلى 35% عند الترحيل الصامت. الأسعار مستقرة، والفواتير ليست كذلك.

إذا كان تتبع التكلفة الوحيد لديك هو فاتورة المزود التي تصل في نهاية الشهر، فإن تغيير مُحلل الرموز يمكن أن يضيف بهدوء نسبة مئوية من رقمين إلى فاتورتك قبل أن تتاح لك أي فرصة للرد. هذا بالضبط ما تهدف الحوكمة عند البوابة إلى منعه.

أوضاع الفشل الأربعة لـ "Tokenmaxxing"

عبر عمليات نشر الذكاء الاصطناعي للمؤسسات، نرى تكرار نفس الأنماط الأربعة لاستهلاك الرموز. كل منها هو خيار تصميم لسير العمل يتفاقم على نطاق واسع، وكل منها يبدو اقتصاديًا بمعزل عن غيره — وهذا هو بالضبط سبب بقائها.

1. الإفراط في استخدام النماذج المميزة

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

766,500 دولار سنويًا من الهدر الصافي في التوجيه على سير عمل واحد. عادةً ما يكون الفرق في دقة التصنيف بين Haiku و Opus في مهمة تحديد النية الخاصة بالمجال أقل من نقطتين مئويتين بعد ضبط دقيق بسيط أو مطالبة قليلة الأمثلة. القيمة الإضافية للقدرة حقيقية للمهام الصعبة؛ أما للمهام الروتينية فهي مجرد زينة.

2. حشو السياق

وضع الفشل الثاني هو استخدام نافذة السياق كمؤشر بحث. يقوم مهندس يبني وكيل مراجعة التعليمات البرمجية بإلقاء المستودع بأكمله (500 ألف رمز) في المطالبة "فقط من باب الاحتياط". يرسل روبوت دعم 50 ألف رمز من التذاكر التاريخية في كل دور "للسياق". هذا يعمل — يعيد النموذج إجابة معقولة — وتتزايد الفاتورة مع حجم البيانات الملقاة، وليس مع ما كان ذا صلة بالفعل.

البديل المعماري هو الاستخدام النشط للأدوات عبر بروتوكول سياق النموذج (MCP). بدلاً من إضافة كل السياق الممكن مسبقًا، يستدعي النموذج أدوات استرجاع تعيد فقط المقتطفات ذات الصلة. تفيد TrueFoundry بأن هذا يوفر ما يصل إلى 99% من رموز الاستدلال مقارنة بحشو السياق، مع قياس الحمل الزائد لاستدعاء الأداة بحوالي 10 مللي ثانية.

3. حلقات الوكلاء (القاتل الصامت للميزانية)

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

4. انجراف مُحلل الرموز

هذا هو نمط الفشل الذي لم يتسبب فيه أي مهندس. يأتي Anthropic's Opus 4.7 مع مُجزئ رموز جديد يحول نفس المدخلات إلى عدد رموز أكبر يتراوح بين 1.0 و 1.35 مرة مقارنة بالإصدار 4.6، مع الحد الأعلى الذي ينطبق على الكود والبيانات المهيكلة. نفس المطالبة. نفس المهمة. نفس بطاقة الأسعار المعلنة. فاتورة أعلى بنسبة تصل إلى 35%.

بدون قياس عدد الرموز لكل طلب مقسمًا حسب إصدار النموذج، يكون هذا الفارق غير مرئي حتى يظهر كبند في الفاتورة التالية. وبدون طبقة إنفاذ يمكنها تحديد المعدل أو التراجع عندما تتجاوز حالات الشذوذ في عدد الرموز لكل طلب عتبة معينة، لا توجد استجابة تلقائية. الحل ليس "ترحيلات أكثر حذرًا". الحل هو جعل البوابة مصدر الحقيقة لما استهلكه كل طلب فعليًا، في الوقت الفعلي.

أنماط الفشل ← التحكم الذي يصلحها

يتوافق كل نمط فشل مذكور أعلاه مع عنصر أساسي محدد للبوابة. الهدف من الجدول أدناه ليس الادعاء بأن البوابة سحرية؛ بل هو جعل الضوابط ملموسة بما يكفي لتتمكن من تحديد العنصر المفقود عند رؤية العرض.

دورة حياة الطلب المحكومة

لكي تعمل الضوابط المذكورة أعلاه بالفعل، يجب أن تعمل على مسار الطلب، وليس في مستودع تحليلات لاحق. الشكل الشامل للطلب المحكوم عبر بوابة TrueFoundry AI:

‍

ثلاث خصائص لهذه الدورة تهم أنماط الفشل المذكورة أعلاه. البوابة موجودة في مسار الطلب، لذا فإن سياساتها تعمل بالفعل — فقاطع الدائرة الذي لا يرى السجلات إلا بعد ساعة لا يمكنه إيقاف حلقة جامحة. النفقات العامة أقل من 5 مللي ثانية، مما يعني أن البوابة يمكنها التعامل مع حركة المرور الإنتاجية دون اعتراض "أفضل عدم إضافة قفزة". وكل نقطة تفتيش تصدر OpenTelemetry، لذا فإن نفس التتبع الذي يثبت أن الطلب كان محكومًا يغذي أيضًا التحليلات التي تجعل الحوكمة قابلة للضبط.

← نظرة عامة على بوابة TrueFoundry AI

← بنية مستوى البوابة

العنصر الأساسي 1 — غلاف الهوية

يجب أن يحمل كل طلب يصل إلى نموذج بيانات وصفية كافية للإسناد والحوكمة والتدقيق. بدون ذلك، فإن كل عنصر أساسي آخر يخمن. تفرض TrueFoundry ذلك عبر حقول X-TFY-METADATA؛ الطلب الذي لا يحتوي على بيانات وصفية هو خطأ في التكوين، وليس طلبًا.

X-TFY-METADATA: {
  "project": "platform-search",
  "team": "data-platform",
  "user_id": "u_8f1c2d",
  "session_id": "sess_a3f9c2-b71d-4e",
  "workflow_tag": "classify-intent",
  "environment": "production",
  "cost_center": "eng-platform-002"
}

لاحظ اسم النموذج: intent-fast. هذا نموذج افتراضي معرف في البوابة، وليس نقطة نهاية مادية. تحوله البوابة إلى استدعاء مزود ملموس (haiku-4-5، sonnet-4-6، Llama مستضاف ذاتيًا، أو أيًا كان ما تحدده سياسة التوجيه). رمز التطبيق لا يسمي مزودًا أبدًا. إعادة التوجيه من مزود إلى آخر هو فرق في YAML، وليس تغييرًا في الكود.

← مرجع رؤوس الطلبات

← النماذج الافتراضية والتوجيه

العنصر الأساسي 2 — قواطع الدائرة (حدود المعدل + الميزانيات)

تحدد حدود المعدل سرعة الاستهلاك. وتحدد الميزانيات الإجمالي. كلاهما ضروري؛ ولا يكفي أحدهما بمفرده. يمكن لوكيل واحد محدود المعدل أن يستهلك 40 ألف دولار خلال عطلة نهاية أسبوع طويلة إذا كان معدله 12 دولارًا في الساعة ولا يوجد شيء آخر يراقب الإجمالي الجاري. أما الميزانية الواحدة بدون حدود للمعدل فتصل إلى الحد الأقصى مرة واحدة ثم لا يتم تشغيل أي شيء حتى الشهر التالي.

# rate-limit-config.yaml — enforce per-session, per-user, per-tag

name: production-rate-limits
type: gateway-rate-limit-config
rules:
  - id: per-session-loop-guard
    when:
      metadata: {environment: production}
    limit:
      tokens: 200000
      window: 1h
      scope: session    # ← key
    on_breach: hard_block

  - id: per-user-burst
    when:
      subjects: {type: user}
    limit:
      tokens: 5000000
      window: 1d
      scope: user
    on_breach: queue_then_429

  - id: classify-intent-soft-cap
    when:
      metadata: {workflow_tag: classify-intent}
    limit:
      requests: 100000
      window: 1h
    on_breach: fallback_to_haiku   # ← graceful degradation

سلوك "عند الاختراق" هو البطل المجهول. رمز 429 مناسب لأعباء العمل الدفعية؛ أما بالنسبة لتطبيق يواجه العملاء، فإن "العودة إلى هايكو" (fallback_to_haiku) هو ما يحافظ على استمرارية العمل مع احتواء الإنفاق. ويعبر نفس العنصر الأساسي عن كليهما.

# budget-config.yaml — hard ceilings per project per month

name: 2026-q2-project-budgets
type: gateway-budget-config
budgets:
  - id: platform-search-monthly
    scope:
      metadata: {project: platform-search}
    ceiling_usd: 4000
    window: monthly
    alerts:
      - {at_pct: 80,  notify: ["slack:#ai-budget-alerts", "pagerduty:platform"]}
      - {at_pct: 100, notify: ["slack:#ai-budget-alerts", "pagerduty:platform"]}
    on_exceed: fallback_to_cheaper   # uses fallback model from routing config

  - id: intern-sandbox-cap
    scope:
      metadata: {project: intern-sandbox}
    ceiling_usd: 500
    window: monthly
    on_exceed: hard_block            # interns get a hard stop

← تحديد المعدل — النوافذ، النطاقات، سلوكيات التجاوز

← تحديد الميزانية — الحدود القصوى، التنبيهات، والتدهور التدريجي

العنصر الأساسي 3 — توجيه النموذج الافتراضي

إن التحسين الأكثر فعالية للتكلفة في أي نظام ذكاء اصطناعي هو اختيار النموذج المناسب للمهمة المناسبة. والمكان الصحيح لهذا القرار هو التكوين، وليس كود التطبيق. تمنحك النماذج الافتراضية اسمًا منطقيًا (مثل: intent-fast، code-review-strong، support-cheap) يتم تحويله عند بوابة الوصول إلى استدعاء مزود محدد بناءً على الوزن، الأولوية، زمن الاستجابة، أو قواعد العودة الاحتياطية.

# routing-config.yaml — a virtual model with multi-provider fallback

name: intent-fast
type: gateway-load-balancing-config
rule_type: weight-based
rules:
  - id: primary-haiku
    weight: 90
    target:
      provider: anthropic
      model: claude-haiku-4-5
    timeout_ms: 8000

  - id: secondary-bedrock-haiku
    weight: 10                       # 10% A/B for resiliency
    target:
      provider: bedrock
      model: anthropic.claude-haiku-4-5
    timeout_ms: 8000

fallbacks:                           # tried in order on primary failure
  - {provider: openai, model: gpt-4o-mini}
  - {provider: vertex, model: gemini-2.0-flash}

circuit_breaker:
  failure_threshold: 5    # 5 errors in window
  window_seconds: 60
  cooldown_seconds: 30

ثلاث مزايا يوفرها لك ملف YAML هذا. تحسين التكلفة: 90% من حركة المرور السريعة (intent-fast) تتدفق إلى Haiku بسعر 1 دولار/5 دولارات لكل مليون توكن بدلاً من أي إعداد افتراضي قام المطور بتضمينه. المرونة: عندما يحدث انقطاع لدى Anthropic، تتحول حركة المرور تلقائيًا إلى OpenAI أو Vertex؛ يرى المستخدمون تدهورًا بمقدار 200 مللي ثانية، وليس انقطاعًا كاملاً. قابلية نقل المزود: عندما يظهر نموذج جديد، تقوم بتغيير سطر واحد ويتم نشره في الإنتاج. يظل كود التطبيق دون تغيير.

← نظرة عامة على التوجيه / موازنة الحمل

← قائمة المزودين (يدعم أكثر من 1000 نموذج)

معايير المؤسسات — ماذا تعني "بوابة الإنتاج" حقًا

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

العرض الضعيف والعرض القوي

معظم المقترحات الداخلية لاعتماد بوابة تعرض الشيء الخطأ. العرض الضعيف يبيع لوحة تحكم. أما العرض القوي فيبيع البنية التي تجعل لوحة التحكم المفيدة ممكنة من الأساس.

الخطوات التالية

لقد قام الجزء الأول بالعمل التشخيصي: "tokenmaxxing" هو المقياس الجديد لعدد أسطر الكود، وله أربعة أنماط فشل مميزة، وكل منها يتوافق مع عنصر أساسي محدد للبوابة. لقد قدمنا المكونات الثلاثة الأساسية: غلاف الهوية، قواطع الدائرة، وتوجيه النموذج الافتراضي.

يتناول الجزء الثاني هذه العناصر الأساسية ويتوسع ليشمل البنية: الأغلفة الأربعة (الهوية، السياسة، الأمان، قابلية المراقبة) التي تحيط بكل طلب مُدار، وكيف تتألف لتشكل نظامًا يمثل في الوقت نفسه حدودًا أمنية، وسطحًا للتحكم في التكلفة، ومصدرًا للقياس عن بعد التشغيلي. ثم يحول الجزء الثالث هذه البنية إلى إيقاع تشغيلي — لوحات تحكم، بطاقات أداء، تنبيهات، والطقوس التي تمنع استخدام الذكاء الاصطناعي المُدار من الانجراف مرة أخرى نحو "tokenmaxxing" بمجرد تشتت انتباهك.

المقياس الصحيح ليس عدد الرموز المستهلكة. بل هو النتائج المحققة مقابل كل دولار، مع حدود قابلة للإثبات لكيفية إنفاق هذا الدولار. كل ما يلي يهدف إلى جعل هذا المقياس قابلاً للقياس، قابلاً للدفاع عنه، وقابلاً للتطبيق.