RAG की योजना: खंडों, ओवरलैप और वेक्टर आकार का अनुमान
खंडों और वेक्टर आकार का अनुमान खोज योग्य ज्ञान-संग्रह की योजना बनाने में मदद करता है। संसाधित टेक्स्ट और कच्चे स्टोरेज को समझने के लिए सेटिंग्स की तुलना करें, फिर प्रतिनिधि नमूने पर खोज की गुणवत्ता और इंडेक्स का वास्तविक आकार जांचें।
ओवरलैप की लागत और संभावित लाभ
खंड बनाने से छोटे हिस्से संसाधित किए जा सकते हैं। ओवरलैप सीमा पर साझा टेक्स्ट रखता है, लेकिन उसे फिर संसाधित करता है। हर दस्तावेज़ और प्रश्न के लिए एक आदर्श अनुपात नहीं है।
सामग्री को तय विंडो के बजाय अनुच्छेद या शीर्षक की सीमाएँ चाहिए हो सकती हैं। अधिक खंड हमेशा बेहतर मानने के बजाय छोटे संग्रह पर प्रतिनिधि प्रश्नों का मूल्यांकन करें।
संदर्भ: Microsoft — Chunking strategies and overlap trade-offs
कैलकुलेटर एक निरंतर टोकन धारा मानता है
ToolRoof निरंतर संग्रह, तय विंडो और संभवतः छोटे अंतिम खंड का मॉडल बनाता है। आगे बढ़ने का अंतर आकार घटा ओवरलैप है; इसलिए ओवरलैप विंडो से छोटा होना चाहिए।
दस्तावेज़ों की सीमाएँ मॉडल में नहीं हैं। 100 छोटे दस्तावेज़ अलग बाँटना उनके टोकन जोड़कर एक धारा मानने से अलग हो सकता है। टूल टेक्स्ट अपलोड या एम्बेडिंग नहीं बनाता; टोकन संख्या आप देते हैं।
कच्चे आकार को कच्चा आकार ही कहें
कच्चा आकार वेक्टर संख्या × आयाम × प्रति आयाम बाइट है। इंडेक्स अतिरिक्त संरचनाएँ जोड़ता है; टेक्स्ट, मेटाडेटा, प्रतियाँ और अपडेट का अतिरिक्त भार पूरा शामिल नहीं है।
आयाम या निरूपण बदलना एम्बेडिंग मॉडल और डेटाबेस के अनुकूल होना चाहिए। परिणाम खोज की सटीकता, होस्टिंग खर्च या उत्तर की गुणवत्ता साबित नहीं करता।
उदाहरण: 2500 टोकन और 4 विंडो
2500 टोकन, विंडो 800 और ओवरलैप 200 होने पर कदम 600 है। लंबाइयाँ 800, 800, 800 और 700 हैं: कुल 3100 संसाधित टोकन, जिनमें 600 दोहराए गए हैं। यह गणना का मॉडल है, चलाए गए RAG का परिणाम नहीं।
प्रत्येक वेक्टर में 384 आयाम और हर आयाम में 4 बाइट हों तो 4 वेक्टर का कच्चा आकार 6144 बाइट, यानी 6 KiB है। शून्य ओवरलैप पर भी इस उदाहरण में 4 खंड हैं, पर एम्बेडिंग इनपुट 2500 टोकन है। समान कच्चा आकार समान खोज गुणवत्ता सिद्ध नहीं करता।