استراتيجيات تجزئة RAG: 7 طرق مرتّبة وفق بيانات الاسترجاع (2026)

استراتيجيات تجزئة RAG: 7 طرق مرتّبة وفق بيانات الاسترجاع (2026)

استراتيجيات تجزئة RAG تحدد ما يمكن لأداة الاسترجاع أن تجده قبل أن يُنفَّذ أول استعلام من الأساس. دراسة Chroma الصادرة في يوليو 2024 شغّلت 472 استعلاماً على خمس مجموعات نصية باستخدام text-embedding-3-large، وأداة التقسيم التي تختارها تحرّك الاستدعاء بنحو خمس نقاط: 86,7% لأداة تقسيم الرموز البسيطة، و91,7% لأداة GPT-4o، مع استرجاع خمسة أجزاء لكل استعلام. أما الدقة فتتأرجح بعنف أكبر؛ إذ تتراوح عبر التقرير كاملاً بين 1,5% و8,0%، ما يجعل اختيارك لحجم الجزء قرار تكلفة يتنكّر في ثوب الجودة، وكل الأدلة التي تتصدر نتائج البحث تسرد الطرق السبع نفسها دون أن تبيّن أيها يسترجع نتائج أفضل.

أبرز النقاط

• التجزئة تقسّم المستندات قبل التضمين، ونقاط التقسيم تحدد ما تستطيع أداة الاسترجاع إيجاده وما تعجز عنه.
• في دراسة Chroma (يوليو 2024) البالغة 472 استعلاماً، تراوح الاستدعاء بين 86,7% و91,7% عبر أدوات التقسيم التي قِيسَت.
• الدقة تتفاوت بأضعاف ما يتفاوت به الاستدعاء، لذا فحجم الجزء هو في الغالب قرار يتعلق بتكلفة الرموز.
• ابدأ من 512 رمزاً مع تداخل 10%، ثم اضبط الإعدادات وفق مجموعة التقييم الخاصة بك.

أي استراتيجية تجزئة RAG يجب أن تعتمدها؟ (مرتّبة)

لمعظم الفرق التي تعمل على نثر مسطح، التجزئة العودية بالمحارف بحجم 512 رمزاً وتداخل 10% هي الخيار الافتراضي الصحيح. فهي تحترم حدود الفقرات والجمل، ولا تكلف شيئاً إضافياً، وقد حلّت في معيار Chroma (472 استعلاماً) متأخرة 3,2 نقطة استدعاء فقط خلف أداة التقسيم القائمة على LLM. لا تبتعد عنها إلا حين تكون لمستنداتك بنية قوية، أو تُثبت مجموعة التقييم لديك عكس ذلك.

قراءتنا: ابدأ بالتجزئة العودية بالمحارف. فهي لا تتأخر في بيانات Chroma إلا خلف أداتَي التقسيم التجميعي والقائم على LLM من حيث الاستدعاء، ودقة 3,9% لأداة LLM تعني أنك تغذّي المولِّد بنحو ضعف الضجيج لكل رمز ذي صلة. معظم الفرق لا تعاني مشكلة تجزئة، بل مشكلة حجم تجزئة لم تقسها قط.

ماذا تقول البيانات فعلاً عن حجم التجزئة؟

المقارنة العلنية الوحيدة وجهاً لوجه بين استراتيجيات تجزئة RAG هي تقرير Chroma التقني «Evaluating Chunking Strategies for Retrieval» (براندون سميث وأنطون تروينيكوف، نُشر في 3 يوليو 2024). فقد شغّل الكاتبان 472 استعلاماً على 5 مجموعات نصية (328.208 رموز)، وضمّنا كل شيء بنموذج OpenAI text-embedding-3-large، واسترجعا 5 أجزاء لكل استعلام. الصفوف أدناه مأخوذة من جدول ملحق التقرير لجميع المجموعات النصية باستخدام text-embedding-3-large عند 5 أجزاء مسترجعة، لذا فهي قابلة للمقارنة المباشرة في ما بينها:

جدول النتائج الرئيسي في Chroma، الذي يبلغ عن إعداد استرجاع مختلف، يضع أفضل دقة لأداة التقسيم التجميعي عند 8,0% مع استدعاء 87,3%، ويمدّ نطاق الدقة عبر جميع أدوات التقسيم من 1,5% (KamradtSemanticChunker) إلى 8,0%. المصدر: أبحاث Chroma، تقييم استراتيجيات التجزئة

مقالة Anthropic «Introducing Contextual Retrieval» (نُشرت في 19 سبتمبر 2024) تهاجم المشكلة من زاوية مختلفة. كان معدل فشل الاسترجاع الأساسي لأفضل 20 نتيجة لديهم 5,7%، وخفضته التضمينات السياقية وحدها إلى 3,7% (انخفاض 35%)، ثم أوصله BM25 السياقي فوقها إلى 2,9% (49%)، ودفعته إعادة الترتيب إلى 1,9% (67%). ولا تنشر Anthropic حجم الجزء أو التداخل الدقيق المستخدم، لذا تعامل مع هذه الأرقام كأدلة على مستوى الطريقة لا على مستوى الحجم. المصدر: Anthropic، الاسترجاع السياقي.

قراءتنا: ثلاث خلاصات من الحساب. أولاً، اختيار أداة التقسيم يستحق استدعاءً حقيقياً، وChroma تقولها صراحة: بعض الاستراتيجيات تتفوق على غيرها بنسبة تصل إلى 9% في الاستدعاء. فعبر جدول النتائج الرئيسي يتراوح الاستدعاء بين 83,6% (KamradtSemanticChunker) و91,9% (LLMSemanticChunker)، وحتى داخل صفوف استرجاع-5 أعلاه يمتد بين 86,7% و91,7%. أما الدقة فتتحرك أضعاف ذلك على البيانات نفسها: من 1,5% إلى 8,0%، أي انتشار بمقدار 5,3x مقابل 1,1x للاستدعاء. لذا فالاستدعاء هو حيث تلتقط بضع نقاط، بينما الدقة وتكلفة الرموز هما حيث يلسعك الاختيار فعلاً. ثانياً، أداة التقسيم القائمة على LLM تشتري أعلى استدعاء بأسوأ دقة: فأنت تدفع استدعاء LLM لكل مستند وتغذّي المولِّد بضجيج أكثر. ثالثاً، تُظهر أرقام Anthropic أن إثراء الأجزاء بالسياق (من 5,7% إلى 3,7%) حرّك معدل الفشل أكثر مما فعله أي اختيار لأداة التقسيم في جدول Chroma. أثْرِ أجزاءك قبل أن تعيد ضبط أداة التقسيم. إعادة الترتيب تستعيد الأجزاء التي أفسدتها أداة التقسيم، والبحث الهجين يجمع BM25 مع الاسترجاع المتجهي للسبب نفسه.

حدود صادقة: كلتا الدراستين تستخدم نموذج تضمين واحداً ومجموعات نصية بالإنجليزية فقط، ولا تمثل أي منهما اختباراً مضبوطاً لمدونتك. فعبر 472 استعلاماً، بلغت الفجوة بين أفضل أداة تقسيم وأسوئها نحو 5 نقاط استدعاء عند 5 أجزاء مسترجعة، وفجوة أكبر بكثير نسبياً في الدقة.

لماذا يحدد حجم التجزئة جودة الاسترجاع؟

حجم الجزء يحدد درجة تفصيل مفتاح الاسترجاع لديك. فجزء من 400 رمز ينتج تضميناً مركّزاً يطابق استعلامات محددة، بينما جزء من 4.000 رمز يتوسط مواضيع كثيرة فلا يطابق شيئاً بدقة. الأجزاء الصغيرة تسترجع المقطع المطلوب بعينه لكنها قد تفتّت الإجابة عبر النتائج، والأجزاء الكبيرة تحافظ على تماسك السياق لكنها تضعف إشارة التضمين.

والسقف السياقي لنموذج التضمين مهم أيضاً. إذا كان نموذجك يتوقف عند 512 رمز إدخال وأدخلت إليه 800، فسيُقتطع الذيل بصمت، وسيُمثّل التضمين ثلثي الجزء فقط، دون أن يُسجَّل أي خطأ.

ثم جهة المولِّد. فقد أظهر Liu وآخرون في ورقة «Lost in the Middle» ‏(arXiv 2307.03172، 2023) أن دقة LLM تهبط أكثر من 20% حين يقع المستند ذو الصلة في منتصف سياق طويل. واسترجاع خمسة أجزاء من 1.000 رمز يُلقي 5.000 رمز في الموجّه، وقد تهبط الإجابة التي تحتاجها في الموضع الذي يقرأ فيه النموذج بأسوأ ما يكون. الأجزاء الأصغر تُبقي المقطع ذا الصلة أقرب إلى موضع يحسن النموذج التعامل معه.

فكّر في الأمر كفهرس مكتبة: بطاقة مكتوب عليها «القسم 4.2، الفقرة 3: سياسة الاسترداد» توصلك إلى الصفحة، وبطاقة مكتوب عليها «كل شيء عن التجارة في القرن العشرين» توصلك إلى المبنى. تضمينك هو البطاقة. ابنِ تطبيق RAG من البداية إلى النهاية لترى أين تقع التجزئة في خط الأنابيب، واقرأ دليلنا في هندسة السياق لتعرف كيف تتحول الأجزاء المسترجعة إلى رموز في الموجّه. ويؤطر دليل Pinecone للتجزئة المفاضلة نفسها من جهة قاعدة البيانات المتجهية.

التجزئة ثابتة الحجم والتجزئة العودية (ابدأ من هنا)

التجزئة ثابتة الحجم هي خط الأساس الذي تقيس كل شيء عليه، والتجزئة العودية هي ما تشحنه فعلاً إلى الإنتاج.

التجزئة ثابتة الحجم بالرموز

اقسم كل N من الرموز بغض النظر عن المحتوى.

def fixed_size_chunks(text: str, size: int = 512, overlap: int = 50) -> list[str]:
    tokens = text.split()  # whitespace proxy; use tiktoken for real token counts
    chunks = []
    step = size - overlap
    for i in range(0, len(tokens), step):
        chunk = " ".join(tokens[i : i + size])
        chunks.append(chunk)
        if i + size >= len(tokens):
            break
    return chunks

الخيار الصحيح لـ: النثر المسطح بلا بنية ترويسات، والنماذج الأولية السريعة، وأي مقارنة على خط الأساس. إنها ليست فكرة ساذجة، بل هي مجموعة الضبط.

التجزئة العودية بالمحارف

أداة RecursiveCharacterTextSplitter من LangChain تقسّم وفق تسلسل فواصل: أولاً \n\n (الفقرات)، ثم \n (الأسطر)، ثم . (الجمل)، ثم (الكلمات). يبقى كل جزء دون chunk_size مع احترام أكبر حد طبيعي يستوعبه.

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    separators=["\n\n", "\n", ". ", " ", ""],
    length_function=len,  # swap for tiktoken len for true token counts
)
chunks = splitter.split_text(document)

قائمة الفواصل هي الجزء الذي يحذفه كل منافس. فالأداة تجرّب \n\n أولاً ولا تهبط إلى . إلا حين تتجاوز فقرة ما chunk_size. وإذا كان Markdown لديك يحتوي ترويسات، فأضف "## " قبل "\n\n" لتبقى الأقسام سليمة.

حساب تداخل الأجزاء: عند 512 رمزاً وتداخل 50 رمزاً تكون الخطوة 462. مستند من 10.000 رمز ينتج ceil(10000 / 462) = 22 جزءاً. إجمالي الرموز المضمّنة: 22 × 512 = 11.264، أي أنك تعيد تضمين نحو 12,6% من المدونة كتداخل. تلك هي كلفة التخزين والـ API لمنع انعزال جمل الحدود.

كيف تعمل التجزئة الدلالية، وهل تستحق التكلفة؟

التجزئة الدلالية تضمّن كل جملة، وتقيس مسافة جيب التمام بين تضمينات الجمل المتجاورة، وتقسّم حيث تتجاوز تلك المسافة عتبة مئينية (عادة المئين 95). فتنكسر الأجزاء عند تحولات الموضوع لا عند أعداد رموز اعتباطية. وقد ابتكر دفتر Greg Kamradt «5 Levels of Text Splitting» هذا النهج القائم على نقاط الانقطاع المئينية، ودراسة Chroma تختبر أدوات التقسيم الخاصة به بالاسم.

from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
splitter = SemanticChunker(
    embeddings,
    breakpoint_threshold_type="percentile",
    breakpoint_threshold_amount=95,
)
chunks = splitter.split_text(document)

حساب التكلفة هو الجزء الذي لا يضعه أحد في الواجهة. التجزئة الدلالية تضمّن مدونتك مرتين: مرة لحساب مسافات الجمل وإيجاد نقاط الانقطاع، ومرة لتضمين الأجزاء الناتجة للفهرسة. فبسعر text-embedding-3-large من OpenAI البالغ 0,13$ لكل مليون رمز، تكلف مدونة من 10 ملايين رمز 1,30$ للفهرسة العادية و2,60$ مع التجزئة الدلالية. أنت تدفع الضعف قبل أن يُنفَّذ استعلام واحد.

وماذا تشتري بذلك؟ في صفوف استرجاع-5 لدى Chroma، حققت أداة التجزئة الدلالية التجميعية استدعاء 89,0% ودقة 6,7% مقابل 88,5% و7,0% للتجزئة العودية بالحجم نفسه (200 رمز). وفي جدول النتائج الرئيسي تسجّل الأداة نفسها أفضل دقة في الدراسة، 8,0%، باستدعاء 87,3%. نصف نقطة استدعاء زيادة أو نقصاناً، ونتيجة دقة تنقلب علامتها بحسب إعداد الاسترجاع الذي تقرأه، مقابل فاتورة تضمين مضاعفة. حكمنا: التجزئة الدلالية تؤتي ثمارها مع المدونات المتنوعة الموضوعات (أرشيفات الأخبار، مجموعات الأوراق البحثية) حيث تقسم الحدود الثابتة منتصف الموضوع بشكل روتيني. أما المدونات المتجانسة (توثيق المنتج، قاعدة معرفية واحدة) فالتجزئة العودية تمنحك 95% من الجودة بنصف التكلفة. وإذا كنت تشغّل نماذج التضمين محلياً عبر Ollama، تهبط كلفة التضمين المزدوج إلى زمن حساب فقط.

التجزئة الواعية بالمستند: Markdown وHTML والشيفرة

التقسيم الواعي بالبنية تستخدم حدود المستند نفسه (الترويسات، عناصر القوائم، تعريفات الدوال) بدلاً من أعداد المحارف. فترويسة H2 في Markdown حدّ دلالي وضعه إنسان عن قصد، وأداة تقسيم المحارف تمزقه إرباً.

from langchain_text_splitters import MarkdownHeaderTextSplitter

headers = [("#", "h1"), ("##", "h2"), ("###", "h3")]
splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers)
splits = splitter.split_text(markdown_doc)
# Each split carries metadata: {"h1": "...", "h2": "...", "h3": "..."}

في الشيفرة، الحدود هي عقد AST. وتوفر أدوات NodeParsers من LlamaIndex أدوات تقسيم واعية باللغة تنكسر عند تعريفات الدوال والأصناف. والتفصيلة الحاسمة: أبقِ كتلة الاستيراد وتوقيع الصنف الحاوي ملتصقين بكل جزء دالة. فمتن دالة بلا استيراداتها ضجيج لا يقبل التضمين، لذا صدّر كليهما قبل كل جزء ليلتقط التضمين ما تفعله الدالة وما تعتمد عليه.

ولـ RAG الشيفرة تحديداً: تقسيم عند حدود AST، استيرادات في المقدمة، 256-512 رمزاً لكل دالة، وصفر تداخل.

ماذا عن التجزئة المتأخرة والهرمية والقائمة على الوكلاء؟

هذه هي استراتيجيات تجزئة RAG المتقدمة الكامنة خلف ضجيج «RAG 2.0»، وجميعها الثلاث لا تتجاوز تغطيتها 1/10 في صفحات النتائج.

التجزئة المتأخرة

التجزئة المتأخرة، التي قدّمها Günther وآخرون في ورقة «Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models» ‏(arXiv 2409.04701، سبتمبر 2024)، تضمّن المستند كاملاً بنموذج طويل السياق أولاً، ثم تجمّع تضمينات مستوى الرموز في متجهات أجزاء، فيحمل كل جزء سياق المستند بأكمله وتعرف عبارة «تكلف 40$ شهرياً» إلى ماذا يشير الضمير. ويدّعي الملخص تفوقاً في الاسترجاع عبر المهام لكنه لا ينشر رقماً رئيساً يمكن التحقق منه. ويشرح مقال Weaviate الآلية ويتوقف هو الآخر قبل المقارنة المضبوطة. حالة الدليل: واعد، غير مُكمَّم.

التجزئة الهرمية (أصل-فرع)

فهرِس أجزاء صغيرة (256 رمزاً) للاسترجاع، وأعد الأصل (1.024 رمزاً) إلى المولِّد. تجد أداة الاسترجاع الإبرة، ويحصل المولِّد على كومة القش المحيطة بها. ستحافظ على مستويَي فهرس وخريطة أصل-فرع. ولا يوجد معيار منشور يعزل هذا الأثر.

التجزئة القائمة على LLM / الوكلاء

أداة LLMSemanticChunker في دراسة Chroma تستخدم GPT-4o لتحديد نقاط التقسيم لكل مستند: استدعاء 91,7% (الأعلى) ودقة 3,9% (الأدنى). أنت تدفع استدعاء LLM لكل مستند عند الفهرسة (نحو 100$ لمدونة من 10.000 مستند) وتغذّي المولِّد بضجيج أكثر. احتفظ بها للمدونات غير المنتظمة حقاً: المذكرات القانونية، وملفات PDF الممسوحة بلا ترويسات قابلة للاستخراج.

أي حجم تجزئة يناسب نموذج التضمين لديك؟

الحد الأقصى لرموز الإدخال في نموذج التضمين لديك هو سقف اقتطاع، لا توصية. فالنموذج الذي يقبل 8.192 رمزاً لا يضمّن عند 8.192 أفضل مما يضمّن عند 512. الجودة تتدهور بالتخفيف قبل السقف بزمن طويل: فالنموذج يتوسط المعنى عبر رموز أكثر فينزف المتجه نحو مركز المدونة. وعمود التوصية أدناه هو تفسير Techsy، لا إرشاد المورّدين.

المصادر: دليل تضمينات OpenAI، توثيق Cohere embed، توثيق تضمينات Voyage، بطاقة نموذج BGE.

النمط: النماذج ذات السقف الصارم عند 512 رمزاً (Cohere v3، BGE) تتطلب أجزاء دون 512 بفارق مريح، لأن الاقتطاع صامت. أدخل 600 رمز لأحدها وستختفي آخر 88 رمزاً من التضمين دون تسجيل أي خطأ. والنماذج ذات الأسقف الكبيرة (OpenAI، Voyage، Cohere v4) تتسامح مع أجزاء أكبر لكنها لا تكافئ عليها. فالطول الأقصى لإدخال النموذج حدّ اقتطاع، لا توصية.

زاوج هذا مع جولة أفضل نماذج التضمين لـ RAG، وماذا تقيس نتيجة MTEB فعلاً، وتضمينات Voyage وOpenAI وCohere جنباً إلى جنب قبل أن تستقر على نموذج.

كيف تجزّئ المستندات غير الإنجليزية؟

أدوات الترميز ليست محايدة لغوياً. فقد أظهر Petrov وآخرون في ورقة «Language Model Tokenizers Introduce Unfairness Between Languages» ‏(arXiv 2305.15425، 2023) أن النص نفسه المترجم عبر اللغات قد يختلف طوله بعد الترميز بما يصل إلى 15x. وحتى النماذج على مستوى المحارف أو البايتات تُظهر فرقاً يتجاوز 4x لبعض أزواج اللغات. فجزء من 512 رمزاً يحمل معنى أقل بكثير بالتركية أو العربية أو اليابانية مما يحمله بالإنجليزية.

هنا الجملة نفسها مرمّزة بترميز cl100k_base من tiktoken (أداة ترميز GPT-4):

import tiktoken
enc = tiktoken.get_encoding("cl100k_base")
en = "The retrieval system returns relevant documents."
tr = "Erişim sistemi ilgili belgeleri döndürür."
ja = "検索システムは関連文書を返します。"
print(len(enc.encode(en)), len(enc.encode(tr)), len(enc.encode(ja)))
# 7 tokens, 19 tokens, 19 tokens: same meaning, 2.7x token spread

الأعداد مولّدة بـ tiktoken cl100k_base في 30 يوليو 2026.

إرشاد عملي: عند حجم جزء ثابت من 512 رمزاً، تحمل أجزاؤك التركية واليابانية نحو 37% من المعنى الذي تحمله أجزاؤك الإنجليزية، وتحمل أجزاؤك العربية نحو 26%. جزّئ حسب عدد المحارف أو عدد الجمل لكل لغة، أو ارفع ميزانية الرموز تناسبياً (نحو 1.400 للتركية و2.000 للعربية). ولغات CJK ليست فيها حدود كلمات بالمسافات البيضاء، لذا تتصرف أدوات تقسيم المحارف بشكل مختلف. ويحشو الصرف العربي علامات نحوية متعددة في رموز مفردة، ما ينفخ الأعداد أكثر.

شجرة قرار لاختيار استراتيجية التجزئة

What kind of document?
├── Structured (Markdown / HTML / code)
│   └── Document-aware splitting on headers or AST boundaries
│       ├── Docs site → MarkdownHeaderTextSplitter, 512 tokens, 0 overlap
│       └── Codebase → AST/function splitter, 256-512 tokens, imports prepended
├── Flat prose (articles, reports, books)
│   └── RecursiveCharacterTextSplitter, 512 tokens, 50 overlap
│       └── Topic-diverse? → try SemanticChunker at 95th percentile
├── Conversational logs (chat, support tickets)
│   └── Split on turn boundaries, group 3-5 turns per chunk, 256 tokens
└── Mixed corpus
    └── Route by MIME type → apply per-type strategy above
        └── Then: how long are expected answers?
            ├── Short (1-2 sentences) → child 256, no parent
            └── Long (multi-paragraph) → hierarchical: child 256, parent 1,024

ثلاث وصفات سريعة. روبوت دردشة للتوثيق: MarkdownHeaderTextSplitter بحجم 512 رمزاً وصفر تداخل ومسار الترويسات في البيانات الوصفية. مساعد بحث في الشيفرة: تقسيم عند حدود AST بحجم 256-512 رمزاً لكل دالة مع الاستيرادات في المقدمة. مدونة مؤسسية مختلطة: وجّه حسب نوع المستند عند الإدخال وخزّن في قاعدة البيانات المتجهية التي تخزّن فيها الأجزاء مع بيانات وصفية للنوع لضبط لاحق لكل نوع. وهذا التوجيه لكل مستند هو جوهر التجزئة التكيفية لتطبيقات RAG.

الأدوات: LangChain مقابل LlamaIndex مقابل Chonkie

نحن لا نبيع أياً من هذه؛ فأعلى ثلاث صفحات ترتيباً لهذه الكلمة المفتاحية مدونات مورّدين تحمل أزرار شراء.

المصادر: توثيق LangChain، LlamaIndex NodeParsers، توثيق Chonkie.

المكتبات الثلاث تطبّق الخوارزميات الجوهرية نفسها، لذا اختر بناء على ما يستخدمه خط أنابيبك أصلاً. وللاطلاع على منظومة أدوات RAG الأوسع خارج أدوات التقسيم ومقارنة Qdrant وChroma وpgvector للتخزين، راجع أدلة العنقود لدينا.

كيف تتعامل Techsy مع التجزئة

في مشاريع RAG التي نبنيها للعملاء، يبدأ فريق Techsy من 512 رمزاً مع تداخل 10% ولا يمس أداة التقسيم حتى نبني مجموعة تقييم من 20-50 سؤالاً من تذاكر الدعم الحقيقية للعميل. مجموعة التقييم تأتي أولاً، ثم نغيّر متغيراً واحداً في كل مرة: الحجم، التداخل، الاستراتيجية. ولا تبديل لأداة التقسيم بلا رقم قبل-وبعد على الأسئلة نفسها. احصل على استشارة مجانية لعين ثانية على خط أنابيب الاسترجاع لديك.

عن الكاتب

Mert Batur شريك مؤسس في Techsy.io، حيث يشحن الفريق وكلاء ذكاء اصطناعي وأنظمة أتمتة وخطوط أنابيب صوتية/SDR لعملاء B2B. يكتب عن منظومة أدوات LLM التي يستخدمها فريق Techsy فعلاً في الإنتاج، بما في ذلك عمل RAG والاسترجاع خلف بناء القواعد المعرفية للعملاء. تواصل معه على LinkedIn.

الأسئلة الشائعة

ما التجزئة في RAG؟

التجزئة خطوة المعالجة المسبقة التي تقسّم المستندات إلى مقاطع أصغر قبل التضمين، لتتمكن أداة الاسترجاع من مطابقة الاستعلامات مع مقاطع مركّزة بدلاً من الملفات كاملة. ونقاط التقسيم تحدد ما يمكن لنظامك إيجاده وما لا يمكنه وقت الاستعلام.

ما أفضل استراتيجية تجزئة لـ RAG؟

لمعظم أنظمة الإنتاج العاملة على مستندات عامة، التجزئة العودية بالمحارف بحجم 512 رمزاً وتداخل 10% هي أقوى خيار افتراضي. ففي دراسة Chroma (472 استعلاماً، يوليو 2024) سجلت استدعاء 88,5%، على بُعد 3,2 نقطة من الطريقة القائمة على LLM الأعلى كلفة، وبدون أي تكلفة إضافية.

ما حجم التجزئة الأمثل لـ RAG؟

ابدأ من 512 رمزاً. انزل إلى 256 إذا كان نموذج التضمين يتوقف عند 512 رمز إدخال (Cohere v3، BGE) أو كانت استعلاماتك تتوقع إجابات من جملة واحدة. واصعد إلى 1.024 فقط إذا أظهرت مجموعة التقييم لديك تفتت الإجابات متعددة الفقرات. قس دائماً على أسئلتك أنت.

كم مقدار التداخل بين الأجزاء الذي يجب استخدامه؟

‏10-20% من حجم الجزء (50-100 رمز عند 512). التداخل يمنع انعزال جمل الحدود: فالحقيقة المقسومة على جزأين تظهر كاملة في أحدهما على الأقل. وفوق 20% تعيد تضمين قدر كبير من المدونة مقابل عوائد متناقصة. معظم الفرق تستقر على 10% ولا تعود إليها أبداً.

هل التجزئة الدلالية أفضل من التجزئة ثابتة الحجم؟

بفارق ضئيل، وبتكلفة تضمين مضاعفة. فقد أظهر معيار Chroma في يوليو 2024 أداة التجزئة الدلالية التجميعية باستدعاء 89,0% ودقة 6,7% مقابل استدعاء 88,5% ودقة 7,0% للتجزئة العودية بحجم الرموز نفسه، مع مجيء أفضل نتيجة دقة لها (8,0%) من إعداد استرجاع مختلف. تستحق العناء للمدونات المتنوعة الموضوعات، ويصعب تبريرها لمجموعات المستندات المتجانسة.

هل يعتمد حجم التجزئة على نموذج التضمين؟

نعم. النماذج ذات سقف إدخال 512 رمزاً (BGE، Cohere v3) تتطلب أجزاء دون 512 بفارق مريح لأن الاقتطاع صامت. والنماذج ذات الأسقف 8.192+ تتسامح مع أجزاء أكبر لكنها لا تكافئ عليها؛ فجودة التضمين تتدهور بالتخفيف قبل بلوغ السقف. راجع جدول الاقتران أعلاه لنقاط البداية لكل نموذج.

كيف أجزّئ الشيفرة لنظام RAG؟

قسّم عند حدود AST (تعريفات الدوال والأصناف) لا عند أعداد الرموز. أبقِ كل جزء عند 256-512 رمزاً لكل دالة، وصدّر كتلة استيراد الملف وتوقيع الصنف الحاوي قبله، واستخدم صفراً من التداخل لأن الدوال وحدات مكتفية ذاتياً. وكل من CodeSplitter من LlamaIndex وأدوات التقسيم الواعية باللغة من LangChain يتكفل بهذا.

ما التجزئة المتأخرة؟

التجزئة المتأخرة تضمّن المستند كاملاً بنموذج طويل السياق أولاً، ثم تجمّع تضمينات مستوى الرموز في متجهات أجزاء. كل تضمين جزء يحمل سياق المستند بأكمله، ما يحل مشكلة «إلى ماذا يشير الضمير؟». قدّمها Günther وآخرون (arXiv 2409.04701، سبتمبر 2024). ولا يوجد معيار مقارن منشور يُكمّم المكسب بعد.

كيف أجزّئ المستندات بلغات غير الإنجليزية؟

أعداد الرموز ليست محايدة لغوياً. الجملة نفسها استهلكت رموزاً أكثر بـ 2,7x بالتركية واليابانية مقارنة بالإنجليزية، وبـ 3,9x بالعربية (tiktoken cl100k_base). وميزانية ثابتة من 512 رمزاً تمنح الأجزاء غير الإنجليزية معنى أقل بصمت. جزّئ حسب عدد المحارف أو الجمل لكل لغة، أو ارفع الميزانية تناسبياً.

كيف أعرف أن التجزئة لدي تعمل فعلاً؟

ابنِ مجموعة تقييم من 20-50 سؤالاً من استعلامات مستخدمين حقيقية قبل أن تمس أداة التقسيم. قس hit@5 وMRR على أجزائك الحالية. غيّر متغيراً واحداً (الحجم، التداخل، الاستراتيجية)، أعد التشغيل، وقارن. بلا مجموعة تقييم أنت تضبط بالإحساس. عشرون سؤالاً تكفي للبداية.

الخلاصة

• ابدأ بالتجزئة العودية بالمحارف عند 512 رمزاً وتداخل 10%. الخيار الافتراضي الصحيح للنثر المسطح.
• عبر عائلات أدوات التقسيم الأربع التي قاسها أحد، تحرّك استعلامات Chroma البالغ عددها 472 الاستدعاءَ نحو 5 نقاط والدقةَ أضعاف ذلك. اضبط للدقة والتكلفة أولاً.
• واءم حجم الجزء مع سقف إدخال نموذج التضمين. نموذج سقفه 512 رمزاً يتطلب أجزاء دون 512.
• أثْرِ الأجزاء بالسياق (انخفاض معدل الفشل لدى Anthropic من 5,7% إلى 3,7%) قبل إعادة ضبط أداة التقسيم.
• ابنِ مجموعة التقييم أولاً. كل قرار بشأن أداة التقسيم بلا رقم قبل-وبعد هو تخمين.

للاطلاع على خط الأنابيب الكامل المحيط بخيار التجزئة، راجع ابنِ تطبيق RAG من البداية إلى النهاية. ولا تزال تحتار بين الاسترجاع والضبط الدقيق؟ مقال RAG أم الضبط الدقيق يفصّل متى تنتصر كل طريقة.