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

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

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

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

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

שכבה 1: Fact-check pipeline אוטומטי

הלב של המערכת הוא פייפליין שבועי שרץ בימי ראשון ב-GitHub Actions ועובר על כל הסקילים בקטלוג. הוא מבצע שלוש בדיקות עיקריות:

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

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

בדיקת גרסאות

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

ניתוח תוכן

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

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

מה קורה כשהפייפליין מוצא פער

פה זה נהיה מעניין: הפייפליין לא רק מזהה בעיות, הוא גם מתקן אותן. התהליך:

1. מודל הבדיקה מחזיר רשימה של findings ברמות חומרה שונות (low / medium / high)
2. מודל התיקון (Claude) כותב גרסה מעודכנת של הסקיל, מיישר גם את SKILL_HE.md
3. המערכת מעלה גרסה אוטומטית לפי semver (major/minor/patch נגזרים מסוג ה-findings)
4. קומיט ותיוג נדחפים ל-GitHub repo של הקטגוריה
5. פייפליין הסנכרון קולט את השינוי ומעדכן את ה-DB
6. אנחנו מקבלים מייל סיכום עם כל מה שהשתנה באותו סבב

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

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

skill-creator

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

update-skill ו-update-mcp

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

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

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

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

כל סקיל חדש או עדכון משמעותי עובר דרך תהליך ניהולי (admin workflow) שכולל סקירת diff ידנית לפני פרסום. ככה אנחנו תופסים מקרים שבהם משהו לא הגיוני, ניסוחים מסורבלים או טעויות עריכה. הפייפליין השבועי האוטומטי, למען הסר ספק, רץ מקצה לקצה בלי human in the loop - ההסתכלות הידנית היא post-hoc, על ה-diffs שהוא ייצר.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Skill Certification

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

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

Community Review מורחב

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

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

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

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

שאלות נפוצות

כמה זמן עובר בין שינוי רגולטורי לעדכון של הסקיל? במקרה הטוב, עד שבוע (מחזור הפייפליין השבועי). הפייפליין מדלג על סקילים שנבדקו לפני פחות משבעה ימים, כך שלא יהיו ריצות מיותרות. במקרים דחופים, למשל שינוי שיעור מע"מ שנכנס לתוקף מיד, הצוות שלנו יכול להריץ את הסקריפט ידנית עם --skill או --category (זה דורש push access ל-repos של הקטגוריות ומפתחות API). משתמשים שמזהים שינוי רגולטורי מוזמנים לדווח ישירות מדף הסקיל דרך כפתור "דווח על בעיה", ואנחנו נדחוף סנכרון ידני במידת הצורך.

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

אתם באמת בודקים כל סקיל כל שבוע? כן, למעשה אנחנו רצים על כ-130+ סקילים בכל סבב. בדיקת URLs זה HTTP HEAD requests מהירות, בדיקת גרסאות זה קריאות ל-npm ו-PyPI, וניתוח התוכן עובר דרך Claude ולכן יקר יותר. עדיין, ריצה אחת בשבוע זה בהחלט אפשרי מבחינת עלות.

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

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

קריאה נוספת

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