diff --git a/CHANGELOG.md b/CHANGELOG.md index d17dcb2..7318e0a 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,9 @@ ## Не выпущено +- Уточнено, что внутренняя лаборатория оценивает выдачу собственного OpenSearch; + ЦБД Минюста служит источником для подтверждения документов, а прежние Excel/PDF + бланки удалены. - Исключены секреты и локальные данные из Docker build context; синхронизирована версия интерфейса. - Добавлен production deployment baseline для Search API и OpenSearch с постоянными хранилищами и healthcheck. diff --git a/README.md b/README.md index 8b17e82..deb2842 100644 --- a/README.md +++ b/README.md @@ -11,7 +11,6 @@ Telegram-бот — только часть рабочего окружения Сейчас реализованы Telegram-бот-секретарь версии `0.2.2` и backend версии `0.8.3`: исправлена безопасность production Docker build context. -размеченном наборе запросов. | Компонент | Версия | Состояние | |---|---:|---| diff --git a/backend/search/RELEVANCE_ANNOTATION.md b/backend/search/RELEVANCE_ANNOTATION.md index beb6a1b..6a725c5 100644 --- a/backend/search/RELEVANCE_ANNOTATION.md +++ b/backend/search/RELEVANCE_ANNOTATION.md @@ -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 в исходном порядке, сохраните снимок и комментарии. + Лаборатория проверяет качество нашей поисковой системы, а не ЦБД Минюста. Пример структуры (код условный): diff --git a/docs/README.md b/docs/README.md index ec297c0..88458e6 100644 --- a/docs/README.md +++ b/docs/README.md @@ -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 — не создан diff --git a/docs/operations/project-status.md b/docs/operations/project-status.md index 6aa411d..fc9c3e4 100644 --- a/docs/operations/project-status.md +++ b/docs/operations/project-status.md @@ -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 — не создан diff --git a/docs/product/frontend-design-readiness-plan.md b/docs/product/frontend-design-readiness-plan.md index ce1ea0a..3321800 100644 --- a/docs/product/frontend-design-readiness-plan.md +++ b/docs/product/frontend-design-readiness-plan.md @@ -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. Отдельно проверить распространённые сокращения, опечатки и запросы о практическом действии. Правило принимается, только если улучшает подтверждённые запросы и не создаёт ложных срабатываний в негативных