פיתוח מערכת AI לאנליטיקה משפטית Litigation Analytics

אנליטיקה משפטית מבוססת AI: היכן ניתוח ידני של תיקים נכשל

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

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

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

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

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

מה משתנה בעבודת עורכי דין עם הטמעת אנליטיקה

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

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

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

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

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

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

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

דרכי פריסה: סביבה סגורה, ענן, היברידי

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

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

מה מבררים לפני בחירת המצב

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

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

שלבי הטמעה: מביקורת מאגר התיקים ועד למסירה

(גוף)

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

סדר העבודות

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

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

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

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

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

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

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

מה מוסרים לידיים: קונפיגורציות, סכימות, תקנונים

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

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

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

מקרה בוחן: כיצד קיצרו את משך הכנת העמדה המשפטית

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

מה עשינו

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

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

מה השתנה

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

מדוע אפשר לסמוך על התוצאה

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

במה שונה חיפוש תקדימים מתחזית תוצאת התיק

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

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

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

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

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

שאלות נפוצות על הטמעה ואיכות נתונים

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

מה עושים אם המאגר חלקי או הטרוגני?

פסקי דין מגיעים במבנה שונה, חלקם סרוקים. אנו ממירים אותם לסכימה אחידה: מזהים פרטים מזהים, הרכב המחלוקת והתוצאה, ופערים בפורמטים נסגרים בכללי נרמול. את בסיס פסקי הדין מעדכנים מКонсультантПлюс וממאגרים משפטיים — פסקי דין חדשים נכנסים לאינדקס בלי בנייה מחדש ידנית.

כיצד מובטחת סודיות תיקי לקוחות?

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

מה כלול בתמיכה לאחר ההשקה?

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

נדון במשימה שלכם ונחזור עם תוכנית עבודה

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

כדי לחזור עם הערכת לוחות זמנים ותוכנית עבודה, ולא עם מילים כלליות, אנו צריכים מכם כמה דברים:

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

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