شهریور
آموزش هوش مصنوعی
توکن چیست و چرا هزینه و محدودیت از آن میآید
هر بار که پیامی برای یک مدل زبانی مثل GPT یا Claude میفرستید، پیش از هر پردازشی متن شما به واحدهای کوچکتری به نام «توکن» شکسته میشود. مدل نه حروف را میبیند و نه کلمات را به شکلی که ما میبینیم؛ او فقط دنبالهای از توکنها را پردازش میکند. همین واحد ساده، هم پایهٔ محاسبهٔ هزینه است و هم دلیل اصلی محدودیتهایی که هر کسی حین ساخت یک چتبات تخصصی با آن روبهرو میشود؛ از قطعشدن پاسخهای طولانی گرفته تا افزایش ناگهانی هزینهٔ API. برای کسی که میخواهد یک سیستم RAG یا ایجنت روی دادهٔ خودش بسازد، فهم دقیق توکن نقطهٔ شروع همهٔ تصمیمهای بعدی است.
لیست مطالب
توکن دقیقاً چیست؟
توکن یک واحد متنی است که میتواند یک کلمهٔ کامل، بخشی از یک کلمه، یک علامت نگارشی یا حتی یک فاصله باشد. مدلهای زبانی امروزی از الگوریتمهایی مثل BPE (Byte Pair Encoding) یا نسخههای مشابه آن استفاده میکنند تا متن را به زیرواحدهای پرتکرار بشکنند. کلمههای رایج انگلیسی معمولاً یک یا دو توکن مصرف میکنند، اما کلمههای نادر، اسمهای خاص، یا زبانهایی با ساختار صرفی متفاوت مثل فارسی، معمولاً به چند توکن کوچکتر تجزیه میشوند. این یعنی «تعداد کلمه» و «تعداد توکن» دو عدد کاملاً متفاوتاند و نباید آنها را جای هم گذاشت.
چرا قیمتگذاری بر اساس توکن است؟
مدل زبانی برای تولید هر توکن خروجی باید یک محاسبهٔ سنگین روی کل دنبالهٔ ورودی انجام دهد. هرچه دنباله طولانیتر باشد، حافظه و توان پردازشی بیشتری مصرف میشود. به همین دلیل ارائهدهندگان مدل، هزینه را نه بر اساس تعداد درخواست بلکه بر اساس تعداد توکنهای رفتوبرگشتی حساب میکنند. بهطور کلی توکنهای خروجی (Output) بهخاطر فرایند تولید گامبهگام، گرانتر از توکنهای ورودی (Input) هستند، و پرامپت سیستمی، تاریخچهٔ مکالمه و متنهایی که برای پاسخ به سؤال به مدل تزریق میشوند (مثل نتایج بازیابیشده در یک سیستم RAG) همگی جزو ورودی محسوب و شمارش میشوند.
| نوع متن | رفتار توکنساز | نکتهٔ عملی |
|---|---|---|
| کلمهٔ رایج انگلیسی | معمولاً یک تا دو توکن | متن انگلیسی ساده نسبتاً کمتوکن است |
| متن فارسی | اغلب به چند زیرتوکن شکسته میشود | همان محتوا به فارسی معمولاً توکن بیشتری میگیرد |
| کد یا JSON | علامتها و نشانهگذاریها هرکدام توکن جدا میشوند | ساختارهای تو در تو حجم توکن را بالا میبرند |
| اعداد و شناسهها | اغلب رقمبهرقم یا در گروههای کوچک تجزیه میشوند | جدولهای عددی بزرگ سریعتر از حد انتظار توکن مصرف میکنند |
محدودیت Context Window از کجا میآید؟
هر مدل یک سقف مشخص برای مجموع توکنهای ورودی و خروجی دارد که به آن Context Window میگویند. این سقف شامل پرامپت سیستمی، تاریخچهٔ گفتوگو، هر متنی که بهعنوان زمینه (context) به مدل داده میشود، و پاسخی که مدل قرار است تولید کند. وقتی مجموع اینها از سقف رد شود، یا درخواست با خطا مواجه میشود یا بخشی از تاریخچه (معمولاً قدیمیترین پیامها) از ابتدای مکالمه حذف میشود تا جا باز شود. این همان جایی است که سیستمهای RAG اهمیت پیدا میکنند: بهجای تزریق کل سند به context، فقط تکههای مرتبط با سؤال کاربر بازیابی و به مدل داده میشوند تا هم هزینه پایین بماند و هم از سقف Context Window عبور نشود. اگر میخواهید ببینید این مفهوم در عمل چطور به یک سیستم واقعی تبدیل میشود، در نقشهٔ راه ساخت چتبات تخصصی این فرایند را قدمبهقدم شرح دادهایم.
چرا این موضوع برای چتبات روی دادهٔ خودتان مهم است؟
وقتی میخواهید چتباتی بسازید که روی مستندات داخلی، کاتالوگ محصول یا پایگاه دانش شرکت پاسخ بدهد، نمیتوانید کل آن داده را در هر درخواست به مدل بدهید؛ هم هزینه غیرقابلقبول میشود و هم از Context Window رد میشوید. راهحل رایج این است که داده از قبل به تکههای کوچک (chunk) تقسیم شود، هر تکه به یک بردار معنایی (embedding) تبدیل شود، و در زمان پاسخدهی فقط مرتبطترین تکهها بازیابی و به مدل تزریق شوند. این معماری دقیقاً همان چیزی است که در ادامهٔ این مجموعه مقالات دربارهٔ embedding، شباهت کسینوسی، وکتور دیتابیس و chunking بررسی میکنیم.
نکتهٔ کلیدی: مدیریت توکن یعنی مدیریت هزینه. هر توکن اضافهای که بدون نیاز به context تزریق میشود، هم پول بیشتری میگیرد و هم فضای کمتری برای پاسخ واقعی مدل باقی میگذارد.
چطور مصرف توکن را کنترل کنیم؟
در عمل چند عادت ساده میتواند مصرف توکن یک سیستم چتبات را بهشکل محسوسی پایین بیاورد. اول، پرامپت سیستمی را کوتاه و متمرکز نگه دارید؛ هر خط اضافه در پرامپت سیستمی در تکتک درخواستها تکرار و شمارش میشود، حتی اگر ربطی به سؤال فعلی کاربر نداشته باشد. دوم، بهجای تزریق کل تاریخچهٔ مکالمه، فقط چند پیام آخر یا یک خلاصهٔ فشرده از مکالمهٔ قدیمیتر را نگه دارید. سوم، در سیستمهای RAG، تعداد chunkهایی که به مدل تزریق میشوند را محدود کنید و فقط مرتبطترینها را انتخاب کنید؛ تزریق ده تکهٔ نیمهمرتبط، هم هزینه را بالا میبرد و هم دقت پاسخ را لزوماً بهتر نمیکند.
تفاوت شمارش توکن بین ارائهدهندگان مختلف
یک نکتهٔ کمتر شناختهشده این است که هر خانوادهٔ مدل معمولاً توکنساز (Tokenizer) خودش را دارد؛ یعنی همان جملهٔ فارسی وقتی از توکنساز یک مدل عبور کند، ممکن است عدد متفاوتی نسبت به عبور از توکنساز مدل دیگری بدهد. این تفاوت به این معناست که نمیشود صرفاً بر اساس تجربهٔ یک مدل، مصرف توکن مدل دیگر را حدس زد؛ اگر پروژهای بین چند مدل یا چند ارائهدهنده جابهجا میشود، بهتر است مصرف توکن هر مسیر بهطور جداگانه و با ابزار توکنسازی همان مدل سنجیده شود، نه با یک قاعدهٔ سرانگشتی مشترک.
جمعبندی
- توکن واحد پایهٔ محاسبهٔ هزینه و ظرفیت مدل است؛ تعداد کلمه با تعداد توکن یکی نیست.
- متن فارسی و ساختارهای دارای نشانهگذاری زیاد (کد، JSON) معمولاً نسبت به متن سادهٔ انگلیسی توکن بیشتری مصرف میکنند.
- توکنهای خروجی معمولاً گرانتر از توکنهای ورودیاند، پس طول پاسخ خواستهشده را هم باید کنترل کرد.
- Context Window یک سقف مطلق است؛ تزریق کل سند بهجای تکههای مرتبط، سریعترین راه برای برخورد به این سقف است.
- معماری RAG دقیقاً برای حل همین مسئله طراحی شده: کاهش توکن مصرفی با بازیابی هوشمند بهجای تزریق کورکورانه.
