agent/akyldash
1
1
Fork 0
Code Issues 4 Pull Requests Actions Packages Projects Releases Wiki Activity

Создать внутренний интерфейс оценки поисковой выдачи #23

New Issue
Open
opened 2026-08-26 20:22:50 +00:00 by agent · 0 comments
agent commented 2026-08-26 20:22:50 +00:00
Owner
Copy Link

Текущее состояние на 2026-09-12

Реализация лаборатории в коде готова и развёрнута локально. Issue остаётся открытым: production API пока не подключён к имеющемуся поисковому индексу, а внешний доступ ещё не защищён.

Сделано

  • Добавлена внутренняя страница GET /review с RU/KY-поиском и выбором 10 или 20 результатов.
  • Реализовано открытие текста выбранной редакции документа.
  • Добавлены оценки 0–3 и комментарии к каждому результату, общий комментарий и имя проверяющего.
  • Реализованы подписанный снимок поисковой выдачи, сохранение через POST /search-reviews в SQLite и JSON-экспорт.
  • Черновик формы сохраняется в localStorage до успешной отправки.
  • Compose-развёртывание проверено в Docker Desktop: /review отвечает 200; API опубликован только на loopback, OpenSearch доступен только во внутренней Compose-сети.
  • Подтверждено наличие исходных данных: data/minjust-normalized/manifest.sqlite3 содержит 209 958 документов. Сохранённый узел data/opensearch-node занимает 16 ГБ; при запуске восстановлено 16 зелёных индексов, включая akyldash-fragments-v1 с 56 295 965 документами.

Осталось сделать

  • Подключить production API к сохранённому кластеру или выполнить проверенную переиндексацию из нормализованных данных. Текущий production Compose использует отдельный именованный том production_opensearch-data, поэтому имеющийся индекс в него не попадает.
  • Проверить и настроить alias akyldash-fragments-current: в сохранённом кластере такого alias сейчас нет. Пока GET /search?q=test через production API отвечает 502.
  • Пройти сквозные критерии на рабочем индексе: RU/KY-запросы, порядок результатов, открытие редакции, сохранение оценки и проверка полного экспорта.
  • До внешнего доступа настроить VPN или HTTPS reverse proxy с аутентификацией. Backend сам не проверяет вход; в частности, GET /search-reviews/export не требует аутентификации. Не публиковать API напрямую.
  • После этих проверок пройти readiness gate issue #21 и закрывать этот issue только после подтверждения критериев.

Цель

Сделать закрытую лабораторию релевантности: юрист оценивает фактическую выдачу нашего OpenSearch, а не алгоритм сайта Минюста.

Сценарий

  1. Ввести RU-запрос и увидеть первые 10–20 актов в точном порядке поиска.
  2. Открыть текст выбранной редакции в правой панели.
  3. Поставить каждому результату оценку 0–3 и комментарий.
  4. Сохранить снимок выдачи и оценок.
  5. Экспортировать накопленные данные для анализа.

Данные

SQLite: запрос, язык, проверяющий, время, индекс/версия алгоритма, код результата #1, полный снимок результатов в порядке выдачи, оценка и комментарий каждого результата, общий комментарий.

Реализация

  • Добавить в существующий backend POST /search-reviews и JSON-экспорт.
  • Использовать текущие GET /search и endpoint редакции документа.
  • Внутренняя статическая страница без публичного frontend MVP.
  • Доступ только локально/VPN или за reverse-proxy-аутентификацией.
  • Сохранять черновик в localStorage до успешной отправки.

Критерии готовности

Юрист выполняет поиск, открывает документ, оценивает результаты, сохраняет оценку; экспорт содержит запрос, порядок выдачи, документ #1, оценки и комментарии.

Подробный план: docs/product/search-relevance-review-interface-plan.md.

## Текущее состояние на 2026-09-12 Реализация лаборатории в коде готова и развёрнута локально. Issue остаётся открытым: production API пока не подключён к имеющемуся поисковому индексу, а внешний доступ ещё не защищён. ### Сделано - Добавлена внутренняя страница `GET /review` с RU/KY-поиском и выбором 10 или 20 результатов. - Реализовано открытие текста выбранной редакции документа. - Добавлены оценки 0–3 и комментарии к каждому результату, общий комментарий и имя проверяющего. - Реализованы подписанный снимок поисковой выдачи, сохранение через `POST /search-reviews` в SQLite и JSON-экспорт. - Черновик формы сохраняется в `localStorage` до успешной отправки. - Compose-развёртывание проверено в Docker Desktop: `/review` отвечает 200; API опубликован только на loopback, OpenSearch доступен только во внутренней Compose-сети. - Подтверждено наличие исходных данных: `data/minjust-normalized/manifest.sqlite3` содержит 209 958 документов. Сохранённый узел `data/opensearch-node` занимает 16 ГБ; при запуске восстановлено 16 зелёных индексов, включая `akyldash-fragments-v1` с 56 295 965 документами. ### Осталось сделать - Подключить production API к сохранённому кластеру или выполнить проверенную переиндексацию из нормализованных данных. Текущий production Compose использует отдельный именованный том `production_opensearch-data`, поэтому имеющийся индекс в него не попадает. - Проверить и настроить alias `akyldash-fragments-current`: в сохранённом кластере такого alias сейчас нет. Пока `GET /search?q=test` через production API отвечает 502. - Пройти сквозные критерии на рабочем индексе: RU/KY-запросы, порядок результатов, открытие редакции, сохранение оценки и проверка полного экспорта. - До внешнего доступа настроить VPN или HTTPS reverse proxy с аутентификацией. Backend сам не проверяет вход; в частности, `GET /search-reviews/export` не требует аутентификации. Не публиковать API напрямую. - После этих проверок пройти readiness gate [issue #21](../21) и закрывать этот issue только после подтверждения критериев. ## Цель Сделать закрытую лабораторию релевантности: юрист оценивает фактическую выдачу нашего OpenSearch, а не алгоритм сайта Минюста. ## Сценарий 1. Ввести RU-запрос и увидеть первые 10–20 актов в точном порядке поиска. 2. Открыть текст выбранной редакции в правой панели. 3. Поставить каждому результату оценку 0–3 и комментарий. 4. Сохранить снимок выдачи и оценок. 5. Экспортировать накопленные данные для анализа. ## Данные SQLite: запрос, язык, проверяющий, время, индекс/версия алгоритма, код результата #1, полный снимок результатов в порядке выдачи, оценка и комментарий каждого результата, общий комментарий. ## Реализация - Добавить в существующий backend POST /search-reviews и JSON-экспорт. - Использовать текущие GET /search и endpoint редакции документа. - Внутренняя статическая страница без публичного frontend MVP. - Доступ только локально/VPN или за reverse-proxy-аутентификацией. - Сохранять черновик в localStorage до успешной отправки. ## Критерии готовности Юрист выполняет поиск, открывает документ, оценивает результаты, сохраняет оценку; экспорт содержит запрос, порядок выдачи, документ #1, оценки и комментарии. Подробный план: docs/product/search-relevance-review-interface-plan.md.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
admin agent
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: agent/akyldash#23
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?