Комментарии 27
Вот прямо лайк за разжёвывание с нуля доступным языком, продолжайте в том же духе. Статей по RAG последнее время множество, но мне было бы сильно легче въехать в тему, если бы в своё время первой статьёй по этому вопросу оказалась Ваша :)
Спасибо за статью, жду продолжение!
Можно ли сделать ассистента который не просто будет искать нужный контекст, но и отвечать на аналитические вопросы. К примеру: Сколько пылесосов с такой-то функцией? Сколько продаж пылесосов было в прошлом месяце и на какую сумму? Какие товары лучше всего продавались осенью прошлого года?
Спасибо за обратную связь. Тут все будет зависеть от задачи в промпте к нейросети. На первом этапе собираете информацию через "умный поискови", ставите нейросети задачу и получаете ответ уже с анализом)
Правильно ли понимаю, что векторный поиск может только искать нужные документы, а не проводить аналитику?
К примеру если я задам вопрос: сколько пылесосов такой марки?
В этом случае от векторного поиска (get_relevant_context) я получу первые три пылесоса, и в ответ мне ии скажет что всего 3 пылесоса, хотя в базе их может быть 100 или более.
То есть в данном случае мы получаем поискового помощника. Я хотел спросить, можно ли сделать аналитического?
Векторный поиск - это поиск. И ничего более. Аналитика - это совсем другое. Процесс обработки найденной информации.
При векторном поиске вы найдете куски векторизированной информации наиболее похожих на поисковый запрос. Как из этих кусков получать информацию для анализа, отдельный вопрос. Связанный с процессом векторизации, формированием запроса и наличием метаданных
Поясните пожалуйста, почему в скриптах несколько раз упоминается OpenAI, но нигде не используется?
"OpenAI - это компания, которая выпустила, кроме всего прочего, нейросеть ChatGPT." Спасибо большое, теперь буду знать, это так неожиданно....
def init(self, provider: Literal["deepseek", "openai"] = "deepseek"):
deepseek вижу, что используется, а openai вроде как не используется?
А если серьёзно, напишите лучше про GraphRAG, ну и про LangGraph
Вот что я пока так и не понимаю - насколько важно чтобы get_relevant_context использовала векторную базу? Особенно в вашей реализации где (насколько понимаю) не веса идут в контекст а текст.
Есть ли причины почему это не может быть например функция которая дергает ElasticSearch, ищет там подходящие документы, делает из них snippet'ы и скидывает LLM? (ну или например :) - тупо дергает API гуглояндекса, затем получает тексты страниц (либо напрямую грузит запросом либо хитростями - да хоть Firecrawl'ом) и скармливает LLM)
Или с векторной базой будет сильно лучше в любом случае будет результат?
Векторная база данных, в первую очередь, про поиск по смыслу, а не по прямому текстовому вхождению. Как по мне, этот подход самый оптимальный. Вот, например, вы говорите Яндекс дергать. Каким образом вы будете уменьшать собранный контекст перед промптом?
Как вариант - не буду вообще. возьму поля passages из ответа ( https://yandex.cloud/ru/docs/search-api/concepts/response )
(с ElasticSearch все вообще проще)
Вот хотелось бы пояснения подробное чем подход с векторной базой лучше.
Потому что яндекс не имеет доступа к вашей коллекции порнухи документов?
Скармливаете вашу коллекцию ллм-ке, а она вычисляет по эпизодам, что в этом фильме X+Y, а в этом 2X+Y, тут 2Y+X, а может и Z+Y, еще и указатели сохраняет на эти эпизоды. А потом по запросу - а что бы такое мне посмотреть экзотическое? Большая модель поймет, что из этих комбинаций является экзотикой (может быть даже персонально для вас) и выдаст где искать.
В случае если речь идет про мою коллекцию то будет не
(ну или например :) - тупо дергает API гуглояндекса,
а
Есть ли причины почему это не может быть например функция которая дергает ElasticSearch,
(собственно уже есть)
И хотелось все же понять чем вариант с векторной базой которая готовит материал для LLM лучше чем "старые" альтернативы
Поиск тоже имеет право на жизнь, llm может его дергать, например посредством mcp сервера/агента. Но если речь о поиске "смыслов", то простой поиск спасует, например, перед омонимами - "точил косу", "шел косой дождь", "косой скрылся в перелеске", а ты спрашиваешь - "как мне заплести косу дочке?" Это из очевидных примеров.
Сила векторной базы мне видится в работе с нетекстовыми данными. Ты скармливаешь картинки и обычный поиск работает только с метаданными (размеры картинки, где снято, формат и тд), а векторная - может сохранить результаты частотного анализа, сгенерить текстовое описание содержимого. И как следствие текст и картинка и звуковые записи приводятся в одно пространство и можно искать "похожие" разнородные данные.
Можно узнать чем этот подход отличается от использования n8n? развязывает руки программистам и дает понимание как это все работает? просто я как обычный юзер, могу ли я построить тоже самое в n8n? будет ли это также эффективно работать?
Приветствую. Лет 15 читаю habr (без регистрации), но эта статья мотивировала пройти регистрацию. В первую очередь хочу выразить благодарность автору, хороший слог, основные моменты вопроса изложены последовательно, понятным языком! Но тема векторных представлений данных в контексте системы RAG лишь на первый взгляд выглядит «чудным» , «экспертным» решением и в начале может показаться бюджетной альтернативой моделям обученным на конкретном домене данных. В статье также следовало сделать акцент на том, что очень важным моментом является правильный выбор имбеддинг модели, а также подчеркнуть, что в процессе работы поменять ее на другую не выйдет, прийдется выполнять векторизацию данных сначала. Но все это по сути «цветочки» , ягодки начинаются когда подходим к вопросу «чанкинга» и приходит осознание, что в кейсах использующих обьемные контекстно не зависимые массивы для узко специализированных доменов, данный подход не принесет желаемого результата. (В специфичных доменах (например, техническая документация СТО) слово «машина» может значить не только «автомобиль», но и, например, станок или агрегат. Если модель не обучена именно на таких данных, она может неправильно интерпретировать смысл. Поэтому в узких областях важно дообучать модель или использовать доменно-специфичные данные для векторизации.) Так же вы упомянули что в случае использования мощных (DeepSeek, ChatGPT) в качестве модели суммирования позволяет получить ответ на нужном языке пользователю. Это верно лишь отчасти, действительно крупная модель с легкостью вернет результат выполнив осмысленный перевод, НО важным моментом является то, что в случае если запрос пользователя выполняется на языке отличного от того в который использовался при создании векторов, ничего у нас не сработает, так как логично что векторное представление «машина» и «car» будут бесконечно далеки. Этот нюанс так же необходимо учитывать. Подводя итог, не все так гладко , прекрасно и легко на текущем уровне развития систем RAG, и пока использование их в сферах с высокими требованиями к достоверности данных вызывают больше вопросов чем ответов. Ведь сама суть таких систем - «модель суммирования» не должна фантазировать, и работать с нулевой температурой. Еще раз спасибо автору, статья действительно хорошая!
Спасибо за такую разверную обратную связь. Полностью согласен с вашими замечаниями.
Последнее время окунулся в изучение данного вопроса (как раз имеющего узкий специализированный домен) и все больше склоняюсь с мысли, что без объемного и развенутого( множеством примеров) файн тюнинга не родится аленький цветочек)) (причем это справедливо как для имбеддинг так и для модели суммирования). Ну а в случае систем выставляющих требования контекстной зависимости, можно улучшить результат добавив в цепочку компонент для работы с графовым представлением данных , что при правильно организованной логики пеплайна даст хороший результат. С уважением.
На мой взгляд RAG лучше всего подходит для динамических данных. Т.е. которые периодически меняются. И где не надо разбивать на чанки. Так сказать CRUD в векторной БД
Для чего нужна ```normalize_text()```?
Если делать эмбеддинг из markdown текста как есть, заметно пострадает качество поиска?
Удивило, что результат поиска вставляется в сообщение пользователя.
Это общепринятый, проверенный практикой подход из разряда best practice?
Не приведёт ли это к нежелательным эффектам, например:
а) LLM не выдаст пользователю нужную информацию так как будет думать что пользователь её уже знает, так как она поступила в сообщении от пользователя.
б) LLM будет упоминать эту информацию как нечто сказанное пользователем, что может вызвать недоумение у пользователя который ничего такого не говорил.
Из общих соображений кажется более логичным заворачивать результат поиска в отдельное сообщение от отдельной роли, например system.
Существует ли такой подход?
Личный ИИ-ассистент на ваших данных. Часть 1: Векторная база ChromaDB + DeepSeek | GPT