AWS Certified Generative AI Developer - Professional
נבדק לאחרונה: מאי 2026
מדריך מקוצר ובר-סריקה לדפוסי ארכיטקטורה שמבחן AIP-C01 בודק. קראו מלמעלה למטה, או דלגו לסעיף.
בחירת מודל Bedrock בסיסי עבור מקרה שימוש.
היגיון בהקשר ארוך + שימוש בכלים ← Claude (Sonnet/Opus). צ'אט ממוטב עלויות ← Claude Haiku או Titan Text Lite. קוד ← Claude או Llama. הטמעות (Embeddings) ← Titan Embeddings V2 או Cohere Embed. יצירת תמונות ← Titan Image, Stable Diffusion, או Nova Canvas. משקלים פתוחים עם שליטה באירוח עצמי ← Llama, Mistral, או Custom Model Import.
למה: אין מודל יחיד שהוא הטוב ביותר בכל ההיבטים: עלות, חביון, יכולת ותנאי רישיון. התאם את סוג המודל לצוואר הבקבוק.
מקור KB הוא שאלות נפוצות קצרות ועצמאיות או תיאורי מוצרים קצרים (כ-100–500 מילים כל אחד).
חלוקה לגושים בגודל קבוע עם גודל אסימון ברירת מחדל (300) וחפיפה (20%).
למה: יחידות עצמאיות אינן מרוויחות מחלוקה לגושים מודעת גבולות. גודל קבוע הוא הפשוט והזול ביותר.
מסמכים מכילים שינויי נושא טבעיים בתוך פסקאות; פיצולים בגודל קבוע קוטעים משפטים באמצע מחשבה.
Semantic chunking. Bedrock Knowledge Bases מקבץ משפטים עוקבים שה-embeddings שלהם קרובים, ומפצל בגבולות משמעותיים.
למה: שומר על רעיונות קוהרנטיים בתוך גוש ← שליפה נקייה יותר, איכות תשובה גבוהה יותר.
מדריכים טכניים ארוכים עם הפניות צולבות בין סעיפים; שאלות דורשות סינתזה על פני מסמך.
Hierarchical chunking. Bedrock בונה גושים הורים (גדולים) + ילדים (קטנים); שולף על בסיס embeddings של ילדים, מחזיר את הקשר ההורי.
למה: גושים קטנים מאפשרים שליפה מדויקת; הקשר ההורי שומר על הפניות צולבות ופרטים מסביב.
קבצי מקור כבר מחולקים לגושים מראש או שכל קובץ הוא בכוונה יחידה לוגית אחת.
אין אסטרטגיית chunking. כל קובץ הופך לגוש אחד ב-KB.
מקור PDF מכיל טקסט + דיאגרמות; משתמשים שואלים שאלות הדורשות הבנה של הדיאגרמות.
אפשר ניתוח מתקדם של Bedrock KB עם מודל בסיס (Claude/Nova) כמנתח. דיאגרמות וטבלאות מתוארות באמצעות ראייה, ולאחר מכן מוטמעות (embedded).
למה: ניתוח ברירת המחדל הוא טקסט בלבד. ניתוח רב-מודאלי ממיר תוכן ויזואלי לטקסט תיאורי לפני ההטמעה.
בחר Titan Embeddings G1 לעומת V2.
V2 תומך בממדים ניתנים להגדרה (256/512/1024) ומשיג ביצועים טובים יותר מ-G1 במבחנים רב-לשוניים. G1 קבוע על 1536. בחר V2 עבור מקרי שימוש מוגבלי אחסון או שאינם באנגלית; G1 רק לתאימות לאחור.
קטלוג מוצרים של 500 אלף: כותרות קצרות (50 מילים) + מפרטים ארוכים (500 מילים). אופטימיזציה של איכות חיפוש + עלות.
הטמע כל פריט פעם אחת (שדות משולבים או נפרדים). השתמש ב-Titan Embeddings V2 עם ממדים מופחתים (256 או 512) לצורך עלות; הטמע שאילתה ומסמך עם אותו מודל.
למה: ערבוב מודלי embedding או דילוג על נורמליזציה פוגע בחיפוש דמיון. ממדים נמוכים יותר מקצצים בעלות האחסון והשאילתה עם אובדן איכות שולי.
בחירת מאגר וקטורי עבור Bedrock Knowledge Bases.
הגדרה מהירה / ברירת מחדל ← Amazon OpenSearch Serverless (מנוהל אוטומטית). תת-מילישנייה עם עדכוני סכימה תכופים + צירופים יחסיים ← Aurora PostgreSQL עם pgvector. לקוח Pinecone / MongoDB Atlas / Redis קיים ← שמור עליו. KB קטן (פחות מ-10 אלף מסמכים) ממוטב עלויות ← Aurora pgvector או Neptune Analytics.
למה: OpenSearch Serverless הוא ברירת המחדל הקלה ביותר ליישום. Aurora pgvector מנצח כשאתה צריך טרנזקציות או צירופים על מטא-דאטה.
KB מחזיר מסמכים רלוונטיים סמנטית, אך הם מגרסאות מיושנות/אזור שגוי.
הוסף מטא-דאטה לקבצי מקור (`version`, `region`, `effective_date`) והחל מסנני מטא-דאטה בזמן שאילתה באמצעות `retrievalConfiguration.vectorSearchConfiguration.filter`.
למה: דמיון וקטורי טהור מתעלם מרעננות וסמכות. סינון מטא-דאטה מצמצם את מאגר המועמדים לפני הדירוג.
RAG מחמיץ שאילתות המכילות מזהים מדויקים (SKUs, קודי שגיאה, מספרי תקנות) מכיוון שחיפוש סמנטי מקנה משקל יתר לטקסט בעל משמעות דומה.
אפשר חיפוש היברידי ב-KB (סמנטי + מילות מפתח/BM25). משלב דמיון וקטורי עם התאמה לקסיקלית עבור מזהים, קודים ושמות עצם פרטיים.
Top-k=5 שולף 5 גושים אך הרלוונטי ביותר מדורג לעיתים קרובות במקום ה-3 או ה-4.
הגדל את `numberOfResults` ל-20 ולאחר מכן אפשר מודל reranking (Cohere Rerank או Amazon Rerank) לסידור מחדש לפי רלוונטיות לשאילתה המקורית.
למה: דמיון Embedding ≠ רלוונטיות למשימה. מודלי reranker מסוג Cross-encoder רואים שאילתה + גוש יחד ומדרגים בדיוק.
שאלות משתמשים הן שיחתיות, מרובות חלקים, או מכילות כינויים/המשכים; איכות שליפת ה-KB יורדת.
אפשר ניסוח מחדש של שאילתות ב-Bedrock KB. המודל כותב מחדש שאילתות מורכבות למספר תת-שאילתות ממוקדות לפני השליפה.
מסמכי מקור ב-S3 מתעדכנים לעיתים קרובות; ה-KB חייב לשקף תמיד את הגרסאות העדכניות ביותר ללא סנכרון ידני.
הגדר את מקור הנתונים של ה-KB לסנכרון אוטומטי באמצעות S3 event notifications → EventBridge → StartIngestionJob, או השתמש בסנכרון מתוזמן של ה-KB. הימנע מהסתמכות על כפתור "Sync" הידני בקונסולה.
מודל QA למסמכים ארוכים "מזייף" (hallucinates) על שאלות שתשובותיהן נמצאות באמצע המסמך.
אל תעביר מסמכים מלאים ב-prompt – חלק לגושים + שלוף באמצעות RAG כך שרק הגושים הרלוונטיים יגיעו למודל. אם מסמך מלא הוא חובה, השתמש במודל עם זיכרון הקשר ארוך חזק (Claude Sonnet 200K) והצב את השאלה לאחר המסמך.
למה: רוב מודלי ה-LLM מציגים ירידה בזיכרון הנקראת "אובדן באמצע". RAG עוקף זאת; מיקום עוזר כאשר RAG אינו זמין.
בחר את ההתאמה האישית הזולה ביותר העומדת ברף האיכות.
נסה לפי הסדר: (1) prompt engineering, (2) RAG עם KB, (3) fine-tuning, (4) continued pre-training, (5) Custom Model Import. עצור בראשון שעומד ברף.
למה: המאמץ והעלות השוטפת גדלים בכל שלב. Fine-tuning + Provisioned Throughput יקרים בהרבה מ-RAG.
כוונן עדין מודל Bedrock עם דוגמאות משימות מתויגות.
קובץ JSONL ב-S3 עם דוגמה אחת לכל שורה: `{"prompt": "...", "completion": "..."}` (או פורמט צ'אט מקביל עבור משפחת המודלים).
למה: לכל משפחת מודלים (Titan, Claude, Llama) יש סכימה ספציפית; בדוק את תיעוד ה-fine-tuning של המודל לפני העיצוב.
התאם מודל בסיס לאוצר מילים מיוחד (משפטי, רפואי, מדעי) באמצעות הרבה טקסט תחום לא מתויג.
אימון מקדים מתמשך על קורפוס התחום הלא מתויג. שונה מ-instruction fine-tuning (שדורש זוגות prompt-completion).
למה: אימון מקדים מתמשך מעדכן את הבנת השפה; instruction fine-tuning מלמד התנהגות משימתית. צורת נתונים שונה, מטרה שונה.
נתוני אינטראקציות לקוחות לצורך fine-tuning מכילים שמות, מיילים, מספרי טלפון.
נקה או סמן (tokenize) מידע PII לפני העלאת מערך נתוני האימון ל-S3. ברגע שהמשקלים סופגים PII, סינון הפלט אינו יכול למסך אותו בצורה אמינה.
למה: מודל מכוונן עדין עשוי להחזיר קטעי נתוני אימון. ניקוי בשכבת הנתונים הוא ההפחתה העמידה היחידה.
הבא מודל Llama או Mistral מכוונן עדין עצמאית והגש אותו באמצעות ה-API המאוחד של Bedrock.
ייבוא מודל מותאם אישית (Custom Model Import). העלה משקלים ל-S3, רשום ב-Bedrock, הפעל באמצעות סביבת הריצה של Bedrock עם IAM ורישום אחודים.
למה: מאפשר לך להשתמש מחדש ב-Bedrock Guardrails, KBs ו-Agents על משקלים משלך מבלי להקים נקודות קצה של SageMaker.
הגשת מודל Bedrock מכוונן עדין לייצור.
רכוש Provisioned Throughput. מודלים מותאמים אישית (מכווננים עדין, מאומנים מראש באופן מתמשך, מיובאים) אינם יכולים להיות מופעלים לפי דרישה.
יישום Claude עתיר תנועה מגיע למגבלות מכסה אזוריות בשיאים; נדרש תפוקה גבוהה יותר ללא רכישת Provisioned Throughput.
פרופילי הסקה בין-אזוריים (Cross-region inference profiles). Bedrock מנתב הפעלות בין מספר אזורים בשקיפות כדי להגדיל את מכסות ה-TPM/RPM האפקטיביות.
למה: מכסות על פי דרישה באזור יחיד מוגבלות בזמן עליות; פרופילים בין-אזוריים מכפילים בקירוב את המכסות ללא שינויים בקוד היישום מעבר לשימוש ב-ARN של פרופיל ההסקה.
משתמשי APAC רואים חביון גבוה משמעותית ממשתמשי ארה"ב/האיחוד האירופי ביישום Bedrock הפרוס ב-us-east-1.
פרוס נקודות קצה אזוריות של Bedrock ב-ap-northeast-1 / ap-southeast-1 / ap-south-1 (היכן שהמודל זמין באופן כללי). נתב משתמשים באמצעות מדיניות חביון או מיקום גיאוגרפי של Route 53.
למה: זמן הלוך-חזור של LLM שולט עבור הקשרים ארוכים; זמן RTT לבדו מעבר לאוקיינוס השקט הוא 150–250 אלפיות השנייה.
יישום המוסדר ב-HIPAA צריך לסכם PHI באמצעות Bedrock.
השתמש רק במודלי בסיס כשירים ל-HIPAA (לפי רשימת השירותים הכשירים ל-HIPAA). חתום על BAA עם AWS. הצפן promptים/תגובות עם מפתחות KMS מנוהלים על ידי הלקוח. השבת רישום הפעלת מודלים או הגבל אותו לדלי S3 פרטי עם גישה מוגבלת.
החלט אילו נתונים רשאים לזרום ל-Bedrock בהתבסס על רגישות (ציבורי / חסוי / מוגבל).
ציבורי ← ללא הגבלה. חסוי ← רק באמצעות נקודות קצה של VPC + CMK + רישום הפעלות בדליים פרטיים. מוגבל (סודות מסחריים, PHI/PCI מוסדר) ← חסום מ-Bedrock לחלוטין או השתמש במשטר תאימות כשיר ל-Bedrock + בצע עריכה לפני הפעלה.
ארגון מרובה חשבונות רוצה שחשבון A ישתף מודל Bedrock מותאם אישית עם חשבון B ללא העתקת משקלים.
שיתוף מודל מותאם אישית באמצעות AWS RAM. הבעלים משתף את ה-ARN של המודל המותאם אישית; חשבונות צרכנים מפעילים אותו דרך סביבת הריצה הסטנדרטית של Bedrock עם ישויות IAM בין-חשבונאיות במדיניות המשאבים.
למה: מונע עלויות fine-tuning מיותרות ומרכז את מחזור חיי המודל. RAM שולט מי יכול לצרוך את המשאב המשותף.
זקוק למודל צד שלישי נישתי (למשל, LLM המתמחה בבריאות) שאינו בקטלוג Bedrock הסטנדרטי.
Amazon Bedrock Marketplace. הירשם למודל מקטלוג Marketplace, פרוס לנקודת קצה של Bedrock, הפעל באמצעות ה-API הסטנדרטי של סביבת הריצה.
למה: מאחד חיובים של צד שלישי, IAM, KMS ויכולת תצפית עם מודלי Bedrock של צד ראשון.
יישום חיפוש עתיר נפח מטמיע מחדש את אותם המסמכים בכל רענון שאילתה; עלות ההטמעה שולטת.
חשב מראש embeddings בעת קליטת מסמך, אחסן את הווקטור ב-DynamoDB או OpenSearch מקושרים לפי מזהה מסמך + גיבוב תוכן. הטמע מחדש רק כאשר גיבוב התוכן משתנה.
למה: הטמעת אותו טקסט שוב ושוב היא העלות הנפוצה ביותר שניתן להימנע ממנה. מטמון מבוסס גיבוב הוא דילוג ב-O(1).
זכות השכחה (GDPR right-to-be-forgotten) על מודל מכוונן עדין: משתמש מבקש מחיקה של PII שלו מנתוני אימון.
מחק רשומות מקורפוס האימון, ולאחר מכן כוונן עדין מודל בסיס חדש מאפס. לא ניתן לנקות נתונים באופן אמין ממשקלים קיימים – סינון פלט אינו מספיק.
למה: ברגע שמשקלים סופגים נתוני אימון, מיסוך בהסקה אינו אמין. הדרך הבטוחה היא אימון מחדש מלא ללא הרשומות המושפעות.
KB משותף משרת מספר צוותים; כל צוות חייב לראות רק את המסמכים שלו.
תייג כל גוש עם מטא-דאטה `tenant_id` / `team_id` / `clearance` בעת קליטה. בזמן שאילתה, הגדר את `retrievalConfiguration.vectorSearchConfiguration.filter` לערכים המותרים של הקורא מהסשן IAM או הקשר היישום.
למה: דמיון וקטורי מתעלם מבקרת גישה; סינון מטא-דאטה הוא הבידוד העמיד היחיד לכל דייר ב-KB משותף.
לקוח אירופאי דורש ש-prompts ו-KB embeddings לעולם לא יעזבו את eu-west-1.
פרוס Bedrock + KB + דלי מקור S3 ב-eu-west-1. הצמד הפעלות באמצעות ARN של פרופיל הסקה מוגבל ל-eu-west-1; SCP `aws:RequestedRegion` דחייה על אזורים אחרים עבור `bedrock:*`.
זרימת עבודה מרובת שלבים דורשת חשיבה של LLM, קריאות ל-APIs/מסדי נתונים חיצוניים, וסינתזה.
Amazon Bedrock Agent. הגדר הוראות, קבוצות פעולה (Lambda + OpenAPI schema), ו-KB אופציונלי. הסוכן מתכנן, מפעיל כלים ומחבר תוצאות.
למה: חוסך כתיבת לולאת התזמור בעצמך. כולל מעקב מובנה, זיכרון סשן, ו-hooks של Return-of-Control.
סוכן Bedrock חייב לקרוא לשלושה APIs פנימיים (CRM, מלאי, תשלומים).
הגדר קבוצת פעולה אחת לכל API. לכל קבוצת פעולה יש OpenAPI schema המתאר את פעולותיה ופונקציית Lambda (או נקודת קצה של Return-of-Control) המבצעת קריאות.
הסוכן חייב לבצע פעולות בסיכון גבוה (מחיקת חשבון, החזרים גדולים) רק לאחר אישור אנושי/עסקי.
הגדר את קבוצת הפעולה עם Return of Control (RoC). Bedrock מחזיר את הפעולה המוצעת ליישום במקום להפעיל אותה; היישום מגן על הביצוע מאחורי אישור ושולח מחדש תוצאות.
למה: שומר על צעדים בסיכון גבוה מחוץ לסביבת הריצה של הסוכן כך שניתן יהיה לבקר אותם או לאשרם על ידי אדם לפני ביצועם.
הסוכן חייב לזכור הקשר על פני פניות בתוך סשן משתמש אחד.
השתמש בתכונות הסשן המובנות של הסוכן ותכונות הסשן של ה-prompt. העבר `sessionId` ל-InvokeAgent — Bedrock שומר את מצב השיחה למשך זמן הקריסה שנקבע.
הסוכן חייב לזכור עובדות על משתמש חוזר על פני סשנים (העדפות, היסטוריה) ולסכם חילופי דברים ישנים יותר.
אפשר זיכרון סוכן Bedrock. הסוכן מתמיד בסיכום היסטוריית סשן לכל `memoryId` ומנגן אותו מחדש כהקשר בהפעלות עתידיות.
זרימת עבודה דורשת סוכנים מיוחדים (מחקר, קוד, חיוב) המתואמים על ידי מתכנן ברמה העליונה.
שיתוף פעולה רב-סוכנים של Bedrock Agents: הגדר סוכן מפקח אחד וכמה סוכנים משתפי פעולה. המפקח מפצל תת-משימות בהתבסס על תיאורי משתפי הפעולה ומסנתז תוצאות.
נדרש צינור עיבוד נתונים רב-שלבי: חלץ → סווג → נתב → סכם, עם ענפים מותנים.
Amazon Bedrock Prompt Flows. זרימת עבודה ויזואלית עם צמתי prompt, צמתי תנאי, צמתי KB, צמתי Lambda; בגרסאות וניתנת להפעלה כ-API יחיד.
למה: מחליף Step Functions שנכתבו ידנית עבור צינורות עיבוד נתונים של promptים וחושף נקודת כניסה אחת.
SaaS מרובה דיירים: promptים מערכתיים לכל דייר, העדפות מודל וניהול גרסאות.
Amazon Bedrock Prompt Management. אחסן promptים כנכסים עם גרסאות ופרמטרים; התייחס אליהם באמצעות ARN בזמן ריצה; בצע A/B testing לגרסאות שונות לכל דייר.
היישום חייב לעבוד עם Claude, Llama, Titan ו-Cohere עם ממשק API אחד בסגנון צ'אט.
השתמש ב-Bedrock Converse API. פורמט רשימת הודעות אחיד, שימוש בכלים ו-system prompts על פני משפחות מודלים. הימנע מ-InvokeModel JSON ספציפי למודל כאשר ניידות חשובה.
צ'אט בוט חייב להציג תגובות אסימון-באסימון כדי לקצר את החביון הנתפס.
ConverseStream (או InvokeModelWithResponseStream). חבר עם API Gateway WebSocket או AppSync subscriptions כדי להפיץ אסימונים לדפדפן.
צ'אט תמיכת לקוחות בזמן אמת: הזרמת תגובות, 500 משתמשים בו-זמנית, היסטוריית שיחה.
דפדפן ↔ API Gateway WebSocket ↔ Lambda ↔ Bedrock ConverseStream. שמור את השיחה ב-DynamoDB מקושרת לפי `sessionId` וטען מחדש בכל פנייה.
למה: WebSocket מונע HTTP polling; מאגר הסשנים של DynamoDB שורד את חוסר המצב של Lambda.
צריך שהמודל יחליט מתי לקרוא לפונקציות (חיפוש במסד נתונים, מחשבון, API).
השתמש ב-tool use של Converse API (`toolConfig`) — הצהר על כלים עם שם + JSON schema; המודל פולט בלוקים של `toolUse`; היישום מבצע ומחזיר `toolResult`. עובד על פני Claude, Llama, Mistral, Cohere Command R.
כרטיס חדש במערכת צד שלישי ← ניתוח אוטומטי של Bedrock (סנטימנט, דחיפות, קטגוריה) ← ניתוב.
Webhook ← API Gateway ← EventBridge ← יעד Lambda ← Bedrock. EventBridge מנתק מפיקים מצרכנים ומספק ניסיונות חוזרים + DLQ בחינם.
מספר מיקרו-שירותים שולחים בקשות יצירה ל-Bedrock; צרכנים אינם זקוקים לתוצאות באופן מיידי.
מפיקים ← SQS ← צרכן Lambda (או ECS) ← Bedrock InvokeModel ← אחסן תוצאה ב-S3/DynamoDB. SQS מרכך עליות פתאומיות ומנסה שוב כשלים במסגרת מכסות השירות.
צור תיאורים עבור 100,000 SKUs מדי לילה; סובלני לחביון; רוצה עלות מינימלית.
Amazon Bedrock Batch Inference. שלח קובץ JSONL קלט ל-S3, Bedrock מריץ את העבודה בעלות נמוכה עד 50% לאסימון לעומת on-demand, וכותב פלט JSONL.
למה: Batch מחליף חביון בעלות. השתמש בו בכל פעם שאין צורך בתוצאות בזמן אמת.
API Gateway לפני Lambda + Bedrock מחזיר 504 Gateway Timeout על יצירות ארוכות.
זמן קצוב של אינטגרציית REST ב-API Gateway מוגבל ל-29 שניות. עבור לתבנית אסינכרונית (החזר מזהה משימה, בצע polling דרך נקודת קצה שנייה) או ל-API Gateway WebSocket + ConverseStream כך שאסימונים חלקיים יזרמו לפני חלון הזמן הקצוב.
צור תיאורי מוצרים מתמונת מוצר + טקסט קצר.
השתמש במודל בעל יכולת ראייה ב-Bedrock (Claude 3+ Sonnet, Nova) באמצעות Converse API עם בלוקי תוכן `image` לצד טקסט.
תרגום הודעות לאנגלית באיכות גבוהה בפחות משנייה.
מודל בסיס (Claude Haiku או Llama קטן) דרך Bedrock לצורך ניואנסים, או Amazon Translate לצורך מהירות/עלות כאשר תרגום מילולי מספיק. Bedrock למודעות הקשר; Translate לטרנזקציות.
הזז בהדרגה תעבורת ייצור ממודל A למודל B עם יכולת מתג חירום.
דגל תכונה של AWS AppConfig המכיל את מזהה המודל הפעיל ופיצול התעבורה. Lambda קורא את הדגל בכל הפעלה, מנתב בהתאם. חזור לאחור באופן מיידי באמצעות AppConfig deployment rollback.
החלט בין Bedrock ל-SageMaker JumpStart לאירוח מודל בסיס.
Bedrock כאשר אתה רוצה הסקה מנוהלת, API אחוד, KB/Agents/Guardrails. SageMaker JumpStart כאשר אתה צריך נקודת קצה פרטית מותאמת VPC עם שליטה מלאה ברשת/IAM או מודל עם משקלים פתוחים שאינו ב-Bedrock.
בחר סגנון הגדרת קבוצת פעולה: מפרט OpenAPI 3.0 לעומת function schema.
OpenAPI כאשר ל-API הבסיסי כבר יש מפרט OpenAPI 3.0 או שאתה צריך סמנטיקת HTTP מלאה (נתיבים, מתודות, סוגי פרמטרים). Function schema לפעולות פנימיות/קלות משקל המוגדרות באמצעות הצהרות מאפיינים פשוטות ב-JSON.
למה: OpenAPI הוא קנוני עבור REST APIs קיימים. Function schema מהיר יותר עבור עוזרים פנימיים חדשים של סוכנים.
הסוכן חייב לבצע מתמטיקה מדויקת, ניתוח סטטיסטי, או להריץ קטעי קוד פייתון קטנים כדי לענות על שאלות.
אפשר את מפרש הקוד של Bedrock Agents. הסוכן מריץ Python בסביבת ארגז חול מנוהלת; התוצאות זורמות חזרה לסינתזת התשובה.
למה: מודלי LLM אינם אמינים במתמטיקה מדויקת; סביבת ריצה בארגז חול מספקת תוצאות מספריות דטרמיניסטיות ללא כתיבת קבוצות פעולה מותאמות אישית.
promptים ברירת המחדל של הסוכן מייצרים תגובות מפורטות מדי; צריך לצמצם את prompt התזמור לייצור.
הגדר החלפות תבניות prompt על הסוכן עבור כל שלב (עיבוד מקדים, תזמור, יצירת תגובת KB, עיבוד לאחר מכן). ההחלפות משולבות עם הסוכן בגרסאות.
בצע איטרציות על סוכן בסביבת פיתוח בזמן שתעבורת הייצור נשארת על גרסה יציבה.
השתמש בגרסאות וכינויים של סוכנים. `DRAFT` לעריכות פעילות; פרסם גרסאות ממוספרות; נתב באמצעות כינויים (`prod` ← גרסה 7, `dev` ← DRAFT). קדם על ידי עדכון הכינוי.
הסוכן בוחר בקבוצת פעולה שגויה; צריך לנפות את השגיאות בתהליך החשיבה צעד אחר צעד.
אפשר מעקב ב-InvokeAgent (`enableTrace: true`). זרם התגובה כולל בלוקים של `preProcessingTrace`, `orchestrationTrace`, `postProcessingTrace`, ו-`failureTrace` המציגים את רציונל המודל, בחירת הכלים והקלט.
בנה Bedrock Flow עבור "חלץ ישויות ← חפש ב-KB ← סכם ← שלח מייל".
הרכב צמתים: צומת prompt (חלץ), צומת Knowledge Base (חפש), צומת prompt (סכם), צומת Lambda (שלח מייל דרך SES). השתמש בצמתי קלט/פלט S3 עבור זרימות אצווה; צמתי תנאי לפיצול.
בחר Bedrock Flows לעומת Step Functions עבור צינור עיבוד GenAI מרובה שלבים.
Bedrock Flows כאשר השלבים הם בעיקר פרימיטיבים של Bedrock (promptים, KBs, סוכנים) — הפעלת API יחידה, ללא דבק IAM נוסף. Step Functions כאשר זרימת העבודה משתרעת על פני שירותי AWS רבים עם ניסיונות חוזרים, ענפים מקבילים, טיפול בשגיאות מורכב, או המתנות ארוכות.
יישם לולאת צ'אט שבה המודל קורא באופן איטרטיבי לכלים, ואז מנסח את התשובה הסופית.
תבנית: שלח הודעת משתמש ← המודל מחזיר `toolUse` ← היישום מבצע כלי ← היישום שולח `toolResult` בחזרה דרך Converse ← חזור על הלולאה עד שהמודל מחזיר טקסט סופי. הגבל איטרציות כדי למנוע יציאה משליטה.
למה: המודל מחליט מתי יש לו מספיק מידע כדי לעצור; היישום חייב לנהל את הלולאה ולאכוף מגבלת שלבים מקסימלית.
המודל צריך לחפש לקוח + הזמנה + מלאי; קריאות כלים רצופות מוסיפות פי 3 חביון.
מודלים התומכים בשימוש בכלים מקבילים (Claude 3+, Nova) פולטים מספר בלוקים של `toolUse` בפנייה אחת. בצע אותם במקביל ביישום והחזר את כל ה-`toolResult`ים לפני ההסקה הבאה.
שמור מצב צ'אט מרובה פניות על פני הפעלות Lambda חסרות מצב עם ניקוי אוטומטי של סשנים מיושנים.
טבלת DynamoDB מקושרת לפי `sessionId` המאחסנת `messages` + `lastActivity`. הגדר תכונת TTL (`expiresAt`) למחיקה אוטומטית של סשנים ישנים מ-24 שעות. Lambda קורא/כותב בכל פנייה.
צ'אט רואה כ-1000 שאילתות בשנייה; קריאות DynamoDB לכל פנייה על היסטוריית סשנים הן נקודה חמה.
הצב ElastiCache for Redis לפני DynamoDB. שמור במטמון את N ההודעות האחרונות לכל סשן ב-Redis hash; כתוב דרך ל-DynamoDB לעמידות. הגדר TTL למפתחות Redis כדי להגביל את הזיכרון.
ניסיון חוזר לקריאת Bedrock InvokeModel מסכן חיוב כפול עבור אותה בקשה לוגית.
צור מפתח אידמפוטנטיות לכל בקשה לוגית (למשל, UUID v5 של קלט + משתמש). שמור את התגובה במטמון מקושרת לפי מפתח אידמפוטנטיות ב-DynamoDB או ElastiCache; החזר את התגובה השמורה במטמון בניסיון חוזר.
למה: Bedrock עצמו אינו אידמפוטנטי — אותו קלט מחויב בכל קריאה. שמירה במטמון בשכבת היישום היא הדרך היחידה לאידמפוטנטיות.
הרץ שתי גרסאות מודלים בייצור במהלך הגירה מבלי להחליף את כל המשתמשים בבת אחת.
גבב את מזהה המשתמש ל-N דליים; נתב דלי i למודל A או מודל B בהתבסס על דגל תכונה (AppConfig / Parameter Store). עקוב אחר מדדים זה לצד זה; העבר הקצאת דליים כדי להתקדם או לחזור.
צ'אט בוט מול לקוחות חייב לחסום תוכן מזיק, נושאים אסורים ודליפת PII.
Amazon Bedrock Guardrails. הגדר נושאים אסורים, מסנני תוכן (שנאה, אלימות, מיניות, עלבונות, התנהגות בלתי הולמת), מסנני מילים, מסנני מידע רגיש (עריכת PII), ובדיקות ביסוס הקשרי (contextual grounding checks). החל על קלט ופלט InvokeModel.
למה: Guardrails אינם תלויים במודל ומוחלים בשני הכיוונים; הם שורדים כל החלפת מודל יחידה.
Guardrail חוסם תגובות פיננסיות לגיטימיות המזכירות סכומי דולרים.
הורד את רמת הרגישות במסנן התוכן המושפע (לדוגמה `MEDIUM` → `LOW`) ו/או הסר ניסוח של נושאים אסורים רחבים מדי. בדוק מחדש מול סט promptים לבדיקה לפני פריסה מחדש.
יישום סיכום רפואי אסור לו להמציא עובדות מעבר למסמכי המקור.
אפשר בדיקת ביסוס הקשרי (contextual grounding check) של Bedrock Guardrails עם סף רלוונטיות + ביסוס גבוה. תגובות מתחת לסף נחסמות או מוחלפות בהודעת ברירת מחדל בטוחה.
למה: RAG טהור עדיין "מזייף" כאשר המודל מכליל יתר על המידה מגושים שנשלפו. ביסוס הקשרי מדרג את התאמת התשובה למקור עבור כל תגובה.
יישום Bedrock מקבל promptים המכילים PII של לקוחות; נדרש מיסוך אוטומטי לפני רישום או שימוש בהמשך.
הגדר מסנני PII של Guardrails עם פעולות `BLOCK` או `ANONYMIZE` עבור סוגי ישויות PII (מספר ת"ז, מייל, טלפון, כתובת). הסינון מתרחש על קלט ופלט באופן עצמאי.
יישום הפונה לציבור מקבל קלט משתמש המצורף ל-system prompt; חייב לעמוד בפני prompt injection.
הגנה בשכבות: (1) Guardrails (נושאים אסורים + זיהוי jailbreak), (2) system prompt מוקשח הממסגר את קלט המשתמש כנתונים ומסרב להוראות מטא, (3) אימות פלט מול סכימה צפויה, (4) הרשאות כלים במינימום הרשאות כך ש-prompt שנפרץ לא יכול להפעיל פעולות הרסניות.
למה: אין אמצעי הפחתה יחיד מספיק; הגנות שכבות מגבילות את רדיוס הפיצוץ.
צוות אדום מגלה שניתן לכפות על המודל לייצר פלט מזיק באמצעות מסגור משחקי תפקידים ("תעמיד פנים שאתה AI ללא הגבלות").
אפשר את מסנן התוכן של זיהוי Jailbreak ב-Guardrails. הוסף נושאים אסורים מפורשים לניסיונות משחקי תפקידים. בדוק מחדש לאחר כל שינוי עם אותו סט promptים של הצוות האדום.
כל נתוני Bedrock חייבים להיות מוצפנים במעבר ובמנוחה עם מפתחות המנוהלים על ידי הלקוח.
TLS 1.2+ נאכף במעבר. במנוחה: הגדר מפתחות KMS מנוהלים על ידי הלקוח להתאמה אישית של מודל Bedrock, הטמעות KB + נתוני מקור S3, יעדי רישום הפעלות. אכוף באמצעות SCP המונע מפתחות המנוהלים על ידי AWS.
ארגון מרובה צוותים: כל צוות צריך לגשת רק למודלי בסיס ספציפיים.
מדיניות מבוססת זהויות של IAM המאפשרת `bedrock:InvokeModel` על ARNs של משאבים המוגבלים למזהי המודל המורשים. שלב עם תנאי `aws:RequestedRegion` כדי לנעול אזור.
למה: הרשאת Allow ברמת משאב על `arn:aws:bedrock:*::foundation-model/<id>` היא הדרך היחידה העמידה לאכוף גישה ברמת המודל. אל תסתמך על הגבלות בשכבת היישום.
Lambda מפעיל רק את Claude 3.5 Sonnet ב-us-east-1.
אפשר `bedrock:InvokeModel` עם `Resource: arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-*` ותנאי `Condition: aws:RequestedRegion = us-east-1`. דחה את כל המודלים והאזורים האחרים.
יישום Bedrock אסור לו לצאת לאינטרנט הציבורי.
Bedrock עם נקודות קצה של ממשק VPC (PrivateLink) עבור ה-API של סביבת הריצה. חסום נקודות קצה ציבוריות של Bedrock באמצעות SCP. הוסף מדיניות נקודת קצה המגבילה פעולות לקבוצה המאושרת.
רגולטור דורש תיעוד ביקורת מלא של כל הפעלה של מודל Bedrock: prompt, תגובה, גרסת מודל, חותמת זמן.
אפשר רישום הפעלות מודל Bedrock ל-CloudWatch Logs או S3. לוכד prompt מלא + תגובה + מזהה מודל + חותמת זמן. שלב עם CloudTrail עבור שכבת מטא-הנתונים של קריאת ה-API (מי/מתי/מאיפה).
למה: CloudTrail לוכד מטא-נתונים בלבד; רישום הפעלות לוכד תוכן. תאימות דורשת בדרך כלל את שניהם.
קבע את חלק אחריות האבטחה של החברה עבור פריסת Bedrock.
מטריצת היקף אבטחה של AWS Generative AI. היקף 1 (SaaS צרכני) ← היקף 5 (מודל מאומן עצמית על נתונים פרטיים). Bedrock עם מודלי בסיס לפי דרישה הוא בדרך כלל היקף 2; KB/Agent + RAG דוחף לכיוון היקף 3; fine-tuning היקף 4; Custom Model Import היקף 5.
הגן על נקודת הקצה של GenAI API מאחורי API Gateway מפני שימוש לרעה.
AWS WAF עם כללים מבוססי קצב (לפי IP), סט כללים מנוהל לבקרת בוטים, וכלל התאמת מחרוזת מותאם אישית על ביטויי jailbreak חשודים. חסום דפוסי LLM-DDoS נפוצים (הצפות prompt ארוכות).
מצא PII או נתונים רגישים אחרים בקורפוסי מקור S3 לפני שהם נכנסים ל-KB או למשימת fine-tuning.
משימת גילוי מתוזמנת של Amazon Macie על דלי S3 הרלוונטיים. הממצאים עוברים ל-Security Hub / EventBridge לצורך עריכה (redaction) בהמשך.
זיהוי תמונות שנוצרו על ידי AI במורד הזרם לצורך מקור תוכן.
השתמש ב-Titan Image Generator (או Nova Canvas) — הפלטים כוללים סימן מים בלתי נראה. אמת עם ה-API לזיהוי סימן מים של Bedrock.
צ'אט בוט שיווקי אסור לו לציין שמות מתחרים ואסור לו לטעון טענות לא מבוססות.
נושאים אסורים ב-Guardrails: רשימה מפורשת של שמות מתחרים + "טענות מוצר לא מאומתות" ברמת הנושא. הוסף מסנן מילים לטענות מוחלטות ("מובטח", "הטוב ביותר", "100%").
החל Bedrock Guardrail על פלטים ממודל שאינו Bedrock (למשל, נקודת קצה של SageMaker באירוח עצמי).
קרא ל-API העצמאי `ApplyGuardrail` עם הטקסט + מזהה Guardrail + גרסה. מחזיר אם התוכן נחסם או שונה, ואיזה מסננים הופעלו.
למה: מנתק את ה-Guardrails מהמודל. השתמש כבדיקה מקדימה על קלט משתמש או בדיקה שלאחר מכן על כל פלט מודל.
מדיניות Guardrail יחידה חייבת לחול על פני us-east-1, eu-west-1, ו-ap-southeast-1.
צור מחדש את אותו Guardrail (אותה תצורה) בכל אזור. Guardrails הם משאבים אזוריים; השתמש ב-IaC (CloudFormation / CDK / Terraform) כדי לשמור על תצורות מסונכרנות.
למה: אין שכפול מנוהל בין אזורים עבור Guardrails. IaC הוא הדרך היחידה לעקביות עמידה.
תוקף מרעיל מסמכים ב-KB הפונה לציבור כך שהסוכן מדליף prompt מערכת או נתונים בעת שליפתם.
התייחס לתוכן KB שנשלף כבלתי מהימן: אפשר Guardrails על קלטים ופלטים, נקה גושים שנשלפו באמצעות זיהוי prompt-injection או התאמת תבניות, אכוף את עקרון הפחות הרשאות (least-privilege) על קבוצות פעולה של סוכנים כך ש-prompt שנפרץ לא יוכל להסלים.
למה: הזרקה עקיפה עוקפת סינון קלט — ה-prompt הזדוני מגיע דרך הקשר שנשלף, לא דרך הודעת המשתמש.
צריך גישת מודל לכל משתמש ביישום מרובה דיירים עם תפקיד backend יחיד.
העבר תכונות משתמש כתגי סשן במהלך AssumeRole. התייחס אליהם באמצעות תנאי `aws:PrincipalTag/<key>` במדיניות הזהות של Bedrock כדי להגביל את `bedrock:InvokeModel` לכל משתמש.
בחר יעד לרישום הפעלות Bedrock.
CloudWatch Logs ל-promptים/תגובות קצרים, שאילתות מהירות ב-Logs Insights, יישומים בקנה מידה קטן יותר. S3 לנפח גבוה, מטענים גדולים (KB + מעקבי סוכנים), שמירה לטווח ארוך, ניתוח Athena/Glue במורד הזרם. השתמש ב-S3 אם תגובה יחידה כלשהי יכולה לעלות על 256KB.
למה: ל-CloudWatch Logs יש מגבלות גודל לכל אירוע; ל-S3 אין. בחר לפי גודל מטען ותבנית ניתוח.
הגן על API צ'אט ציבורי מפני DDoS ושימוש לרעה בהצפת אסימונים בקנה מידה גדול.
AWS Shield Standard פעיל כברירת מחדל; אפשר Shield Advanced בנקודות קצה קריטיות להגנות L7 + תמיכת SRT 24/7. שלב עם כללים מבוססי קצב של WAF ו-CloudFront לספיגה בקצה.
יישום יוצר תמונות חייב לחסום תמונות בעלות תוכן מיני מפורש, אלים או שנאה.
מסנני תוכן תמונות של Bedrock Guardrails על קלט (תמונות שהועלו) ופלט (תמונות שנוצרו). המסננים מסווגים תוכן ויזואלי עם ספי HIGH/MEDIUM/LOW.
זרימת עבודה לפני כיוונון עדין של מודל Bedrock על תמלילי תמיכת לקוחות.
Pipeline: מקור S3 ← משימת גילוי Macie לזיהוי PII ← זיהוי PII + עריכה ב-Comprehend (או Glue עם regex) ← מערך נתונים נקי לקידומת S3 נפרדת ← Bedrock fine-tune. כשלים של Macie מפעילים EventBridge ← SNS לצוות האבטחה בכוננות.
למה: ברגע שנתונים נכנסים למשקלים, הסרה דורשת אימון מחדש. עריכה לפני טיסה זולה בהרבה מאימון מחדש לאחר אירוע.
בחר On-demand לעומת Provisioned Throughput.
תעבורה משתנה / לא ידועה ← on-demand. נפח גבוה קבוע עם SLA של תפוקה מובטחת ← Provisioned Throughput (יחידות מודל, התחייבות ל-1 או 6 חודשים). מודלים מותאמים אישית (מכווננים עדין, מיובאים) ← Provisioned Throughput הוא חובה.
למה: On-demand הוא לפי אסימון, ללא התחייבות. PT הוא לפי שעה, קיבולת ייעודית, זול בכ-50% לאסימון בניצול גבוה.
היישום משתמש מחדש באותו system prompt בן 4,000 אסימונים בכל אינטראקציות המשתמש; רק הודעת המשתמש משתנה.
אפשר שמירת prompt במטמון ב-Bedrock. סמן את הקידומת הסטטית כניתנת לשמירה במטמון; הפעלות עוקבות מדלגות על עיבוד מחדש למשך TTL מטמון של כ-5 דקות, מה שמפחית את עלות הקריאה בכ-90% על אסימונים שמורים במטמון.
משתמשים רבים שואלים שאלות דומות אך לא זהות; רוצים לשמור תשובות במטמון על פני ניסוחים שונים.
הטמע את שאילתת המשתמש וחפש שכנים קרובים ביותר במטמון וקטורי (DynamoDB + ElastiCache, או OpenSearch) מעל סף דמיון. פגיעה במטמון ← החזר תגובה שמורה. החטאה במטמון ← הפעל Bedrock וכתוב בחזרה.
למה: מטמוני מפתח-ערך סטנדרטיים מחמיצים ניסוחים שונים. דמיון סמנטי לוכד כוונה.
הפחת את עלות הקריאה ביישום Bedrock.
צמצם את ה-system prompt, הסר דוגמאות few-shot מיותרות, הגדר `maxTokens` מפורש על הפלט, השתמש ברצפי עצירה כדי לסיים מוקדם. בחר מודל קטן יותר היכן שהאיכות מאפשרת.
למה: העלות פרופורציונלית בקירוב למספר האסימונים הכולל שעובד. אסימוני פלט מתומחרים בדרך כלל גבוה יותר מאסימוני קלט — הגבלת פלט היא בעלת מינוף גבוה.
השלמת קוד: חביון תת-שנייה, עלות מאוזנת, נפח בקשות גבוה.
Claude Haiku (או Nova Micro / Llama קטן) ב-Bedrock. הימנע מ-Opus או Llama גדול עבור נתיבי השלמת אסימונים רגישים לחביון.
ל-KB יש 500 אלף מסמכים אבל רק כ-200 שאילתות ביום; מזער עלויות.
Aurora PostgreSQL Serverless v2 עם pgvector. מדרג עד כמעט אפס ACUs במצב סרק; מודל תשלום לפי שאילתה מנצח את רצפות OCU של OpenSearch Serverless הפועלות תמיד בקצב QPS נמוך.
ל-OpenSearch Serverless KB יש חביון שאילתה של 800 אלפיות השנייה; צריך <200 אלפיות השנייה.
הגדל את רצפת ה-OCU באוסף החיפוש (יותר כוח חישוב = יותר וקטורים שמורים במטמון). הפחת את מימד ה-embedding, הגדל את top-k בחוזקה, גזום מטא-דאטה, אפשר שמירת תוצאות במטמון בשכבת היישום.
משימות fine-tuning ארוכות טווח הסובלניות להפרעות; מזעור עלויות.
עבור fine-tuning ב-SageMaker השתמש ב-Managed Spot Training (עד 90% הנחה). ה-fine-tuning המקורי של Bedrock הוא on-demand בלבד — בחר SageMaker JumpStart לאימון מותאם אישית כשיר ל-spot כאשר התקציב שולט.
הקצאת הוצאות Bedrock על פני צוותים או קווי מוצרים.
החל תגי הקצאת עלויות למשאבי Bedrock (Provisioned Throughput, מודלים מותאמים אישית, ערימות יישומים). הפעל תגים ב-Billing → Cost Allocation Tags. דוחות מפורטים לפי תג.
נטר את חביון הפעלת Bedrock, נפח אסימונים ושגיאות.
CloudWatch metrics תחת `AWS/Bedrock`: `InvocationLatency`, `InputTokenCount`, `OutputTokenCount`, `Invocations`, `InvocationClientErrors`, `InvocationServerErrors`, `InvocationThrottles`. הגדר אזעקות על חביון p95 ושיעורי שגיאות.
כ-100 שיחות ביום, שאלות נפוצות פשוטות; מזער עלויות.
Bedrock on-demand עם המודל המוכשר הקטן ביותר (Titan Text Lite, Claude Haiku, או Nova Micro). Lambda + API Gateway HTTP API. ללא KB אם השאלות הנפוצות מתאימות ל-system prompt; KB קטן על Aurora pgvector אם נדרש.
קביעת גודל Provisioned Throughput עבור עומס עבודה יציב ב-Bedrock.
מדוד שיא אסימוני קלט + פלט לשנייה על תעבורת צללים. Bedrock מפרסם תפוקה ליחידת מודל; הקצה `ceil(שיא TPS / TPS ליחידה)` יחידות. אמת עם תעבורת צללים לפני התחייבות.
למה: הקצאת חסר גורמת לחניקה; הקצאת יתר מבזבזת את ההתחייבות השעתית. קביעת גודל אמפירית על תעבורת צללים היא הגישה האמינה היחידה.
הקצאת עלות Bedrock לכל יישום או צוות בחשבון משותף.
צור פרופילי הסקה ליישומים (application inference profiles) לכל יישום, צרף תגי הקצאת עלויות (לדוגמה `application=chatbot-X`, `team=marketing`). כל הפעלה מתייחסת ל-ARN של הפרופיל; Cost Explorer מפרט את ההוצאות לפי תג.
השווה שלושה מודלי בסיס במשימת סיכום; רוצה הערכה אוטומטית וניתנת לשחזור.
משימות הערכת מודלים של Amazon Bedrock (אוטומטיות). ספק מערך נתוני prompt; Bedrock מריץ כל מודל ומדווח על BLEU, ROUGE, BERTScore בתוספת רעילות / דיוק היכן שרלוונטי.
ציוני ROUGE נראים גבוהים אך קוראים אנושיים אומרים שהסיכומים מחמיצים נקודות מפתח.
עבור להערכה מבוססת אדם של Bedrock עם מדדים מותאמים אישית (רלוונטיות, שלמות, נאמנות). הגדר רובריקה, נתב דגימה לכוח אדם, צבור ציונים.
למה: מדדי חפיפה לקסיקלית (BLEU, ROUGE) מחמיצים נאמנות סמנטית. הערכה אנושית היא אמת המידה למשימות סובייקטיביות.
נדרשת הערכה בקנה מידה, וניתנת לשחזור אך סקירה אנושית בלבד איטית/יקרה מדי.
הערכת Bedrock LLM-as-a-judge. מודל חזק מדרג תגובות מול רובריקה; התוצאות מתואמות היטב עם סוקרים אנושיים ורצות תוך דקות לעומת ימים.
סיכומי תיק השקעות שנוצרו חייבים להתאים במדויק לנתונים במסמך המקור.
הגבל יצירה: טמפרטורה נמוכה (0–0.2), הוראות prompt מחמירות ("צטט מספרים מילולית מהמקור"), בדיקת ביסוס הקשרי של Guardrails על הפלט, regex/parser לאחר יצירה המאמת מספרים מול המקור.
למה: גם עם RAG מבוסס, מודלים מנסחים מחדש מספרים. שכבות מרובות (prompt + ביסוס + parser) לוכדות את המקרים הנותרים.
RAG מחזיר לעיתים קרובות "אין לי מספיק מידע" אפילו עבור נושאים המכוסים ב-KB.
בדוק עקבות שליפה: ציוני גושים, ספירת גושים שנשלפו, יישור שאילתה-לגוש. תיקונים נפוצים: אפשר חיפוש היברידי, הגדל top-k, כוונן גודל גוש, עבור ל-semantic chunking, אפשר ניסוח מחדש של שאילתות, הורד את סף הרלוונטיות.
הסוכן מחזיר תמחור מיושן גם לאחר סנכרון KB אחרון; מקור הנתונים הוא S3 עם גרסאות.
אמת שה-IngestionJob האחרון נמצא בסטטוס `COMPLETE` וש-`documentsModified` משקף את האובייקטים החדשים. גרסאות פירושן שגרסאות לא עדכניות עדיין יכולות להיות באינדקס אם מקור הנתונים אינו מוגבל לגרסאות עדכניות בלבד — וודא את מסנן מקור הנתונים וסנכרן מחדש.
סוכן משאבי אנוש חושף מדי פעם מידע על שכר של עובדים אחרים כאשר נשאל בערמומיות.
צמצם את הוראות הסוכן ("ענה רק על הנתונים של המשתמש המבקש"), הגבל את קבוצת הפעולה באמצעות תכונות סשן הכוללות את מזהה המשתמש, הגבל את IAM על ה-Lambda התומך בקבוצת הפעולה כדי לשאול רק את הרשומות של המשתמש עצמו, הוסף נושא אסור ב-Guardrails על שאילתות שכר בין משתמשים.
להפעלות Bedrock יש עליות חביון p95 לסירוגין.
בדוק את `InvocationThrottles` (פגיעות במגבלת קצב) ו-`ModelLatency` ב-CloudWatch; הפעל מעקב AWS X-Ray על ה-Lambda הקורא; בדוק את CloudWatch Logs Insights עבור קריאות כלים איטיות או שליפת KB. הפחת באמצעות הסקה בין-אזורית, מודל קטן יותר, שמירת prompt במטמון, או עיבוד באצווה.
העבר מ-Claude v2 ל-Claude 3.5 Sonnet ללא רגרסיות.
הרץ משימת הערכה של Bedrock המשווה את שניהם על סט promptים מייצג. לאחר מכן תעבורת צללים בייצור: שלח את אותו קלט לשניהם, השווה פלטים במצב לא מקוון. קדם עם דגל תכונה של AppConfig ב-10% ← 50% ← 100%.
הרץ Bedrock Model Evaluation כחלק מ-CI/CD בכל שינוי תצורת מודל.
השתמש ב-API `CreateEvaluationJob`. הגדר מערך נתונים ב-S3, מעריכים (מובנים או מותאמים אישית), ומודלים יעד. בצע polling על מצב המשימה; קדם כאשר `COMPLETED` עם מדדים מעל ספים.
למה: ממשק המשתמש של הסטודיו מיועד לפעולות חד פעמיות; ה-API הוא הדרך היחידה לשערי הערכה אוטומטיים וניתנים לחזרה.
הימנע מרגרסיות איכות בעת שדרוג מודל הבסיס בייצור.
שמור על סט בדיקות רגרסיה אצור: 100–500 promptים מייצגים עם פלטים צפויים (או רובריקות). הרץ באמצעות Bedrock Model Evaluation בכל החלפת מודל. חסום קידום אם הציונים יורדים מעל סף מוגדר.
מדוד אם המודל בוחר את הכלי הנכון עם הטיעונים הנכונים בצ'אט המשתמש בכלים.
בנה מערך מתויג: prompt + בלוק(ים) צפויים של `toolUse`. הרץ באמצעות מעריך מותאם אישית המבצע השוואה בין שם כלי בפועל לעומת שם כלי צפוי + טיעוני JSON. עקוב אחר דיוק/זכירות לכל כלי.
למה: מדדים לקסיקליים (BLEU) מחמיצים אם הסוכן הפעיל את הפעולה הנכונה. דיוק השימוש בכלים הוא המדד הנכון לעומסי עבודה מבוססי סוכנים.
