Files
legal-ai/docs/precedent-corpus-redesign/06-extractor-generosity-committee-application.md
Chaim 4de555367d
All checks were successful
Build & Deploy / build-and-deploy (push) Successful in 1m32s
G12 Leak-Guard / leak-guard (push) Successful in 5s
Lint — undefined names / undefined-names (push) Successful in 11s
chore: fix .gitignore inline comments + add untracked code files
Inline # comments in gitignore are not supported — they were silently
breaking three patterns (data/checkpoints/, data/adapter-migration-state.json,
.claude/agents/.generated/). Moved comments to their own lines and added
missing entries for runtime dirs (data/audit/, data/logs/, etc.) and
temp files (.interaction_tmp.json, .design-build/, .taskmaster bak files).

Also tracks previously untracked legitimate files: scripts, tests, docs,
skills references, .env.example, taskmaster templates.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-06-27 12:49:32 +00:00

9.9 KiB
Raw Permalink Blame History

06 — נדיבות-המחלץ: application בהחלטות-ועדה (כימות חוצה-קורפוס)

קלט-נתונים ליוזמה, נמדד חי על 5,489 רשומות halachot (כל הקורפוס, 2026-06-20). נולד משאלת-חיים: "8508-03-24 מפיק 71 הלכות ממתינות — האם המחלץ נדיב מדי על החלטות-ועדה, או שזה ספציפי לתיק הזה?" התשובה: שיטתי, לא ספציפי — אבל הנדיבות מוצדקת.

מתכתב עם 00-final-synthesis.md: הנתונים כאן מחזקים את הכרעת-הסינתזה ("לא לחתוך") ומוסיפים שני דברים שלא היו לה: (א) כימות חוצה-קורפוס של ה-application, (ב) ממצא חדש וגדול יותר — nli_unsupported על הפסיקה החיצונית. ראה §4 (יישוב-מתח) ו-§5 (דרכי-פעולה).


1. הממצא המרכזי — application הוא תופעה שיטתית של החלטות-ועדה

הפרדנו את הקורפוס לפי authority (נגזר דטרמיניסטית מ-precedent_level, 02-data-model §162): binding = פסיקת-עליון/מנהלי · persuasive = ועדת-ערר מחוזית.

source                         rows   rt=application   nli_unsupported   any-flag
court (binding)               3,603        0.2%            39.7%           45.4%
committee (persuasive)        1,842       13.7%            25.0%           30.5%
  • rule_type='application' הוא כמעט-בלעדית של ועדות: 13.7% מול 0.2%. מתוך 258 רשומות-application בכל הקורפוס, ~252 מגיעות מהחלטות-ועדה. פער של פי-~70.
  • עקבי בין תחומים (לא עניין-שמאות נקודתי):
committee, rt=application by practice_area:
  rishuy_uvniya     13.5%      betterment_levy   14.1%      compensation_197   18.8%

הפרשנות (תואם 02-data-model §163): application = "החלה תלוית-עובדות — לרוב לא-הלכה". ועדת-ערר היא גוף מיישֵם: היא לא יוצרת הלכה (רק בית-משפט עושה זאת), אלא מיישמת פסיקת-עליון קיימת (לוסטרניק, דלי-דליה) על עובדות-התיק. לכן חילוץ מהחלטת-ועדה מייצר באופן מובנה שיעור גבוה של יישומי-דוקטרינה. זו תכונה של מקור-הנתונים, לא באג של המחלץ.

2. 8508-03-24 — מייצג בקצה-העליון, לא חריג

דירוג 8508-03-24:   7 מתוך 45 תיקי-ועדה (≥15 רשומות)   ·   27% application (rt או flag)
חציון תיקי-הוועדה:                                          11.9%
מעליו: 1001-02-19 (40%) · 1044-08-22 (37%) · 9002-24 (33%) · 1007-01-25 (30%)

8508 הוא ~פי-2.3 מהחציון (רבעון-עליון), אבל מה שבולט בו הוא בעיקר שהוא התיק הארוך בקורפוס (111 רשומות) — אז 27% נותן 30 פריטי-application במספר מוחלט, הגבוה בקורפוס. כלומר: כמות גבוהה, שיעור גבוה-אך-נורמלי. אין כאן פתולוגיה ייחודית לתיק.

3. מנגנון-הניתוב הקיים (איך זה כבר מטופל ב-UI)

הפיצול בתור-ההלכות (/precedents → "תור הלכות") אינו לפי exclude_low_quality, אלא לפי isExtractionFixItem(h) = (quality_flags.length>0) && !panel_round (web-ui/.../precedent-library.ts:652):

8508-03-24, 71 ממתינות (מצב 2026-06-20):
  bucket                          #     panel?   →"להכרעתך"   →"דורש תיקון-חילוץ"
  clean (ללא דגל)                40     15/40        40              0
  application                    23      0/23         0             23
  nli_unsupported                 4      4/4          4              0
  thin_restatement                4      0/4          0              4

משמעות: פריטי-application (חסרי-פאנל) כבר מנותבים ל**"דורש תיקון-חילוץ"** — מחוץ לתור-ההכרעה של היו"ר. כלומר המערכת כבר מסננת אותם מהעומס-הידני. (הפאנל התלת-מודלי, halacha_panel_approve.py:191, מטפל רק בדליים clean+nli; application ו-defect עוקפים אותו במכוון.)

4. ⚠️ יישוב-המתח מול הסינתזה — application ≠ "רעש"

זו הנקודה הקריטית להעברה. אסור לתרגם "13.7% application" ל"13.7% רעש לחיתוך". המבחן בסינתזה (§2 שם) כבר הוכיח שחיתוך-אגרסיבי על 8508 השמיד את לוסטרניק ו-~22 עקרונות-ליבה. רוב פריטי-ה-application הם בדיוק יישומי-הדוקטרינה הללו — בני-ציטוט שהכותב צריך. דוגמאות אמיתיות מ-8508 שמסומנות application:

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

לכן: הנתון הזה תומך ב"שמור-בספק" של עמוד-1/2 בסינתזה. המסקנה הנכונה אינה "לסנן application" אלא "application מאשר שעקרוני-הוועדה הם persuasive-יישומיים — לדרג אותם נמוך באחזור (רמה B), לא למחוק אותם (רמה A)". importance=0 ל-8508 כבר משקיע אותם ממילא.

5. ממצא-לוואי גדול יותר — nli_unsupported על הפסיקה החיצונית

nli_unsupported:   court (binding) 39.7%   ≫   committee 25.0%
any-flag:          court 45.4%   ·   committee 30.5%

כמעט מחצית מעקרוני-הפסיקה-החיצונית נושאים דגל-איכות, בעיקר nli_unsupported (הכלל אינו נגזר לוגית מהציטוט התומך שלו, halacha_quality.py:282). זה מגמד מספרית את סוגיית-ה-application, ונוגע ישירות ל"רמה A = ניקוי-רעש" של הסינתזה: מהו ה"רעש" שמנקים? הדגל הדומיננטי הוא nli, והוא מרוכז בפסיקה, לא בוועדות.

שתי השערות מתחרות, שצריך להכריע ביניהן לפני שמשתמשים ב-nli כמסנן-רעש ברמה A:

  • (א) הבודק מחמיר מדי — סף-ה-NLI חותך יישורים לגיטימיים → 40% הם false-positives, וה"רעש" מדומה.
  • (ב) החילוץ-מהפסיקה לקוי — ציטוטים תומכים שלא מיישרים לכלל → בעיית-חילוץ אמיתית בקנה-מידה.

ההכרעה משנה את כל אסטרטגיית רמה-A. אנו ממליצים לאמת זאת על מדגם-זהב לפני כל שימוש ב-nli כסיגנל.


6. דרכי-פעולה מוצעות (לסוכן-הקורפוס)

ממוין מהשמרני לאגרסיבי. ההמלצה שלנו: B כברירת-מחדל + C כעבודה-מקבילה; להימנע מ-A ומ-D.

# פעולה טיעון סיכון המלצה
A לכוונן את ה-prompt לדכא application מוועדות במקור מטפל-בשורש (G1); חוסך 14% רשומות גבוה — סותר את מבחן-8508; משמיד יישומי-לוסטרניק בני-ציטוט ✗ לא
B להשאיר את החילוץ; לסמוך על הניתוב הקיים (application→"תיקון", מחוץ לתור-היו"ר) + לדרג נמוך ב-RRF תואם-סינתזה (שמור-בספק + דרג-בזמן-אחזור); אפס סיכון-אובדן הרעש נשאר ב-DB (אחסון בלבד) כן — ברירת-מחדל
C לחקור קודם את nli_unsupported (40% פסיקה): מדגם-זהב, להכריע (א) מחמיר-מדי מול (ב) חילוץ-לקוי זה הסיגנל הגדול; הכרחי לפני שמגדירים "רעש" ברמה A דורש מדגם מתויג-ידנית כן — במקביל
D להפסיק חילוץ-עקרונות מוועדות לגמרי רוב עקרוני-הוועדה הם שכתוב-persuasive של עליון קיצוני — נוגד 07-learning §61 (ועדות ברות-ציטוט במכוון); נוגע INV-LRN ✗ לא (אלא בהכרעת-יו"ר מפורשת)

ההמלצה המזוקקת

  1. לא לגעת בחילוץ-מוועדות — הנתון מאשר שהנדיבות מוצדקת; application=יישום-בר-ציטוט, לא זבל. עקבי עם הכרעת-הסינתזה "לא לחתוך".
  2. רמה B עושה את העבודהimportance boost ב-RRF מטביע את עקרוני-הוועדה ה-persuasive מתחת לפסיקה-המחייבת, בלי למחוק דבר. 8508 (importance≈0) שוקע ממילא.
  3. להעביר את ה-nli לראש תור-המחקר — לפני שמשתמשים בו כמסנן-רעש ברמה A, לאמת אם 40% אמיתי.

מקור-הנתונים: GET /api/halachot?limit=100000 (5,489 שורות) + per-case ?case_law_id=…. ניתן לשחזר את כל המספרים מהשאילתות האלו. הקאנון הוא live — שיעורים ינועו ככל שהדריינר/פאנל רצים.