Спасибо за вопрос! Вы верно подметили, что эмбеддер — это лишь часть системы поиска. Обычно RAG сочетается с гибридным подходом: классическое индексирование (например, по метаданным вроде дат, авторов или ключевых слов) комбинируется с векторным поиском.
Мы используем Milvus, он позволяет гибридный поиск без дополнительных надстроек. Также стоит отметить, что это не самая простая для настройки система.
Для быстрой и простой реализации я бы порекомендовал связку PostgreSQL с расширением pgvector для хранения и фильтрации векторов по метаданным (даты, авторы, факты) и FAISS для быстрого поиска ближайших соседей по эмбеддингам. Например, сначала в PostgreSQL делается выборка ID векторов по заданным фильтрам, а затем FAISS выполняет поиск по близости к запросу. Это эффективно и масштабируемо. Elasticsearch тоже подходит, особенно если важна полнотекстовая индексация, но для задач с упором на векторный поиск связка PostgreSQL+FAISS часто проще и дешевле.
Изначально документы были в формате ворда. Мы разбили их по главам/параграфам относительно содержания, которое указано в начале документа. И уже внутри каждой главы/параграфа выделяли чанки. Нашли этот подход более эффективным.
По железу: две 4090 24гб. Ориентировались на нагрузку в ~10 пользователей.
По поводу чанкера:
Многие семантик чанкер решения работают по API. API варианты нам не подходят ввиду требований безопасности. Открытые решения по типу langchain с выбором энкодера с HF не дали приемлемого результата. Также решение по выбору рекрсивного чанкера обусловлено общей идеей алгоритма о выделении структуры. Ну и что немаловажно, рекурсивный чанкер отрабатывает гораздо быстрее и меньше нагружает систему.
OpenWebUI не рассматривали. Посмотрели несколько других инструментов и пришли к выводу, что лучше написать свой, подходящий под нашу структуры документов.
Все верно, таблицы нужно обрабатывать отдельно от основного текста. Идея та же - сохранение структуры. Вычленяем название таблицы, названия столбцов, а затем считываем ее построчно.
Например:
Чанк1:
«название таблицы: таблица 1
Столбец 1: текст из первой строки первого столбца
Столбец 2: текст из первой строки второго столбца»
И так далее для всех строк. Получаем для каждой строки таблицы отдельный чанк. Это может быть эффективно, ведь зачастую тексты в таблицах не связаны.
Да, вы все верно подметили.
Спасибо за вопрос! Вы верно подметили, что эмбеддер — это лишь часть системы поиска. Обычно RAG сочетается с гибридным подходом: классическое индексирование (например, по метаданным вроде дат, авторов или ключевых слов) комбинируется с векторным поиском.
Мы используем Milvus, он позволяет гибридный поиск без дополнительных надстроек. Также стоит отметить, что это не самая простая для настройки система.
Для быстрой и простой реализации я бы порекомендовал связку PostgreSQL с расширением pgvector для хранения и фильтрации векторов по метаданным (даты, авторы, факты) и FAISS для быстрого поиска ближайших соседей по эмбеддингам. Например, сначала в PostgreSQL делается выборка ID векторов по заданным фильтрам, а затем FAISS выполняет поиск по близости к запросу. Это эффективно и масштабируемо. Elasticsearch тоже подходит, особенно если важна полнотекстовая индексация, но для задач с упором на векторный поиск связка PostgreSQL+FAISS часто проще и дешевле.
Изначально документы были в формате ворда. Мы разбили их по главам/параграфам относительно содержания, которое указано в начале документа. И уже внутри каждой главы/параграфа выделяли чанки. Нашли этот подход более эффективным.
По железу: две 4090 24гб. Ориентировались на нагрузку в ~10 пользователей.
По поводу чанкера:
Многие семантик чанкер решения работают по API. API варианты нам не подходят ввиду требований безопасности. Открытые решения по типу langchain с выбором энкодера с HF не дали приемлемого результата. Также решение по выбору рекрсивного чанкера обусловлено общей идеей алгоритма о выделении структуры. Ну и что немаловажно, рекурсивный чанкер отрабатывает гораздо быстрее и меньше нагружает систему.
OpenWebUI не рассматривали. Посмотрели несколько других инструментов и пришли к выводу, что лучше написать свой, подходящий под нашу структуры документов.
Все верно, таблицы нужно обрабатывать отдельно от основного текста. Идея та же - сохранение структуры. Вычленяем название таблицы, названия столбцов, а затем считываем ее построчно.
Например:
Чанк1:
«название таблицы: таблица 1
Столбец 1: текст из первой строки первого столбца
Столбец 2: текст из первой строки второго столбца»
И так далее для всех строк. Получаем для каждой строки таблицы отдельный чанк. Это может быть эффективно, ведь зачастую тексты в таблицах не связаны.