چرا مدل‌های هوش مصنوعی کلمات را مثل انسان نمی‌بینند؟ راز Tokenization

Tokenization چیست؟

Tokenization فرآیندی است که طی آن متن خام به واحدهای کوچک‌تری به نام Token تبدیل می‌شود.

Tokenizer وظیفه دارد متن ورودی را آماده کند تا مدل بتواند آن را پردازش کند.

در کتابخانه Transformers، Tokenizer علاوه بر تقسیم متن، عملیات دیگری مانند تبدیل Tokenها به شناسه عددی، اضافه کردن Special Tokenها، Padding، Truncation و ساخت Attention Mask را نیز انجام می‌دهد.

فرآیند کلی را می‌توان به این شکل تصور کرد:

متن

⬇

Tokenization

⬇

Tokenها

⬇

Token IDها

⬇

Tensor

⬇

مدل هوش مصنوعی

برای مثال، یک جمله ساده مثل:

«من امروز برنامه‌نویسی می‌کنم.»

ممکن است توسط یک Tokenizer به مجموعه‌ای از قطعات تبدیل شود که لزوماً با کلمات کامل فارسی مطابقت ندارند.

بعد هر یک از این قطعات یک شناسه عددی دریافت می‌کند.

مدل در نهایت با همین اعداد کار می‌کند، نه با حروفی که ما روی صفحه می‌بینیم.

آیا هوش مصنوعی کلمه را می‌فهمد؟

اینجا یک سوءتفاهم مهم وجود دارد.

وقتی می‌گوییم مدل زبانی «کلمه» را پردازش می‌کند، این عبارت بیشتر برای ساده‌سازی توضیح موضوع است.

مدل در سطح ورودی با Tokenها کار می‌کند.

Token ممکن است یک کلمه کامل باشد، اما هیچ الزامی وجود ندارد که چنین باشد.

یک Token می‌تواند شامل موارد زیر باشد:

• یک کلمه کامل
• بخشی از یک کلمه
• چند حرف
• یک علامت نگارشی
• فاصله یا بخشی از آن
• عدد
• بخشی از یک URL
• بخشی از یک کد
• یک Emoji یا قطعه‌ای از آن

Tokenizer بر اساس الگوریتم و واژگان مخصوص همان مدل تصمیم می‌گیرد متن چگونه تقسیم شود. به همین دلیل Tokenization بین مدل‌های مختلف می‌تواند متفاوت باشد.

پس وقتی انسان جمله‌ای را می‌خواند، معمولاً آن را در سطح کلمات و معنا درک می‌کند، اما مدل ابتدا باید متن را به واحدهای عددی تبدیل کند.

چرا مدل نمی‌تواند مستقیماً با کلمات کار کند؟

کامپیوتر در نهایت باید داده را به شکلی عددی دریافت کند.

مدل Transformer نیز نمی‌تواند رشته‌ای از حروف خام را مستقیماً مانند انسان بخواند.

به همین دلیل یک Tokenizer بین متن و مدل قرار می‌گیرد.

فرض کنید ورودی شما این باشد:

«هوش مصنوعی در حال پیشرفت است.»

Tokenizer ابتدا این متن را به Tokenها تقسیم می‌کند.

سپس هر Token با یک شناسه عددی در Vocabulary مدل مطابقت داده می‌شود.

مثلاً به شکل مفهومی:

«هوش» → 1254

«مصنوعی» → 7832

«در» → 421

«حال» → 936

«پیشرفت» → 6217

اعداد بالا صرفاً مثال هستند و ID واقعی به Tokenizer مدل بستگی دارد.

مدل این اعداد را دریافت می‌کند و آنها را به Embeddingهای عددی تبدیل می‌کند تا بتواند روابط میان آنها را در شبکه Transformer پردازش کند.

بنابراین مسیر واقعی بسیار شبیه این است:

متن ⬇

Token → ID → Embedding → Transformer

Token دقیقاً چیست؟

Token کوچک‌ترین واحدی نیست که همیشه یک تعریف ثابت داشته باشد.

این نکته بسیار مهم است.

Token به نوع Tokenizer، Vocabulary و مدل مورد استفاده بستگی دارد.

برای یک مدل، یک کلمه ممکن است یک Token باشد.

برای مدل دیگری همان کلمه ممکن است به چند Token تقسیم شود.

حتی ممکن است یک عبارت در یک مدل به شکلی متفاوت نسبت به مدل دیگری Tokenize شود.

مستندات Hugging Face نیز Tokenization را فرآیندی برای تقسیم متن به Tokenهای کلمه یا زیرکلمه و سپس تبدیل آنها به IDهای عددی توصیف می‌کنند.

چرا یک کلمه ممکن است چند Token باشد؟

فرض کنید مدل کلمه‌ای را در Vocabulary خود به شکل کامل نداشته باشد.

در این حالت Tokenizer می‌تواند آن را به بخش‌های کوچک‌تر تقسیم کند.

برای مثال، در یک Tokenizer فرضی ممکن است:

unbelievable

به شکل:

un + believe + able

تقسیم شود.

یا یک کلمه ناآشنا ممکن است به قطعات کوچک‌تری تقسیم شود.

هدف این روش این است که مدل بتواند حتی کلمات یا ترکیب‌های جدید را نیز تا حدی پردازش کند، بدون اینکه مجبور باشد برای تک‌تک کلمات ممکن یک Token مستقل داشته باشد.

این ایده اساس بسیاری از روش‌های Subword Tokenization است.

Subword Tokenization چیست؟

Subword Tokenization یعنی به‌جای اینکه متن فقط بر اساس کلمات کامل تقسیم شود، کلمات نیز می‌توانند به قطعات کوچک‌تر تقسیم شوند.

این روش یک تعادل مهم ایجاد می‌کند.

اگر Vocabulary فقط شامل کلمات کامل باشد، تعداد کلمات ممکن بسیار زیاد می‌شود و مدل با واژه‌های جدید، نام‌ها، اصطلاحات تخصصی و شکل‌های صرفی مختلف مشکل پیدا می‌کند.

اگر Vocabulary فقط شامل حروف باشد، تعداد Tokenهای مورد نیاز برای هر جمله بسیار افزایش پیدا می‌کند.

Subword Tokenization بین این دو حالت قرار می‌گیرد.

در نتیجه مدل می‌تواند بسیاری از کلمات رایج را به شکل یک یا چند Token و کلمات ناآشنا را به قطعات کوچک‌تر تبدیل کند.

روش‌هایی مانند BPE، WordPiece و Unigram از مشهورترین الگوریتم‌های Tokenization مبتنی بر Subword هستند.

BPE چیست؟

BPE یا Byte Pair Encoding یکی از روش‌های بسیار شناخته‌شده Tokenization است.

ایده اصلی BPE این است که از واحدهای کوچک شروع کند و با پیدا کردن ترکیب‌های پرتکرار، آنها را به واحدهای بزرگ‌تر تبدیل کند.

به زبان ساده، فرض کنید در یک مجموعه داده ترکیب خاصی از حروف بارها تکرار شود.

Tokenizer می‌تواند این ترکیب را به یک Token تبدیل کند.

با ادامه این فرآیند، Vocabulary ساخته می‌شود.

در نتیجه Tokenizer می‌تواند مجموعه‌ای از قطعات پرتکرار زبان را یاد بگیرد.

یکی از مزایای این روش این است که مدل مجبور نیست برای هر کلمه یک Token مستقل داشته باشد و می‌تواند کلمات جدید را از ترکیب قطعات موجود بسازد.

BPE در بسیاری از مدل‌های زبانی مدرن مورد استفاده قرار گرفته و یکی از روش‌های مهم در دنیای Tokenization محسوب می‌شود.

WordPiece چیست؟

WordPiece نیز یک روش Subword Tokenization است که شباهت‌هایی با BPE دارد.

این روش به‌خصوص با مدل‌هایی مانند BERT شناخته شده است.

در WordPiece، Tokenizer تلاش می‌کند توالی‌های طولانی‌تر را در Vocabulary پیدا کند و اگر کلمه کامل وجود نداشته باشد، آن را به قطعات کوچک‌تر تقسیم می‌کند.

در پیاده‌سازی‌های کلاسیک WordPiece، قطعاتی که ادامه یک کلمه هستند با نشانه‌ای مانند ## مشخص می‌شوند.

بنابراین ممکن است یک کلمه به شکل چند Subword نمایش داده شود.

Unigram چیست؟

Unigram نیز یک روش Subword Tokenization است، اما رویکرد آن با BPE و WordPiece متفاوت است.

در روش Unigram، الگوریتم ابتدا یک Vocabulary نسبتاً بزرگ ایجاد می‌کند و سپس Tokenهای کم‌کاربرد را حذف می‌کند تا به اندازه موردنظر برسد.

در زمان Tokenization، الگوریتم می‌تواند چند روش مختلف برای تقسیم یک جمله را در نظر بگیرد و براساس احتمال، مناسب‌ترین Tokenization را انتخاب کند.

Unigram معمولاً همراه با SentencePiece دیده می‌شود.

یکی از ویژگی‌های SentencePiece این است که می‌تواند متن خام را مستقیماً پردازش کند و وابستگی شدیدی به فاصله‌گذاری بین کلمات نداشته باشد.

این موضوع برای زبان‌هایی که ساختار فاصله‌گذاری متفاوتی دارند اهمیت زیادی دارد.

چرا Tokenization برای زبان فارسی اهمیت زیادی دارد؟

یکی از نکات مهم درباره Tokenها این است که تعداد Tokenها برای زبان‌های مختلف یکسان نیست.

مدلی که با داده‌های چندزبانه آموزش دیده، باید بتواند زبان‌هایی با ساختارهای کاملاً متفاوت را پردازش کند.

فارسی نیز ویژگی‌های خاص خود را دارد.

برای مثال:

• شکل اتصال حروف
• نیم‌فاصله
• پسوندها و پیشوندها
• ترکیبات فارسی
• اعداد فارسی و انگلیسی
• علائم نگارشی
• کلمات انگلیسی در متن فارسی
• نام‌های خاص
• URLها
• کدهای برنامه‌نویسی

همگی می‌توانند روی نحوه Tokenization تأثیر بگذارند.

به همین دلیل تعداد Tokenهای یک متن فارسی لزوماً با تعداد کلمات آن رابطه ساده‌ای ندارد.

چرا یک جمله فارسی ممکن است Token بیشتری مصرف کند؟

فرض کنید دو متن از نظر تعداد کلمات تقریباً یکسان باشند.

یکی فارسی و دیگری انگلیسی.

این دو متن الزاماً تعداد Token یکسانی نخواهند داشت.

علت این است که Tokenizer بر اساس Vocabulary و الگوهایی که در داده‌های آموزشی دیده است، متن را به قطعات تقسیم می‌کند.

اگر یک کلمه یا ترکیب در Vocabulary مدل به شکل مناسبی وجود داشته باشد، ممکن است با تعداد Token کمتری نمایش داده شود.

اما اگر ترکیب کمتر دیده شده باشد، ممکن است به چند Subword تقسیم شود.

به همین دلیل نمی‌توان یک قانون ثابت مانند «هر کلمه دقیقاً یک Token است» برای مدل‌های زبانی در نظر گرفت.

چرا Tokenization روی هزینه استفاده از API تأثیر دارد؟

این قسمت برای کاربران سرویس‌های هوش مصنوعی اهمیت زیادی دارد.

بسیاری از سرویس‌های API هزینه را براساس تعداد Tokenهای ورودی و خروجی محاسبه می‌کنند.

بنابراین چیزی که برای انسان فقط یک متن کوتاه به نظر می‌رسد، ممکن است برای مدل تعداد زیادی Token ایجاد کند.

فرض کنید یک درخواست 1000 کلمه‌ای دارید.

نمی‌توان بدون دانستن Tokenizer مدل گفت این درخواست دقیقاً 1000 Token است.

ممکن است تعداد Token بیشتر یا کمتر باشد.

پس در سرویس‌های پولی، Tokenization مستقیماً می‌تواند روی هزینه تأثیر بگذارد.

Token چه ارتباطی با Context Window دارد؟

Context Window حداکثر مقدار اطلاعاتی است که مدل می‌تواند در یک فرآیند پردازش در اختیار داشته باشد و این ظرفیت معمولاً بر اساس Token اندازه‌گیری می‌شود.

برای مثال اگر مدلی Context Window برابر 128K Token داشته باشد، این عدد به معنای 128 هزار کلمه نیست.

منظور حدود 128 هزار واحد Token است.

اگر متن شما به‌دلیل Tokenization به تعداد زیادی Token تبدیل شود، سریع‌تر به سقف Context نزدیک خواهید شد.

به همین دلیل برای مدل‌های زبانی بهتر است Context را با Token بسنجیم، نه صرفاً تعداد کلمات.

چرا تعداد Token با تعداد کاراکتر فرق دارد؟

یک Token ممکن است چند کاراکتر داشته باشد.

همچنین ممکن است یک کلمه به چند Token تبدیل شود.

بنابراین رابطه‌ای مانند:

1 Token = 1 کلمه

یا:

1 Token = 1 حرف

وجود ندارد.

Token واحدی است که Tokenizer براساس Vocabulary و الگوریتم خود تعریف می‌کند.

به همین دلیل حتی طول یکسان دو متن از نظر تعداد کاراکتر نیز لزوماً به تعداد Token یکسان منجر نمی‌شود.

Special Token چیست؟

Tokenizerها فقط متن عادی را به Token تبدیل نمی‌کنند.

گاهی مدل به Tokenهای خاصی نیاز دارد که برای مشخص کردن ساختار ورودی استفاده می‌شوند.

به این موارد Special Token گفته می‌شود.

نمونه‌هایی از آنها شامل:

• Beginning of Sequence
• End of Sequence
• Padding Token
• Unknown Token
• Mask Token

هستند.

البته همه مدل‌ها از تمام این Tokenها استفاده نمی‌کنند.

Tokenizer براساس معماری و نیاز مدل می‌تواند Special Tokenهای مناسب را هنگام آماده‌سازی ورودی اضافه کند.

Input ID چیست؟

بعد از اینکه متن Tokenize شد، هر Token باید به یک عدد تبدیل شود.

به این عدد معمولاً Token ID یا Input ID گفته می‌شود.

مثلاً به شکل فرضی:

«هوش» → 1523

«مصنوعی» → 8392

«است» → 421

مدل مستقیماً رشته «هوش مصنوعی است» را دریافت نمی‌کند.

بلکه چیزی شبیه:

1523, 8392, 421

را دریافت می‌کند.

البته IDهای واقعی کاملاً به Vocabulary همان Tokenizer بستگی دارند.

Hugging Face نیز input_ids را فهرست شناسه‌های Tokenهایی معرفی می‌کند که به مدل داده می‌شوند.

مدل چگونه از این اعداد به معنا می‌رسد؟

اینجا بخش جالب ماجرا شروع می‌شود.

اگر مدل فقط اعداد را ببیند، این اعداد به‌خودی‌خود معنای خاصی ندارند.

برای مثال ID شماره 1523 ذاتاً معنای «هوش» ندارد.

این عدد فقط یک شناسه در Vocabulary است.

مدل این شناسه‌ها را به نمایش‌های عددی غنی‌تری به نام Embedding تبدیل می‌کند.

Embeddingها فضایی عددی ایجاد می‌کنند که در آن روابط میان Tokenها می‌تواند توسط شبکه یاد گرفته شود.

سپس Transformer با استفاده از Attention و سایر اجزای معماری، روابط بین Tokenهای مختلف را بررسی می‌کند.

بنابراین مسیر را می‌توان این‌طور خلاصه کرد:

کلمه و متن

⬇

Token

⬇

ID

⬇

Embedding

⬇

پردازش Transformer

⬇

پیش‌بینی Token بعدی

این همان جایی است که مدل از یک فهرست عددی ساده به یک سیستم پیچیده پردازش زبان تبدیل می‌شود.

Attention Mask چه کاری انجام می‌دهد؟

Tokenizer علاوه بر input_ids می‌تواند اطلاعات دیگری مانند attention_mask نیز تولید کند.

Attention Mask مشخص می‌کند مدل باید به کدام Tokenها توجه کند.

این موضوع مخصوصاً هنگام Padding کردن چند ورودی با طول متفاوت اهمیت پیدا می‌کند.

برای مثال اگر دو جمله طول متفاوت داشته باشند، برای قرار دادن آنها در یک Batch ممکن است کوتاه‌ترها با Padding پر شوند.

Attention Mask به مدل کمک می‌کند Tokenهای Padding را از Tokenهای واقعی تشخیص دهد.

Padding و Truncation چیست؟

گاهی ورودی‌های یک Batch طول یکسانی ندارند.

برای هماهنگ کردن آنها می‌توان از Padding استفاده کرد.

در این حالت Tokenهای مخصوصی به ورودی کوتاه‌تر اضافه می‌شوند تا طول آن با سایر ورودی‌ها هماهنگ شود.

از طرف دیگر اگر متن بیش از حداکثر طول قابل پردازش باشد، می‌توان از Truncation استفاده کرد تا بخشی از Tokenها حذف شود.

این موضوع اهمیت زیادی دارد، زیرا محدودیت مدل‌ها بر اساس Token تعریف می‌شود، نه تعداد کلمات.

چرا مدل‌های مختلف Tokenهای متفاوتی دارند؟

هر مدل الزاماً از یک Tokenizer یکسان استفاده نمی‌کند.

Tokenizer بخشی از سیستم یک مدل است و Vocabulary آن باید با مدلی که برایش آموزش داده شده هماهنگ باشد.

اگر Tokenizer متفاوتی را به‌جای Tokenizer اصلی استفاده کنید، شناسه‌های Token دیگر لزوماً با چیزی که مدل در زمان آموزش دیده است مطابقت ندارند.

مستندات Hugging Face نیز تأکید می‌کنند که Vocabulary مربوط به Tokenizer باید با Vocabulary مورد استفاده مدل مطابقت داشته باشد.

به همین دلیل نمی‌توان انتظار داشت یک متن در تمام مدل‌های هوش مصنوعی دقیقاً به یک تعداد Token تقسیم شود.

آیا Tokenizer روی کیفیت مدل تأثیر دارد؟

بله، و این بخش گاهی نادیده گرفته می‌شود.

Tokenizer فقط یک ابزار جانبی برای تبدیل متن نیست.

نحوه تقسیم متن می‌تواند روی کارایی مدل تأثیر بگذارد.

اگر یک زبان یا نوع خاصی از داده با Tokenهای بسیار ناکارآمد نمایش داده شود، مدل برای بیان همان مقدار اطلاعات به Token بیشتری نیاز خواهد داشت.

این مسئله می‌تواند روی:

• مصرف Context
• سرعت پردازش
• هزینه inference
• آموزش مدل
• عملکرد چندزبانه
• پردازش کد
• پردازش متن‌های تخصصی

اثر بگذارد.

به همین دلیل طراحی Tokenizer یکی از بخش‌های مهم ساخت مدل زبانی است.

چرا Tokenization برای کدنویسی هم مهم است؟

کد با زبان طبیعی تفاوت دارد.

در کد، مواردی مانند:

• نام متغیرها
• تابع‌ها
• مسیر فایل‌ها
• URLها
• علائم
• پرانتزها
• براکت‌ها
• عملگرها
• فاصله‌ها
• ساختار زبان برنامه‌نویسی

اهمیت دارند.

Tokenizer باید بتواند چنین داده‌هایی را نیز به شکلی مناسب به Token تبدیل کند.

برای همین ممکن است یک Tokenizer که برای متن عمومی طراحی شده، برای برخی الگوهای کدنویسی نسبت به Tokenizerهای بهینه‌شده برای Code عملکرد متفاوتی داشته باشد.

این موضوع یکی از دلایلی است که در مدل‌های مخصوص Coding، طراحی Vocabulary و Tokenization اهمیت ویژه‌ای پیدا می‌کند.

Tokenizer چگونه آموزش داده می‌شود؟

Tokenizer معمولاً از یک مجموعه متن بزرگ برای ساخت Vocabulary استفاده می‌کند.

الگوریتم براساس روش مورد استفاده، الگوهای پرتکرار را شناسایی می‌کند یا مجموعه‌ای از Subwordها را براساس احتمال و فراوانی ایجاد می‌کند.

برای مثال در BPE، ترکیب‌های پرتکرار به‌تدریج به Tokenهای بزرگ‌تر تبدیل می‌شوند.

در Unigram، ابتدا مجموعه بزرگی از گزینه‌ها ساخته شده و سپس Tokenهای نامناسب حذف می‌شوند.

در نهایت Vocabulary مشخص می‌کند مدل چه مجموعه‌ای از Tokenها را می‌شناسد.

آیا Tokenization همیشه ثابت و قطعی است؟

در بسیاری از Tokenizerها برای یک ورودی مشخص، Tokenization قطعی است.

اما برخی روش‌ها می‌توانند در فرآیند Tokenization چند مسیر احتمالی داشته باشند.

Unigram یکی از نمونه‌هایی است که می‌تواند چند روش برای تقسیم متن در نظر بگیرد و براساس احتمال بهترین مسیر را انتخاب کند.

بنابراین Tokenization صرفاً بریدن متن در فاصله‌های بین کلمات نیست.

یک فرآیند الگوریتمی است که براساس Vocabulary و روش Tokenizer انجام می‌شود.

آیا فاصله هم می‌تواند بخشی از Token باشد؟

بله.

این یکی از نکاتی است که نشان می‌دهد Token با «کلمه» تفاوت دارد.

بسته به Tokenizer، فاصله می‌تواند همراه با Token بعدی یا به شکل بخشی از ساختار Tokenization نمایش داده شود.

در برخی روش‌ها، اطلاعات مربوط به فاصله به‌صورت مستقیم در Tokenها یا پیش‌پردازش متن لحاظ می‌شود.

به همین دلیل وقتی Tokenهای یک جمله را مشاهده می‌کنید، ممکن است نمایش آنها دقیقاً شبیه فهرستی از کلمات جداشده با فاصله نباشد.

چرا Emoji و URLها گاهی Tokenهای زیادی مصرف می‌کنند؟

Tokenizer باید تمام محتوای ورودی را به Vocabulary خود نگاشت کند.

اگر یک رشته در Vocabulary مدل به شکل مناسبی وجود نداشته باشد، ممکن است به چند قطعه تقسیم شود.

Emojiهای خاص، URLهای طولانی، نام‌های تصادفی، شناسه‌ها و رشته‌های غیرمعمول می‌توانند Tokenهای بیشتری نسبت به چیزی که از ظاهرشان انتظار داریم ایجاد کنند.

به همین دلیل یک URL کوتاه از نظر تعداد کاراکتر لزوماً از نظر Token نیز ارزان نیست.

Tokenization چه ارتباطی با Context Window دارد؟

یکی از اشتباهات رایج این است که کاربر می‌گوید:

«مدل من Context یک میلیون کلمه دارد.»

در حالی که مدل معمولاً Context را بر اساس Token اعلام می‌کند.

مثلاً:

128K Token

به معنای 128 هزار کلمه نیست.

این مقدار شامل Tokenهای ورودی و در بسیاری از معماری‌ها Tokenهای دیگری است که در فرآیند تولید و پردازش مورد استفاده قرار می‌گیرند.

پس وقتی درباره ظرفیت Context یک مدل صحبت می‌کنیم، باید بپرسیم:

چند Token؟

نه:

چند کلمه؟

آیا Token بیشتر یعنی مدل ضعیف‌تر است؟

نه.

تعداد Token به‌تنهایی معیار قدرت مدل نیست.

یک مدل ممکن است یک عبارت را با Tokenهای بیشتری نمایش دهد اما عملکرد بسیار خوبی داشته باشد.

Tokenization بیشتر درباره نحوه نمایش متن برای مدل است.

با این حال، Token Efficiency می‌تواند اهمیت عملی زیادی داشته باشد.

اگر یک مدل برای انتقال مقدار مشخصی اطلاعات به Tokenهای بیشتری نیاز داشته باشد، ممکن است Context سریع‌تر مصرف شود و در APIهایی که بر اساس Token هزینه می‌گیرند، هزینه بیشتری ایجاد شود.

پس:

Token بیشتر ≠ مدل ضعیف‌تر

اما:

Token بیشتر می‌تواند = مصرف بیشتر Context و گاهی هزینه بیشتر

آیا می‌توان Tokenها را خودمان تغییر دهیم؟

در حالت عادی، هنگام استفاده از یک مدل آماده، بهتر است از همان Tokenizer رسمی مدل استفاده شود.

تغییر Tokenizer بدون آموزش یا سازگار کردن مدل می‌تواند باعث ناسازگاری بین شناسه‌های Token و چیزی شود که مدل در زمان آموزش یاد گرفته است.

در Hugging Face معمولاً می‌توان Tokenizer متناظر با مدل را از Hub دریافت کرد و با همان Tokenizer متن را به input_ids تبدیل کرد.

بنابراین وقتی یک مدل را دانلود می‌کنید، فایل‌ها و تنظیمات Tokenizer آن نیز بخش مهمی از مدل محسوب می‌شوند.

چگونه تعداد Token یک متن را محاسبه کنیم؟

بهترین روش این است که از Tokenizer همان مدل استفاده کنیم.

در اکوسیستم Hugging Face می‌توان Tokenizer مربوط به مدل را بارگذاری کرد و متن را Encode کرد.

برای نمونه، یک مدل می‌تواند متن را دریافت کرده و خروجی‌ای شامل input_ids و attention_mask ایجاد کند. تعداد IDهای ورودی نیز تعداد Tokenهای توالی را نشان می‌دهد، البته بسته به تنظیمات ممکن است Special Tokenها، Padding یا Truncation نیز در نتیجه وجود داشته باشند.

به همین دلیل ابزارهای Token Counter عمومی همیشه برای همه مدل‌ها دقیق نیستند.

Token Counter باید با Tokenizer همان مدل هماهنگ باشد.

چرا فهم Tokenization برای کاربران هوش مصنوعی مهم است؟

ممکن است در نگاه اول Tokenization یک موضوع کاملاً فنی به نظر برسد.

اما در عمل تقریباً همه کاربران حرفه‌ای AI با آن سروکار دارند.

برای کاربران عادی

به شما کمک می‌کند بفهمید چرا یک متن مشخص ممکن است Context زیادی مصرف کند.

برای برنامه‌نویسان

برای مدیریت Context، API، هزینه و Promptهای طولانی اهمیت دارد.

برای توسعه‌دهندگان AI

در طراحی سیستم‌های RAG، Agent و LLM Application باید مصرف Token را مدیریت کنند.

برای تولیدکنندگان محتوا

طول متن و ساختار آن می‌تواند روی هزینه استفاده از مدل تأثیر بگذارد.

برای شرکت‌ها

در مقیاس بالا، تفاوت چند Token در هر درخواست می‌تواند در مجموع هزینه قابل توجهی ایجاد کند.

تفاوت Token، Word و Character چیست؟

برای جلوگیری از اشتباه، این سه مفهوم را جدا کنیم.

Character

یک نویسه منفرد است.

مثلاً:

«م»

Word

یک واحد زبانی که انسان معمولاً آن را به‌عنوان کلمه تشخیص می‌دهد.

مثلاً:

«هوش»

Token

واحدی است که Tokenizer مدل برای پردازش متن انتخاب می‌کند.

Token ممکن است با Word یا Character برابر باشد، اما الزامی نیست.

پس:

Character ≠ Word ≠ Token

این یکی از مهم‌ترین نکات برای فهم نحوه کار مدل‌های زبانی است.

Tokenization؛ پلی بین زبان انسان و زبان مدل

انسان متن را با ساختارهایی مانند کلمه، جمله و مفهوم می‌بیند.

کامپیوتر چنین درکی از متن خام ندارد.

Tokenizer ابتدا متن را به واحدهایی تبدیل می‌کند که مدل بتواند آنها را به شکل عددی پردازش کند.

در نتیجه می‌توان Tokenizer را یک پل میان دنیای زبان انسان و ورودی عددی مدل دانست.

فرآیند کلی به شکل زیر است:

متن انسانی

↓

Tokenization

↓

Tokenها

↓

Token IDها

↓

Embeddingها

↓

Transformer

↓

پیش‌بینی Token بعدی

↓

Decode

↓

متن قابل خواندن برای انسان

این فرآیند در کسری از ثانیه اتفاق می‌افتد و کاربر معمولاً هیچ‌کدام از این مراحل را نمی‌بیند.

جمع‌بندی

مدل‌های هوش مصنوعی کلمات را دقیقاً همان‌طور که انسان می‌بیند، نمی‌بینند.

آنها ابتدا متن را از طریق Tokenizer به Token تقسیم می‌کنند و سپس هر Token را به یک شناسه عددی تبدیل می‌کنند. این شناسه‌ها در ادامه به نمایش‌های عددی یا Embedding تبدیل شده و وارد شبکه Transformer می‌شوند.

نکته مهم این است که Token الزاماً یک کلمه نیست.

ممکن است یک Token یک کلمه کامل، بخشی از یک کلمه، چند حرف، علامت نگارشی یا بخش دیگری از متن باشد.

روش‌هایی مانند BPE، WordPiece و Unigram برای ساخت چنین Tokenهایی استفاده می‌شوند و هرکدام رویکرد متفاوتی برای ایجاد Vocabulary و تقسیم متن دارند.

این موضوع فقط یک جزئیات فنی نیست.

تعداد Tokenها روی مصرف Context Window، هزینه API، سرعت پردازش و حتی کارایی مدل در زبان‌ها و انواع مختلف داده تأثیر می‌گذارد.

بنابراین دفعه بعد که یک مدل می‌گوید «این درخواست ۲۰۰۰ Token مصرف کرد»، تصور نکنید ۲۰۰۰ کلمه خوانده شده است.

مدل احتمالاً مجموعه‌ای از قطعات متن را دریافت کرده که برای ما انسان‌ها حتی ممکن است تقسیم‌بندی عجیبی داشته باشند.

و این همان راز Tokenization است: مدل زبان را به شکل کلمه نمی‌بیند؛ ابتدا آن را به شکلی تبدیل می‌کند که بتواند با آن به‌صورت عددی کار کند.