9.1.2 · блок 9
RAG и векторные базы данных
RAG и векторные базы данных
Зачем это нужно
RAG позволяет отвечать по обновляемым внутренним документам без переобучения LLM. Но это production-пайплайн данных: неверный chunk, устаревший индекс или обход прав доступа ухудшат ответ даже у сильной модели.
Основные идеи
Векторная БД хранит embeddings и metadata, чтобы найти семантически близкие фрагменты. Qdrant — отдельная векторная БД; pgvector добавляет векторный поиск в PostgreSQL. Выбор зависит от нагрузки, уже имеющейся платформы и требований к фильтрам.
Chunking превращает документ в фрагменты. Размер и overlap — компромисс: слишком маленький chunk теряет контекст, слишком большой расходует context window и ухудшает точность поиска. Храните document id, версию, источник, права и позиции в документе.
Hybrid search объединяет keyword/BM25 и vector search. Ключевые артикулы, номера ошибок и имена сервисов часто ищутся лучше лексически, а перефразированные вопросы — семантически.
Retrieval ≠ generation. Оцените отдельно recall нужного фрагмента, ranking и groundedness ответа. Не пишите в prompt «ответь только по контексту», если контекст не проверяется.
Как это выглядит на практике
Pipeline: HTML/PDF → извлечение текста → chunks → embedding model → upsert в Qdrant с metadata → hybrid retrieval с фильтром department=ml → top-k chunks в prompt.
Для документа runbook-v7 старые chunks нужно удалить или пометить неактуальными. Иначе retrieval найдёт одновременно правила из v6 и v7, а модель уверенно смешает их.
Что сделать после занятия
- [ ] Выберите chunk size и overlap для одного типа документов, объясните компромисс.
- [ ] Опишите metadata, необходимую для удаления старой версии и контроля доступа.
- [ ] Составьте 10 вопросов и измерьте, находится ли правильный chunk в top-k.