Комментарии 8
Рассматривали ли вы OpenWebUI в качестве инструмента для данной задачи? Сам делаю нечто похожее с его помощью, но пока не добился достаточного качества результатов на 12Гб GPU
Отдельная боль таких документов - таблицы, которые могут иметь разные структуры и размеры
Все верно, таблицы нужно обрабатывать отдельно от основного текста. Идея та же - сохранение структуры. Вычленяем название таблицы, названия столбцов, а затем считываем ее построчно.
Например:
Чанк1:
«название таблицы: таблица 1
Столбец 1: текст из первой строки первого столбца
Столбец 2: текст из первой строки второго столбца»
И так далее для всех строк. Получаем для каждой строки таблицы отдельный чанк. Это может быть эффективно, ведь зачастую тексты в таблицах не связаны.
Спасибо за то, что поделились опытом. Неужели Semantic Chunking хуже Recursive?
Под какой GPU ориентировались?
По железу: две 4090 24гб. Ориентировались на нагрузку в ~10 пользователей.
По поводу чанкера:
Многие семантик чанкер решения работают по API. API варианты нам не подходят ввиду требований безопасности. Открытые решения по типу langchain с выбором энкодера с HF не дали приемлемого результата. Также решение по выбору рекрсивного чанкера обусловлено общей идеей алгоритма о выделении структуры. Ну и что немаловажно, рекурсивный чанкер отрабатывает гораздо быстрее и меньше нагружает систему.
А в каком формате были изначально документы?
И, возможно, их надо сначала разбить по абзацам и предложениям (см. библиотеки razdel и SpaCy)
RAG: борьба с низким качеством ответов в условиях экономии памяти на GPU