GenAI стремительно ворвался в нашу жизнь. Ещё вчера мы с опаской смотрели на него, а сегодня уже вовсю используем в работе. Многие эксперты пророчат GenAI большое будущее, считая его предвестником новой промышленной революции.

И ведь действительно, LLM и мультимодальные модели уже сейчас демонстрируют впечатляющие возможности и при этом относительно просты во внедрении. Создать простое приложение на их основе - дело нескольких строк кода. Однако переход от эксперимента к стабильному и надежному решению — задача посложнее.

Как метко подметил Мэтт Тёрк: если в 2023 году мы боялись, что GenAI нас погубит, то в 2024-м мечтаем хоть как-то приручить его и запустить в "мелкосерийное производство".

Если вы уже успели создать свои первые LLM-приложения и готовы вывести их на новый уровень, эта статья для вас. Мы рассмотрим 17 продвинутых RAG-техник, которые помогут избежать типичных ошибок и превратить ваш прототип в мощное и стабильное решение.

Пристегните ремни, мы отправляемся в увлекательное путешествие по миру AGI! Вместе мы:

• Поймем, как система отличает ценную информацию от информационного шума;

• Разберемся, как правильно подготовить данные для LLM;

• Выясним, можно ли строить цепочки из нескольких LLM;

• Поймем, как направлять запросы через разные компоненты системы.

Готовность к продакшену: не моделями едиными

Конечно, LLM становятся всё мощнее и умнее, но не стоит забывать о простых истинах. Эффективность RAG-системы часто зависит от куда более прозаичных вещей: качественных данных, их правильной обработки и подготовки.

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

Не стоит тешить себя иллюзиями, что с появлением супер-моделей все проблемы волшебным образом исчезнут. Работа с данными никуда не денется.

Возможно, когда-нибудь нам и удастся "скормить" необработанные данные одной модели, которая всё сама разложит по полочкам. Но даже в этом случае останутся вопросы стоимости и эффективности такого подхода.

Яркий пример — выступление Andrew Ng на конференции Sequoia Capital AI Ascent. Он показал, как GPT-3.5 с помощью агентного подхода обходит по точности более "навороченные" модели. На изображении ниже — наглядное сравнение точности GPT-4 (с нулевым количеством примеров) и GPT-3.5, использующей агентный рабочий процесс:

AGI — уже не фантастика, а научный прогноз. И хотя создать всезнающую модель вряд ли получится, мы можем построить нечто не менее интересное. Andrew Ng видит AGI как целостную систему, где LLM и мультимодальные модели работают в связке с другими инструментами.

Путь к AGI — это увлекательное путешествие. И каждый из нас может внести свой вклад, соединяя сложные модели с реальными задачами. Шаг за шагом, мы делаем эту систему умнее и способнее.

Naive RAG: краткий обзор

Принцип RAG основан на использовании и объединении существующих концепций и технологий. Многие из них пришли из области поисковых систем. Цель — построить процесс вокруг LLM, предоставляя модели правильные данные для принятия решений или обобщения информации.

На рисунке ниже показаны технологии, которые мы используем при построении такой системы:

Помимо Transformer-моделей, мы используем:

• Семантический поиск

• Технологии подготовки и обработки текстовых данных

• Графы знаний

• Небольшие модели классификации/регрессии/NLP и др.

RAG просто объединяет эти компоненты для решения конкретной задачи.

Представьте, что вы спрашиваете поисковик: "Сколько стоят акции Google сегодня?". Поисковик с RAG сначала найдет самую свежую информацию о стоимости акций, а затем сформулирует для вас ответ.

На рисунке ниже показан стандартный процесс RAG. Когда пользователь задаёт вопрос, наивный RAG сравнивает его напрямую с содержимым векторной базы данных.

Наша цель — найти похожий контент, то есть контент, расположенный близко к запросу в векторном пространстве. Расстояние измеряется, например, с помощью косинусного сходства.

Простой пример:

Вопрос: "На какой позиции играл Том Брэди?"

RAG анализирует базу данных и находит статью о Томе Брэди в Википедии и статьи из кулинарной книги. Очевидно, что первая статья намного релевантнее.

Невозможно установить порог сходства, который позволил бы нам чётко различать релевантный и нерелевантный контент. Можете попробовать сами, но, скорее всего, это окажется непрактичным.

Итак, мы нашли контент, похожий на запрос пользователя. Теперь нужно упаковать его в осмысленный промпт. Хороший промпт — как хороший вопрос: чёткий, понятный и полный. Он должен содержать инструкцию для LLM (как себя вести, что делать с информацией), сам вопрос пользователя и, конечно же, контекст — то есть релевантные документы, найденные в результате поиска по сходству

Вот как может выглядеть подходящий шаблон промпта:

Часть системного промпта "... используйте только предоставленную информацию" в инструкции для LLM превращает её в своего рода аналитика: она не пытается блеснуть собственными знаниями, а сосредотачивается на анализе конкретных данных.

Вроде бы всё просто: взяли базу данных, добавили модель для обработки текста, приправили LLM, написали пару строчек кода — и готово!

Однако при переходе от прототипа к реальному приложению возникают нюансы. Масштабирование системы — это как переезд из уютной квартирки в большой дом: появляется больше пространства, но и забот прибавляется.

Конечно, на этом пути нас ждёт ещё немало испытаний. Как отличить по-настоящему важный контент от информационного шума? Наш поиск ближайших соседей всегда будет выдавать релевантный контент, но насколько он релевантен? Данные, которые не имеют отношения к ответам на вопросы пользователей, называются дистракторами.

Какого размера должны быть отдельные фрагменты контента, чтобы они были достаточно конкретными, но при этом содержали достаточно контекста? Как отслеживать работу системы и вовремя вносить коррективы? И как быть с более сложными запросами, которые не решаются одним промптом?

Как улучшить RAG: 5 точек приложения усилий

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

Сфокусироваться стоит на следующих 5 этапах:

1. Предварительная выборка: эффективная загрузка эмбеддингов в векторное хранилище.

2. Выборка: точный и быстрый поиск релевантного контента.

3. Пост-обработка: грамотная предварительная обработка результатов перед тем, как отправить их в LLM.

4. Генерация: максимально эффективное использование контекста для решения задачи пользователя.

5. Маршрутизация: оптимизация маршрутизации запроса, например, использование агентного подхода — разбиения вопроса на части и организация их последовательной обработки моделью.

Более детальный взгляд на проблему представлен на следующем изображении:

Давайте разберём каждую из этих техник. Начнём с самого очевидного и простого —  качества данных. В большинстве RAG-систем используются текстовые данные, например, статьи из Википедии.

1. Создание и подготовка исходных данных

Мы привыкли считать исходные данные чем-то незыблемым. Но при работе с RAG у нас появляется уникальная возможность влиять на создание документов, и этим нельзя пренебрегать.

LLM и RAG-приложения любят чёткие и понятные базы знаний. Простой RAG видит документ не целиком, а как набор отдельных фрагментов, вырванных из контекста. Представьте, что вам нужно собрать пазл, но вместо целой картинки у вас есть только кучка разрозненных кусочков. Примерно так себя чувствует LLM, когда сталкивается с узкоспециализированными терминами, аббревиатурами или ссылками на другие части документа.

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

(1) Самодостаточные фрагменты текста

Взгляните на рисунок ниже. Вспомните, как часто в учебниках и инструкциях мы видим сухой текст, который сложно понять даже человеку. LLM без поддержки мультимодальных моделей будет крайне сложно разобраться в содержании первого варианта (слева). Второй вариант (справа) даёт ей гораздо больше шансов на успех.

Следующий важный этап — разбиение данных на осмысленные фрагменты, создание эмбеддингов и их индексирование.

2. Индексирование и фрагментирование

Важно помнить, что Transformer-модели работают с с ограниченным объемом информации, поэтому размер промпта также ограничен.

Но не стоит принимать это за фатальный недостаток. Гораздо важнее найти оптимальную длину — фрагмент, который будет достаточно информативным, но при этом не перегрузит систему. От этого зависит и скорость работы, и точность поиска, и многие другие параметры.

К счастью, существует множество инструментов, которые помогут вам разбить текст на фрагменты.

(2) Оптимизация фрагментирования

Размер фрагмента — это ключевой параметр. Стандартные Sentence Transformers на базе BERT работают с фрагментами не более 512 токенов. Существуют и более "прожорливые" модели, способные "переваривать" 8191 токен и больше.

Но не стоит злоупотреблять! Иногда лучше найти два точных предложения, несущие ключевую информацию, чем "скармливать" модели 5 страниц текста в надежде, что она сама найдёт нужный абзац.

Главное — найти золотую середину. Фрагмент должен быть достаточно объемным, чтобы LLM могла уловить контекст, но при этом достаточно конкретным, чтобы обеспечить эффективный поиск нужной информации.

Для подбора оптимального размера фрагмента существуют разные подходы. Например, в LlamaIndex за это отвечает класс NodeParser, который позволяет гибко настраивать параметры фрагментирования — от выбора разделителя до указания метаданных и связей между фрагментами.

Один из простейших и надёжных способов — скользящее окно.

Принцип прост: каждый следующий фрагмент частично перекрывает предыдущий.

Помимо "скользящего окна" можно использовать и другие методы: учитывать логическую структуру документа, разбивать текст на предложения и абзацы, ориентироваться на разметку или даже привлекать NLP для анализа содержания.

(3) Повышение качества данных

Очистка данных — важный этап, который помогает избавиться от информационного шума и сделать текст более понятным для LLM.

Часто смысл отдельного фрагмента становится ясен только в контексте всего документа. Вне контекста он может выглядеть как бессмысленный набор слов.

Особенно сложно LLM "переваривать" аббревиатуры, специфическую терминологию и внутренние термины компаний.

Взгляните на примеры на изображении ниже:

Без знания баскетбольной терминологии невозможно догадаться, что MJ — это "тот самый" Майкл Джордан. А аббревиатура PO, означающая "purchase order" ("заказ на покупку"), вне контекста логистики может быть истолкована совершенно неверно.

Чтобы помочь LLM разобраться в таких премудростях, необходимо добавить контекст в процессе обработки данных. Например, заменить аббревиатуры полными названиями с помощью специального словаря.

Это особенно важно при работе с SQL-запросами. Названия полей в базах данных часто бывают не слишком информативными. Иногда их смысл понятен только самим разработчикам базы.

Яркий пример — система SAP. Для названий полей здесь часто используются сокращения от немецких слов. Так, поле "WERKS" — это не что иное, как "Werkstoff", то есть "материал".

Понятно, что для разработчиков SAP это логично и удобно. Вот только LLM, как и всем остальным, придётся приложить немало усилий, чтобы понять этот код.

(4) Добавление метаданных

Одна из полезных возможностей векторных баз данных — это добавление метаданных к векторам. Метаданные служат дополнительными "ярлыками", которые позволяют нам отфильтровать нужные данные ещё до начала поиска по сходству.

Представьте, что половина информации в вашем векторном хранилище предназначена для пользователей из Европы, а вторая — для жителей США. Зная местоположение пользователя, вы можете существенно сузить круг поиска, ограничившись только релевантными данными. Для этого достаточно добавить информацию о регионе в качестве метаданных. Большинство векторных баз данных позволяют использовать метаданные для предварительной фильтрации.

(5) Оптимизация структуры индекса

Поиск по сходству — не самое узкое место в большинстве RAG-систем, особенно если говорить о времени ответа. Тем не менее, и его можно значительно ускорить.

Секрет высокой скорости векторных баз данных — в использовании алгоритмов приближенного поиска ближайших соседей (ANN), таких как FAISS, NMSLIB, ANNOY. Эти алгоритмы позволяют эффективно работать даже с миллионами записей.

Если ваша база данных относительно небольшая (несколько тысяч записей), то выбор между ANN и полным поиском не критичен. Однако при создании масштабируемой системы стоит уделить оптимизации индекса особое внимание. Правильный выбор алгоритма позволит вам добиться максимальной производительности.

(6) Выбор правильной модели эмбеддингов

Создание качественных эмбеддингов — основа успеха любой RAG-системы. К счастью, выбор инструментов сегодня очень широк.

Если вы не знаете, с чего начать, обратите внимание на бенчмарки, которые оценивают эффективность разных моделей текстовых эмбеддингов. Один из них —  MTEB (Massive Text Embedding Benchmark).

При выборе модели важно учитывать размерность эмбеддингов. Чем она выше, тем больше семантических нюансов текста она позволяет уловить и сохранить. Но за это придётся платить — возрастают требования к ресурсам для хранения и обработки данных.

Прежде чем попасть в векторную базу данных, текст необходимо преобразовать в эмбеддинги. Существует множество готовых моделей от разных разработчиков. Ознакомиться с моделями, поддерживаемыми модулем langchain.embeddings, можно в исходном коде модуля. Список впечатляет:

      __all__ = [
    "OpenAIEmbeddings",
    "AzureOpenAIEmbeddings",
    "CacheBackedEmbeddings",
    "ClarifaiEmbeddings",
    "CohereEmbeddings",
    ...
    "QianfanEmbeddingsEndpoint",
    "JohnSnowLabsEmbeddings",
    "VoyageEmbeddings",
    "BookendEmbeddings"
]
    

3. Оптимизация поиска

Чтобы получить от RAG-системы максимально точный результат, важно не только правильно подготовить данные, но и сформулировать запрос.

Расширение запроса, его перефразирование или преобразование — все эти техники служат одной цели: улучшить исходный запрос, прежде чем он попадёт в систему векторного поиска.

Вот два основных подхода:

• Расширение запроса: LLM генерирует дополнительные документы, которые уточняют исходный запрос и помогают найти более релевантные данные.

• Перефразирование запроса: LLM немного изменяет формулировку, создавая несколько вариаций запроса. Затем мы отправляем их в модель и анализируем полученные результаты, выбирая наиболее точный.

Давайте подробнее остановимся на первом способе.

(7) Расширение запроса с помощью сгенерированных ответов

Что делать, если ответ на запрос пользователя требует доступа к за закрытой базе знаний, не проиндексированной в RAG? В этом случае можно использовать генерацию ответа до выполнения поиска по сходству.

Идея в том, чтобы сначала попросить LLM "выдумать" ответ на запрос, основываясь на своих общих знаниях. Затем мы используем этот "выдуманный" ответ как ключ для поиска похожих фрагментов в нашей базе знаний.

Среди подобных методов можно выделить HyDE (Hypothetical Document Embeddings), Rewrite-Retrieve-Read, Step-Back Prompting, Query2Doc, ITER-RETGEN и др.

HyDE работает следующим образом: сначала LLM генерирует возможный ответ на запрос пользователя, не видя контекста. Затем этот гипотетический ответ используется для поиска релевантной информации в векторной базе данных.

В качестве альтернативы HyDE можно использовать расширение запроса с помощью нескольких системных промптов.

(8) Несколько системных промптов

Иногда, чтобы получить максимально точный и полный ответ от LLM, полезно задать не один, а несколько вопросов.

Например, если вам нужно создать краткое содержание большого текста, вы можете сгенерировать несколько промптов, каждый из которых будет сфокусирован на определённом аспекте текста. Затем вы сможете объединить полученные результаты в единый текст.

Другой вариант — создать несколько похожих промптов с одинаковым контекстом, но с небольшими вариациями в системной части. Таким образом, вы дадите LLM несколько разных указаний по интерпретации информации и формулировке ответа.

Подобные ансамблевые методы широко используются в машинном обучении. Например, в алгоритмах бустинга несколько "слабых" моделей совместно работают над решением задачи, и каждая вносит свой вклад в финальный, более точный, результат.

Аналогично, вы можете использовать несколько LLM или несколько промптов для одной LLM, чтобы получить более качественный ответ. Главный недостаток этого подхода — увеличение времени вычислений.

(9) Маршрутизация запросов: указываем LLM правильное направление

Представьте, что ваша векторная база данных — это огромная библиотека, где хранятся книги самых разных жанров. Чтобы найти нужную книгу, необходимо сначала определиться с жанром, иначе можно долго плутать по полкам, наполненным детективами, фантастикой и кулинарными рецептами.

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

В чём суть? Прежде чем отправлять запрос в поиск, мы просим LLM проанализировать его и определить, к какой тематической области он относится. LLM выступает в роли опытного библиотекаря, который направляет нас в нужный отдел.

Например, если наша база данных содержит новости о спорте, политике и кулинарии, то перед поиском ответа на вопрос о футбольном матче LLM должна "понять", что искать нужно в разделе спорта.

Маршрутизация запросов позволяет повысить скорость и точность поиска, исключив из него нерелевантные данные, а также предоставить пользователю дополнительные возможности для уточнения запроса — например, позволить ему самостоятельно выбрать интересующую его тему.

(10) Гибридный поиск: комбинируем сильные стороны разных подходов

Поиск релевантной информации — ключевой этап любой RAG-системы. Его эффективность во многом определяет успех всего приложения.

Один из способов улучшить поиск — это объединить достоинства векторного и лексического поиска. Такой подход называется гибридным поиском.

Как это работает? Мы параллельно запускаем два поисковых процесса:

• Векторный поиск анализирует смысл запроса и ищет похожие по смыслу фрагменты текста.

• Лексический (ключевой) поиск сосредоточен на отдельных словах и фразах в запросе.

Затем мы комбинируем результаты обоих подходов, получая более точные и полные данные.

Гибридный подход — не новинка в мире Data Science. Он основан на простом, но эффективном принципе: коллективный разум лучше, чем индивидуальный. Объединяя прогнозы нескольких моделей или методов, мы получаем более надёжный результат.

4. Пост-обработка: добавляем контекст

В погоне за точностью поиска мы стремимся разбивать текст на максимально короткие фрагменты. Однако иногда это играет с нами злую шутку. LLM становится сложно уловить смысл отдельного фрагмента без окружающего его контекста.

Давайте обратимся к примеру:

Представьте, что мы ищем информацию о немецком футбольном клубе "Бавария" (Мюнхен). Скорее всего, первый фрагмент текста на изображении покажет высокую степень сходства с запросом.

Однако более важная и интересная информация содержится во втором фрагменте. Именно поэтому так важен контекст.

Существует несколько эффективных методов обогащения контекста. Рассмотрим два из них:

• Поиск по окну предложений: вместо того, чтобы ограничиваться только самым релевантным предложением, мы берём также несколько окружающих его предложений.

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

(11) Поиск по окну предложений

Иногда для полного понимания смысла фрагмента текста необходимо видеть его в контексте окружающих предложений. Именно эту задачу решает поиск по окну предложений.

Вместо того чтобы ограничиваться только самым релевантным фрагментом, мы берём также несколько предложений до и после него. Это позволяет LLM лучше уловить смысл и связи между частями текста.

(12) Автоматическое объединение: собираем пазл из фрагментов

В сложных документах, таких как техническая документация или юридические договоры, важную роль играют перекрёстные ссылки. Чтобы LLM могла воспринимать такой документ целостно, необходимо восстановить эти связи.

Именно для этого используется автоматическое объединение. Мы выстраиваем иерархию фрагментов текста, связывая их друг с другом по смыслу.

Простой пример — иерархия из трёх уровней с разными размерами фрагментов (LlamaIndex):

• 1-й уровень: крупные фрагменты (2048 токенов).

• 2-й уровень: фрагменты среднего размера (512 токенов).

• 3-й уровень: короткие фрагменты (128 токенов).

При поиске мы сначала ищем релевантные короткие фрагменты, а затем "поднимаемся" по иерархии, добавляя к ним контекст из более крупных фрагментов.

Какой из этих подходов выбрать? Всё зависит от конкретной задачи и структуры ваших данных.

Но и после того, как мы нашли релевантную информацию, нам предстоит ещё одна важная задача — выбрать подходящую LLM для её обработки.

5. Генерация и агенты

(13) Выбор LLM: не всегда размер имеет значение

Какую LLM выбрать для RAG-системы? Ответ не так очевиден, как может показаться. Многое зависит от конкретной задачи и особенностей вашего приложения.

Конечно, первое, что приходит на ум, — взять самую мощную и продвинутую модель. Но не спешите!

У  небольших LLM есть ряд весомых преимуществ:

• Скорость работы. В некоторых случаях быстрота реакции важнее абсолютной точности. Например, в агентных системах, где LLM должна оперативно принимать множество промежуточных решений.

• Низкая стоимость. Использование менее ресурсоёмких моделей позволяет существенно снизить эксплуатационные расходы.

Прежде чем гоняться за "тяжёлыми" моделями, убедитесь, что их мощь действительно вам необходима. Вполне возможно, что более простая LLM справится с вашей задачей не хуже, а то и лучше — с учётом скорости и стоимости.

Как же выбрать оптимальный вариант?

Существуют специальные бенчмарки, которые сравнивают разные LLM по ряду параметров. Но лучший способ — это самостоятельно протестировать несколько кандидатов на ваших данных и задачах.

(14) Агенты

Иногда вопрос пользователя слишком сложен, чтобы LLM могла ответить на него сразу. В таких случаях на помощь приходят агенты — специальные программы, которые разбивают сложную задачу на несколько простых шагов.

Агент действует по аналогии с человеческим мышлением: вместо того, чтобы пытаться сразу охватить всю проблему, он последовательно анализирует её отдельные аспекты, постепенно приближаясь к решению.

Как работает агент?

Отправляет запрос в LLM, -> получает ответ и анализирует его, -> на основе анализа принимает решение о следующем шаге, -> выполняет действие (например, отправляет новый запрос).

У такого подхода есть как минимум два преимущества.

Во-первых, он повышает точность. Разбивая задачу на части, мы упрощаем работу LLM и помогаем ей сосредоточиться на главном.

Во-вторых, он позволяет использовать более простые LLM. Агент может эффективно работать даже с небольшими и быстрыми моделями, что снижает нагрузку на систему и экономит ресурсы.

Конечно, у агентного подхода есть и обратная сторона. Поскольку запрос обрабатывается поэтапно, на это требуется больше времени.

Когда использовать агентов?

• Когда задача слишком сложна для одноэтапного решения.

• Когда требуется максимальная точность ответа.

• Когда важно сократить затраты на вычисления.

Важно помнить, что время ответа — критически важный параметр для многих RAG-систем, особенно для тех, которые предназначены для информационного поиска.

6. Оценка: как понять, насколько хороша ваша RAG-система

Создать RAG-систему — это только полдела. Важно также уметь объективно оценить её эффективность.

Насколько хорошо она справляется с поиском релевантной информации? Насколько качественные и полезные ответы она генерирует?

Двухэтапная оценка

Чтобы получить полную картину, необходимо оценить работу каждого компонента RAG. Оценку можно разделить на два этапа:

1. Оценка компонентов поиска. Насколько хорошо система находит релевантную информацию в базе знаний? Для этого используются стандартные метрики поиска, такие как DCG и nDCG, которые оценивают качество ранжирования результатов.

   

   2. Оценка компонентов генерации. Насколько качественные и полезные ответы генерирует LLM? Эта задача сложнее, поскольку качество текста сложно оценить объективно.

Как оценить качество ответа LLM?

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

К тому же, каждый раз, когда вы вносите изменения в свою RAG-систему, вам придётся проводить оценку заново.

Автоматизация оценки

Более эффективный подход — использовать другую LLM в качестве "судьи". Эта LLM будет анализировать ответы вашей RAG-системы и выносить вердикт об их качестве. Такой подход позволяет автоматизировать оценку и сделать её более объективной.

(15) LLM в роли судьи: пусть ИИ оценит ИИ

Как мы уже знаем, оценить качество текста, сгенерированного LLM, — задача непростая. Человеческая оценка субъективна и трудоёмка. На помощь приходит подход "LLM в роли судьи".

Мы обучаем отдельную LLM анализировать ответы нашей RAG-системы и выставлять им оценки по заданным критериям.

Три шага к объективной оценке:

1. Подготовка данных. Создаём набор данных для обучения LLM-судьи, который должен включать контекст, вопрос и ответ.

   Данные могут быть как реальными, так и синтетическими. Во втором случае мы можем использовать LLM для генерации вопросов к заданному контексту.

2. Создание "агента-критика". Выбираем мощную LLM и "обучаем" её оценивать ответы по определённым критериям. Например:

   • Профессионализм: насколько формален и уважителен тон ответа.

   Для каждого критерия необходимо создать чёткое описание с разными уровнями оценки. Например:

         definition=(
       "Профессионализм  относится  к  использованию  формального,  уважительного  и  подходящего  стиля  общения,  который  "
       "адаптирован  к  контексту  и  аудитории.  Это  часто  подразумевает  избегание  чрезмерно  неформального  языка,  сленга  или  "
       "разговорных  выражений  и  вместо  этого  использование  четкого,  краткого  и  уважительного  языка."
   ),
   grading_prompt=(
       "Профессионализм:  Если  ответ  написан  в  профессиональном  тоне,  ниже  приведены  подробности  для  разных  баллов:  "
       "-  Балл  1:  Язык  чрезмерно  неформальный,  может  включать  сленг  или  разговорные  выражения.  Не  подходит  для  "
       "профессионального  контекста."
       "-  Балл  2:  Язык  неформальный,  но  в  целом  уважительный  и  избегает  резкой  неформальности  или  сленга.  Допустимо  в  "
       "некоторых  неформальных  профессиональных  условиях."
       "-  Балл  3:  Язык  в  целом  формальный,  но  всё  же  имеет  разговорные  слова/фразы.  На  грани  профессионального  контекста."
       "-  Балл  4:  Язык  сбалансированный  и  избегает  крайней  неформальности  или  формальности.  Подходит  для  большинства  профессиональных  контекстов.  "
       "-  Балл  5:  Язык  заметно  формальный,  уважительный  и  избегает  неформальных  элементов.  Подходит  для  формального  "
       "делового  или  академического  контекста.  "
   ),
       

3. Тестирование. "Скармливаем" LLM-судье ответы, сгенерированные нашей RAG-системой, и получаем оценки.

   Примеры промптов для оценки можно найти в шаблонах промптов Prometheus или в учебных материалах Databricks (MLFlow).

   Важно понимать, что оценка LLM — это не абсолютная истина. Результаты могут варьироваться в зависимости от выбранной модели и настроек. Тем не менее, этот метод позволяет получить более объективную оценку, чем при использовании человеческих ресурсов.

(16) RAGAs

RAGAs (Retrieval-Augmented Generation Assessment) — это фреймворк, который позволяет оценивать каждый компонент вашей RAG-системы.

В его основе лежит идея  "LLM в роли судьи", но Ragas предлагает гораздо больше: различные инструменты и техники для непрерывного обучения вашего RAG-приложения.

Ragas позволяет оценить качество работы каждого компонента RAG-системы в отдельности, используя предопределенные метрики.

Например для генерации важны достоверность и релевантность, а для поиска точность и полнота контекста.

Другие метрики ориентированы на оценку конвейера RAG в целом, например:

• Семантическое сходство ответа.

• Правильность ответа.

(17) Непрерывный сбор данных от приложения и пользователей

Сбор данных — ключ к выявлению и устранению пробелов в процессе. Часто проблема кроется в самих данных в базе знаний. Чтобы знать об этом, нам нужно внедрить механизмы, которые максимально упростят пользователям предоставление обратной связи.

Важные метрики для мониторинга:

• Время выполнения каждого шага RAG (векторизация, поиск, генерация).

• Использованные промпты.

• Найденные документы.

• Сгенерированные ответы.

RAG-система состоит из нескольких этапов. Чтобы оптимизировать её производительность и время ответа, нам нужно знать, где находится узкое место.

---

Не существует универсального рецепта успеха в разработке RAG-систем. Это процесс постоянных экспериментов и поиска оптимальных решений.

Именно это и делает работу с RAG такой увлекательной! Ведь было бы скучно, если бы существовал статичный сборник рецептов на все случаи жизни, не так ли?