ezer-mishpati/legal-ai
1
0
Fork 0
Code Issues 29 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

אימות-פסיקה: השלמה ברקע לתצוגה חלקית — 16 מתוך 32 טיעונים מקבלים הצעות בייצור #465

New Issue
Open
opened 2026-08-05 13:43:15 +00:00 by chaim · 0 comments
chaim commented 2026-08-05 13:43:15 +00:00
Owner
Copy Link

What & Why

דף אימות-הפסיקה כבר לא נופל ולא איטי — PRs #462 · #463 · #464 סגרו את ה-500, את סינון-היתר ואת זמן-הטעינה החוזרת. מה שנשאר: התצוגה חוזרת חלקית בייצור.

מדידה דרך ה-API הציבורי אחרי הפריסה (2026-08-05):

תיק טעינה 1 טעינה 2 retrieval_complete טיעונים עם תמיכה
8124-09-24 26.5 שנ' 0.058 שנ' false 16 מתוך 32
1069-04-26 24.5 שנ' 0.053 שנ' false 16 מתוך 69

אותו קוד בדיוק על המארח מסיים 32 מתוך 32 ב-21.5 שנ' עם retrieval_complete=true. הקונטיינר איטי בערך פי-2 — הוא חולק CPU עם שרתי ה-MCP ועם תהליכי הסוכנים (עומס ~5 בזמן המדידה) — ולכן בתוך _RETRIEVAL_BUDGET_S = 22 מספיקים רק כמחצית החיפושים.

מכיוון שתצוגה חלקית נשמרת ב-cache ל-_PARTIAL_TTL_S = 90 שניות, היו"ר רואה 16 מתוך 32 עד שירענן אחרי דקה וחצי — ואז עשוי לקבל 16 אחרים, כי אין המשכיות בין הריצות. זה טוב בהרבה מ-500 או מאפס הצעות, אבל זו עדיין תמונה חלקית שנראית שלמה למי שלא בודק את הדגל.

הפתרון המוצע — השלמה ברקע

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

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

  • _view_cache כבר מבחין בין שלם לחלקי (expires_at is None מול TTL).
  • retrieval_complete כבר נישא בתשובה עד ה-UI.
  • _inputs_fingerprint כבר מבטיח שהשלמה על טביעה ישנה לא תיכתב על נתונים שהשתנו.

חסר רק מי שימלא את החסר.

נקודות עיצוב שצריך להכריע

  • איפה רצה המשימה — asyncio.create_task בתוך הקונטיינר הוא הפשוט ביותר, אבל מת עם ה-worker. שווה לשקול אם זה מספיק או שצריך תור.
  • מרוץ מול הטביעה — לפני כתיבת ההשלמה ל-cache, לאמת שהטביעה לא זזה בינתיים (היו"ר אימת תקדים / הצבירה רצה מחדש). אם זזה — לזרוק, לא לכתוב.
  • הגבלת מקביליות — ההשלמה חייבת לכבד את אותו _MAX_CONCURRENT_LOOKUPS, אחרת היא תחזיר בדלת האחורית בדיוק את ההיצף ש-#462 חסם.
  • התנהגות ה-UI — כשהתצוגה חלקית, להראות שההצעות עדיין נטענות, ולא להציג טיעון בלי הצעות כאילו אין לו תקדים תומך (INV-AH — שתי טענות שונות).

Acceptance Criteria

  • תצוגה חלקית מפעילה השלמה ברקע רק לטיעונים חסרי-הצעות.
  • ההשלמה מכבדת את _MAX_CONCURRENT_LOOKUPS; אין קפיצה במקביליות מול Voyage.
  • לפני עדכון ה-cache — אימות שהטביעה זהה; אחרת ההשלמה נזרקת ואינה נכתבת.
  • אחרי השלמה, retrieval_complete=true ומספר הטיעונים עם תמיכה תואם את הריצה המלאה על המארח (32/32 ל-8124-09-24).
  • טעינה ראשונה נשארת מהירה — ההשלמה אינה מאריכה את זמן התגובה.
  • ה-UI מבחין בין "עדיין נטען" לבין "אין תקדים תומך" (INV-AH).
  • טסט: תצוגה חלקית → השלמה → retrieval_complete=true בקריאה הבאה; ו-טסט שהטביעה שהשתנתה מבטלת את הכתיבה.

הקשר

  • PRs שקדמו: #462 (פיזור מבוקר + תשובה חלקית) · #463 (סקאלת relevance) · #464 (cache מבוסס-טביעה)
  • קוד: mcp-server/src/legal_mcp/services/case_citation_verification.py
  • קשור: אם הדריפט של MULTIMODAL_ENABLED / STORAGE_BACKEND בין הקונטיינר לשרת ה-MCP ייסגר, ייתכן שזמני החיפוש ישתנו — שווה למדוד מחדש אחרי אותו תיקון לפני שמכיילים כאן.
## What & Why דף אימות-הפסיקה כבר לא נופל ולא איטי — PRs #462 · #463 · #464 סגרו את ה-500, את סינון-היתר ואת זמן-הטעינה החוזרת. מה שנשאר: **התצוגה חוזרת חלקית בייצור.** מדידה דרך ה-API הציבורי אחרי הפריסה (2026-08-05): | תיק | טעינה 1 | טעינה 2 | `retrieval_complete` | טיעונים עם תמיכה | |---|---|---|---|---| | 8124-09-24 | 26.5 שנ' | 0.058 שנ' | **false** | **16** מתוך 32 | | 1069-04-26 | 24.5 שנ' | 0.053 שנ' | **false** | **16** מתוך 69 | אותו קוד בדיוק על המארח מסיים **32 מתוך 32 ב-21.5 שנ'** עם `retrieval_complete=true`. הקונטיינר איטי בערך פי-2 — הוא חולק CPU עם שרתי ה-MCP ועם תהליכי הסוכנים (עומס ~5 בזמן המדידה) — ולכן בתוך `_RETRIEVAL_BUDGET_S = 22` מספיקים רק כמחצית החיפושים. מכיוון שתצוגה חלקית נשמרת ב-cache ל-`_PARTIAL_TTL_S = 90` שניות, היו"ר רואה 16 מתוך 32 עד שירענן אחרי דקה וחצי — ואז עשוי לקבל **16 אחרים**, כי אין המשכיות בין הריצות. זה טוב בהרבה מ-500 או מאפס הצעות, אבל זו עדיין תמונה חלקית שנראית שלמה למי שלא בודק את הדגל. ## הפתרון המוצע — השלמה ברקע התצוגה תמשיך לחזור מיד עם מה שהספיק, ומשימת-רקע תמשיך לחפש **רק עבור הטיעונים שנותרו** ותעדכן את הרשומה ב-cache. הטעינה הבאה תהיה שלמה, בלי להאריך את ההמתנה של אף אחד. התשתית כבר קיימת ולא צריך לבנות אותה מחדש: - `_view_cache` כבר מבחין בין שלם לחלקי (`expires_at is None` מול TTL). - `retrieval_complete` כבר נישא בתשובה עד ה-UI. - `_inputs_fingerprint` כבר מבטיח שהשלמה על טביעה ישנה לא תיכתב על נתונים שהשתנו. חסר רק מי שימלא את החסר. ## נקודות עיצוב שצריך להכריע - **איפה רצה המשימה** — `asyncio.create_task` בתוך הקונטיינר הוא הפשוט ביותר, אבל מת עם ה-worker. שווה לשקול אם זה מספיק או שצריך תור. - **מרוץ מול הטביעה** — לפני כתיבת ההשלמה ל-cache, לאמת שהטביעה לא זזה בינתיים (היו"ר אימת תקדים / הצבירה רצה מחדש). אם זזה — לזרוק, לא לכתוב. - **הגבלת מקביליות** — ההשלמה חייבת לכבד את אותו `_MAX_CONCURRENT_LOOKUPS`, אחרת היא תחזיר בדלת האחורית בדיוק את ההיצף ש-#462 חסם. - **התנהגות ה-UI** — כשהתצוגה חלקית, להראות שההצעות עדיין נטענות, ולא להציג טיעון בלי הצעות כאילו אין לו תקדים תומך (INV-AH — שתי טענות שונות). ## Acceptance Criteria - [ ] תצוגה חלקית מפעילה השלמה ברקע רק לטיעונים חסרי-הצעות. - [ ] ההשלמה מכבדת את `_MAX_CONCURRENT_LOOKUPS`; אין קפיצה במקביליות מול Voyage. - [ ] לפני עדכון ה-cache — אימות שהטביעה זהה; אחרת ההשלמה נזרקת ואינה נכתבת. - [ ] אחרי השלמה, `retrieval_complete=true` ומספר הטיעונים עם תמיכה תואם את הריצה המלאה על המארח (32/32 ל-8124-09-24). - [ ] טעינה ראשונה נשארת מהירה — ההשלמה אינה מאריכה את זמן התגובה. - [ ] ה-UI מבחין בין "עדיין נטען" לבין "אין תקדים תומך" (INV-AH). - [ ] טסט: תצוגה חלקית → השלמה → `retrieval_complete=true` בקריאה הבאה; ו-טסט שהטביעה שהשתנתה מבטלת את הכתיבה. ## הקשר - PRs שקדמו: #462 (פיזור מבוקר + תשובה חלקית) · #463 (סקאלת relevance) · #464 (cache מבוסס-טביעה) - קוד: `mcp-server/src/legal_mcp/services/case_citation_verification.py` - **קשור:** אם הדריפט של `MULTIMODAL_ENABLED` / `STORAGE_BACKEND` בין הקונטיינר לשרת ה-MCP ייסגר, ייתכן שזמני החיפוש ישתנו — שווה למדוד מחדש אחרי אותו תיקון לפני שמכיילים כאן.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area:agents
סוכני Paperclip, תזמור, שער-הפלטפורמה (X15)
 area:backend
FastAPI web/, endpoints
 area:ci
Gitea Actions, שערי-CI
 area:docs
ספ-המערכת, תיעוד, תכנון
 area:extraction
קליטה, OCR, חילוץ הלכות/מטא/טענות/תכניות
 area:frontend
web-ui/ (Next.js), RTL
 area:infra
Deploy, Coolify, MinIO, אחסון, גיבויים
 area:mcp
שרת ה-MCP וחוזה-הכלים (X9)
 area:retrieval
RAG, חיפוש, קורפוס, גרף-ציטוטים, יומונים
 area:security
אבטחה, סודות, PII, audit
 area:writing
12 הבלוקים, סגנון דפנה, QA, רכישת-סגנון
 priority:p0-blocker
Blocks everything
 priority:p1-high
High priority
 priority:p2-normal
Normal priority
 priority:p3-low
Low priority / nice to have
 size:l
a week+ — consider splitting
 size:m
2-3 days
 size:s
~1 day
 size:xs
< half a day
 status:blocked
Waiting on another issue/decision
 status:deferred
Decided to defer — parked backlog; not auto-picked
 status:good-first-issue
Small, self-contained starting point
 status:in-progress
Being worked on (a branch/worktree exists)
 status:in-review
A PR is open for this issue
 status:needs-decision
Requires a call before proceeding
 status:ready
Scoped + pickable (has acceptance criteria + size)
 type:bug
Something works incorrectly
 type:chore
Infra, deps, refactor, CI, docs
 type:feature
New capability
 type:spike
Time-boxed investigation -> a decision/doc
No Label area:backend area:retrieval priority:p2-normal size:s status:ready type:feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
chaim
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: ezer-mishpati/legal-ai#465
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?