스크립트
00:00:00مرحباً بالجميع. شكراً لحضوركم اليوم. أهلاً بكم في حديث عن لا شيء. عذراً، حديث عن
00:00:21الاسترجاع. اسمي يوفال. أعمل في AI21، وهي في جوهرها مختبر أبحاث ذكاء اصطناعي. واليوم،
00:00:29أريد أن أحدثكم عن شيء لا يرغب معظم الناس في الحديث عنه، ألا وهو التجزئة (Chunking).
00:00:37وأتمنى أن أكون قادراً على إقناعكم في النهاية بأن التجزئة لم تموت، وأن هناك ما يمكن فعله حيال ذلك.
00:00:45وفي الواقع، إذا كنتم تتابعون إكس، أو لينكد إن، أو أي منصة أخرى، فمن المحتمل أنكم رأئم أن تقنية RAG قد ماتت، أليس كذلك؟
00:00:53أعتقد أن الناس قتلوا أيضاً بروتوكول MCP مؤخراً. ومجدداً، ماتت تقنية RAG. فلتخيا الاسترجاع العضوي،
00:01:00البحث العضوي. ويأتي وقت يتعين عليك فيه أن تسأل نفسك: كم مرة يمكن لتقنية RAG أن تموت؟
00:01:07أليس كذلك؟ وحتى عندما يقول أحدهم، حسناً، تقنية RAG لم تمت، مثل جيري، الرئيس التنفيذي لشركات لاما إندكس،
00:01:14فإنهم ما زالوا بحاجة لقتل شيء ما. وكما يبدو، هذا الشيء هو التجزئة. كأن يقولون: لا تستثمروا فيها.
00:01:23لا تفعلوا ذلك. وهذا هو السبب الذي جعل الناس يقولون إن التجزئة قد ماتت، لأن الجميع يستخدمون
00:01:30البحث الموجه بالوكلاء (agentic search) الآن، أليس كذلك؟ لديك أوامر grep، وls، وfind. كل هذه أدوات رائعة،
00:01:36ولكنها لا تزال غير كافية إذا كان لديك الكثير من البيانات ومجموعة متنوعة من الاستعلامات.
00:01:46حسناً، دقيقة واحدة. وأعتقد أن السبب الرئيسي وراء عدم إعجاب الكثير من الناس بالحديث
00:01:51عن التجزئة، هو أنها ليست الجزء الممتع، أليس كذلك؟ في أي نظام RAG أو نظام ملفات،
00:02:00لدينا مرحلتان. المرحلة الأولى هي المرحلة المملة، إذا صح التعبير. تلك التي تقوم بها في البداية،
00:02:07حين يكون لديك الكثير من البيانات. عليك بمعالجتها مسبقاً. وعليك تحديد حجم التجزئة. وبعد ذلك
00:02:13يجب عليك تخزين كل شيء في قاعدة بيانات متجهة. أما الجزء الآخر فهو جزء الاسترجاع، وتحديداً ذاك
00:02:20الذي يحدث لكل استعلام على حدة. وهذا أمر أسهل بكثير للقيام به، أليس كذلك؟ من الأسهل بكثير
00:02:25تحسينه. يمكنك استخدام جميع استعلاماتك ومن ثم اللعب بمعامل max K، أو top K، عذراً، يمكنك اللعب
00:02:32بالبحث الهجين ربوريا، ومثل هذه الأمور. ضبط الاسترجاع هو أمر أكثر متعة بكثير، أليس كذلك؟
00:02:40لذا سأزعم أنه إذا كان علينا قتل شيء ما، وإذا كان لابد لشيء أن يموت، فهذا غالباً ما يكون
00:02:47ضبط الاسترجاع. ونعم، ربما يكون البحث الموجه بالوكلاء قد قضى على ذلك. ولكن مع ذلك، البحث الموجه بالوكلاء، حتى لو أمكننا
00:02:55قبول حقيقة أنه قضى على ضبط الاسترجاع، لا يزال غير جيد بما يكفي عندما يكون لديك قدر هائل من
00:03:02البيانات. إنه يكلف الكثير من المال. ولا أعتقد أنني بحاجة لذكر ذلك بعد الآن. تعظيم الرموز (Token maxing)
00:03:09هو أمر يتحدث عنه الجميع. والشيء الكامن تحته، وهو أنه إذا لم تكن البيانات نفسها
00:03:17مرتبة بالطريقة الصحيحة في مجلداتك وأدلتك، فسوف تحصل في النهاية على شيء
00:03:25غير كفء. لذا دعونا نحاول التفكير في مثال في الوقت المناسب، أليس كذلك؟ بطولة كأس العالم لكرة القدم تقام الآن. ودعونا
00:03:33نتخيل أن لدينا مجموعة بيانات تحتوي على كافة بطولات كأس العالم. إذن كل مجلد يمثل، فلنقل،
00:03:40بطولة عام 98، وبطولة عام 2002، وهكذا دواليك. ولكن إذا كان استعلامك يسأل عن الفريق الذي فاز بأكبر عدد من بطولات كأس
00:03:50العالم، فلا يمكنك ببساطة الذهاب إلى مجلد والوصول إلى ذلك. بل عليك الذهاب إلى كل مجلد، ومعرفة من فاز،
00:03:57ثم تجميع هذه النتائج معاً، وهو أمر غير كفء للغاية. والإجابة الفورية هي البرازيل، آمل ذلك، على الأقل
00:04:03وفقاً للوقت الذي تجري فيه هذه المحادثة. إذن الاسترجاع لم يمت في الواقع. نحن لا
00:04:13نقتل أي شيء في هذه المحاضرة. لقد تحول إلى مجرد أعمال سباكة وخلفيات تقنية. وأعتقد أن كل من عمل على
00:04:21أي نظام RAG يعرف هذا الشعور. في اليوم الأول، أو الأسبوع الأول، أو ربما حتى الشهر الأول إذا كنت دقيقاً للغاية،
00:04:29فإنك تختار نوعاً ما حجم التجزئة. وليكن مثلاً 512. وربما تضع بعض التداخل (overlap)،
00:04:36أليس كذلك، بنسبة 10%، 20%، وما إلى ذلك، وتقوم بفهرسة كل شيء، ثم تنسى الأمر برمته. ويمكنك فعل ذلك، أليس كذلك،
00:04:43نحن نتحدث كثيراً عن استراتيجيات التجزئة الثابتة، حيث إذا كانت جزئك كبيرة جداً،
00:04:49أليس كذلك، فسوف تحصل على الصورة الكاملة، وهذا أمر لطيف، ولكنك تفقد الكثير من التفاصيل الدقيقة. ولن تحصل جميع
00:04:54الجزئيات على تمثيلات تضمينية (embeddings) ذات معنى. أما إذا اخترت أن تكون أجزاؤك صغيرة جداً،
00:05:00فستفقد الصورة الكبيرة. وواقعياً، لن يكون النظام بنفس الكفاءة. وما يخبرنا به هذا هو
00:05:07أن التجزئة هي في جوهرها ضغط يفقد بعض البيانات. بغض النظر عما نفعله، فإننا نفقد شيئاً ما.
00:05:15وسأزعم أنه لا يوجد حجم تجزئة صحيح بالمطلق. والكثير منكم ممن عملوا على البيانات سيقولون:
00:05:23لا، بل لدينا هذه المدونة (corpus)، لدينا مجموعة البيانات هذه، وقد استخدمناها بالفعل وحسّننا نظامنا
00:05:29ليعمل بشكل جيد للغاية على هذه البيانات. ونحن ظننا ذلك أيضاً. لقد كانت لدينا تجربة كبيرة مع ذلك،
00:05:35مع الكثير من الأنواع المختلفة من الوكلاء والأنظمة وسير العمل حيث يمكنك حقاً،
00:05:40أليس كذلك، تفكر في معايير القياس (benchmarks)، ومدى سهولة فرط تخصيص نموذجك (overfit) لمعيار قياس معين.
00:05:48ولكن ليس مع تقنية RAG. فهذا لا يحدث هناك. ولا يمكنك حقاً تحسينها لكل مجموعة بيانات على حدة. وسأعرض عليكم
00:05:54كيفية التأكد من أنها تعتمد على الاستعلام. وكيف أكون متأكداً إلى هذا الحد؟ كيف يمكنني الادعاء بمثل هذا
00:06:00الشيء؟ لأننا أجرْنا تجارب، واختبرناها، والآن سأقوم بعرضها عليكم. إذن ما قمنا به،
00:06:06بدلاً من القول ما هو أفضل حجم تجزئة لكل بيانات، دعنا نكتشف ذلك. دعنا نأخذ في الواقع مجموعة بيانات
00:06:14ونقوم بمضاعفة مجموعة البيانات هذه عدة مرات. في هذه الحالة، ست مرات. وفي كل عملية مضاعفة،
00:06:23وفي كل نسخة، يكون حجم التجزئة مختلفاً. إذن لدينا قاعدة بيانات بحجم تجزئة يبلغ 2000،
00:06:28وقاعدة بيانات بحجم تجزئة يبلغ 1000، وهكذا دواليك. وفعلنا ذلك مع عدة مجموعات بيانات،
00:06:36مثل QMSUM، وهي مجموعة بيانات لنصوص الاجتماعات. وNarrative QA، وهي الإجابة على الأسئلة المتعلقة
00:06:41بالروايات. ومجموعة بيانات ساينفيلد (Seinfeld)، وهي عبارة عن معلومات عامة عن لا شيء. ليس حقاً، بل هي أسئلة معلومات عامة
00:06:49حول نصوص مسلسل ساينفيلد. إنه نوع من مجموعات البيانات الساخرة التي أنشأناها بأنفسنا داخلياً. لقد قمنا أيضاً
00:06:56بنشرها لمن يرغب في الحصول على الرابط في النهاية. واختبرناها على جميعها لنرى ما سيحدث.
00:07:03أولاً وقبل كل شيء، أردنا فقط أن نرى لكل مجموعة بيانات، أي حجم تجزئة هو الأفضل. وما
00:07:10نراه هنا هو مثال من مجموعة بيانات ساينفيلد، حيث يعطي أساساً استعلامان، يختلفان في جوهرهما،
00:07:16نتائج مختلفة بناءً على حجم التجزئة ذلك. السؤال الأول إذن: ما هو اسم
00:07:24قميص جيري المفضل؟ يمكنك أن ترى أن هذا سؤال مركز للغاية، وسؤال محدد للغاية.
00:07:28ومن المرجح أن الإجابة عليه محصورة في نطاق ضيق. وهذا هو النوع الذي يؤدي فيه
00:07:33حجم التجزئة الأصغر أداءً أفضل. ويمكنك رؤية المرتبة الأولى مقابل مرتبة تقل عن 50. بين حجم تجزئة ثابت قدره 100 رمز
00:07:43إلى 100. بينما سؤال مثل: من هو الشخص الذي يصفه جيري بأنه عدوه اللدود والشر المحض،
00:07:50والذي لست حتى معجباً كبيراً بمسلسل ساينفيلد ومع ذلك أعرف أنه نيومان (Newman). ولكن إذا نظرت إلى
00:07:56النص، فهو ليس شيئاً يمكنك العثور عليه بهذه السهولة. ويمكنك أن ترى أنه يتغير حقاً، أليس كذلك؟ إذا كنت تستخدم
00:08:02حجم تجزئة صغيراً، فلن تحصل على الإجابة. وما قمنا به حقاً -- بعد أن شغلنا
00:08:10كل هذه الأمور وكل هذه الاختبارات، لاحظنا، وقلنا، ماذا لو كان لدينا عراف (oracle)، أو جني، إذا
00:08:19شئت، يمكنه أن يخبرنا، لكل استعلام، ما هو أفضل حجم تجزئة لإجراء الاسترجاع لأجله؟ هذا هو في الأساس
00:08:25تجربة العراف. هذا ما أردنا معرفته لنرى الإمكانات. هذا ليس -- نحن نمتلك بالفعل
00:08:33القدرة على بناء نظام هنا. نحن نريد فقط أن نرى ما هي الإمكانات التي نملكها هنا. وما يمكنك
00:08:38رؤيته هنا، حسناً، في هذا الرسم البياني، كل الخطوط الزرقاء -- أولاً، المحور الرأسي هو نسبة الاسترجاع (recall). وكلما زاد كان أفضل. والمحور
00:08:46الأفقي هو عدد الجزئيات المسترجعة. إذن هي نسبة الاسترجاع عند k مقابل k. يمكنك رؤية جميع الخطوط الزرقاء، وربما
00:08:52لا يمكن تمييزها عن بعضها، ولكن كل منها يمثل الأداء لحجم تجزئة ثابت. بينما الخط البرتقالي هو
00:09:01خط العراف. هذا هو -- لكل استعلام، أخذنا الأفضل من بين هؤلاء. ويمكنك أن ترى أنه يحدث
00:09:09عبر عدة مجموعات بيانات. في كثير منها، يمكنك أن ترى في الواقع أن الخطوط الزرقاء تتقاطع مع
00:09:16بعضها البعض، مما يعني أنه في الواقع بالنسبة للعديد من مجموعات البيانات، لا يوجد حجم تجزئة يهيمن لوحده. وما هو
00:09:24أكثر إثارة للاهتمام هو أن هناك إمكانات هائلة. الفجوة، التي يمكنك رؤيتها بين الخط البرتقالي
00:09:30وجميع الخطوط الزرقاء، هي فجوة كبيرة. وعندما أقول كبيرة، فهي تبدو بحدود 20 إلى 40 بالمائة فقط من
00:09:38خلال وضع استراتيجية للتجزئة. واستراتيجية بسيطة للغاية، إن جاز لي القول. وهذه -- هذه الفجوة، هي ما يكلفك إياه
00:09:47اختيار 512 أو 1000 أو أياً كان، أليس كذلك؟ هذا الرقم هو مجرد رقم تعسفي. هذا هو الثمن الذي تدفعه. وأعتقد أن
00:09:56المشكلة هنا هي -- أنها معقدة بعض الشيء لأنها تشبه مشكلة معلوماتية حيث لا تتوفر لدينا
00:10:07المعلومات التي نحتاجها في كل مرحلة. وماذا أعني بذلك؟ إذا كنت أنظر إلى جزء الفهرسة،
00:10:12حيث أمتلك سيطرة على حجم التجزئة، فأنا لا أعرف ما ستكون عليه الاستعلامات.
00:10:18يمكنني التخمين. ويمكنني ربما التقدير. ويمكنني المحاولة. لكني لا أعرف ما ستكون عليه الاستعلامات، لذلك لا يمكنني
00:10:25ضبط حجم التجزئة الخاص بي وفقاً لذلك. وفي جزء الاسترجاع، حيث تتوفر لدي استعلاماتي،
00:10:31لا يمكنني التحكم في حجم التجزئة، أليس كذلك؟ إنه ثابت بالفعل. ومن الواضح أنني لن أُجري العملية بأكملها
00:10:37لكل استعلام من البداية. لذلك نظرنا في الأعمال السابقة، وعلى الأخص الأعمال الانتروبية،
00:10:47والاسترجاع السياقي (contextual retrieval)، حيث يقومون بإثراء كل جزء، وغيرها من الأساليب التي تحاول في الأساس تحسين الفضاء الكامن
00:10:54لكل جزء. ولكن هذا لم يكن الاتجاه الذي سلكناه. لقد بقيت كل تلك الأعمال ضمن نموذج
00:11:01العمل بحجم تجزئة ثابت، بينما اتخذنا نحن نهجاً مختلفاً. وقلنا، لماذا نلتزم
00:11:08بحجم واحد بينما يمكننا الالتزام بعدة أحجام؟ ونسمي ذلك الفهرسة متعددة المقاييس (multi-scale indexing). في الأساس، نحن نفعل فقط
00:11:16ما رأيناه من قبل. إذن نحن نأخذ قاعدة البيانات. ونقوم بمضاعفتها وتجزئتها بعدة
00:11:26أحجام تجزئة أو أحجام نوافذ (window sizes). وبعد ذلك، هذا ما يحدث في الفهرسة. ثم في وقت الاسترجاع،
00:11:34نحن نقوم بالاستعلام منها جميعاً. إذن إذا كان لدينا n نسخة مكررة من قاعدة البيانات وأحجام النوافذ، فيتعين علينا الآن تشغيل
00:11:43ستة استدعاءات استرجاع مختلفة لكل استعلام. عذراً، ستة باعتبارها n. وكيف نقوم بدمجها؟ من الواضح أننا لا نستطيع
00:11:52استخدام العراف، أليس كذلك؟ العراف هو شيء نمتلكه فقط للإمكانات. في الواقع الحقيقي،
00:11:57نحن لا نعرف الإجابة. ولكن ما يمكننا فعله هو إيجاد نوع من خوارزمية الدمج. والآن، قد تقولون،
00:12:06عندما ننظر إلى الأمر بهذه الطريقة، ما هي المشكلة المحتملة؟ حقيقة أن لدينا n من الترتيبات،
00:12:13ولكن هذه الترتيبات مخصصة للجزئيات. والجزئيات ذات الأحجام المختلفة ليست قابلة للمقارنة حقاً،
00:12:19أليس كذلك؟ لذلك اخترنا بدلاً من ذلك أن نفعل شيئاً شائعاً جداً هذه الأيام. والكثير من
00:12:25أنظمة RAG تعمل في الواقع هكذا، بحيث بدلاً من استرجاع المقطع فقط، عندما نحصل على
00:12:30مقطع، فإننا نسترجع المستند بأكمله، أليس كذلك؟ عندما تزيد نافذة السياق، نريد تقديم المزيد والمزيد
00:12:35من السياق. والآن، في هذه الحالة، لدينا (n) من الترتيبات للمستندات نفسها، لأنها
00:12:44لم تعد مقاطع. وهذا يمكننا مقارنته. وفي هذه الحالة، يمكنك التفكير في الاسترجاع على أنه أساساً
00:12:50مجرد تصويت. أليس كذلك؟ لذا فهو ليس ترتيباً بحتاً. ليس لدينا ترتيب واحد ثم نقوم
00:12:56بإعادة ترتيبه. بل لدينا (n) من الترتيبات المختلفة للمستندات ذات الصلة، ونريد دمجها
00:13:03جميعاً في ترتيب واحد. ولهذا السبب نستخدم شيئاً يسمى RRF، أو دمج الرتب المتبادلة، وهي صيغة
00:13:11بسيطة إلى حد ما. لقد جربنا عدة أشياء، وكانت هذه هي الأفضل. وكما ترون، فهي ليست نموذجاً،
00:13:17 وليست شيئاً يتطلب منك القيام به بشكل محدد. وعلى وجه الخصوص، هذا مجرد
00:13:23سكريبت بسيط لا يستغرق أي وقت حقاً. وهكذا يبدو النظام الكامل. إذن لدينا عملية
00:13:32الفهرسة (n) من المرات، ثم نُجري الاستعلام لكل استعلام من كل قاعدة بيانات، ونستخدم RRF لدمجها جميعاً.
00:13:40ويمكنك تخمين أن النتائج جيدة، وإلا لما كنت واقفاً هنا
00:13:48وأنا واثق أكثر من اللازم. أليس كذلك؟ ولكن كما ترون، لقد اختبرناها عبر عدة مجموعات بيانات، مثل QMSum،
00:13:56وNarrative QA، وSeinfeld، وأيضاً Finance Bench. لقد أخذناها كلها، وهي تتفوق على الحجم الثابت لدينا
00:14:05بأفضل شكل. دعونا نرى ذلك في الرسم البياني. يصعب رؤيته قليلاً هنا، لذا سأستعرضه ببطء. كل صف
00:14:12هنا يمثل حجم المقطع. لذا يمكنك رؤية 50، 100، وهكذا. الصف السفلي هو طريقتنا. هذا الصف،
00:14:21الذي تقوم به من الكل ثم تدمجه. وكل عمود يمثل معدل الاستدعاء (Recall) عند حد معين. مثل الاستدعاء عند 1،
00:14:312، 3، حتى 10. ما يمكنك رؤيته هنا هو أمران، أليس كذلك؟ أولاً، أنه عبر
00:14:39مستويات الاستدعاء المختلفة، لا تزال طريقتنا تفوز، وهو أمر قد تبدو خوارزميته بسيطة، لكن حقيقة
00:14:46أنك مضطر لدمج كل هذه النتائج ليست أمراً بالغ السهولة. ويمكنك أيضاً أن ترى أن الجودة
00:14:53تزداد في الواقع. خريطة التمثيل اللوني (Heat map) تصبح أكثر اخضراراً. ومرة أخرى، كان هذا مجرد
00:14:58شيء أريد عرضه على نطاق واسع. وهنا يمكنك رؤية مجموعات البيانات الأربع كلها حيث نحقق
00:15:06نتائج أفضل. بنسبة 20، 30، 40 بالمائة تقريباً في الكثير من الحالات. وأيضاً، هناك نتائج
00:15:14لم أعرضها هنا وهي موجودة على MTab. يمكنك رؤيتها في مدونتنا، سأضع الرابط لاحقاً، فنحن نحقق
00:15:22هناك أيضاً الكثير من التحسينات تتراوح بين 10 إلى 40 بالمائة اعتماداً على مجموعة البيانات.
00:15:30الآن، لستُ ساذجاً. ولن أدعي هنا أن هذا بلا ثمن. من الواضح أن هناك تكلفة،
00:15:36أليس كذلك؟ لا توجد وجبات غداء مجانية. كل شيء يأتي بثمن ما. ونعم، يكلفنا ذلك ذاكرة إضافية.
00:15:43إنه يكلف ما بين 2 إلى 5 أضعاف، أي ثابت من الذاكرة الإضافية حيث يتعين عليك الاحتفاظ
00:15:51بكل تلك النسخ من قاعدة البيانات. ومع ذلك، إذا فكرت في الأمر من ناحية زمن الاستجابة (Latency)، فهو لا
00:15:59يؤثر حقاً على ذلك لأنه يمكنك إجراء عملية الاسترجاع بالكامل بالتوازي. وأيضاً، جزء RRF لا يستغرق وقتاً طويلاً حقاً.
00:16:10أود القول إن هذا كان مشروع بحث رائعاً جداً قمنا به وحصلنا على نتائج رائعة حقاً.
00:16:16هناك أشياء يمكن القيام بها، أليس كذلك؟ هناك جوانب للتحسين وهناك عمل مستقبل يتعين القيام به. وبشكل أكثر تحديداً،
00:16:23نريد أن نفهم عدد أحجام المقاطع التي نريدها وأيها، أليس كذلك؟ حقيقة أننا عملنا بـ 50، 100،
00:16:32200، وما إلى ذلك، كانت عشوائية تماماً، لكي أكون صادقاً. لذا نحتاج حقاً إلى معرفة كيف نحسب ذلك
00:16:40وكيف نعرف عدد النسخ التي تحتاجها بالضبط. وأيضاً، تجاوز استخدام RRF، أليس كذلك؟ حقيقة أننا
00:16:46نستخدم RRF ترجع إلى أنه كان الأفضل بين الطرق التي استخدمناها، لكن هذا لا يعني أنه لا توجد
00:16:52طريقة أفضل. وإذا كان لي أن أترككم برسالة أودعكم بها، فأود القول إن الوكلاء (Agents) لم يقضوا على
00:16:59الاسترجاع. لم يمت أي شيء، هيا! إنها مجرد بنية تحتية. والجزء السيئ هو أنها
00:17:07بنية تحتية تعود لعام 2022. وبطرق بسيطة حقاً، يمكنك الارتقاء بنظام RAG الخاص بك أو أي نظام يتعلق
00:17:17بتخزين البيانات ثم استرجاعها بنسبة تحسن تتراوح بين 20 إلى 40 بالمائة، ودون الحاجة لأي شيء معقد للغاية.
00:17:26لذا إذا كنت تريد القراءة أكثر عن هذا الموضوع، يمكنك قراءة المدونة. وهناك أيضاً مثال
00:17:34للشيفرة البرمجية هناك ومجموعة بيانات Seinfeld. هذا كل ما في الأمر. أنا يوفال. شكراً جزيلاً لحضوركم.
00:17:47أراكم في المرة القادمة.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기