Ассистент это упрощенный способ использования RAG, сама методология RAG появилась раньше чем этот инструмент.
По поводу разделения по блокам - вариант рабочий, но не всегда удобный. Плюс есть и другие ограничения на использование ассистентов.
По целесообразность таких статей могу сказать следующее: Это не научная статья об открытии, а базовые знания по методологии. Да, сейчас появились инструменты которые позволяют все сделать проще(Убирая тонкости реализации RAG под капот), но это все равно знания которые лежат в основе понимания применения LLM. Мы же не убираем учебники по базовой математике из-за того что появились калькуляторы.
В целом RAG это методология которая не связана с продуктами OpenAI, она дает подход, который позволяет LLM отвечать на вопросы, информацию по которым отсутствует в обучающей выборке. Это работает для любой LLM, включая OnPremise решения.
Ответ на оба вопроса: Граница на данный момент в объеме данных которые можно предоставить по теме в которой работает LLM. В большой компании объем прикладных данных (документация, FAQ, записи по собраниям, общение с подрядчиками и т.п.) сильно превышает 2кк токенов, к тому же все время обновляется, да и не всегда понятно в каком документе ответ на вопрос содержится, тогда собирают целые пайплайны выгрузки, обработки, обогащения метаданными (Например откуда взята информация, кто автор, документ в процессе написания или уже завершен) и загрузки их в векторное хранилище, чтобы потом любая LLM могла их использовать в процессе генерации ответа.
В целом разница между "простым ассистентом" и "сложным RAG" и тут только в автоматизации и объеме: - для личного пользования подойдет и ассистент, просто грузим пачку доков и задаем вопросы - для корпоративного - уже более сложный подход с пайплайнами подготовки данных
В целом методология RAG работает через передачу данных в модель через контекст. Модели OpenAI на данный момент имеют максимальную длину контекста 128к токенов. Для того чтобы бороться с проблемой использую разбиение всей базы знаний (в контексте вашего вопроса - файлов) на части ограниченной длины, помещаются в векторную БД. Для ответа на вопрос - подбираются куски файлов с наиболее подходящим содержимым, их и помещают в контекст.
Поиск происходит с помощью сравнение embiding'ов части документа и запроса пользователя в семантическом векторном пространстве ( https://habr.com/ru/companies/ods/articles/329410/ ). Выбираются N самых похожих на запрос пользователя.
При слишком большом суммарном размере всех частей - они могут быть суммаризированны, но это может привести к некоторой потере деталей.
Отвечая конкретно по вопросам: 1. Проблемы некуда не ушли, просто OpenAI ассистенты сильно упростили создание простых RAG ботов, но это не подходит для больших баз знаний. 2. Контекста ассистента все так же дробится на N частей и загружается в векторную базу, по которой, в момент вопроса, ассистент попробует найти самые актуальные части и с их помощью ответить.
Надеюсь я не запутал вас еще больше.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
@AlexanderAnisimov
Ассистент это упрощенный способ использования RAG, сама методология RAG появилась раньше чем этот инструмент.
По поводу разделения по блокам - вариант рабочий, но не всегда удобный. Плюс есть и другие ограничения на использование ассистентов.
По целесообразность таких статей могу сказать следующее:
Это не научная статья об открытии, а базовые знания по методологии. Да, сейчас появились инструменты которые позволяют все сделать проще(Убирая тонкости реализации RAG под капот), но это все равно знания которые лежат в основе понимания применения LLM. Мы же не убираем учебники по базовой математике из-за того что появились калькуляторы.
@AlexanderAnisimov
В целом RAG это методология которая не связана с продуктами OpenAI, она дает подход, который позволяет LLM отвечать на вопросы, информацию по которым отсутствует в обучающей выборке. Это работает для любой LLM, включая OnPremise решения.
Ответ на оба вопроса:
Граница на данный момент в объеме данных которые можно предоставить по теме в которой работает LLM. В большой компании объем прикладных данных (документация, FAQ, записи по собраниям, общение с подрядчиками и т.п.) сильно превышает 2кк токенов, к тому же все время обновляется, да и не всегда понятно в каком документе ответ на вопрос содержится, тогда собирают целые пайплайны выгрузки, обработки, обогащения метаданными (Например откуда взята информация, кто автор, документ в процессе написания или уже завершен) и загрузки их в векторное хранилище, чтобы потом любая LLM могла их использовать в процессе генерации ответа.
В целом разница между "простым ассистентом" и "сложным RAG" и тут только в автоматизации и объеме:
- для личного пользования подойдет и ассистент, просто грузим пачку доков и задаем вопросы
- для корпоративного - уже более сложный подход с пайплайнами подготовки данных
@AlexanderAnisimov, добрый вечер.
В целом методология RAG работает через передачу данных в модель через контекст. Модели OpenAI на данный момент имеют максимальную длину контекста 128к токенов. Для того чтобы бороться с проблемой использую разбиение всей базы знаний (в контексте вашего вопроса - файлов) на части ограниченной длины, помещаются в векторную БД. Для ответа на вопрос - подбираются куски файлов с наиболее подходящим содержимым, их и помещают в контекст.
Поиск происходит с помощью сравнение embiding'ов части документа и запроса пользователя в семантическом векторном пространстве ( https://habr.com/ru/companies/ods/articles/329410/ ). Выбираются N самых похожих на запрос пользователя.
При слишком большом суммарном размере всех частей - они могут быть суммаризированны, но это может привести к некоторой потере деталей.
Отвечая конкретно по вопросам:
1. Проблемы некуда не ушли, просто OpenAI ассистенты сильно упростили создание простых RAG ботов, но это не подходит для больших баз знаний.
2. Контекста ассистента все так же дробится на N частей и загружается в векторную базу, по которой, в момент вопроса, ассистент попробует найти самые актуальные части и с их помощью ответить.
Надеюсь я не запутал вас еще больше.