Как вы работаете с Milvus в контексте RAG-системы?

Question

[accuM]

Здравствуйте!

Меня интересует очень душещипательный вопрос, как вы работаете с Milvus в контексте RAG-системы?

Я прохожу от и до, переживая все этапы взаимодействия с этой векторной базой данной, но так и не пойму каким образом я могу выстроить с ней качественную взаимосвязь.

В качестве документов я использую корпоративную документацию, которая вся написана на русском языке.

Весь процесс работы с Milvus Standalone происходит локально и выглядит следующим образом (Также дополняю его своим представлением):

1. Создание БД - это логический контейнер для хранения коллекций:
Технология: pymilvus

2. Создание коллекции:
- Определение схемы с обязательным первичным ключом (PK);
- Определение индексации, метрик и параметров векторных полей;
- Обязательно использование метода .flush для закрепления документов.

Технология: pymilvus

3. Обработка документов - это текстовые документы:
- Извлечение текста;
- Извлечение метаданных;
- Парсинг - удаление специальных символов.

Технология: Apache Tika

4. Разбиение на чанки (части) - это процесс умного деления содержания документов на части:
- RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=100)

Технология: langchain

5. Векторизация - это процесс кодировки текста документов:
- Используется модель ai-forever/sbert_large_nlu_ru, которая обучена на BERT и специально на русском языке;

Технология: transformers (HuggingFace)

Дальше идет взаимодействие с LLM, но мне незачем об этом упоминать, потому что проблема происходит на этапе получения результатов поиска.

Мной был проведен эксперимент, в котором я создал плотные вектора (dense) данных и разреженные вектора (sparse), чтобы опробовать несколько методов:

1. Для плотных векторов использовал такие основные типы индексов:
- FLAT (Полный поиск);
- HSNW (Графовый поиск);
- IVF_FLAT (Кластеры).

Для каждого типа индекса были применены три базовых метрики:
- COSINE (Косинус угла);
- L2 (Евклидово расстояние);
- IP (Внутреннее произведение).

Мне известно, что для семантики больше подойдет метрика - COSINE, но как итог, каждая метрика и каждый тип индекса отработали - ужасно, ни один не справился с задачей найти наилучший результат.

2. Для разреженного вектора использовал встроенную возможность Milvus - BM25, она автоматически создает разреженные вектора под данные. Тип индекса:
- SPARSE_INVERTED_INDEX, метрика BM25.

Очевидно говоря, текстовое соответствие отработало хорошо, но мне нужен не просто цитатник, который работает как обычный поисковик ключевых слов.

Milvus поддерживает гибридный поиск, который включает в себя поиск по плотным и разреженным векторам, где, в моем случае, есть плохой семантический результат и точное текстовое соответствие, после идет ранжирование с помощью RRFRanker, но мне важно не только соответствие, но и смысл, а также контекст, который должен быть в работе с плотными векторами и которого по факту нет.

Вопросы:

1. Подскажите, какие ошибки я допустил при работе с ВБД?
2. Какие типы индексов вы подбираете, на какое количество сущностей в коллекциях и почему?
3. Какие параметры для создания коллекции и далее для поиска сущностей в ней вы подбираете и почему?
4. Как вы обрабатываете документы, делите ли их на чанки, какие модели для эмбеддингов вы использовали и какие технологии применяете в обработке?
5. Как связываете результат поиска с LLM?
6. Как работаете с ограниченным контекстом LLM в части работы с результатом поиска?
7. Какой объем данных (количество векторов) вы обычно храните в одной коллекции?
8. Используете ли вы партиции (Partitioning) в Milvus? Если да, то как делите данные?
9. Как вы мониторите производительность Milvus (запросы в секунду, latency, нагрузка на CPU/GPU)?
10. Какие альтернативы Milvus рассматривали (Weaviate, Qdrant, Chroma, PGVector)? Почему выбрали Milvus?
11. Как решаете проблему обновления данных (инкрементальное добавление, переиндексация)?

Comments

[rPman]

подскажи примеры запросов и пример данных которые он не находит

Answer 1

[rPman]

RAG это когда берут из запроса пользователя вектор, и ищут среди векторов в базе ближайший (алгоритмы ты выше озвучил)

Смотри руками в базе, бери вектор своего запроса и ищи какие записи по нему проходят.

p.s. лично я считаю что RAG это исключительно поисковая система, для вопрос-ответных систем он подходит отвратительно (если честно я даже в шоке что у cursor что то получилось в принципе), отличный пример - поисковый запрос: 'Сколько ног у какающих принцесс' - вектор будет суммой (на самом деле не совсем но как пример) векторов смысла 'ноги', 'какать', 'принцессы', и 'обкаканые ноги' и что то там с комбинацией количеством, типа 'количество принцесс', 'количество ног' и т.п. а так как вектора смыслов работают еще и на близкие понятия, в довесок ты получишь какающих принцев, писающих принцесс, королей, президентов и т.п... как ты думаешь, сколько документов приедет в качестве ответа на запрос, если они каждый тоже совокупность (сумма) смыслов в них?

Если честно полученные документы нужно не брать верхушку результатов, а каждый обрабатывать полноценным промптом (можно использовать слабую модель) который уже будет принимать решение, нужно или нет...

Самая важная часть в получении эмбендингов - это разделение документа на чанки, и если честно я не знаю красивых алгоритмов... мне нравится идея (я ее только пробовал) - когда документы предварительно снабжаются самморизацией ее частей (в идеале отдельно по темам, на которую разрабатывается поисковая система) и вот искать нужно среди этих самморизаций.

p.p.s. ai-forever/sbert_large_nlu_ru? ничего не имею против него, но попробуйте другие модели получения эмбендингов, было бы классно если отпишитесь о результатах