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

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

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

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

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

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

تلهٔ chunk خیلی بزرگ

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

چرا Overlap لازم است؟

حتی با انتخاب اندازهٔ مناسب، مرز بین دو chunk متوالی می‌تواند دقیقاً وسط یک جمله یا یک ایدهٔ مهم بیفتد. برای جلوگیری از این، معمولاً بخشی از انتهای هر chunk در ابتدای chunk بعدی هم تکرار می‌شود؛ به این تکرار عمدی، Overlap می‌گویند. Overlap تضمین می‌کند که اگر اطلاعات مهمی درست روی مرز دو تکه قرار گرفته باشد، حداقل در یکی از دو chunk به‌طور کامل و با زمینهٔ کافی حفظ شود، نه این‌که نصفه در یک تکه و نصفهٔ دیگر در تکهٔ بعدی از هم جدا بیفتد.

سند اصلی:
[... بخش الف ...][ بخش ب ][... بخش ج ...]

بدون overlap:
chunk 1: [... بخش الف ...][ نیمهٔ اول بخش ب ]
chunk 2: [ نیمهٔ دوم بخش ب ][... بخش ج ...]
=> بخش ب در هیچ‌کدام کامل نیست

با overlap:
chunk 1: [... بخش الف ...][ بخش ب کامل ]
chunk 2: [ بخش ب کامل ][... بخش ج ...]
=> بخش ب حداقل یک‌بار کامل در دسترس است

روش‌های رایج تکه‌کردن

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

برای بیشتر مستندات سازمانی، شروع با تکه‌کردن ساختارمحور (بر اساس پاراگراف یا بخش) همراه با یک overlap کوچک، نقطهٔ شروع معقولی است که بعداً می‌شود بر اساس رفتار واقعی جست‌وجو تنظیمش کرد.

Chunking و ارتباطش با متادیتا

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

یک اشتباه رایج: یک اندازهٔ ثابت برای همهٔ اسناد

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

جمع‌بندی

• chunk خیلی کوچک زمینهٔ لازم برای فهمیده‌شدن را از دست می‌دهد و پاسخ‌ها را ناقص می‌کند.
• chunk خیلی بزرگ چند موضوع را در یک بردار قاطی می‌کند و دقت جست‌وجوی معنایی را پایین می‌آورد.
• Overlap بین chunk‌های متوالی از قطع‌شدن اطلاعات مهم روی مرز دو تکه جلوگیری می‌کند.
• ترجیحاً مرزهای chunk را هم‌راستا با ساختار طبیعی سند (پاراگراف، بخش) انتخاب کنید، نه صرفاً یک عدد ثابت بی‌ربط به محتوا.
• استراتژی chunking باید بر اساس رفتار واقعی جست‌وجو در دادهٔ خودتان تست و تنظیم شود، نه یک تنظیم پیش‌فرض که همیشه بدون تغییر باقی بماند.