Как проверить RAG-ассистента до внедрения

1. Выберите задачу и исходный процесс

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

Измерьте текущий процесс на типичных примерах: время поиска, проверки и исправления. Эти измерения станут основой сравнения. Цель пилота — проверить рабочий процесс целиком, включая человека, а не только скорость генерации текста.

• Одна задача и её пользователь
• Текущий способ решения и затраты времени
• Ответственный за проверку результата
• Граница действий, которые ассистенту разрешены

2. Подготовьте документы и права доступа

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

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

• Актуальные документы и владелец каждого источника
• Версии и правила обновления базы
• Разделение документов по правам
• Сценарии удаления и отзыва доступа

3. Соберите контрольные вопросы до настройки

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

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

• Типичные вопросы с ожидаемыми ответами и источниками
• Вопросы без ответа и противоречивые документы
• Проверка запрета на доступ к чужим данным
• Отдельный набор для проверки после настройки

4. Проверьте отказ и контроль действий

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

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

• Ответ при недостатке данных
• Проверка человеком значимых результатов
• Разрешённые инструменты и ограничения действий
• Проверки недоверенных инструкций в контексте

5. Оцените качество и стоимость вместе

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

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

• Результаты на независимом контрольном наборе
• Время сотрудника с учётом проверки
• Стоимость и задержка обработки
• Ответственные за документы, качество и отключение функции

Дополнительные материалы

• Microsoft Learn: устройство Retrieval-Augmented Generation