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

## מבוא  

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

מודלים גדולים של שפה (LLMs) כגון GPT‑4, Claude, או Llama 2 יכולים לכתוב תשובות נרטיביות באיכות גבוהה תוך שניות. עם זאת, שחרור הכוח הזה ישירות על שאלון כמעט ואיננו מניב תוצאות אמינות. הפלט הגולמי עלול לסטות משפת המדיניות, לפספס סעיפים קריטיים, או לחלום עדויות שאינן קיימות.  

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

נסקר:

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

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

---

## 1. הבנת נוף הפרומפט  

### 1.1 סוגי פרומפט  

| סוג פרומפט | מטרה | דוגמה |
|-------------|------|---------|
| **פרומפט קונטקסטואלי** | מספק ל‑LLM קטעי מדיניות רלוונטיים, סטנדרטים והגדרות | “להלן קטע מהמדיניות שלנו ב‑[SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2) לגבי הצפנה במצב מנוחה…” |
| **פרומפט אינסטרוקטיבי** | מודיע למודל בדיוק איך יש לעצב את התשובה | “כתוב את התשובה בשלושה פסקאות קצרות, כל אחת מתחילה בכותרת מודגשת.” |
| **פרומפט מגבלה** | קובע גבולות קשים כמו מספר מילים או מילים אסורות | “אל תעלה על 250 מילים והימנע משימוש במילה ‘אולי’.” |
| **פרומפט אימות** | יוצר רשימת ביקורת שהתגובה חייבת למלא | “לאחר ניסוח התשובה, רשום את כל סעדי המדיניות שלא הוזכרו.” |

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

### 1.2 מדוע פרומפטים חד‑שלביים נכשלים  

פרומפט חד‑שלבי פשוט כמו *“ענה על השאלת האבטחה הבאה”* לרוב מניב:

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

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

---

## 2. בניית מסגרת הנדסת פרומפט  

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

### 2.1 שלב 1 – שליפת קטעי מדיניות רלוונטיים  

השתמשו במאגר ידע שניתן לחיפוש (חנות וקטורים, גרף DB, או אינדקס מילות‑מפתח) כדי לאסוף את סעדי המדיניות המתאימים ביותר.  
*שאילתת דוגמה*: “הצפנה במצב מנוחה” + “[ISO 27001](https://www.iso.org/standard/27001)” או “SOC 2 CC6.1”.

התוצאה עשויה להיות:

```
קטע מדיניות A:
“כל נתוני הייצור חייבים להיות מוצפנים במצב מנוחה באמצעות AES‑256 או אלגוריתם מקביל. מפתחות ההצפנה מתחלפים כל 90 יום ומאוחסנים במודול אבטחת חומרה (HSM).”
```

### 2.2 שלב 2 – הרכבת תבנית הפרומפט  

תבנית המשלבת את כל סוגי הפרומפטים:

```
[CONTEXT] 
{קטעי מדיניות}

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

[QUESTION] 
{טקסט השאלה האבטחתית}

[CONSTRAINT] 
- מקסימום 250 מילים.
- אל תציג בקרים שאינם מצוינים בקטעים.
- סיים באמירה שמאשר שהוכחות ניתנות לספק על‑בקשה.

[VERIFICATION] 
לאחר המענה, רשום אילו קטעי מדיניות לא נחתמו ואילו מונחים חדשים הוצגו.
```

### 2.3 שלב 3 – שליחת הפרומפט ל‑LLM  

שלחו את הפרומפט המרוכב ל‑LLM שבחרתם דרך ה‑API שלו. לשם שחזור, קבעו `temperature = 0.2` (רעש נמוך) ו‑`max_tokens` בהתאם למגבלת המילים.

### 2.4 שלב 4 – ניתוח ואימות הפלט  

ה‑LLM מחזיר שני חלקים: **התשובה** ו‑**רשימת הבדיקה**. סקריפט אוטומטי בודק:

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

במקרה של כשלון, הסקריפט מפעיל **פרומפט‑חדש** עם משוב:

```
[FEEDBACK]
חסר אזכור קטע B והצגת את המונח “סיבוב מפתחות דינמי” שאינו חלק מהמדיניות שלנו. אנא עדכן בהתאם.
```

### 2.5 שלב 5 – הוספת קישורי הוכחות  

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

---

## 3. דיאגרמת זרימת עבודה בעולם אמת  

הדיאגרמה הבאה ב‑Mermaid ממחישה את תהליך הקצה‑לקצה בפלטפורמת צייתנות SaaS טיפוסית.

```mermaid
graph TD
    A["משתמש בוחר שאלון"] --> B["המערכת מאחזרת קטעי מדיניות רלוונטיים"]
    B --> C["בונה הפרומפט משלב פרומפט רב‑חלקי"]
    C --> D["LLM מייצר תשובה + רשימת בדיקה"]
    D --> E["מאמת אוטומטי מפרש את רשימת הבדיקה"]
    E -->|הצלחה| F["התשובה נשמרת, מתווספים קישורי הוכחות"]
    E -->|כישלון| G["פרומפט מחדש עם משוב"]
    G --> C
    F --> H["מבקרים צופים בתשובה בלוח המחוונים של Procurize"]
    H --> I["ה audit הושלם, תשובה מיוצאת"]
```

כל התוויות במרכאות נכתבו בעברית.

---

## 4. טכניקות מתקדמות בפרומפט  

### 4.1 הדגמות מצומצמות (Few‑Shot)  

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

```
דוגמה 1:
ש: כיצד אתם מגנים על נתונים בזמן העברה?
ת: כל הנתונים בזמן העברה מוצפנים באמצעות TLS 1.2 או גרסה גבוהה יותר, עם צופן בעל קידוד קדמי (forward‑secrecy). [קטע C]

דוגמה 2:
ש: תארו את תהליך תגובת האירועים שלכם.
ת: תוכנית תגובה לאירועים שלנו פועלת לפי מסגרת [NIST CSF](https://www.nist.gov/cyberframework) (NIST 800‑61), כוללת חלון העברת אירוע של 24 שעות ונבדקת פעמיים בשנה. [קטע D]
```

ה‑LLM כעת מקבל סגנון ברור לחיקוי.

### 4.2 עידוד חשיבה שלב‑אחר‑שלב (Chain‑of‑Thought)  

הנחו את המודל לחשוב שלב‑אחר‑שלב לפני כתיבת התשובה:

```
חשוב על אילו קטעי מדיניות חלים, רשום אותם, ואז נסח את התשובה.
```

זה מצמצם הזיות ומספק עקבות שקיפות שניתן לתעד.

### 4.3 ייצור משולב‑שיחזור (Retrieval‑Augmented Generation – RAG)  

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

---

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

Procurize מציע כבר:

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

הטמעת צינור הנדסת הפרומפט דורשת שלושה קריאות API מרכזיות:

1. `GET /policies/search` – שליפת קטעים על‑פי מילות‑מפתח שהוצאה משאלת השאלון.  
2. `POST /llm/generate` – שליחת הפרומפט המורכב וקבלת תשובה + רשימת ביקורת.  
3. `POST /questionnaire/{id}/answer` – שליחת תשובה מותאמת, צירוף קישורי הוכחות, וסימון המשימה כהושלמה.

דוגמת עטיפה ב‑Node.js:

```javascript
async function answerQuestion(questionId) {
  const q = await api.getQuestion(questionId);
  const fragments = await api.searchPolicies(q.keywords);
  const prompt = buildPrompt(q.text, fragments);
  const { answer, verification } = await api.llmGenerate(prompt);
  if (verify(verification)) {
    await api.submitAnswer(questionId, answer, fragments.evidenceLinks);
  } else {
    const revisedPrompt = addFeedback(prompt, verification);
    // חזור על הלולאה עד להצלחה
  }
}
```

כאשר משולב בממשק של Procurize, אנליסטי האבטחה יכולים ללחוץ על **„יצירת תשובה אוטומטית”** ולצפות בתהליך מתקדמת דרך הסרגל שמוצג בדיאגרמת Mermaid למעלה.

---

## 6. מדידת הצלחה  

| מדד | בסיס | יעד אחרי הנדסת פרומפט |
|------|------|--------------------------|
| זמן ממוצע יצירת תשובה | 45 דק' | ≤ 15 דק' |
| שיעור תיקונים בביקורת אנושית | 22 % | ≤ 5 % |
| ציות לציטוטי מדיניות (תגיות) | 78 % | ≥ 98 % |
| מדד שביעות רצון מבקרים | 3.2/5 | ≥ 4.5/5 |

איספו KPI אלו דרך לוח האנליטיקה של Procurize. ניטור מתמשך מאפשר כיול מדויק של תבניות הפרומפט ובחירת קטעי המדיניות.

---

## 7. חלודות והימנעות מהן  

| חלודה | סימן | פתרון |
|--------|------|--------|
| הצפת הפרומפט בקטעים לא רלוונטיים | תשובה נוטה לסטייה, זמן תגובה גבוה | החילו סף רלוונטיות (cosine similarity > 0.78) לפני ההכללה |
| התעלמות מטמפרטורת המודל | מדי פעם פלט יצירתי אך לא מדויק | קבעו טמפרטורה נמוכה (0.1‑0.2) לעומסי צייתנות |
| חוסר גרסאות לקטעי מדיניות | תשובות מציינות סעיפים מיושנים | אחסנו קטעים עם מזהה גרסה וכפו שימוש רק בגרסה האחרונה אלא אם מבוקשת אחרת |
| הסתמכות על אימות יחיד | שגיאות קצה נדלקות | הריצו בדיקת כלל‑שנייה (למשל regex למונחים אסורים) אחרי שלב ה‑LLM |

---

## 8. כיוונים עתידיים  

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

ההתקדמות הזו תזיז את האוטומציה משלב *“טיוטת מהירה”* ל‑*“מוכנה לביקורת ללא פיקוח אנושי”*.

---

## סיכום  

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

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

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

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

---  

## ראה גם  

- פרקטיקות מיטביות להנדסת פרומפט עבור מודלי שפה  
- ייצור משולב‑שיחזור: תבניות ועקיפי‑חביבה  
- מגמות אוטומציית צייתנות לשנת 2025  
- מדריך API של Procurize והשלבות  

---