المشروع النهائي لدورة استرجاع المعلومات CS 582 في جامعة إلينوي في شيكاغو
لتشغيل البرنامج من Terminal فقط استخدم الأمر:
Python Main.py
يتم تقديم تقرير لشرح وظائف وواجهة المستخدم الخاصة بمحرك البحث بشكل أفضل ، يرجى الرجوع إلى:
Report.pdf
هذه الوثيقة هي تقرير للمشروع النهائي لاسترجاع المعلومات CS 582 في جامعة إلينوي في شيكاغو. يتألف المشروع في بناء محرك بحث على شبكة الإنترنت لنطاق UIC من نقطة الصفر. تم تصميم البرنامج بشكل معياري ، بدءًا من تزحف الويب ، وتجاوز المعالجة المسبقة للصفحات وفهرسته وأخيراً إضافة واجهة مستخدم رسومية. علاوة على ذلك ، كان مكونًا "ذكيًا" مخصصًا اخترعهنا أمرًا ضروريًا.
قررت أن أجرب في تحسين محرك البحث باستخدام توسيع الاستعلام استنادًا إلى نهج التغذية المرتدة ذات الصلة الزائفة التي تحاول الحصول على سياق واسع من استعلام المستخدم ، أطلق عليها اسم سياق التعليقات Pseudo-Relevance ( CPRF ). يجب أن يكون هذا قد أضاف بشكل أساسي نوعين من التحسينات على محرك البحث:
لا تركز جميع النتائج فقط على الكلمات الموجودة في الاستعلام ولكن بما في ذلك المحتوى المتنوع والمحتوى المرتبط بمجموعة الصفحات التي تم استردادها.
توسيع إجمالي عدد النتائج ، بما في ذلك صفحات الويب التي لا تحتوي على أي من الكلمات الموجودة في الاستعلام ولكن لا يزال من المهم للمستخدم منذ تعامل مع نفس الموضوع.
يتم دمج تطبيق تصنيف الصفحة أيضًا ويمكن تشغيله أو إيقاف تشغيله من واجهة المستخدم. يمكن العثور على مزيد من التفاصيل حول كل من المكونات الذكية لاحقًا في هذا المستند.
يمكن الوصول إلى المستودع الذي يحتوي على البرنامج من خلال github على:
https://github.com/mirkomantovani/web-search-engine-uic
يتم كتابة البرنامج في Python3 بطريقة برمجة موجهة نحو الكائن لجعلها قابلة للتمديد بسهولة في المستقبل. من أجل تسهيل تنزيل الكود واختباره دون الحاجة إلى إجراء الزحف والمعالجة المسبقة للصفحات واسعة النطاق والمستهلكة للوقت ، فإن مجموعة البيانات التي تحتوي على 10000 صفحة تم الزحف من مجال UIC: https://www.uic.edu/ ، و Documents pages و tok ، يتم تضمين عناوين URL) في المستودع. وبهذه الطريقة من خلال استنساخ المستودع ، يمكن تشغيل Main.py وفي أقل من ثانية ، يكون محرك البحث جاهزًا للحصول على استعلامات في الإدخال. ومع ذلك ، يتم تضمين البرامج النصية لتشغيل الزحف والمعالجة المسبقة وشرحها في الأقسام الفرعية التالية مع جميع المكونات الأخرى.
يمكن إجراء تزحف الويب عن طريق تنفيذ البرنامج النصي multitherded_crawling.py ، يحدث الزحف بالتوازي مع استخدام وحدة قائمة الانتظار للوصول إلى الموارد بطريقة متزامنة ، يمكن تغيير عدد المواضيع عن طريق تعديل Thread_number العالمي في نفس البرنامج النصي ، وهو ما يتأخر عن السداد ، ومع ذلك ، فإن الفقرة الرئيسية في الزحيل في حالة تنزيلها.
يبدأ الزحف من نطاق UIC CS الفرعي: https://www.cs.uic.edu/ المحدد في البرنامج النصي multiTherded_crawling.py .
يحدث الزحف باستراتيجية اتساع ، كل صفحة يتم إلغاؤها وتنزيلها وتحليلها باستخدام مكتبة HTMLParser ، يتم استخراج روابطها وفحصها للانتماء إلى مجال UIC ، ثم تمت إضافتها إلى قائمة انتظار FIFO إذا كانت بتنسيق مناسب. تم اشتقاق قائمة سوداء من جميع التنسيقات السيئة من قبلي أثناء رؤية النتائج التي كنت أحصل عليها في الزحف وتتألف في هذه الأشكال الـ 18: ".tgz" ، ".zip" ، ".exe" ، ".js" ، ".css" ، ".ppt". يتم تحديد مهلة 10 ثوانٍ كحد أقصى لتنزيل صفحة قبل إغلاق الاتصال والانتقال إلى الصفحة التالية.
يتم تعديل عناوين URL أيضًا بعد استخلاصها ، ويصبح كل HTTP أولي HTTPs ، يتم القضاء على كل ما تم القطع في النهاية ، وتتم إزالة سلاسل الاستعلام وأيضًا الروابط داخل الصفحة التي يتم التعبير عنها بواسطة رمز التجزئة (#) أيضًا من أجل السماح للتجول بالاعتقاد بأن المزيد من الصلاحات ذات الصلاحات المختلفة ، يتم إزالتها مختلفة. علاوة على ذلك ، فإن التعامل مع الروابط حيث يتم فتح علامة <a> ويتم فتح علامة أخرى في الداخل قبل إغلاق HREF عن طريق تقسيم الرابط على فتح علامة أخرى "<" في السلسلة.
أثناء الزحف ، يتم حفظ اثنين من القواميس ، عنوان URL من الكود والرمز من عنوان URL باستمرار إلى القرص لاستخدامه لاحقًا ، رمز صفحة الويب هو رقم الصفحة التي تم تنزيلها بالترتيب الزمني.
يمكن تنفيذ المعالجة المسبقة للصفحات المزروعة من البرنامج النصي Run_preprocessing.py ، ويمكنك أيضًا تحديد عدد الصفحات التي يجب مراعاتها والحد الأقصى لعدد تكرارات تصنيف الصفحة عن طريق تغيير الثوابت المقابلة Page_Rank_Max_iter و N_Pages.
أثناء المعالجة المسبقة ، يتم استخدام كائن مخصص من النصي preprocess.py . يتم معالجة كل صفحة مسبقًا عن طريق الحصول على النص العادي في جميع العلامات باستثناء <script> و <style>. في هذه الخطوة ، قررت استخدام مكتبة سريعة للغاية: SelectOlax ، وهي واجهة برمجة تطبيقات Python لاستخدام المحرك المتواضع المكتوب في C. cpython سيوفر بالطبع ترتيبًا واحدًا على الأقل من حيث الحجم أقل في الوقت الحسابي فيما يتعلق بأي أسماك HTML مكتوبة في Python النقي. بعد ذلك ، يتم رمز الصفحة ، ويتم تنبؤ الرموز باستخدام PorterStemmer بواسطة NLTK ، ويتم التخلص من الكلمات المتوقفة باستخدام قائمة الكلمات الموقف المتوفرة في ملف File Stopwords.txt ، وتتم إزالة الأرقام والكلمات أقصر من 3 أحرف لا يتم النظر فيها.
في المعالجة المسبقة ، تم تصميم الفهرس المقلوب ويتم حساب TF-IDF لكل زوج-doc Word وتخزينه في الفهرس المقلوب. يتم أيضًا إنشاء رسم بياني ويب موجه ( Graph.py ) ويتغذى على تنفيذ تصنيف الصفحة في page_rank.py . ثم يتم حفظ جميع الملفات اللازمة لاحقًا للرد على الاستعلام كملفات ثنائية.
كان إجمالي الوقت المستغرق للمعالجة المسبقة والتقارب Page_rank لـ 10000 صفحة حوالي 236 ثانية ، وكان وقت تشغيل تصنيف الصفحة حوالي 11 ثانية فقط.
يحتوي البرنامج النصي الرئيسي على نقطة الوصول إلى محرك البحث. عند بدء تشغيل البرنامج ، يتم إنشاء كائن مخصص لـ ThankTokenizer لرمز الاستعلامات ، يتم إنشاء كائن tfidfranker بدلاً من ذلك من أجل تصنيف المستندات بناءً على الاستعلامات.
عندما يتم تصنيف المستندات استنادًا إلى استعلام المستخدم ، يتم النظر في 100 مستندات بحد أقصى ، يمكن تغيير هذا الثابت في Main.py : max_results_to_consider ، معلمات أخرى قابلة للتخصيص هي عدد النتائج التي يجب عرضها في وقت واحد النتائج _per_page ، وعدد الصفحات لاستخدامه: n_pages.
واجهة المستخدم رسومية وتنفيذها باستخدام حزمة Python: EasyGui. واجهة المستخدم الرسومية هي وحدة قابلة للتمديد ، CustomGui.py التي تحتوي على واجهات برمجة التطبيقات الرئيسية للوظائف الأساسية للبرنامج.
عندما يبدأ البرنامج ، يتم سؤال المستخدم عن الإعدادات الأساسية ، سواء كان يريد استخدام تصنيف الصفحة والسياق التعليقات ذات الصلة الزائفة أم لا. بعد ذلك تظهر القائمة الرئيسية. تعرض القائمة الرئيسية الإعدادات الحالية لمحرك البحث وبعض الأزرار للإجراءات الرئيسية التي يمكن تنفيذها. يمكن تغيير الإعدادات ديناميكيًا في وقت التشغيل عن طريق اختيار الزر المناسب من القائمة الرئيسية. الخياران الآخران هما: ترك البرنامج وتشغيل استعلام. إذا ضغط المستخدم على الزر لإنشاء استعلام جديد ، يظهر نافذة جديدة ، ويتم مطالب المستخدم بإدخال استعلام جديد. عندما ينقر على ما يرام ، يتم معالجة الاستعلام مسبقًا ، ويتم تصنيف المستندات ، ويتم عرض المستندات العشرة الأولى (المتغير في البرنامج) مع المعلومات المتعلقة بالاستعلام المسبق وربما الرموز الموسعة إذا كانت ردود الفعل الزائفة على الإطلاق قيد التشغيل. يمكن للمستخدم الآن النقر المزدوج على نتيجة لفتح الصفحة في علامة تبويب جديدة على المتصفح الافتراضي لنظامه أو يمكنه الضغط بشكل متكرر على "إظهار المزيد من النتائج" في نهاية القائمة لإظهار 10 نتائج أخرى. علاوة على ذلك ، إذا كانت ردود الفعل ذات الصلة الزائفة مطفأة ، يتم منح المستخدم أيضًا إمكانية إعادة تشغيل الاستعلام نفسه مع التوسع.
بعد تشغيل استعلام وقررت إلغاء أو فتح نتيجة ، تتم مطالب المستخدم بالعودة إلى القائمة الرئيسية حيث يمكنه تغيير الإعداد و/أو تشغيل استعلام جديد أو نفس الاستعلام مع إعدادات مختلفة لمقارنة النتائج مع تم الحصول عليها مسبقًا.
التحديات الرئيسية التي واجهتها خلال تطوير هذا المشروع هي:
في البداية كان من الصعب حقًا اختيار نوع المكون الذكي الذي يجب تصميمه. ليس لدي أي خبرة في هذا النوع من التطبيقات على الإطلاق والتفكير في التحسينات دون وجود عرض تجريبي لاختباره أمر صعب للغاية.
خلال جزء التنفيذ ، قضيت الكثير من الوقت في التعرف على مكتبات Python والبنيات التي لم أكن أعرفها بعد ، مثل مؤشرات الترابط ، كيفية تنفيذ أو القيام بتجريف الويب للحصول على الروابط من صفحة HTML. شيء آخر كان علي أن أتعلمه من نقطة الصفر هو كيفية إنشاء واجهة المستخدم الرسومية في بيثون.
كان الشيء المزعج هو حقيقة أنني اضطررت إلى زحف 10000 صفحة أكثر من مرة ، لأنني وجدت في الصفحات التنسيقات المختلفة والخاطئة. في النهاية ، كان حجم القائمة الكاملة للتنسيقات التي اضطررت إلى القائمة السوداء بحجم 18 ، وشملت ".docx" ، ".doc" ، ".avi" ، ".mp4" ، ".jpg" ، ".jpeg" ، ". ".exe" ، ".js" ، ".css" ، ".ppt".
كان الأمر صعبًا للغاية هو ضبط المفرطات المفرطة وتكامل تصنيف الصفحة لتصنيف المستندات. المعلمة " E " لتحديد مقدار الأهمية التي يجب إعطاؤها لرموز الاستعلام الموسع هي الأكثر صعوبة في ضبطها لأنه لا يمكنك معرفة متوسط العروض لمحرك البحث إذا لم يكن لديك بيانات وصفها (المستندات ذات الصلة لكل استعلام). أيضًا ، تعتبر أهمية الاستعلام ذاتية ، ولا تعرف أبدًا ما يريد الشخص استرداده ، ولا يمكنك التخمين إلا بناءً على الاستعلام. قررت أن تكون E على الأقل 0.5 وفي النهاية قمت بتعيينها حوالي 0.1-0.2 ، فأنت لا تريد تحيز الاستعلام كثيرًا من خلال إعطاء الكثير من الأهمية للكلمات التي لا يكتبها المستخدم.
كان مخطط الترجيح الذي استخدمته هو TF-IDF البسيط للكلمات في المستندات لأنه ثبت أنه أحد أكثرها فعالية عندما يتعلق الأمر بمحركات البحث على الويب ويحسب أهمية الكلمات في كل وثيقة بالطريقة الصحيحة. لم أفكر حتى في تجربة إجراء آخر لمجرد أنه لم يكن الغرض من هذا المشروع ، ويبدو أن هذا يعمل بشكل جيد.
كان مقياس التشابه المستخدم في ترتيب المستندات هو تشابه جيب التمام . لقد قمت بتنفيذ بدء تشابه المنتج الداخلي والتحول إلى ذلك سيكون مجرد تغيير سطر واحد من التعليمات البرمجية. أعتقد أن تشابه جيب التمام هو أفضل لاستخدامه لأنه يأخذ في الاعتبار طول المستند وطول الاستعلام. إنه أكثر تعقيدًا ، وعادةً ما يعمل بشكل جيد في الممارسة العملية في هذا النوع من التطبيقات ، لذا فإن اختيار مقياس التشابه لم يكن مشكلة حقًا ، فقد عرفت فقط أن تشابه جيب التمام كان الصحيح.
قمت بتقييم للدقة عند 10 (فقط مع الأخذ في الاعتبار النتائج العشرة الأولى التي تم استردادها) لبعض الاستعلامات العشوائية والمتنوعة التي توصلت إليها. ها هي النتائج:
الاستعلام: "أطروحة المستشار" ، وكانت النتيجة الأولى https://grad.uic.edu/electronic-thesisdissertation-faqs وأعتقد أن جميع النتائج كانت مرتبطة بالأطروحة والأشياء المرتبطة ، وسأعطي دقة: p = 1.0 لهذا الاستعلام.
الاستعلام: "المعارض الوظيفية" ، كانت النتيجة الأولى https://ecc.uic.edu/career-fairs وأعتقد أن جميع النتائج كانت ذات صلة إلى حد ما بالمعارض الوظيفية والخدمات الوظيفية والأحداث والتوظيف ، وسأعطي دقة: P = 1.0 لهذا الاستعلام.
الاستعلام: "مساعد البحث" ، كانت النتيجة الأولى هي http://grad.uic.edu/assistantships وأعتقد أن كل شيء باستثناء آخر ما كان مرتبطًا بالمساعدين ، كونه RA ، TA أو GA ، لمجرد أن مجال UIC لا يحتوي على صفحة محددة لـ RA ، لذلك سأقدم دقة: P = 0.9 إلى هذا الفتحة.
الاستعلام: "التدريب الداخلي والوظائف" ، كانت النتيجة الأولى https://careerservices.uic.edu/students/internships وهذه المرة كانت فقط 6 صفحات ويب كانت ذات صلة ، ومع ذلك ، فإن تلك التي لم تكن مرتبطة بالمهنة والتوظيف. سأعطي دقة: ع = 0.6 لهذا الاستعلام.
الاستعلام: "عنوان مركز الطالب الشرقي" ، كانت النتيجة الأولى https://fimweb.fim.uic.edu/buildingsdata.aspx ، هذا الاستعلام أكثر تحديداً وتعقيدًا ، وفي الواقع من 4 نتائج ، نحن قادرون بالفعل على استخراج عنوان المبنى ، ومع ذلك ، كانت جميع النتائج الأخرى تتحدث عن الشرق ، وهو ما لا يزال سيئًا. سأعطي دقة: ع = 0.4 لهذا الاستعلام.
مع متوسط دقة 0.78 ، وحقيقة أن كل استعلام أعاد نتيجة واحدة على الأقل ذات صلة ، أعتقد أن النتائج منفصلة.
أول ذكاء جربته كان رتبة صفحة بسيطة وبسيطة. أثناء المعالجة المسبقة للصفحات ، يتم استخراج الروابط واستنادا إلى اتصالات الارتباط يتم إنشاء رسم بياني عالمي. كان تنفيذ تصنيف الصفحة لدرجة أنه أنشأ عنصرًا متصلًا بقوة مع الرسم البياني بأكمله ، مما يعني أنه من كل عقدة ، من الممكن الوصول إلى عقدة أخرى من الرسم البياني مع احتمال غير فائق. مع هذا التفسير ، لا يوجد أي احتمال أن تتعثر مشاة عشوائية في صفحة.
كان من الصعب بعض الشيء الاندماج في صفوف الصفحة في تسجيل المستندات لتصنيفها. في البداية ، حاولت فقط القيام بمزيج خطي من تشابه جيب التمام وتصنيف الصفحات وأرى كيف كان يعمل وكان الأمر سيئًا للغاية لأنه إذا كان وزن تصنيف الصفحة أكثر من اللازم من الصفحة الرئيسية وستظهر الصفحات الموثوقة الأخرى دائمًا في النتائج. بدلاً من ذلك ، إذا كان الوزن يميل أكثر نحو تشابه جيب التمام ، فلن يكون لتصنيف الصفحة أي تأثير على الإطلاق.
أنتجت المحاولة الثانية نتائج جيدة. لقد أخذت للتو أول 100 نتيجة فقط باستخدام وتجاهل كلهم الآخرون واعتبروهم غير ذويين. ثم فعلت الجمع الخطي مع تصنيف الصفحة. هذه المرة نجحت لأنها كانت مجرد تقليد مختلف للوثائق ذات الصلة بالفعل ، وعلى سبيل المثال ، تم بالفعل تجاهل الصفحة الرئيسية وغيرها من المستندات الموثوقة في هذه المرحلة.
أعتقد أن الغرض من تصنيف الصفحة في هذا النوع من التطبيقات قد تم تحقيقه ، تمكنت من التحيز في البحث العادي للنظر في صفحات أكثر ملاءمة أكثر موثوقية بحيث يكون المستخدم أكثر عرضة للعثور على مصادر معلومات جيدة وموثوقة بالإضافة إلى النتائج التي تشبه إلى حد كبير ما يكتبه في استعلامه.
سياق التعليقات ذات الصلة الزائفة ( CPRF ) توصلت إلى هذه الفكرة عن مبدأ ومكون ذكي مخصص بعد شهر تقريبًا من التنفيذ الفعلي. عندما كنت أقوم بالتنفيذ ، لم أكن متأكدًا من أنه كان سيعمل كما هو متوقع ، وكنت خائفًا حقًا من أنني كنت أفعل كل ذلك مقابل لا شيء.
عندما كنت أفكر في نوع المكون الذكي الذي يمكن أن يكون عليه محرك البحث على شبكة الإنترنت ، اعتقدت أنه سيكون من الرائع أن نتمكن من تخمين سياق استعلام المستخدم ومنحه بالإضافة إلى ما يطلبه على وجه التحديد ، بعض النتائج المرتبطة جدًا بما بحث عنه. كان توسيع الاستعلام الثابت البسيط استنادًا إلى المرادفات بسيطًا للغاية ولم يكن قادرًا على التقاط المحتويات ذات الصلة ولكن لها دلالة مختلفة.
ومع ذلك ، يجب أن تكون نقطة البداية دائمًا استفسار المستخدم ، حيث لا يوجد شيء آخر إلا في البداية. لقد أحببت حقًا فكرة كيف تمكنت ردود الفعل ذات الصلة الزائفة من السماح لك بإعادة صياغة استعلامك بطريقة مستقلة. بالطبع ، من المحتمل أن تكون التعليقات الصريحة ذات الصلة عندما يُسأل المستخدم الكلمات الأخرى التي يرغب في إدراجها في استعلامه ، ولكن في الوقت نفسه قد يكون من المزعج له الاضطرار إلى الرد على بعض الأسئلة أثناء البحث. يبدو أن ردود الفعل ذات الصلة الزائفة وسيلة أكثر ملاءمة وسهلة لتشغيلها في الخلفية بعض الاستعلام الأكثر تعقيدًا لا يدركه المستخدم.
لاستخراج بعض الكلمات التي يمكن أن تعبر عن سياق الاستعلام المصمم ، قررت استخدام بعض المعلومات الجوهرية التي لدى المستندات التي تم استردادها في البداية. على وجه الخصوص ، أعتقد أن الكلمات ذات أعلى TF-IDF في وثيقة يمكن أن تمثل موضوع هذا المستند ، وما الذي يميزه عن الآخرين ، لأن TF-IDF مرتفع عندما لا تكون الكلمة موجودة في العديد من المستندات ولكنها متكررة في هذا المستند.
العملية لاستخراج كلمات السياق هي ما يلي: من المستندات المرتبة التي أخذت مستندات number_docs_expansion ، والتي قمت بتعيينها على 30 ولكن يمكن تغييرها في pseudo_relevance_feedback.py. ، بالنسبة لكل مستند ، آخذ الرموز التي تحتوي على أعلى TF-IDF (رقم ثابت _top_tokens) ولكل رمز مميز فيها ، ألخص كل TF-IDF لهذه الكلمة من كل مستند في حالة وجود الكلمة. في النهاية ، أحتل الرموز الرموز والكلمات المرتبة الأولى هي الكلمات المشتركة لكل وثيقة تم استردادها تمثل سياق الاستعلام. ثم أعيد مجموعة الكلمات الموسعة (number number_expansion_tokens) ، والتي يتم طرح الرموز المميزة للاستعلام الأصلية حتى لا يكون لها تكرار وإعطاء أهمية كبيرة لتلك الكلمات.
سيتم منح الرموز الموسعة وزنًا اختلافًا ، أقل من الكلمات الأصلية في الاستعلام ، يمكن تغيير هذا E_Const في البرنامج النصي Statistics.py .
استنادًا إلى الاستعلامات التي حاولت أن يعتقد أن المكون الذكي يعطي حقًا بعض التحسينات في بعض الحالات.
النتائج الكبيرة الأولى التي تعمل دائمًا هي القدرة على توسيع مجموعات المستندات التي تم استردادها ، في الواقع ، إذا كانت هناك عدد قليل فقط من المستندات تحتوي على أي من الكلمة في الاستعلام ، فإن محرك البحث العادي سيسترجع تلك المستندات القليلة فقط. بدلاً من ذلك ، مع المكون الذكي CPRF ، ستكون مجموعات النتائج أكبر بكثير ويمكن أن تؤدي دائمًا إلى مجموعة مستردة بحجمها أكثر من 100 وثيقة.
والنتيجة الإيجابية الأخرى التي لاحظتها في بعض الاستعلامات هي أنها تجد بالفعل ما كنت أبحث عنه كنتيجة أولى في حين أن محرك البحث البسيط لا يجده حتى في أفضل عشر نتائج. مثال على ذلك يمكن ملاحظة ذلك من خلال البحث في "دورات علوم الكمبيوتر" ، ما أردت العثور عليه هو قائمة بجميع الدورات الرئيسية التي تقدمها قسم علوم الكمبيوتر في UIC. هذه هي النتيجة الأولى التي يتم استردادها بواسطة المحرك عندما يكون المكون الذكي نشطًا. بدلاً من ذلك ، دون تفعيلها ، فإن هذه الصفحة ليست في النتائج الأولى.
أخيرًا ، حاولت البحث عن "استرجاع المعلومات" ، وكان محرك البحث بدون CPRF سيئًا للغاية ، والنتيجة الأولى هي صفحة بحث عن أقسام UIC ، وربما يكون ذلك أيضًا أنه لا توجد صفحة لاسترجاع المعلومات في مجال UIC أو لم يتم تضمينها في المجال. ومع ذلك ، مع وجود المكون الذكي ، تم العثور على العديد من صفحات الويب المتعلقة بذلك ، وهما من الكلمات الممتدة "كورنيليا كاراجيا" ، الأستاذة التي تدرس هذه الدورة ، كانت العديد من الصفحات مرتبطة بالفعل بمنشوراتها وعملها في استرجاع المعلومات ، وهذا أيضًا خاصية جيدة جدًا لمحرك البحث. في حالة عدم وجود نتائج ذات صلة للغاية ، لا يزال قادرًا على العثور على أفضل النتائج الممكنة حول الأشياء ذات الصلة.
كما هو موضح في 5.3 عندما قمت بالمقارنة بين محرك البحث العادي واستخدام المكون الذكي ، أعتقد أن النتائج المنتجة كانت جيدة جدًا وحصلت على ما كان متوقعًا عندما كنت أفكر في هذا. كانت الأشياء الجيدة الملخصة التي لاحظتها عن طريق اختبارها هي:
القدرة على العثور على العديد من النتائج حتى عندما يخرج الاستعلام الأصلي مجموعة من المواقع الإلكترونية فقط.
على سبيل المثال ، فإن قدرة إيجاد ما كنت أبحث عنه بالفعل كنتائج أولى ، على سبيل المثال في "دورات علوم الكمبيوتر" ، كما أوضحت في الفقرة 5.3.
خاصية لطيفة للغاية لاسترداد المحتوى المنفصل حتى عندما لا تحتوي المجموعة على صفحات ذات صلة كبيرة بالاستعلام وربما ما يبحث عنه المستخدم ، لاحظت ذلك عن "استرجاع المعلومات" كما هو موضح في الفقرة 5.3.
إحدى الطرق التي أوضحت لي أن هذا كان ينتج عن النتائج الصحيحة هي حقيقة أنه في أفضل 10 كلمات متوسعة تمثل السياق ، كانت بعض الكلمات التي تنتمي إلى استعلام المستخدم موجودة. يوضح هذا كيف أن الطريقة قادرة بشكل فعال على التقاط الموضوع ولا توجد طريقة أخرى لوصف الكلمات الأخرى في تلك المجموعة إن لم يكن مثل الكلمات التي تنتمي إلى نفس سياق تلك الموجودة في الاستعلام الأصلي.
الحديث عن تصنيف الصفحة بدلا من ذلك. أعتقد أنها تؤدي وظيفتها ، لكنها لا تغير التصنيفات كثيرًا بالطريقة التي قمت بتطبيقها ، إنها مجرد وسيلة لتحيز النتائج لتفضيل المزيد من الصفحات الموثوقة إذا كان هناك أي شيء.
من المؤكد أن أحد الأشياء التي يجب معالجتها من هنا هو ضبط المتقاطعات. إنه أصعب شيء يجب القيام به بشكل أساسي بسبب نقص البيانات المسمى. لا يمكنني معرفة قيمة المعلمة التي تعمل بشكل أفضل إذا لم أتمكن من تقييم دقة الاستعلامات ، ومن أجل ضبطها تلقائيًا ، يجب أن يكون هناك الكثير من البيانات المسمى بالفعل.