Когда PostgreSQL и pgvector достаточно для RAG — не изолированный приём, а решение внутри связанного конвейера данных, retrieval, генерации и контроля качества. Ниже — способ проверить его на собственном корпусе.
Начните с наблюдаемой проблемы
Зафиксируйте реальные вопросы пользователей, ожидаемые источники и тип ошибки. Не меняйте одновременно модель, chunking, индекс и промпт: тогда улучшение невозможно объяснить и воспроизвести.
Разложите RAG по этапам
Для каждого этапа сохраните версию конфигурации и технические сигналы. Финальный ответ без retrieved chunks недостаточен для диагностики.
Минимальный эксперимент
- Отберите 50–100 вопросов разных типов.
- Укажите релевантные документы и допустимые ответы.
- Запустите простую baseline.
- Измените один компонент.
- Сравните retrieval, groundedness, latency и стоимость.
Какие данные записывать
| Сигнал | Зачем |
|---|---|
| query и его преобразования | понимать, что реально искала система |
| document/chunk ids и scores | отделять retrieval от генерации |
| prompt и model version | воспроизводить ответ |
| citations и отказ | контролировать groundedness |
| latency и cost | связывать качество с эксплуатацией |
Типичные ошибки
- оценка на демонстрационных вопросах разработчика
- смешение старых и новых версий документов
- права доступа проверяются после retrieval
- успех измеряется красотой формулировки
- нет набора для регрессии после обновления индекса
Критерий готовности
Решение готово к следующему этапу, если команда может объяснить источник ответа, воспроизвести результат на фиксированной версии, показать отсутствие утечки прав и связать качество с бизнес‑метрикой. Иначе это полезный эксперимент, но ещё не production.