لنفترض أنك تبني بحثًا على وثائق فريقك الداخلية — الأدلة، كتب التشغيل، تقارير ما بعد الحادث. لديك جدول مع تضمين تلقائي: تدخل النص، يشغل Manticore النموذج ويملأ عمود المتجه تلقائيًا. تحمّل وثيقة من 4000 كلمة. ينجح الإدراج. يعمل البحث. باستثناء أن النموذج لديه نافذة إدخال 512 توكن، وتلك الوثيقة حوالي 5000 توكن. قرأ النموذج أول 380 كلمة وألقى بالباقي 3600 كلمة.

يتعامل Manticore الآن مع هذا في تعريف الجدول: أضف chunk_strategy إلى عمود المتجه في CREATE TABLE، فيقسم Manticore كل وثيقة إلى أجزاء، ويضمّن كل جزء، ويبحث في جميعها. خمس استراتيجيات: truncate، mean، fixed، recursive، sentence. تظل الوثيقة نتيجة بحث واحدة. تتنافس الأجزاء فرديًا، ويعيد Manticore الوثيقة مرة واحدة، مع knn_dist() تُبلغ عن المسافة إلى أقرب جزء. k يحسب الوثائق، لا الأجزاء.

قيس على دليل Manticore (189 صفحة، ~298k كلمة): ارتفع recall@5 من 55.1% إلى 83.3% و MRR من 0.44 إلى 0.70، مع ~2.5× ذاكرة الوصول العشوائي و ~4× وقت الاستيعاب. الاستعلامات لا تُجزّأ أبدًا. الاستعلام قصير بما يكفي ليُضمّن ككل؛ فقط الوثائق المخزنة تُقسم.