trustgraph/docs/tech-specs/ontorag.he.md

---
layout: default
title: "OntoRAG: מפרט טכני לחילוץ ידע מבוסס אונטולוגיה ושליפת שאילתות"
parent: "Hebrew (Beta)"
---

# OntoRAG: מפרט טכני לחילוץ ידע מבוסס אונטולוגיה ושליפת שאילתות

> **Beta Translation:** This document was translated via Machine Learning and as such may not be 100% accurate. All non-English languages are currently classified as Beta.

## סקירה כללית

OntoRAG היא מערכת לחילוץ ידע ושליפת שאילתות המונעת על ידי אונטולוגיה, המאכפת עקביות סמנטית קפדנית במהלך חילוץ משולשים של ידע מטקסט לא מובנה וכן במהלך שליפת שאילתות מגרף הידע המתקבל. בדומה ל-GraphRAG, אך עם אילוצי אונטולוגיה פורמליים, OntoRAG מבטיחה שכל המשולשים החילוצים תואמים למבנים אונטולוגיים מוגדרים מראש ומספקת יכולות שליפת שאילתות מודעות לסמנטיקה.

המערכת משתמשת בהתאמת דמיון וקטורי כדי לבחור דינמית תת-קבוצות רלוונטיות של אונטולוגיות הן עבור פעולות חילוץ והן עבור פעולות שליפה, ומאפשרת עיבוד ממוקד ומתאים להקשר תוך שמירה על תוקף סמנטי.

**שם השירות**: `kg-extract-ontology`

## מטרות

**חילוץ התואם לאונטולוגיה**: להבטיח שכל המשולשים החילוצים תואמים באופן קפדני לאונטולוגיות הטעונות.
**בחירת הקשר דינמית**: להשתמש בהטבעות כדי לבחור תת-קבוצות רלוונטיות של אונטולוגיות עבור כל מקטע.
**עקביות סמנטית**: לשמור על היררכיות מחלקות, תחומים/טווחים של תכונות ואילוצים.
**עיבוד יעיל**: להשתמש במאגרי וקטורים בזיכרון עבור התאמת אלמנטים של אונטולוגיה מהירה.
**ארכיטקטורה ניתנת להרחבה**: לתמוך במספר אונטולוגיות מקבילות עם תחומים שונים.

## רקע

שירותי חילוץ ידע נוכחיים (`kg-extract-definitions`, `kg-extract-relationships`) פועלים ללא אילוצים פורמליים, מה שעלול לגרום ליצירת משולשים לא עקביים או לא תואמים. OntoRAG פותרת בעיה זו על ידי:

1. טעינת אונטולוגיות פורמליות המגדירות מחלקות ותכונות חוקיות.
2. שימוש בהטבעות כדי להתאים תוכן טקסטואלי לאלמנטים רלוונטיים של אונטולוגיה.
3. הגבלת החילוץ ליצירת משולשים התואמים לאונטולוגיה בלבד.
4. מתן אימות סמנטי של ידע חילוץ.

גישה זו משלבת את הגמישות של חילוץ עצבי עם הדיוק של ייצוג ידע פורמלי.

## עיצוב טכני

### ארכיטקטורה

מערכת OntoRAG מורכבת מהרכיבים הבאים:

```
┌─────────────────┐
│  Configuration  │
│    Service      │
└────────┬────────┘
         │ Ontologies
         ▼
┌─────────────────┐      ┌──────────────┐
│ kg-extract-     │────▶│  Embedding   │
│   ontology      │      │   Service    │
└────────┬────────┘      └──────────────┘
         │                      │
         ▼                      ▼
┌─────────────────┐      ┌──────────────┐
│   In-Memory     │◀────│   Ontology   │
│  Vector Store   │      │   Embedder   │
└────────┬────────┘      └──────────────┘
         │
         ▼
┌─────────────────┐      ┌──────────────┐
│    Sentence     │────▶│   Chunker    │
│    Splitter     │      │   Service    │
└────────┬────────┘      └──────────────┘
         │
         ▼
┌─────────────────┐      ┌──────────────┐
│    Ontology     │────▶│   Vector     │
│    Selector     │      │   Search     │
└────────┬────────┘      └──────────────┘
         │
         ▼
┌─────────────────┐      ┌──────────────┐
│    Prompt       │────▶│   Prompt     │
│   Constructor   │      │   Service    │
└────────┬────────┘      └──────────────┘
         │
         ▼
┌─────────────────┐
│  Triple Output  │
└─────────────────┘
```

### פרטי רכיב

#### 1. טוען אונטולוגיות

**מטרה**: שולף ומנתח תצורות אונטולוגיות משירות התצורה באמצעות עדכונים מבוססי אירועים.

**יישום**:
טוען האונטולוגיות משתמש בתור ConfigPush של TrustGraph כדי לקבל עדכוני תצורת אונטולוגיות מבוססי אירועים. כאשר רכיב תצורה מסוג "אונטולוגיה" נוסף או משתנה, הטוען מקבל את העדכון דרך תור config-update ומנתח את מבנה ה-JSON המכיל מטא-נתונים, מחלקות, מאפייני אובייקטים ומאפייני טיפוס נתונים. האונטולוגיות המנותחות מאוחסנות בזיכרון כאובייקטים מובנים שניתן לגשת אליהם ביעילות במהלך תהליך החילוץ.

**פעולות מרכזיות**:
להירשם לתור config-update עבור תצורות מסוג אונטולוגיה
לנתח מבני אונטולוגיה מסוג JSON לאובייקטים של OntologyClass ו-OntologyProperty
לאמת את מבנה האונטולוגיה ועקביותה
לשמור אונטולוגיות מנותחות בזיכרון לגישה מהירה
לטפל בעיבוד פר-פלואו עם מאגרי וקטורים ספציפיים ל-פלואו

**מיקום יישום**: `trustgraph-flow/trustgraph/extract/kg/ontology/ontology_loader.py`

#### 2. משובץ אונטולוגיות

**מטרה**: יוצר הטמעות וקטוריות עבור כל רכיבי האונטולוגיה כדי לאפשר התאמת דמיון סמנטי.

**יישום**:
משובץ האונטולוגיות מעבד כל רכיב באונטולוגיות הטעונות ויוצר הטמעות וקטוריות באמצעות שירות EmbeddingsClientSpec. עבור כל רכיב, הוא משלב את מזהה הרכיב, התוויות והתיאור (הערה) כדי ליצור ייצוג טקסטואלי. טקסט זה מומר לאחר מכן להטמעת וקטור ממדית גבוהה הלוכדת את המשמעות הסמנטית שלו. הטמעות אלה מאוחסנות במאגר וקטורים FAISS בזיכרון, פר-פלואו, יחד עם מטא-נתונים על סוג הרכיב, האונטולוגיה המקורית וההגדרה המלאה. המשובץ מזהה באופן אוטומטי את ממד ההטמעה מהתגובה הראשונה להטמעה.

**פעולות מרכזיות**:
ליצור ייצוגים טקסטואליים ממזהי רכיבים, תוויות והערות
ליצור הטמעות באמצעות EmbeddingsClientSpec (תוך שימוש ב-asyncio.gather לעיבוד באצווה)
לאחסן הטמעות עם מטא-נתונים מקיפים במאגר וקטורים FAISS
לאנדקס לפי אונטולוגיה, סוג רכיב ומזהה רכיב לשליפה יעילה
לזהות באופן אוטומטי את ממדי ההטמעה לאתחול מאגר הווקטורים
לטפל במודלי הטמעה פר-פלואו עם מאגרי וקטורים עצמאיים

**מיקום יישום**: `trustgraph-flow/trustgraph/extract/kg/ontology/ontology_embedder.py`

#### 3. מעבד טקסט (מפצל משפטים)

**מטרה**: מפרק מקטעי טקסט לפלחי משנה מפורטים לצורך התאמת אונטולוגיות מדויקת.

**יישום**:
מעבד הטקסט משתמש ב-NLTK לטוקניזציה של משפטים וסימון חלקי דיבור כדי לחלק מקטעי טקסט נכנסים למשפטים. הוא מטפל בתאימות גרסאות של NLTK על ידי ניסיון להוריד את `punkt_tab` ו-`averaged_perceptron_tagger_eng`, עם מעבר לגרסאות ישנות יותר במידת הצורך. כל מקטע טקסט מחולק למשפטים בודדים שניתן להתאים אליהם באופן עצמאי לרכיבי אונטולוגיה.

**פעולות מרכזיות**:
לחלק טקסט למשפטים באמצעות טוקניזציה של משפטים של NLTK
לטפל בתאימות גרסאות של NLTK (punkt_tab לעומת punkt)
ליצור אובייקטים של TextSegment עם טקסט ומידע על מיקום
לתמוך הן במשפטים שלמים והן במקטעים בודדים

**מיקום יישום**: `trustgraph-flow/trustgraph/extract/kg/ontology/text_processor.py`

#### 4. בורר אונטולוגיות

**מטרה**: מזהה את תת-הקבוצה הרלוונטית ביותר של רכיבי אונטולוגיה עבור מקטע הטקסט הנוכחי.

**יישום**:
בורר האונטולוגיות מבצע התאמה סמנטית בין פלחי טקסט ורכיבי אונטולוגיה באמצעות חיפוש דמיון וקטורי של FAISS. עבור כל משפט ממקטע הטקסט, הוא יוצר הטמעה ומחפש במאגר הווקטורים את רכיבי האונטולוגיה הדומים ביותר באמצעות דמיון קוסינוס עם סף הניתן להגדרה (ברירת מחדל 0.3). לאחר איסוף כל הרכיבים הרלוונטיים, הוא מבצע פתרון תלות מקיף: אם נבחרה מחלקה, מחלקות האב שלה כלולות; אם נבחר מאפיין, מחלקות הדומיין והטווח שלו מתווספות. בנוסף, עבור כל מחלקה שנבחרה, הוא כולל באופן אוטומטי **את כל המאפיינים המתייחסים למחלקה זו** בתחום או בטווח שלה. זה מבטיח שלחילוץ יש גישה לכל מאפייני היחס הרלוונטיים.

**פעולות מפתח**:
יצירת הטמעות עבור כל מקטע טקסט (משפטים)
ביצוע חיפוש של שכנים הקרובים ביותר בבנק וקטורים FAISS (top_k=10, threshold=0.3)
החלת סף דמיון כדי לסנן התאמות חלשות
פתרון תלויות (מחלקות הורים, תחומים, טווחים)
**הכללת כל המאפיינים הקשורים למחלקות שנבחרו באופן אוטומטי** (התאמת תחום/טווח)
יצירת תת-אונטולוגיה קוהרנטית עם כל היחסים הנדרשים
הסרת אלמנטים כפולים המופיעים מספר פעמים

**מיקום יישום**: `trustgraph-flow/trustgraph/extract/kg/ontology/ontology_selector.py`

#### 5. בניית הנחיה (Prompt)

**מטרה**: יוצר הנחיות מובנות המכוונות את מודל השפה הגדול (LLM) לחלץ רק משולשות התואמים לאונטולוגיה.

**יישום**:
שירות החילוץ משתמש בתבנית Jinja2 שנטענת מ-`ontology-prompt.md` אשר מעצבת את תת-האונטולוגיה ואת הטקסט לחילוץ על ידי מודל השפה הגדול. התבנית חוזרת באופן דינמי על מחלקות, מאפייני אובייקט ומאפייני נתוני טיפוס תוך שימוש בתחביר Jinja2, ומציגה כל אחד עם התיאורים, התחומים, הטווחים והיחסים ההיררכיים שלהם. ההנחיה כוללת כללים קפדניים לגבי שימוש רק באלמנטים של האונטולוגיה המסופקת ומבקשת פורמט פלט JSON לצורך ניתוח עקבי.

**פעולות מפתח**:
שימוש בתבנית Jinja2 עם לולאות על אלמנטים של אונטולוגיה
עיצוב מחלקות עם יחסי הורה (subclass_of) והערות
עיצוב מאפיינים עם אילוצי תחום/טווח והערות
הכללת כללי חילוץ מפורשים ודרישות פורמט פלט
קריאה לשירות ההנחיה עם מזהה התבנית "extract-with-ontologies"

**מיקום התבנית**: `ontology-prompt.md`
**מיקום יישום**: `trustgraph-flow/trustgraph/extract/kg/ontology/extract.py` (שיטת build_extraction_variables)

#### 6. שירות החילוץ הראשי

**מטרה**: מתאם את כל הרכיבים לביצוע חילוץ משולשות מבוסס אונטולוגיה מקצה לקצה.

**יישום**:
שירות החילוץ הראשי (KgExtractOntology) הוא שכבת הארגון המנהלת את זרימת העבודה שלמה. הוא משתמש בדפוס FlowProcessor של TrustGraph עם אתחול רכיבים ספציפיים לכל זרימה. כאשר מגיעה עדכון תצורה של אונטולוגיה, הוא מאתחל או מעדכן את הרכיבים הספציפיים לזרימה (טוען אונטולוגיה, ממיר, מעבד טקסט, בוחר). כאשר מגיע מקטע טקסט לעיבוד, הוא מתאם את הצינור: חלוקת הטקסט למקטעים, מציאת אלמנטי אונטולוגיה רלוונטיים באמצעות חיפוש וקטורי, בניית הנחיה מוגבלת, קריאה לשירות ההנחיה, ניתוח ותיקוף של התגובה, יצירת משולשות הגדרת אונטולוגיה, ופליטה הן של משולשות תוכן והן של הקשרים של ישויות.

**צינור חילוץ**:
1. קבלת מקטע טקסט דרך תור chunks-input
2. אתחול רכיבי זרימה אם יש צורך (במקטע הראשון או בעדכון תצורה)
3. חלוקת הטקסט למשפטים באמצעות NLTK
4. חיפוש בבנק וקטורים FAISS כדי למצוא מושגי אונטולוגיה רלוונטיים
5. בניית תת-אונטולוגיה עם הכללה אוטומטית של מאפיינים
6. בניית משתני תבנית Jinja2
7. קריאה לשירות ההנחיה עם תבנית extract-with-ontologies
8. ניתוח תגובת JSON למשולשות מובנים
9. תיקוף משולשות והרחבת URIs ל-URIs מלאים של אונטולוגיה
10. יצירת משולשות הגדרת אונטולוגיה (מחלקות ומאפיינים עם תויות/הערות/תחומים/טווחים)
11. בניית הקשרים של ישויות מכל המשולשות
12. פליטה לתורים של משולשות והקשרים של ישויות

**תכונות מפתח**:
בנקי וקטורים ספציפיים לכל זרימה התומכים במודלי הטמעה שונים
עדכוני אונטולוגיה מונעי אירועים דרך תור config-update
הרחבת URI אוטומטית באמצעות URIs של אונטולוגיה
אלמנטים של אונטולוגיה מוספים לגרף ידע עם מטא-נתונים מלאים
הקשרים של ישויות כוללים הן אלמנטים של תוכן והן אלמנטים של אונטולוגיה

**מיקום יישום**: `trustgraph-flow/trustgraph/extract/kg/ontology/extract.py`

### תצורה

השירות משתמש בגישה הסטנדרטית של TrustGraph לתצורה עם ארגומנטים של שורת הפקודה:

```bash
kg-extract-ontology \
  --id kg-extract-ontology \
  --pulsar-host localhost:6650 \
  --input-queue chunks \
  --config-input-queue config-update \
  --output-queue triples \
  --entity-contexts-output-queue entity-contexts
```

**פרמטרי תצורה מרכזיים**:
`similarity_threshold`: 0.3 (ברירת מחדל, ניתן להגדרה בקוד)
`top_k`: 10 (מספר רכיבי אונטולוגיה לשליפה לכל מקטע)
`vector_store`: FAISS IndexFlatIP עם זיהוי אוטומטי של ממדים לכל זרימה
`text_processor`: NLTK עם טוקניזציה של משפטים punkt_tab
`prompt_template`: "extract-with-ontologies" (תבנית Jinja2)

**תצורת אונטולוגיה**:
אונטולוגיות נטענות באופן דינמי באמצעות תור ההודעות config-update עם סוג "ontology".

### זרימת נתונים

1. **שלב אתחול** (לכל זרימה):
   קבלת תצורת אונטולוגיה באמצעות תור ההודעות config-update
   ניתוח JSON של האונטולוגיה לאובייקטים של OntologyClass ו-OntologyProperty
   יצירת הטמעות עבור כל רכיבי אונטולוגיה באמצעות EmbeddingsClientSpec
   אחסון הטמעות בתוך מאגר וקטורים FAISS ספציפי לכל זרימה
   זיהוי אוטומטי של ממדי ההטמעה מהתגובה הראשונה

2. **שלב חילוץ** (לכל מקטע):
   קבלת מקטע מתור הקלט chunks-input
   חלוקת המקטע למשפטים באמצעות NLTK
   חישוב הטמעות עבור כל משפט
   חיפוש במאגר הווקטורים FAISS עבור רכיבי אונטולוגיה רלוונטיים
   בניית תת-אונטולוגיה עם הכללת מאפיינים אוטומטית
   יצירת משתנים לתבנית Jinja2 עם טקסט ואונטולוגיה
   הפעלת שירות שאילתות עם תבנית extract-with-ontologies
   ניתוח תגובת JSON ואימות של שלשות
   הרחבת URIs באמצעות URIs של אונטולוגיה
   יצירת שלשות הגדרת אונטולוגיה
   בניית הקשרים של ישויות מכל השלשות
   פליטה לתורים triples ו-entity-contexts

### מאגר וקטורים בזיכרון

**מטרה**: מספק חיפוש מהיר של דמיון המבוסס על זיכרון, לציפוף של התאמת רכיבי אונטולוגיה.

**יישום: FAISS**

המערכת משתמשת ב-**FAISS (Facebook AI Similarity Search)** עם IndexFlatIP לחיפוש מדויק של דמיון קוסינוס. תכונות עיקריות:

**IndexFlatIP**: חיפוש מדויק של דמיון קוסינוס באמצעות מכפלה פנימית
**זיהוי אוטומטי**: ממד נקבע מהתגובת ההטמעה הראשונה
**מאגרים ספציפיים לזרימה**: לכל זרימה יש מאגר וקטורים עצמאי עבור מודלים שונים של הטמעה
**נרמול**: כל הווקטורים מנורמלים לפני אינדוקס
**פעולות באצווה**: הוספה יעילה באצווה לטעינת אונטולוגיה ראשונית

**מיקום יישום**: `trustgraph-flow/trustgraph/extract/kg/ontology/vector_store.py`

### אלגוריתם בחירת תת-אונטולוגיה

**מטרה**: בוחר באופן דינמי את החלק הרלוונטי המינימלי של האונטולוגיה עבור כל מקטע טקסט.

**שלבי אלגוריתם מפורטים**:

1. **פילוח טקסט**:
   חלוקת המקטע הקלט למשפטים באמצעות זיהוי משפטים של NLP
   חילוץ צירופי שמות עצם, צירופי פעלים וישויות בעלות שם מכל משפט
   יצירת מבנה היררכי של מקטעים תוך שמירה על הקשר

2. **יצירת הטמעות**:
   יצירת הטמעות וקטוריות עבור כל מקטע טקסט (משפטים וצירופים)
   שימוש באותו מודל הטמעה כמו זה המשמש עבור רכיבי אונטולוגיה
   שמירת הטמעות עבור מקטעים חוזרים כדי לשפר את הביצועים

3. **חיפוש דמיון**:
   עבור כל הטמעת מקטע טקסט, חיפוש במאגר הווקטורים
   אחזור rכיבי אונטולוגיה הדומים ביותר (לדוגמה, 10)
   החלת סף דמיון (לדוגמה, 0.7) כדי לסנן התאמות חלשות
   צבירת תוצאות על פני כל המקטעים, תוך מעקב אחר תדירות התאמות

4. **פתרון תלות**:
   עבור כל מחלקה שנבחרה, הכללה רקורסיבית של כל מחלקות האב עד לשורש
   עבור כל מאפיין שנבחר, הכללת מחלקות הדומיין והטווח שלו
   עבור מאפיינים הפוכים, ודאו ששני הכיוונים כלולים
   הוספת מחלקות שוות ערך אם הן קיימות באונטולוגיה

5. **בניית תת-קבוצה**:
   הסרת כפילויות של רכיבים שנאספו תוך שמירה על יחסים
   ארגון למחלקות, מאפיינים אובייקטיים ומאפיינים של טיפוסי נתונים
   ודאו שכל האילוצים והיחסים נשמרים
   יצירת מיני-אונטולוגיה עצמאית שתקפה ושלמה

**דוגמה להמחשה**:
בהינתן טקסט: "The brown dog chased the white cat up the tree."
מקטעים: ["brown dog", "white cat", "tree", "chased"]
רכיבים תואמים: [dog (class), cat (class), animal (parent), chases (property)]
תלויות: [animal (parent of dog and cat), lifeform (parent of animal)]
תת-קבוצה סופית: מיני-אונטולוגיה שלמה עם היררכיית animal ויחס chase

### אימות שלשות

**מטרה**: מבטיח שכל שלשות החילוץ תואמות באופן קפדני לאילוצי האונטולוגיה.

**אלגוריתם אימות**:
פלט חוזה (יש לעקוב אחר הפורמט בדיוק).
1. **בדיקת תקינות מחלקה**:
   ודאו שהנושאים הם מופעים של מחלקות המוגדרות בתת-אונטולוגיה.
   עבור מאפיינים אובייקטים, ודאו שהאובייקטים הם גם מופעים חוקיים של מחלקות.
   בדקו שמות מחלקות מול מילון המחלקות של האונטולוגיה.
   התייחסו להירוארכיות מחלקות - מופעים של תת-מחלקות תקפים עבור אילוצי מחלקת האב.

2. **בדיקת תקינות מאפיינים**:
   ודאו שהפרדיקטים תואמים למאפיינים בתת-אונטולוגיה.
   הבדילו בין מאפייני אובייקטים (מקישורים בין ישויות) ומאפייני טיפוס נתונים (מקישורים בין ישות לליטרל).
   ודאו ששמות המאפיינים תואמים בדיוק (תוך התחשבות בשם המרחב אם קיים).

3. **בדיקת תחום/טווח**:
   עבור כל מאפיין המשמש כפרדיקט, אחזרו את התחום והטווח שלו.
   ודאו שסוג הנושא תואם או יורש מסוג התחום של המאפיין.
   ודאו שסוג האובייקט תואם או יורש מסוג הטווח של המאפיין.
   עבור מאפייני טיפוס נתונים, ודאו שהאובייקט הוא ליטרל מסוג XSD הנכון.

4. **בדיקת קרדינליות**:
   עקבו אחר ספירת השימוש במאפיינים לכל נושא.
   בדקו קרדינליות מינימלית - ודאו שמאפיינים נדרשים קיימים.
   בדקו קרדינליות מקסימלית - ודאו שמאפיין לא משמש יותר מדי פעמים.
   עבור מאפיינים פונקציונליים, ודאו שיש לכל היותר ערך אחד לכל נושא.

5. **בדיקת טיפוס נתונים**:
   נתחו ערכי ליטרל בהתאם לטיפוסי XSD המוצהרים שלהם.
   ודאו שמספרים שלמים הם מספרים חוקיים, תאריכים מעוצבים כראוי וכו'.
   בדקו תבניות מחרוזות אם מוגדרים אילוצי regex.
   ודאו שכתובות URI מעוצבות כראוי עבור טיפוסי xsd:anyURI.

**דוגמה לבדיקה**:
טריפל: ("Buddy", "has-owner", "John")
בדקו ש-"Buddy" מסווג כמחלקה שיכולה להיות בעלת מאפיין "has-owner".
בדקו ש-"has-owner" קיים באונטולוגיה.
ודאו אילוץ תחום: הנושא חייב להיות מסוג "Pet" או תת-מחלקה.
ודאו אילוץ טווח: האובייקט חייב להיות מסוג "Person" או תת-מחלקה.
אם תקף, הוסיפו לפלט; אם לא תקף, רשמו הפרה ודלגו.

## שיקולי ביצועים

### אסטרטגיות אופטימיזציה

1. **מטמון הטבעות**: שמרו הטבעות עבור פלחים טקסטואליים בשימוש תכוף.
2. **עיבוד באצווה**: עבדו על מספר פלחים במקביל.
3. **אינדקס אחסון וקטורים**: השתמשו באלגוריתמים של שכנים קרובים ביותר משוערים עבור אונטולוגיות גדולות.
4. **אופטימיזציית שאילתות**: צמצמו את גודל השאילתה על ידי הכללת רק אלמנטים חיוניים של האונטולוגיה.
5. **מטמון תוצאות**: שמרו תוצאות חילוץ עבור מקטעים זהים.

### יכולת הרחבה

**הרחבה אופקית**: מספר מופעים של תוכנת חילוץ עם מטמון אונטולוגיה משותף.
**חלוקת אונטולוגיה**: חלקו אונטולוגיות גדולות לפי תחום.
**עיבוד סטרימינג**: עבדו על מקטעים כשהם מגיעים מבלי לבצע אצווה.
**ניהול זיכרון**: ניקוי תקופתי של הטבעות לא בשימוש.

## טיפול בשגיאות

### תרחישי כשל

1. **אונטולוגיות חסרות**: חזרו לחילוץ לא מוגבל.
2. **כשל בשירות הטבעות**: השתמשו בהטבעות שמורות או דלגו על התאמה סמנטית.
3. **חריגה של זמן תגובה של שירות השאילתות**: נסו שוב עם השהייה אקספוננציאלית.
4. **פורמט טריפל לא חוקי**: רשמו ודלגו על טריפלים מעוותים.
5. **אי-עקביות באונטולוגיה**: דווחו על סתירות והשתמשו באלמנטים חוקיים הספציפיים ביותר.

### ניטור

מדדים מרכזיים למעקב:

זמן טעינה ושימוש בזיכרון של האונטולוגיה.
השהייה ביצירת הטבעות.
ביצועי חיפוש וקטורי.
זמן תגובה של שירות השאילתות.
דיוק חילוץ טריפלים.
שיעור התאמה לאונטולוגיה.

## נתיב מעבר

### מתוכנות חילוץ קיימות

1. **פעולה מקבילה**: הפעילו במקביל לתוכנות החילוץ הקיימות בתחילה.
2. **פריסה הדרגתית**: התחילו עם סוגי מסמכים ספציפיים.
3. **השוואת איכות**: השוו את איכות הפלט לתוכנות החילוץ הקיימות.
4. **מעבר מלא**: החליפו את תוכנות החילוץ הקיימות לאחר אימות האיכות.

### פיתוח אונטולוגיה

1. **התחילו מקיים**: צרו אונטולוגיות ראשוניות מידע קיים.
2. **שיפור איטרטיבי**: שפרו בהתבסס על תבניות חילוץ.
3. **סקירה של מומחי תחום**: ודאו עם מומחי תחום.
4. **השתמשו ב-LLM**: השתמשו במודלים גדולים של שפה כדי ליצור אונטולוגיות.
**השתמשו ב-RAG**: השתמשו בשליפה מבוססת אחזור כדי לשפר את התוצאות.
**השתמשו ב-Agent**: השתמשו בסוכנים כדי לבצע משימות.
**השתמשו ב-Tool**: השתמשו בכלים כדי לשפר את הפרודוקטיביות.
**השתמשו ב-Memory**: השתמשו בזיכרון כדי לשפר את ההקשר.
**השתמשו ב-Output**: השתמשו בפלט כדי לשפר את התוצאות.


**רכיבי השירות**:
`onto-query-sparql`: ממיר שפה טבעית לשאילתות SPARQL עבור Cassandra.
`sparql-cassandra`: שכבת שאילתות SPARQL עבור Cassandra באמצעות rdflib.
`onto-query-cypher`: ממיר שפה טבעית לשאילתות Cypher עבור מסדי נתונים גרפיים.
`cypher-executor`: ביצוע שאילתות Cypher עבור Neo4j/Memgraph/FalkorDB.

### ארכיטקטורה

```
                    ┌─────────────────┐
                    │   User Query    │
                    └────────┬────────┘
                             │
                             ▼
                    ┌─────────────────┐      ┌──────────────┐
                    │   Question      │────▶│   Sentence   │
                    │   Analyser      │      │   Splitter   │
                    └────────┬────────┘      └──────────────┘
                             │
                             ▼
                    ┌─────────────────┐      ┌──────────────┐
                    │   Ontology      │────▶│   Vector     │
                    │   Matcher       │      │    Store     │
                    └────────┬────────┘      └──────────────┘
                             │
                             ▼
                    ┌─────────────────┐
                    │ Backend Router  │
                    └────────┬────────┘
                             │
                 ┌───────────┴───────────┐
                 │                       │
                 ▼                       ▼
    ┌─────────────────┐          ┌─────────────────┐
    │ onto-query-     │          │ onto-query-     │
    │    sparql       │          │    cypher       │
    └────────┬────────┘          └────────┬────────┘
             │                            │
             ▼                            ▼
    ┌─────────────────┐          ┌─────────────────┐
    │   SPARQL        │          │   Cypher        │
    │  Generator      │          │  Generator      │
    └────────┬────────┘          └────────┬────────┘
             │                            │
             ▼                            ▼
    ┌─────────────────┐          ┌─────────────────┐
    │ sparql-         │          │ cypher-         │
    │ cassandra       │          │ executor        │
    └────────┬────────┘          └────────┬────────┘
             │                            │
             ▼                            ▼
    ┌─────────────────┐          ┌─────────────────┐
    │   Cassandra     │          │ Neo4j/Memgraph/ │
    │                 │          │   FalkorDB      │
    └────────┬────────┘          └────────┬────────┘
             │                            │
             └────────────┬───────────────┘
                          │
                          ▼
                 ┌─────────────────┐      ┌──────────────┐
                 │   Answer        │────▶│   Prompt     │
                 │  Generator      │      │   Service    │
                 └────────┬────────┘      └──────────────┘
                          │
                          ▼
                 ┌─────────────────┐
                 │  Final Answer   │
                 └─────────────────┘
```

### צינור עיבוד שאילתות

#### 1. מנתח שאלות

**מטרה**: מפרק שאלות משתמש לרכיבים סמנטיים לצורך התאמה לאונטולוגיה.

**תיאור אלגוריתם**:
מנתח השאלות לוקח את השאלה בשפה טבעית ומפרק אותה לפלחי משמעות באמצעות אותה גישת חלוקת משפטים כמו צינור החילוץ. הוא מזהה ישויות, קשרים ואילוצים מרכזיים המוזכרים בשאלה. כל פלח נתח עבור סוג השאלה (עובדתית, אגרגציה, השוואה וכו') ופורמט התשובה הצפוי. פירוק זה עוזר לזהות אילו חלקים של האונטולוגיה רלוונטיים ביותר למענה על השאלה.

**פעולות מרכזיות**:
חלוקת השאלה למשפטים ולביטויים
זיהוי סוג השאלה והכוונתה
חילוץ ישויות ויחסים המוזכרים
זיהוי אילוצים וסינונים בשאלה
קביעת פורמט התשובה הצפוי

#### 2. מותאם אונטולוגיות לשאילתות

**מטרה**: מזהה את תת-האונטולוגיה הרלוונטית הדרושה כדי לענות על השאלה.

**תיאור אלגוריתם**:
דומה לבחירת האונטולוגיה בצינור החילוץ, אך מותאם לשאלות ותשובות. המתאם מייצר הטבעות עבור פלחי שאלה ומחפש במאגר הווקטורים אלמנטים רלוונטיים באונטולוגיה. עם זאת, הוא מתמקד במציאת מושגים שיכולים להיות שימושיים ליצירת שאילתות, ולא לחילוץ. הוא מרחיב את הבחירה כדי לכלול מאפיינים קשורים שניתן לעבור דרכם במהלך חקר הגרף, גם אם הם אינם מוזכרים במפורש בשאלה. לדוגמה, אם נשאל על "עובדים", הוא עשוי לכלול מאפיינים כמו "עובד עבור", "מנהל" ו"מדווח ל" שיכולים להיות רלוונטיים למציאת מידע על עובדים.

**אסטרטגיית התאמה**:
הטבעת פלחי שאלה
מציאת מושגי אונטולוגיה המוזכרים ישירות
הכללת מאפיינים המחברים בין מחלקות המוזכרות
הוספת מאפיינים הפוכים וקשורים לניווט
הכללת מחלקות הורה/ילד לשאילתות היררכיות
יצירת מחיצת אונטולוגיה ממוקדת שאילתות

#### 3. מנתב רקע

**מטרה**: מנתב שאילתות לנתיב השאילתות הספציפי המתאים לרקע בהתבסס על תצורה.

**תיאור אלגוריתם**:
מנתב הרקע בודק את תצורת המערכת כדי לקבוע איזה רקע גרף פעיל (Cassandra או מבוסס Cypher). הוא מנתב את השאלה ומחיצת האונטולוגיה לשירות יצירת השאילתות המתאים. המנתב יכול גם לתמוך באיזון עומסים בין רקעים מרובים או במנגנוני גיבוי אם הרקע הראשי אינו זמין.

**לוגיקת ניתוב**:
בדיקת סוג הרקע המוגדר בהגדרות המערכת
ניתוב ל-`onto-query-sparql` עבור רקעי Cassandra
ניתוב ל-`onto-query-cypher` עבור Neo4j/Memgraph/FalkorDB
תמיכה בתצורות מרובות רקעים עם הפצת שאילתות
טיפול בתרחישי גיבוי ואיזון עומסים

#### 4. יצירת שאילתות SPARQL (`onto-query-sparql`)

**מטרה**: ממיר שאלות בשפה טבעית לשאילתות SPARQL לביצוע ב-Cassandra.

**תיאור אלגוריתם**:
מחולל שאילתות ה-SPARQL לוקח את השאלה ואת מחיצת האונטולוגיה ויוצר שאילתת SPARQL המותאמת לביצוע על הרקע של Cassandra. הוא משתמש בשירות ה-prompt עם תבנית ספציפית ל-SPARQL הכוללת סמנטיקה של RDF/OWL. המחולל מבין תבניות SPARQL כמו נתיבי מאפיינים, סעיפים אופציונליים וסינונים שיכולים לתרגם ביעילות לפעולות Cassandra.

**תבנית prompt ליצירת SPARQL**:
```
Generate a SPARQL query for the following question using the provided ontology.

ONTOLOGY CLASSES:
{classes}

ONTOLOGY PROPERTIES:
{properties}

RULES:
- Use proper RDF/OWL semantics
- Include relevant prefixes
- Use property paths for hierarchical queries
- Add FILTER clauses for constraints
- Optimise for Cassandra backend

QUESTION: {question}

SPARQL QUERY:
```

#### 5. יצירת שאילתות Cypher (`onto-query-cypher`)

**מטרה**: ממירה שאלות בשפה טבעית לשאילתות Cypher עבור מסדי נתונים גרפיים.

**תיאור האלגוריתם**:
יוצר השאילתות Cypher מייצר שאילתות Cypher מקומיות המותאמות ל-Neo4j, Memgraph ו-FalkorDB. הוא ממפה מחלקות אונטולוגיה לתגיות צמתים ומאפיינים ליחסים, תוך שימוש בתחביר התאמת תבניות של Cypher. היוצר כולל אופטימיזציות ספציפיות ל-Cypher כגון רמזים לכיוון יחסים, שימוש באינדקסים ורמזים לתכנון שאילתות.

**תבנית הנחיה ליצירת Cypher**:
```
Generate a Cypher query for the following question using the provided ontology.

NODE LABELS (from classes):
{classes}

RELATIONSHIP TYPES (from properties):
{properties}

RULES:
- Use MATCH patterns for graph traversal
- Include WHERE clauses for filters
- Use aggregation functions when needed
- Optimise for graph database performance
- Consider index hints for large datasets

QUESTION: {question}

CYPHER QUERY:
```

#### 6. מנוע שאילתות SPARQL-Cassandra (`sparql-cassandra`)

**מטרה**: מבצע שאילתות SPARQL נגד Cassandra באמצעות ספריית rdflib של Python.

**תיאור האלגוריתם**:
מנוע ה-SPARQL-Cassandra מיישם מעבד SPARQL באמצעות ספריית rdflib של Python עם אחסון מותאם אישית ב-Cassandra. הוא מתרגם תבניות גרף SPARQL לשאילתות CQL מתאימות של Cassandra, תוך טיפול בחיבורים, פילטרים ואגרגציות. המנוע שומר על מיפוי מ-RDF ל-Cassandra המשמר את המבנה הסמנטי תוך אופטימיזציה עבור מודל האחסון של משפחות עמודות של Cassandra.

**מאפייני יישום**:
יישום ממשק rdflib Store עבור Cassandra
תמיכה בשאילתות SPARQL 1.1 עם תבניות נפוצות
תרגום יעיל של תבניות משולשות ל-CQL
תמיכה בנתיבי מאפיינים ובשאילתות היררכיות
הזרמת תוצאות עבור מערכי נתונים גדולים
בריכת חיבורים ומטמון שאילתות

**דוגמה לתרגום**:
```sparql
SELECT ?animal WHERE {
  ?animal rdf:type :Animal .
  ?animal :hasOwner "John" .
}
```
מתרגם לשאילתות Cassandra מותאמות אופטימלית תוך שימוש באינדקסים ומפתחות מחיצה.

#### 7. מפעיל שאילתות Cypher (`cypher-executor`)

**מטרה**: מריץ שאילתות Cypher נגד Neo4j, Memgraph ו-FalkorDB.

**תיאור האלגוריתם**:
מפעיל ה-Cypher מספק ממשק אחיד להרצת שאילתות Cypher על פני מסדי נתונים גרפיים שונים. הוא מטפל בפרוטוקולי חיבור ספציפיים למסד הנתונים, רמזי אופטימיזציה לשאילתות ושינוי פורמט תוצאות. המפעיל כולל מנגנון ניסיון חוזר, ניהול חיבורים וניהול טרנזקציות המתאימים לכל סוג מסד נתונים.

**תמיכה במספר מסדי נתונים**:
**Neo4j**: פרוטוקול Bolt, פונקציות טרנזקציה, רמזי אינדקס
**Memgraph**: פרוטוקול מותאם אישית, זרימת תוצאות, שאילתות אנליטיות
**FalkorDB**: התאמת פרוטוקול Redis, אופטימיזציות בזיכרון

**תכונות ביצוע**:
ניהול חיבורים שאינו תלוי במסד הנתונים
אימות שאילתות ובדיקת תחביר
אכיפת מגבלות זמן ומשאבים
דף תוצאות וזרימת תוצאות
ניטור ביצועים לפי סוג מסד נתונים
מעבר אוטומטי בין מופעי מסד נתונים

#### 8. מחולל תשובות

**מטרה**: יוצר תשובה בשפה טבעית מתוצאות שאילתות.

**תיאור האלגוריתם**:
מחולל התשובות לוקח את תוצאות השאילתות המובנות ואת השאלה המקורית, ולאחר מכן משתמש בשירות ה-prompt כדי ליצור תשובה מקיפה. בניגוד לתגובות פשוטות המבוססות על תבניות, הוא משתמש ב-LLM כדי לפרש את נתוני הגרף בהקשר של השאלה, תוך טיפול ביחסים מורכבים, אגרגציות והסקת מסקנות. המחולל יכול להסביר את הנימוקים שלו על ידי התייחסות למבנה האונטולוגיה ולטרפלים הספציפיים שנשלפו מהגרף.

**תהליך יצירת תשובות**:
עיצוב תוצאות שאילתות להקשר מובנה
הכללת הגדרות אונטולוגיה רלוונטיות לצורך בהירות
יצירת prompt עם שאלה ותוצאות
יצירת תשובה בשפה טבעית באמצעות LLM
אימות התשובה מול כוונת השאלה
הוספת ציטוטים לישויות גרף ספציפיות במידת הצורך

### אינטגרציה עם שירותים קיימים

#### יחס עם GraphRAG

**משלימים**: onto-query מספק דיוק סמנטי בעוד ש-GraphRAG מספק כיסוי רחב
**תשתית משותפת**: שניהם משתמשים באותו גרף ידע ובשירותי prompt
**ניתוב שאילתות**: המערכת יכולה לנתב שאילתות לשירות המתאים ביותר בהתאם לסוג השאלה
**מצב היברידי**: ניתן לשלב את שתי הגישות ליצירת תשובות מקיפות

#### יחס עם OntoRAG Extraction

**אונטולוגיות משותפות**: משתמש באותות תצורת האונטולוגיה שנטענו על ידי kg-extract-ontology
**מאגר וקטורים משותף**: משתמש בהטמעות בזיכרון משירות החילוץ
**סמנטיקה עקבית**: השאילתות פועלות על גרפים שנבנו עם אותן מגבלות אונטולוגיות

### דוגמאות לשאילתות

#### דוגמה 1: שאילתת ישות פשוטה
**שאלה**: "אילו בעלי חיים הם יונקים?"
**התאמת אונטולוגיה**: [animal, mammal, subClassOf]
**שאילתה שנוצרה**:
```cypher
MATCH (a:animal)-[:subClassOf*]->(m:mammal)
RETURN a.name
```

#### דוגמה 2: שאילתת קשר
**שאלה**: "אילו מסמכים נכתבו על ידי ג'ון סמית'?"
**התאמה לאונטולוגיה**: [document, person, has-author]
**שאילתה שנוצרה**:
```cypher
MATCH (d:document)-[:has-author]->(p:person {name: "John Smith"})
RETURN d.title, d.date
```

#### דוגמה 3: שאילתת אגרגציה
**שאלה**: "כמה רגליים יש לחתולים?"
**התאמה לאונטולוגיה**: [חתול, מספר-רגליים (מאפיין נתונים)]
**שאילתה שנוצרה**:
```cypher
MATCH (c:cat)
RETURN c.name, c.number_of_legs
```

### הגדרות

```yaml
onto-query:
  embedding_model: "text-embedding-3-small"
  vector_store:
    shared_with_extractor: true  # Reuse kg-extract-ontology's store
  query_builder:
    model: "gpt-4"
    temperature: 0.1
    max_query_length: 1000
  graph_executor:
    timeout: 30000  # ms
    max_results: 1000
  answer_generator:
    model: "gpt-4"
    temperature: 0.3
    max_tokens: 500
```

### אופטימיזציות ביצועים

#### אופטימיזציית שאילתות

**גיזום אונטולוגיה**: כלול רק רכיבי אונטולוגיה נחוצים בפרומפטים
**מטמון שאילתות**: שמור שאילתות נפוצות ותשובותיהן
**מטמון תוצאות**: שמור תוצאות עבור שאילתות זהות בתוך חלון זמן
**עיבוד באצווה**: טפל במספר שאלות קשורות בביצוע מעבר גרף יחיד

#### שיקולי סקיילביליות

**ביצוע מבוזר**: חלק תת-שאילתות בין מחיצות גרף
**תוצאות מצטברות**: הזרם תוצאות עבור מערכי נתונים גדולים
**איזון עומסים**: חלק את עומס השאילתות בין מופעים רבים של שירות
**בריכות משאבים**: נהל בריכות חיבורים למסדי נתונים גרפיים

### טיפול בשגיאות

#### תרחישי כשל

1. **יצירת שאילתה לא חוקית**: חזור ל-GraphRAG או לחיפוש מילות מפתח פשוט
2. **אי התאמת אונטולוגיה**: הרחב את החיפוש לתת-אונטולוגיה רחבה יותר
3. **זמן קצוב של שאילתה**: פשט את השאילתה או הגדל את זמן הקצוב
4. **תוצאות ריקות**: הצע ניסוח מחדש של השאילתה או שאלות קשורות
5. **כשל בשירות LLM**: השתמש בשאילתות שמורות או בתגובות מבוססות תבניות

### מדדי ניטור

התפלגות מורכבות של שאלות
גדלי מחיצות אונטולוגיה
שיעור הצלחה של יצירת שאילתות
זמן ביצוע שאילתות גרפיות
ציוני איכות תשובות
שיעורי פגיעה במטמון
תדירויות שגיאות לפי סוג

## שיפורים עתידיים

1. **למידת אונטולוגיה**: הרחב באופן אוטומטי אונטולוגיות בהתבסס על דפוסי חילוץ
4. **הקצאת ציוני אמון**: הקצה ציוני אמון לטרפלים שחולצו
3. **יצירת הסברים**: ספק הסבר לניתוח טריפלים
4. **למידה פעילה**: בקש אימות אנושי לחילוצים לא ודאיים

## שיקולי אבטחה

1. **מניעת הזרקת פרומפטים**: נקה טקסט של חלקים לפני בניית פרומפט
2. **מגבלות משאבים**: הגבל את השימוש בזיכרון עבור מאגר וקטורים
3. **הגבלת קצב**: הגבל בקשות חילוץ לכל לקוח
4. **רישום ביקורת**: עקוב אחר כל בקשות חילוץ ותוצאות

## אסטרטגיית בדיקה

### בדיקות יחידה

טוען אונטולוגיה עם פורמטים שונים
יצירת ואחסון וקטורים
אלגוריתמים לחלוקת משפטים
חישובים של דמיון וקטורי
ניתוח ותיקוף טריפלים

### בדיקות אינטגרציה

צינור חילוץ מקצה לקצה
אינטגרציה עם שירות תצורה
אינטראקציה עם שירות פרומפטים
טיפול בו-זמני בחילוץ

### בדיקות ביצועים

טיפול באונטולוגיות גדולות (1000+ מחלקות)
עיבוד נפח גבוה של חלקים
שימוש בזיכרון תחת עומס
מדדי השהייה

## תוכנית הפצה

### סקירה כללית

מערכת OntoRAG תופץ בארבע פאזות עיקריות, כאשר כל פאזה מספקת ערך מצטבר תוך בניית המערכת השלמה. התוכנית מתמקדת בהקמת יכולות חילוץ בסיסיות תחילה, ולאחר מכן הוספת פונקציונליות שאילתות, ולאחר מכן אופטימיזציות ותכונות מתקדמות.

### פאזה 1: יסודות וחילוץ ליבה

**מטרה**: הקמת צינור חילוץ מונחה אונטולוגיה בסיסי עם התאמת וקטורים פשוטה.

#### שלב 1.1: יסודות ניהול אונטולוגיה
יישום טוען תצורה של אונטולוגיה (`OntologyLoader`)
ניתוח ותיקוף מבני JSON של אונטולוגיה
יצירת אחסון אונטולוגיה בזיכרון ודפוסי גישה
יישום מנגנון רענון אונטולוגיה

**קריטריוני הצלחה**:
טעינה וניתוח מוצלחים של תצורות אונטולוגיה
אימות מבנה אונטולוגיה ועקביות
טיפול במספר אונטולוגיות בו-זמנית

#### שלב 1.2: יישום מאגר וקטורים
יישום מאגר וקטורים פשוט מבוסס NumPy כפרוטוטייפ ראשוני
הוספת יישום מאגר וקטורים FAISS
יצירת הפשטת ממשק למאגר וקטורים
יישום חיפוש דמיון עם ספים הניתנים לתצורה

**קריטריוני הצלחה**:
אחסון ושליפה של הטמעות בצורה יעילה
ביצוע חיפוש דמיון עם השהייה של פחות מ-100ms
תמיכה גם ב-NumPy וגם ב-FAISS

#### שלב 1.3: צינור הטמעת אונטולוגיה
שילוב עם שירות הטמעות
יישום רכיב `OntologyEmbedder`
יצירת הטמעות עבור כל רכיבי האונטולוגיה
אחסון הטמעות עם מטא-דאטה ב-vector store

**קריטריוני הצלחה**:
יצירת הטמעות עבור מחלקות ומאפיינים
אחסון הטמעות עם מטא-דאטה מתאים
בנייה מחדש של הטמעות בעת עדכוני אונטולוגיה

#### שלב 1.4: רכיבי עיבוד טקסט
יישום מפצל משפטים באמצעות NLTK/spaCy
חילוץ ביטויים וישויות שמניות
יצירת היררכיה של פלחי טקסט
יצירת הטמעות עבור פלחי טקסט

**קריטריוני הצלחה**:
חלוקה מדויקת של טקסט למשפטים
חילוץ ביטויים בעלי משמעות
שמירה על יחסי הקשר

#### שלב 1.5: אלגוריתם בחירת אונטולוגיה
יישום התאמת דמיון בין טקסט לאונטולוגיה
בניית פתרון תלות עבור רכיבי אונטולוגיה
יצירת תת-קבוצות אונטולוגיה קוהרנטיות מינימליות
אופטימיזציה של ביצועי יצירת תת-קבוצות

**קריטריוני הצלחה**:
בחירת רכיבי אונטולוגיה רלוונטיים בדיוק של >80%
הכללת כל התלויות הנדרשות
יצירת תת-קבוצות בפחות מ-500ms

#### שלב 1.6: שירות חילוץ בסיסי
יישום בניית הנחיה לחילוץ
שילוב עם שירות הנחיות
ניתוח ואימות תגובות משולשות
יצירת נקודת שירות `kg-extract-ontology`

**קריטריוני הצלחה**:
חילוץ משולשות התואמות לאונטולוגיה
אימות כל המשולשות מול האונטולוגיה
טיפול בשגיאות חילוץ בצורה חלקה

### שלב 2: יישום מערכת שאילתות

**מטרה**: הוספת יכולות שאילתות מודעות לאונטולוגיה עם תמיכה במספר ממשקים.

#### שלב 2.1: רכיבי יסוד של שאילתות
יישום מנתח שאלות
יצירת מתאם אונטולוגיה לשאילתות
התאמת חיפוש וקטורי להקשר השאילתה
בניית רכיב ניתוב ממשקים

**קריטריוני הצלחה**:
ניתוח שאלות לרכיבים סמנטיים
התאמת שאלות לרכיבי אונטולוגיה רלוונטיים
ניתוב שאילתות לממשק מתאים

#### שלב 2.2: יישום נתיב SPARQL
יישום שירות `onto-query-sparql`
יצירת מחולל שאילתות SPARQL באמצעות LLM
פיתוח תבניות הנחיה ליצירת SPARQL
אימות תחביר SPARQL שנוצר

**קריטריוני הצלחה**:
יצירת שאילתות SPARQL חוקיות
שימוש בתבניות SPARQL מתאימות
טיפול בסוגי שאילתות מורכבים

#### שלב 2.3: מנוע SPARQL-Cassandra
יישום ממשק rdflib Store עבור Cassandra
יצירת מתרגם שאילתות CQL
אופטימיזציה של התאמת תבניות משולשות
טיפול בעיצוב תוצאות SPARQL

**קריטריוני הצלחה**:
ביצוע שאילתות SPARQL על Cassandra
תמיכה בתבניות SPARQL נפוצות
החזרת תוצאות בפורמט סטנדרטי

#### שלב 2.4: יישום נתיב Cypher
יישום שירות `onto-query-cypher`
יצירת מחולל שאילתות Cypher באמצעות LLM
פיתוח תבניות הנחיה ליצירת Cypher
אימות תחביר Cypher שנוצר

**קריטריוני הצלחה**:
יצירת שאילתות Cypher חוקיות
שימוש בתבניות גרף מתאימות
תמיכה ב-Neo4j, Memgraph, FalkorDB

#### שלב 2.5: מפעיל Cypher
הטמעת מנגנון ביצוע שאילתות Cypher עבור מספר מסדי נתונים.
תמיכה בפרוטוקול Bolt (Neo4j/Memgraph).
תמיכה בפרוטוקול Redis (FalkorDB).
טיפול בנרמול תוצאות.

**קריטריוני הצלחה**:
ביצוע שאילתות Cypher על כל מסדי הנתונים המיועדים.
טיפול בהבדלים ספציפיים למסד נתונים.
שמירה על בריכות חיבורים בצורה יעילה.

#### שלב 2.6: יצירת תשובות
הטמעת רכיב ליצירת תשובות.
יצירת הנחיות ליצירת תשובות.
עיצוב תוצאות שאילתות לצריכה על ידי מודל שפה גדול (LLM).
יצירת תשובות בשפה טבעית.

**קריטריוני הצלחה**:
יצירת תשובות מדויקות מתוצאות שאילתות.
שמירה על הקשר משאלת השאלה המקורית.
מתן תשובות ברורות ותמציתיות.

### שלב 3: אופטימיזציה ואמינות

**מטרה**: אופטימיזציה של ביצועים, הוספת מנגנון אחסון מטמון, שיפור טיפול בשגיאות ושיפור אמינות.

#### שלב 3.1: אופטימיזציה של ביצועים
הטמעת מנגנון אחסון מטמון עבור הטמעות (embeddings).
הוספת מנגנון אחסון מטמון עבור תוצאות שאילתות.
אופטימיזציה של חיפוש וקטורי באמצעות אינדקסים IVF של FAISS.
הטמעת עיבוד באצווה עבור הטמעות.

**קריטריוני הצלחה**:
הפחתת זמן השהייה ממוצע של שאילתות ב-50%.
תמיכה במספר גדול פי 10 של בקשות מקבילות.
שמירה על זמני תגובה מתחת לשנייה.

#### שלב 3.2: טיפול מתקדם בשגיאות
הטמעת מנגנון התאוששות מקיף משגיאות.
הוספת מנגנוני גיבוי בין נתיבי שאילתות.
יצירת לוגיקה של ניסיונות חוזרים עם השהייה אקספוננציאלית.
שיפור רישום שגיאות ואבחון.

**קריטריוני הצלחה**:
טיפול תקין בכל תרחישי כשל.
מעבר אוטומטי בין מערכות גיבוי.
דיווח מפורט על שגיאות לצורך איתור באגים.

#### שלב 3.3: ניטור ונגישות
הוספת איסוף מדדי ביצועים.
הטמעת מעקב אחר שאילתות.
יצירת נקודות קצה לבדיקת תקינות.
הוספת ניטור שימוש במשאבים.

**קריטריוני הצלחה**:
מעקב אחר כל מדדי הביצועים העיקריים.
זיהוי צווארי בקבוק במהירות.
ניטור בריאות המערכת בזמן אמת.

#### שלב 3.4: ניהול תצורה
הטמעת עדכונים דינמיים של תצורה.
הוספת אימות תצורה.
יצירת תבניות תצורה.
תמיכה בהגדרות ספציפיות לסביבה.

**קריטריוני הצלחה**:
עדכון תצורה ללא אתחול מחדש.
אימות כל שינויי התצורה.
תמיכה בסביבות פריסה מרובות.

### שלב 4: תכונות מתקדמות

**מטרה**: הוספת יכולות מתקדמות לפריסה בסביבת ייצור ושיפור פונקציונליות.

#### שלב 4.1: תמיכה במספר אונטולוגיות
הטמעת לוגיקה לבחירת אונטולוגיה.
תמיכה בשאילתות חוצות אונטולוגיות.
טיפול בגרסאות של אונטולוגיות.
יצירת יכולות מיזוג אונטולוגיות.

**קריטריוני הצלחה**:
שאילתות על פני מספר אונטולוגיות.
טיפול בקונפליקטים בין אונטולוגיות.
תמיכה באבולוציה של אונטולוגיות.

#### שלב 4.2: ניתוב שאילתות חכם
הטמעת ניתוב מבוסס ביצועים
הוספת ניתוח מורכבות שאילתות
יצירת אלגוריתמי ניתוב אדפטיביים
תמיכה בבדיקות A/B עבור נתיבים

**קריטריוני הצלחה**:
ניתוב שאילתות בצורה אופטימלית
למידה מביצועי שאילתות
שיפור הניתוב לאורך זמן

#### שלב 4.3: תכונות חילוץ מתקדמות
הוספת ניקוד אמון עבור משולשות
הטמעת יצירת הסברים
יצירת לולאות משוב לשיפור
תמיכה בלמידה מצטברת

**קריטריוני הצלחה**:
מתן ציוני אמון
הסבר החלטות חילוץ
שיפור מתמיד של הדיוק

#### שלב 4.4: חיזוק עבור סביבת ייצור
הוספת הגבלת קצב
הטמעת אימות/הרשאה
יצירת אוטומציה של פריסה
הוספת גיבוי ושחזור

**קריטריוני הצלחה**:
אבטחה מוכנה לסביבת ייצור
תהליך פריסה אוטומטי
יכולת שחזור מאסון

### אבני דרך של אספקה

1. **אבן דרך 1** (סוף שלב 1): חילוץ מבוסס אונטולוגיה בסיסי פועל
2. **אבן דרך 2** (סוף שלב 2): מערכת שאילתות מלאה עם נתיבי SPARQL ו-Cypher
3. **אבן דרך 3** (סוף שלב 3): מערכת מותאמת ויציבה, מוכנה לשלב בדיקות
4. **אבן דרך 4** (סוף שלב 4): מערכת מוכנה לסביבת ייצור עם תכונות מתקדמות

### הפחתת סיכונים

#### סיכונים טכניים
**מדרגיות של מאגר וקטורים**: להתחיל עם NumPy, לעבור בהדרגה ל-FAISS
**דיוק יצירת שאילתות**: הטמעת מנגנוני אימות וגיבוי
**תאימות לבסיס נתונים**: לבדוק באופן נרחב עם כל סוג בסיס נתונים
**צווארי בקבוק בביצועים**: לנתח ולבצע אופטימיזציה באופן איטרטיבי

#### סיכונים תפעוליים
**איכות אונטולוגיה**: הטמעת מנגנוני אימות ובדיקת עקביות
**תלויות שירות**: הוספת מנגנוני ניתוב וגיבוי
**מגבלות משאבים**: ניטור והגדרת מגבלות מתאימות
**עקביות נתונים**: הטמעת טיפול מתאים בעסקאות

### מדדי הצלחה

#### מדדי הצלחה לשלב 1
דיוק חילוץ: >90% התאמה לאונטולוגיה
מהירות עיבוד: <שנייה אחת לחלק
זמן טעינת אונטולוגיה: <10 שניות
השהיה של חיפוש וקטורים: <100ms

#### מדדי הצלחה לשלב 2
שיעור הצלחה של שאילתות: >95%
השהיה של שאילתות: <2 שניות מקצה לקצה
תאימות לבסיס נתונים: 100% עבור בסיסי נתונים מיועדים
דיוק תשובות: >85% בהתבסס על נתונים זמינים

#### מדדי הצלחה לשלב 3
זמן פעולה של המערכת: >99.9%
שיעור התאוששות משגיאות: >95%
שיעור פגיעות במטמון: >60%
משתמשים מקבילים: >100

#### מדדי הצלחה לשלב 4
שאילתות מרובות אונטולוגיות: נתמכות במלואן
אופטימיזציה של ניתוב: הפחתת השהיה של 30%
דיוק ניקוד אמון: >90%
פריסה לסביבת ייצור: עדכונים ללא השבתה

## הפניות

[OWL 2 Web Ontology Language](https://www.w3.org/TR/owl2-overview/)
[GraphRAG Architecture](https://github.com/microsoft/graphrag)
[Sentence Transformers](https://www.sbert.net/)
[FAISS Vector Search](https://github.com/facebookresearch/faiss)
[spaCy NLP Library](https://spacy.io/)
[rdflib Documentation](https://rdflib.readthedocs.io/)
[Neo4j Bolt Protocol](https://neo4j.com/docs/bolt/current/)