56f64e9077
retrieval_eval.py now runs every existing query through hybrid_query alongside flat/cascade, and gate criteria 1/3 (no degradation, negative controls) check hybrid too -- this is the phase's key regression test: does adding mail chunks to the HNSW index degrade the 7 existing paperless queries? Criterion 4 (mail hit@3 in hybrid) is wired but skipped with an explicit report note when queries.yaml's new `mail_queries` placeholder is empty, rather than silently PASSing/FAILing on absent data. queries.yaml: added an empty `mail_queries: []` placeholder + inline format docs. The existing 7-query `queries:` list is untouched. REMINDER for the operator (per plan §8, Krok 5): 3-5 mail queries are still needed -- things you know are in last year's mail, plus each one's expected gmail Message-ID -- before criterion 4 and the full plan §8 gate can PASS. Until then this only re-verifies the paperless regression check. docs/kb/modules/05-faza-mailowa-plan.md, §8.
90 lines
3.7 KiB
YAML
90 lines
3.7 KiB
YAML
# Eval-set for the retrieval quality gate (module 5, phase 3, plan §6.2,
|
|
# docs/kb/modules/05-faza3-plan.md). Transcribed 1:1 from the pilot baseline,
|
|
# docs/kb/eval/retrieval-pilot-2026-07-16.md (read-only source -- this file is the versioned
|
|
# copy the plan asked for, so the set stops living only in a session transcript).
|
|
#
|
|
# kind:
|
|
# hit -- pilot found a correct top-1 match (dist < 0.45)
|
|
# grey_zone -- pilot landed in the 0.45-0.55 band (on-topic, imprecise)
|
|
# negative_control -- pilot correctly found nothing (dist > 0.55)
|
|
# negative_control_borderline -- pilot correctly found nothing, but close to the 0.55 edge
|
|
#
|
|
# expected_envelope is null for both negative-control kinds: there is no document these
|
|
# queries should match, by design.
|
|
|
|
queries:
|
|
- id: "1"
|
|
text: "polisa ubezpieczeniowa PZU warunki odpowiedzialności"
|
|
kind: hit
|
|
expected_envelope: "paperless:14"
|
|
baseline_top1_dist: 0.3418
|
|
note: >
|
|
Pilot top-1 = paperless:14 (OWU PZU Auto); ujawnił duplikat paperless:14 ≡ paperless:74
|
|
(flagowany excluded_reason='duplicate' w kroku 1 fazy 3).
|
|
|
|
- id: "2"
|
|
text: "faktura za usługi telekomunikacyjne kwota do zapłaty"
|
|
kind: hit
|
|
expected_envelope: "paperless:192"
|
|
baseline_top1_dist: 0.3447
|
|
note: >
|
|
Pilot top-1 = paperless:192 (faktura P4); poz. 3/5 w pilocie był chunk z OCR-śmieciem
|
|
(kody kreskowe) -- powinien wypaść po excluded_reason='ocr_junk' z kroku 1.
|
|
|
|
- id: "3"
|
|
text: "zasady punktacji FLL Challenge robot game (PL)"
|
|
kind: grey_zone
|
|
expected_envelope: "paperless:5"
|
|
baseline_top1_dist: 0.4154
|
|
note: >
|
|
Pilot: szara strefa -- rodzina dokumentów OK, sedno (zasady punktacji) nie trafione
|
|
precyzyjnie. Kandydat na poprawę: czy pre-filtr po streszczeniu podnosi trafność?
|
|
|
|
- id: "4"
|
|
text: "FLL robot game mission scoring points table (EN)"
|
|
kind: hit
|
|
expected_envelope: "paperless:5"
|
|
baseline_top1_dist: 0.4114
|
|
note: >
|
|
Cross-lingual (EN zapytanie) trafia lepiej niż PL (zapytanie 3); poz. 2+ w pilocie =
|
|
paperless:119 (scoresheet, mojibake) -- mojibake nie jest śmieciem, niesie sygnał.
|
|
|
|
- id: "5"
|
|
text: "innovation project scoring"
|
|
kind: hit
|
|
expected_envelope: "paperless:3"
|
|
baseline_top1_dist: 0.3869
|
|
note: "Najlepszy wynik pilota: top-5 spójnie z jednego właściwego dokumentu (arkusz ocen IP)."
|
|
|
|
- id: "N"
|
|
text: "przepis na sernik z rodzynkami"
|
|
kind: negative_control
|
|
expected_envelope: null
|
|
baseline_top1_dist: 0.6210
|
|
note: "Poprawny brak w pilocie; separacja od trafień wyraźna."
|
|
|
|
- id: "N2"
|
|
text: "piaskownica plastikowa"
|
|
kind: negative_control_borderline
|
|
expected_envelope: null
|
|
baseline_top1_dist: 0.5533
|
|
note: >
|
|
Poprawnie na granicy "brak" w pilocie -- semantycznie sąsiednie dokumenty wspólnoty
|
|
mieszkaniowej, nie odpowiedź na zapytanie.
|
|
|
|
# Faza mailowa (docs/kb/modules/05-faza-mailowa-plan.md, §8, Krok 5) -- bramka jakościowa dla
|
|
# treści mailowej wprowadzonej w Etapie A (ostatnie 12 miesięcy, plan §7 Krok 4). PLACEHOLDER:
|
|
# operator ma dostarczyć 3-5 zapytań "wiem że to mam w mailach z ostatniego roku" +
|
|
# oczekiwany Message-ID (surowy, bez prefiksu "gmail:" -- envelope.id dla źródła gmail to
|
|
# bare Message-ID, np. "abc123@mail.gmail.com", inaczej niż "paperless:N" powyżej).
|
|
# Do czasu uzupełnienia ta lista jest pusta i retrieval_eval.py pomija kryterium hit@3 mailowe
|
|
# z jawną notatką w raporcie, zamiast fałszywie PASS/FAIL na braku danych.
|
|
#
|
|
# Format wpisu (identyczny co do pól z `queries:` powyżej):
|
|
# - id: "M1"
|
|
# text: "..."
|
|
# kind: hit
|
|
# expected_envelope: "<raw gmail Message-ID>"
|
|
# note: "..."
|
|
mail_queries: []
|