Как устроен SP-AI
Качество ответов на нормативных документах определяется не моделью и не удачным промптом, а тем, как устроены сами данные. Здесь — почему обычный подход здесь не работает и что это меняет в ответах, которые вы получаете.
Где ломается обычный RAG
Стандартная схема выглядит так: нарезать документы на фрагменты, посчитать эмбеддинги, сложить в векторную базу, подключить сверху модель. На демо это работает. На нормативке начинает сыпаться быстро.
Причина в том, что минимальная единица хранения и минимальная единица смысла в нормах не совпадают. Пользователь спрашивает про конкретное требование, семантический поиск находит похожий по формулировке пункт — но рядом есть подпункт, примечание или ссылка на другой документ, без которых ответ уже некорректен. Модель видит один подходящий кусок текста и отвечает так, будто этого достаточно.
Мелкие фрагменты теряют контекст, крупные дают шумный поиск. Проблема не в том, что модель недостаточно умна, а в том, что документ представлен слишком плоско.
Что мы сделали вместо плоского поиска
Норматив в SP-AI — не набор текстовых фрагментов, а связанная структура. Требования адресуемы по пунктам, таблицы и формулы существуют как самостоятельные объекты, а между требованиями зафиксированы связи, в том числе обязательные.
Практический смысл вот в чём: система не отвечает по одному «похожему» куску текста. Найдя релевантное требование, она проверяет, что необходимо учесть вместе с ним — уточняющий подпункт, примечание, таблицу, обязательную ссылку на другой документ — и собирает минимально достаточный контекст прежде, чем формировать ответ.
Поверх этой структуры работает не одна стратегия поиска, а несколько: один и тот же вопрос может требовать и поиска по смыслу, и точного попадания в номер пункта, и обращения к таблице. Результаты сводятся в общий контекст ответа.
Проверяемость ответа
Ответ обязан ссылаться на конкретный пункт в том виде, в котором его можно открыть и прочитать — «СП 1.13130.2020, п. 7.13.2». Это требование системы, а не пожелание к модели.
Если релевантного контекста в корпусе не нашлось, правильное поведение — сказать об этом прямо, а не собрать правдоподобный ответ по памяти модели. Инженер должен иметь возможность открыть документ и убедиться, что система ничего не придумала.
Как мы измеряем качество
Мы ведём собственный Evaluation Set — набор реальных запросов, отобранных из пользовательских логов, с разметкой по типу вопроса, дисциплине и сложности. Один и тот же набор прогоняется через несколько систем: SP-AI с нашим RAG и универсальные модели без доменного корпуса.
Каждый ответ независимо оценивается по единой рубрике, а не «по общему впечатлению». Критерии:
Главный вывод этих прогонов оказался не про «умность» моделей. Универсальная модель нередко объясняет инженерную логику даже лучше — но проигрывает там, где нужно открыть норматив и подтвердить сказанное. Разница между системами проходит не по качеству рассуждения, а по проверяемости.
Честно о границах
- Корпус наполняется. Сейчас размечены основные разделы проектирования — пожарная безопасность, общие СП, вентиляция, водоснабжение и канализация, электроснабжение, градостроительство. Полный фонд отраслевых норм ещё впереди; архитектура индексации спроектирована под масштабирование, поэтому рост корпуса не требует переработки ядра.
- RAG не устраняет проблему, а переносит её. Когда поиск находит несколько похожих нормативов или вопрос требует одновременно инженерного анализа и обхода нескольких документов, качество падает. Мы отслеживаем это отдельной таксономией ошибок.
- Честный отказ лучше уверенного ответа. Если нужного документа в корпусе нет, правильное поведение системы — сказать об этом прямо.