ТЗ на RAG-систему: источники, права, цитаты и тестовый набор

Определите ответ, который нужен пользователю

ТЗ на RAG-систему должно начинаться с вопросов и допустимых ответов, а не с выбора векторной базы. RAG объединяет поиск подходящего контекста и генерацию ответа с его использованием. Поэтому ошибка может возникнуть при загрузке документа, поиске фрагмента, проверке доступа или формулировании вывода. Все эти этапы требуют самостоятельных критериев.

Выберите ограниченную область первой версии: например, ответы сотрудникам по действующим инструкциям одного подразделения. Укажите, какие решения система поддерживает, какие вопросы исключены и когда нужен человек. Не обещайте достоверный ответ на любой вопрос только потому, что в базу загружено много файлов.

Инвентаризируйте документы и версии

Для каждого источника укажите владельца, формат, язык, структуру, период обновления и признак актуальной версии. Два похожих файла могут содержать действующее и отменённое правило. Без метаданных система иногда находит убедительный фрагмент, который уже нельзя применять.

Проверьте образцы таблиц, сканов, вложений и документов со сложной вёрсткой. Качество извлечённого текста влияет на дальнейший поиск. В задании нужен контрольный пример: какой заголовок, значение и связь должны сохраниться после обработки. Количество успешно загруженных файлов не показывает, сохранился ли их смысл.

Согласуйте удаление и исправление. Если владелец отозвал документ, его фрагменты должны перестать участвовать в ответах в заданный срок. Проверять нужно также кэши, цитаты и повторные запросы. Это наблюдаемое требование, которое не зависит от конкретной технологии индексации.

Проведите права через весь путь данных

Пользователь должен получать только разрешённые ему сведения. Ограничение требуется для найденных фрагментов, текста ответа, цитат и скачиваемых оригиналов. Нельзя рассчитывать, что модель сама надёжно скроет запрещённый фрагмент, если он уже попал в её контекст.

Учебный тест: два сотрудника задают один вопрос, но имеют доступ к разным документам. Система использует только разрешённые каждому источники и не раскрывает содержание недоступного файла через пересказ. Затем право отзывают и повторяют вопрос в существующем диалоге, чтобы проверить обновление контекста.

Определите доступ к журналам и тестовым наборам. Они могут содержать выдержки из документов и пользовательские вопросы. Диагностика не должна становиться отдельным неконтролируемым каналом раскрытия знаний компании.

Задайте проверку поиска фрагментов

Подготовьте контрольные вопросы с известными подтверждающими фрагментами. Включите синонимы, сокращения, номера документов, похожие понятия и вопросы, на которые база не отвечает. Для каждого укажите нужный источник и объяснение, почему он подходит.

Обзор RAG в Microsoft Learn показывает роль поиска, структуры данных и релевантности контекста. Практическое требование вашего проекта должно быть конкретнее: какой фрагмент должен попасть в выборку и какие похожие фрагменты будут ошибочными. Выбор размера частей документа проверяют на реальном содержании, а не принимают как универсальное число.

Отдельно оцените таблицы и условия с исключениями. Если в контекст попало правило без следующего абзаца с ограничением, генерация может дать формально связный, но неверный ответ. Контрольный набор должен обнаруживать такие потери связи.

Опишите требования к ответу

Для каждого типа вопроса задайте форму результата: краткое правило, последовательность действий, сравнение версий или указание на отсутствие данных. Важные утверждения должны иметь проверяемую опору. Ссылка на документ полезна только тогда, когда выбранный фрагмент подтверждает соответствующий тезис.

Согласуйте конфликт источников. Если есть установленный приоритет версий, он должен применяться явно. Если приоритета нет, система сообщает о противоречии и направляет вопрос владельцу. Нельзя незаметно смешивать несовместимые правила в один удобный ответ.

Отказ от ответа тоже требует качества: объяснить, какой информации не хватает, и предложить допустимый следующий шаг. Общая фраза «я не знаю» может быть честной, но недостаточной для рабочего процесса.

Отделите данные от команд

Внешний документ может содержать текст, похожий на инструкцию системе: раскрыть секрет, игнорировать ограничения или изменить источник. Материалы OWASP о prompt injection помогают выделить эту границу. Найденное содержание должно служить данными для ответа и не получать полномочия управлять инструментами или доступом.

Включите безопасные контрольные документы с такими попытками в тестовую среду. Проверяйте отсутствие раскрытия закрытых сведений и выполнения постороннего действия. Инструкция модели — только часть защиты; права и доступные операции должны ограничиваться архитектурой приложения.

Если система только отвечает, не добавляйте ей возможности изменять данные без отдельной задачи. Переход от поиска к действию требует новых подтверждений, журналирования и приёмочных сценариев.

Оценивайте поиск и генерацию отдельно

Сначала проверьте, найден ли правильный контекст. Затем оцените, соответствует ли ответ этому контексту и не добавлены ли неподтверждённые утверждения. Общий балл без разделения причин затрудняет исправление: плохой ответ может быть следствием хорошего поиска или наоборот.

Критические нарушения доступа и выдуманные обязательные правила нельзя растворять в среднем показателе удачных ответов. Для них задают отдельное условие отказа в приёмке. Порог качества, состав выборки и владельца оценки согласуют до испытаний, а результаты сохраняют вместе с версией данных и системы.

Добавьте проверку обновления документа и повторный прогон набора после изменения поиска. Старые успешные ответы не доказывают качество новой конфигурации. Время ответа и стоимость также измеряют на согласованной нагрузке, не обещая неподтверждённых значений.

Соберите требования к пилоту

В скачиваемом брифе соедините вопросы пользователей, источники, права, правила ответа и контрольный набор. Укажите владельца актуальности базы и порядок обработки спорного ответа. Пилот должен иметь границы, наблюдение и критерий остановки при критическом нарушении.

После запуска сохраняйте обратную связь с причиной ошибки: источник, поиск, доступ или формулировка. Такой разбор позволяет улучшать систему осмысленно. Сам факт наличия RAG не гарантирует достоверности; её поддерживают проверяемые данные, ограниченные полномочия и регулярная оценка.