לעצור הזיות של AI: לעגן את RAG בנתונים עם Azure AI Search

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

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

למה אפליקציות מולטי-מודליות נכשלות בעולם האמיתי

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

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

הכשל אינו חוסר חכמה של המודל. הנתונים פשוט אינם מוכנים, אינם מאורגנים ואינם מנוטרים.

RAG ו-Azure AI Search: חיפוש היברידי ודירוג סמנטי

מהו RAG ולמה הוא נחוץ

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

Azure AI Studio ו-Azure AI Foundry נשענים על התבנית הזאת ותומכים בכל סוגי המודליות: שפה, ראייה, דיבור ואפילו שליפת וידאו. אבל RAG טוב רק כמו הנתונים שלו.

שליפה אחת לא מספיקה

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

• חיפוש היברידי שמשלב מילות מפתח ווקטורים;
• דירוג סמנטי (semantic ranker) המובנה ב-Azure AI Search.

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

הערכה מתמשכת: ביסוס, רלוונטיות ועקביות

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

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

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

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

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

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

הכלים של מייקרוסופט

• Copilot Studio הוא סביבת ה-low-code לעיצוב התנהגות סוכנים, זרימות, הנחיות וטריגרים של אירועים.
• Agent Service ב-Azure AI Foundry הוא התשתית הארגונית להפעלת סוכנים בייצור, עם ניטור, יומנים ומדדים ועם אוטומציה שמובנה בה פיקוח אנושי.

שלוש שאלות לבדיקת סוכן

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

אם התשובה לאחת מהן שלילית, אין לכם סוכן חכם אלא שומר מסך יקר.

סוכנים אוטונומיים: איך בונים קודם רשת ביטחון

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

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

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

1. הגדרת היקף של זהות וגישה: הרשאות מינימליות לסוכן, בלי תפקידי ניהול גורפים.
2. רישום ושחזור: כל פעולה משאירה עקבות שניתן לבקר, ולכל פעולה רצינית יש מסלול חזרה.
3. מסנני תוכן והתנהגות: Azure AI Content Safety והגדרות ידע שמונעים תשובות לא הולמות וחריגה מהתסריט.

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

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

Azure AI Foundry: מפעל או שדה מוקשים

Azure AI Foundry הוא המיזם הדגל של מייקרוסופט לבניית בינה מלאכותית, ובו מצויים:

• קטלוג מודלים של מייקרוסופט, OpenAI, Meta, Mistral, DeepSeek ואחרים;
• אפשרויות התאמה כמו RAG, כיוונון עדין (fine-tuning) וזיקוק מודלים;
• Agent Service לתזמור סוכנים;
• כלים כמו Prompt Flow להערכה וניפוי שגיאות;
• תכונות להבטחת ביסוס, בקרות זהות וגישה, מסנני בטיחות תוכן ולוחות מחוונים לתצפית.

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

טעויות נפוצות ואבני נגף

• דילוג על בקרת גישה: צוות חיבר קופיילוט ב-Foundry ל-SharePoint וחשף בטעות נתוני משאבי אנוש רגישים. כללי גישה מובנים היו מונעים זאת.
• הדגמה מעבדתית מול שטח: ארגון הריץ GPT-4 Turbo לתיוג תמונות מוצרים. תמונות סטודיו נקיות עבדו מצוין, אבל בצילומי טלפון מטושטשים מהמחסן המודל זיהה עגלות תינוק כרהיטי משרד וסיפק מספרים סידוריים שגויים במקום תוויות UPC.
• הזנחת העלויות: התמחור ב-Foundry מבוסס צריכה וקשור לכל שירות ולכל קריאה. בלי הערכה במחשבון התמחור של Azure ומעקב אחר השימוש, צוות הכספים יופתע מהחשבונית.
• אב טיפוס בסנדבוקס שעולה לייצור בלי הערכות: נתוני הדגמה נקיים יוצרים אפקט "וואו", אבל בלי בדיקות ביסוס, שטף, רלוונטיות ועקביות מופיעות סטיות בפלט, האמון יורד וההנהלה מקצצת בתקציב. זה כישלון משילות, לא כישלון של הפלטפורמה.
• בחירת המודל הגדול ביותר רק כי הוא נשמע חכם במקום להתאים מודל למשימה.

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

בינה מלאכותית אחראית וניהול מחזור חיים

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

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

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

נקודת ההתחלה היא Azure AI Content Safety, שמסנן הנחיות ותגובות אלימות, מגונות או פוגעניות, אבל זו רמת היגיינה בסיסית בלבד. Foundry ו-Copilot Studio מוסיפים שכבות הערכה: בדיקות אמינות, דירוג רלוונטיות ולוחות מחוונים לשקיפות והסברתיות, כך שאפשר להתאים ספים ולסנן קלטים ופלטים.

מייקרוסופט משקיעה בתחום בהיקף עצום, עם 34 אלף מהנדסים במשרה מלאה המוקדשים להבטחה ועוד 15 אלף שותפים. אבל אף אחד מהם אינו בתוך הדייר (tenant) שלכם. נעילת זהויות, בידוד נתונים, הצפנה ומדיניות נשארים באחריותכם.

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

טיפים מעשיים לסיכום

• אל תסתמכו על שיטת שליפה אחת: שלבו חיפוש היברידי של מילות מפתח ווקטורים עם דירוג סמנטי ב-Azure AI Search.
• הריצו מעריכים לביסוס, רלוונטיות, קוהרנטיות ונאמנות למקור כבר מהיום הראשון ולא רק לפני ההשקה.
• הגדירו לכל סוכן היקף צר, הרשאות מינימליות ותיאור תפקיד מדויק.
• הבטיחו רישום פעולות, מסלול חזרה ואדם בלולאה בכל פעולה משמעותית.
• הפעילו Azure AI Content Safety ומסנני התנהגות כבסיס, והוסיפו שכבות הערכה.
• התייחסו לסוכנים אוטונומיים, שנמצאים בתצוגה מקדימה, כאל טכנולוגיה שנדרשת בה זהירות ובדיקה לפני פריסה רחבה.
• בדקו את מודל התמחור לפי צריכה במחשבון של Azure ועקבו אחר השימוש.
• התאימו את המודל למשימה במקום לבחור את הגדול ביותר.
• הטמיעו ניהול מחזור חיים: בדיקה, אישור, הפצה, ביקורת, חזרה.

סיכום

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