خدمة البحث: الدليل التشغيلي للاسترجاع¶

1. المهمة والنطاق¶

تتمثل مهمة خدمة البحث في توفير تجربة بحث سريعة، قابلة للتوسع، وذات صلة عالية لجميع البيانات في منصة لبيب.

صُممت الخدمة لتكون مخزن بيانات قوي ومرن، ومُحسَّنًا للاستعلامات المعقدة التي تتطلبها خدمة الذكاء (AI-Box). تجمع الخدمة بين البحث النصي التقليدي (BM25) والبحث الدلالي الحديث القائم على المتجهات (k-NN) لتقديم نتائج متطورة.

مخطط المكونات¶

flowchart LR
  API-->OS[(OpenSearch)]
  API-->AI[AI-Box]
  subgraph OpenSearch
    Q[مسار معالجة الاستعلامات]-->C[أدوات التجميع BM25,kNN]
    C-->RRF[أداة دمج النتائج RRF]
  end

تدفقات البيانات¶

• الاستعلام: API ← مسار OpenSearch (BM25 + kNN) ← إعادة ترتيب اختيارية عبر AI-Box.
• الجلب: API (من Scraper) ← OpenSearch (قوالب الفهارس، المحللات).

2. مسؤوليات الخدمة وتفاعلاتها¶

يحدد هذا الجدول دور خدمة البحث واعتمادياتها الحيوية داخل منظومة منصة لبيب.

نظرة عامة¶

استرجاع وتصنيف البيانات لمنصة لبيب: بحث هجين يجمع بين BM25 و kNN مع مُعيد ترتيب اختياري، بالإضافة إلى محللات للغتين العربية والإنجليزية وفهارس مُدارة بالإصدارات.

الموقع والمسؤوليات¶

• توفير استرجاع بزمن استجابة منخفض مع صلة متسقة.
• تقديم بحث هجين (BM25 + متجه) مع إعادة ترتيب اختيارية عبر AI-Box.
• الحفاظ على فهارس مُدارة بالإصدارات مع أسماء مستعارة للقراءة/الكتابة ونقل آمن.
• كشف بيانات الرصد والمراقبة لاكتشاف الأجزاء (shards) الساخنة، انحراف المخططات، والاستعلامات البطيئة.

روابط ذات صلة¶

• مسارات المعالجة: services/search/pipelines.md
• الفهارس وإدارة دورة الحياة (ILM): services/search/indices.md
• استكشاف الأخطاء وإصلاحها: services/search/troubleshooting.md

أهداف مستوى الخدمة (SLOs)¶

• زمن استجابة الاستعلام (p95) ≤ 800ms (OpenSearch فقط)، ≤ 1200ms (مع إعادة الترتيب).
• معدل الأخطاء < 1% خلال 10 دقائق.

3. المبادئ التوجيهية¶

تستند البنية الهندسية والفلسفة التشغيلية لخدمة البحث بشكل عميق على مبادئ SRE الأساسية التالية:

• البنية التحتية كشيفرة برمجية ():

  • ماذا: جميع تكوينات العنقود — قوالب الفهارس، قوالب المكونات، مسارات المعالجة، وسياسات ISM — مُعرَّفة كملفات JSON خاضعة للتحكم في الإصدارات.
  • لماذا: يضمن هذا أن تكوين العنقود قابل للتكرار والتدقيق ويمكن إدارته بأمان من خلال مسارات عمل Git.
  • كيف: تُستخدم مجموعة من النصوص البرمجية (tools/search/) لتطبيق هذا التكوين على العنقود بطريقة متطابقة النتائج (idempotent).

• البيانات قابلة لإعادة البناء، وليست مقدسة ():

  • ماذا: يُعامل فهرس OpenSearch كذاكرة تخزين مؤقت عالية الأداء وقابلة للاستبدال للبيانات المخزنة في قاعدة بيانات PostgreSQL.
  • لماذا: هذه العقلية التشغيلية تبسط التعافي من الكوارث. في حالة فشل كارثي، يمكن حذف فهرس البحث بأكمله وإعادة بنائه من مصدر الحقيقة دون فقدان للبيانات.

• الإدارة الآلية لدورة حياة البيانات ():

  • ماذا: تُستخدم سياسات إدارة حالة الفهرس (ISM) لأتمتة المهام الروتينية مثل تدوير الفهارس، أخذ لقطات (snapshots)، والحذف.
  • لماذا: يقلل هذا من العمل اليدوي المتكرر للمشغلين ويضمن تشغيل العنقود بكفاءة وضمن حدود موارده.

4. نظرة سريعة على البنية الهندسية¶

خدمة البحث هي عنقود OpenSearch قائم بذاته يخدم طلبات البحث من AI-Box ويتلقى طلبات الفهرسة من API.

flowchart TD
    subgraph "منصة لبيب"
        API[(خدمة API)]:::svc
        AIB[(خدمة AI-Box)]:::svc
    end

    subgraph "خدمة البحث"
        direction LR
        OS[عنقود OpenSearch]:::store
        T[قوالب الفهارس]
        P[مسارات البحث]
    end

    API -- "فهرسة المستندات" --> OS
    AIB -- "تنفيذ استعلامات البحث" --> OS
    T -- "تحديد الهيكل" --> OS
    P -- "معالجة الاستعلامات" --> OS

    classDef svc fill:#f8fafc,stroke:#64748b,stroke-width:1px;
    classDef store fill:#f0fdf4,stroke:#22c55e,stroke-width:1px;

5. أدلة التشغيل الرئيسية¶

هذه النظرة العامة هي نقطة البداية. للإجراءات التشغيلية التفصيلية، استخدم الأدلة التالية:

• البنية التحتية كشيفرة برمجية (IaC): شرح مفصل للقوالب ومسارات المعالجة التي تُعرّف العنقود.
• الاختبارات المبدئية (Smoke Tests): الأداة الأساسية للتحقق من صحة وسلامة تكوين البحث.
• دليل استكشاف الأخطاء وإصلاحها: أدلة تشغيل خطوة بخطوة لسيناريوهات الاستجابة للحوادث الشائعة.