נבדק לאחרונה: יוני 2026
מדריך מקוצר ובר-סריקה לדפוסי ארכיטקטורה שמבחן AI-103 בודק. קראו מלמעלה למטה, או דלגו לסעיף.
תכונת צ'אט פועלת בנפח גבוה עם תורות קצרים ופשוטים ותקציב הדוק של זמן אחזור ועלות.
פרוס SLM (מודל שפה קטן) כגון Phi מקטלוג המודלים של Foundry במקום LLM חזיתי.
למה: SLMs מפחיתים עלויות וזמני אחזור למשימות צרות; שמור LLMs גדולים לנימוק מורכב. התאם את גודל המודל למשימה, לא למותג.
agent יחיד חייב להסיק מסקנות מתמונות וטקסט שהועלו על ידי המשתמש בבקשה אחת.
בחר מודל multimodal (לדוגמה, משפחת GPT-4o) בקטלוג Foundry במקום לשרשר מודל ראייה ל-LLM מבוסס טקסט בלבד.
למה: מודלים multimodal מקוריים מקבלים תמונה וטקסט ב-prompt אחד; מודל מבוסס טקסט בלבד כופה העברה של כיתובים שגורמת לאובדן פרטים ויזואליים.
תשובות חייבות להיות מבוססות על מאגר ידע ארגוני פרטי, לא על האימון המוקדם של המודל.
בנה שכבת שליפה: אינדקס את הקורפוס ב-Azure AI Search עם vector embeddings ובסס את המודל באמצעות RAG על גבי אינדקס זה.
למה: Grounding מזריק הקשר נשלף וניתן לציטוט בהסקת מסקנות; fine-tuning אופה ידע באופן סטטי ואינו יכול לצטט או לעדכן בזול.
agent צריך לקרוא ל-APIs פנימיים מבוססי REST וגם לשלוף ממאגר מסמכים מאונדקס.
רשום את ה-APIs כ-agent tools (function/OpenAPI) וצרף את אינדקס AI Search כמקור ידע ל-agent של Foundry.
למה: Tools מקנים ל-agent יכולת פעולה; knowledge sources מקנים שליפה מבוססת. הם משטחי אינטגרציה נפרדים, לא אותו מחבר.
מספר צוותים זקוקים לתצורות agent, חיבורים ופריסות מבודדות תחת ניהול משותף.
השתמש ב-Foundry hub עם Foundry projects לכל צוות; כל project מגדיר את החיבורים, הפריסות והגישה שלו.
למה: ה-hub מרכז רשת, מדיניות ומשאבים משותפים; ה-project הוא יחידת סביבת העבודה עבור אפליקציה או צוות. אל תשתף project אחד בין צוותים.
אפליקציית ייצור זקוקה למיקום נתונים צפוי ולתפוקה שמורה עבור פריסת מודל.
השתמש בפריסת Standard (אזורית) או Provisioned Throughput (PTU) במקום פריסה Global עבור עומסי עבודה בעלי רגישות למיקום נתונים ותפוקה גבוהה.
למה: פריסות Global מנתבות לכל אזור לצורך קיבולת; Standard מקבע את האזור, ו-PTU שומר קיבולת לזמן אחזור יציב. בחר לפי צרכי מיקום נתונים ו-SLA.
הגדרות prompt ו-agent חייבות לעבור מפיתוח לייצור עם סקירה וגלגול חזרה.
אחסן הגדרות prompt flow / agent כקוד במאגר וקדם אותן דרך סביבות עם Azure DevOps או GitHub Actions pipelines.
למה: התייחס ל-prompts ולתצורת agent כאל artifacts מבוקרים בגרסאות; לעריכות ידניות בפורטל בסביבת ייצור אין תיעוד ביקורת או נתיב גלגול חזרה.
פיצוץ תנועה מפעיל שגיאות 429 כנגד פריסת מודל.
העלה את המכסה (quota) של TPM/RPM של הפריסה היכן שזמין, הוסף ניסיון חוזר בצד הלקוח עם exponential backoff, ושקול פריסת PTU עבור קיבולת מובטחת.
למה: Quota היא התקרה של tokens לדקה; backoff מרכך מצערות זמניות. הקמת משאבים כפולים ללא תכנון quota פשוט מעבירה את צוואר הבקבוק.
ההוצאה בלתי צפויה ונשלטת על ידי prompts ארוכים של RAG.
הגבל את ה-max output tokens, קצץ את ה-context שנשלף ל-top-k, שמור context מערכת שניתן לשימוש חוזר ב-cache, ועקוב אחר שימוש ב-tokens לכל פריסה ב-Azure Monitor.
למה: העלות משתנה עם input בתוספת output tokens; צמצום context ותפוקות הוא המנוף הישיר. החלפת אזור או SKU לעיתים רחוקות משנה את מחיר ה-token באופן משמעותי.
במהלך שבועות, איכות התשובות ונאמנות ה-grounding נראות מתדרדרות בייצור.
הרץ הערכות מקוונות רציפות ב-Foundry עבור groundedness, relevance ו-coherence על תעבורה חיה מדגמית והתראה על ירידות בציון.
למה: מנגנוני הערכה מתוזמנים מזהים סחיפה שאינך יכול לראות במדדי זמן אחזור גולמיים; לוחות מחוונים של CPU/latency לבדם לעולם אינם חושפים רגרסיה ב-grounding.
תשובות RAG מתיישנות מכיוון שמסמכים חדשים אינם נשלפים.
נטר את היסטוריית ההרצה וספירת המסמכים של Azure AI Search indexer; תזמן אינדוקס הדרגתי והתראה על הרצות indexer שנכשלו.
למה: איכות השליפה נשברת בשקט כאשר ה-indexer נכשל או מפגר; מדדי צד המודל נראים תקינים מכיוון שהפער נמצא ב-data pipeline.
אפליקציה חייבת לקרוא לפריסת מודל Foundry ללא סודות בתצורה.
הפעל managed identity באפליקציה והענק לה את התפקיד "Cognitive Services OpenAI User"; הזדהה באמצעות Entra ID tokens, לא API keys.
למה: אימות Entra ללא מפתחות מסיר סודות ניתנים להדלפה ומרכז RBAC; אחסון API keys, גם ב-Key Vault, עדיין משאיר מפתח לסיבוב והגנה.
תעבורת Foundry אסור שתעבור אי פעם דרך האינטרנט הציבורי.
הצב את משאב Foundry והתלויות מאחורי private endpoints, השבת גישה לרשת ציבורית, ופתור באמצעות private DNS zones.
למה: private endpoints מקבעים את התעבורה ל-VNet; רשימות IP מותרות ב-firewall עדיין מנתבות דרך public endpoints והן בידוד חלש יותר.
תגובות שנוצרו כוללות מדי פעם תוכן שנאה או אלימות.
החל Azure AI Content Safety filter בפריסה עם ספי סף חומרה מתאימים עבור קטגוריות שנאה, מיניות, אלימות ופגיעה עצמית.
למה: Content filters מסננים prompts והשלמות בצד השרת; הסתמכות רק על הוראת system-prompt ניתנת לעקיפה בקלות על ידי jailbreaks.
agent אוטונומי יכול לבצע פעולות בלתי הפיכות כגון הוצאת החזרים כספיים.
הגדר human-in-the-loop approval gate עבור tools בעלי השפעה גבוהה והגבל את ה-agent לקבוצת פעולות מאושרות מראש (allow-listed).
למה: מצבי אישור והגבלות גישה ל-tool מגבילים אוטונומיה; ל-agent אוטונומי בלתי מוגבל אין בלם על קריאת tool הרסנית.
מבקרי מערכת צריכים לראות אילו מקורות וקריאות tool יצרו תשובה נתונה.
הפעל tracing ב-Foundry (OpenTelemetry) כדי ללכוד prompts, ציטוטים שנשלפו, קריאות tool ותפוקות לכל בקשה.
למה: מעקבים מקצה לקצה מספקים מקוריות ויכולת שחזור; מדדי tokens מצטברים לבדם אינם יכולים לשחזר את שרשרת ההיגיון של תשובה בודדת.
שירות backend חייב לקרוא למודלים ול-agents המוגדרים ב-Foundry project.
השתמש ב-Azure AI Foundry SDK (AIProjectClient) עם string החיבור של הפרויקט ו-DefaultAzureCredential כדי לקבל clients של מודל ו-agent.
למה: ה-project client פותר חיבורים ופריסות באופן מרכזי; קידוד קשיח של endpoints ומפתחות לכל מודל עוקף את ניהול הפרויקט.
בנה אפליקציית שאלות ותשובות המבוססת על מסמכי מדיניות.
הטמע ואינדקס את המסמכים, שלוף top-k chunks לכל שאילתה, והעבר אותם כ-context להשלמת הצ'אט עם הוראת ציטוט מקורות.
למה: RAG שומר על הידע עדכני וניתן לציטוט ללא אימון מחדש; העברת הקורפוס המלא ל-prompt מפוצצת את חלון ה-context והעלות.
המודל חייב לחפש סטטוס הזמנה חי במהלך שיחה.
הגדר tool עם JSON schema, תן למודל להוציא קריאת tool, בצע אותה בצד השרת, והחזר את התוצאה למודל כדי שיסכם אותה.
למה: function/tool calling מאפשר למודל להפעיל מערכות אמיתיות באופן דטרמיניסטי; לבקש ממנו "לנחש" את הסטטוס מייצר בדיות.
משימה דורשת מספר קריאות tool תלויות לפני תשובה סופית.
הרץ לולאת שימוש ב-tool: הזן כל תוצאת tool בחזרה למודל וחזור על הפעולה עד שיחזיר הודעה סופית, עם הגבלת max-iteration.
למה: לולאות tool איטרטיביות תומכות בהיגיון רב-שלבי; מעגל יחיד אינו יכול לשרשר חיפושים תלויים, ולולאה ללא הגבלה יכולה לצאת משליטה.
לפני השקה, כמת את התדירות שבה אפליקציית RAG "מדמיינת" (hallucinates) או סוטה מהנושא.
הרץ Foundry evaluators עבור groundedness, relevance ו-coherence על סט נתונים לבדיקה מתויג ושחרור שער על ספי ציון.
למה: מנגנוני הערכה מובנים מספקים אותות איכות ובטיחות מדידים; סקירת מספר דגימות בלבד אינה מזהה בדיות שיטתיות.
הגדר agent תמיכה עם פרסונה, מטרות וגבולות ברורים.
הגדר את הוראות המערכת של ה-agent (תפקיד, מטרות, כללי סירוב) וצרף רק את ה-tools שהוא צריך עבור היקפו.
למה: הוראות הדוקות בתוספת גישה מינימלית ל-tools שומרות על ה-agent ממוקד במשימה; הוראות רחבות וכל tool מזמינות זחילה בהיקף ופעולות לא בטוחות.
agent חייב לזכור context לאורך תורות בתוך סשן.
השתמש ב-threads של Foundry Agent Service, שמתמידים את היסטוריית ההודעות לכל שיחה כך שכל הרצה רואה תורות קודמים.
למה: threads מספקים זיכרון שיחה מנוהל; שליחה חוזרת ידנית של כל התמליל בכל קריאה היא שבירה וקל לקטוע באופן שגוי.
agent זקוק ל-web grounding ולביצוע קוד ללא צורך בפיתוח מותאם אישית.
צרף built-in Foundry agent tools כגון Grounding with Bing Search ו-Code Interpreter במקום לבצע אינטגרציות ידניות.
למה: tools מנוהלים נשלטים ונתמכים מחוץ לקופסה; מימושים מותאמים אישית מוסיפים תחזוקה ומדלגים על בקרות בטיחות של הפלטפורמה.
agent ראשי צריך להאציל שאלות חיוב ל-agent חיובים מומחה.
השתמש ב-connected agents: חשוף את agent החיובים כ-tool שה-agent הראשי יכול לקרוא לו, כך שהוא מנתב משימות משנה למומחים.
למה: connected agents מאפשרים האצלה היררכית; דחיסת כל תחום ל-mega-agent אחד מנפחת הוראות ומדרדרת דיוק.
workflow זקוק למתכנן, חוקר וכותב המשתפים פעולה עם מצב משותף.
תזמר אותם עם framework מסוג multi-agent (Semantic Kernel / AutoGen ב-Foundry) באמצעות תבנית תזמור מוגדרת ו-context משותף.
למה: Frameworks מנהלים תורות, מצב וסיום; העברת strings אד-הוק בין agents חסרה תיאום או תנאי עצירה.
agent פועל ללא השגחה במשך הלילה ואסור לו לבצע פעולות מסוכנות לבדו.
הגבל אותו עם tools מאושרים מראש (allow-listed), תקציבים לכל פעולה, content filters, ו-checkpoint שמסלים צעדים בעלי השפעה גבוהה לאישור.
למה: הגנות מרובות שומרות על אוטונומיה בטוחה; לולאה אוטונומית עם גישה מלאה ל-tools וללא אישור יכולה לגרום נזק בלתי הפיך.
agent נכשל לסירוגין באמצע משימה ועליך למצוא את השלב הכושל.
בדוק את השלבים המועקבים (traced steps) וקלט/פלט של קריאות tool בהרצה ב-Foundry כדי לאתר את ה-tool הכושל או הארגומנט שאינו תקין.
למה: מעקבים ברמת השלב מאתרים היכן הרצה נכשלה; הודעת שגיאה סופית יחידה מסתירה איזו קריאת tool או שלב הנמקה נכשל בפועל.
תפוקות אינן עקביות ומתעלמות מהוראות עיצוב.
השתמש בהודעת מערכת ברורה, דוגמאות few-shot והגבלות פלט מפורשות; לצורה מחמירה, אפשר structured outputs / JSON schema.
למה: prompting מובנה ותפוקות עם אכיפת schema הופכים את התוצאות לאמינות; העלאת temperature או ניסיון חוזר בעיוורון לא יתקנו את הציות להוראות.
משימת יצירת תוכן נשמעת חוזרת מדי; משימת חילוץ נתונים אקראית מדי.
העלה את ה-temperature/top-p עבור המשימה היצירתית והורד אותם לכיוון 0 עבור חילוץ כדי להפוך אותה לדטרמיניסטית.
למה: פרמטרי דגימה מאזנים מגוון מול דטרמיניזם; החלפת מודלים היא מוגזמת כאשר הגדרת הפרמטר היא הסיבה האמיתית.
agent לוגיקה מבצע שגיאות לוגיות הניתנות למניעה במשימות קשות.
הוסף שלב reflection / self-critique שבו ה-agent סוקר ומתקן את טיוטתו, או השתמש במודל הנמקה עבור השלב.
למה: Chain-of-thought ו-self-critique משפרים דיוק במשימות קשות; מעבר קדימה בודד לא נותן סיכוי לתפוס את הטעות שלו.
צוות התפעול זקוק למידע על הוצאת tokens, זמן אחזור ואותות בטיחות לכל בקשה בסביבת ייצור.
פלוט OpenTelemetry traces ומדדים מהאפליקציה ל-Azure Monitor / Application Insights, תוך לכידת tokens, זמן אחזור ודגלי content-safety.
למה: Unified observability קושר עלות, ביצועים ובטיחות יחד; גירוד לוגים ידני אינו יכול לתאם תור איטי עם שימוש ה-tokens שלו.
אפליקציה אחת משלבת סיווג זול עם הנמקה מורכבת מדי פעם.
תזמר מספר פריסות: נתב תורות פשוטים ל-SLM והסלם תורות קשים ל-LLM חזיתי מאחורי שכבת אפליקציה אחת.
למה: ניתוב מודלים מייעל עלות ואיכות לכל תור; שימוש במודל פרימיום אחד לכל דבר משלם יתר על המידה עבור הרוב הקל.
אפליקציית שיווק חייבת לייצר תמונות מקוריות מ-text prompts.
פרוס מודל יצירת תמונות (לדוגמה, DALL-E / GPT-image בקטלוג Foundry) וקרא לו עם ה-text prompt ופרמטרי גודל.
למה: מודלים גנרטיביים לתמונות מסנתזים תמונות חדשות; ה-Image Analysis (vision) API רק מתאר תמונות קיימות, הוא אינו יכול ליצור אותן.
החלף רק את הרקע של תמונת מוצר קיימת, תוך שמירה על המוצר שלם.
השתמש ב-endpoint של עריכת תמונה (inpainting) עם תמונת המקור בתוספת mask שמסמן רק את האזור הניתן לעריכה.
למה: mask מגביל עריכות לאזור הצבוע; קריאת text-to-image פשוטה יוצרת מחדש את כל המסגרת ומאבדת את המוצר המקורי.
הפק קטעי וידאו קצרים שנוצרו מתיאור טקסטואלי.
השתמש במודל text-to-video כגון Sora בקטלוג Foundry עם prompt, duration ופרמטרי רזולוציה.
למה: יצירת וידאו היא משפחת מודלים נפרדת; מודלי תמונה פולטים פריימים בודדים ואינם יכולים לייצר תנועה זמנית.
משתמשים שואלים שאלות חופשיות לגבי תמונת תרשים שהועלתה.
שלח את התמונה בתוספת השאלה ל-multimodal LLM (GPT-4o) עבור מענה חזותי לשאלות ותשובה בשפה טבעית.
למה: צ'אט multimodal מטפל ב-QA ויזואלי פתוח; תיוג תמונות בטקסונומיה קבועה מחזיר תוויות, לא תשובות לשאלות שרירותיות.
צור אוטומטית טקסט alt תיאורי לאלפי תמונות לצורך נגישות.
השתמש ביכולת ה-caption / dense-captions של Image Analysis כדי לייצר תיאורים קריאים לבני אדם בקנה מידה רחב.
למה: captioning מניב טקסט alt תמציתי ישירות; object detection מחזיר תיבות תוחמות שעדיין צריך להפוך לטקסט.
חלץ שדות מובנים ותובנות ברמת הפלח מסרטוני וידאו מוקלטים ארוכים.
השתמש ב-Azure AI Content Understanding עם video analyzer כדי לקבל פלט מובנה, מוגדר על ידי schema, לאורך ציר הזמן.
למה: Content Understanding מפיק פלט מובנה מבוסס על פני modalities; קריאות תמונה פריימים-אחר-פריימים אינן מספקות מבנה מודע לציר זמן.
agent multimodal קורא תמונות משתמש שעשויות להכיל טקסט הוראות נסתר.
אפשר prompt shields / indirect-injection detection והתייחס לטקסט בתוך תמונות כנתונים לא מהימנים, לא כהוראות.
למה: טקסט תמונה מוטמע הוא וקטור classic prompt-injection עקיף; העברת טקסט מ-OCR ישירות ל-system prompt מאפשרת לתוקפים לחטוף את ה-agent.
שלף שמות, תאריכים וסכומים מאימיילים לרשומת JSON מוגדרת טיפוס.
תן prompt ל-LLM עם JSON schema יעד ואפשר structured outputs כך שכל שדה יוחזר בצורה קבועה.
למה: חילוץ LLM מוגבל על ידי schema מטפל בפורמטים פתוחים ומבטיח JSON שניתן לניתוח; regex שביר נשבר על מגוון שפה טבעית.
הפק סיכום תמציתי ומשוכתב של תמלילי תמיכה ארוכים.
השתמש ב-LLM עבור abstractive summarization עם הוראת אורך ומיקוד, או בכישרון הסיכום של שירות השפה.
למה: סיכומים abstractive מפרפרזים את העיקר; בחירת משפטים extractive רק מעתיקה משפטים ויכולה להחמיץ את הנקודה הכוללת.
סווג הודעות לקוחות לפי sentiment וסמן טון אגרסיבי.
השתמש ב-LLM (או ב-Language sentiment API) כדי לתייג קוטביות ולזהות טון, תוך החזרת קטגוריה ורמת ביטחון.
למה: ניתוח sentiment/tone הוא משימת סיווג עם תוויות מוגדרות; יצירת טקסט חופשי ללא label schema קשה לניתוב בהמשך.
תרגם נפחים גבוהים של מחרוזות ממשק משתמש במדויק ובזול על פני 30 שפות.
השתמש ב-Azure AI Translator לתרגום המוני ודטרמיניסטי; שמור LLM לקטעים עשירים בניואנסים ועתירים context.
למה: Translator בנוי למטרה, זול יותר ועקבי בקנה מידה; LLM לכל מחרוזת עולה יותר ויכול לסטות בטון בין הרצות.
agent קולי חייב לתמלל אודיו של מתקשרים בזמן אמת.
השתמש ב-Speech service real-time speech-to-text (או fast transcription) כדי להזין טקסט ל-pipeline של ה-agent.
למה: Streaming STT מספק תמלילים חלקיים עם זמן אחזור נמוך לשיחות חיות; batch transcription מיועד לקבצים לא מקוונים, לא לתורות חיים.
תמלול שומע לא נכון שמות מוצרים וז'רגון רפואי.
אמן Custom Speech model עם אודיו מתחום ורשימות ביטויים כדי לשפר את זיהוי אוצר מילים מיוחד.
למה: Custom Speech מתאים את המודל האקוסטי/שפה למונחים שלך; למודל הבסיס אין חשיפה לז'רגון הפרטי שלך.
ה-agent חייב להשיב עם אודיו מדובר בעל צליל טבעי.
השתמש ב-neural Text to Speech עם קול מתאים ו-SSML כדי לשלוט בפרוזודיה, הפסקות והגייה.
למה: Neural TTS בתוספת SSML מניב דיבור חי, שניתן לשלוט בו; טקסט רגיל ללא SSML נותן ניסוח שטוח על מספרים ושמות.
שליפת vector-only מפספסת התאמות מדויקות של מילות מפתח ומזהי קוד.
השתמש ב-hybrid search ב-Azure AI Search (vector בתוספת keyword) עם semantic ranking כדי לסדר מחדש את התוצאות הממוזגות.
למה: Hybrid בתוספת semantic reranking עולה על כל אחד מהאותות לבדו; pure vector search יכול לפספס מונחים מילוליים, pure keyword מפספס פרפרזה.
הקורפוס כולל קובצי PDF סרוקים שהטקסט שלהם אינו ניתן לבחירה.
הוסף OCR cognitive skill (Document Intelligence / Vision) ל-indexing skillset כך שטקסט סרוק יחולץ לפני chunking ו-embedding.
למה: העשרת OCR חושפת טקסט מתמונות לשליפה; אינדוקס ה-PDF הסרוק הגולמי אינו מניב דבר שניתן לחיפוש.
במהלך ingestions אתה זקוק ל-OCR, חילוץ ביטויים מרכזיים, ותרגום המיושמים לכל מסמך.
הגדר AI Search skillset המשרשר את ה-cognitive skills הנדרשים, ומקרין תפוקות לשדות אינדקס שה-indexer מאכלס.
למה: skillset מתזמר באופן דקלרטיבי העשרה בזמן האינדוקס; ביצוע זאת בקוד האפליקציה לכל שאילתה חוזר על עבודה ושובר שימוש חוזר.
אתה רוצה ש-chunking ו-embedding יטופלו בתוך ה-index pipeline, לא בקוד האפליקציה.
השתמש ב-AI Search integrated vectorization כדי לפצל מסמכים ולקרוא למודל embedding במהלך האינדוקס ובזמן השאילתה.
למה: integrated vectorization שומר על עקביות chunking/embedding בין ingest לשאילתה; embedding מותאם אישית בצד הלקוח מסכן אי-התאמה של מודל.
חלץ שדות מובנים מחשבוניות בעלות פריסות מגוונות.
השתמש ב-Document Intelligence prebuilt invoice model, או אמן מודל מותאם אישית, כדי להחזיר שדות מוגדרים טיפוס עם רמת ביטחון ואזורי תחימה.
למה: Document Intelligence מבין layout ומחזיר שדות מוגדרים טיפוס; dump של OCR בלבד נותן טקסט גולמי ללא סמנטיקת שדות.
אתה זקוק לייצוג markdown נקי ומבוסס של מסמכים מעורבים עבור RAG.
השתמש ב-Content Understanding analyzers כדי לייצר פלט מובנה / markdown השומר על כותרות, טבלאות ו-field grounding.
למה: Grounded markdown שומר על מבנה וציטוטים לשליפה; טקסט רגיל שטוח מאבד טבלאות ו-section context שהמודל זקוק להם.
agent של Foundry חייב לשלוף מאינדקס החיפוש המועשר שלך בזמן ריצה.
הוסף את אינדקס AI Search כמקור ידע / tool ל-agent כך שכל הרצה תבסס תשובות בתוצאות שנשלפו וצוטטו.
למה: חיבור האינדקס כ-agent tool נותן שליפה מבוססת חיה; הדבקת קטעים סטטיים להוראות אינה יכולה להישאר מעודכנת עם הקורפוס.