مسرد مصطلحات توكنات الذكاء الاصطناعي

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

في اللغة الإنجليزية، يعادل التوكن الواحد تقريبًا 4 أحرف أو نحو ثلاثة أرباع الكلمة. الكلمات القصيرة والشائعة مثل “the” و“is” و“in” غالبًا ما تكون كل منها توكنًا واحدًا. أما الكلمات الأطول أو الأقل شيوعًا فتنقسم إلى جزأين أو أكثر. تُحسب علامات الترقيم والمسافات البيضاء والأرقام كل منها على حدة، وقد تكون تجزئة الشيفرة البرمجية أو الكتابات غير اللاتينية أكثر تكلفة من النثر الإنجليزي.

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

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

تأتي كل عائلة نماذج مزوّدة بمُجزّئ توكنات وقاموس خاصين بها. وهذا أمر مهم لأن النص نفسه قد ينتج عنه عدد توكنات مختلف باختلاف النموذج المستخدم. فجملة تُجزَّأ إلى 50 توكنًا مع GPT-4o قد تنتج 47 أو 55 توكنًا مع Claude أو Gemini. ينشأ هذا الاختلاف من حجم القاموس، وقواعد الدمج المكتسَبة أثناء التدريب، وطريقة تعامل المُجزّئ مع المسافات البيضاء والأحرف الخاصة.

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

ترميز الأزواج البايتية (BPE) هو خوارزمية مستوحاة من الضغط تبني قاموسًا فرعيًا عبر الدمج التكراري للزوج الأكثر تكرارًا من الوحدات المتجاورة. تبدأ العملية من البايتات أو الأحرف الفردية، وتطبّق آلاف عمليات الدمج حتى يصل القاموس إلى حجم مستهدف (على سبيل المثال 50,000 أو 100,000 مُدخَل).

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

تستخدم نماذج GPT من OpenAI تقنية BPE عبر مكتبة tiktoken الخاصة بها. كما تستخدم نماذج أخرى كثيرة إصدارات من BPE، بما في ذلك بعض نماذج Llama وMistral. وتختلف قواعد الدمج والقاموس المحدد باختلاف التطبيقات، وهذا هو السبب في أن النص نفسه ينتج عنه أعداد مختلفة في نماذج مختلفة حتى عندما يستخدم كلاهما BPE.

SentencePiece هي مكتبة تجزئة طوّرتها Google وتتبع نهجًا مختلفًا عن BPE على طراز tiktoken. فبدلًا من اشتراط خطوة تجزئة أولية خاصة باللغة (كالتقسيم عند المسافات قبل تطبيق قواعد الدمج)، تتعامل SentencePiece مع المدخل بأكمله كتدفق خام من أحرف يونيكود، بما فيها المسافات. وتُمثَّل المسافات برمز خاص يشبه الشرطة السفلية قد تراه في المخرجات المُجزَّأة (وغالبًا ما يظهر كحرف “_” أو رمز يونيكود خاص).

هذا التصميم يجعل SentencePiece غير مرتبطة بلغة معيّنة. فهي تتعامل مع اليابانية والصينية والعربية وغيرها من الكتابات التي لا تستخدم المسافات كفواصل بين الكلمات بطبيعية تماثل تعاملها مع الإنجليزية. وتدعم خوارزميتين رئيسيتين: BPE وتجزئة نموذج اللغة أحادي الوحدة (unigram).

تستخدم نماذج مثل Gemini وLlama وT5 والعديد من النماذج متعددة اللغات SentencePiece. ونظرًا لتعاملها المختلف مع المسافات البيضاء، قد تُجزَّأ الجملة الإنجليزية نفسها إلى عدد مختلف قليلًا عمّا ستنتجه مع BPE الخاص بـ tiktoken، حتى مع حجم قاموس مشابه. وهذا أحد الأسباب الرئيسية وراء عدم قابلية تبادل أعداد التوكنات بين مزوّدي الخدمة.

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

تأتي tiktoken مزوّدة بعدة ترميزات مسمّاة تقابل أجيالًا مختلفة من النماذج. أهمّها اثنان: cl100k_base، الذي يغطي GPT-3.5 Turbo ونماذج سلسلة GPT-4، وo200k_base، الذي يغطي GPT-4o وGPT-5 ونماذج الاستدلال في سلسلة o. يشير الرقم في الاسم إلى الحجم التقريبي للقاموس: 100,000 و200,000 توكن على التوالي. القاموس الأكبر يعني أن الترميز الأحدث يمكنه تمثيل عناصر أكثر في توكن واحد، ما يؤدي غالبًا إلى أعداد توكنات أقل قليلًا للنص نفسه.

تشغّل حاسبة التوكنات هذه ترميزات متوافقة مع tiktoken مباشرة داخل متصفحك باستخدام بنية WebAssembly، بحيث لا يغادر نصك جهازك أبدًا، وتكون الأعداد الخاصة بنماذج OpenAI دقيقة.

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

نمت أحجام نوافذ السياق بسرعة عبر الأجيال المختلفة. كان لدى GPT-3 المبكر نافذة بحجم 4,096 توكنًا. وتدعم النماذج المتطورة الحالية نوافذ تُقاس بمئات الآلاف أو حتى الملايين من التوكنات، ما يجعل من الممكن عمليًا تمرير قواعد شيفرة كاملة أو كتب كاملة في طلب واحد.

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

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

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

صيغة تكلفة الطلب بسيطة:

التكلفة الإجمالية = (عدد توكنات المدخلات / 1,000,000) × سعر المدخلات لكل مليون + (عدد توكنات المخرجات / 1,000,000) × سعر المخرجات لكل مليون

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

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

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

يكون التخزين المؤقت للموجّهات ذا قيمة عالية بشكل خاص عندما تظهر بادئة كبيرة وثابتة في طلبات عديدة: رسالة نظام طويلة، أو مستند مرجعي، أو ملف شيفرة برمجية، أو مجموعة من الأمثلة قليلة اللقطات (few-shot). فإذا كان تطبيقك يضيف دائمًا مستندًا من 10,000 توكن قبل كل سؤال من المستخدم، فإن تخزين هذا المستند مؤقتًا يمكن أن يقلّل تكاليف المدخلات لكل طلب بشكل كبير.

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

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

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

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

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

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

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

تشمل التقنيات الشائعة للبقاء ضمن الميزانية اختصار رسائل النظام، والحد من عدد الأجزاء المسترجَعة في خطوط معالجة RAG، واقتطاع أو تلخيص أدوار المحادثة القديمة، وتقييد معامل max_tokens لمنع المخرجات غير المنضبطة.

تقدير ميزانيتك قبل البناء أسهل بكثير من تصحيح تجاوز الميزانية في بيئة الإنتاج. استخدم حاسبة التوكنات لقياس موجّهاتك ومعرفة موقع عدد التوكنات لديك بدقة قبل الالتزام بنموذج أو مستوى تسعير معيّن.