.taskmaster/tasks/tasks.json

@@ -2418,6 +2418,20 @@
         "priority": "medium",
         "subtasks": [],
         "updatedAt": "2026-05-31T14:11:27.861937+00:00"
+      },
+      {
+        "id": "71",
+        "title": "[FU-5 follow-up] כוונון עומק-אחזור/rerank — recall רב-תקדימי לסוגיות רחבות",
+        "description": "ה-eval harness (#63) חשף: לשאלות משפטיות רחבות (5 תקדימים רלוונטיים) חלק מהתקדימים ה-co-relevant מדורגים 15–16 ונופלים מ-top-10. אבחון 2026-05-31: התקדימים *מאוחזרים* (recall תקין, ≈1.0 ב-rank 20) — זו בעיית עומק-חיתוך/דירוג, לא כשל-recall. לשקול בזהירות: העלאת limit ברירת-מחדל של search_precedent_library (10→15/20) ו/או כוונון rerank depth/diversity, ולמדוד ΔR@10 מול רגרסיה ב-known-item (MRR≈1.0 כיום).",
+        "details": "מקור: baseline FU-5 על 9 שאילתות-יו\"ר מהותיות (S1-S9). שאילתות חלשות: S2 נטרול תמ\"א 38 (R@10=0.60, הבית שמעוני@16), S8 שמאי מכריע (0.50), S4 (ב.דייניש@15), S7 (גבעת האירוסים@15). חשוב: שינוי limit משפיע על web-ui (תצוגה), סוכני-כתיבה (כמות תקדימים ל-LLM, עלות-tokens), ולכן דורש שיקול מוצר + מדידה. תהליך: env VOYAGE/POSTGRES → scripts/eval_retrieval.py לפני/אחרי כל שינוי, להשוות מול data/eval/baseline.json. severity: Medium. סוג: retrieval-tuning + מדידה. תלוי ב-#63 (harness).",
+        "testStrategy": "לפני/אחרי כל שינוי: eval_retrieval.py באותו retrieval_config; הוכחה ש-R@10 הרב-תקדימי עולה בלי ירידה ב-MRR/known-item recall.",
+        "status": "pending",
+        "dependencies": [
+          "63"
+        ],
+        "priority": "low",
+        "subtasks": [],
+        "updatedAt": "2026-05-31T16:05:35.071261+00:00"
       }
     ],
     "metadata": {