Исходная идея

Часто приходится искать в огромной куче документов какую нибудь частную, специфичную вещь. На данный момент, только лично у меня более 2Gb различных pdf файлов. Зачастую разбросанных не системно. И хотя обычно представляешь где искать, но это отнимает время. Захотелось иметь инструмент ускоряющий поиск.

Первая мысль: “a не до обучить ли какую ни будь сетку на данных из документов”.

Остался вариант "векторная БД + RAG"

Казалось все просто. Накидать за пару вечеров код, что бы получить векторный поиск по смыслу и прикрутить генерацию LLM по вопросу и найденному чанку. Обычная «наивная» реализация RAG исходя из ограничения аппаратных ресурсов.

Исходя из объективно/субъективных требований выбрал архитектуру

1. Ollama с вызовом http+json API ('/api/embed' + '/api/generate') напрямую.

2. Qdrant в виде docker контейнера (быстро и просто). Обращение через http+json api

3. Хранение документов и картинок страниц на файловой системы и ссылками на них в payload записей Qdrant.

4. Одностраничный сайт для поиска без идентификации/аутентификации (домашняя сеть же)

Так оно и оказалось. Написать ПО оказалось не долго. Действительно ничего принципиального сложного.

Но, вылезли первые нежданчики. Ответы в топе были, мягко скажем, не адекватны вопросам.

Внимательно просмотрев код, данные чанков, логи и не найдя явных ошибок ни в логике ни в данных, решил начать с нуля. Т.е. с примеров на «причесанных данных», которые приводятся в Интернете и идеально работают.

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

Эксперименты в песочнице с разными моделями

В статьях постоянно приводят же примеры прямо в jupyter notebook «вот 10 строк залили в chromadb, а вот сразу нашли нужный текст по запросу». Решил пойти по шагам от этого. Что бы понять почему на реальных данных все так красиво не работает.

Данные для тестов нагенерил конечно не сам (LLM), но вычитал и явного бреда там нет. (https://github.com/mmMikeKn/local-vector-db/tree/main/py_tests/tests_local)
Как оказалось, выбор модели эмбеддинга имеет решающее значение. И не нужно никому доверять в оценках модели. Нужно проводить тесты самому. Графическое отображение результатов тестов по моделям показался более наглядным чем просто обобщенные цифры.

• Точка на диаграмме – это чанк в списке ответа на поиск. Оси: X - номер вопроса, Y - дистанция между вектором вопроса и вектором найденного чанков в топе выдачи.

  • Зеленый цвет – найденный чанк прямо соответствует вопросу (в тестовых данных). Остальные точки серые – это другие чанки в списке найденных. Просто для наглядности что бы оценить их "дистанцию" до вопроса.

  • Красный цвет – ни один найденный чанк не соответствует вопросу.

Признаки наилучшего поиска на диаграмме

• Зеленая точка лежит ниже всех и максимально близко к 0 (ось Y). Т.е. "дистанция" между вектором эмбеддинга вопроса и ответа минимальная.

• Серые точки лежат заметно выше зеленой – хорошая дифференциация ответов в списке найденных ответов.

• Красный точек нет (ну или очень мало)

Результаты всем моделям можно посмотреть в https://github.com/mmMikeKn/local-vector-db/tree/main/py_tests/tests_local/plt

Все тесты сделаны на одном и том же наборе данных

Модель embeddinggemma:latest

Несмотря на то, что модель свежая, но она отвратительная по качеству. Размер 621 MB (_{размер привожу в том, сколько фактически займет GPU памяти. Для меня это важней, чем количество параметров}), контекст 2048, вектор 768. Время расчета эмбеддинга не предсказуемо в широких пределах. От 300ms до 30 сек (!). Почему? Не знаю. Не вникал и не интересно. Есть из чего выбирать.

Диаграммы тестов

Модель (русскоязычная) evilfreelancer/FRIDA:latest

Просто не грузится в ollama с ошибкой INFO source=sched.go:438 msg="Load failed" model=/usr/share/ollama/.ollama/models/blobs/sha256-b94dd828625ffee6bd86723e18c5bf8b7a452d71d8d981dde45a974134c8bb03 error="llama runner process has terminated: exit status 2". Хотя находится в списке доступных для ollama и версия ollama, судя по описанию, подходящая. Не стал разбираться. Тем более, что у нее окно контекста всего 512

Модель evilfreelancer/enbeddrus:latest

Позиционируется как до обученная на русском. Размер 336MB, контекст 512.
Да простят меня авторы модели, но, по моим тестам, оказалась хуже мультиязычных схожего размера.

Диаграммы тестов

На этом закончил эксперименты с «русскими» моделями и занялся мультиязычными. Все они, кроме 'qwen3-embedding' оказались приблизительно похожи +/- по результатам.
Но явно видна корреляция между общим размером модели в памяти GPU (оцениваю по ресурсам GPU) и результатами. Чем больше, тем лучше результат. Что ожидаемо.

После всех экспериментов остановился на

Модель qwen3-embedding:latest

Довольно «тяжелая» модель 4.7 GB с огромным контекстным окном и размерностью вектора в 4096. Основной недостаток – высокое потребление ресурсов GPU. Слышно, как включается вентилятор на карте при обработке всех документов. На остальных моделях такого нет. Но время расчета вектора стабильное в рамках одного и того же размера чанка. Для чанка в 2-3Kb байт (условно) это где-то 1000-1200ms. Но полностью использовать огромное контекстное окно данной модели для данной цели не стоит.

1. Сильно увеличивается потребление ресурсов GPU на больших данных контекста.

2. Крупные чанки документа приводят к не релевантным результатам поиска по коротким вопросам.

Диаграммы тестов

В результате модель "qwen3-embedding:latest" и была выбрана мной как рабочая для получения эмбеддинга по всем моим документам.
За ночь (удалил лог не посмотрев время) все обработалось и загрузилось в qdrant.

Мои впечатление и выводы от поиска по векторной БД и RAG

Восторженные статьи замалчивают недостатки как векторного поиска, так и RAG. В области AI вообще тренд "щенячьего восторга". Мне это всегда казалось сомнительным («..и вы то же говорите, что 10 раз за ночь») и собственный опыт это подтверждает. Да _{<сараказм>}AI_{</сараказм>} инструменты. Да удобные. Но вот не прям "ого..ого" с решением вопроса "42".

Контекстный поиск, совсем не заменяет поиск по подстроке

Если вам нужно найти что-либо очень конкретное, например, документ (страницу документа) со строкой вида «Требование 492», то вероятность, того, что страница с этим текстом попадет в топ результатов поиска по вектору контекста близка к 0.

Малейшее изменение формулировки вопроса и получите другой набор результатов в топе выдачи. Все красиво на тестовых данных. А когда у вас есть ~100 очень похожих по стилю документов, на близкую тему, в которых полно таблиц, диаграмм, бюрократически/технически жаргонных оборотов и т.п., то нужно как минимум знать, что должно найтись.

Нужно постараться, что бы за несколько попыток поиска с разными формулировками найти нужный документ (_{хотя бы документ, не говоря уж о нужной странице}). И никогда точно не знаешь: не нашлось потому что просто нет, или потому что далеко по контексту для данной модели эмбеддинга.

Все что работает «как бы хорошо» в контекстном поиске по товарам Озона (_{хотя лично меня он бесит. А вас? Недоделка какая-то, а не поиск}), очень плохо работает для задачи поиска в технической документации.

Теперь о RAG

Лично мне, он был не особо нужен. Достаточно было png страниц документов на экране для быстрой оценки и ссылок на документы для скачивания. Но прикрутить было не долго и прикрутил (отдельной кнопкой на странице сайта). Но:

• Скармливать весь документ в контекст запроса – не тянет GPU 16Gb. А для облачных LLM быстро токены кончатся, если в контекст передавать весь документ.

• Чанк, по реальному документу, это, зачастую, обрывки мыслей и с этим LLM не справляется. Что локальная типа Qwen3-Coder-REAP-25B-A3B-MXFP4_MOE-GGUF:latest, что чатботы «больших» LLM.

  • Несут банальности на которых обучались, игнорируя содержимое чанка.

  • Впадают в откровенный бред.

• Результаты (_{ну если не фиксировать параметр options.seed в запросе к LLM}) будут каждый раз разные. И никогда не будешь знать: каких то данных в ответе LLM нет потому что их вообще нет, или потому что механизм генерации очередного токена в LLM обошел нужное тебе ветвление предсказаний очередного токена.

В общем то, что "говорит" LLM по вопросу + текст чанка меня сильно разочаровало. Хотя возится и подбирать системные промты и прочее не стал.

Даже большие LLM иногда такой убедительный бред несут, когда их спрашиваешь про узкие/частные случаи, которых не было или было мало в исходных данных обучения. А искать приходится не "почему небо голубое?", а информацию которой просто нет в Интернете (служебные документы и т.п.).

Ссылка на проект [GitHub](https://github.com/mmMikeKn/local-vector-db)