Vector DB Testing

Смотрите тесты

Как использовать

• Убедитесь, что соответствующие пакеты установлены. Убедитесь, что следующее установлено: Support_transformers TQDM Pandas PYPDF2 TORCH ASYNCIO CONDURRENT RE QDRANT_CLIENT PINECONE PYMILVUS DOTENVV
• Загрузите все PDF в /data /или другой каталог, если указано.
  • Если у вас есть файл метаданных для получения дополнительной информации о файлах PDF, загрузите его в Home Directory и укажите его metadata.csv или измените имя. Код, вероятно, должен быть изменен в get_metadata () в MacLoader, чтобы приспособить ваш конкретный файл метаданных.
• Входные данные подключения в .env. Смотрите .env-example для того, как должен выглядеть ваш .env.
  • Этого можно избежать, если вы просто хотите ввести детали как часть инициализации БД в коде.
• Создайте индексный файл Python. Отсюда я бы определил соответствующие журналы. Со всеми данными важно искать любые проблемы. Все журналы соответствующим образом названы с использованием информации, предупреждения, ошибки и критического.
• Создайте delete.txt, не кладите в него ничего.
• Импортируйте соответствующие файлы из проекта и инициализируйте их с помощью соответствующих деталей. Все доступные параметры хорошо задокументированы и должны быть показаны вашим IDE посредством зависания или щелчка.
  • Пример: from Loader import MacLoader & from databases.PineconeDB import PineconeDB
• После запуска ваших файлов, ознакомьтесь с DELETE.TXT и посмотрите, какие файлы дают проблемы с читателем PYPDF2. Если вы хотите удалить эти файлы, используйте utility.delete_bad_pdfs ()
• Наслаждайтесь, дайте мне знать, как улучшить этот процесс!

Ключевые выводы

Предварительная обработка

Llama_index - это здорово, но его надежность узлов является настоящим препятствием. TextNodes кажутся очень полезными, но вместе с ним приходит много ненужных данных, которые вы загружаете со своим вектором, которые просто занимают хранение и производительность. Только по этой причине llama_index не должен использоваться для его усложнения процесса загрузки вектора. Дополнительные данные слишком много, когда они находятся в наборе данных по производственной шкале. Мне также не нравится, как это раздражает, иногда писать код с ним, так много странных правил и ненужных шагов. TextNodes может быть ценным мощным активом, если все управляется должным образом, при этом все дополнительные данные хранятся локально, а не мешают скоростям поиска или памяти.

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

В целом, я не могу найти что -то, что легко подходит именно так, как я хочу. Вот мое понимание того, как я думаю, что этот процесс должен идти:

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

Встраиваемые / трансформаторы

Выбирать трансформеры предложений было не слишком сложно.

• All-Minilm-V2 был хорош и быстрым, но я беспокоился о масштабируемости с огромными объемами данных. Не самый точный, но все еще хорош, но не для производства.

• E5-Large-V2 не удался базовый поиск данных в небольших масштабах в моих тестах. Из -за этого я не буду рассматривать это в более широком масштабе.

• Все занимает больше времени при встраивании инструктора , но они, вероятно, дадут гораздо лучшую точность данных. Я еще не проверил их.

• All-MPnet-V2 просто всего всего, с точки зрения скорости и производительности, может быть, не так точным, как встраивание инструктора, но скорость и производительность могут быть предпочтительны в производственной среде.

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

  • Важно считать, что ADA также встраивается в размере 1536 года. Это приведет к более высоким семантическим временам поиска из -за дополнительной математики, необходимой для гораздо большего количества измерений. Опять же, это также приведет к более высокой точности, но другие модели также могут выполнять высокие размерные встраиваемые без использования дорогих внешнего API.
  • Если использование локального трансформатора предложения ограничивает или неудобно, это отличная замена.

Окончательный выбор: неопределен. Мне нужно сначала закончить предварительную обработку, прежде чем выбирать между инструктором или mpnet

Векторные базы данных

Отклоненные базы данных

• Хрома
  • Не хватает параметров развертывания сервера. Для небольших проектов это всегда будет лучшим выбором, хотя я думаю.
• PGVector
  • По какой -то причине выступает очень плохо в критериях. Может не быть представителем реального мира, хотя. Смотрите здесь
  • Если база данных PotresQl уже планируется использовать, или она является практичной для данных данных, я не сомневаюсь, что PGVector будет лучшим вариантом. Тем не менее, я бы не стал использовать библиотеку PGVector самостоятельно или переключаться на Potresql для нее.
• Эластичный
  • Медленный и неуклюжий
• Укоренившись
  • Ранее я планировал оценить это, но, пытаясь реализовать это в этой программе, у меня было гораздо больше трудностей по сравнению со всеми остальными.
    • Документация для клиента Python совсем не очень хороша, это было не сумасшедшим, но отсутствие документации беспокоит.
    • Мой вариант использования планирует использовать управляемое облако, и WCS заставил меня действительно беспокоиться. Кажется, нет большой безопасности, нет даже 2FA. Я лично не доверяю WCS, и у него был худший пользовательский интерфейс по сравнению с любой из других баз данных.
    • Если планировать использование в контейнере Docker, Weaviate должен быть пересмотрен и дать справедливый выстрел, но сейчас я не продолжаю его оценивать.

В настоящее время расследует

• Pinecone
• Милвус
• Qdrant

Соображения от всего процесса

• В формате PDF так много мусора, и большинство погрузчиков едят это. Для снятия текста из PDF есть много мусора, особенно при использовании решения для чтения от Langchain или Llama_index. Не имея контроля над этим процессом, что было бы сложнее, чем было бы сделать пользовательский каталог PDF -загрузки.
  • Я думаю, что почти любой другой формат превосходит PDFS для чтения из массовых объемов данных. Так много проблем с кодированием, мусорными персонажами и нечитаемым текстом PDF -файла PDF и заклиниванием трубопровода.
• Текстовые данные могут храниться во всех векторных базах данных, если это необходимо. Это значительно упростит процесс хранения. Многие векторные базы данных позволят это в форме метаданных, но не позволяя отдельно хранению текста, которое может быть проблемой. Текст слишком велик, и память интенсивна, чтобы также храниться в памяти, а метаданные можно хранить на диске, но тогда фильтрация метаданных не будет доступной.
  • Если векторная база данных не обрабатывает это должным образом, процесс загрузки вектора может быть упрощен только путем загрузки векторов и идентификатора. Когда выполняется семантический поиск, найдите локальную базу данных или базу данных NOSQL из связанного идентификатора.