Comments 20
Спасибо за статью!
Подскажите, почему выбрали именно ChromaDB в качестве векторной бд?
Хотелось бы также увидеть какой-то промежуточный результат (пример данных на входе и на выходе)
Когда я у него спросил: "Напиши список сотрудников", он написал всех и добавил себя в конце.
Пробовал спрашивать по таблице сотрудников без RAG, что то типа большого списка имен, их возраст и профессия и запрос типа покажи 20 самых молодых программистов. И результат был явно неправильный, если не присматриваться то что то похожее на правду но если внимательно посмотреть то не было самого молодого и были повторы.
Можно ли верить таким роботам на слово?
Явно что то не так Ж(
Есть похожая проблема, когда он берет данные из таблицы, то часто смещает столбцы на одну строку. Например у нас есть таблица будущих отпусков напротив имен, и там выдает все неправильно со смещением на одну строку данных из второго стоблца. Пока не разбирался как это починить.
Всё сильно зависит от системных промтов и модели, если мы говорим о запуске локальных моделей. Банально - перевод. Если просто просить его переводить то он будет регулярно ломаться, но если написать длинющий текст с описанием и примерами, неожиданно качество перевода и количество "правильных ответов" сильно увеличивается. У того же 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 для своей компании