מה הסטנדרט ממטב
הסטנדרט נועד למקסם את המינוף התפעולי של המפעיל/ה, תוך שמירה על רמת אמון קבועה. AGI אישי מחזיק את ההקשר המלא של המפעיל/ה, ומיישם עליו ישירות יכולת מכונה. ארבע השכבות הן התנאים למצב הזה: שום דבר שהמפעיל/ה יודע/ת או מחליט/ה לא הולך לאיבוד (זיכרון), העבודה קורית גם איתו וגם בלעדיו (תפעול), אפשר לסמוך על הפלט בלי לצפות במנגנון (אמינות), וכל חודש שימוש הופך את החודש הבא לטוב יותר במקום לרועש יותר (הצטברות). כל קריטריון מודד התקדמות לעבר אחת מארבע ההבטחות האלה. אינטליגנציה אינה המטרה: המודל מספק אותה, וחוק המשקל מאפס כל דבר שמודל גולמי כבר עושה. גם נפח האוטומציה אינו המטרה: מערכת אוטונומית שהמפעיל/ה לא יכול/ה לסמוך עליה או לבקר אותה מקבלת ציון נמוך יותר, כי מנוף שצריך לבדוק שוב ביד הוא לא מנוף. במקום שבו שני קריטריונים מושכים זה נגד זה, אוטונומיה מול שליטה או נפח פלט מול אימות, ההכרעה נוטה לכיוון האמון של המפעיל/ה.
איך הניקוד עובד
- כל קריטריון מנוקד מ-0 עד 4 לפי הדקדוק המוצהר שלו (להלן).
- הציונים מוחלטים ולעולם לא מותאמים למטרות המערכת או לתקציבה.
- מערכת רשאית לפרסם פרופיל יעד: רמת יעד לכל קריטריון עם סיבה מתוך אוצר מילים קבוע (out of scope for my stage, cost exceeds benefit at my volume, conflicting design goal). הפער בין הנמדד ליעד הוא ציבורי וניתן לערעור; המדידה עצמה אינה.
- כל ציון נושא תג ראיה: verified (המעריך ראה את זה עובד), documented (העדות קיימת, לא הופעלה), inferred (ראיה עקיפה), unknown (אין ראיה בכל כיוון). unknown לעולם לא מתעגל לאפס; הוא נשאר בלתי-ידוע.
- ציון משוקלל = רמה × משקל, מסוכם. המשקלים מגיעים כנתונים; מי שחולק עליהם משקלל מחדש ובונה מחדש, לא מתווכח על החשבון.
- מזהי הקריטריונים יציבים: מספר תמיד מצביע על אותו קריטריון. קריטריונים נוספים, נערכים, משוקללים מחדש או יוצאים משימוש; מזהה שיצא משימוש לעולם לא נעשה בו שימוש חוזר, ולכן בטבלאות השכבה יש פערים. המזהים שיצאו משימוש רשומים להלן.
- תת-הקבוצות החוצות שכבות (להלן) מדווחות כסכומי ביניים נוספים, לעולם לא במקום סכומי השכבות. תת-קבוצה לא משנה משקל, רמה או מזהה.
- תת-קבוצת ״יוזמה עצמית״ (O10 עד O13, 72 מתוך 644 הנקודות) מנוקדת מול עדויות שהמערכת עצמה מייצרת והמפעיל/ה פוסק/ת לגביהן. אותן עדויות מתעדות מה המערכת העלתה. שום דבר בהן לא קובע מה היה עליה להעלות ופספסה, כי המקור היחיד לרשימה הזאת הוא המפעיל/ה. תת-הקבוצה מדווחת כסכום ביניים משלה מסיבה זו, והרמות שלה אינן ניתנות לשחזור עצמאי על ידי צד שלישי. O3, O4 ו-O9 נושאים צורה חלשה יותר של אותה מגבלה. קריטריון עוזב את הקבוצה הזאת כשמבחן מספק את המכנה החסר; הדקדוק עובר ל-measured והמזהה נשאר.
מאיפה הקריטריונים מגיעים
כל קריטריון מכריז על origin, הרשום בטבלאות השכבה להלן.
- function: נגזר ממה שהיכולת חייבת לעשות, נכתב לפני שהסתכלו על מוצר כלשהו שמיישם אותה.
- adversarial:<worldview>: נכתב מנקודת המבט של ארכיטקטורה יריבה, כדי שהסט לא יעוצב על ידי ההנחות של בונה אחד. המעבר חובה ב-20% מהקריטריונים ועומד כרגע על 12 מתוך 41 (29%). נקודות המבט שבהן נעשה שימוש עד כה: graph-memory, open-knowledge-metabolism, benchmarked-retrieval, graceful-degradation, plain-files, measured-autonomy, hooks-not-prompts, predictable-cost, tested-harness, confidence-scored-instincts.
- practice+research: שני מקורות מזינים אותו. הראשון הוא התחום עצמו. AGI אישי נשען על מחקר AGI ועל עבודת למידת המכונה שמתחתיו, על ספרות המחשוב-האמין שנותנת לשכבה השלישית את הגדרת המילה שלה, ועל הגל הנוכחי של מפעילים/ות שדוחפים/ות התאמה אישית והתאמה בקצב שהמודלים נעים בו, בפומבי. השני הוא מערכת פועלת: AGI אישי בהיקף ייצור למפעיל בודד, בשימוש יומיומי, שבה כל אחת מהיכולות האלה מתמודדת עם עבודה אמיתית ולא רק מתוארת. קריטריונים המתויגים כך נוקבים ביכולות ששני המקורות מתייחסים אליהן כנושאות משקל. הם משוקללים לפי אותו חוק כמו כל קריטריון אחר, כי חשיבות היא שאלה נפרדת מתרומה מעל מודל גולמי. O3 הוא המקרה הבולט: מוערך מאוד, ומשוקלל 2.
דקדוקי הרמות
default: סולם האוטומציה
- 0 נעדר. היכולת לא קיימת בשום צורה.
- 1 ידני ואד-הוק. המפעיל/ה עושה זאת ביד כשהוא/היא נזכר/ת.
- 2 שיטתי אך לא מאומת. קיים מנגנון מוגדר והוא בשימוש, אבל שום דבר לא בודק שהוא עובד.
- 3 אוטומטי עם ראיה. פועל בלי המפעיל/ה, וקיימת לפחות עדות אחת הניתנת לביקורת שמראה שהוא רץ ועבד.
- 4 אוטומטי, נמדד לאורך זמן, שורד כישלון. פועל בלי המפעיל/ה, שיעור ההצלחה שלו נעקב, וקיימת ראיה שהוא המשיך לעבוד (או נכשל בקול רם והתאושש) דרך לפחות כישלון אמיתי אחד.
measured: סולם המדידה
- 0 נעדר. היכולת לא קיימת.
- 1 קיים, איכות לא ידועה. היכולת עובדת אנקדוטלית; אף אחד לא מדד אותה.
- 2 נבדק נקודתית ולא רשמית. מישהו בדק את האיכות ביד, בלי שיטה שאדם אחר יכול לחזור עליה.
- 3 נמדד פעם אחת, מספר נאמר. שיטה שניתנת לחזרה הפיקה לפחות מספר קונקרטי אחד (recall@k, שיעור שגיאות, שיעור פגיעה), והמספר כתוב.
- 4 נמדד באופן רציף. המספר נעקב לאורך זמן, המגמה נראית, וסף מסוים מפעיל פעולה כשהוא מתדרדר.
evidence: סולם עדות השיפור (שכבת הצטברות)
- 0 לא ניתן לטעון לשיפור. שום דבר לא מצטבר.
- 1 אנקדוטלי. המפעיל/ה מרגיש/ה שהמערכת השתפרה; שום עדות לא תומכת בזה.
- 2 מנגנון בלי הוכחה. קיים מנגנון שנועד לייצר שיפור (לכידת משוב, חילוץ דפוסים), אבל שום עדות לא מראה שהמערכת באמת השתפרה.
- 3 עדות אחת שניתנת לביקורת מוכיחה שיפור. זר יכול לבחון עדות קונקרטית של ״לפני/אחרי״ ולהסכים שהמערכת השתפרה.
- 4 הוכחה מתמשכת ושיטתית. מדידות חוזרות לאורך זמן מראות שהשיפור נמשך, ושיטת המדידה עצמה מפורסמת יחד עם הטענה.
תת-קבוצות חוצות-שכבות
תת-קבוצה מסמנת קריטריונים שעונים יחד על שאלה אחת בזמן שהם נמצאים בשכבות שונות. סכום הביניים שלה מדווח בנוסף לסכומי השכבות, לעולם לא במקומם. השייכות מוצהרת לכל קריטריון בנתונים.
תת-קבוצת ״יוזמה עצמית״: האם המערכת פרואקטיבית?
4 קריטריונים: O10, O11, O12, O13. 72 מתוך 644 הנקודות.
עבודה שהמערכת יוזמת בעצמה: ההתחייבויות של המפעיל/ה עצמו/ה מועלות לפני שמישהו שואל (O10), סטייה והזדמנות מועלות בלי הנחיה (O11), מטרות מוחזקות לאורך סשנים במקום להיאמר מחדש (O12), ושיעור הקבלה שקובע אם היוזמה שווה משהו (O13).
מדוע מדווחת כסכום ביניים משלה: מערכת יכולה לנקד גבוה בכל שכבת התפעול בלי לזוז ראשונה אף פעם, וההבדל הזה חשוב יותר ממה שסכום השכבה מראה. סכום הביניים מפריד בין השניים, ו-O13 שומר עליו כן על ידי מדידת כמה מהפלט היוזמתי המפעיל/ה באמת רצה/רצתה. תת-קבוצה זו נושאת גם את הראיה החלשה ביותר בסטנדרט: העדויות שלה מתעדות מה המערכת העלתה ולא יכולות לתעד מה היא פספסה, כך שהרמות שלה אינן ניתנות לשחזור עצמאי על ידי צד שלישי.
תת-קבוצת ״בעלות״: מה שורד אם כל ספק נסוג?
2 קריטריונים: M10, D8. 28 מתוך 644 הנקודות.
בעלות היא המילה ״אישי״ ממומשת באופן מכני: זיכרון בפורמטים פתוחים שהמפעיל/ה יכול/ה לקחת איתו/ה לכל מקום (M10), ושרידה מוכחת של שינוי במעלה הזרם שהמפעיל/ה לא בחר/ה (D8).
מדוע מדווחת כסכום ביניים משלה: שני הקריטריונים האלה נמצאים בשכבות שונות כי כל אחד מרוויח את משקלו מסיבה שונה: M10 מעצב איך הזיכרון נשמר, D8 בוחן מה קורה כשההחלטה של מישהו אחר משנה את הקרקע מתחת למערכת. יחד הם עונים על השאלה אם המערכת באמת שייכת למפעיל/ה או רק מושאלת מספק, על הציר היחיד שבו מערכת קטנה מנצחת מערכת מרוכזת. זהו סכום ביניים ולא שכבה חמישית כי עצמאות לא משנה מה המערכת יכולה לעשות היום, וזה אותו טיעון שקובע את משקלו של M10 על 3. תיקיית טקסט פשוט שלא עושה כלום מקבלת כאן ציון גבוה וכמעט אפס בכל מקום אחר, וזו התוצאה הנכונה.
מזהי קריטריונים שיצאו משימוש
קריטריון יכול להיות מוסר מהסטנדרט. המזהה שלו לעולם לא נעשה בו שימוש חוזר, כך שמספר תמיד מצביע על אותה שאלה בכל גרסה. זו הסיבה שבטבלאות השכבה להלן יש פערים.
| ID | היה | הוסר | למה |
|---|
| M11 | ״הפרדת סודיות״ (Confidentiality separation) | טרום-פרסום | מחוץ לתחום. הגנה על חומר רגיש היא עניין שונה מהעצמאות מספק שתת-קבוצת ״בעלות״ מודדת. |
| D7 | ״עמדת אבטחה ופרטיות״ (Security and privacy posture) | טרום-פרסום | מחוץ לתחום, על אותו טיעון כמו M11. |
| D9 | ״מצב חדר-נקי״ (Clean-room mode) | טרום-פרסום | מחוץ לתחום, על אותו טיעון כמו M11. |
שכבה: זיכרון (Memory)
מה המערכת אוספת ושומרת על המפעיל/ה ועל עולמו: עובדות, תחומי עניין, פרויקטים, החלטות, העדפות, התחייבויות. השכבה מנקדת את הזיכרון עצמו, מהלכידה דרך הייצוג, האחזור, ההיגיינה והבעלות. מודל גולמי לא זוכר כלום בין סשנים; כל מה שבשכבה הזאת הוא ארכיטקטורה.
| ID | קריטריון | משקל | דקדוק | עלות | origin |
|---|
| M1 | כיסוי לכידה (Capture coverage) | 5 | default | בינונית | function |
| M2 | אוטומטיות הלכידה (Capture automaticity) | 4 | default | בינונית | function |
| M3 | ייצוג מובנה (Structured representation) | 3 | default | בינונית | adversarial:graph-memory |
| M4 | מקור לכל עובדה (Provenance per fact) | 3 | default | בינונית | adversarial:graph-memory |
| M5 | רמת ביטחון ועדכניות לכל טענה (Confidence and freshness per claim) | 4 | default | בינונית | adversarial:open-knowledge-metabolism |
| M6 | דיוק אחזור, נמדד (Retrieval precision, measured) | 4 | measured | גבוהה | adversarial:benchmarked-retrieval |
| M7 | איכות אחזור בקנה מידה (Retrieval quality at scale) | 4 | measured | גבוהה | adversarial:graph-memory |
| M8 | מסלול התדרדרות באחזור (Retrieval degradation path) | 3 | default | נמוכה | adversarial:graceful-degradation |
| M9 | תיקון ושכחה (Correction and forgetting) | 3 | default | בינונית | function |
| M10 | בעלות על הנתונים וניידותם (Data ownership and portability) | 3 | default | נמוכה | adversarial:plain-files |
M1כיסוי לכידה (Capture coverage)
משקל5דקדוקdefaultשכבת עלותבינוניתoriginfunction
האם ידע על המפעיל/ה (החלטות, העדפות, פרויקטים, התחייבויות, קשרים) נלכד על פני המשטחים שבהם הוא באמת מופיע: שיחות, מסמכים, פגישות, הודעות, גלישה?
במונחים פשוטים: זו שאלת חומר הגלם. ידע על מפעיל/ה מופיע על משטחים רבים במהלך שבוע רגיל: סשנים של צ'אט, מסמכים, תמלולי פגישות, הודעות, גלישה. הקריטריון הזה שואל כמה מהמשטחים האלה באמת מזינים את מאגר הזיכרון. מערכת שזוכרת רק מה שהמפעיל/ה מקליד/ה ביד לאפליקציית פתקים מקבלת ציון נמוך גם אם הפתקים מצוינים, כי רוב הידע אף פעם לא הגיע אליה. מערכת שצינורות הלכידה שלה שולפים החלטות משיחות, קולטות הקלטות פגישות, ומתייקות מסמכים שנשמטו אליה, מכסה את המשטחים שבהם ידע באמת חי.
עדות הוכחה לרמה 4: מפת כיסוי המפרטת את משטחי הלכידה, בתוספת עדות מדגמית שעובדות המופיעות במשטחים האלה הגיעו למאגר בתוך חלון זמן מוגדר.
למה המשקל הזה: מודל גולמי לא לוכד שום דבר; כל עובדה זכורה קיימת רק כי הארכיטקטורה תפסה אותה. זהו יסוד השכבה: כל מה שבהמשך שולף רק את מה שהלכידה תפסה.
M2אוטומטיות הלכידה (Capture automaticity)
משקל4דקדוקdefaultשכבת עלותבינוניתoriginfunction
האם הזיכרון נוצר כתוצר לוואי של עבודה רגילה (hooks של סשן, צינורות קליטה, חילוץ מתוזמן), או רק כשהמפעיל/ה נזכר לתייק דברים?
במונחים פשוטים: האם הזכירה עולה משמעת מהמפעיל/ה. כישלון נראה כמו מערכת תיוק מצוינת שתלויה בכך שהמפעיל/ה יזכור לתייק: היא עובדת שבועיים ומתמוטטת תחת חודש עמוס. הצלחה נראית כמו זיכרון שנוצר כתוצר לוואי של עבודה: סשן נגמר ו-hook מחלץ את ההחלטות שהתקבלו בו; קובץ מגיע לתיבה ועבודה מתוזמנת מעבדת אותו. המבחן פשוט: אם המפעיל/ה מפסיק/ה לעשות כל דבר מכוון סביב זיכרון, האם הלכידה נמשכת?
עדות הוכחה לרמה 4: לוגים המראים זיכרון שנכתב על ידי טריגרים אוטומטיים לאורך תקופה ממושכת, בלי שום שלב תיוק ידני בנתיב.
למה המשקל הזה: לכידה ידנית קורסת תחת חיים אמיתיים; תרומת הארכיטקטורה היא הסרת המשמעת מהמפעיל/ה מהלולאה. משוקלל אחד מתחת לכיסוי כי מפעיל/ה חרוץ/ה יכול/ה לפצות חלקית ביד.
M3ייצוג מובנה (Structured representation)
משקל3דקדוקdefaultשכבת עלותבינוניתoriginadversarial:graph-memory
האם עובדות נשמרות כיחידות אטומיות עם קישורים מפורשים או יחסים מסוגים, כך ששאלות החוצות כמה עובדות (״אילו לקוחות נגעו ב-X ומה הבטחתי להם״) ניתנות למענה, במקום כגושי פרוזה לא מובחנים?
במונחים פשוטים: איך עובדות מעוצבות ברגע שהן נשמרות. עמוד פרוזה על לקוח מכיל עובדות, אבל הן לכודות בפסקה. ייצוג מובנה אומר שכל עובדה היא יחידה אטומית המחוברת לאחרות באמצעות קישורים מפורשים או יחסים מסוגים, כך ששאלה החוצה כמה עובדות (״אילו לקוחות נגעו בנושא X, ומה הבטחתי לכל אחד מהם״) ניתנת למענה על ידי מעקב אחר קישורים במקום קריאה מחדש של הכול. ארכיון של חיבורים כתובים היטב נכשל בזה גם כשכל עובדה נוכחת, כי שום דבר לא יכול לעבור בו. שימו לב להבדל מ-M4: M3 עוסק באיך עובדות מתחברות זו לזו; M4 עוסק במקור של כל עובדה.
עדות הוכחה לרמה 4: מסמך סכמה או קונבנציה, בתוספת שאילתה רב-שלבית פתורה שנענתה על ידי מעבר על יחסים שמורים.
למה המשקל הזה: מודל חזק יכול לשחזר חלקית מבנה מתוך פרוזה בזמן שאילתה, במחיר טוקנים. התרומה של הארכיטקטורה אמיתית אך חלקית, ולכן זה שוקל בטווח הביניים ולא גבוה.
M4מקור לכל עובדה (Provenance per fact)
משקל3דקדוקdefaultשכבת עלותבינוניתoriginadversarial:graph-memory
האם כל עובדה שמורה מתחקה אחורה למקורה ותאריכה, ברמת ההיגד ולא ברמת הקובץ?
במונחים פשוטים: כל היגד שמור צריך להיות מסוגל לענות ״מי אמר, ומאיזה מועד״. מקור ברמת הקובץ (״העמוד הזה מסכם את הפודקאסט ההוא״) חלש יותר ממקור ברמת ההיגד (״הטענה הספציפית הזאת הגיעה מהדקה 34״ או ״מהמייל של מרץ״). הרווח הוא יכולת ביקורת: כשעובדה שמורה מתגלה כשגויה, מקור ברמת ההיגד מאפשר לעקוב אליה, לשפוט אם המקור נקרא לא נכון או שהעולם השתנה, ולתקן כל עותק נגזר. בלעדיו, עובדה שגויה היא פשוט שגויה, בלי שביל.
עדות הוכחה לרמה 4: מדגם אקראי של עובדות שמורות, שכל אחת ניתנת לפתרון עד מקור מתוארך שזר יכול לבדוק.
למה המשקל הזה: מודל גולמי לא יכול לצטט מאיפה הגיעה אמונה; המאגר יכול. התרומה אמיתית, אבל המקור הוא אמצעי לאמון ולא יכולת שהמפעיל/ה מרגיש/ה יומיומית, ולכן זה שוקל בטווח הביניים.
M5רמת ביטחון ועדכניות לכל טענה (Confidence and freshness per claim)
משקל4דקדוקdefaultשכבת עלותבינוניתoriginadversarial:open-knowledge-metabolism
האם עובדה שמורה נושאת עד כמה היא בטוחה ועד כמה היא טרייה? האם קיים כלל מחייב שמסווג כל עובדה לפי איך היא מזדקנת (נצחית; מתוארכת עם חלון תוקף; ניתנת לביטול, כלומר תקפה עד שנסתרת ומוחלפת רק באישור המפעיל/ה; או הפניה למקור חי), עם מדיניות לכל מחלקה ולינטר או ביקורת שתופס הפרות?
במונחים פשוטים: עובדות מזדקנות בקצבים שונים, ומאגר שמתייחס אליהן באחידות יטען בביטחון את עולם השנה שעברה. הצלחה אומרת שכל עובדה מסווגת לפי איך היא מזדקנת, לכל מחלקה יש מדיניות, ולינטר אוכף אותה. דוגמאות למחלקות: עובדות תנודתיות כמו הכנסה עסקית חודשית פוקעות לפי לוח זמנים; עובדות מחזוריות כמו פרטי קשר של לקוח דורשות אימות מחדש כל כמה שנים; עובדות ניתנות לביטול כמו מסקנות מחקר נשארות תקפות עד שנסתרות בעדות חדשה, ומוחלפות רק באישור המפעיל/ה; עובדות נצחיות כמו החלטות עבר לעולם לא פוקעות; עובדות-הפניה כמו המחיר הנוכחי של כלי נשמרות כהפניה למקור חי במקום כערך מועתק. הלינטר הוא מה שהופך את זה לאמיתי: הוא מסמן את נתון ההכנסה בן החודשיים ואת איש הקשר שלא אומת שלוש שנים.
עדות הוכחה לרמה 4: הכלל בכתב, בתוספת פלט לינטר או ביקורת המראה תפיסה של טענות מיושנות או לא מסומנות.
למה המשקל הזה: זיכרון מיושן גרוע מאין זיכרון: מודל גולמי בלי זיכרון לא יכול לטעון בביטחון שעובדות אשתקד הן עדכניות, אבל מאגר נאיבי כן. הארכיטקטורה חייבת למנוע באופן פעיל מצב כישלון שהיא עצמה יצרה.
M6דיוק אחזור, נמדד (Retrieval precision, measured)
משקל4דקדוקmeasuredשכבת עלותגבוההoriginadversarial:benchmarked-retrieval
כשהמערכת פונה לזיכרון עבור משימה, האם העובדות הנכונות חוזרות? לא ״האם קיים חיפוש״ אלא ״האם איכות האחזור נמדדה ונאמרה כמספר״ (recall@k, דיוק, דיוק תשובה על סט מבחן).
במונחים פשוטים: הפער שנמדד כאן הוא בין תכונה מותקנת ליכולת ידועה. הצלחה נראית כמו סט קבוע של שאלות עם עובדות נכונות ידועות, מורץ מול המאגר, ומפיק מספר: recall@10 של 85 אחוז, או דיוק תשובה של 9 מתוך 10. כישלון נראה כמו אינדקס סמנטי שמדגים היטב ומעולם לא נוקד. בלי המספר, כל טענה בהמשך על כך שהמערכת ״יודעת״ דברים נשענת על אנקדוטה.
עדות הוכחה לרמה 4: מבחן אחזור עם שיטה ומספר מפורסמים, נעקב לאורך זמן.
למה המשקל הזה: אחזור הוא המקום שבו זכירה הופכת לשימושית; אחזור לא נמדד הוא תחושה, לא יכולת. למודל הגולמי אין ממה לשלוף, כך שכל היכולת היא ארכיטקטורה.
M7איכות אחזור בקנה מידה (Retrieval quality at scale)
משקל4דקדוקmeasuredשכבת עלותגבוההoriginadversarial:graph-memory
האם איכות התשובה נשמרת ככל שהמאגר גדל בסדר גודל, והאם עקומת ההתדרדרות ידועה ולא מונחת מראש?
במונחים פשוטים: אחזור שעובד על אלפיים מסמכים יכול להתדרדר בשקט על עשרים אלף: יותר כמעט-כפילויות, יותר פגיעות מיושנות, יותר שכנים סבירים אך שגויים. הקריטריון הזה שואל אם עקומת ההתדרדרות ידועה ולא מונחת: אותו מבחן מורץ בשני גדלי מאגר במרחק סדר גודל אחד מזה. הוא קיים כי מערכות זיכרון נמכרות על ההתנהגות שלהן בקנה מידה קטן ונחיות איתן בקנה מידה גדול.
עדות הוכחה לרמה 4: מדידות של איכות אחזור או תשובה בשני גדלי מאגר במרחק סדר גודל אחד, עם ההבדל נאמר.
למה המשקל הזה: כל ארכיטקטורת זיכרון עובדת על חמישים פתקים. הטענה הארכיטקטונית היא שביום 1,000 זה עדיין עובד; מערכת שמתדרדרת בשקט עם הצמיחה מבטלת את הטעם שבהצטברות בכלל.
M8מסלול התדרדרות באחזור (Retrieval degradation path)
משקל3דקדוקdefaultשכבת עלותנמוכהoriginadversarial:graceful-degradation
כשאינדקס, backend של embeddings, או שירות חיפוש נופל, האם האחזור נופל חזרה למשהו זול יותר (מילות מפתח, קטלוג), או שהזיכרון של המערכת נעלם למעשה?
במונחים פשוטים: מה נשאר מהזיכרון כשהשכבה החכמה נופלת. אם האחזור תלוי באינדקס embeddings או בשירות חיפוש, היום שבו הרכיב הזה נשבר הוא היום שבו הזיכרון של המערכת נעלם למעשה, אלא אם קיימת חלופה זולה יותר: קבצי טקסט פשוטים הניתנים לחיפוש לפי מילת מפתח, קטלוג קריא לבני אדם. הצלחה אומרת שהחלופה קיימת ובאמת הופעלה (הפילו את האינדקס ליום שלם ווידאו שהמערכת עדיין עונה). ארכיטקטורות שבהן המסלול הראשי כבר קבצים פשוטים עוברות כמעט מעצם הבנייה; ארכיטקטורות שבהן מסד וקטורי מת פירושו שכחה נכשלות.
עדות הוכחה לרמה 4: שרשרת חלופה מתועדת, בתוספת עדות לאירוע כשל בפועל או תרגיל שבו התשובות המשיכו לזרום.
למה המשקל הזה: תכונת חוסן של הזיכרון ולא יכולת חדשה. התרומה מעבר למודל הגולמי היא שמירה על יכולת קיימת בחיים תחת כישלון, ולכן זה שוקל בטווח הביניים.
M9תיקון ושכחה (Correction and forgetting)
משקל3דקדוקdefaultשכבת עלותבינוניתoriginfunction
האם המפעיל/ה יכול/ה לתקן או למחוק עובדה שמורה ולסמוך שהשינוי מתפשט: כפילויות מאוחדות, עמודים נגזרים מעודכנים, האמונה המתה מסומנת כמתה במקום לצוץ שוב מאוחר יותר?
במונחים פשוטים: הזיכרון חייב להיות ניתן לתיקון, והתיקונים חייבים להיות עמידים. כשהמפעיל/ה מוחק/ת או מתקן/ת עובדה שמורה, השינוי חייב להתפשט: כפילויות מאוחדות, עמודים נגזרים מעודכנים, האמונה המתה מסומנת כמתה. מצב הכישלון שנגדו זה מגן הוא העובדה-זומבי: מתוקנת במקום אחד, צצה שוב חודשים אחר כך מעותק לא מתוקן, עכשיו לובשת את הסמכות של הזיכרון.
עדות הוכחה לרמה 4: דוגמה עבודה: תיקון אחד נעקב דרך המאגר, מראה כל מקום שבו העובדה הישנה חיה ושאף אחד מהם עדיין לא טוען אותה.
למה המשקל הזה: מודל גולמי שוכח הכול, מה שכולל באופן טריוויאלי עובדות שגויות. המאגר יוצר את בעיית התמדת השגיאה וחייב לפתור אותה; התרומה תיקונית ולא תוספתית.
M10בעלות על הנתונים וניידותם (Data ownership and portability)
משקל3דקדוקdefaultשכבת עלותנמוכהoriginadversarial:plain-filesתת-קבוצהבעלות
האם הזיכרון נשמר בפורמטים פתוחים שהמפעיל/ה בבעלותו/ה, קריא בלי הכלי, ניתן לייצוא במלואו, וניתן לשימוש על ידי סביבת ריצה או מודל אחרים?
במונחים פשוטים: של מי הנתונים, באופן מכני. הצלחה אומרת שהזיכרון נשמר בפורמטים פתוחים שהמפעיל/ה יכול/ה לקרוא בלי הכלי, לייצא במלואם, ולמסור לסביבת ריצה או מודל אחרים: קבצי טקסט פשוטים בתיקייה שהמפעיל/ה שולט/ת בה. כישלון אומר שהזיכרון חי במאגר קנייני עם ייצוא חלקי או ללא ייצוא, כך שעזיבת הכלי פירושה השארת שנים של הקשר שהצטבר מאחור. זהו הקריטריון שקובע אם המפעיל/ה בבעלות המערכת או שהמערכת בבעלות המפעיל/ה.
עדות הוכחה לרמה 4: ייצוא מודגם או סביבת ריצה שנייה שעונה על שאלות מאותו מאגר.
למה המשקל הזה: הבעלות לא משנה מה המערכת יכולה לעשות היום; היא משנה מה שורד מחר. משוקללת בטווח הביניים כי ערכה תלוי בשינוי במעלה הזרם שהמפעיל/ה לא בחר/ה, וזה מה ש-D8 בוחן ישירות.
שכבה: תפעול (Operations)
מה המערכת עושה עם הזיכרון שלה על המפעיל/ה: עבודה מונעת-מטרה המבוצעת עם מיומנויות, סוכנים, שגרות ולולאות, מעוגנת בהקשר שהצטבר במקום תדריך חדש בכל פעם. שכבה זו מנקדת את הפעולה עצמה; האמינות של המנגנון עצמו תוך כדי פעולה שייכת לשכבת האמינות. תת-הקבוצה ״יוזמה עצמית״ מכסה עבודה שהמערכת מתחילה בעצמה; הציון שלה מדווח גם בנפרד.
| ID | קריטריון | משקל | דקדוק | עלות | origin |
|---|
| O1 | ביצוע מעוגן בהקשר (Context-grounded execution) | 5 | default | בינונית | function |
| O2 | אריזת מיומנויות ושימוש חוזר (Skill packaging and reuse) | 3 | default | נמוכה | function |
| O3 | הרחבת טווח (Range extension) | 2 | default | נמוכה | practice+research |
| O4 | שותפות רפלקטיבית (Reflective partnership) | 2 | default | נמוכה | practice+research |
| O5 | שגרות מתוזמנות (Scheduled routines) | 5 | default | בינונית | function |
| O6 | נוכחות מקבילה (Parallel presence) | 4 | default | בינונית | function |
| O7 | פעולה בהיעדרות (Action in absence) | 5 | default | גבוהה | practice+research |
| O8 | הפעלה חיצונית (External actuation) | 3 | default | בינונית | function |
| O9 | שיקול דעת בהסלמה (Escalation judgment) | 4 | default | בינונית | function |
| O10 | מעקב אחר התחייבויות (Commitment tracking) | 5 | default | בינונית | practice+research |
| O11 | העלאת סטיות והזדמנויות (Drift and opportunity surfacing) | 4 | default | גבוהה | practice+research |
| O12 | אחיזה במטרה (Goal grip) | 5 | default | בינונית | practice+research |
| O13 | דיוק היוזמה (Initiative precision) | 4 | measured | בינונית | function |
| O14 | אופק האוטונומיה (Autonomy horizon) | 4 | measured | גבוהה | adversarial:measured-autonomy |
O1ביצוע מעוגן בהקשר (Context-grounded execution)
משקל5דקדוקdefaultשכבת עלותבינוניתoriginfunction
האם המערכת מבצעת משימות באמצעות ההקשר שהצטבר אצל המפעיל/ה (מטרות, העדפות, היסטוריה, פרויקטים נוכחיים) בלי תדריך מחדש, והאם העיגון נראה בפלט ולא רק נטען?
במונחים פשוטים: התכלית של הקשר שהצטבר היא שתוצרי העבודה מגיעים כבר מעוגנים בו. בקשו מהמערכת לנסח הצעה, והיא צריכה לחזור בקול של המפעיל/ה, מודעת להיסטוריית התמחור עם אותו לקוח, מכבדת אילוצים שנקבעו לפני חודשים, בלי פסקת תדריך מחדש. העיגון חייב להיראות בפלט, לא רק להיטען בשיווק. מודל גולמי מפיק טיוטה כללית טובה; התרומה של הארכיטקטורה היא כל מה שהופך אותה לטיוטה של המפעיל/ה הזה/זו.
עדות הוכחה לרמה 4: תוצרים זה לצד זה: אותה משימה בוצעה קר לעומת דרך המערכת, עם ההבדלים התלויים בהקשר מזוהים.
למה המשקל הזה: זהו הציר בין שכבת הזיכרון לכל השאר: זיכרון שלעולם לא מגיע לעבודה הוא אחסון, לא מערכת הפעלה. מודל גולמי צריך את התדריך המלא בכל פעם מחדש.
O2אריזת מיומנויות ושימוש חוזר (Skill packaging and reuse)
משקל3דקדוקdefaultשכבת עלותנמוכהoriginfunction
האם ידע מקצועי ארוז כנהלים בעלי שם וניתנים לשימוש חוזר (מיומנויות, תבניות, ספרי משחק) שניתנים לגילוי כשהם רלוונטיים, במקום להיגזר או להיכתב מחדש בכל פעם?
במונחים פשוטים: האם ידע מקצועי מצטבר כנהלים בעלי שם וניתנים לשימוש חוזר (מיומנויות, תבניות, ספרי משחק) שעולים כשהם רלוונטיים, או נגזר מחדש כל פעם. המבחן: כשסוג משימה חוזר על עצמו, האם המערכת פונה לנוהל ארוז שמקודד את הלקחים מהסבבים הקודמים, או שהאיכות תלויה עד כמה המפעיל/ה מנסח/ת את הפרומפט היום? יכולת גילוי היא חלק מהקריטריון: ספריית מיומנויות שאף אחד לא מפעיל היא סחורה על המדף.
עדות הוכחה לרמה 4: מלאי מיומנויות בתוספת לוגי הפעלה המראים שימוש חוזר חוזר, ומנגנון גילוי שטוען את המיומנות הנכונה בלי לטעון את כולן.
למה המשקל הזה: מודל גולמי יכול לבצע רוב הנהלים האלה כשהוא מונחה היטב; התרומה של הארכיטקטורה היא עקביות ועלות גזירה מחדש אפסית, לא היכולת עצמה.
O3הרחבת טווח (Range extension)
משקל2דקדוקdefaultשכבת עלותנמוכהoriginpractice+research
האם המערכת מרחיבה באופן אמין את המפעיל/ה לתחומים שמעולם לא תרגל (עיצוב, קוד, ניתוח נתונים), עם שערי איכות קבועים לכל תחום, כך שהתוצאות תלויות ולא מזדמנות?
במונחים פשוטים: האם המערכת מרחיבה באופן אמין את המפעיל/ה לתחומים שמעולם לא תרגל: מי שאינו מעצב משגר מצגות, מי שאינו מתכנת משגר תוכנה עובדת. המילה המרכזית היא אמין. תוצאה טובה אחת היא המודל; תוצאות אמינות דורשות שערי איכות קבועים לכל תחום (מעבר QA לעיצוב, סוויטת בדיקות), כך שהמפעיל/ה יכול/ה לסמוך על פלט בתחום שבו הוא/היא לא יכול/ה לשפוט את הפרטים בעצמו/ה.
עדות הוכחה לרמה 4: תוצרים שנמסרו בתחומים שהמפעיל/ה לא מתרגל/ת, שכל אחד עבר שער איכות מוגדר לתחום שלו.
למה המשקל הזה: רוב הכוח הזה שייך למודל הגולמי: חלון צ'אט כבר כותב קוד ומנתח נתונים. הארכיטקטורה מוסיפה עקביות ושערי איכות, שכבה דקה אך אמיתית, ולכן זה שוקל נמוך למרות היותו אחת היכולות המוערכות ביותר אישית. המשקל הולך אחר חוק התרומה-מעל-מודל-גולמי, לא אחר ערך מורגש.
O4שותפות רפלקטיבית (Reflective partnership)
משקל2דקדוקdefaultשכבת עלותנמוכהoriginpractice+research
האם הקשר עמוק שהצטבר מאפשר דיאלוג שהמפעיל/ה לא יכול/ה לקיים עם זר: רפלקציה, תובנה עצמית, למידה, הוראה בהקשר המתאימה למה שהמפעיל/ה כבר יודע?
במונחים פשוטים: התועלת השיחתית של הקשר עמוק: דיאלוג שהמפעיל/ה לא יכול/ה לקיים עם זר. רפלקציה השואבת מחודשים של החלטות מתועדות, הוראה שמתאימה את עצמה למה שהמפעיל/ה כבר יודע/ת במקום להתחיל מאפס, העלאת דפוסים (״עשית את הפשרה הזאת שלוש פעמים והתחרטת פעמיים״). מודל גולמי יכול להיות בן-שיח מבריק; הוא לא יכול להיות שותף עם היסטוריה משותפת.
עדות הוכחה לרמה 4: תוצרי סשן שבהם התרומה של המערכת תלויה באופן מוכח בידע לאורך זמן על המפעיל/ה (הפניות להחלטות עבר, דפוסים על פני חודשים), לא בשיחה הנוכחית בלבד.
למה המשקל הזה: מודל גולמי כבר בן-שיח רפלקטיבי חזק בתוך שיחה אחת. התרומה של הארכיטקטורה היא עיגון לאורך זמן, שמעמיק את הדיאלוג אך לא יוצר את היכולת.
O5שגרות מתוזמנות (Scheduled routines)
משקל5דקדוקdefaultשכבת עלותבינוניתoriginfunction
האם עבודות חוזרות רצות ללא השגחה לפי לוח זמנים ומפיקות פלט שבאמת נעשה בו שימוש, במקום פלט שמצטבר בלי שקוראים אותו?
במונחים פשוטים: האם עבודות חוזרות רצות ללא השגחה לפי לוח זמנים, ומפיקות פלט שמישהו באמת משתמש בו? הצלחה אומרת רשומות מתזמן אמיתיות (cron, launchd) עם היסטוריית ריצה, נראות כישלון, והתאוששות מחלונות שהוחמצו: התדריך הבוקרי שמופיע כל יום כולל הימים שהמפעיל/ה שכח/ה שהוא קיים. כישלון אומר ״שגרות״ שהן למעשה המפעיל/ה שנזכר/ת לבקש.
עדות הוכחה לרמה 4: הגדרות מתזמן בתוספת לוגי ריצה בתוספת עדות לצריכה (פלטים שנעשה בהם שימוש, שפעלו לפיהם, או שהזינו עבודה אחרת).
למה המשקל הזה: מודל גולמי לא עושה כלום בין פרומפטים. עבודה שקורית בלי נוכחות המפעיל/ה היא התרומה הארכיטקטונית הברורה ביותר, והיא המנגנון מאחורי רוב השכבה הזאת.
O6נוכחות מקבילה (Parallel presence)
משקל4דקדוקdefaultשכבת עלותבינוניתoriginfunction
האם כמה זרמי עבודה יכולים להתקדם במקביל בלי שהמפעיל/ה מטפל/ת בכל אחד: סוכנים מקבילים, עבודות ברקע, צינורות בתור שלא מתנהלים בטור מאחורי שיחה אחת?
במונחים פשוטים: האם המערכת יכולה להיות ביותר ממקום אחד בו-זמנית: עבודות ברקע שרצות בזמן שהמפעיל/ה עובד/ת על משהו אחר, סוכנים מקבילים על תת-משימות עצמאיות, ערוץ מהטלפון של המפעיל/ה בזמן שהוא/היא רחוק/ה מהמכונה. זה ההבדל בין כלי שהמפעיל/ה מפעיל/ה לבין צוות שפועל לצידו.
עדות הוכחה לרמה 4: לוגים של ריצות חופפות ללא השגחה על זרמי עבודה נבדלים, עם התוצרים שלהן.
למה המשקל הזה: להיות בכמה מקומות בו-זמנית בלתי אפשרי עבור המפעיל/ה ועבור סשן צ'אט בודד; הארכיטקטורה מייצרת את זה. שלב אחד מתחת לשגרות כי היא נבנית עליהן.
O7פעולה בהיעדרות (Action in absence)
משקל5דקדוקdefaultשכבת עלותגבוההoriginpractice+research
אם המפעיל/ה נעדר/ת לכמה ימים, האם המערכת ממשיכה לפעול: שגרות רצות, עבודה נכנסת ממוינת, החלטות מעל סמכותה נכנסות לתור בצורה נקייה עד לחזרתו/ה, שום דבר לא נרקב בשקט?
במונחים פשוטים: הצורה החזקה ביותר של תפעול: תוצרים קיימים כי המערכת פעלה בזמן שהמפעיל/ה נעדר. התדריך נכתב לפני שהוא/היא התעורר/ה; תיבת הדואר עובדה במהלך הלילה; בדיקת התקינות רצה ותיקנה משהו ביום שאף אחד לא פתח סשן. מנוקד לפי עדות (תוצרים עם חותמות זמן, לוגי דופק), לא לפי היכולת התיאורטית.
עדות הוכחה לרמה 4: תרגיל היעדרות מתועד: התקופה, מה רץ, מה נכנס לתור, מה נשבר, והמצב שאליו המפעיל/ה חזר/ה.
למה המשקל הזה: המבחן החזק ביותר לארכיטקטורה כולה: הוא דורש זיכרון עמוק, שיקול דעת לגבי גבולות סמכות, ותחזוקה עצמית בו-זמנית. מודל גולמי לא יכול לשרוד שעה אחת של היעדרות. תפעול יומיומי הופך את זה ליכולת שהיעדרה מורגש ראשון.
O8הפעלה חיצונית (External actuation)
משקל3דקדוקdefaultשכבת עלותבינוניתoriginfunction
האם המערכת יכולה לפעול על העולם מעבר לקבצים שלה עצמה (לשלוח, לפרסם, לפרוס, להזמין, לקנות) דרך שערי הרשאה שמבחינים בין פעולות הפיכות לבלתי-הפיכות?
במונחים פשוטים: האם המערכת יכולה לפעול על העולם החיצוני: לשלוח, לפרסם, לפרוס, להזמין, לקנות. מערכת שרק קוראת ומנסחת טיוטות משאירה את הקילומטר האחרון למפעיל/ה בכל פעם. הקריטריון הזה ממוקם בכוונה במתח מול הממשל (O9, D6): מערכת יכולה לנקד באופן מתון כאן במכוון כי המפעיל/ה שלה רוצה שכל פעולה יוצאת תהיה מגודרת. זו התכלית של יעד מוצהר עם סיבת קונפליקט-עיצוב.
עדות הוכחה לרמה 4: הגדרות השער כקוד או תצורה, בתוספת לוגים של פעולות מגודרות כולל לפחות ניסיון אחד שנחסם נכון.
למה המשקל הזה: רתמות מודרניות כבר מספקות שימוש בכלים; התרומה של הארכיטקטורה היא משמעת השערים, לא הטווח. טווח לא מגודר הוא סיכון, ולכן הקריטריון מודד את השערים.
O9שיקול דעת בהסלמה (Escalation judgment)
משקל4דקדוקdefaultשכבת עלותבינוניתoriginfunction
האם המערכת יודעת מתי לעצור ולשאול: האם היא מבחינה בין מה שמותר לה להחליט לבין מה ששייך למפעיל/ה, והאם היא שומרת על הגבול הזה תחת לחץ להיות מועילה?
במונחים פשוטים: האם המערכת יודעת מה מותר לה לעשות לבד ומה דורש את המפעיל/ה, והאם הגבול הזה אמיתי. הצלחה אומרת נתיבי סמכות מקודדים (לפעול בחופשיות; לפעול ולסמן; עצירה קשה ולשאול), עם נתיב העצירה הקשה נאכף בקוד ולא נשאר לשיקול הדעת של המודל ברגע האמת. מצבי הכישלון בשני הצדדים יקרים: מערכת ששואלת על הכול היא כלי, ומערכת ששואלת על כלום היא סיכון.
עדות הוכחה לרמה 4: לוג הסלמה המראה עצירות נכונות בגבול הסמכות, ואפס חציות גבול, לאורך תקופה ממושכת.
למה המשקל הזה: אוטונומיה בלי כלל עצירה היא סיכון, לא יכולת. למודל הגולמי אין מודל סמכות עומד של מפעיל/ה ספציפי/ת לעצור מולו; הארכיטקטורה מספקת אותו.
O10מעקב אחר התחייבויות (Commitment tracking)
משקל5דקדוקdefaultשכבת עלותבינוניתoriginpractice+researchתת-קבוצהיוזמה עצמית
האם המערכת מעלה את ההבטחות וההתחייבויות של המפעיל/ה עצמו/ה ללא הנחיה: פריטים שעברו את המועד מועלים ברגע הנכון, ולא נשמרים ברשימה שאף אחד לא פותח מחדש?
במונחים פשוטים: הבטחות הן העובדות בעלות הסיכון הגבוה ביותר שמפעיל/ה מייצר/ת. הקריטריון הזה שואל אם התחייבויות (ללקוחות, לעמיתים, לעצמו/ה) נעקבות עם בעלים ומועד יעד, והאם המערכת ממשיכה מעצמה בלי הנחיה: מעלה את מה שעבר את המועד, מסמנת את הבסיכון לפני המועד ולא אחריו. לכידת התחייבויות לרשימה שאף אחד לא קורא מחדש מקבלת ציון נמוך; בדיקה מתוזמנת שמעלה דגלים מקבלת ציון גבוה.
עדות הוכחה לרמה 4: מקרים של העלאה ללא הנחיה שנעקבים מההתחייבות המקורית ועד התזכורת שהועלתה ועד התוצאה.
למה המשקל הזה: זכירת מה שהמפעיל/ה הבטיח/ה והעלאת זה בלי שנשאלים היא ארכיטקטורה טהורה: מודל גולמי לא יודע שהובטחה הבטחה, ורשימה שהמפעיל/ה חייב/ת לפתוח מחדש היא המפעיל/ה עובד/ת, לא המערכת.
O11העלאת סטיות והזדמנויות (Drift and opportunity surfacing)
משקל4דקדוקdefaultשכבת עלותגבוההoriginpractice+researchתת-קבוצהיוזמה עצמית
האם המערכת שמה לב, ללא הנחיה, כשהמציאות סוטה מהמטרות המוצהרות של המפעיל/ה (פלט שסוטה מהמיצוב, עולם של לקוח שמשתנה, פתח ששווה לפעול לפיו) ומעלה זאת?
במונחים פשוטים: האם המערכת שמה לב לדברים שהמפעיל/ה לא שאל עליהם: התפתחויות רלוונטיות בתחומו/ה, סטייה בפלט של המערכת עצמה, הזדמנות שתואמת את מטרותיו/ה. הצלחה דורשת מסירה ללא הנחיה עם עדויות (סריקה יומית או שבועית שרצה לפי לוח הזמנים שלה), לא את היכולת לחקור כשמבקשים. זו פונקציית מגדל התצפית: ערכה הוא בדיוק שאף אחד לא היה צריך לזכור לשאול.
עדות הוכחה לרמה 4: התערבויות ללא הנחיה מסוג זה שתועדו, עם מה שהפעיל כל אחת ומה קרה אחר כך.
למה המשקל הזה: דורש להחזיק את מטרות המפעיל/ה כמצב עומד ולהשוות את העולם מולן ברציפות. ארכיטקטורה לחלוטין; משוקלל אחד מתחת למעקב התחייבויות כי שיפוט סטייה מטושטש יותר מהבטחה מתוארכת, ופספוסים עולים בתשומת לב.
O12אחיזה במטרה (Goal grip)
משקל5דקדוקdefaultשכבת עלותבינוניתoriginpractice+researchתת-קבוצהיוזמה עצמית
האם המערכת מתווכחת בחזרה עם עומד: מצטטת את המטרות וההחלטות המתועדות של המפעיל/ה עצמו/ה מול הוראה נוכחית שסותרת אותן? האם עוצמת האחיזה ניתנת להגדרה על ידי המפעיל/ה, והאם קיים לוג התערבות עם תוצאות?
במונחים פשוטים: האם המערכת מחזיקה את מטרות המפעיל/ה בחוזקה או רק מציגה אותן. לוח מחוונים שמראה את מטרת הרבעון בזמן שכל סשן סוטה למה שצץ מקבל ציון נמוך. אחיזה אומרת שהמטרה המוצהרת באמת מבנה התנהגות: סשנים נפתחים מכוונים אליה, בקשות לא קשורות מסומנות בעדינות כלא-קשורות-למטרה, והנוקשות מכוילת לכל מטרה בנפרד (חלק מהמטרות מצדיקות משיכה חזקה בחזרה, אחרות הערה קלה). הקריטריון הזה נולד מתצפית שאף אחד לא בנה אחיזה מכוילת, וזה כשלעצמו אינפורמטיבי.
עדות הוכחה לרמה 4: תצורת האחיזה, בתוספת לוג התערבות המראה דחיפות נגד, פסיקות המפעיל/ה, ושיעור הפגיעה.
למה המשקל הזה: מודל גולמי מתכופף לכל מה שהפרומפט הנוכחי רוצה; להחזיק את המטרה המוצהרת של אתמול מול הדחף של היום דורש מטרות עמידות ואי-הסכמה מורשית, שתיהן ארכיטקטורה טהורה. דיוק בלי דחיפה נגדית הוא הכישלון שתפעול יומיומי חושף: מערכת שמבצעת את הבקשה ומאבדת את המטרה.
O13דיוק היוזמה (Initiative precision)
משקל4דקדוקmeasuredשכבת עלותבינוניתoriginfunctionתת-קבוצהיוזמה עצמית
מתוך כל מה שהמערכת מעלה ללא הנחיה, כמה מזה הצדיק את תשומת הלב של המפעיל/ה? האם היחס אות-רעש של היוזמה נמדד, כך שעבודה ללא הנחיה מרוויחה אמון במקום להפוך לספאם?
במונחים פשוטים: בקרת האיכות על היוזמה. מערכת שפועלת ללא הנחיה (O10, O11, O12) יכולה להיות שותפה או מטרד, וההבדל מדיד: מתוך הפעולות וההצעות ללא הנחיה, איזה חלק המפעיל/ה מקבל/ת? הצלחה אומרת ששיעור הקבלה באמת נעקב והמערכת מסתגלת (פחות התערבויות, טובות יותר, לאורך זמן). זרם יוזמה לא נמדד שמרגיש רועש מקבל ציון נמוך לא משנה כמה מתוחכמים הטריגרים.
עדות הוכחה לרמה 4: שיעור קבלה נמדד עבור התערבויות ללא הנחיה, נעקב לאורך זמן.
למה המשקל הזה: יכולות ללא הנחיה שוות רק כמו הדיוק שלהן; מערכת רועשת מאמנת את המפעיל/ה להתעלם ממנה, ומאפסת בשקט את O10 עד O12. הקריטריון הזה הופך את תת-הקבוצה לניתנת להפרכה.
O14אופק האוטונומיה (Autonomy horizon)
משקל4דקדוקmeasuredשכבת עלותגבוההoriginadversarial:measured-autonomy
כשהמפעיל/ה נעדר/ת, כמה זמן המערכת ממשיכה להפיק פלט שימושי לפני שנדרש אדם? האם האופק הזה נמדד ונעקב, ולא מונח מראש?
במונחים פשוטים: O5, O6 ו-O7 שואלים אם עבודה קורית בלי המפעיל/ה. אף אחד מהם לא שואל לכמה זמן. מערכת שרצה ללא השגחה עשרים דקות ומערכת שרצה ללא השגחה שלושה שבועות שתיהן מספקות את ״פועלת בהיעדרות״, והמרחק ביניהן הוא רוב המרחק בקטגוריה הזאת. הקריטריון הזה שואל את המספר: התקופה הארוכה ביותר ללא השגחה שהפלט שלה נשאר שימושי בלי התערבות, נקבעת על ידי תצפית ולא כוונה. הצלחה אומרת שהאופק הוא מספר עוקב עם סף, ונסיגה בו מבחינים בה.
עדות הוכחה לרמה 4: אופק מוצהר עם שיטתו (התקופה הארוכה ביותר ללא השגחה שהפלט שלה התקבל בלי התערבות), לפחות שתי מדידות מתוארכות, וסף שמפעיל בדיקה כשהאופק מתקצר.
למה המשקל הזה: הציר שהתחום מתחרה עליו כרגע, וזה שבו הטענות מתנפחות הכי מהר, כי ״פועל אוטונומית״ נאמר באותה מילה על ידי מערכת ששורדת שעה ואחת ששורדת חודש. האופק של מודל גולמי הוא תור אחד בלבד, כך שכל מה שמעל זה הוא תרומת הארכיטקטורה. מוחזק מתחת למשקל של O7 כי אופק נמדד מניח מראש את יכולת ההיעדרות ש-O7 כבר מנקד.
שכבה: אמינות (Dependability)
האם אפשר לסמוך על הפלט בלי לצפות במנגנון שמייצר אותו. המילה נושאת את המובן ההנדסי שלה: אספקת שירות שאפשר לתת בה אמון מוצדק, מה שהופך ניטור עצמי, תיקון עצמי, שלמות, אימות, שליטה, שקיפות עלות וראיה לכולם חלק מתכונה אחת. כל מה שכאן הוא המערכת מכוונת אל עצמה. למודל גולמי אין מנגנון לתחזק; כל קריטריון כאן קיים כי הארכיטקטורה קיימת.
| ID | קריטריון | משקל | דקדוק | עלות | origin |
|---|
| D1 | ניטור עצמי (Self-monitoring) | 5 | default | בינונית | function |
| D2 | תיקון עצמי בגבולות בטוחים (Self-repair within safe bounds) | 4 | default | בינונית | function |
| D3 | גיבוי ושחזור בדוק (Backup and tested restore) | 5 | default | נמוכה | function |
| D4 | ביקורת דיוק הזיכרון (Memory accuracy audit) | 4 | measured | בינונית | function |
| D5 | אימות פלט (Output verification) | 4 | default | בינונית | function |
| D6 | כללים מחייבים מול מייעצים (Enforced versus advisory rules) | 4 | default | נמוכה | adversarial:hooks-not-prompts |
| D8 | חוסן מול שינוי ספק (Vendor-change resilience) | 4 | default | גבוהה | practice+research |
| D10 | שליטה בהתנהגות (Behavior control) | 3 | default | בינונית | practice+research |
| D11 | שקיפות ההרכבה (Assembly transparency) | 4 | default | בינונית | practice+research |
| D12 | נראות ושליטה בעלות (Cost observability and control) | 3 | default | נמוכה | adversarial:predictable-cost |
| D13 | בדיקות על המערכת עצמה (Tests on the system itself) | 4 | default | בינונית | adversarial:tested-harness |
D1ניטור עצמי (Self-monitoring)
משקל5דקדוקdefaultשכבת עלותבינוניתoriginfunction
האם המערכת יודעת מתי המנגנון שלה עצמו נכשל? האם כשלים שקטים (שגרה שהפסיקה לירות, צינור שמפיק פלט ריק) מתגלים על ידי המערכת ולא מתגלים על ידי המפעיל/ה?
במונחים פשוטים: האם המערכת יודעת מתי היא שבורה. הצלחה אומרת שהמערכת בודקת את הדופק שלה עצמה לפי לוח זמנים: שיעורי כישלון שגרה, עבודות מתות, חיישני-כשל-שקט, עם ממצאים עולים למקום שבו המפעיל/ה באמת יראה/תראה אותם. החלופה היא לגלות שצינור מת לפני שלושה שבועות רק כשהיעדרו סוף סוף כואב. ניטור שמת בעצמו בשקט נכשל בקריטריון; לשם כך קיימים חיישני הכשל.
עדות הוכחה לרמה 4: תצורת ניטור בתוספת לפחות אירוע אמיתי אחד שבו המערכת גילתה את הכישלון שלה עצמה לפני המפעיל/ה.
למה המשקל הזה: מפעל לא מנוטר מתדרדר באופן בלתי נראה ומוציא את אמון המפעיל/ה בלי ידיעתו/ה. מותקן זה לא אותו דבר כמו עובד; רק המערכת עצמה יכולה לצפות בתדירות הנדרשת.
D2תיקון עצמי בגבולות בטוחים (Self-repair within safe bounds)
משקל4דקדוקdefaultשכבת עלותבינוניתoriginfunction
כשהמערכת מגלה תקלה, האם היא יכולה לתקן בעצמה את קבוצת המשנה הבטוחה וההפיכה, והאם היא מנתבת נכון את קבוצת המשנה המסוכנת למפעיל/ה במקום לנסות אותה?
במונחים פשוטים: צעד אחד מעבר לניטור: כשהבדיקה מוצאת בעיה בטוחה והפיכה (תור תקוע, מטמון מיושן, ריצה שהוחמצה), האם המערכת מתקנת ומשאירה שביל עדות, או פותחת כרטיס למפעיל/ה? הגבול חשוב: תיקון עצמי צריך לכסות את השגרתי וההפיך, ולהסלים את המסוכן. מערכת שלא מתקנת כלום מעמיסה על המפעיל/ה; אחת שמתקנת מעבר לסמכותה היא סיכון.
עדות הוכחה לרמה 4: לוג תיקון המראה תיקונים אוטומטיים שהוחלו, כל אחד בתוך גבול פעולה-בטוחה מוצהר, ומקרים מסוכנים שהוסלמו.
למה המשקל הזה: גילוי בלי תיקון עדיין צורך את זמן המפעיל/ה בכל תקלה. התרומה היא אוטונומיה מוגבלת מעל הבריאות של המערכת עצמה; אחד מתחת לניטור כי תיקון בלי גילוי בלתי אפשרי.
D3גיבוי ושחזור בדוק (Backup and tested restore)
משקל5דקדוקdefaultשכבת עלותנמוכהoriginfunction
האם מצב המערכת (זיכרון, תצורה, קוד) עובר גרסאות ומגובה אוטומטית, והאם השחזור באמת נבדק ולא רק הונח?
במונחים פשוטים: הקריטריון נקרא בכוונה ״גיבוי ושחזור בדוק״ כי החצי השני הוא המקום שבו מערכות נכשלות. עותקים שמעולם לא שוחזרו הם תקווה, לא גיבוי. הצלחה אומרת שגיבויים קיימים, רצים אוטומטית, ושחזור באמת תורגל מקצה לקצה (תיקייה חדשה, שחזור הכול, אימות שזה עובד), עם התרגול חוזר לפי לוח זמנים. הפער בין ״יש לנו גיבויים״ ל״שחזרנו מגיבויים״ הוא המקום שבו אובדן נתונים חי.
עדות הוכחה לרמה 4: תצורת גיבוי בתוספת תרגיל שחזור מתועד עם תוצאתו.
למה המשקל הזה: הזיכרון שהצטבר במערכת הוא הרכיב היחיד שאי אפשר לגזור מחדש במחיר כלשהו; שנים של הקשר יכולות להיעלם בכישלון דיסק אחד. התרגול משוקלל יחד עם הגיבוי כי נתיב ההתאוששות הוא החצי שנכשל בפועל.
D4ביקורת דיוק הזיכרון (Memory accuracy audit)
משקל4דקדוקmeasuredשכבת עלותבינוניתoriginfunction
האם הזיכרון השמור נדגם מול המציאות לפי לוח זמנים, עם שיעור שגיאה נאמר ונעקב? לא ״האם המאגר מאורגן״ אלא ״האם הוא באמת נכון״.
במונחים פשוטים: זיכרון הוא נכס רק אם הוא אמיתי. הקריטריון הזה שואל האם טענות שמורות עוברות ביקורת שיטתית מול המציאות: בדיקת עובדות מדגמית לפי לוח זמנים (שולפים עשרים עובדות שמורות, מאמתים כל אחת, מנקדים את המאגר), עם עובדות שגויות מתוקנות דרך המנגנון של M9. בלעדיה, הביטחון בזיכרון נשען על ההנחה ששום דבר שנלכד לא היה שגוי ושום דבר אמיתי לא התיישן, ושתי ההנחות שגויות בכל גודל מאגר אמיתי.
עדות הוכחה לרמה 4: שיטת ביקורת, תוצאות מדגם, ומספר שיעור שגיאה נעקב על פני ביקורות.
למה המשקל הזה: זיכרון שגוי בביטחון הוא מצב הכישלון הידוע של כל מערכת בקטגוריה הזאת. הביקורת היא מה ששומר על שכבת הזיכרון כנה: בלי שיעור שגיאה נדגם, כל ציון בשכבה ההיא מודד את הצורה של המאגר ולא את אמיתותו.
D5אימות פלט (Output verification)
משקל4דקדוקdefaultשכבת עלותבינוניתoriginfunction
האם המערכת מאמתת את תוצרי העבודה שלה עצמה מול קריטריוני קבלה מוגדרים לפני מסירה (עובדות נבדקות, קישורים נפתחים, רינדורים נצפים), או שהמפעיל/ה נושא/ת בכל נטל הבדיקה?
במונחים פשוטים: האם תוצרי עבודה עוברים דרך שערים לפני שהם מגיעים למפעיל/ה או לעולם. דוגמאות: סקריפט QA לעיצוב על כל תוצר מרונדר, סוויטת בדיקות על כל שינוי קוד, בדיקת קול על כל טיוטה שיוצאת בשם המפעיל/ה. הקריטריון מבחין בין מערכות שמאמתות פלטים למערכות שפולטות אותם; בהיקף, פלט לא מאומת מעביר בשקט את נטל הבדיקה בחזרה למפעיל/ה.
עדות הוכחה לרמה 4: הגדרות שער לכל סוג פלט בתוספת לוגים המראים פלטים שנחסמו או תוקנו על ידי השערים.
למה המשקל הזה: אם המפעיל/ה חייב/ת לבדוק הכול מחדש, המערכת חוסכת זמן ייצור ומוציאה אותו בחזרה בבדיקה. אימות עצמי הוא מה שממיר נפח פלט לפלט מהימן.
D6כללים מחייבים מול מייעצים (Enforced versus advisory rules)
משקל4דקדוקdefaultשכבת עלותנמוכהoriginadversarial:hooks-not-prompts
מתוך הכללים שהמערכת טוענת שהיא עוקבת אחריהם, כמה חסומים בקוד (hooks, שערים, הרשאות) לעומת מבוקשים בפרוזה שהמודל עשוי להתעלם ממנה? האם הסט המחייב מזוהה ומכוון?
במונחים פשוטים: ההבחנה הנושאת-משקל של השכבה כולה: האם כלל נאכף בקוד, או כתוב בפרוזה ומושאר לשיקול הדעת של המודל? ״לעולם אל תבצע commit לסודות״ בקובץ הוראות הוא מייעץ; hook שחוסם את ה-commit הוא מחייב. כללים מייעצים נכשלים בדיוק כשזה חשוב: סשנים ארוכים, קשב מתדרדר, קלט אדברסרי. ספרו את הכללים שישרדו יום רע של המודל; אלה הם המחייבים.
עדות הוכחה לרמה 4: מלאי שממפה כל כלל טענתי למנגנון האכיפה שלו, בתוספת בדיקה שלילית המראה כלל מחייב באמת חוסם.
למה המשקל הזה: הוראות בהקשר הן הצעות, לא תצורה; כל מערכת בקטגוריה הזאת משווקת כללים, והם נבדלים בדיוק כאן. התרומה של הארכיטקטורה היא הפיכת מדיניות מוצהרת לפיזיקה.
D8חוסן מול שינוי ספק (Vendor-change resilience)
משקל4דקדוקdefaultשכבת עלותגבוההoriginpractice+researchתת-קבוצהבעלות
האם המערכת שורדת שינויים שאינה שולטת בהם: החלפת מודל, עדכון רתמה, שינוי מדיניות ספק? האם ניידות לסביבת ריצה אחרת מודגמת ולא רק מונחת מתוך פורמטים פתוחים?
במונחים פשוטים: כל AGI אישי רץ על המודל וסביבת הריצה של מישהו אחר, ושינויים במעלה הזרם קורים בלי לשאול. הקריטריון הזה שואל מה קורה אז: האם קיימת סביבת ריצה חלופית, האם שכבות הנתונים והמיומנויות ניידות מספיק כדי להגר, האם משהו מזה נוסה בפועל. מערכת שהזיכרון שלה הוא קבצים פשוטים (M10) מחזיקה את חומר הגלם לחוסן, אבל ניידות לא בדוקה היא תוכנית, לא יכולת. שילוב עמוק עם ספק בודד אולי הפשרה הנכונה; הקריטריון הזה מתמחר אותה.
עדות הוכחה לרמה 4: תרגיל החלפה או שדרוג מתועד: השינוי, מה נשבר, זמן ההתאוששות, והמערכת פועלת על החלופה.
למה המשקל הזה: היסוד של המערכת מושכר מספק שיכול לשנות אותו בכל יום, ושינוי אחד במעלה הזרם יכול להשבית את כל המפעל. חוסן כאן הוא ההבדל בין הפסקת חשמל לסוף. ה-origin כולל אובדן כמעט אמיתי משינוי רתמה במעלה הזרם.
D10שליטה בהתנהגות (Behavior control)
משקל3דקדוקdefaultשכבת עלותבינוניתoriginpractice+research
האם המפעיל/ה יכול/ה לשלוט באופי של המודל, לא רק בידע שלו: לרסן נטיות מאומנות כמו חנופה וחיפוש הסכמה, ולאמת עם בדיקות שהשליטה באמת מחזיקה?
במונחים פשוטים: מודל מגיע עם אופי מאומן: הוא מסכים בקלות, מחניף, ומרכך חדשות רעות. הנטיות האלה בלתי נראות בהדגמה ויקרות לאורך חודשים, כי מערכת שאומרת למפעיל/ה מה שהוא/היא רוצה לשמוע משחיתה כל שיפוט שנבנה על הפלט שלה. הקריטריון הזה שואל האם המפעיל/ה יכול/ה לרסן אותן, ומה מוכיח שהריסון מחזיק. הצלחה אומרת בדיקות התנהגותיות: תרחישים כתובים שמזמינים את הנטייה (תוכנית חלשה שמוצגת בביטחון, טענה שגויה שנטענת כעובדה) מנוקדים לפי אם המערכת דחפה נגד, מורצים מחדש אחרי כל עדכון מודל או רתמה. כללי פרוזה בתוספת כוונות טובות מקבלים ציון נמוך כי שום דבר לא מזהה סטייה בין ספר הכללים להתנהגות בפועל.
עדות הוכחה לרמה 4: מנגנון השליטה בתוספת תוצאות בדיקה התנהגותית המדגימות את הנטייה המרוסנת, מורצות מחדש אחרי עדכוני מודל או רתמה.
למה המשקל הזה: ספקים מכווננים אופי באופן גלובלי; המפעיל/ה יורש/ת אותו. הארכיטקטורה יכולה רק לנטרל חלקית את האימון, כך שהתרומה אמיתית אך מוגבלת, וחייבת להיות מאומתת כדי להתקיים בכלל.
D11שקיפות ההרכבה (Assembly transparency)
משקל4דקדוקdefaultשכבת עלותבינוניתoriginpractice+research
האם המפעיל/ה יכול/ה להרים את המכסה על כל תשובה: לראות מה נטען, מה ירה, מה נשלף, מה היה דלוק וכבוי כשהתשובה הופקה?
במונחים פשוטים: כשהמערכת עונה, מה נכנס לתשובה? שקיפות הרכבה אומרת שהמפעיל/ה יכול/ה להרים את המכסה על תשובה נתונה: אילו קבצי זיכרון נטענו, אילו מיומנויות ירו, אילו כללים היו בתוקף. זהו הקריטריון האנטי-קופסה-שחורה: בלעדיו, ניפוי תשובה שגויה פירושו ניחוש, ואמון בתשובה טובה פירושו אמונה. צינורות אחזור שקטים שמזריקים הקשר לא רשום הם מצב הכישלון.
עדות הוכחה לרמה 4: עקבה לכל תשובה (מניפסט הקשר, לוג אחזור, רשימת רכיבים פעילים) שזר יכול לעקוב אחריה.
למה המשקל הזה: בלי נראות למה שהרכיב תשובה, המפעיל/ה לא יכול/ה לנפות תשובות שגויות, לבקר פרטיות, או לכייל אמון; כל קריטריון אמון אחר הופך לפולקלור לא ניתן לאימות. לצ'אט גולמי כמעט אין מה להסתיר; לארכיטקטורה יש.
D12נראות ושליטה בעלות (Cost observability and control)
משקל3דקדוקdefaultשכבת עלותנמוכהoriginadversarial:predictable-cost
האם ההוצאה נראית וניתנת להיגוי: עלות לכל שגרה ולכל תוצר שנמסר ידועה, עלות סרק ידועה, עבודות יקרות מסומנות לפני שהן רצות, תקציבים נאכפים במקום להתגלות בחשבון?
במונחים פשוטים: האם המפעיל/ה יודע/ת כמה המערכת עולה, לפני החשבונית. הצלחה אומרת שההוצאה נראית ברמת פירוט שימושית (ליום, לשגרה, לעבודה כבדה), עם ספים שמתריעים על חריגות במקום להסתמך על שהמפעיל/ה יבחין/תבחין. מערכת אוטונומית בלי נראות עלות היא בעלת תקציב בלתי מוגבל כברירת מחדל; הקריטריון הזה מתמחר בכנות ארכיטקטורות API-מדוד מול ארכיטקטורות בעלות קבועה.
עדות הוכחה לרמה 4: טלמטריית עלות לכל שגרה ותוצר, בתוספת מנגנון תקציב שמוצג עוצר ריצה שחורגת מתקציב.
למה המשקל הזה: מפעל שאי אפשר להרשות אותו נסגר בלי קשר לאיכות, אבל בקרת עלות היא תשתית הישרדות ולא יכולת. משקל בינוני: היעדרה הורג לאט, נוכחותה לא מוסיפה כלום לפלט.
D13בדיקות על המערכת עצמה (Tests on the system itself)
משקל4דקדוקdefaultשכבת עלותבינוניתoriginadversarial:tested-harness
האם המנגנון עובר בדיקות רגרסיה: האם ל-hooks, לשגרות, לאחזור ולשערים יש סוויטת בדיקות שרצה על שינוי ולפי לוח זמנים, או שרק הפלט אי פעם נשפט?
במונחים פשוטים: המערכת עצמה היא תוכנה: מיומנויות, hooks, מתזמנים, תצורה. הקריטריון הזה שואל האם השכבה הזאת נבדקת כמו תוכנה: סוויטת בדיקות ששוערת שינויים למיומנויות ול-hooks, בדיקות מתוזמנות שהתצורה תואמת את המציאות (כל עבודה מתוזמנת קיימת, כל קובץ מוזכר נוכח). בלעדיה, האינסטלציה של המערכת עצמה היא הקוד הכי פחות נבדק שהמפעיל/ה תלוי/ה בו יומיומית.
עדות הוכחה לרמה 4: סוויטת בדיקות המכסה את המנגנונים של המערכת עצמה, באינטגרציה רציפה או ריצה מתוזמנת, עם היסטוריית המעבר שלה.
למה המשקל הזה: מערכת שמשתנה שבועית בלי בדיקות מהמרת את המפעל על כל עריכה. בדיקות הן מה שמאפשר למערכת להתפתח בלי להישבר בשקט; הן שכבת האכיפה של האמינות עצמה.
שכבה: הצטברות (Compounding)
האם המערכת משתפרת ממה שהיא צוברת, ויכולה להוכיח זאת: יום 300 טוב מיום 30, על ראיה שאפשר לבקר. השכבה נקראת על שם המנגנון שהיא דורשת: רווחים נבנים על רווחים קודמים במקום להצטבר בקו ישר. זו הקטגוריה שרוב המערכות טוענות לה וכמעט אף אחת לא יכולה להדגים; דקדוק הראיה קיים כי הטענה זולה וההוכחה לא.
| ID | קריטריון | משקל | דקדוק | עלות | origin |
|---|
| C1 | תיקונים הופכים להתנהגות (Corrections become behavior) | 5 | evidence | בינונית | function |
| C2 | קידום דפוסים נלמדים (Learned-pattern promotion) | 4 | evidence | בינונית | adversarial:confidence-scored-instincts |
| C3 | הצטברות הזיכרון משתלמת (Memory accretion pays off) | 4 | measured | גבוהה | function |
| C4 | מדד יכולת אורכי (Longitudinal capability benchmark) | 5 | measured | גבוהה | function |
| C5 | שיפור בהכוונה עצמית (Self-directed improvement) | 4 | evidence | גבוהה | function |
| C6 | הישנות שגיאות פוחתת (Error recurrence declines) | 4 | measured | בינונית | function |
C1תיקונים הופכים להתנהגות (Corrections become behavior)
משקל5דקדוקevidenceשכבת עלותבינוניתoriginfunction
כשהמפעיל/ה מתקן/ת את המערכת, האם התיקון הופך לשינוי התנהגות עמיד: מקודד, מיושם בסשנים עתידיים, ומוכח כלא חוזר?
במונחים פשוטים: הלולאה הבסיסית של הצטברות: כשהמפעיל/ה מתקן/ת את המערכת, התיקון חייב להפוך להתנהגות עמידה, מקודד במקום שסשנים עתידיים ייתקלו בו, ומוכח כלא חוזר. המבחן אורכי: קחו תיקון מלפני כמה חודשים ובדקו אם הטעות הישנה עדיין קורית. מערכת שמקבלת את אותו תיקון שלוש פעמים לא לומדת; היא מופעלת.
עדות הוכחה לרמה 4: יומן תיקונים שעוקב אחר תיקונים בודדים עד לצורתם המקודדת ועד לסשנים מאוחרים יותר שבהם ההתנהגות הישנה הייתה קורית ולא קרתה, עם הישנות נמדדת לאורך זמן.
למה המשקל הזה: מודל גולמי מתאפס להתנהגות ברירת המחדל בכל סשן; המפעיל/ה משלם/ת עבור כל טעות בדיוק פעם אחת רק אם הארכיטקטורה עושה זאת כך. זוהי יחידת היסוד של ההצטברות: בלעדיה, כל מנגנון שיפור אחר דולף.
C2קידום דפוסים נלמדים (Learned-pattern promotion)
משקל4דקדוקevidenceשכבת עלותבינוניתoriginadversarial:confidence-scored-instincts
האם המערכת מחלצת דפוסים מהפעילות שלה עצמה ומקדמת אותם ליכולת עמידה (מיומנויות, אינסטינקטים, ברירות מחדל) עם מעקב ביטחון, כך שעבודה חוזרת הופכת לעבודה מקודדת?
במונחים פשוטים: האם המערכת שמה לב לחזרתיות שלה עצמה ומקדמת אותה ליכולת. כשאותו תהליך רב-שלבי מבוצע ביד בפעם השלישית, מערכת מצטברת מחלצת אותו למיומנות בעלת שם, עם מעקב ביטחון כך שהקידום מרוויח את מקומו ולא נעשה בטרם עת. כתיבת מיומנויות ביד היא הגרסה הידנית ומנוקדת באמצע; הקריטריון מצביע על הצינור שבו עבודה חוזרת הופכת לעבודה מקודדת עם מעורבות פוחתת של המפעיל/ה.
עדות הוכחה לרמה 4: שביל קידום: פעילות חוזרת, הדפוס שחולץ ממנה, רשומת הביטחון שלו, והמיומנות המקודמת בשימוש מאוחר יותר.
למה המשקל הזה: תיקונים לוכדים מה השתבש; קידום דפוסים לוכד מה הצליח. הוא ממיר היסטוריית תפעול ליכולת בלי שהמפעיל/ה מחבר/ת משהו, מה שמודל גולמי לא יכול לצבור.
C3הצטברות הזיכרון משתלמת (Memory accretion pays off)
משקל4דקדוקmeasuredשכבת עלותגבוההoriginfunction
האם תשובות משתפרות ככל שהזיכרון גדל, באופן מוכח? הניגוד ל״ריקבון הקשר״: האם יש עדות שיותר זיכרון שהצטבר שיפר את איכות הפלט במקום להתדרדר?
במונחים פשוטים: משקל הנגד לריקבון ההקשר. חוויית ברירת המחדל בתעשייה היא שיותר הקשר שהצטבר הופך מודלים לגרועים יותר: אחזור רועש יותר, עובדות מיושנות יותר, פרומפטים ארוכים יותר. מערכת מצטברת טוענת את ההפך, והקריטריון הזה דורש עדות: כל מדידה שמראה תשובות שהשתפרו ככל שהמאגר גדל (אותה שאלה נענתה טוב יותר עם זיכרון מאשר בלעדיו, איכות נעקבת ככל שהמאגר הכפיל את עצמו). צמיחה במספר הקבצים אינה הטענה; צמיחה בתועלת היא הטענה.
עדות הוכחה לרמה 4: אותו סוג משימה מוערך בשני גדלי מאגר או תאריכים, מראה איכות עולה עם ההצטברות, עם השיטה נאמרת.
למה המשקל הזה: ההצטברות היא ההימור המרכזי של המערכת והוא לא בחינם: צמיחה לא מנוהלת מתדרדרת מודלים. הוכחת ההימור היא מה שמפריד בין מערכת מצטברת למערכת אוגרת.
C4מדד יכולת אורכי (Longitudinal capability benchmark)
משקל5דקדוקmeasuredשכבת עלותגבוההoriginfunction
האם קיים מבחן קבוע שרץ לאורך חיי המערכת: אותו סט משימות מבוצע במרווחים, מראה שיום 300 מנצח יום 30 על מדדים מוגדרים?
במונחים פשוטים: הטענה המרכזית של השכבה, נמדדת בדרך הכנה היחידה: מבחן קבוע שרץ לאורך חיי המערכת. הקפיאו סט משימות מייצגות, הריצו אותו במרווחים על מדדים מוגדרים (איכות, מהירות, כמה התערבות מהמפעיל/ה נדרשה), וראו אם יום 300 מנצח יום 30. בלעדי זה, ״המערכת משתפרת עם הזמן״ היא תחושה, ותחושות לגבי המערכת של עצמך אופטימיות באופן שיטתי.
עדות הוכחה לרמה 4: הגדרת המבחן, לפחות שתי ריצות מתוארכות, ומגמת הציון.
למה המשקל הזה: כל קריטריון אחר בשכבה הזאת מראה מנגנון; זה מראה את העקומה, וזה מה שהופך את הטענה של השכבה לניתנת להפרכה במקום רק לטענה.
C5שיפור בהכוונה עצמית (Self-directed improvement)
משקל4דקדוקevidenceשכבת עלותגבוההoriginfunction
האם המערכת מציעה ומבצעת שיפורים לעצמה מתוך הטלמטריה שלה עצמה (דפוסי כישלון, נתוני עלות, אנליטיקת שימוש), דרך אותם שערי בטיחות כמו כל שינוי אחר?
במונחים פשוטים: האם השיפור עצמו הופך לאוטונומי. המערכת צופה בטלמטריה שלה עצמה (דפוסי כישלון, נתוני עלות, אילו מיומנויות לא בשימוש) ומציעה או מבצעת שיפורים, דרך אותם שערי בטיחות כמו כל שינוי אחר. השערים הם העיקר: שינוי עצמי בלי בקרת שינויים הוא איך מערכות נרקבות; איתם, תחזוקה הופכת לשגרה מתוזמנת נוספת במקום לפרויקט סוף השבוע של המפעיל/ה.
עדות הוכחה לרמה 4: רשימת שיפורים שהמערכת ייצרה מהטלמטריה שלה עצמה, עם פריטים שבוצעו והאפקט הנמדד שלהם.
למה המשקל הזה: סגירת הלולאה: המפעל שמתחזק את עצמו הוא אמינות; המפעל שמשדרג את עצמו הוא הצטברות. דורש טלמטריה, שיקול דעת ושערים עובדים יחד, כולם ארכיטקטורה.
C6הישנות שגיאות פוחתת (Error recurrence declines)
משקל4דקדוקmeasuredשכבת עלותבינוניתoriginfunction
האם שיעור הטעויות החוזרות נעקב, והאם הוא יורד? לא ״האם שגיאות נרשמות״ אלא ״האם אותה מחלקת שגיאה קורית פחות לאורך זמן״, כמספר.
במונחים פשוטים: מדידת החלל השלילי של הלמידה: האם שיעור הטעויות החוזרות יורד? הצלחה דורשת טקסונומיית שגיאות (מחלקות של טעות, לא אירועים בודדים), ספירות הישנות לכל מחלקה, ומגמה נראית. רישום שגיאות אינו הקריטריון; הקריטריון הוא המספר שמראה שאותה מחלקת שגיאה קורית פחות ברבעון הזה מברבעון הקודם. עקומת הישנות שטוחה או עולה מפריכה את טענת ההצטברות לא משנה כמה מתוחכם נראה מנגנון הלמידה.
עדות הוכחה לרמה 4: טקסונומיית שגיאות עם ספירות הישנות לאורך תקופות, מראה את המגמה.
למה המשקל הזה: התמונה השלילית של המבחן: שיפור חייב להתבטא בפחות כישלונות חוזרים, אחרת מנגנוני הלמידה קישוטיים. הישנות היא המדד הכן כי אי אפשר לרמות אותו על ידי הוספת תכונות.
מחברת ואחראית: דנה ממן (saltedmind.co). ראו README.md להיקף, CONTRIBUTING.md להגשת הערכה או ערעור על קריטריון, ASSESS.md לפרוטוקול ההערכה הניתן להרצה על ידי מכונה, ו-LIMITS.md למגבלות המבניות של הכלי הזה.
מורשה תחת CC BY 4.0.
