عادةً ما تعني «رموز المطالبة» الشيء نفسه. لكن هذه التسمية قد تكون مضللة، لأن المطالبة قد تتضمن مواد أضافها التطبيق أو واجهة API.
الطلب بأكمله، وليس رسالتك فقط
تخيّل أنك كتبت «لخّص التقرير الأخير» في مربع محادثة. هذه الجملة جزء واحد من الإدخال. وقد يرسل التطبيق أيضًا:
- تعليمات تحدد دور المساعد وسلوكه؛
- رسائل المستخدم والمساعد السابقة؛
- التقرير نفسه أو المقاطع المسترجعة منه؛
- تعريفات الأدوات التي يمكن للنموذج استدعاؤها؛
- النتائج التي تُرجعها إحدى الأدوات؛ و
- علامات تحدد الأدوار أو حدود الرسائل أو الموضع الذي ينبغي أن يبدأ عنده التوليد.
يمكن أن تصبح كل هذه الأجزاء رموز إدخال. وتعتمد المجموعة الدقيقة على التطبيق وواجهة API والنموذج والميزات المفعّلة.
وهذا يمنح رموز الإدخال حدًا دقيقًا: فهي تُعرَّف من خلال دورها في طلب واحد. وقد يصبح النص الذي ولّده النموذج كمخرج في إحدى الجولات إدخالًا في الجولة التالية عندما يعيده التطبيق ضمن سجل المحادثة.
كيف يتحول الطلب إلى رموز إدخال
يبدو المسار من الواجهة إلى النموذج كما يلي:
system instructions ─┐
conversation history ├─> request formatting ─> tokenizer ─> input token IDs ─> model
documents and tools ┤
current message ─────┘أولًا، يجمع التطبيق السياق الخاص بالطلب. قد لا يحتوي استدعاء API بسيط إلا على مطالبة واحدة. أما المساعد المستخدم في بيئة إنتاجية فقد يضيف التعليمات، والسجل، والمستندات المسترجعة، ومخططات الأدوات، ومحتوى آخر.
بعد ذلك، تنسّق الخدمة تلك المواد للنموذج المحدد. ولا تتلقى نماذج المحادثة نسخة مرئية من المحادثة تتضمن فقاعات رسائل ملوّنة، بل تتلقى تسلسلًا يُبنى باستخدام قالب محادثة أو تنسيق داخلي مكافئ. وتوضح وثائق واجهة المحادثة في vLLM هذه الخطوة صراحةً: إذ تُحوَّل الرسائل المنظَّمة إلى مطالبة نصية باستخدام قالب محادثة النموذج.
ثم يحوّل مُرمِّز الرموز التسلسل المنسَّق إلى معرّفات رموز. وكما يوضح مرجع مُرمِّز الرموز في Hugging Face، قد يتضمن ذلك التطبيع، وتقسيم النص إلى أجزاء، وربط الأجزاء بالمعرّفات، وإضافة الرموز الخاصة. وبما أن النماذج قد تستخدم مُرمِّزات رموز وقوالب مختلفة، فإن تطابق النص الظاهر لا يضمن تطابق عدد رموز الإدخال.
وأخيرًا، يعالج النموذج تسلسل الرموز هذا ويبدأ التوليد. وتُبلغ بيانات استخدام الاستجابة عن الطريقة التي احتسب بها موفّر الخدمة الطلب.
مثال تطبيقي
لنفترض أن تطبيقًا أبلغ عن سجل الطلب التوضيحي التالي:
- تعليمات النظام: 36 رمزًا
- تعريفات الأدوات: 74 رمزًا
- سجل المحادثة: 160 رمزًا
- رسالة المستخدم الحالية: 12 رمزًا
- تنسيق الرسائل والرموز الخاصة: 15 رمزًا
يحتوي الطلب على 297 رمز إدخال، رغم أن الرسالة الحالية لا تحتوي إلا على 12 رمزًا.
والآن، لنفترض أن الاستجابة تحتوي على 60 رمزًا مولَّدًا. هذه الرموز الستون هي رموز المخرج لهذا الطلب. وفي الجولة التالية، قد يضمّن التطبيق تلك الإجابة في السجل. وعندئذٍ يسهم النص نفسه في عدد رموز الإدخال للطلب التالي.
يغيّر التخزين المؤقت معالجة الإدخال المتكرر وسعره، لا دوره المفاهيمي. فإذا كان 200 من رموز الإدخال البالغ عددها 297 تأتي من بادئة قابلة لإعادة الاستخدام، فقد يُبلغ موفّر الخدمة عن هذه الرموز المئتين أو يسعّرها بصورة منفصلة بوصفها إدخالًا مخزّنًا مؤقتًا. لكنها تظل سياقًا مُقدَّمًا إلى النموذج. فعلى سبيل المثال، يقسم Anthropic الطلبات المخزّنة مؤقتًا بين حقول استخدام متعددة، بينما يعرض OpenAI الإدخال المخزّن مؤقتًا كفئة إدخال مميزة. اقرأ دائمًا تعريفات الحقول الحالية بدل افتراض أن الحقل المسمى input_tokens يمثل الإجمالي الكامل.
كيفية عدّ رموز الإدخال
في المسودة الأولية، يمكن لمُرمِّز رموز متوافق مع النموذج تقدير النص العادي. لكنه لا يستطيع إعادة إنتاج العدد الكامل لواجهة API بصورة موثوقة إلا إذا طبّق أيضًا قالب الرسائل نفسه، وتنسيق الأدوات، والرموز الخاصة، وترميز الوسائط، والإضافات من جانب موفّر الخدمة.
للحصول على عدد الطلب الكامل، استخدم نقطة النهاية الخاصة بعدّ الرموز لدى موفّر الخدمة عندما تكون متاحة. إذ تقبل نقطة نهاية عدّ الرموز في Anthropic الرسائل، ومطالبات النظام، والأدوات، والصور، وملفات PDF. كما يميّز دليل الرموز في Google بين أعداد الإدخال السابقة للتنفيذ والاستخدام المُعاد بعد التوليد. وتشير إرشادات OpenAI الخاصة بعدّ الرموز إلى أن بنية الطلب والمدخلات غير النصية قد تؤثران في العدد الكامل.
تعامل مع العدد السابق للتنفيذ باعتباره تقديرًا للسعة والتكلفة. وبعد الطلب، احتفظ باستجابة الاستخدام من موفّر الخدمة باعتبارها السجل الفعلي لكيفية عدّ تلك المكالمة وفوترتها.
لماذا تهم رموز الإدخال؟
التكلفة
تسعّر كثير من واجهات API الإدخال، والإدخال المخزّن مؤقتًا، والمخرج بصورة منفصلة. وسجل التكلفة المفيد هو:
input cost =
uncached input tokens × uncached input rate
+ cached input tokens × cached input rateتتغير الأسعار والفئات، لذا استخدم صفحة الأسعار الحالية لدى موفّر الخدمة بدل نسخ سعر إلى منطق التطبيق. وقد تجعل تعليمات النظام الطويلة، وتعريفات الأدوات المتكررة، والمقاطع المسترجعة الكبيرة، وسجل المحادثة المتنامي، الإدخالَ الجزء الأكبر من عبء العمل.
السياق المتاح
تشغل رموز الإدخال مساحة في سياق النموذج. وقد يترك المزيد من الإدخال مساحة أقل للاستجابة، تبعًا لحدود النموذج وواجهة API. لذلك فإن إرسال سياق إضافي لا يعني سعة مجانية؛ فهو ينافس التعليمات والأدلة وأدوار المحادثة الأخرى على انتباه النموذج وميزانية الرموز.
زمن الاستجابة
يجب على النموذج معالجة الإدخال قبل أن يتمكن من إنتاج أول رمز مخرج. وتتطلب المدخلات الأكبر عمومًا مزيدًا من عمل معالجة المطالبة. وقد تؤدي إعادة استخدام بادئة مؤهلة ومخزنة مؤقتًا إلى تقليل هذا العمل، لكن سلوك التخزين المؤقت وفوائده يختلفان باختلاف موفّر الخدمة.
القياس
تساعد أعداد رموز الإدخال في مقارنة الطلبات على مستوى أكثر فائدة من عدد الأحرف أو الكلمات. وقد تكشف عن مخطط أدوات ضخم، أو نظام استرجاع يرسل مقاطع كثيرة جدًا، أو سجل محادثة ينمو مع كل جولة.
المفاهيم الخاطئة الشائعة
«رموز الإدخال هي الكلمات التي كتبتها»
كلماتك ليست إلا الجزء الظاهر. فقد يتضمن الطلب الموجَّه إلى النموذج أيضًا التعليمات، والسجل، والمستندات، والأدوات، والوسائط، والتنسيق.
«كل كلمة تساوي رمز إدخال واحدًا»
قد يكون الرمز كلمة، أو جزءًا من كلمة، أو علامة ترقيم، أو وحدة أخرى خاصة بالنموذج. وتختلف حدود الرموز باختلاف مُرمِّز الرموز. ويتناول ما الرمز في الذكاء الاصطناعي؟ تلك الوحدة الأساسية.
«الرموز المخزنة مؤقتًا لم تعد رموز إدخال»
الرموز المخزنة مؤقتًا هي إدخال معاد استخدامه. وقد يغير التخزين المؤقت مقدار الحوسبة والسعر وحقول الاستخدام، لكن البادئة المخزنة مؤقتًا تظل تسهم في سياق الطلب.
«رسائل المساعد هي دائمًا رموز مخرج»
تكون رسائل المساعد مخرجًا عند توليدها. أما إذا أُدرجت رسالة المساعد في سجل طلب لاحق، فهي إدخال لذلك الطلب اللاحق. يصف الإدخال والمخرج جانبي الطلب، ولا يصفان نوعين دائمين من النص.
«يعطي مُرمِّز الرموز المحلي عدد الفوترة»
قد يعطي عددًا قريبًا للنص. لكنه قد يفوّت علامات قالب المحادثة، ومخططات الأدوات، والمرفقات، والتنسيق الذي يضيفه موفّر الخدمة. استخدم بيانات الاستخدام بعد الطلب من واجهة API لسجلات الفوترة.
كيف تندرج رموز الإدخال ضمن النظام الأوسع
رموز الإدخال هي التسلسل الذي يبدأ به النموذج عند تنفيذ طلب. وتُولَّد رموز المخرج بعد ذلك التسلسل، بينما تمثل رموز الإدخال المخزنة مؤقتًا تقسيمًا فرعيًا للإدخال من ناحية المعالجة والفوترة. وتشرح هذه الفئات مجتمعة معظم سجل الرموز الظاهر في استجابات واجهات API وصفحات الأسعار.
العادات المهمة هي قياس الطلب المُجمَّع. عندما تنتج رسالة مستخدم قصيرة عددًا كبيرًا على نحو مفاجئ، افحص تعليمات النظام، والسجل، والمواد المسترجعة، والأدوات، والتنسيق قبل إلقاء اللوم على مُرمِّز الرموز.
إلى أين تذهب بعد ذلك
افحص استجابة حقيقية من واجهة API وحدد كل حقل استخدام يسهم في إجمالي الإدخال. ثم شغّل أداة العد السابقة للتنفيذ لدى موفّر الخدمة على الطلب نفسه، وقارن التقدير بالاستخدام النهائي. وإذا كانت حدود الرموز نفسها غير واضحة، فابدأ بموضوع ما الرمز في الذكاء الاصطناعي؟ ثم انتقل إلى ما رموز المخرج؟، ثم استخدم رموز الإدخال مقابل رموز المخرج ورموز الاستدلال لمقارنة فئات المحاسبة الثلاث جميعها.