רוב ה-blog-posts של ספקי AI נראים כך: "שיפרנו את המנוע ב-X%! החכמנו אותו! תוצאות מדהימות!". אף אחד לא כותב על הניסויים שלא עבדו. כי למה? שיווק.
ה-post הזה הולך לעשות בדיוק את ההפך. אני אספר לכם על שבועיים של עבודה שהוספתי ל-Legal Eye, על 850 פסקי-דין חדשים שצירפתי לקורפוס, ועל ה-eval שרצתי ביום שאחרי. התוצאה? אפס שינוי. 17 שאלות עברו לפני. 17 עברו אחרי. אפילו אותן 17 השאלות.
בפרקטיקה השיווקית, זה רע. בפרקטיקה המקצועית, זה חדשות טובות לעורך-דין שמחפש כלי AI אמין — וזה ה-post שיסביר למה.
01. ה-baseline: 17 מתוך 50
ל-Legal Eye יש 50 שאלות-בדיקה קנוניות. הן מכסות 8 דומיינים: חוזים, פיצויים, נדל"ן, רשלנות, צרכנות, עבודה, ירושה, בריאות. כל שאלה מקבלת ציון של PASS, WEAK, או FAIL לפי 3 קריטריונים:
- doctrine match — האם המערכת זיהתה את הדוקטרינה הנכונה?
- anchor case — האם היא הביאה את התקדים הנכון?
- verbatim quote — האם הציטוט מילה-במילה מהפסק (לא הזיה)?
ב-eval של ה-baseline (לפני ההרחבה), התוצאות לפי דומיין:
| דומיין | PASS / סה"כ | גודל קורפוס |
|---|---|---|
| חוזים | 6/10 (60%) | 6,229 |
| פיצויים | 3/6 (50%) | 5,832 |
| נדל"ן | 3/6 (50%) | 5,234 |
| רשלנות | 2/5 (40%) | 3,455 |
| צרכנות | 2/5 (40%) | 4,012 |
| ירושה | 2/4 (50%) | 4,545 |
| בריאות | 1/6 (17%) | 3,201 |
| עבודה | 0/9 (0%) | 2,948 ← הקטן ביותר |
התבנית בולטת: תחום העבודה הוא החלש ביותר. 0 מתוך 9. אפס. הקורפוס שלו גם הקטן ביותר — 2,948 docs. הקשר נראה ברור: פחות docs = פחות יכולת.
ההיפותזה שלי הייתה "תוסיף עוד פסקי-דין בעבודה, ה-PASS rate יקפוץ". נראה סביר. נראה אינטואיטיבי. הייתי טועה.
02. ההרחבה: +850 פסקי-דין
שבועיים. כתבתי script שעובר על קורפוס של 583,813 פסקי-דין כלליים, עם classifier שמזהה האם פסק שייך לתחום העבודה. הסקריפט בנוי בשני שלבים: prefilter מהיר (regex על 17 מונחי-עבודה) שמסנן 95% מהמסמכים, ואחריו classifier מלא על השורדים. תהליך שלם של 583K → 850 docs ב-485 שניות.
למה רק 850?
ה-classifier ביקש score > 9.0 (לפחות 3 מונחי-עבודה ליבתיים). זה רף-איכות גבוה — אני מעדיף 850 docs רלוונטיים מאוד על 3,000 docs בסיכון נמוך. מהמסננת עברו 3,531 docs שזוהו כ-"labor", אבל רק 850 מהם עברו את ה-MIN_SCORE.
ה-shard של תחום העבודה גדל מ-2,948 ל-3,798 docs (גידול של 29%). ה-chunks גדלו מ-16,291 ל-17,983. הקבצים: bm25.pkl.gz מ-10.6MB ל-11.5MB; hebrew_encoder.pkl.gz מ-21MB ל-23MB. כולם נדחפו ל-prod (Hugging Face Space) ב-LFS upload של 35MB. ה-Space התעורר עם הקורפוס החדש ב-57.5 שניות.
ביום שאחרי, הרצתי את אותו eval. אותן 50 שאלות. אותם קריטריונים. הציפייה: 0/9 בעבודה → 2/9 או 3/9. שיפור צנוע אבל מדיד.
03. התוצאה: 0 שינוי. אפילו לא pixel.
cluster_scores זהים בדיוק. אפילו לא הרעש האקראי של retrieval. שום
שינוי לא קרה.
רגע ראשון: למה? בדקתי שה-shard באמת התעדכן (היה). בדקתי שה-Space אכן רץ על הגרסה החדשה (היה). בדקתי שהאלגוריתם של ה-eval לא השתנה (לא השתנה). הכל כשורה. ובכל זאת — 0 שינוי.
רגע שני: ההכרה האדריכלית. ה-Legal Eye בנוי על שני tiers נפרדים:
04. Tier A מול Tier B — אותה מילה, שתי ארכיטקטורות
ל-Legal Eye יש שני נתיבי-תשובה שונים לחלוטין. גם שניהם נקראים "קורפוס". וזה בלבול שיכול לעלות לך הרבה זמן אם אתה לא מבחין ביניהם:
| תכונה | Tier A (anchor-based) | Tier B (BM25 shards) |
|---|---|---|
| תוכן | 16K פסקי-דין מבית-המשפט העליון, anchors דוקטרינריים | 732K פסקי-דין מ-15 shards ספציפיים לתחומים |
| טריגר | שאלה משפטית עם דוקטרינה מזוהה | שאלה לא-מזוהה / fallback / חיפוש מקיף |
| מה הוסף הרחבה | לא הוסף שום דבר | +850 docs |
| מי מניע את ה-eval? | זה הנתיב הראשי | נחלץ רק כש-Tier A לא מוצא |
זה היה הקליק. ה-eval רץ דרך Tier A — מנוע ה-anchors הדוקטרינריים שבעיקר מתבסס על פסיקת העליון. הוספתי 850 docs דווקא ל-Tier B (השכבה הספציפית-לתחום שמשמשת כ-fallback). זה כמו להוסיף ספרים לספרייה האחורית של משרד עורכי-דין — בזמן שהשופט בוחן רק את ה-2 ספרי הפסיקה שעל השולחן הראשי שלו.
אותה מילה ("labor shard"), שתי ארכיטקטורות. הזמן ביזבזתי לא היה זמן מבוזבז — הוא חידד את ההבנה שלי על איפה ה-bottleneck האמיתי. אבל ה-eval לא יזוז עד שאני אדאג להרחבה ב-Tier A.
ה-Tier A בנוי על doctrine clusters — קבוצות של פסקי-עליון שמצטטים זה את זה סביב דוקטרינה אחת (למשל "תום-לב חוזי", "פרשנות הסכם", "הלכת אפרופים"). ה-eval בודק האם המנוע יודע לזהות את הדוקטרינה הנכונה לשאלה ולשלוף את התקדים המוביל שלה. הוספת 850 docs דרגתיים ב-shard העבודה לא יוצר doctrine clusters חדשים. זה רק מוסיף "עוד טקסט" שהמערכת תמצא אם תפנה אליו ב-fallback.
05. למה ספק AI לא יספר לך את זה
התשובה הקצרה: זה לא נראה טוב ב-pitch deck. "השקענו שבועיים ושום דבר לא שיפר" לא מוכר מערכת. כל ספק AI בעולם — לא רק בעברית, לא רק במשפט — מוצא דרכים לטשטש את הניסויים שלא עבדו:
- cherry-pick — מבחר השאלות שמראות שיפור, השאר נעלמות
- "דיוק מעודכן 99%" — אבל מה היה לפני? מה השתנה? לא נדע
- benchmark פנימי שלא רץ ציבורית — אי-אפשר לבדוק את הטענה
- "השתפרנו ב-3 דומיינים" — שלא אומר מה קרה ב-8 הדומיינים האחרים
ב-Legal Eye, ה-eval רץ ציבורית, אוטומטית ב-/eval, וכל תוצאה מתועדת ב-STATE.md הציבורי שלי. כשמשהו לא עובד — זה מופיע. כשמשהו עובד — זה גם מופיע. אין למה להמציא מספרים כשהמערכת בודקת את עצמה כל שבוע.
💡 כלל-אצבע למשתמש
אם ספק AI מסרב להראות לך eval ציבורי שאתה יכול לקרוא, להריץ, ולבדוק את השאלות בעצמך — תניח שהוא לא קיים. אי-אפשר לבטוח במספר שאין דרך לאמת.
06. מה אני עושה עם הידע הזה
התוצאה של ההרחבה הכושלת לא הייתה כלום. ההכרה אדריכלית שהושגה ממנה היא ה-ROI האמיתי. עכשיו אני יודע:
- הרחבה ב-Tier B לא תזיז את ה-eval. זה מאשר שהמערכת באמת מסתמכת על Tier A כפי שתוכננה.
- השיפור הבא חייב להיות ב-Tier A. כלומר: יותר doctrine anchors בתחומים החלשים (עבודה, בריאות). זה עבודה אחרת — לא expansion של docs אלא בניית doctrine clusters חדשים סביב anchor cases.
- ה-eval שלי באמת בודק את מה שהמשתמש רואה — לא שכבת fallback. אם ה-eval היה זז מ-Tier B expansion, זה היה מסמן שה-fallback מתערב בתשובות יותר מהרצוי. ה-fact שזה לא קרה מאשר שה-architecture עובדת כפי שתוכננה.
בשבועות הקרובים אעבוד על Tier A expansion — הוספת anchors דוקטרינריים בתחומי עבודה. אדווח כשיהיה. גם אם זה לא יעבוד.
סיכום
שקיפות עולה על מספרים. ספק שמראה לך eval מלא — כולל הניסיונות שלא עבדו — הוא ספק שאתה יכול לסמוך על המספרים שלו כשהם כן מראים שיפור. ספק שמראה לך רק את "99% הצלחה" בלי הקשר, היסטוריה, ו-failures — הוא ספק שאתה לא יכול לאמת שום דבר אצלו.
Legal Eye מודד 17/50 PASS היום. בעוד חודש זה עשוי להיות 20/50, או 17/50, או 15/50 (אם משהו דווקא נסוג). מה שלא יקרה — אתם תדעו. וזה ההבדל.