2026-09-12 06:23:02 +00:00
6 changed files with 68 additions and 33 deletions
@@ -2,6 +2,9 @@

 ## Не выпущено

+- Уточнено, что внутренняя лаборатория оценивает выдачу собственного OpenSearch;
+  ЦБД Минюста служит источником для подтверждения документов, а прежние Excel/PDF
+  бланки удалены.
 - Исключены секреты и локальные данные из Docker build context; синхронизирована версия интерфейса.
 - Добавлен production deployment baseline для Search API и OpenSearch с
  постоянными хранилищами и healthcheck.
@@ -11,7 +11,6 @@ Telegram-бот — только часть рабочего окружения

 Сейчас реализованы Telegram-бот-секретарь версии `0.2.2` и backend версии
 `0.8.3`: исправлена безопасность production Docker build context.
-размеченном наборе запросов.

 | Компонент | Версия | Состояние |
 |---|---:|---|
@@ -56,17 +56,19 @@ cp backend/search/relevance-set-v1.template.json data/search/relevance-set-v1.js

 ## Разметка одного запроса

-1. До просмотра выдачи зафиксируйте информационную потребность и формулировку
-   `query`.
-2. Найдите кандидатов в локальном OpenSearch и в официальной ЦБД Минюста.
-   Проверьте исходный запрос, его короткий вариант и вариант с юридическим
-   термином или известным номером акта.
-3. Просмотрите не только заголовки, но и текст, статус, дату и редакцию каждого
-   кандидата.
-4. Запишите уникальные `document_code` всех документов, удовлетворяющих
-   критерию релевантности.
-5. Повторите поиск по ключевым терминам найденных документов, чтобы обнаружить
-   пропущенные альтернативные акты.
+1. Зафиксируйте исходную формулировку `query` и информационную потребность до
+   оценки выдачи нашего поиска.
+2. Юрист устанавливает релевантные акты по содержанию и реквизитам документов.
+   Используйте ЦБД Минюста как авторитетный источник для проверки текста,
+   статуса и редакции акта. Порядок выдачи ЦБД не является объектом оценки и не
+   переносится в эталон.
+3. Запишите уникальные `document_code` всех документов, которые прямо отвечают
+   на запрос. Спорные документы передайте на независимую проверку.
+4. Зафиксируйте согласованный набор до просмотра результатов OpenSearch и
+   сохраните его отдельно от рабочих данных.
+5. Проверьте запрос во внутренней лаборатории (`/review`): оцените фактические
+   результаты OpenSearch в исходном порядке, сохраните снимок и комментарии.
+   Лаборатория проверяет качество нашей поисковой системы, а не ЦБД Минюста.

 Пример структуры (код условный):

@@ -9,7 +9,9 @@
 - [Готовность к проектированию frontend](product/frontend-design-readiness-plan.md) —
  обязательные работы и критерии перехода к frontend.
 - [План интерфейса оценки поисковой выдачи](product/search-relevance-review-interface-plan.md) —
-  внутренний инструмент сбора оценок юристов для настройки OpenSearch.
+  внутренняя лаборатория сбора оценок юристов для настройки OpenSearch.
+- [Разметка relevance set](../backend/search/RELEVANCE_ANNOTATION.md) — подготовка
+  эталонных документов и воспроизводимая оценка собственного поиска.
 - [Задание по нормализации документов](product/minjust-document-normalization-agent-task.md) —
  требования и критерии приёмки нормализатора ЦБД Минюста КР.

@@ -37,4 +39,4 @@

 ---

-Акылдаш · Telegram-бот v0.2.2 · Backend v0.7.1 · Frontend — не создан
+Акылдаш · Telegram-бот v0.2.2 · Backend v0.8.3 · Frontend — не создан
@@ -1,19 +1,21 @@
 # Статус проекта

-Последняя проверка: 2026-08-14
+Последняя проверка: 2026-09-12
 Назначение документа: быстро восстановить контекст проекта для участников команды и будущих агентов.

 - Telegram-бот: `0.2.2`
 - Telegram-бот на Synology: `0.2.1`
- Backend: `0.7.1`
+- Backend: `0.8.3`
 - Frontend: не создан

 ## Краткий итог

 Репозиторий переориентирован с отдельного бота на весь проект юридической информационно-аналитической платформы. Telegram-бот выделен в инструмент рабочего окружения. Реализованы возобновляемая выгрузка документов из официального Open Data API ЦБД Минюста КР и их локальная воспроизводимая нормализация.

-Ближайшая цель — оценить полный локальный индекс на 50–100 запросах RU/KY и
-настроить ранжирование до начала разработки поискового API.
+Поисковая система и внутренняя лаборатория оценки выдачи реализованы. Ближайшая
+цель — проверить собственную выдачу на практических RU/KY-запросах, разобрать
+оценки юристов и зафиксировать baseline. ЦБД Минюста служит источником для
+проверки документов и редакций, а не системой для сравнения поисковой выдачи.

 ## Уже сделано

@@ -77,6 +79,8 @@
 - Полный проход завершён: 209 958 документов нормализованы без ошибок.
 - Контрольная выборка RU/KY прошла проверки текста, фрагментов, ID и SHA-256.
 - Добавлены строгий mapping и атомарный Bulk NDJSON-экспорт для OpenSearch.
+- На предыдущей итерации использовались Excel/PDF-бланки юридической проверки;
+  текущий процесс опирается на relevance set и внутреннюю лабораторию.

 ### Развёртывание

@@ -112,6 +116,17 @@
 - Не настроены уведомления Gitea.
 - Не проведён полный пользовательский тест: сообщение → сохранение → экспорт → анализ в ChatGPT → возврат отчёта.

+### Готовность поиска к frontend
+
+- Реализована внутренняя лаборатория для просмотра и оценки фактической
+  выдачи OpenSearch; пилот с юристами ещё не проведён.
+- Не завершена независимая юридическая проверка всех 50 запросов relevance set
+  v1; спорные строки нельзя включать в baseline.
+- Не зафиксированы неизменяемая копия подтверждённого relevance set и baseline
+  `Recall@10`/`MRR@10`.
+- Не пройден финальный readiness gate: обновление корпуса, переиндексация,
+  проверка выдачи и API-сценарии для RU, KY и одноязычных актов.
+
 ## Важные неизвестные

 По мере реального использования нужно принять решения по следующим вопросам:
@@ -122,19 +137,32 @@

 ## Следующий этап

-### Фиксация MVP и проверка полного цикла
+### Проверка собственной поисковой выдачи

-Рекомендуемый порядок:
-
-1. Настроить резервное копирование `/volume1/docker/akyldash/data`.
-2. Зафиксировать состав MVP с командой и закрыть тему `MVP`.
-3. Провести одно реальное обсуждение с ответами, правками и вложением.
-4. Экспортировать обсуждение и вручную проанализировать Markdown в ChatGPT.
-5. Вернуть подтверждённый итог в тему `Решения` и зафиксировать его в Git/Gitea.
-6. Записать обнаруженные неудобства и только после этого выбирать следующую доработку.
+1. Подготовить согласованный RU/KY relevance set: фиксировать потребность
+   запроса и подтверждённые `document_code`, не ориентируясь на порядок выдачи.
+2. Проверить практические запросы во внутренней лаборатории `/review`, сохранить
+   снимки и оценки фактических результатов OpenSearch.
+3. Разобрать ошибки ранжирования, сохранить baseline и повторить ту же проверку
+   после изменений.
+4. Затем пройти readiness gate issue #21 для корпуса, индекса и Search API перед
+   проектированием публичного frontend.

 ## История изменений статуса

+### 2026-09-12
+
+- Внутренняя лаборатория оценивает фактическую выдачу собственного OpenSearch;
+  ЦБД Минюста используется только для проверки источников и редакций актов.
+- Backend `0.8.3`; закрытая внутренняя лаборатория готова к пилоту.
+
+### 2026-09-06
+
+- Подготовлены бланки независимой юридической проверки relevance set v1 для
+  русского и кыргызского языков и инструкция для юриста.
+- Ближайшим этапом зафиксированы юридическая верификация, baseline качества
+  поиска и финальный readiness gate перед frontend.
+
 ### 2026-08-18

 - Оценщик поиска использует `cross_fields` для совместного сопоставления
@@ -234,4 +262,4 @@

 ---

-Акылдаш · Telegram-бот v0.2.2 · Backend v0.7.1 · Frontend — не создан
+Акылдаш · Telegram-бот v0.2.2 · Backend v0.8.3 · Frontend — не создан
@@ -52,13 +52,14 @@ alias без смешивания старого и нового корпуса.
 1. Заполнить рабочую копию из `backend/search/relevance-set-v1.template.json`
   естественными формулировками пользователей и подтверждёнными
   `document_code` релевантных действующих актов.
-2. Проверить каждый запрос по официальной ЦБД и локальному индексу; не
-   включать запросы без установленного эталонного результата.
+2. Подтвердить документы по официальной ЦБД и проверить их наличие в локальном
+   индексе по `document_code`, не оценивая порядок поисковой выдачи. Не включать
+   запросы без установленного эталонного результата.
 3. Провести независимую вторую проверку языка, формулировки и полного списка
   кодов. Спорные результаты не включать до согласования.
-4. После проверки сохранить неизменяемую копию набора и baseline
-   `Recall@10`/`MRR@10`; новые правила ранжирования оценивать только сравнением
-   с этим baseline.
+4. После независимой проверки сохранить неизменяемую копию набора, затем
+   оценить собственную выдачу и сохранить baseline `Recall@10`/`MRR@10`. Новые
+   правила ранжирования проверять на том же наборе и сравнивать с baseline.
 5. Отдельно проверить распространённые сокращения, опечатки и запросы о
   практическом действии. Правило принимается, только если улучшает
   подтверждённые запросы и не создаёт ложных срабатываний в негативных