Комментарии 7
Что если приблизить задачу к реальному сценарию?
кролим репозиторий документов с метаданными и контентом (тот же PDF). Контент в среднем 10к символов но может быть максимум до 10М символов текст. В контекст точно не влезет.
При этом поиск делаем как по метаданным, так и по контенту.
Имена полей в метаданных тоже необходимо маппить в NLP, к примеру dateModified дата изменения документа и тд..
Прогнать тест на 100м документов репозитории и посмотреть, заодно сравнить milvus и постгресс.
И было бы неплохо дополнить до гибридного RAG с поиском в векторном хранилище и в базе или люсин индексе, вроде моделей для люсин хватает в отличие от SQL...
Я бы сейчас для тренировки полепил такой поиск.
если получится уложиться во время поиска (после конверсии в вектора, без учета llm) до 10 секунд на 100м документах на обычном железе, то вполне неплохо.
В данной статье я делал упор не столько на вопросы производительности и выбор наиболее быстрого векторного хранилища, сколько на то, что Spring AI позволяет нам уже здесь и сейчас с минимальным количеством кода использовать RAG. Поэтому взял pgVector, т.к. большинство проектов на Spring-стеке использует postgres.
Касательно того, что документ может не влезть в контекст, в Spring AI есть такой класс как TokenTextSplitter. Он позволяет разбивать исходный документ на несколько частей. Параметры такого разбиения можно гибко настраивать.
А вы какое векторное хранилище предпочитаете использовать?
Собственно, в продакшн никакого пока не использовал. В саббатикале сейчас, после нескольких лет работы без нормального отпуска (два три дня когда не дергают), и нагоняю сейчас.
RAG смотрю так как это соприкасается с темой прошлой работы - миграция репозиториев документов и поисковые движки (в том числе самописные) на базе люсин. Типичные объемы - от 100 до 500 млн документов в одном репозитории. В начале этого года была миграция у клиента на 1.5 млрд документов (перед моим уходом). Т.е примерно понимаю что люди использовали в корпоративной среде (банки и страховые) для поиска документов и что ожидают.
PostgreSQL практически не касался больше 20 лет (в первом стартапе его использовали, затем формально перешли на Oracle), хотя база хорошая (по какой причине от нее активно воротили нос - не могу объяснить, возможно проблема моего окружения принимающего решения и выборка клиетов такая). MySQL к примеру, тащили (наверное из за стоимости в облаке Amazon), хотя как база это откровенное непонятно что.
В домашних условиях прототипирую кое что из положенного на полку и не доделанного, но большие объемы не прогнать ни на локальной сетке (квантированная модель, на 16ГБ чтобы входила), покупать через прокладки или напрямую доступ у OpenAI для теста хотя бы 10М документов (а лучше 100, 200) - дороговато. А без больших тестов оценить сложно на что это похоже.
Если к примеру, я могу хотя бы от 50-100 тысяч документов в час кролить включая создание embedding векторов (а он понадобится не один, так понимаю, если обрабатываем контент со скользящим окном), то уже можно с натяжкой этим методом пользоваться у более менее крупного клиента. Подобные скорости кролинга с контентом типичны и для on premises репозиториев, типа FileNET, и у облачных провайдеров контента типа Box или Sharepoint (если удавалось договориться и уменьшить тротлинг).
Пользователи хотят:
Скорость поиска - до 10 секунд, лучше до 5.
Скорость обновления (документ изменился, поиск тоже, счет на минуты). Иногда приходилось обновлять индекс одновременно с репозиторием (preemptive update), у того же Box, к примеру, события приходят с задержкой от секунд до десятков минут (а это "не есть хорошо"...)
Еще и security втащить. Хотя это совсем не "кошерный" вариант, но если H2 использует Lucene для полнотекствого поиска, то почему бы не всунуть индекс для ускорения join в Lucene? Без join получается денормализованные записи, при изменении общих полей (security) могут быть огромные по объему обновления. Лучше этого избегать, конечно в NoSQL, включая люсин. В Postgres большой плюс - это уже нормальная база с join. Что делать если нужен обычный поиск по полям метаданных, векторный поиск по контенту (семантическое сходство, по словам или по тексту) и join сверху?
У меня пока недостаточно опыта для оценки, какое железо для нужной производительности потребуется для RAG, чтобы LLM модели с достаточной скоростью (и точностью) создавали вектора. Не получится ли что проще будет плюнуть на RAG и создать поиск старыми способами а РАГ оставить для чат ботов...
Проверка быстродействия RAG на объёмах 50-100 тысяч документов - эта тема заслуживает отдельной статьи! Но мне кажется если мы говорим в основном про поиск документов, то RAG действительно не самое оптимальное и далеко не дешёвое решение.
Вы верно подметили про RAG и чат-ботов, потому что порой интересно даже не поиск информации "как есть" в документе, а вывод из существующей информации новых фактов.
Например, где-то среди тысяч документов в описании конкретного процесса всего 1 раз упоминается, что "... согласованием занимается Иванов (начальник отдела документооборота)...", чат-бот нам сможет ответить и кто такой Иванов (в контексте именно данной компании), и кто является начальником отдела документооборота.
RAG было бы полезно использовать, если цена конечно (и быстродействие) позволят.
Поправлю условия по количеству документов: не 50-100 тысяч, а 50-100 тыс в час, добавление. Всего для мелких организаций (небольшой банк и тд) достаточно 10 млн документов. Для более менее крупных контор типично от 100 до 500 млн.
Еще вопрос по RAG - предположим что контент большой, в разы больше контекста LLM модели. Мы создаем вектора и тд. А вопрос будет касаться содержимого начала и конца документа, те разных векторов и у них совпадение по отдельности будет так себе. Т.е RAG хорошо будет работать когда контекст почти того же размера или больше чем размер контента документа и непонятно как работать когда контент в разы больше... И следующее - поиск по метаданным, наверное, через RAG гонять не нужно, достаточно сформулировать запрос по метаданным в языке запроса который LLM "по зубам"
Интересно, что можно сделать с графовой базой, если уйти от векторов сразу в knoledge graph, RDF, knowledge graph DB. Ссылки:
https://migalkin.github.io/posts/2023/03/27/post/
https://migalkin.github.io/kgcourse2021/lectures/lecture1
PS понятно что фантазии пока, но я на саббатикале, и могу себе позволить "подурить" на непрактичные темы. Хочется иногда забыть чем занимался на работе.
Сейчас LocalAI ставлю, попробую с локальной сеткой квантированной embedding прогнать, наверное печальная будет скорость... подозреваю что неприемлимая
50-100 тысяч документов в час... тут явно ведь не про базу знаний речь идёт?)
Не база знаний, обычные бизнес документы, договора, ипотечные всякие, страховые кейсы, медицинские (из того чего касался). 50-100 тыс это скорость кролинга документов в час, как правило, причина торможения это обработка контента. Без контента типичная скорость около 1 млн /час. Еще важно тротлинг применять и сажать репозиторий в рабочее время (по ночам основная работа). Всего документов, к примеру, 10 миллионов - это детский объем на самом деле. С ними работают примерно 500 пользователей (активных сессий), это включает поиск в индесе, редактирование документов в репозитории, оттуда обновленные документы добавляются кролером в индекс (перезаписывая старую версию), и тд, по кругу. Удаление документов из репозитория - событие которое отрабатывает кролер и удаляет запись из индеса. Если идет массовое обновление или реиндексация, то при максимальной скорости кролинга в 100 тыс/час (к примеру) и 10 млн документов, нам понадобится 100 часов, это почти неделя, но в реальности две или три, так как активный кролинг нагружает репозиторий и придется кролить в нерабочее время. А теперь представим что документов не 10 млн а 200 или 300 млн - это обычный индекс в нормальном банке или страховой. Значит, документы желательно кешировать (хоть в файловой системе или в какой то базе которая хороша как кеш, cassandra или что то подобное, главное чтобы скорость записи не падала сильно при росте объема). С подобной базой кешем рекролинг будет быстрее, уже 2,3, 5 миллионов документов в час на обычном PC. Значит изменять индексы и заменять можно шустрее. Был клиент у которого индекс кролился 4 месяца, кеш он по религиозным мотивам (иначе понять не могу) не ставил (типа, некому будет обслуживать а архитекторы не подумали и пропустили мимо ушей предупреждения) - в итоге на индекс молился. Позже вскрылись баги кое какие, в типах люсин, и пришлось вместо обновленного код и рекролинга делать обходные патчи в логике в поисковике. Сейчас этим индусы занимаются, не знаю что там и как. Думаю все хорошо, деньги есть.
Посмотрел эластик, с ним мало имел дело, после 5й версии не касался его, он сильно изменился, оброс и заматерел, скачал исходники, надо посмотреть его лучше. Он мне раньше нравился, видно по уровню кода что команда сильная. Попробовал localAI с моделью отсюда https://www.elastic.co/search-labs/blog/localai-for-text-embeddings и сразу воспроизвел баг (да что ж такое) https://github.com/mudler/LocalAI/issues/4529 и https://github.com/mudler/LocalAI/issues/3886
четко по статье все поставил и поймал проблему, видать когда статью писали, бага не было. С другой моделью попроще запустил
curl http://localhost:8080/embeddings -X POST -H "Content-Type: \
application/json" -d '{ "input": "Your text string goes here", "model": "text-embedding-ada-002" }'
Вектор выплюнула, замерю попозже на пачке и на разных моделях.
но это пожалуй, для обучения, не более, скорость низкая на домашней игровой карточке.
Пардон за много букв...
Spring AI: retrieval augmented generation