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