Спасибо! Да, это все можно настроить в ноутбуке на Google Colab. Если мы говорим об использовании моделей по API (как это сделано в статье), то мы не храним модели, только изначальные текстовые последовательности и вектора (chroma, faiss хранят вектора в RAM) Можно аналогично сделать полностью закрытое решение на локальной инфраструктуре, например, E5 + Mistral-7b. Оно будет полностью автономно и не связано с chatGPT, но результаты будут похуже (в статье есть ссылка на сравнение моделей в RAG задаче)
Если имеется ввиду разница в скорости работы LLM по API и open-source на своем железе, то зависит от мощности железа. Так что, если есть свой кластер, то, наверное, можно поравняться по скорости с API решениями
В эмбеддерах используются subword токенизаторы, что решает проблему out-of-vocabulary, поэтому эмбеддинг мы все равно получим и он будет отражать название в векторном пространстве. Также, если в вопросе юзера будет не только название прибора, а еще какой-то вопрос, например, "Как настроить уровень <setting> в приборе крутойприбор1159па71?", то это тоже поможет найти нужный документ, если он существует. При добавлении новых документов они аналогично старым делятся на chunk'и, эмбедятся и добавляются в базу, после этого они будут доступны для поиска. Вопросы юзера не делятся на chunk'и, с них берется единый эмбеддинг (sentence embedding) и по этому эмбеддингу производится поиск. По поводу пустых полей и их заполнения не очень понял
Документ сначала разбивается на кусочки (есть множество стратегий, советую видео: 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)
Спасибо! Да, это все можно настроить в ноутбуке на Google Colab.
Если мы говорим об использовании моделей по API (как это сделано в статье), то мы не храним модели, только изначальные текстовые последовательности и вектора (chroma, faiss хранят вектора в RAM)
Можно аналогично сделать полностью закрытое решение на локальной инфраструктуре, например, E5 + Mistral-7b. Оно будет полностью автономно и не связано с chatGPT, но результаты будут похуже (в статье есть ссылка на сравнение моделей в RAG задаче)
Если имеется ввиду разница в скорости работы LLM по API и open-source на своем железе, то зависит от мощности железа. Так что, если есть свой кластер, то, наверное, можно поравняться по скорости с API решениями
В эмбеддерах используются subword токенизаторы, что решает проблему out-of-vocabulary, поэтому эмбеддинг мы все равно получим и он будет отражать название в векторном пространстве. Также, если в вопросе юзера будет не только название прибора, а еще какой-то вопрос, например, "Как настроить уровень <setting> в приборе крутойприбор1159па71?", то это тоже поможет найти нужный документ, если он существует.
При добавлении новых документов они аналогично старым делятся на chunk'и, эмбедятся и добавляются в базу, после этого они будут доступны для поиска.
Вопросы юзера не делятся на chunk'и, с них берется единый эмбеддинг (sentence embedding) и по этому эмбеддингу производится поиск.
По поводу пустых полей и их заполнения не очень понял
Документ сначала разбивается на кусочки (есть множество стратегий, советую видео: 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)