Chunking محتوای خام و normalized صفحه را به واحدهای retrieval تبدیل میکند. انتخابهای ضعیف cost را inflate میکنند، با fragmentهای بیش از حد؛ recall را degrade میکنند، با blockهای بیش از حد بزرگ؛ یا precision را dilute میکنند، با fracture در boundaryها. روش universal best وجود ندارد؛ strategy با ساختار corpus، volatility و query patternها همراستا میشود. این guide فضای طراحی، trade-offها، workflow ارزیابی و اهرمهای optimization برای RAG pipelineهای production را map میکند.
چرا Chunking مهم است
هدفها:
- بیشینه کردن احتمال اینکه factهای مرتبط در top-k retrieval ظاهر شوند.
- حفظ semantic cohesion تا answerهای generated grounded بمانند.
- بهینهسازی token utilization و پرهیز از embedding تکراری boilerplate.
- فعال کردن updateهای incremental deterministic با chunk IDهای stable.
chunking ناهماهنگ به شکل redundancy بالا، Recall@k پایین، hallucinated boundary facts و embedding spend inflate شده ظاهر میشود.
Chunking با پنجره ثابت
پنجرههای ساده N-token، مثلاً 500 token. مزیتها: deterministic، آسان برای implementation، رفتار update stable. عیبها: boundary مفهومها را قطع میکند؛ برای کاهش truncation به overlap redundant نیاز است و cost رشد میکند. کم استفاده کنید: baseline خوبی است برای محتوای heterogeneous یا poorly structured که signalهای semantic قابل اعتماد نیستند.
پنجرههای sliding همپوشان
window size W با overlap O، مثلاً 500 / 50 token، truncation factها در boundary را کم میکند. overlap بالاتر از حدود 15% gainهای recall کاهنده دارد و همزمان index size را compounding میکند. برای پایین آوردن O، duplication_ratio = distinct_token_count / total_token_count را track کنید.
تشخیص boundary معنایی
بر اساس signalهای structural segment کنید: headingهای H2/H3، groupingهای list، code blockها و table boundaryها. boundهای min/max token را enforce کنید، siblingهای خیلی کوچک را merge و sectionهای خیلی بزرگ را split کنید. مزیتها: cohesion بالاتر و overlap کمتر. ریسکها: markup malformed و heading hierarchy inconsistent. با hierarchy repair و fallback به paragraph splitting وقتی heading نیست mitigation کنید.
Chunking سلسلهمراتبی
index دو لایه: embedding بخشهای coarse، مثلاً کل یک tutorial section، بهعلاوه subchunkهای fine-grained. جریان retrieval: coarse ANN → filter top N sectionها → fine retrieval درون آنها. مزیتها: global search space برای corpusهای بزرگ کم میشود و latency بهتر میشود. complexity: بخشهای متحرک بیشتر و نیاز به cascade scoring logic.
Chunking adaptive / dynamic
اندازه chunkها را بر اساس semantic density محلی و structural cueها تنظیم کنید. منطق نمونه: از heading section شروع کنید؛ اگر >800 token بود، با clusterهای paragraph که با semantic similarity امتیاز گرفتهاند split کنید؛ اگر <120 token بود، با sibling بعدی merge کنید مگر اینکه topic divergence از threshold بالاتر باشد. به embedding یا similarity pre-pass نیاز دارد؛ cost را یکبار در ingestion میپردازید تا retrieval efficiency بلندمدت بهتر شود.
ملاحظات Embedding
metadata را نگه دارید: token_count، model_version، content_hash. برای جلوگیری از truncation، tokenها را پیشاپیش compute و پیش از model call split کنید. مدلهای dense با boilerplate زیاد degrade میشوند؛ artifactهای navigation را پیش از chunk حذف کنید. vector_density یعنی unique terms / tokens را monitor کنید تا fragmentهای کمsignal، candidate برای re-merge، نمایان شوند.
روشهای Evaluation
benchmark برای هر strategy:
| شاخص | هدف |
|---|---|
| Recall@k | حفظ fact |
| Precision@k | noise در context |
| Chunk Count | شاخص cost |
| Duplication Ratio | تنظیم overlap |
| Avg Tokens per Chunk | استفاده از window |
| Latency (Retrieval) | کارایی index |
روی gold query set اجرا کنید؛ strategy را فقط وقتی adopt کنید که gainهای recall بر cost و latency delta غلبه کنند.
Playbook پیادهسازی
- Baseline: Fixed 500 + 10% overlap؛ benchmark جمع کنید.
- Semantic Boundaries را معرفی کنید: جایی که headingها reliable هستند windowها را replace کنید و دوباره اندازه بگیرید.
- اگر corpus >250k chunk یا latency > target بود Hierarchical Layer اضافه کنید.
- برای section sizeهای high-variance منطق Adaptive deploy کنید.
- بازبینی فصلی: cost per quality delta را در برابر capabilityهای جدید model مقایسه کنید.
برای rollback، در هر iteration diff manifest chunk را ذخیره کنید.
نکات کلیدی
- boundaryهای semantic معمولاً در precision/cost از pure fixed window بهترند.
- overlap یک dial است؛ duplication را اندازه بگیرید، حدس نزنید.
- retrieval سلسلهمراتبی کمک میکند بدون رشد linear latency scale کنید.
- chunk IDهای stable refresh incremental embedding را امن میکنند.
- تغییر strategy را مثل code deploy ارزیابی کنید: benchmark، compare، log.