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