Мы делаем не “универсальный семантический поиск по всему законодательству”, у нас доменно‑ориентированный продукт под нормативно‑технические документы, в первую очередь строительная нормативка. То есть мы изначально не пытались покрыть весь корпус документов РФ, а целились в качество и доказуемость ответа в конкретном классе источников.
По объёму в нашей базе сейчас мы прилижаемся всего лишь к 150 документам, интересно, что у нас в силу специфики не только текст но бесконечное количество таблиц, формул и изображений. Это не “миллионы”, но уже достаточно, чтобы плоский RAG (чанки + векторка) начал регулярно терять обязательный контекст (соседние подпункты, примечания, ссылки, таблицы).
Стек на текущий момент:
Backend: NestJS
Хранилище структуры/разметки: PostgreSQL + Prisma
Поиск: Elasticsearch (lexical + vector + hybrid)
Эмбеддинги: отдельный embeddings‑сервис (768‑dim)
LLM‑слой: несколько специализированных “голов” под разные задачи (извлечение/нормализация, сборка контекста, генерация/верификация)
Инфраструктура: Redis, RabbitMQ
Про масштаб сотен тысяч/миллионов документов: там действительно почти всегда недостаточно “одного универсального поиска”. Рабочий вектор — маршрутизация запроса по доменам/коллекциям и затем специализированный retrieval‑конвейер, где обязательные связи подтягиваются детерминированно:
domain routing → навигация по структуре (иерархия/оглавление) → reranker → сборка контекста с mandatory/cross‑связями.
Это почти всегда дороже по latency/ресурсам/токенам, поэтому в проде приходится балансировать качество, скорость и стоимость.
Мы делаем не “универсальный семантический поиск по всему законодательству”, у нас доменно‑ориентированный продукт под нормативно‑технические документы, в первую очередь строительная нормативка. То есть мы изначально не пытались покрыть весь корпус документов РФ, а целились в качество и доказуемость ответа в конкретном классе источников.
По объёму в нашей базе сейчас мы прилижаемся всего лишь к 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 (все открыто, денег не берем).