Локальный RAG нужен, когда компания хочет контролировать данные, сеть и обновления. Это не один продукт, а цепочка компонентов. Чем меньше новых технологий в первом контуре, тем быстрее команда получит измеримый результат.
Карта стека
| Слой | Задача | Варианты |
|---|---|---|
| Загрузка | Получить текст и метаданные | Собственные коннекторы, LlamaIndex |
| Хранение | Версии документов и права | Объектное хранилище, PostgreSQL |
| Векторный поиск | Найти смысловые фрагменты | pgvector, Qdrant |
| Оркестрация | Собрать поиск и генерацию | LlamaIndex или тонкий собственный слой |
| Оценка | Ловить регрессии | Версионируемый тестовый набор |
| Наблюдаемость | Время, стоимость, ошибки | OpenTelemetry и метрики приложения |
pgvector или Qdrant
pgvector удобен, если PostgreSQL уже является стандартом компании, объём умеренный, а транзакционные данные и фильтры хочется держать рядом. Qdrant полезен, когда векторный поиск становится отдельной высоконагруженной подсистемой и нужны специализированные возможности масштабирования.
Критерии выбора
- Поддерживает ли команда резервное копирование и восстановление?
- Можно ли обеспечить фильтрацию по правам до передачи фрагментов модели?
- Как измеряется качество поиска на вашем корпусе?
- Насколько легко заменить компонент без переиндексации всей системы?
- Есть ли понятные метрики задержки, ошибок и размера индекса?
Рекомендация AI Insider: для пилота на существующем PostgreSQL начните с pgvector. Выделяйте специализированную векторную базу, когда измерения покажут реальную потребность, а не потому, что архитектура выглядит современнее.
