Введение в RAG

1. Используемые данные

1.1. Какие данные

Система использует 2 корпуса данных: рецепты и советы

1. Рецепты структурированы в виде JSON-документов с названием, описанием, перечнем ингредиентов, кухонной утвари, шагов приготовления и дополнительными советами.
2. Советы также будут структурированны в виде JSON-документов с данными о категории совета и содержанием.

1.2. Объем данных

Объем данных в данной системе может быть потенциально крупным, поскольку:

• Число рецептов на различных кулинарных порталах варьируется от 1 000 до 100 000 штук

1.3. Динамика изменения

Сами рецепты и советы вряд ли будут подвергаться изменению. Основные изменения будут связаны с добавлением новых и удалением старых документов. Однако и эти добавления/удаления будут происходить не очень часто.

2. Стратегия доступа к знаниям

2.1. Доступ к рецептам

Для работы с рецептами предусмотрим следующую стратегрию:

1. Выберем характеристики, которые наиболее полно отражают тот или иной рецепт:

• Название
• Описание
• Ингредиенты
• Кухонная утварь

2. Агрегацию этих характеристик представим в виде эмбеддинга. Шаги и советы включать в эмбеддинг не будем, поскольку они составляют основную часть описания рецепта, но при этом несут меньше полезной информации, что может создавать лишний шум и снизить качество
3. Для каждого рецепта выполним такое представление и сохраним результаты в базу знаний в виде пар соответствия вектор <=> рецепт
4. При поступлении запроса пользователя, создаем его векторное представление
5. Осуществляем поиск наиболее схожих векторов по нашему хранилищу
6. Возвращаем исходные тексты рецептов, исходя из заданных соотвествий вектор <=> рецепт
7. Отдаем эти тексты дальше по цепочке

2.2. Доступ к советам

Работа с советами имеет аналогичную стуктуру:

1. Представить совет с дополнительными характеристиками (например, категория) и представить вектором
2. Задать соответствия вектор <=> совет
3. Осуществалять сравнение вектора представления запроса пользователя и векторов из базы знаний
4. Вернуть оригиналы наиболее релевантных советов через соотвествение вектор <=> совет

3. Архитектурные решения

3.1. Необходимость изменений

Элементы RAG-системы уже были предусмотрены на первом этапе построение системы, однако требуется внести уточнения связанные c названиями, а также с компонентами, взаимодейтсвующими с поисковой составляющией. Компоненты извлечения метаданных и сущностей были удалены как отдельные этапы, поскольку их функциональность может быть реализована внутри Retriever через методы улучшения поиска.

Теперь схема работы системы примет следующий вид:

3.2. Расчет эффективности RAG по сравнению с полным контекстом

1. Примем размер базы рецептов за 1000. Размер одного рецепта ~ 600 токенов. В таком случае размер контекста составит 600 000 токенов, что уже не поместится в контекстное окно используемой gpt-oss-120b.
2. Примем размер базы рецептоа за 200. Размер одного рецепта ~ 600 токенов. В таком случае размер контекста составит более 120 000 токенов, что еще поместится в контекстное окно. Если взять стоимость 1000 входных токенов за 0,3 руб. (по данным Yandex AI Studio), то цена только входной части запроса составит: 120 000 / 1 000 * 0,3 = 36 (руб), что достаточно дорого.
3. Примем, что используется RAG, в рамках которой возвращается 5 документов. Размер одного рецепта ~ 600 токенов. Размер шаблона промпта ~ 250 токенов. В этом случае размер входного контекста: 5 * 600 + 250 = 3250. Стоимость входной части запроса: 3250 / 1000 * 0,3 = 0.975 (руб), что 37 раз выгоднее. Размер обрабатываемого контекста также меньше в 37 раз

3.3. Последствия изменений

1. +Упрощение архитектуры без изменения внешнего контура системы, как следствие, меньше действий, меньше временных и ресурных затрат.
2. +Меньше стоимость по сравнению с полным контектом.
3. -Введение RAG ставит новые задачи по корректному ранжированию и применению техник улушения работы ретривера.
4. -Качество работы ретривера имеет существенное влияние на результат работы по двум ветвям намерения (рецепты, советы).