Какво е RAG архитектура? Пълно определение с подробни практически примери

RAG (retrieval augmented generation – генериране, допълнено с извличане) е процес, при който LLM използват външна информация, за да разширят и подобрят своите отговори. Архитектурата на RAG е съвкупността от компоненти и връзки, които правят RAG възможен.

Съществуват няколко различни категории RAG и всяка от тях работи със собствена уникална архитектура. По същество архитектурата на една RAG система определя уникалния начин, по който информацията се съхранява, извлича и подава към LLM.

Какво е RAG архитектура?

RAG архитектурата е основната конфигурация от компоненти (и свързаните с тях възможности), която задвижва дадена RAG система. Всички тези архитектури надграждат базов шаблон, често наричан „прост“ или „наивен“ RAG.

Ето общ преглед на базовата RAG архитектура:

• Източник на информация: Тук се съхранява външната информация. Това може да бъде търсещ индекс, векторна база данни, представяща големи обеми информация, или хранилище с необработени документи.
• Компонент за извличане: Това е механизмът, чрез който се отправят заявки към източника на информация. RAG системата може например да използва просто търсене по ключови думи, за да открие релевантни фрагменти от текст, или по-сложни векторни заявки за търсене по сходство.
• Компонент за оркестрация: Този слой е частта от базираното на LLM приложение, която стартира RAG конвейера за даден потребителски промпт – съвместно с LLM или самостоятелно. Той също така обединява извлечената информация в разширен промпт.

Компонентите на RAG архитектурата обикновено са организирани в два пътя. Пътят за приемане на данни взема данните и ги организира в източник на информация, в който може да се търси. Векторните бази данни, в които големи обеми текст се преобразуват в хранилище от векторни представяния (embeddings) с възможност за търсене, са едно от най-широко използваните приложения.

Пътят за извличане взема промпта на потребителя и генерира заявка, с която да се търси в източника на информация. След това оркестраторът добавя извлечената информация към входния контекст на LLM. При агентните и хибридните RAG архитектури може да има няколко пътя за извличане.

Видове RAG архитектура

Подвеждащо е RAG да се възприема като набор от напълно отделни архитектури. Повечето инженери прилагат модулен подход, като внедряват отделни компоненти според конкретните случаи на употреба. Макар да е възможно да се очертаят условни граници, важно е да се отбележи, че между архитектурните модели има значително припокриване.

1. Базов RAG

Базовият RAG, наричан още „наивен“ или „прост“ RAG, е архитектурният шаблон за останалите видове RAG.

Основният процес е сравнително прост: потребителят въвежда промпт, оркестраторът определя дали е необходима външна информация (самостоятелно или съвместно с LLM) и съответно формулира и изпраща заявка за извличане.

Външният източник на информация обикновено е векторна база данни, но може да бъде и SQL база данни, уеб API, граф на знанията или дори хранилище с „необработени“ документи. След това тази допълнителна информация се добавя към входния контекст на LLM.

Освен SQL заявките и API интерфейсите съществуват два основни вида методи за извличане:

• Лексикално търсене (търсене по ключови думи): Това е проста форма на RAG, при която от потребителската заявка се извличат ключови думи и се съпоставят с текстови пасажи, които ги съдържат. В съвременните конвейери оркестраторът може да използва за целта т.нар. заявка с разреден вектор (sparse vector query), която не улавя значението.
• Търсене с плътни вектори (семантично търсене): Плътните векторни представяния улавят значението. Оркестраторът може да отправя заявки към база данни с плътни вектори по начин, който позволява да се улови значението както на потребителския промпт, така и на изходната информация.

Използването на памет също е важна част от RAG архитектурата. То се отнася до начина, по който LLM използва контекст от предишни чатове, за да изгради заявка за извличане, като по този начин я вписва в по-широкия контекст на дадена дискусия (или на няколко дискусии). Разговорният RAG е стандарт за повечето чатботове, въпреки че при някои случаи на употреба, като отговорите на тикети за поддръжка, може да се използва RAG с единичен въпрос.

2. Хибриден

Хибридният RAG съчетава два различни вида извличане – обикновено по ключови думи и семантично. Търсенето по ключови думи открива съвпадащи термини, а векторното търсене открива пасажи със сходно значение.

Може да се използват и други форми на извличане, като обхождане на граф на знанията или заявки към SQL бази данни. Процесът често се направлява от логика за маршрутизиране – под формата на програмирани правила или на класификация на въпроса от модел (макар че няколко конвейера могат да работят и едновременно).

Оркестраторът обединява резултатите и може да ги класира повторно, преди да ги предаде на LLM. Повторното класиране е процесът на присвояване на оценки за релевантност на извлечените фрагменти, така че LLM да дава приоритет на най-приложимата информация.

3. Адаптивен RAG

При адаптивния RAG компонент за маршрутизиране избира стратегия за извличане въз основа на изискванията на потребителския промпт, след което оркестраторът изпълнява избрания работен процес.

В оригиналната рамка (Adaptive-RAG) по-малък модел действа като класификатор и избира между липса на извличане, извличане в една стъпка или извличане в няколко стъпки. Някои архитектури вече използват вместо това генеративни модели или евристики, базирани на правила.

Тази архитектура е популярна, защото разпределя изчислителната мощ според сложността и изискванията на промпта, като намалява ненужните стъпки на извличане при по-простите промптове. Тя е често срещана при асистентите, които работят с различни видове въпроси.

4. Коригиращ RAG (CRAG)

Коригиращият RAG оценява извлечената информация, преди да я добави към входния контекст на LLM. Оценител на извличането преценява дали извлечената информация е релевантна и полезна. Отличителната архитектурна характеристика е изричният етап на оценка и корекция преди генерирането на отговора.

Ако се установи, че информацията е непълна или неприложима към промпта, се задействат допълнителни заявки. При тях може да се използват различни методи за извличане от тези при първоначалната заявка, като уеб търсене или обхождане на граф на знанията.

Коригиращият RAG е често срещан в области, в които точността е важна, като медицината и правото. Той обаче изисква допълнителен източник на информация, който да допълва първоначално извлечените пасажи.

5. Self-RAG

При Self-RAG моделът може да инициира заявки, след като получи първоначалния входен контекст. Генерираните отговори се оценяват спрямо извлечените доказателства с помощта на токени за рефлексия, а при нужда през оркестратора се изпращат допълнителни заявки. Обратно, LLM може да реши, че изобщо не е необходимо извличане.

Той се различава от коригиращия RAG по това, че LLM преценява собствените си резултати, определя дали е нужно извличане и дали извлеченият текст е полезен, и следи собствените си отговори, като ги променя при необходимост. Коригиращият RAG, от друга страна, оценява качеството на извлечената информация преди генерирането.

Тази архитектура е особено полезна за сложни промптове в стила на задълбочено проучване. Тъй като интегрира оценки на релевантността (на извлечената информация) в генерирането на отговора, тя е добър избор за промптове, които изискват отговори, основани на доказателства.

6. Агентен RAG

Агентният RAG обозначава всяка форма на RAG, която се изпълнява в контекста на агентна платформа. Моделът използва способностите си за разсъждение, за да определи какъв вид информация е необходим, и избира измежду наличните възможности за извличане.

Извличането може да се задейства многократно според нуждите, а моделът има възможност да възлага по-сложните заявки на агенти. Например LLM може да поиска справка в база данни, за да идентифицира доставчик, да задейства търсене в документи, за да открие съответните договори, и накрая да извърши уеб търсене, за да провери данните за контакт чрез публични източници.

Агентният RAG е основната архитектурна реализация в масовите чатботове като Perplexity, ChatGPT, Claude и други. Тъй като тези платформи осигуряват на основния модел достъп до множество инструменти и RAG конвейери, той може да избере коя форма на извличане е най-подходяща за даден промпт.

7. Мултимодален RAG

Мултимодалният RAG извлича контекст от различни видове медии. Той е важна форма на RAG, защото прави достъпна за LLM информация, като диаграми и аудиозаписи, която иначе би била недостъпна.

Основната архитектура е същата като при всяка друга система. Например конвейер за индексиране може да подготви изображения за търсене, като ги преобразува в директни векторни представяния. След това агентна RAG система може да извлече тези изображения заедно със семантично релевантен текст и да ги подаде на визуално-езиков модел за комбинирана обработка.

8. GraphRAG

GraphRAG използва графи на знанията наред с векторното търсене, за да извлича информация за същности. Обикновено оркестраторът открива релевантни начални същности, наричани още възли, чрез извличане на ключови думи или понякога чрез предварително векторно търсене. Компонент за извличане от граф обхожда графа на знанията, за да изгради по-широк контекст.

Например в отговор на заявка за подробна разбивка на дадена продуктова категория LLM може да задейства векторно търсене, за да идентифицира конкретни същности (продукти). След това оркестраторът ще задейства търсене в графа на знанията, за да открие свързани същности, като доставчици, търговски обекти, отзиви и други.

9. Разклонен RAG

Докато хибридната RAG архитектура може да използва различни методи за извличане, разклоненият RAG обозначава процеса на едновременно изпълнение на множество заявки, наречени разклонения. Всяко разклонение може да търси в отделен източник на информация, или разклоненията могат да търсят паралелно в един и същ източник с различни заявки или филтри. Агентната RAG архитектура често използва разклонен RAG.

10. HyDE (Hypothetical Document Embeddings – векторни представяния на хипотетични документи)

HyDE е иновативна форма на RAG, при която LLM създава хипотетичен текстов документ, показващ как би могъл да изглежда един оптимален отговор. След това този „хипотетичен документ“ се използва за създаване на заявка за по-точно извличане. Макар релевантното знание да не е представено в параметрите на LLM, логиката е, че пасаж, наподобяващ отговор, може да съответства по-добре на релевантните документи, отколкото кратък въпрос или двусмислен промпт.

Пример за проста RAG архитектура: векторна база данни

Базовият RAG служи като основа за по-сложните видове архитектура. При проста RAG система, която използва векторна база данни, изходната документация се разделя на по-малки части (фрагменти) и се преобразува в плътни векторни представяния. Когато потребителят въведе промпт, оркестраторът генерира заявка, кодира я и търси в базата данни, за да открие релевантни пасажи.

Ето разбивка на процеса стъпка по стъпка:

1. Големи обеми текст се преобразуват във вектори с помощта на автоматизиран конвейер за приемане на данни и модел за векторни представяния като BERT.
2. Приложението за база данни организира, индексира и съхранява векторите за бързо търсене.
3. Потребителят въвежда промпт в чатбот (например Perplexity).
4. Оркестраторът на приложението кодира промпта (с помощта на модел за векторни представяния), за да извлече релевантна информация от векторната база данни.
5. Векторната база данни връща релевантни фрагменти, а оркестраторът ги добавя към входния контекст („големия промпт“) и го подава на LLM.
6. LLM използва допълнителния контекст, за да генерира отговор с помощта на вътрешните си знания (съхранени в параметричните му тегла).

Уголеми

Пример за усъвършенствана RAG архитектура: агентен RAG

Агентният RAG обозначава основната архитектура на RAG системите в рамките на агентна платформа. Агентните RAG потоци обикновено са сложни, защото AI агентите могат да извикват различни инструменти и конвейери в зависимост от естеството на промпта, като при необходимост задействат множество агенти.

Ето практически пример за процеса:

1. Потребителят въвежда сложен въпрос, който изисква задълбочено проучване на дадена тема. За този пример да приемем, че промптът е: „Направи прогноза за печалбата на компанията през следващите шест месеца с оглед на важните геополитически събития.“
2. LLM преценява, че ще е необходима комбинация от RAG заявки към различни видове съдържание.
3. Задействат се три различни агента за (а) векторно търсене, (б) обосноваване с уеб източници и (в) търсене на изображения (мултимодално).
4. Агентите търсят релевантна информация, като новинарски материали и вътрешни финансови данни, чрез оркестратора, като използват наличните инструменти за извличане.
5. LLM сравнява извлечените резултати с изследователския въпрос на всеки агент и ги подрежда по релевантност.
6. LLM оценява информацията и задейства допълнителни търсения чрез отделни агенти там, където липсва информация.
7. След като бъде извлечена достатъчно информация, LLM генерира прогнози по сценарии въз основа на наличните финансови показатели (извлечени от вътрешната документация) и извиква инструмент за изчисления, за да прогнозира печалбата за всеки от тях.
8. LLM генерира окончателен отговор, като използва извлечената информация и изчисленията и цитира източници при необходимост.

Уголеми

Какво следва за RAG?

Настоящите иновации са насочени към това да придадат дълбочина и скорост на съвременните RAG архитектури, да подобрят точността на мултимедийното извличане и да изградят системи, предназначени да работят с информация в реално време.

Ето три тенденции, които в момента определят посоката на изследванията:

• Задълбочено проучване в множество източници: Това е RAG архитектура, която може да планира търсения, да изпълнява множество разклонения в разнородни източници, да оценява извлечените доказателства и самостоятелно да оптимизира генерираните отговори. Агентният RAG, способен да изпълнява всички тези задачи, продължава да става все по-бърз и по-икономичен.
• Мултимодални приложения: Конвейерите за извличане работят все по-добре с изображения и видео. Те все по-често могат да откриват точно определени видове информация в сложни мултимодални данни, като дълги видеоклипове и усъвършенствани диаграми.
• Обосноваване на отговорите с постоянно променяща се информация: Базираните на LLM приложения могат да черпят от източници на информация в реално време (като видеопотоци и сензори), за да осигурят входен контекст. Системите могат също да генерират многоизмерни мрежи от информация, например с GraphRAG, за да интерпретират тези данни.

RAG е в основата на начина, по който работят базираните на LLM приложения. Той позволява на широк кръг потребители – от обикновените хора до предприятия, работещи в специализирани области – да преодолеят проблеми, свързани с халюцинации, непълни данни за обучение и липса на достъп до специализирани вътрешни знания.

Ето защо RAG системите и тяхната основна архитектура са сред най-бързо развиващите се и най-вълнуващи области на изследванията в сферата на AI.