POWER M2: незалежна людська оцінка пошуку¶

Статус¶

M2 визначає, як POWER перевіряє якість пошуку за участі людей. Технічний контракт, протокол і валідатор існують; сама оцінка ще не почалась. До отримання незалежних людських оцінок POWER не заявляє доведеної якості пошуку, готовності до production або переваги будь-якого режиму пошуку.

Навіщо потрібна людська оцінка¶

Синтетичні тести корисні для регресій у CI, але не доводять, що пошук допомагає людині у реальному knowledge-workflow. M2 перевіряє п'ять задач:

знайти актуальний операційний факт;
відновити історичний або замінений факт на задану дату;
простежити твердження до джерела та походження;
коректно утриматися від відповіді без достатніх доказів;
знайти зв'язок між нотатками, не надаючи heuristic candidate статусу авторитетного факту.

Незалежність і приватність¶

Двоє незалежних оцінювачів отримують однаковий набір кандидатів без позначок режиму пошуку. Вони не бачать відповідей один одного. Лише після фіксації обох відповідей обчислюється agreement; кожну розбіжність розглядає третій незалежний арбітр.

Публічний репозиторій ніколи не містить:

сирі оцінки людей;
імена, контакти або інші персональні дані учасників;
посилання, шляхи чи облікові дані захищеного сховища;
неанонсовані запити або покрокові результати sealed holdout;
вихідний вміст, який не пройшов деідентифікацію та публічний review.

GitHub призначений для коду, публічного протоколу, контрольних сум, підсумкових метрик і відтворюваних команд. Первинні матеріали зберігаються поза репозиторієм у сховищі з розділеними правами доступу.

Хто саме потрібен¶

Повний тест не починається з коду. Він починається з трьох різних людей:

Роль	Що робить	Чого не робить
Координатор	готує деідентифіковані пакети, видає їх, зберігає receipts	не виставляє relevance-оцінок
Оцінювач А	незалежно оцінює кожну пару «запит—документ»	не бачить роботу Б
Оцінювач Б	виконує ту саму незалежну оцінку	не бачить роботу А
Арбітр В	вирішує лише випадки, де А і Б розійшлися	не змінює первинні файли

А, Б і В мають бути різними людьми. Людина, яка змінювала ranking або обирала його режим заради бажаного результату, не може бути оцінювачем цього порівняння. Для кожної ролі достатньо псевдоніма на кшталт ANN-A01; справжні імена не потрібні в репозиторії.

Як реально запустити тест¶

Координатор створює один деідентифікований corpus і відокремлює development від sealed holdout. Один document family або його перефраза не може бути в обох частинах.
Координатор формує pooled candidate set з усіх порівнюваних режимів і випадкових нерелевантних документів. Не можна давати на оцінку лише top results одного режиму.
Координатор перевіряє, що в пакетах немає URL, hostname, секретів, персональних даних, source path або назви retrieval mode; фіксує SHA-256 corpus, queries, packet і версії runtime/protocol.
Координатор кладе дві ідентичні копії packet у два різні доступообмежені канали й передає по одній А та Б. Після передачі corpus і questions не редагуються.
А і Б самостійно заповнюють по одному JSON-рядку для кожної пари query_id і document_id, зберігають файл без редагування після здачі та не обговорюють відповіді.
Координатор перевіряє повноту файлів, обчислює agreement до будь-якого обговорення й створює receipt: input SHA-256, назва показника agreement, формула, результат, кількість пар і кількість розбіжностей.
Координатор передає В лише disagreement bundle. В для кожного рядка обирає final relevance та один reason code: scope, temporal, provenance, partial, conflict або other.
Координатор формує frozen qrels, який містить оцінки А, Б і рішення В, перевіряє hashes та manifest. Development split можна використати для налаштування; sealed holdout не відкривається implementers до freeze release candidate.
Після freeze однаковий corpus/runtime manifest застосовується до lexical, semantic, hybrid, reranked і graph-assisted режимів. У звіті наводяться всі результати, у тому числі результати нижче порогів.

Точний формат відповіді оцінювача¶

Один рядок JSONL для однієї пари має таку форму:

{"query_id":"q-001","document_id":"doc-014","relevance":2,"abstention_correct":false,"acceptable_citation_ids":["doc-014"],"temporal_classification":"current"}

Допустимі relevance: 2, 1, 0, -1. Допустимі temporal_classification: current, historical, conflicted або unknown. Відсутній рядок, повторена пара query_id і document_id або значення поза цим набором робить packet неповним і повертається оцінювачу без reconciliation. Один query_id може законно повторюватися в кількох рядках — по одному для кожного документа-кандидата.

Що перевіряє координатор¶

Коли сформовано manifest і файли evidence, у захищеному середовищі термінала встановити M2_EVIDENCE_ROOT на корінь сховища. Не записувати його фактичне значення в репозиторій, Issue, PR або лог. Потім запускати:

python benchmarks/human_retrieval/scripts/validate_human_evidence.py \
  "${M2_EVIDENCE_ROOT}/development/manifest.json"

python benchmarks/human_retrieval/scripts/validate_human_evidence.py \
  "${M2_EVIDENCE_ROOT}/sealed_holdout/manifest.json" --allow-sealed

Команда не оцінює якість замість людей. Вона перевіряє, що manifest пов'язує точні байти corpus, queries, raw judgments і qrels через SHA-256; sealed перевірка вимагає явного дозволу.

Вимоги до оцінювання¶

Кожна оцінка пов'язана з непрозорими ідентифікаторами запиту й документа та має ordinal relevance: 2 — прямо підтверджує відповідь, 1 — корисний, але неповний контекст, 0 — не підтверджує, -1 — вводить в оману, застарів або суперечить доказам. Також фіксуються коректність утримання від відповіді, допустимі цитати та temporal classification.

Перед reconciliation необхідно зберегти agreement receipt: обраний показник, версію інструмента, контрольні суми input-файлів і результат. Арбітр фіксує причину кожного рішення: scope, temporal, provenance, partial, conflict або other. Остаточний qrels зберігає обидві первинні оцінки, а не перезаписує їх.

Повний машинно-перевірюваний контракт наведено у benchmarks/human_retrieval/annotation_protocol.md та перевіряється validate_human_evidence.py.

Умови проходження M2¶

M2 може бути позначений як пройдений або не пройдений лише після того, як:

зафіксовані дві незалежні первинні оцінки та agreement receipt;
третя людина розглянула всі розбіжності;
corpus, queries, raw judgments і frozen qrels мають перевірені SHA-256;
development evidence пройшов валідацію, а sealed holdout відкрито лише окремим явним рішенням;
lexical, semantic, hybrid, reranked і graph-assisted режими оцінено на однакових corpus/runtime hashes;
оприлюднені Recall@10, nDCG@10, MRR@10, точність citation/provenance, stale-answer rate, якість abstention, p95 latency, confidence intervals і всі пороги, які не було досягнуто.

Наперед зареєстровані пороги¶

Для evidence зі статусом adjudicated поле thresholds має містити рівно ці сім ключів, які вимагає validate_human_evidence.py, із такими значеннями:

Ключ у manifest	Поріг	Умова проходження
`recall_at_10`	`0.80`	результат `>= 0.80`
`ndcg_at_10`	`0.70`	результат `>= 0.70`
`mrr_at_10`	`0.70`	результат `>= 0.70`
`citation_provenance_accuracy`	`0.95`	результат `>= 0.95`
`stale_answer_rate_max`	`0.02`	результат `<= 0.02`
`abstention_quality`	`0.90`	результат `>= 0.90`
`p95_latency_ms`	`1500`	результат `<= 1500` мс

M2 проходить лише тоді, коли виконані всі попередні умови цього розділу і кожен із семи результатів проходить свою умову з таблиці. Будь-який невиконаний поріг означає verdict «M2 не пройдено»: результат, фактичне значення, поріг і confidence interval публікуються без приховування. Пороги не змінюються після відкриття sealed holdout; інший набір порогів потребує нової pre-registration до такого відкриття.

Як долучитися¶

Потенційний оцінювач або арбітр залишає коротку заявку в координаційному Issue №220: роль, псевдонім і готовність працювати незалежно. Не додавайте у звернення особисті дані або інформацію про vault. Maintainers підтверджують відсутність конфлікту інтересів і передають через окремий захищений канал деідентифікований пакет, інструкцію та мінімально необхідний доступ. Учасник не обговорює власні оцінки з іншими оцінювачами до завершення agreement gate.