Обновить

Почему нам пришлось превратить нормативные документы в граф, а не просто загрузить их в векторную базу

Время на прочтение7 мин
Охват и читатели7.1K
Всего голосов 9: ↑9 и ↓0+9
Комментарии5

Комментарии 5

Хотелось бы подробностей. Какой у Вас проект, каков объём документов? Какой технологический стек в итоге выбрали?

Сейчас многие покушаются на задачу сделать той или иной полноты семантический поиск по российскому законодательству/судебной практике. В каких-то отраслевых вопросах оно работает неплохо, но более или менее универсальный инструмент - это минимум сотни тысяч, максимум десятки миллионов документов, и вот тут всё становится гораздо интереснее...

Присоединяюсь

Мы делаем не “универсальный семантический поиск по всему законодательству”, у нас доменно‑ориентированный продукт под нормативно‑технические документы, в первую очередь строительная нормативка. То есть мы изначально не пытались покрыть весь корпус документов РФ, а целились в качество и доказуемость ответа в конкретном классе источников.

По объёму в нашей базе сейчас мы прилижаемся всего лишь к 150 документам, интересно, что у нас в силу специфики не только текст но бесконечное количество таблиц, формул и изображений. Это не “миллионы”, но уже достаточно, чтобы плоский RAG (чанки + векторка) начал регулярно терять обязательный контекст (соседние подпункты, примечания, ссылки, таблицы).

Стек на текущий момент:

  • Backend: NestJS

  • Хранилище структуры/разметки: PostgreSQL + Prisma

  • Поиск: Elasticsearch (lexical + vector + hybrid)

  • Эмбеддинги: отдельный embeddings‑сервис (768‑dim)

  • LLM‑слой: несколько специализированных “голов” под разные задачи (извлечение/нормализация, сборка контекста, генерация/верификация)

  • Инфраструктура: Redis, RabbitMQ

Про масштаб сотен тысяч/миллионов документов: там действительно почти всегда недостаточно “одного универсального поиска”. Рабочий вектор — маршрутизация запроса по доменам/коллекциям и затем специализированный retrieval‑конвейер, где обязательные связи подтягиваются детерминированно:

domain routing → навигация по структуре (иерархия/оглавление) → reranker → сборка контекста с mandatory/cross‑связями.

Это почти всегда дороже по latency/ресурсам/токенам, поэтому в проде приходится балансировать качество, скорость и стоимость.

Наш проект тут: https://sp-ai.ru (все открыто, денег не берем).

Спасибо, интересно!

https://github.com/techserv/Open-NotebookLM

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации