נבדק לאחרונה: יוני 2026
מדריך מקוצר ובר-סריקה לדפוסי ארכיטקטורה שמבחן NCP-AAI בודק. קראו מלמעלה למטה, או דלגו לסעיף.
בחירה בין סוכן יחיד למערכת מרובת סוכנים עבור תהליך עבודה מורכב.
ברירת מחדל היא סוכן יחיד עם כלים. פצל למספר סוכנים רק כאשר גבולות המשימות ברורים, הקונטקסט עולה על גדותיו, או כאשר רמות מודלים שונות מתאימות למשימות משנה שונות.
למה: כל סוכן נוסף מכפיל את זמן ההשהיה, משטח השגיאות ועלות התזמור; רוב עומסי העבודה מצליחים עם סוכן אחד מצויד היטב.
המתזמר חייב לשלוח משימות משנה הטרוגניות למומחים.
השתמש בסוכן מפקח שמפרק את המטרה, מנתב לסוכני עבודה עם הנחיות וכלים משלהם, ומאגד תוצאות.
למה: שליטה מרכזית שומרת על מצב עקבי והופכת את גבול ההחלטה לניתן לביקורת לעומת נחיל חופשי לכל.
לזרימת ה-agent יש ענפים מותנים, לולאות והתפצלות מקבילה (parallel fan-out).
מַדֵּל את תהליך העבודה כגרף מפורש של צמתים וקצוות במקום לולאה חופשית, כך שזרימת הבקרה תהיה דטרמיניסטית וניתנת לחידוש.
למה: גרף מאפשר בדיקה של ענפים ומאפשר לך ליצור נקודות ביקורת (checkpoint) ולשחזר מכל צומת לאחר כשל.
בקשות נכנסות משתנות באופן נרחב בסוגן ובעלותן.
מקם לפני המערכת סוכן נתב קל משקל שמסווג כוונות ושולח לסוכן או כלי היכולים לבצע את המשימה בעלות הנמוכה ביותר.
למה: ניתוב מונע תשלום עלות frontier-model לבקשות טריוויאליות ומבודד חששות לכל נתיב.
מספר סוכנים חייבים לקרוא ולכתוב מצב תהליך עבודה משותף.
העבר את המצב לאחסון משותף חיצוני (מפתח-ערך או מסמך) שמקודד לפי סשן, במקום להעביר את התמליל המלא בין סוכנים.
למה: אחסון משותף מגביל את צמיחת הקונטקסט ומונע עותקים מגוונים של מצב בין סוכנים.
תכנון סוכנים להרחבה אופקית.
שמור על חישוב ה-agent כחסר מצב (stateless); שמור שיחה וזיכרון באופן חיצוני כך שכל עותק יוכל לטפל בכל בקשה.
למה: צמתים חסרי מצב מבצעים הרחבה אוטומטית נקייה ושורדים הפעלות מחדש של pods מבלי לאבד עבודה בתהליך.
סוכן משנה או כלי נכשלים באמצע תהליך העבודה.
תכנן צעדים אידמפוטנטיים עם ניסיון חוזר/השהיה הולכת וגוברת, פעולות פיצוי לתופעות לוואי, ונתיב חלופי או הסלמה אנושית כאשר הניסיונות החוזרים נגמרים.
למה: מערכות מבוססות agent נכשלות באופן חלקי; התאוששות חייבת להיות שיקול עיצובי מרכזי, לא מחשבה בדיעבד.
סוכני משנה מפותחים על ידי צוותים נפרדים.
הגדר את חוזה הקלט/פלט של כל agent כסכימה מוגדרת וטפל בסוכנים כשירותים מאחורי ממשקים יציבים.
למה: חוזים מפורשים מאפשרים לסוכנים להתפתח באופן עצמאי ולהיבדק ביחידות בנפרד.
איכות הפלט של הסוכן אינה עקבית במשימות קשות.
הוסף שלב ביקורת/רפלקציה שבודק את הטיוטה מול קריטריונים ומפעיל ניסיון חוזר מוגבל לפני החזרה.
למה: ביקורת עצמית תופסת שגיאות בזול, אך הגבל את האיטרציות כדי למנוע לולאות בלתי נשלטות ועלויות.
ה-agent חייב לקיים אינטראקציה עם APIs חיצוניים, מסדי נתונים או קבצים.
חשוף יכולות כהגדרות פונקציות/כלים מוגדרות; המודל פולט קריאת כלי, הקוד שלך מבצע אותה ומחזיר את התוצאה, ואז הלולאה ממשיכה.
למה: קריאת כלי מובנית אמינה יותר וניתנת לביקורת מאשר ניתוח הוראות בטקסט חופשי.
ה-agent חייב להסיק מסקנות לגבי תצפיות לפני שהוא פועל שוב.
יישם לולאת ReAct: המודל מייצר מחשבה, בוחר כלי, מקבל את התצפית, וחוזר על הפעולה עד לעמידה בתנאי עצירה.
למה: שילוב חשיבה ופעולה חושף את השרשרת לניפוי באגים ומשפר את הדיוק בריבוי שלבים.
המודל משתמש לרעה או מדמיין (hallucinates) ארגומנטים של כלים.
כתוב תיאורים מדויקים של כלים, הגבל סוגי ארגומנטים ו-enums, וספק דוגמה אחת או שתיים לשימוש לכל כלי.
למה: רוב שגיאות קריאת הכלים נובעות מסכימות מעורפלות; התיאור הוא ה-prompt עבור הכלי.
קוד במורד הזרם (downstream) זקוק ל-JSON אמין מה-agent.
הגבל את היצירה לסכימת JSON (פלט מובנה) במקום לנתח טקסט חופשי, ובדוק תקינות לפני השימוש.
למה: פענוח מוגבל על ידי סכימה מבטל ניתוח regex שביר וסטייה שקטה בפורמט.
בניית agent בסביבת ייצור על גבי ערימת NVIDIA.
השתמש ב-NeMo Agent Toolkit כדי להרכיב agents, tools, ותהליכי עבודה, ולחבר קריאות מודלים לקצה האחורי (backends) המוגש על ידי NIM.
למה: ה-toolkit מתקנן את הצינורות (plumbing) של ה-agent ומשתלב באופן טבעי עם שירותי NVIDIA.
כלי מחזיר שגיאה או פג זמן.
החזר את השגיאה בחזרה למודל כתוצאה של הכלי כדי שיוכל לנסות שוב, להתאים ארגומנטים או לבחור נתיב חלופי.
למה: חשיפת כשלים ל-agent מאפשרת התאוששות; בליעתם משאירה את ה-agent עיוור.
נדרשות מספר קריאות כליות עצמאיות בשלב אחד.
בצע קריאות כליות במקביל כאשר המודל תומך בכך ואין תלות בסדר הקריאות, ולאחר מכן מיזג את התוצאות.
למה: ביצוע מקבילי מקצר את זמן ההשהיה הכולל (wall-clock latency) לעבודת fan-out כמו בדיקות מרובות מקורות.
יכולת מומחה צריכה להיות ניתנת לשימוש חוזר בתהליכי עבודה שונים.
עטוף סוכן משנה מאחורי ממשק כלי יחיד כך שההורה יפעיל אותו כמו כל כלי אחר.
למה: התייחסות לסוכני משנה ככלים שומרת על אחידות ההרכבה ומסתירה מורכבות פנימית.
ה-agent סוטה מהמשימה או מתעלם ממגבלות.
קבע את התפקיד, הכלים המותרים, פורמט הפלט והמגבלות הקשות ב-system prompt תמציתי; חזור על כללים קריטיים לקראת הסוף.
למה: system prompt הדוק הוא הבקרה הזולה ביותר והיעילה ביותר על התנהגות ה-agent.
מדידת האם סוכן פתר משימה רבת-שלבים כראוי.
הערך גם את התשובה הסופית וגם את המסלול - דיוק קריאת הכלי, סדר השלבים ופעולות מיותרות - אל מול סט מסומן.
למה: תשובה נכונה ממסלול שגוי היא שברירית; ניקוד מסלול תופס כשלים סמויים.
אין תוויות אמת (ground-truth labels) לפלטים פתוחים של agents.
השתמש ב-LLM-as-judge עם קריטריונים לניקוד פלטים, מכויל אל מול מדגם קטן המסומן על ידי אדם.
למה: מודלי שופט מרחיבים את ההערכה, אך חייבים להיות מכוילים אחרת הם מקודדים את ההטיה שלהם.
עליך לתפוס רגרסיות לפני כל שחרור גרסה.
בנה סביבת בדיקה (eval harness) לא מקוונת עם חבילת תרחישים קבועה שרצה על כל שינוי ומונעת פריסות על סף מעבר.
למה: התנהגות ה-agent משתנה בעדינות עם שינויים ב-prompt או במודל; חבילת רגרסיה היא רשת הביטחון.
ה-agent בוחר את הכלי הלא נכון או ארגומנטים שגויים.
עקוב אחר דיוק/רקורסיה של בחירת כלי ותוקף ארגומנטים כמדדים עצמאיים, לא רק הצלחת המשימה הסופית.
למה: בידוד שכבת קריאת הכלי מאתר אם כשלים נובעים מבחירה או מהסכימה.
שיעור המעבר בהערכה ירד לאחר שינוי.
בדוק מסלולים מלאים של מקרים כושלים, קבץ מצבי כשל, ותקן תחילה את הקבוצה הדומיננטית.
למה: ציונים מצטברים מסתירים את שורש הבעיה; קיבוץ לפי עקבות חושף את הפגם האמיתי.
ה-agent מתפקד פחות מהצפוי ועליך לשפר אותו.
חזור על prompts ותיאורי כלים תחילה; עבור למודל גדול יותר או ל-fine-tuning רק כאשר שינויים ב-prompt מגיעים לרוויה.
למה: איטרציית Prompt מהירה וזולה; החלפת מודל מוסיפה עלות וצריכה להיות מונעת מראיות.
השוואת שני עיצובי agent ששניהם עומדים ביעדי דיוק.
הוסף עלות למשימה וזמן השהיה p95 להערכה כך שהעיצוב הזול והמהיר יותר ינצח במצבי תיקו.
למה: כדאיות ייצור היא דיוק בתוספת עלות בתוספת זמן השהיה, לא רק דיוק לבדו.
הגשת הסקת מודלים עבור agents בסביבת ייצור.
פרוס מודלים כ-NIM microservices, מה שמעניק ל-agents נקודת קצה (endpoint) סטנדרטית, מואצת GPU להסקה עם batching מובנה.
למה: NIM אורז הסקה אופטימלית מאחורי API יציב כך ש-agents אינם צריכים לנהל פרטי שירות פנימיים.
תעבורת ה-agent קופצנית ובלתי צפויה.
הפוך את ה-agents והשירות ל-containers, הפעל על Kubernetes, ובצע autoscale על בסיס במקביליות או ניצול GPU עם גבולות מינימום/מקסימום הגיוניים.
למה: Autoscaling סופג עליות תלולות בעוד שמינימום עותקים מונע זמן השהיה של אתחול קר (cold-start latency) בנתיב הקריטי.
עלות הסקת ה-GPU גבוהה מדי תחת עומס.
אפשר batching דינמי/רציף בשכבת ה-NIM כדי להעלות tokens-per-GPU-second לפני הוספת חומרה.
למה: Batching משפר באופן דרמטי את ניצול ה-GPU; הרחבת צמתים קודם מבזבזת קיבולת.
Agents מפעילים קריאות כליות ומודלים מקביליות ללא גבולות.
החל הגבלות מקביליות לכל agent ולכלל המערכת עם תור כך שהמערכת תתדרדר בחן תחת עומס.
למה: Unbounded fan-out מרוקן את מכסת ה-GPU והמכסות במורד הזרם, וגורם לכשלים.
בחירת חומרת GPU עבור עומס עבודה של הסקת agent.
התאם את הגודל לטביעת הרגל של המודל וליעדי זמן ההשהיה - H100 למודלים גדולים ומוכרים, Blackwell היכן שרוחב פס זיכרון ותפוקת חשיבה שולטים.
למה: התאמת החומרה למודל מונעת גם תת-הקצאה וגם תשלום עבור קיבולת סרק.
שליחת גרסת agent או מודל חדשה בבטחה.
פרוס באמצעות canary לפרוסת תעבורה קטנה, השווה מדדים חיים מול קו הבסיס, ואז התקדם או בטל פריסה.
למה: שינויים בהתנהגות ה-agent קשים לניבוי מלא במצב לא מקוון; canary מגביל את רדיוס הפגיעה.
שרשרות agent ארוכות מסכנות בקשות תלויות.
הגדר תקציבי פסק זמן לכל שלב ולכל אורך התהליך; בטל וחזור אחורה כאשר חורגים מהם.
למה: ללא תקציבים, כלי איטי יחיד יכול לתפוס חריץ GPU ולמנוע ממשאבים מבקשות אחרות.
משימה דורשת צעדים רבים ותלויים זה בזה.
השתמש בתבנית תכנון וביצוע: צור תוכנית מפורשת תחילה, ואז בצע את הצעדים, וצור תוכנית מחדש כאשר הנחה כלשהי נשברת.
למה: תכנון מוקדם מפחית נדידה ומספק נקודת ביקורת לאימות לפני ביצוע קריאות כלים.
איכות הפירוק היא צוואר הבקבוק.
נתב את שלב התכנון למודל חשיבה Nemotron תוך שימוש במודלים זולים יותר לביצוע.
למה: השקיע חישוב ברמת חשיבה היכן שזה חשוב - התוכנית - לא בכל משימת משנה שגרתית.
ה-agent חייב לזכור עובדות לאורך סשן ארוך.
שמור פניות אחרונות בקונטקסט העבודה; שמור עובדות עמידות במאגר זיכרון לטווח ארוך שיאוחזרו לפי דרישה.
למה: הכנסת הכל לתוך הקונטקסט מגדילה את העלות וזמן ההשהיה ובסופו של דבר עולה על גדות החלון.
בחירה כיצד לאחסן זיכרון של agent.
אחסן היסטוריית אינטראקציות אפיזודיות בנפרד מעובדות סמנטיות; אחזר זיכרון סמנטי לפי דמיון, אפיזודי לפי תדירות/סשן.
למה: דפוסי גישה שונים דורשים אחסונים שונים; דלי אחד מאחזר גרוע עבור שניהם.
שיחה ארוכה מתקרבת למגבלת הקונטקסט.
סכם פניות ישנות יותר לסיכום מתמשך קומפקטי ושחרר היסטוריה גולמית, ושמור רק פניות אחרונות מילה במילה.
למה: סיכום מתגלגל שומר על רציפות תוך הגבלת עלות האסימונים ומניעת שגיאות קיטוע.
ה-agent חייב לבסס תשובות בנתונים ארגוניים פרטיים.
תן ל-agent כלי אחזור מעל מאגר וקטורים כך שהוא יחליט מתי ומה לאחזר, במקום להקדים תמיד את הקונטקסט.
למה: אחזור סוכני מביא נתונים רק כשצריך, מה שמקצץ אסימונים וקונטקסט לא רלוונטי.
בניית צינור אחזור איכותי על NVIDIA.
השתמש ב-NeMo Retriever embedding וב-reranking NIM microservices עבור RAG מואץ וברמת ייצור.
למה: NeMo Retriever מספק מודלי embedding/rerank מכווננים המוגשים ביעילות על GPU.
חיפוש וקטורי טהור מפספס שאילתות התאמה מדויקת ומילות מפתח.
שלב חיפוש וקטורי צפוף עם אחזור דליל/מילות מפתח ובצע rerank למועמדים הממוזגים.
למה: אחזור היברידי משחזר מונחים מדויקים (מזהים, קודים) שהטמעות (embeddings) מטשטשות.
יחידות המידע (chunks) שאוחזרו גסות מדי או מפוצלות מדי.
חלק ליחידות מידע בגבולות סמנטיים עם חפיפה מתונה וצרף מטא-נתונים; כוונן את הגודל למודל ה-embedding ולסוג השאילתה.
למה: גרעיניות יחידות המידע מניעה ישירות את רלוונטיות האחזור; שני הקצוות מורידים את איכות הביסוס (grounding).
ה-agent מחזיר מידע מיושן מהאינדקס.
בצע מחדש אינדוקס הדרגתי על שינויי מקור וחתום מסמכים עם חותמות זמן לדירוג המודע לרעננות (recency-aware ranking).
למה: ללא טיפול ברעננות, RAG מבסס בביטחון תשובות בנתונים מיושנים.
בחירת קצה אחורי (backend) למודל עבור חשיבת agent.
בחר מודל Nemotron בגודל המתאים לעומס החשיבה והגש אותו דרך NIM עבור נקודת קצה (endpoint) סטנדרטית.
למה: גרסאות החשיבה של Nemotron מכוונות לתכנון סוכני ושימוש בכלים; NIM מתקנן את ההגשה.
מיפוי צורך סוכני לרכיב NVIDIA הנכון.
השתמש ב-NeMo Agent Toolkit לתזמור, NIM להגשה, NeMo Retriever עבור RAG, NeMo Guardrails לבטיחות, ו-Nemotron לחשיבה.
למה: ידיעה איזה רכיב אחראי על איזה עניין היא שאלה חוזרת במבחן והחלטת תכנון.
הרכבת יישום agent מקצה לקצה על NVIDIA.
הרכב NIM microservices נפרדים (LLM, embedding, rerank, guardrails) מאחורי שכבת ה-agent, והרחב כל אחד באופן עצמאי.
למה: פירוק ל-microservices מאפשר לכל יכולת להתאים את קנה המידה והגרסה שלה באופן עצמאי.
כללי מגורי נתונים אוסרים שליחת נתונים ל-APIs חיצוניים.
ארח בעצמך את NIM microservices על תשתית GPU בבעלותך כך שהמודלים והנתונים יישארו בתוך הגבולות.
למה: האריזה הניידת של NIM תומכת בפריסה מקומית (on-prem) העומדת בדרישות מגורי נתונים.
agent בסביבת ייצור מתנהג באופן שגוי ועליך לאבחן אותו.
הפק מעקבים מבוזרים שכוללים כל קריאת מודל, קריאת כלי והחלטה, ואז בדוק את המסלול הכושל מקצה לקצה.
למה: כשלי agent הם רב-שלביים; ללא עקבות מלאים אינך יכול לאתר היכן השתבשה החשיבה.
הוצאת אסימוני agent וזמן ההשהיה עולים בהדרגה לאורך זמן.
עקוב אחר אסימונים, עלות, וזמן השהיה p95 לכל agent ולכל כלי, עם התראות על חריגה מספים.
למה: עלות וזמן השהיה נסחפים בשקט ככל שה-prompts והתעבורה מתפתחים; מדדים תופסים זאת מוקדם.
האיכות יורדת בהדרגה ללא שינויים בקוד.
הרץ את חבילת ההערכה באופן רציף מול דוגמאות ייצור והתראה על סחף מדדים מקו הבסיס.
למה: סחף נתונים ומודלים במעלה הזרם שוחק את האיכות באופן בלתי נראה בין גרסאות.
ה-agent חייב להישאר בנושא ולסרב לבקשות לא בטוחות.
החל NeMo Guardrails עם מגבלות קלט, פלט, נושא ודיאלוג סביב ה-agent.
למה: מגבלות ניתנות לתכנות אוכפות מדיניות באופן בלתי תלוי, וכרשת ביטחון, להתנהגות המודל עצמו.
תוכן לא מהימן עלול לחטוף את ה-agent באמצעות נתונים מאוחזרים או נתוני כלים.
התייחס לכל תוכן חיצוני כלא מהימן, בודד אותו מהוראות, והגבל את סמכות הכלי כך שפקודות שהוזרקו לא יוכלו להסלים.
למה: הזרקה מנצלת את כוחו של ה-agent; ההגנה היא עקרון ההרשאה המינימלית בתוספת הפרדת הוראות/נתונים.
ה-agent מטפל בנתונים מוסדרים או אישיים.
הסר או בצע טוקניזציה ל-PII לפני קריאות מודל וכתוב יומני ביקורת עמידים בפני שינויים (tamper-evident audit logs) של פעולות ה-agent והפעלות כלים.
למה: ציות דורש גם מזעור חשיפה וגם הוכחה למה שה-agent עשה.
ה-agent יכול לבצע פעולות בסיכון גבוה כמו תשלומים או מחיקות.
הכנס שער אישור אנושי לפני קריאות כליות בלתי הפיכות או בעלות השפעה גבוהה, והשהה את תהליך העבודה עד לאישור.
למה: אוטונומיה מתאימה לשלבים הפיכים; פעולות משמעותיות דורשות אדם בלולאה.
ה-agent אינו בטוח או נכשל שוב ושוב במשימה.
הגדר סף ביטחון/כשל שמסלים לאדם עם הקונטקסט המלא במקום לנחש.
למה: העברה חלקה עדיפה על תשובה שגויה בטוחה בעבודת סיכון גבוה.
בעלי העניין חושדים בתוצרי ה-agent.
חשוף את סיכום החשיבה של ה-agent, מקורותיו והכלים שבהם נעשה שימוש, כך שבני אדם יוכלו לבדוק ולדרוס החלטות.
למה: היכולת להסביר בונה אמון ולעיתים קרובות נדרשת לפיקוח וביקורת.