מדריך

אוטומציה של סיבוב מפתחות API עבור שירות AI ללא השבתת היישום.

→אחסון מפתחות ראשיים ומשניים ב-Azure Key Vault עם סיבוב אוטומטי. הגדרת היישום לנסות את המפתח המשני אם הראשי נכשל.

למה: Key Vault מנהל את מחזור החיים של הסיבוב. דפוס המפתח הכפול מבטיח שמפתח אחד תמיד תקף במהלך חלון הסיבוב.

הבטחה שתעבורת שירותי AI לעולם לא תעזוב את ה-VNet וש-Microsoft לא תוכל להשתמש בנתוני לקוחות לשיפור השירות.

→פריסת שירות ה-AI עם Private Endpoint וביטול גישת רשת ציבורית. בנפרד, הפעלת הגדרת ביטול הסכמה לעיבוד נתונים במשאב.

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

מתן גישה מאובטחת וללא אישורי גישה לשירות AI עבור יישום ב-Azure Kubernetes Service (AKS).

→הקצאת Managed Identity מסוג User-Assigned ל-pods ב-AKS. הענקת תפקיד ה-RBAC "Cognitive Services User" לזהות זו על משאב שירות ה-AI.

למה: Managed Identity הוא דפוס האימות הסטנדרטי ללא סיסמה עבור משאבי Azure, ומבטל את הצורך לאחסן סודות בתצורות ה-pod.

מקור↗

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

→יצירת משאבי שירותי AI נפרדים לכל מחלקה. החלת תג משאב "department" על כל אחד. הגדרת תקציבים ב-Azure Cost Management עם ספי התראה המבוססים על ערך התג.

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

התראה לפעולות כאשר שיעורי שגיאות API של שירות AI עולים על 5% או שהשיהוי עולה על 2 שניות.

→הגדרת התראות מבוססות מדדים ב-Azure Monitor על משאב שירות ה-AI. השתמש במדדים "Failed Requests" ו-"Latency" עם תקופת אגרגציה מתאימה.

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

תכנון תוכנית התאוששות מאסון עבור מודלי AI מותאמים אישית (לדוגמה, Custom Vision, LUIS) עם RTO/RPO נמוך.

→פריסת משאבים באזורים מזווגים. אוטומציה של ייצוא מודלים יומי לאחסון גיאו-יתיר (GRS). שימוש ב-Azure Traffic Manager לכשל-מעבר אוטומטי מבוסס בדיקת תקינות.

למה: שירותי AI PaaS אינם מכוסים על ידי Azure Site Recovery. התאוששות מאסון דורשת ייצוא/ייבוא מודלים מפורש ומבוסס סקריפטים ושירות ניתוב תעבורה ברמת ה-DNS.

רישום לוגים של כל בקשות ותגובות של קריאות לשירותי AI לצורך שמירת ביקורת לטווח ארוך.

→הצבת Azure API Management (APIM) מול שירות ה-AI. הגדרת מדיניות APIM לרישום גופי בקשות/תגובות מלאים. שליחת לוגים ל-Azure Storage עם מדיניות אי-שינוי.

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

פריסת פתרון AI בתחום הבריאות המעבד נתוני מטופלים וחייב לעמוד בתקנות HIPAA.

→פריסת משאב ה-AI באזור Azure בארה"ב התומך ב-HIPAA. חתימה על הסכם Business Associate Agreement (BAA) עם Microsoft עבור המנוי.

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

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

→שימוש ב-Azure AI Content Safety API. חסימה אוטומטית של תוכן המסומן בחומרה "גבוהה". תכנים המסומנים כ"בינוני" או "נמוך" יעמדו בתור לתהליך סקירה אנושית.

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

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

→אימון מודל Custom Vision לזיהוי אובייקטים. שימוש במאגר נתונים של תמונות מתויגות המייצגות את המוצרים בסביבת מדף מציאותית.

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

מקור↗

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

→פריסת קונטיינר Azure AI Vision לניתוח תמונות למכשיר קצה (לדוגמה, Azure IoT Edge).

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

חילוץ טקסט ממסמכים היסטוריים סרוקים המכילים שילוב של טקסט מודפס, טקסט בכתב יד, ומספר שפות.

→שימוש ב-Azure AI Vision Read API (חלק מ-Image Analysis). ציון גרסת המודל העדכנית ביותר כדי להבטיח את הביצועים הטובים ביותר על תוכן מעורב.

למה: ה-Read API הוא מנוע ה-OCR המתקדם ביותר של Azure, המותאם במיוחד לתרחישים מבוססי מסמכים עם תוכן מעורב, וביצועיו עולים על ממשקי OCR ישנים יותר.

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

→פריסת קונטיינר Azure AI Vision Spatial Analysis למכשיר קצה המחובר למצלמות החנות.

למה: Spatial Analysis הוא פתרון ייעודי ומקונטיינר לאנליטיקה מרחבית בזמן אמת מוידאו, המספק פעולות כמו `personcount`, `persondistance` ו-`personcrossingline`.

למודל Custom Vision לזיהוי אובייקטים יש דיוק גבוה אך Recall נמוך (מפספס אובייקטים רבים).

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

למה: Recall נמוך הוא בעיית כמות/גיוון נתונים. המודל לא ראה מספיק וריאציות כדי להכליל ביעילות. הוספת דוגמאות מגוונות היא הפתרון העיקרי.

ניתוח ביקורות לקוחות לזיהוי סנטימנט כלפי תכונות ספציפיות של מוצר (לדוגמה, חיובי ל"חיי סוללה", שלילי ל"מסך").

→שימוש ב-Azure AI Language Sentiment Analysis API כשהפרמטר `opinionMining` מופעל.

למה: Opinion Mining (המכונה גם Aspect-Based Sentiment Analysis) היא התכונה הספציפית שנועדה לחלץ סנטימנט הקשור ליעדים בודדים (היבטים) בתוך טקסט.

מקור↗

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

→שימוש בתכונת Custom Question Answering של Azure AI Language. יש לה יכולת תרגום שאילתות מובנית כדי להתאים שאלות כנגד בסיס הידע האנגלי.

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

מודל Conversational Language Understanding (CLU) מבלבל בין שתי כוונות דומות (לדוגמה, "הזמן פיצה" לעומת "שנה הזמנה").

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

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

חילוץ ישויות ספציפיות לתחום כמו "ContractValue" או "TerminationClause" ממסמכים משפטיים.

→אימון מודל Custom Named Entity Recognition (NER) באמצעות Azure AI Language. ספק דוגמאות מתויגות מהמסמכים שלך.

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

איתור והסתרת מידע אישי מזהה (PII) באופן אוטומטי, כמו שמות ומספרי טלפון מטקסט.

→שימוש ב-Azure AI Language PII detection API. הגדרת קטגוריות הישויות לזיהוי וקביעת מצב ההסתרה.

למה: זהו API ייעודי ל-PII, אמין ומקיף יותר מ-regex או NER גנרי למשימת ציות ספציפית זו.

חילוץ ישויות רפואיות, קשרים וטענות (לדוגמה, שלילה) מהערות קליניות.

→שימוש ב-Azure AI Health Insights, ובפרט בשירות Text Analytics for Health.

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

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

→שימוש ב-Azure Custom Translator. אימון מודל מותאם אישית באמצעות אוסף מסמכים מתורגמים קיימים שלך (מסמכים מקבילים).

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

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

→שימוש בשירות Azure AI Speech to Text עם תמלול שיחות ו-diarization מופעלים.

למה: Diarization היא התכונה הספציפית המפצלת אודיו לפי דובר, ומספקת מידע "מי אמר מה" יחד עם התמלול.

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

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

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

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

→שימוש ב-Speech Synthesis Markup Language (SSML) בבקשת ה-Text-to-Speech API.

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

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

→שימוש ב-Azure AI Search בשכבה Standard או גבוהה יותר. הרחבה עם Replicas לטיפול בעומס שאילתות ועם Partitions לטיפול בנפח נתונים.

למה: Replicas מיועדים לתפוקת שאילתות (QPS). Partitions מיועדים לגודל אינדקס וקלט/פלט. שניהם נחוצים לתרחישים בקנה מידה גדול וביצועים גבוהים.

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

→שימוש ב-Azure AI Search עם חיפוש סמנטי מופעל. שימוש בתכונות התשובות הסמנטיות וכותרות המשנה.

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

מקור↗

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

→הגדרת אינדקס Azure AI Search עם שדות טקסט הניתנים לחיפוש ושדות וקטוריים. ביצוע שאילתות היברידיות המשלבות פרמטרים של מילות מפתח (`search`) ווקטור (`vectorQueries`).

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

חילוץ ישויות בפורמט מותאם אישית, כמו קודי מוצר (XX-####), במהלך צינור ה-indexing של Azure AI Search.

→יצירת skillset מותאם אישית הקורא ל-Azure Function. הפונקציה מכילה את ה-regex או לוגיקה מותאמת אישית אחרת למציאת וחילוץ הישויות.

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

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

→יצירת מפת מילים נרדפות ב-Azure AI Search המגדירה את המונחים השקולים. שיוך מפת המילים הנרדפות לשדות הניתנים לחיפוש הרלוונטיים בהגדרת האינדקס.

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

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

→הפעלת שמירת מטמון של העשרה (enrichment caching) בתצורת האינדקסר. האינדקסר ישתמש אז בתוצאות השמורות במטמון עבור כישורים שלא השתנו ויריץ מחדש רק כישורים חדשים או ששונו.

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

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

→שימוש במודל מורכב ב-Azure AI Document Intelligence לחילוץ, Azure Function עבור לוגיקת אימות מותאמת אישית, ו-Azure Cosmos DB לאחסון. תיאום באמצעות Azure Logic Apps.

למה: ארכיטקטורת Serverless זו מפרידה נכון בין תחומי אחריות: Document Intelligence לחילוץ מיוחד, Functions ללוגיקה עסקית מותאמת אישית, ו-Logic Apps לתיאום תהליכי עבודה.

עיבוד חבילת מסמכים המכילה סוגי טפסים מרובים (לדוגמה, טופס תביעה, קבלות ותמונות) בעסקה יחידה.

→שימוש במודל מורכב של Azure AI Document Intelligence. אימון מודל סיווג לזיהוי סוג המסמך וניתובו למודל החילוץ המותאם אישית או המובנה המתאים.

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

הסתרת PII ממסמכים לפני שהם מאונדקסים על ידי Azure AI Search, כך שנתונים רגישים לעולם לא יאוחסנו באינדקס החיפוש.

→הוספת כישור PII Detection קוגניטיבי ל-skillset של האינדקסר. הגדרת הכישור למיסוך PII ומיפוי שדה הטקסט המוסתר לאינדקס.

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

הגברת תוצאות חיפוש בהתבסס על רעננות המסמך (תאריך פרסום) ופופולריות (מספר צפיות).

→הגדרת פרופיל ניקוד מותאם אישית ב-Azure AI Search. שימוש בפונקציית `freshness` על שדה התאריך ובפונקציית `magnitude` על שדה ספירת הצפיות.

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

צ'אטבוט של Azure OpenAI צריך לספק תגובות עקביות, ממוקדות ולא יצירתיות עבור תרחיש שירות לקוחות.

→הגדרת פרמטר ה-`temperature` לערך נמוך, כגון 0.1 או 0.2. יש להימנע מהגדרתו ל-0 בדיוק עבור רוב המודלים.

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

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

→יישום "חיתוך אבטחה" (security trimming) בשלב השליפה. ב-Azure AI Search, החלת מסנני אבטחה על שאילתת החיפוש בהתבסס על זהות ה-AAD של המשתמש וחברות בקבוצות.

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

חילוץ עקבי של נתונים מובנים מטקסט לא מובנה לאובייקט JSON תקף באמצעות Azure OpenAI.

→שימוש בפרומפט הכולל: 1) תפקיד ברור. 2) הוראה מפורשת להחזיר JSON בלבד. 3) סכימת ה-JSON הרצויה עם שמות שדות וסוגים. 4) דוגמאות Few-shot אם אפשר.

למה: פרומפטים מובנים ומפורשים ביותר מגבירים משמעותית את האמינות של קבלת פלט מובנה ובעל צורה טובה מ-LLMs.

יישום קריטי למשימה דורש תפוקה מובטחת ועקבית מ-Azure OpenAI, ללא הגבלה (throttling) בעת עומס שיא.

→רכיסה ופריסת המודל באמצעות Provisioned Throughput Units (PTU).

למה: PTUs מספקים קיבולת עיבוד מודלים ייעודית ושמורה, בניגוד לפריסות "שלם לפי שימוש" סטנדרטיות הפועלות על מודל קיבולת משותף וכפופות להגבלה (throttling).

מקור↗

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

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

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

הפעלת מודל Azure OpenAI לקרוא ל-API חיצוני כדי לקבל מידע על מזג האוויר הנוכחי.

→הגדרת ה-API ככלי עבור המודל באמצעות פורמט JSON Schema מדויק. כלול `description` פונקציה ברור ותיאורי `parameter` מפורטים כדי שהמודל יידע מתי וכיצד להשתמש בו.

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

שימוש ב-Azure OpenAI לסיכום מסמך שארוך בהרבה מחלון ההקשר של המודל.

→יישום אסטרטגיית "map-reduce" או "refine". פיצול המסמך ל"חלקים", יצירת סיכום לכל חלק (map), ולאחר מכן יצירת סיכום סופי מאוסף סיכומי החלקים (reduce).

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

שיפור התגובתיות הנתפסת של יישום צ'אט על ידי הצגת תגובת ה-AI בזמן שהיא נוצרת.

→בעת קריאה ל-Chat Completions API, הגדר את הפרמטר `stream` ל-`true`. עבד את ה-server-sent events כפי שהם מגיעים כדי לבנות את התגובה אסימון אחר אסימון.

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

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

→שימוש ב-framework כמו Semantic Kernel או Azure AI Agent Service. הגדר כל יכולת ככלי/תוסף נפרד ואפשר למתכנן של הסוכן או ללולאת ReAct לתאם את קריאות הכלים.

למה: Frameworks מבוססי סוכנים מספקים את שכבת התיאום (מתכנן/לולאת חשיבה) המאפשרת ל-LLM לעבור מעבר לשאלות ותשובות פשוטות ולהפוך לשחקן אוטונומי המשתמש בכלים.

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

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

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