איך בונים מערכות Legal Answering שאפשר לסמוך עליהן

הדבר האחד שבאמת עבד

ניסיתי כל טריק retrieval שקיים בספרות על קורפוס משפטי. כוונון BM25, RAG Fusion, HyDE, step-back prompting. אף אחד מהם לא הזיז את המחט. אף אחד. השינוי היחיד ששיפר באופן אמין את איכות התשובות מקצה לקצה היה להפוך את המערכת למהירה יותר. prompt caching הוריד latency מ-5,086ms ל-1,931ms, והדיוק עלה יחד עם זה.

זו לא הייתה ההפתעה היחידה. ה-eval הפנימי שלי נתן למערכת ציון סביב 0.92. ה-eval של הפלטפורמה על מבחן חסוי החזיר 0.48. פער של 48 נקודות אחוז מ-distribution shift בלבד. השאלות שבדקתי מולן לא ייצגו את השאלות שהמערכת באמת תתמודד איתן.

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

מצב הכשל: ראיות לא נכונות, לא ניסוח חלש

כשאנשים אומרים שמערכת משפטית "הזייה," הם לרוב מתכוונים לאחד מארבעה כשלים שונים:

• היא שלפה מהמסמך הלא-נכון
• היא שלפה את המסמך הנכון אבל את הסעיף הלא-נכון
• היא ענתה מעמוד תומך אחד והשמיטה בשקט את העמוד השני שהתשובה תלויה בו
• היא כפתה תשובת free-form כשהמשימה באמת דרשה תוצאה מוגדרת-טיפוס

להתייחס ל-hallucination כבעיית prompt engineering מפספס את רוב שטח הכשלון.

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

השאלה הארכיטקטונית האמיתית היא לא "כמה חכם המודל?" אלא:

האם המערכת יכולה לשמור על זהות המקור הקובע לכל אורך הדרך מ-ingestion ועד לתשובה הסופית?

קורפוסים משפטיים הם קלט עוין

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

מחקר ב-2025 נתן למצב כשל הזה שם שימושי: Document-Level Retrieval Mismatch. מרקוס רויטר ועמיתיו הראו ש-retrievers משפטיים לעיתים קרובות בוחרים chunks מהמסמך המקור הלא-נכון כי boilerplate ושפה פורמלית חזרתיים מאוד לאורך הקורפוס. התיקון שהם הציעו, Summary-Augmented Chunking, אטרקטיבי בדיוק בגלל שהוא פשוט: להזריק זהות ברמת מסמך חזרה לכל chunk לפני retrieval, במקום להתיימר שטקסט מקומי של chunk מספיק בפני עצמו.

לכך שלוש השלכות תכנוניות.

שמרו על זהות עמוד ומקטע מיום ראשון

אתם צריכים לפחות:

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

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

השתמשו ב-OCR כ-fallback, לא כמחשבה שלאחר מעשה

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

שמרו על חלוקה מבנית

ברירת המחדל הלא-נכונה היא עדיין "fixed-size chunking ולקוות לטוב." בחומר משפטי, מבנה חשוב:

• חוקים דורשים chunks מודעי-סעיף/מאמר
• פסיקה דורשת גבולות בין הנמקה/עובדות/החלטה
• חוזים דורשים גבולות סעיף והגדרות

חלוקה שטוחה עובדת עד שהיא מפרידה את ההגדרה מהחובה שהיא מפנה אליה.

Retrieval לעמוד הנכון

מחסנית ה-retrieval השימושית ביותר ל-Legal QA היא עדיין היברידית:

• dense retrieval לדמיון סמנטי
• lexical retrieval לשפה מדויקת, מספרי חוקים, מספרי סעיפים ושמות צדדים

אבל hybrid search לבד לא מספיק. בחירת התכנון החשובה יותר היא מה קורה אחרי שלב ה-retrieval הראשון.

אני מעדיף את הרצף הזה:

1. שליפה רחבה מספיק כדי לשמר recall
2. אגרגציה של מועמדים לפי מסמך או משפחת חוק
3. שכבת בדיקת-שפיות של עקביות מסמך
4. reranking בתוך ה-shortlist
5. שליחה ל-generation רק של סט הראיות הקטן ביותר שאפשר להגן עליו

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

אותו מסמך קרוב הוא לעיתים קרובות האויב האמיתי ב-legal retrieval:

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

המערכת לא צריכה להתייחס אליהם כאל חליפיים. היא צריכה להבין אותם כ-משפחת מסמכים ולשמר את בן המשפחה הנכון בהתאם לשאלה.

לדוגמה:

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

זו הסיבה שהגדלת חלון ה-context לא פותרת את הבעיה. היא מעלה recall ורעש בו-זמנית. ב-Legal QA, המטרה היא לא context מקסימלי. היא הישרדות נכונה של משפחת התמיכה.

להפסיק לכפות סגנון תשובה אחד על כל שאלה

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

חלק מהשאלות המשפטיות הן באופן טבעי free text. רבות לא.

יש הבדל עצום בין:

• "מהו התאריך?"
• "מי הם התובעים?"
• "האם סעיף X הופך את ההגבלה הזאת לאפקטיבית?"
• "השוו איך שני חוקים מתייחסים לאותו מושג."

אלה לא צריכים לעבור דרך אותו חוזה תשובה.

הנה הדפוס שאני סומך עליו ביותר:

זה חשוב משתי סיבות.

ראשית, תשובות מוגדרות-טיפוס קלות יותר לאימות.

שנית, הן מצמצמות את מספר הדרכים שבהן המודל יכול להיות "יצירתי" כשהמשימה לא באמת דרשה יצירתיות.

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

1. ייצוג פנימי עשיר-ראיות או חשיבה
2. חוזה סופי כלפי המשתמש או ה-API

ההפרדה הזאת בריאה. הטעות היא לכווץ אותן יחד.

Provenance: מינימלי ושלם

ערימת ציטוטים יכולה להיכשל בשני כיוונים מנוגדים:

• היא יכולה לצטט יותר מדי
• היא יכולה לצטט פחות מדי

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

אם התשובה תלויה בשני אטומי עובדות שנמצאים בעמודים שונים, צריך את שני העמודים. לא עמוד "הכי טוב" אחד שנבחר בשביל להיראות נקי.

זה נשמע טריוויאלי. זה לא.

בפועל, פריט תשובה משפטי עשוי להכיל מספר חריצי תמיכה:

• כותרת המכשיר
• תאריך חקיקה
• תאריך תחולה
• החוק שתוקן
• סעיף הניהול
• האלמנט המשותף שמשווים

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

זו הסיבה שאני מעדיף provenance ברמת פריט וברמת חריץ על פני vibes ברמת משפט. זה גם מתיישב עם הכיוון הדיאגנוסטי הרחב יותר של מסגרות כמו RAGChecker: אם רוצים להבין מערכת retrieval-augmented, צריך לדרג היכן התמיכה נכונה, חסרה, או מחוברת ליחידת ראיות לא נכונה.

הכלל פשוט:

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

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

Streaming וטלמטריה — חלק מהמוצר

Legal answerers נבנים לעיתים קרובות כאילו latency וטלמטריה הם שאלות של observability. הם לא. הם התנהגות מוצר.

אם הטוקן הראשון מגיע מאוחר, המערכת מרגישה מהססת.

אם הטלמטריה לא שלמה, אי אפשר להסביר כשלים.

אם נתיב ה-streaming ונתיב התשובה הסופית מתפצלים, נוצרת מערכת צל שמתנהגת אחרת בפומבי ממה שהיא עושה ב-traces.

הדפוס הפרודקשני שאני סומך עליו ביותר הוא:

• stream מוקדם ככל שחוזה התשובה מאפשר בבטחה
• שמירה על תשובה סופית קנונית
• פליטת תזמוני שלבים, ספירת טוקנים, זהות provider ומקורות שנשלפו/שנוצלו
• אף פעם לא לבפר את כל התשובה רק כדי להרגיש נקי

זה לא אומר "stream בפזיזות." זה אומר ש-streaming צריך להיות מתוכנן יחד עם:

• ניתוב לפי סוג תשובה
• provenance
• גבולות אימות
• דיווח כשלים

המערכת צריכה להיות מסוגלת לענות על שאלה מאוד משעממת אבל מאוד חשובה:

למה חשבנו שהתשובה הזאת מותרת לצאת מהמערכת?

Evals מפרידים איכות תשובה מאיכות grounding

הרבה צוותים עדיין משתמשים בציון כותרת אחד וקוראים לזה evaluation.

זה לא מספיק.

עבור מערכות legal answering, אני רוצה אותות נפרדים עבור:

• נכונות תשובה
• grounding recall
• שיעור מסמך-לא-נכון
• שיעור משפחה-לא-נכונה
• שיעור עמוד-יתום
• ציות לפורמט
• latency

ואני רוצה עוד הבחנה אחת שנהיית קריטית ככל שהמערכת מתבגרת:

• שכבת benchmark אמינה
• שכבת monitoring

זה נשמע בירוקרטי עד שחיים דרך gold pages שתויגו לא נכון, regression seeds שנורשו, או מקרי eval שמועילים כ-monitors אבל לא כשערים קשיחים כנים.

הלקח המעשי פשוט:

• השתמשו בשכבה קטנה, מבוקרת ואמינה לקבלה קשיחה
• שמרו את השכבה הרחבה והרועשת יותר ל-drift monitoring ולמיון

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

ה-eval harness שלכם טוב רק כמו חלוקת הבדיקה שלכם. למדתי את זה בדרך הקשה.

אם הייתי משחרר את זה מחר

אם הייתי בונה legal answerer היום, הייתי מתחיל ממשהו קרוב לזה:

שימו לב מה לא ברשימה:

• פירמידות prompt ענקיות
• לולאות multi-agent מיותרות (יש מקרים שבהם מערכות multi-agent מתואמות מוצדקות, עוד על זה בהמשך)
• דחיסת context עיוורת
• אמון עיוור במודל frontier יחיד

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

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

1. ingestion עם זהות עמוד ו-OCR fallback
2. חלוקה מודעת-מבנה עם שימור זהות מסמך
3. hybrid retrieval עם בדיקות שפיות של משפחת מסמך
4. חוזי תשובה מוגדרי-טיפוס לשאלות strict
5. provenance ברמת עמוד עם כיסוי תמיכה שלם
6. benchmark אמין קטן לפני אופטימיזציה רחבה
7. streaming וטלמטריה שמסבירים כל שלב

הרצף הזה חשוב.

רוב המערכות החלשות עושות את ההפך:

1. בוחרים מודל
2. כותבים prompts
3. מקווים ש-retrieval בסדר
4. מוסיפים evaluation אחר כך

הסדר הזה בדרך כלל מייצר מערכות שעובדות בדמואים אבל מתדרדרות מהר תחת שאילתות אמיתיות.

עבור Legal AI, הסטנדרט צריך להיות גבוה באופן משעמם.

לא:

• "המודל נשמע חכם."

אלא:

• "המערכת מצאה את המקור הנכון."
• "היא שמרה על העמוד הנכון."
• "היא השתמשה בסט התמיכה הקטן ביותר שעדיין מכסה את כל הטענה."
• "היא יכולה להסביר לי למה ענתה ככה."
• "היא יודעת מתי להימנע מתשובה."

הדגש עובר מגודל context ורהיטות מודל לאיכות ראיות וחוזי תשובה.

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

מה באמת קרה: ספרינט של 13 ימים

נכנסתי ל-Agentic AI RAG Challenge כדי לבדוק את העקרונות האלה מול benchmark אמיתי. 300+ קובצי PDF משפטיים של DIFC, 900 שאלות, נוסחת ציון כפלית, 13 ימים. המערכת נבנתה בזמן עימות פעיל בישראל, מה שהטיל אילוצים בלתי צפויים על זמן הפיתוח והנחה את פילוסופיית ההנדסה לכיוון עמידות ויעילות על פני מורכבות. מה שבא הוא תיאור מרוכז של מה שעבד, מה שלא, ומה שהפתיע אותי.

הנוסחה

כל בחירה אסטרטגית נובעת מהמשוואה הזו:

Total = (0.7 * Det + 0.3 * Asst) * G * T * F

נקודת אחוז אחת של grounding שווה פי 3 מנקודת אחוז אחת של איכות free-text. ההשלכה הייתה מיידית: הגנו על המכפילים בכל מחיר, ואז דחפו את איכות התשובות גבוה יותר בתוך אותה מעטפת בטיחות.

מערכה 1: בית הקברות של ה-ablations

רוב מה שקוראים במדריכי RAG יפגע בכם באופן אקטיבי ב-domain משפטי. הרצתי 16 ניסויים רציניים ב-13 ימים. שיעור הדחייה לניסויי הרחבת-retrieval היה 100 אחוז. הנה ארבעת הניסויים שלימדו אותי הכי הרבה.

RAG Fusion היה הרגרסיה הגרועה ביותר: -7.8pp grounding, +246ms. הטכניקה כותבת מחדש שאילתה לשלושה עד חמישה וריאנטים מפורפרזים וממזגת את התוצאות. שאילתה כמו "What is the Date of Issue of CFI 022/2025?" הפכה ל-"provisions related to CFI 022/2025" ו-"date associated with case filing CFI 022." המיזוג קידם עמודים קשורים-באופן-שולי על פני עמודים מדויקים. גיוון שאילתות מוסיף רעש כששאילתות משפטיות כבר ספציפיות באופן אופטימלי.

HyDE יצר מסמך תשובה היפותטי והשתמש ב-embedding שלו כדי לשלוף מסמכים אמיתיים דומים. ה-LLM הפיק תשובות היפותטיות שהפנו להוראות סבירות אבל לא קיימות, למשל "Article 47(2) of the Regulatory Law", שהוטמעו לשכונות וקטוריות רחוקות מהחלטות האכיפה בפועל. תוצאה: -0.65pp grounding, +560ms. context משפטי שהוזה מרעיל retrieval.

Step-back rewriting הפשיט שאלות לצורות רחבות יותר. "What does Article 16(1)(c) of the Employment Law say about payroll deductions?" הפך ל-"What are the payroll deduction rules in DIFC?" זה איבד את הפניית הסעיף המדויקת שמעגנת retrieval והוסיף 1,542ms של latency. הפשטה מאבדת את הדיוק שנדרש בשאילתות משפטיות.

BM25 hybrid retrieval הוסיף חיפוש מילות מפתח sparse לצד dense embeddings. אפס שיפור grounding, +260ms. ה-dense encoder המותאם-לתחום כבר תפס את האות הלקסיקלי. אות מילות מפתח לא תורם עם dense encoder מותאם-לתחום.

טבלת ablation מלאה עם כל 16 הניסויים בנספח הטכני למטה.

הדפוס עקבי: טכניקות שתוכננו לשאילתות כלליות עמומות לא עוברות לטקסט משפטי מדויק.

שיא מערכה 1

השיפור הגדול ביותר לציון הכולל הגיע מ-prompt caching. שיניתי את מבנה ה-system prompts כדי לעבור את סף ה-1,024 טוקנים של OpenAI ל-caching (נכון למרץ 2026). TTFT של free-text ירד מ-5,086ms ל-1,931ms. מקדם ה-F קפץ מ-0.973 ל-1.006: +3.0pp של ציון כולל משינוי שלא נגע בשום לוגיקת תשובה ובשום קוד retrieval. לא retrieval טוב יותר. תשתית מהירה יותר.

בשילוב עם פליטת טוקן מוקדמת (הזזת mark_first_token() כדי שייורה לפני שה-grounding sidecar סיים), מקדם ה-F הסופי הגיע ל-1.032. זה +3.19% מהציון הכולל, שנצבר אך ורק מזה שעצרתי את השעון מוקדם יותר.

הייתי בטוח. ה-evaluation הפנימי הראה ציונים כמעט מושלמים.

מערכה 2: הפער

ה-proxy הפנימי שלי ל-grounding הראה G=0.9956. טלמטריה הייתה מושלמת ב-T=1.000. מהירות הייתה ממוטבת ב-F=1.032. הערכתי ציון כולל סביב 0.92.

הפלטפורמה החזירה 0.48.

הפער לא היה באג. הוא היה distribution shift. סט ה-warmup כלל 100 שאלות:

שאלות date עלו מ-1 ל-93. Names עלו מ-5 ל-90. ו-279 שאלות התייחסו לסוגי מסמכים שהופיעו אפס פעמים בסט ה-warmup. ה-eval harness שלי כוונן לחלוקה שלא ייצגה את המבחן האמיתי.

ה-grounding proxy היה הכשל השני. הוא מדד אם עמודים מצוטטים קיימים בקורפוס, לא אם הם העמודים הנכונים. ציון פנימי של 0.9956 הסתיר ציון פלטפורמה של 0.589. ה-proxy ענה על השאלה הלא-נכונה.

ניתוח distribution shift מלא נמצא בנספח הטכני.

ספרינט ה-multi-agent

תהליך הפיתוח עם מספר סוכנים (12 סוכני Claude Code שעבדו במקביל על מחשב נייד יחיד, סגרו 737 כרטיסים ב-47 שעות) צמח בסופו של דבר ל-Bernstein, אורקסטרטור קוד פתוח. ה-pipeline של התחרות עצמו פורסם כ-Shafi, על שם אל-שאפעי (767–820), אבי המתודולוגיה של המשפט האסלאמי. אסוציאציה הולמת למערכת שמנמקת על משפט.

מה החזיק מעמד

הטכניקות ששרדו את ה-distribution shift לא היו תלויות בחלוקת האימון. Prompt caching סיפק את אותו שיפור TTFT בלי קשר לסוג השאלה. חיפושי metadata עבדו לכל שאלה שהפנתה למספר תיק, בין אם הופיע בסט ה-warmup ובין אם לא. ניתוב לפי סוג הכליל כי הוא התבסס על מבנה השאלה, לא על תוכן השאלה.

הטכניקות שנשברו כוונו לחלוקת ה-warmup: סיפי grounding שכויילו על 100 שאלות, דפוסי תשובה שהותאמו-יתר לקומץ סוגי מסמכים, מטריקת proxy שמעולם לא נבדקה מול ground truth. תשתית ניצחה תחכום. הנדסת domain ניצחה RAG גנרי.

לטבלת ה-ablation המלאה, תרשימי התקדמות ציונים, ניתוח distribution shift ופירוט ביצועים לפי סוג, ראו את הצלילה המחקרית בטאב השני למעלה.

מה הייתי עושה אחרת

הייתי משקיע בניתוח חלוקת eval ביום 1. בסט ה-warmup הייתה שאלת date אחת. בסט ה-private היו 93. זה מכפיל של 93 על סוג שכמעט לא בדקתי. השוואת חלוקת הסוגים ב-warmup מול ציפיות סבירות לקורפוס משפטי (כמה החלטות אכיפה, כמה תקנות, כמה הנחיות פרקטיקה) הייתה חושפת את פער הכיסוי מיד. לא הסתכלתי על החלוקה עד שהציון הסופי חזר. הניתוח הזה לוקח 30 דקות והיה משנה את כל אסטרטגיית הבדיקה.

הייתי מדלג על ניסויי ה-retrieval לחלוטין. עם dense encoder מותאם-לתחום שכבר משיג 90%+ page recall, ה-retrieval היה קרוב לתקרה. כל שעה שהושקעה ב-BM25, RAG Fusion, HyDE ו-step-back rewriting הייתה מבוזבזת. שישה ניסויי הרחבת-retrieval, כולם נדחו, כולם צרכו זמן שלא היה לי. התשואות היו באיכות תשובה וכיול grounding, לא ב-retrieval. הייתי מפנה את המאמץ לאיכות תשובות free-text, שהתגלתה כפער הציון הגדול ביותר.

הייתי בונה את מערכת ה-multi-agent מההתחלה. התפוקה הנמדדת של פי 1.78 מ-12 סוכנים מקבילים הייתה אמיתית. 737 כרטיסים ב-47 שעות. אבל להקים את תשתית התיאום מאפס ביום 10, תחת לחץ דדליין, גרם ל-8 השעות הראשונות להיות מושקעות בפרוטוקולי wakeup, לוחות מודעות וקבצי directive במקום בבעיה עצמה. להתחיל את מערכת ה-multi-agent ביום 3, עם גבולות מודולים כבר במקום, היה מפחית את תקורת התיאום על פני כל הספרינט ומצמצם את קונפליקטי ה-merge שהטרידו את 48 השעות האחרונות.

הייתי מודד TTFT מיום 1. מקדם ה-F היה המכפיל הזול ביותר בנוסחה. Prompt caching לבד סיפק +3.0pp של ציון כולל. פליטת טוקן מוקדמת הוסיפה עוד +2.0pp. ביחד, זה יותר מכל שיפור retrieval או איכות-תשובה שמצאתי. אבל לא התמקדתי ב-TTFT עד הגשה v6 ביום 3. שני הימים הראשונים של הגשות רצו עם F מתחת ל-1.0, והשאירו נקודות חינם על השולחן. בנוסחה כפלית, המכפיל הזול ביותר הוא תמיד הראשון ששווה לייעל.

קריאה קשורה

• רוב הכשלים ב-RAG מתחילים במסמכים
• כיצד מריצים LLM evals בפרודקשן

לקריאה נוספת

• Towards Reliable Retrieval in RAG Systems for Large Legal Datasets
• LegalBench-RAG: A Benchmark for Retrieval-Augmented Generation in the Legal Domain
• RAGChecker: A Fine-grained Framework for Diagnosing Retrieval-Augmented Generation
• OpenAI: Evaluation best practices
• Anthropic: Demystifying evals for AI agents