Chunking؛ سند را چطور تکه کنیم که جواب درست دربیاید

خیلی از تیم‌هایی که برای اولین‌بار یک سیستم RAG راه‌اندازی می‌کنند، بیشترین وقت را صرف انتخاب مدل embedding یا وکتور دیتابیس می‌کنند، در حالی که کیفیت واقعی پاسخ نهایی اغلب به یک تصمیم ساده‌تر و کم‌توجه‌تر برمی‌گردد: سند را چطور تکه‌تکه کرده‌اید؟ به این فرایند Chunking می‌گویند، و انتخاب نادرست اندازهٔ chunk می‌تواند نتیجهٔ بهترین مدل embedding و بهترین وکتور دیتابیس را هم خنثی کند.

چرا اصلاً باید سند را تکه کرد؟

هم مدل‌های embedding و هم Context Window مدل زبانی محدودیت دارند؛ نمی‌توان یک سند صد صفحه‌ای را یک‌جا به بردار تبدیل کرد و انتظار داشت آن بردار همهٔ جزئیات ریز سند را به‌طور جداگانه نمایندگی کند. راه‌حل این است که سند به تکه‌های کوچک‌تر (chunk) تقسیم شود، هر chunk جداگانه به بردار تبدیل و ذخیره شود، و در زمان پاسخ‌دهی فقط chunk‌های مرتبط با سؤال بازیابی شوند. اما اندازهٔ این تکه‌ها یک نقطهٔ تعادل حساس دارد.

تلهٔ chunk خیلی کوچک

وقتی chunk خیلی کوچک باشد — مثلاً فقط یک یا دو جمله — هر تکه به‌تنهایی زمینهٔ کافی برای فهمیده‌شدن ندارد. تصور کنید جمله‌ای مثل «این مبلغ باید ظرف ده روز پرداخت شود» به‌تنهایی یک chunk باشد؛ بدون این‌که معلوم باشد «این مبلغ» به کدام مبلغ در پاراگراف قبلی اشاره دارد، هم embedding آن ضعیف‌تر می‌شود و هم اگر همین chunk بازیابی و به مدل زبانی تزریق شود، مدل نمی‌تواند پاسخ کاملی بسازد چون بخشی از زمینه را از دست داده است.