legal-ai/docs/precedent-corpus-redesign/01-claude-architecture-data-audit.md

ממצאי ביקורת — ארכיטקטורת קורפוס־הפסיקה + מצב הדאטה בפועל

מקור: Claude (Opus 4.8) · תאריך: 2026-06-20 · קונטקסט: חקירה לקראת תכנון־מחדש של קורפוס־הפסיקה. מסמך זה הוא אחד מכמה קלטי־סוכנים שחיים אוסף; ייעודו להזין את שלב־הסינתזה. אינו תכנית — הוא אבחון.

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

המודל הרצוי (כפי שחיים תיאר אותו): מאגר פסקי־דין והחלטות ועדות־ערר; חוקר־התקדימים מזהה בשלב ניתוח־הערר פס"ד/החלטות שדנו במקרה דומה או הלכה דומה; הסוכן־הכותב משייך ומזכיר אותם בפרק הדיון וההכרעה בסגנון דפנה. שלושה מקורות־הזנה: (1) החלטות דפנה עצמה, (2) ועדות־ערר אחרות שמצטטות פסיקה, (3) פס"ד עליון/מחוזי.

---

0. תקציר־מנהלים (TL;DR)

מה ש"בנוי לא נכון" אינו הסכמה — היא שכבת־הביצוע. הסכמה כבר תואמת בדיוק את המודל שחיים תיאר: טבלה אחת (case_law) ששלושת המקורות נכנסים אליה דרך source_kind/source_type; שלושת ה־search_* הם שלושה מסננים על אותו מקור, לא שלושה מאגרים מקבילים (G2 מקוים ברמת־הסכמה). רֵבילד של הסכמה ייצר בדיוק את אותה סכמה — ולכן אינו פותר דבר, ומסכן ב־second-system syndrome.

מה שכן מחולל את "התיקונים האינסופיים" — שלושה כשלי־ביצוע מדידים:

1. חוזה־קליטה רופף → 66% מהפסיקה בלי practice_area, 31 רשומות ריקות, אכיפת־שלמות (INV-DM1) מופרת בפועל.
2. צינור הלכות→קנוני מייצר רעש → 5,472 קנוני, מתוכם 5,456 סינגלטונים, 0 published → השכבה שאמורה להזין את הכותב (INV-G10) אינרטית לגמרי.
3. כפילות style_corpus → 55 החלטות דפנה חיות בשני נתיבי־אחזור.

המלצה: לא לשרוף את הסכמה. כן לבצע "איפוס שכבות־נגזרות" צר (truncate ל-chunks+halachot+canonical והרצה־מחדש), אבל רק אחרי תיקון החוזה והסף — אחרת מחזירים את אותו בלגן (G1: תיקון במקור, לא בקריאה). מסמכי־המקור (363 רשומות, 332 עם full_text) נשמרים; הם יקרים ו/או ניתנים לקליטה־מחדש מ־PDF.

---

1. מצב הדאטה בפועל (שאילתות חיות מול legal_ai @ localhost:5433, 2026-06-20)

┌─────────────────────────────────────┬─────────┬──────────────────────────────────┐
│ Metric                              │ Count   │ Reading                          │
├─────────────────────────────────────┼─────────┼──────────────────────────────────┤
│ case_law (total precedents)         │   363   │ קטן — re-ingestable              │
│   • external_upload (court rulings) │   240   │ מקור (3) — עליון/מחוזי           │
│   • internal_committee (ועדות ערר)  │    92   │ מקור (1)+(2)                     │
│   • (יתר — ללא source_kind מובהק)   │    31   │ = הרשומות הריקות (ראה למטה)      │
│ style_corpus (החלטות דפנה)          │    55   │ כפילות עם internal_committee     │
│ precedent_chunks                    │ 11,904  │ נגזר — מתחדש מ-full_text         │
│ halachot (total)                    │  5,489  │ נגזר                             │
│   • approved/published              │  1,352  │ 25% בלבד                         │
│   • pending_review (backlog ידני)   │  2,402  │ 44% — צוואר־בקבוק                │
│ canonical_halachot (V41)            │  5,472  │ כמעט 1:1 עם halachot ⚠️           │
│   • singletons (instance_count=1)   │  5,456  │ דה־דופ כמעט לא קרה                │
│   • merged (instance_count>=2)      │    16   │ 0.3% מיזוג                       │
│   • published (מגיע לסוכן הכותב)    │     0   │ ⚠️ השכבה אינרטית לחלוטין          │
│ case_law w/o practice_area          │   240   │ 66% — חופף-בדיוק לפסיקה החיצונית │
│ case_law missing summary            │    27   │                                  │
│ case_law w/ 0 chunks / no full_text │    31   │ רשומות שבורות/ריקות              │
│ distinct practice_area              │     4   │ rishuy/betterment/197/(ריק)      │
└─────────────────────────────────────┴─────────┴──────────────────────────────────┘

practice_area breakdown:
  (ריק)            240   ← כל הפסיקה החיצונית ללא סיווג
  rishuy_uvniya     70
  betterment_levy   50
  compensation_197   3

קריאות מפתח:

• 240 = 240: מספר הפסיקה־החיצונית שווה־בדיוק למספר חסרי־practice_area. כלומר אף פס"ד חיצוני לא סווג לתחום — סינון לפי תחום באחזור פשוט לא עובד עליהם.
• 5,456 / 5,472 סינגלטונים: מנוע הקנוניזציה (V41) רץ אך לא מאחד. סף 0.85 כנראה הדוק מדי, או שהחילוץ מנסח כל הלכה ייחודית מספיק כדי לא להתלכד.
• 0 published canonical: לפי INV-G10 רק קנוני published מגיע לכתיבה. אפס. כל מנגנון V41 כרגע מנותק מהכתיבה בפועל.
• 2,402 pending_review: צוואר־הבקבוק הוא אישור־אנושי ידני, לא טכנולוגיה.

---

2. מפת הארכיטקטורה — קורפוס אחד, שלושה מסננים

פיזית: טבלה אחת. כל שלושת המקורות מתכנסים ל-case_law, מתחתיה precedent_chunks (FK) ו-halachot (FK), ומעל ה-halachot שכבת canonical_halachot (V41).

        canonical_halachot   (עקרונות מאוחדים — V41; כיום אינרטי, 0 published)
              ▲ 1:many
         halachot            (מופע-להלכה per precedent; review_status gate)
              ▲ FK
         case_law            (רישום מרכזי — court rulings + ועדות-ערר)
         ├─ source_kind='external_upload'   → פס"ד עליון/מחוזי  [מקור 3]
         └─ source_kind='internal_committee'→ ועדות-ערר + דפנה   [מקור 1+2]
              ▼ FK
         precedent_chunks    (chunks + embedding vector(1024))

  בנפרד:
         style_corpus        (55 החלטות דפנה — נתיב-אחזור מקביל ל-search_decisions)
         document_chunks     (מסמכי-תיק + style; FK→documents→cases)

שלושת נתיבי־האחזור (לא שלושה מאגרים — שלושה scopes):

┌──────────────────────────────┬─────────────────────────┬────────────────────────────┐
│ Tool                         │ Table / filter          │ Purpose                    │
├──────────────────────────────┼─────────────────────────┼────────────────────────────┤
│ search_decisions             │ document_chunks         │ סגנון/קול: החלטות דפנה     │
│                              │ (scoped case/area)      │ + מסמכי-תיק                │
│ search_precedent_library     │ case_law + chunks/halach │ source_kind=external_upload│
│                              │ ot, source_kind filter  │ → פסיקה חיצונית            │
│ search_internal_decisions    │ אותן פונקציות DB,        │ source_kind=internal_      │
│                              │ source_kind אחר         │ committee → ועדות-ערר      │
└──────────────────────────────┴─────────────────────────┴────────────────────────────┘

שתי האחרונות קוראות לאותן פונקציות DB (search_precedent_library_semantic/_lexical) עם source_kind שונה. זו הפרדה־בשאילתה, לא קוד מקביל.

---

3. שלושת המקורות של חיים → איפה הם נופלים היום

┌────────────────────────────────────┬───────────────────────────────┬─────────────────────────┐
│ Source (חיים)                      │ Stored as                     │ Retrieval               │
├────────────────────────────────────┼───────────────────────────────┼─────────────────────────┤
│ (1) החלטות דפנה עצמה               │ style_corpus  +  (מהוגר ל-)   │ search_decisions  +     │
│                                    │ case_law internal_committee   │ search_internal_decisions│
│                                    │ chair_name='דפנה תמיר'        │ ← כפילות / נתיב-כפול     │
│ (2) ועדות-ערר אחרות                │ case_law internal_committee   │ search_internal_decisions│
│                                    │ chair_name=<אחר>, district     │                         │
│ (3) פס"ד עליון/מחוזי               │ case_law external_upload      │ search_precedent_library │
│                                    │ source_type='court_ruling'    │                         │
└────────────────────────────────────┴───────────────────────────────┴─────────────────────────┘

מסקנה: המודל המנטלי של חיים כבר ממומש בסכמה. אין צורך להמציא מבנה חדש — צריך לאכוף את המבנה הקיים בקליטה, ולחבר את שכבת־הקנוני לכתיבה.

---

4. הדיאגנוזה — מה "בנוי לא נכון" (3 מחוללי־כאב)

4.1 חוזה־קליטה רופף (root cause #1)

• 66% מהפסיקה ללא practice_area; 27 ללא summary; 31 ללא full_text/chunks.
• אין אכיפה ש"searchable=false עד שהמטא שלם" → INV-DM1 מופר בפועל.
• כל העלאה מוסיפה חוב במקום רשומה שלמה. זה המקור לתיקונים החוזרים.

4.2 צינור הלכות→קנוני מייצר רעש, לא ערך (root cause #2)

• 5,456/5,472 סינגלטונים → דה־דופ לא עובד (סף 0.85? ניסוח־חילוץ?).
• 0 published → השכבה שאמורה להזין את הכותב (INV-G10) מנותקת.
• 2,402 בתור־אישור־ידני → הצינור מייצר מהר יותר ממה שאדם מאשר.
• זה בולע את רוב זמן־התחזוקה.

4.3 כפילות style_corpus (root cause #3)

• 55 החלטות דפנה בשני מקומות + שני נתיבי־אחזור.
• צריך מקור־אמת אחד: או style_corpus SoT וה-case_law נגזר, או הפוך.

---

5. ההמלצה — לא רֵבילד־סכמה; "איפוס שכבות־נגזרות" אחרי תיקון־חוזה

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

1. קודם החוזה: אכוף ב-*_upload שדות־חובה (practice_area, summary, full_text); כשל → searchable=false. נקה/מחק את 31 הריקות.
2. תקן את הקנוניזציה: כוונן סף 0.85, הגדר מתי published, ובדוק ניסוח־החילוץ. בלי זה אין טעם להריץ מחדש.
3. רק אז re-derive מהמקור הקיים: chunks → halachot → canonical.
4. הכרע style_corpus: מקור־אמת אחד.

מתי רֵבילד־מלא כן מוצדק: רק אם יתגלה שמסמכי־המקור עצמם (PDF/full_text של 363) פגומים/חסרים. המספרים לא מראים זאת (332/363 עם full_text תקין).

---

6. שאלות פתוחות לשלב־הסינתזה

• למה 0 published בקנוני? האם זה סף, ניסוח־חילוץ, או שפשוט אף אחד לא אישר? (קריטי — קובע אם V41 שמיש בכלל.)
• style_corpus מול case_law: מי SoT? (משפיע על search_decisions מול search_internal_decisions.)
• practice_area לפסיקה חיצונית: לחלץ אוטומטית בקליטה, או להשאיר ידני?
• תור־האישור (2,402): האם המנגנון (פאנל/active-learning, #133) יכול לסגור את הפער, או שצריך לחתוך את קצב־החילוץ?

---

7. נספח — קבצים מרכזיים (file:line)

• סכמה: mcp-server/src/legal_mcp/services/db.py (case_law, precedent_chunks, halachot, canonical_halachot)
• קליטה חיצונית: mcp-server/src/legal_mcp/tools/precedent_library.py (precedent_library_upload)
• קליטה פנימית: mcp-server/src/legal_mcp/tools/internal_decisions.py (internal_decision_upload)
• הגירת style→case_law: mcp-server/src/legal_mcp/services/internal_decisions.py (migrate_from_style_corpus, chair/district hardcoded)
• אחזור: mcp-server/src/legal_mcp/tools/search.py, services/hybrid_search.py, services/db.py (search_precedent_library_semantic/_lexical)
• ספ: docs/spec/02-data-model.md (INV-DM1–7), docs/spec/03-retrieval.md (INV-RET1–5), docs/spec/00-constitution.md (G2/G10)