
# חיפוש סמנטי המונע שליפת ראיות עבור שאלוני אבטחת AI

שאלוני אבטחה—בין אם הם מגיעים ממבקרי **[SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2)**, מעריכי **[ISO 27001](https://www.iso.org/standard/27001)**, או מצוותי רכש ברמת הארגון—בדרך כלל מהווים צוואר בקבוק מוסתר במחזורי מכירות SaaS. גישות מסורתיות תלויות בחיפוש ידני במאגרי קבצים משותפים, PDF‑ים ומאגרים של מדיניות, תהליך שלוקח זמן ונטול דיוק.

היכרות עם **חיפוש סמנטי** ו‑**מאגרי וקטורים**. על‑ידי הטמעת כל פיסת ראיות התאימות—מדיניות, יישומי בקרה, דוחות ביקורת ואפילו שיחות Slack—בוקטורים במימדים גבוהים, מאפשרים שכבת שליפה מונעת‑AI שיכולה לאתר את הקטע הרלוונטי במילי‑שניות. כאשר מצמדים זאת לצינור **RAG (Retrieval‑Augmented Generation)**, המערכת יכולה לנסח תשובות שלמות, מודעות להקשר, עם ציטוטים, מבלי להסיט אדם מהתהליך.

במאמר זה נסקור:

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

---

## 1. למה חיפוש סמנטי מנצח חיפוש מילות מפתח

חיפוש מילות מפתח מתייחס למסמכים כ„שקיות מילים“. אם הביטוי המדויק „הצפנה במנוחה” לעולם לא מופיע במדיניות, אך הטקסט אומר „הנתונים מאוחסנים באמצעות AES‑256“, שאילתת מילות מפתח תאבד את הראיה הרלוונטית. חיפוש סמנטי, לעומת זאת, קולט *משמעות* על‑ידי המרת טקסט למיזוגים צפופים (embeddings). מיזוגים ממפים משפטים דומים סמנטית קרוב זה לזה במרחב הווקטורים, מה שמאפשר למנוע לשחזר משפט על „הצפנה AES‑256” כשמתבקשת תשובה על „הצפנה במנוחה”.

### יתרונות לתהליכי התאימות

| יתרון | חיפוש מילות מפתח מסורתי | חיפוש סמנטי |
|-------|----------------------------|--------------|
| ריכוז על מילון נרדפים | נמוך | גבוה |
| טיפול בקיצורים ובקיצור מילים | לקוי | חזק |
| שונות לשוניות (למשל „שמירת‑נתונים” vs „תיעוד‑שמר”) | מפספס | תופס |
| תמיכה בריבוי שפות (באמצעות מודלים רב‑לשוניים) | דורש אינדקסים נפרדים | מרחב וקטורי מאוחד |

הזיכרון הגבוה מתורגם ישירות למספר קטן יותר של פריטי ראיה שנשכחו, מה שאומר שהמבקרים מקבלים תשובות שלמות יותר וצוות התאימות חוסך זמן אתרור „המסמך החסר”.

---

## 2. סקירה ארכיטקטונית מרכזית

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

```mermaid
flowchart TD
    A["מקורות מסמכים"] --> B["קליטת נתונים והנרמול"]
    B --> C["חיתוך והעשרת מטה‑נתונים"]
    C --> D["יצירת מיזוגים\n(LLM או SBERT)"]
    D --> E["מאגר וקטורים\n(Pinecone, Qdrant, Milvus)"]
    E --> F["API חיפוש סמנטי"]
    F --> G["בונה פרומפט RAG"]
    G --> H["מחולל LLM\n(Claude, GPT‑4)"]
    H --> I["תשובה עם ציטוטים"]
    I --> J["ממשק UI / API של Procurize"]
```

### 2.1 מקורות מסמכים

- **מאגר מדיניות** (Git, Confluence, SharePoint)  
- **דוחות ביקורת** (PDF, CSV)  
- **מערכות ניהול משימות** (Jira, ServiceNow)  
- **ערוצי תקשורת** (Slack, Teams)  

### 2.2 קליטת נתונים והנרמול

מטלת ETL קלה מחלצת קבצים גולמיים, ממירה אותם לטקסט רגיל (כולל OCR עבור PDF סרוקים במידת הצורך) ומסירה תבנית מיותרת. הנרמול כולל:

- הסרת PII (באמצעות מודל DLP)  
- הוספת מטה‑נתונים של המקור (סוג מסמך, גרסה, בעלים)  
- תיוג לפי מסגרות רגולטוריות (SOC 2, ISO 27001, GDPR)  

### 2.3 חיתוך והעשרת מטה‑נתונים

מסמכים גדולים מחולקים לחתיכות ניהוליות (בין 200‑300 מילים). לכל חתיכה מועברים מטה‑נתונים של המסמך ההורה, ומקבלים גם **תגיות סמנטיות** שנוצרות על‑ידי מסווג אפסי‑ירייה. דוגמאות לתגיות: `"הצפנה"`, `"בקרת‑גישה"`, `"תגובה לאירוע"`.

### 2.4 יצירת מיזוגים

שתי גישות נפוצות:

| מודל | ויתור |
|------|--------|
| **SBERT / MiniLM בקוד‑פתוח** | עלות נמוכה, רינדור מקומי, מהיר |
| **מיזוגים של מודלים קנייניים (למשל OpenAI text‑embedding‑ada‑002)** | איכות גבוהה יותר, מבוסס API, עלות לפי טוקן |

וקטורי המיזוג נשמרים במאגר וקטורים התומך בחיפוש קרוב‑שכן (ANN). אפשרויות פופולאריות הן **Pinecone**, **Qdrant**, או **Milvus**. המאגר שומר גם על מטה‑נתוני החתיכות לתמיכה בסינון.

### 2.5 API חיפוש סמנטי

כאשר משתמש (או תהליך אוטומטי) שואל שאלה, השאילתה מוטבעת באותו מודל, ואז מחפש ANN כדי להחזיר את k‑החתיכות הרלוונטיות ביותר. ניתן להחיל גם מסננים נוספים, כגון „רק מסמכים מ‑Q3‑2024” או „חייב להשתייך ל‑SOC 2”.

### 2.6 Retrieval‑Augmented Generation (RAG)

החתיכות שהוחזרו מוכנסות לתבנית פרומפט שמורה ל‑LLM:

1. **לסכם** תשובה תמציתית.  
2. **לצטט** כל פריט ראיה בפורמט Markdown (למשל `[1]`).  
3. **לאמת** שהתגובה תואמת לרגולציה המבוקשת.  

דוגמת פרומפט:

```
אתה עוזר בתאימות. השתמש בקטעי הראיות הבאים כדי לענות על השאלה. צטט כל קטע בעיצוב [#].

שאלה: כיצד הפלטפורמה מצפינה נתונים במנוחה?

ראיות:
[1] "כל הנתונים המאוחסנים ב‑S3 מוצפנים עם AES‑256 באמצעות הצפנה בצד השרת."
[2] "בסיסי הנתונים PostgreSQL שלנו משתמשים ב‑Transparent Data Encryption (TDE) עם מפתח של 256‑ביט."

תשובה:
```

פלט של ה‑LLM הופך לתשובה הסופית שמוצגת ב‑Procurize, מוכנה לאישור סופי.

---

## 3. אינטגרציה עם Procurize

Procurize מציע כבר **מרכז שאלונים** שבו כל שורה ניתנת לקישור ל‑ID מסמך. הוספת המנוע הסמנטי יוצרת כפתור **„מילוי אוטומטי”** חדש.

### 3.1 שלבי זרימת העבודה

1. **המשתמש בוחר פריט בשאלון** (למשל „תאר את מדיניות השמירת הגיבויים”).  
2. **Procurize שולח את טקסט השאלה** ל‑API החיפוש הסמנטי.  
3. המנוע **מחזיר את שלוש חתיכות הראיה המובילות** ותשובה שנוצרה על‑ידי LLM.  
4. הממשק מציג את התשובה **לתיקון מקומי** עם קישורי ציטוטים.  
5. לאחר **אישור**, התשובה ו‑ID‑י המקורות נשמרים בלוג האודיט של Procurize, משמרים את המקוריות.

### 3.2 השפעה במציאות

מחקר מקרה פנימי הציג **הפחתה של 72 %** בזמן המענה הממוצע לכל שאלה—מ‑12 דקות של חיפוש ידני לתחתית של 3 שניות של ניסוח בעזרת AI. דיוק, כפי שנמדד משוב המבקרים לאחר ההגשה, עלה **15 %**, בעיקר בגלל שהפסדים של ראיות נפלו.

---

## 4. ממשל, אבטחה וביצועים

### 4.1 פרטיות נתונים

- **הצפנה במנוחה** עבור מאגר הווקטורים (השתמשו בהצפנה המובנית של DB).  
- **רשת Zero‑Trust** עבור נקודות הקצה של ה‑API (mutual TLS).  
- **בקרת גישה מבוססת תפקידים (RBAC)**: רק מהנדסי התאימות יכולים להפעיל את תהליך ה‑RAG.

### 4.2 עדכוני מודלים

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

### 4.3 מדדי זמן תגובה

| רכיב | זמן תגובה טיפוסי |
|------|-------------------|
| יצירת מיזוג (שאילתה בודדת) | 30‑50 ms |
| חיפוש ANN (top‑10) | 10‑20 ms |
| הרכבת פרומפט + תגובה של LLM (ChatGPT‑4) | 800‑1200 ms |
| קריאת API מקצה‑לקצה | < 2 שניות |

המספרים עומדים בקלות בציפיות UI אינטראקטיבי. עבור עיבוד באצ' (למשל יצירת שאלון שלם בפעם אחת), מומלץ למקביל את צינור הבקשות.

### 4.4 ביקורת והסבריות

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

---

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

1. **שליפה רב‑לשונית** – שימוש במודלים רב‑לשוניים (למשל LASER) לתמיכה בצוותים גלובליים.  
2. **לולאת משוב** – תיעוד עריכות הסוקר כנתוני אימון לשיפור המודל של ה‑LLM, כך שהאיכות עולה עם הזמן.  
3. **גרסאות מדיניות דינאמיות** – זיהוי אוטומטי של שינויי מדיניות דרך Git hooks וביצוע אינדקס מחדש רק לחלקים שהשתנו.  
4. **תעדוף מבוסס סיכון** – שילוב המנוע עם מודל דירוג סיכון כדי להציג תחילה את פריטי השאלון הקריטיים ביותר.

---

## 6. מדריך יישום מהיר

1. **פרוס מאגר וקטורים** (לדוגמה Qdrant ב‑Docker).  
2. **החלץ מודל מיזוגים** (sentence‑transformers/paraphrase‑multilingual‑MPNET‑base‑v2).  
3. **בנה צינור קילוט** בעזרת Python – `langchain` או `Haystack`.  
4. **פרוס API קל** (FastAPI) עם נקודות קצה `/search` ו‑`/rag`.  
5. **השתלב עם Procurize** בעזרת Webhooks או תוסף UI מותאם.  
6. **ניטור** באמצעות Grafana + Prometheus לתצוגת זמן תגובה ושיעור שגיאות.

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

---

## 7. סיכום

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

- **להאיץ** את זמן המענה מדקות לשניות.  
- **לשפר את הדיוק** באמצעות ציטוט אוטומטי של הראיות הרלוונטיות ביותר.  
- **לשמר תאימות** עם תיעוד מתמשך וניתן לביקורת.

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