הגדרת מגבלות תקציב לסוכני AI ב-Paperclip

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

בקרת הוצאות של סוכני AI: נקודות דליפה וסיבות

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

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

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

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

מה נותן ניהול מגבלות וכללי קריאות

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

הפחתת התפרצויות שיא

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

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

קיצור זמן הטיפול בתקלות

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

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

דרכים להגבלת קריאות: השוואת גישות

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

מגבלות נוקשות מול מכסות אדפטיביות

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

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

מגבלות בצד הפלטפורמה ובצד השירות

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

שלבי הגדרת מגבלות ומכסות בסביבה שלכם

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

  1. סקר קריאות. אוספים אילו סוכנים, תרחישים ומשימות רקע פונים למודלים, באיזו תדירות ועל איזה היקף הקשר. בפלט — מרשם קריאות עם בעלים ועדיפות: בלעדיו המגבלה תקטע את הנדרש ותפספס את המיותר.
  2. סכימת מגבלות. מגדירים רמות — תרחיש, סוכן, יחידה — וסוגי הגבלות: היקף יומי, תדירות פניות, עומק שרשרת החשיבה. כאן גם מקבעים את ההתנהגות בעת מיצוי המכסה: מעבר למודל חסכוני, תור או עצירה.
  3. הגדרת כללים. מעבירים את הסכימה לתצורה: מפתחות גישה, מונים, חלונות מיצוע, ספי אזהרה. הכללים מנוהלים בגרסאות יחד עם הקוד, ולכן שינוי מגבלה עובר בדיקה, ולא נערך בפאנל «בעין».
  4. בדיקה בסביבת בדיקות לפני מסירה. מריצים תרחישים עם ספים מונמכים בכוונה ומוודאים שמופעל בדיוק מה שתוכנן: הסוכן עובר למצב גיבוי, ולא נופל עם שגיאה. בנפרד בודקים את החזרה לאחור ואת ההתנהגות בזמן התפרצות עומס.
  5. העברת נהלים. מוסרים מפת קריאות, סכימת מגבלות, סדר שינוי ספים וטיפול בתקלות. המהנדסים שלכם מכאן והלאה משנים מכסות בעצמם, בלי לפנות אלינו.

הרכב האספקה: תצורות, סכימות ונהלים

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

סכימות וכללי דחיות

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

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

מקרה בוחן: איך התפרצויות שיא הפסיקו לשבור את השירות

מה היה לפני

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

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

מה היה אחרי

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

זמן ההתאוששות התקצר לדקות: במקום התערבות ידנית פועלים הגבלת קצב ואיפוס אוטומטי של החלון. שיעור הקריאות שנדחו נשמר ברמה של 1–3% והוא חל על משימות רקע, ולא על משימות משתמשים. סוג הדחיות «מיצוי המגבלה הכללית» נעלם מהיומנים — במשך רבעון לא היה אף אירוע של אי-זמינות.

מה לעשות אם המגבלות כבר הוגדרו ידנית?

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

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

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

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

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

ספקות טכניים לגבי מגבלות ויומנים

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

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

האם המגבלה תפעל בטעות?

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

האם התשובה תיקטע באמצע?

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

האם ניתן להגדיר מגבלות שונות עבור צוותים ויחידות?

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

מה בדיוק נרשם ביומן הקריאות?

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

כיצד נבחנות מחדש המכסות?

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

נדון במשימה: נרכיב סכימת מגבלות לסביבה שלכם

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

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

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

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

תארו את המשימה והראו את ההגדרות הנוכחיות — נחזור עם הערכה ותוכנית.