Комментарии 10
Разъясните плиз, каждый локалбный документ представили векторами (с помощью чего?) и сохранили в векторной базе. А что вы делаете с вопросом юзера? Правильно ли я понял что вопрос юзера пусть даже из одного слова надо также преобразовать в вектор строго того же типа и спомощью тех же средств, что использовались для векторизации локальных документов? Но ведь документы могут большими, но тем не менее не содержать ни одного слова из запроса, который может состоять просто из одного слова?
Документ сначала разбивается на кусочки (есть множество стратегий, советую видео: https://www.youtube.com/watch?v=8OJC21T2SL4&ab_channel=GregKamradt(DataIndy))
Затем уже эти кусочки превращаются в вектора, для этого можно использовать любой embedder, в данном случае использовались text-embedding-ada-002 от OpenAI.
Вопрос юзера превращается в вектор с помощью этой же модели и потом мы ищем наиболее близкие к нему вектора в нашей БД с документами. Из БД мы получим именно фрагменты документов, которые затем подадим в LLM вместе с вопросом пользователя.(Если использовать open-source embedder'ы, то для русского языка стоит посмотреть в сторону E5)
В случае использования key-word поиска вопрос человека, состоящий из одного слова, которого нет в наших документах - проблема. Но в векторе отражается именно семантика, соответственно мы сможем найти похожие слова.
Проблему того, что юзер задает слишком короткие вопросы можно частично решить с помощью перефразирования вопроса, например, Multi Query, где мы просим LLM сгенерировать для нас k вопросов из оригинального и затем ищем их по отдельности, объединяя результаты. (Подробнее про механику: https://www.youtube.com/watch?v=JChPi0CRnDY&list=PLfaIDFEXuae2LXbO1_PKyVJiQ23ZztA0x&index=5&ab_channel=LangChain)
Спасибо! А вот еще вопрос, если речь идет о специализированной документации, и там например прибор с название "крутойприбор1159па71", и вопрос будет о нем, то,кажется, стандартный эмбедер ничего в себе с таким буквосочетанием не найдет? и не сможет его векторизовать? А поиск в точности по слову может не дать результатов т.к. прибор может быть устаревших и уже отсутствовать в доках или наоборот - совсем новый и его не будет в документации т.к. еще не успели внести и обновить базу документов?
Я помотрел как Gpt4 - иногда он довольно удачно что-то похожее, но не совпадающее по названию находит... ?
По поводу запроса из одного слова - его надо форматировать как один чанк которые делаются на стадии загрузки документов? Будет много пустых полей? Чем их заполнить - рандомными строками из документации или просто рандомными или пустыми?
В эмбеддерах используются subword токенизаторы, что решает проблему out-of-vocabulary, поэтому эмбеддинг мы все равно получим и он будет отражать название в векторном пространстве. Также, если в вопросе юзера будет не только название прибора, а еще какой-то вопрос, например, "Как настроить уровень <setting> в приборе крутойприбор1159па71?", то это тоже поможет найти нужный документ, если он существует.
При добавлении новых документов они аналогично старым делятся на chunk'и, эмбедятся и добавляются в базу, после этого они будут доступны для поиска.
Вопросы юзера не делятся на chunk'и, с них берется единый эмбеддинг (sentence embedding) и по этому эмбеддингу производится поиск.
По поводу пустых полей и их заполнения не очень понял
интересно, насколько разнится скорость работы какой-то виртуальной llm при работе с RaG по сравнению с предобученным контентом? есть ли разница?
Если имеется ввиду разница в скорости работы LLM по API и open-source на своем железе, то зависит от мощности железа. Так что, если есть свой кластер, то, наверное, можно поравняться по скорости с API решениями
Ну если в кратце - скорость разнится. Но этим можно пожертвовать.
Прелесть RAG в том что одна модель отвечающая за ответ может обслуживать множество источников данных, в том числе и более актуальных. Использование векторной бд это лишь один из способов предоставлять модели актуальные знания по %SUBJECT%.
Можно использовать поисковые движки (хотя, они в целом используют индексаторы, которые делают +- тоже самое)
Можно использовать поиск по файловой системе, заставить llm брутфорсить википедию, искать по ключевым словам, заставить использовать wolfram, calc.exe и прочие вещи для поиска ответов. Тем более инструментов, помимо langchain на рынке хватает. Huggingface, например, год назад выпустили agents, который позволяет делать много всяких вещей.
Если вам нужен исключительно rag + vector db можно пощупать и haystack, api которого +- стабилен и многое работает без принудительного использования openai.
Работа отличная, весьма и весьма перспективная! Даниил, а можно ли через Google Colab все это настроить? И, если да, где в таком случае будут храниться все данные по модели? сколько в итоге весит эта модель? Можно ли это развернуть на отдельном компьютере?
Правильно ли я понял, что система применения LLM в бизнесе, которую Вы разработали, полностью автономна и, в конечном счете, не будет никак связана с API самого ChatGPT?
Спасибо! Да, это все можно настроить в ноутбуке на Google Colab.
Если мы говорим об использовании моделей по API (как это сделано в статье), то мы не храним модели, только изначальные текстовые последовательности и вектора (chroma, faiss хранят вектора в RAM)
Можно аналогично сделать полностью закрытое решение на локальной инфраструктуре, например, E5 + Mistral-7b. Оно будет полностью автономно и не связано с chatGPT, но результаты будут похуже (в статье есть ссылка на сравнение моделей в RAG задаче)
Как общаться с базой знаний на естественном языке с помощью LLM и объективно оценить работу полученной системы