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

הבעיה האמיתית עם סקילים

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

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

בגלל זה בנינו מערכת של כמה שכבות בקרה שעוברות על התוכן של כל סקיל בקטלוג. המדריך הזה מסביר איך זה עובד.

שכבה 1: בדיקות עובדתיות בעדכון של סקיל

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

בדיקת קישורים

כל URL שמופיע בסקיל מקבל בקשת HTTP. אם הקישור מחזיר 404, 500 או מפנה למקום אחר, אנחנו עוצרים את העדכון עד לתיקון. ככה אנחנו תופסים דפי ממשלה שעברו למבנה חדש, טפסים שהוחלפו, מאמרים שהורדו, ו-repos שנמחקו.

בדיקת גרסאות ספריות

סקילים שמסתמכים על ספרייה או tool ספציפיים (למשל SDK של שירות ממשלתי) נבדקים מול npm ו-PyPI. אם הגרסה התיישנה או שה-API הוחלף, זה עולה לטיפול.

ניתוח תוכן ב-LLM

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

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

שכבה 2: LLM כשופט עצמאי (Independent Judge)

שכבה 1 משתמשת ב-LLM כדי לקרוא את הסקיל ולחפש טעויות, דפוס שמכונה בעולם "LLM as a judge". הוא עובד טוב לבדיקה תקופתית של תוכן קיים, אבל יש לו חולשה מוכרת: מודלים נוטים להסכים עם עצמם. אם אותו מודל שכתב "מע"מ הוא 18%" יתבקש לאמת את המספר, סביר שיאשר אותו גם אם הוא שגוי. זה confirmation bias קלאסי, ומדידות אקדמיות מראות שהפער בין self-check לבין fresh-context check יכול להגיע לעשרות אחוזים בדיוק.

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

איך זה עובד בפועל

1. כל טענה מספרית או רגולטורית בסקיל מתועדת בקובץ עדויות עם URL רשמי - שיעור מע"מ, שמות טפסים, תקרות, ציטוטי חוקים, מספרי תקנות. אם משהו לא נכנס לקובץ העדויות, הוא לא יעבור את השופט.
2. השופט מקבל את התוכן + קובץ העדויות, ולכל פריט הוא ניגש בזמן אמת אל המקור החי באינטרנט ובודק אם הטענה אכן מופיעה שם כמו שכתוב בסקיל.
3. הפלט הוא verdict מובנה: סטטוס PASS או FAIL, רשימה של טענות שנפלו באימות, ורשימה של טענות שאין להן בכלל רשומה בקובץ העדויות.
4. רק verdict PASS עם שתי הרשימות ריקות מתקדם לפרסום. כל דבר אחר חוזר לתיקון.

למה לא בודקים את עצמנו

הסוכן שכתב client.get('/v1/accounts') ישמח לאשר ש"GET /v1/accounts נראה תקין" כשיתבקש לבדוק את עצמו. לעומת זאת, subagent חדש שראה רק את הקובץ הסופי, בלי לדעת מי כתב מה, מתייחס לכל טענה כקלט זר, מוריד את התיעוד הרשמי ועושה את ההשוואה לעומק. זו הסיבה שאנחנו מדפישים subagent נפרד עם זרימת מסרים נקייה, ולא עוד pass של אותו מודל.

Expert Review Simulation

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

הפלט הוא רשימה של חוסרים מסווגים לפי חומרה (קריטי / משמעותי / משני). ממצא קריטי חוסם פרסום עד שהוא מתוקן או מנומק מפורשות כמחוץ לסקופ.

לולאת eval על תיאורי סקילס

מעבר לתוכן, אנחנו מריצים שופט LLM גם על שדה ה-description של כל סקיל. הוא מקבל 8-12 שאילתות (חיובי, שלילי, edge cases) ומחזיר לכל אחת האם הסקיל היה אמור להפעיל את עצמו או לא. כשיעור ההתאמה יורד מתחת ל-90%, ה-description מתחדד עד שהוא עובר. כדי למנוע overfitting אנחנו מחלקים את השאילתות 70/30 לאימון מול holdout, וה-90% נמדד על ה-holdout. ככה אנחנו מצמצמים את שני כשלי המשתמש הכואבים ביותר: שאלה רלוונטית שהסקיל בשתיקה לא נטען לה, או שאלה לא קשורה שהסקיל קופץ אליה בלי סיבה.

זו אותה משפחה רחבה של דפוסים שעובדת תחת המטרייה של "LLM as a judge", עם שני מנגנונים שמייצבים אותה: קונטקסט נקי שמונע confirmation bias, וקריטריונים מובְנים (JSON עם שדות מובהקים) שמכריחים את השופט להחזיר verdict שאפשר לבדוק אותו, לא הערכה כללית. זה לא תחליף לבן אדם, אבל זה תופס מספיק כדי שהבן אדם בשכבה 4 יתעסק בשיפוטים אמיתיים ולא בבדיקת עובדות מכניות.

שכבה 3: סקילים שבודקים סקילים (Meta-Skills)

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

בדיקת תוכן אוטומטית

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

Gap analysis תקופתי על סקילים ו-MCPs

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

שכבה 4: בקרה אנושית

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

סקירת diff על עדכונים ידניים

כל סקיל חדש או עדכון משמעותי עובר דרך סקירת diff ידנית לפני פרסום. ככה אנחנו תופסים מקרים שבהם משהו לא הגיוני, ניסוחים מסורבלים או טעויות עריכה. אין human-in-the-loop בתוך השכבות 1-3 עצמן - הן רצות כתהליך עצמאי - אבל בן אדם מאשר את ה-diff הסופי לפני שכל שינוי יוצא לאוויר.

בדיקת זרימת שיחה דרך Try Skill

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

דיווחים מהקהילה

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

שכבה 5: סורק אבטחה (Tank)

Tank הוא סורק אבטחה ייעודי שרץ על כל MCP וסקיל בקטלוג. הוא בודק שישה דברים:

1. שלמות החבילה וסביבת הרצה מבודדת
2. ניתוח קוד סטטי (Bandit + Semgrep)
3. זיהוי ניסיונות prompt injection
4. סריקת סודות חשופים
5. audit של תלויות מול מאגר OSV
6. בדיקת מבנה ומטא-דאטה

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

שכבה 6: אימות GitHub

במקביל ל-Tank, כל סקיל עובר בדיקה מול המפרט הפתוח של agentskills.io ומול אותות האבטחה של GitHub. השכבה הזו לא בודקת את התוכן עצמו, אלא את שרשרת האספקה של הקוד: שהריפו נעול כמו שצריך, שה-release חתום, ושמה שמותקן בסוף זהה בדיוק למה שנדחף ל-GitHub. התוצר הוא Security Scorecard עם 15 אותות בשלוש רמות:

• קריטי (5): תאימות למפרט, secret scanning, code scanning, release חתום ב-Sigstore ורישיון SPDX
• מומלץ (8): הגנת תגים, הגנת ברנץ׳, קומיטים חתומים, SECURITY.md, MFA, CODEOWNERS, Dependabot ותאימות semver
• בונוס (2): release מהחצי שנה האחרונה, ו-tree SHA שתואם ל-HEAD

ברגע שחמשת האותות הקריטיים עוברים, הסקיל מקבל את התג הירוק "מאומת ✓" ועוד עד 10 נקודות בונוס לציון האמון. האותות שמשתנים מ-release ל-release (תג הגרסה, קומיט חתום, attestation) מתרעננים בכל push לסקיל; אותות שקשורים להגדרות הריפו (code scanning, secret scanning, MFA, branch protection) מתרעננים פעם בשבוע דרך workflow נפרד. הפירוט המלא נמצא בצ'קליסט אימות GitHub.

שכבה 7: ציון אמון (Trust Score)

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

יש לנו מדריך נפרד ומפורט על איך ציון האמון מחושב ואיך לשפר אותו, ראו מדריך ציון האמון.

מה הלאה: אימות על ידי מומחים אמיתיים

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

עין מקצועית לתחומים רגישים

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

Skill Certification

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

משתמשים יראו הבדל ברור בין סקיל שעבר fact-check אוטומטי לבין סקיל שעבר certification מקצועי. שניהם אמינים, אבל רמת הביטחון שונה.

Community Review מורחב

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

חיבור למקורות חיים

במקום שהסקיל "ידע" את שיעור המע"מ, שהוא יקרא אותו בזמן אמת מה-API של רשות המיסים. זה מייתר לגמרי את העדכונים הידניים, כי הסקיל לא מחזיק את העובדה בכלל, הוא שואל אותה מחדש בכל בקשה.

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

שאלות נפוצות

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

מה קורה אם השופט "מתקן" משהו שלא היה שבור? מי שאחראי על העדכון רואה את ה-diff המוצע לפני שהוא יוצא לאוויר - אם משהו נראה בעייתי, פשוט לא מאשרים את התיקון. זה למעשה human-in-the-loop ברמת ה-diff, אבל לא ברמת ההחלטה האוטונומית של השופט. השופט עצמו מכוון לטעויות עובדתיות בלבד, לא לסגנון או לסובייקטיב, מה שמצמצם false positives.

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

מה לגבי סקילים חיצוניים (מ-repos שלא בארגון skills-il)? סקילים חיצוניים לא יכולים להריץ את שכבת קובץ העדויות כי אין לנו push access ל-repo המקור — לקובץ פשוט אין איפה לחיות. החיצוניים עדיין עוברים סריקת Tank, אימות GitHub, סקירת prompt-injection ב-LLM, וחישוב trust score, אבל קובץ העדויות והשופט העצמאי שמסתמך עליו רלוונטיים רק לסקילים שאנחנו מארחים. אם סקיל חיצוני מיובא אחר כך לארגון שלנו, הצינור המלא נכנס לפעולה.

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

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

קריאה נוספת

• מדריך ציון האמון - איך ציון האמון מחושב ואיך לשפר אותו
• אבטחת הצ'אט - על הצפנה, פרטיות ובדיקת עובדות תוך כדי שיחה
• עמוד האבטחה - סקירה כללית של מערך האבטחה של Skills IL