Флаг «выдуманная ссылка» судья ставит на ответ целиком, если нашёл в нём хотя бы один несуществующий документ или пункт. Знаменатель пометок — 400 судейских проходов на систему (100 ответов × 4 судьи): 120/400 у соло-версии против 8/400 у версии с контуром.
Четыре судьи, а не пять — как в таблице статьи: Gemini исключён из этого подсчёта, потому что, поймав выдуманную ссылку, он иногда обнулял все шесть оценок разом. Со всеми пятью картина та же: 15/500 против 168/500.
В разрезе ответов: у соло 60 из 100 помечены хотя бы одним судьёй (33 — минимум двумя, 7 — всеми четырьмя); у системы с контуром — 6 из 100 хотя бы одним, большинством — 1, всеми четырьмя — 0.
Теперь «из скольки ссылок». Вердикта по каждой отдельной ссылке судьи не выносили — флаг на уровне ответа. По текстам: соло-ответ ссылается в среднем на 3–6 нормативных документов (смотря что считать: уникальные документы или все упоминания), ответ с контуром — на 2–4. Если грубо пересчитать долю помеченных ответов в вероятность фабрикации на одну ссылку, выходит примерно 13–23% у соло против 1,5–3% с контуром: способ подсчёта двигает цифры, но разрыв в обоих случаях порядковый.
Всё выше — пометки LLM-судей по единой инструкции; точный подсчёт по каждой ссылке автоматическим верификатором цитат и независимая ручная разметка — следующий этап нашего исследования.
Мы делаем не “универсальный семантический поиск по всему законодательству”, у нас доменно‑ориентированный продукт под нормативно‑технические документы, в первую очередь строительная нормативка. То есть мы изначально не пытались покрыть весь корпус документов РФ, а целились в качество и доказуемость ответа в конкретном классе источников.
По объёму в нашей базе сейчас мы прилижаемся всего лишь к 150 документам, интересно, что у нас в силу специфики не только текст но бесконечное количество таблиц, формул и изображений. Это не “миллионы”, но уже достаточно, чтобы плоский RAG (чанки + векторка) начал регулярно терять обязательный контекст (соседние подпункты, примечания, ссылки, таблицы).
Стек на текущий момент:
Backend: NestJS
Хранилище структуры/разметки: PostgreSQL + Prisma
Поиск: Elasticsearch (lexical + vector + hybrid)
Эмбеддинги: отдельный embeddings‑сервис (768‑dim)
LLM‑слой: несколько специализированных “голов” под разные задачи (извлечение/нормализация, сборка контекста, генерация/верификация)
Инфраструктура: Redis, RabbitMQ
Про масштаб сотен тысяч/миллионов документов: там действительно почти всегда недостаточно “одного универсального поиска”. Рабочий вектор — маршрутизация запроса по доменам/коллекциям и затем специализированный retrieval‑конвейер, где обязательные связи подтягиваются детерминированно:
domain routing → навигация по структуре (иерархия/оглавление) → reranker → сборка контекста с mandatory/cross‑связями.
Это почти всегда дороже по latency/ресурсам/токенам, поэтому в проде приходится балансировать качество, скорость и стоимость.
Товарищ Политрук, докладываем по знаменателю.
Флаг «выдуманная ссылка» судья ставит на ответ целиком, если нашёл в нём хотя бы один несуществующий документ или пункт. Знаменатель пометок — 400 судейских проходов на систему (100 ответов × 4 судьи): 120/400 у соло-версии против 8/400 у версии с контуром.
Четыре судьи, а не пять — как в таблице статьи: Gemini исключён из этого подсчёта, потому что, поймав выдуманную ссылку, он иногда обнулял все шесть оценок разом. Со всеми пятью картина та же: 15/500 против 168/500.
В разрезе ответов: у соло 60 из 100 помечены хотя бы одним судьёй (33 — минимум двумя, 7 — всеми четырьмя); у системы с контуром — 6 из 100 хотя бы одним, большинством — 1, всеми четырьмя — 0.
Теперь «из скольки ссылок». Вердикта по каждой отдельной ссылке судьи не выносили — флаг на уровне ответа. По текстам: соло-ответ ссылается в среднем на 3–6 нормативных документов (смотря что считать: уникальные документы или все упоминания), ответ с контуром — на 2–4. Если грубо пересчитать долю помеченных ответов в вероятность фабрикации на одну ссылку, выходит примерно 13–23% у соло против 1,5–3% с контуром: способ подсчёта двигает цифры, но разрыв в обоих случаях порядковый.
Всё выше — пометки LLM-судей по единой инструкции; точный подсчёт по каждой ссылке автоматическим верификатором цитат и независимая ручная разметка — следующий этап нашего исследования.
Мы делаем не “универсальный семантический поиск по всему законодательству”, у нас доменно‑ориентированный продукт под нормативно‑технические документы, в первую очередь строительная нормативка. То есть мы изначально не пытались покрыть весь корпус документов РФ, а целились в качество и доказуемость ответа в конкретном классе источников.
По объёму в нашей базе сейчас мы прилижаемся всего лишь к 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 (все открыто, денег не берем).