Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 20
Спасибо за статью!
Подскажите, почему выбрали именно ChromaDB в качестве векторной бд?
Хотелось бы также увидеть какой-то промежуточный результат (пример данных на входе и на выходе)
Есть похожая проблема, когда он берет данные из таблицы, то часто смещает столбцы на одну строку. Например у нас есть таблица будущих отпусков напротив имен, и там выдает все неправильно со смещением на одну строку данных из второго стоблца. Пока не разбирался как это починить.
Всё сильно зависит от системных промтов и модели, если мы говорим о запуске локальных моделей. Банально - перевод. Если просто просить его переводить то он будет регулярно ломаться, но если написать длинющий текст с описанием и примерами, неожиданно качество перевода и количество "правильных ответов" сильно увеличивается. У того же LangCain есть примеры этих сумасшедших промотов в 3 абзаца.
Увы, с пол пинка не заводится(
Да тоже чувствую что нужно больше потратить времени на prompt engineering. Единственное что меня отпугивает - это по идее после каждого изменения промта - мне нужно оценить изменение по качестве RAG ответов, то есть прогнать например набор из 25 вопросов, которые я использовал изначально. И если что-то станет хуже, то опять менять и тюнить. Не могу пока придумать как этот процесс оптимизировать.
IMHO, просто не надо пытаться заменить нейросетями те задачи, которые и обычными средствами решаются (в данном случае тупо табличкой с настраиваемыми фильтрами и сортировкой). С помощью нейросетей надо решать те задачи, которые обычными средствами не решаются.
RAG очень интересен для задачек типа "найди в нашей корпоративной файлопомойке, накопленной за 20 лет, все документы, где ситуация максимально похожа на изложенную вот в этом файлике". И тут даже если он найдёт не всё / не точно - лучше неидеальный ответ, чем никакого.
А для обычных запросов, на которые должен быть дан вполне детерминированный ответ, оставим старые добрые средства.
векторная база ищет логику, текст. возраст в цифрах она не понимает. немного не про то твой запрос.
Очень полезная статья!
Сам сейчас занимаюсь похожей задачей, используя OpenWebUI + Ollama. В роли генератора использую deepseek-R1 7B Q4 с сайта Ollama, Embed-модель bge-m3. Запускаю всё это на RTX 3060 12Гб. Надо будет попробовать повторить ваш алгоритм действий
Я попробовал с локальными моделями на MacBook M3, очень низкое качество ответа и очень медленно работает, поэтому перешел полностью на cloud модели. Конечно можно тюнить, но оставил эту задачу на потом, сейчас охота поднять что-то полезное и сразу работающее.
Если уместиться в видеопамять (не уверен на счёт возможностей М3, но на 16 ОЗУ в теории будет грустно), то даже не самая мощная видеокарта способна выдать адекватную скорость. Но облако имеет слишком огромное преимущество по размеру окна контекста и кол-ву параметров самой модели (671B у DeepSeek R1 против 32B/70B моделей на 3090 и 7/14B на 3060-12) при чаще всего меньшей стоимости
А как долго происходил импорт в векторную базу данных? Просто у меня будут десятки миллионов документов и сотни миллионов их фрагментов, поэтому у меня сомнения на счет того, можно ли будет такой массив загрузить в обычную векторную БД за разумное время. Или они хорошо работают с большими объемами?
Есть приложение GPT4ALL, там есть способ закидывать в RAG огромные объёмы данных парой кнопок, так вот... Попробовал туда залить все исходники clang компилятора. Учитывая что у меня i9 13th и 64ГБ озу и raid0 на 20ГБс это заняло около 5 часов. (Справедливости ради их реализация какая-то странная, оно зачем-то уничтожало всю доступную ОЗУ и не сильно работало с диском. Но это пример уже "готовых" решений)
Я вот этого и боюсь. Давно сталкиваюсь с тем, что многие популярные решения хорошо работают с тысячами, десятками, ну сотнями тысяч документов, но на миллионах и более... спотыкаются. Хочу посмотреть в сторону ElasticSearch (точнее в сторону форка - OpenSearch), там видел возможность работы с векторами, а также поиск схожих документов. Да, там примитивно всё (в этой плоскости), но зато ориентировано на работу с большими объемами инфорамции.
Я пока заливал только wiki + один канал slack. Это за 7-8 лет истории, но получилось на удивление немного - несколько тысяч документов. По времени 5 минут на MacBook M3.
Исходя из своего опыта, полагаться только на «на контекст, сформированный по топу полученных векторов» — очень наивный подход, теряется уйма важных деталей. Стоит сразу смотреть в сторону решений вроде GraphRAG, и аннотации чанков дополнительными метаданными, теми же NER к примеру.
Записал попробовать GraphRAG + NER. Очень интересно на сколько лучше оно будет работать. Сейчас кстати уже неплохо на твердую 4 работает.
Мой опыт использования для RAG только векторов коротких фрагментов также негативный. Это годится разве что для коротких энциклопедических вопрос-ответов. А ситуация/проблема/задача как правило описываются не одним фрагментом, а несколькими связанными фрагментами, большинство из которых не связано напрямую с текстом запроса (особенно короткого). В итоге, в контекст не будет попадать исчерпывающее описание запроса пользователя, а попадет лишь маленький кусочек. А в худшем (и очень вероятном, особенно если запрос подробный) случае в контекст еще попадут фрагменты, не относящиеся по существу к запросу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я сделал RAG для своей компании