Качество ответа RAG зависит от того, как сформулирован запрос и что лежит в базе знаний. Ниже — типы вопросов, практические советы по формулировкам и границы ожиданий: чего от RAG ждать не стоит.
Тот же запрос уходит в пайплайн из UI (/chat/) или через POST /api/v1/query — разница только в обёртке аутентификации и истории диалога.
Типы запросов
RAG хорошо справляется с вопросами, ответ на которые есть в загруженных документах. Удобно различать три типа.
| Тип | Пример | Что ожидать |
|---|---|---|
| Факт, команда, код | «Какая команда для проверки порта 5432?», «Какой параметр nginx для таймаута?» | Точная выдержка или краткий ответ с цитатой из регламента или конфига |
| Процедура | «Как развернуть сервис X в staging?», «Что делать при ошибке Y?» | Пошаговый ответ на основе runbook'а или инструкции; ссылки на разделы |
| Сравнение, выбор | «Чем отличается A от B?», «Когда использовать гибридный поиск?» | Сводка из нескольких фрагментов, если в базе есть соответствующие описания |
Как формулировать запросы
- Конкретика — «как настроить nginx для reverse proxy к сервису auth» лучше, чем «как настроить nginx». Контекст сужает поиск и повышает релевантность.
- Указание контекста — если в базе несколько проектов или сервисов, можно явно указать: «в проекте X», «для сервиса Y». Часть RAG-систем поддерживает фильтры по метаданным.
- Перефразирование при пустом ответе — если ответ пустой или общий, попробуйте другую формулировку или более короткий запрос. Иногда запрос «команда проверки порта 5432» сработает там, где «как проверить, что PostgreSQL слушает порт» не нашёл точного совпадения по смыслу.
- Один вопрос за раз — сложные составные вопросы («сделай X и объясни Y») лучше разбивать на отдельные запросы.
Чего не стоит ждать от RAG
RAG отвечает только на основе загруженных документов. Он не «знает» то, чего нет в базе, и не подтягивает актуальные данные из интернета или из вашей инфраструктуры в реальном времени.
- Ответов вне базы — если в документах нет темы, ответ будет пустым или модель может начать додумывать; в хорошем RAG додумывание ограничивают промптом и явной пометкой «в базе не найдено».
- Актуальности «на сейчас» — данные в RAG такие, какими были на момент индексации. Изменения в конфигах или регламентах попадут в ответы только после обновления базы и переиндексации.
- Выполнения действий — RAG даёт справку и инструкции, но не выполняет команды и не меняет системы. Для автоматизации нужны скрипты и пайплайны.
Чек-лист: хороший запрос
- Сформулирован конкретно: указана тема, при необходимости — контекст (проект, сервис).
- Один вопрос или одна задача в одном сообщении.
- Ожидание реалистично: ответ возможен только из того, что есть в базе знаний.
- При пустом или нерелевантном ответе — попробовать перефразировать или упростить запрос.
Готовый набор примеров запросов для тестирования RAG в DevOps-сценариях — в статье 10 сценариев вопросов для DevOps.
Вывод: Формулируйте запросы конкретно, при необходимости указывайте контекст и разбивайте сложные вопросы. Помните: RAG отвечает только по загруженным документам и не обновляется в реальном времени. При слабом ответе пробуйте перефразировать.