Нам нужен RAG, вам нужен RAG: как встроить LLM туда, где она не нужна

Когда хайп захватывает умы, кажется, что любое техническое решение должно строиться вокруг новой модной технологии и что теперь-то мы ух заживем! Сегодня у нас на хайпе RAG (Retrieval-Augmented Generation), вчера — NFT, позавчера — блокчейн везде и всюду. Давайте попробуем разобраться, нужен ли RAG на самом деле, или это просто «новый блокчейн» и через год все набьют шишки и забудут о нем.

Покажи свой RAG, чтобы сказать кто ты

В последнее время любая корпорация, стартап и даже бабушка в ЖЭКе мечтает «внедрить LLM с поддержкой RAG». Два слова про то, что вообще такое RAG:

• Retrieval: поиск информации из базы знаний или любых доступных данных

• Augmented Generation: найденная информация подается в заготовленный промпт LLM, которая уже учитывает это в ответе

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

Но на практике часто стоит задать себе вопрос: зачем RAG, если задача решается регуляркой, tf-idf или простым BERT-эмбедингом?

RAG/LLM как блокчейн

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

Ну че как?

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

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

Когда RAG оправдан?

Есть ситуации, где RAG действительно попадает в сердечко:

1. Масштабные базы знаний: у вас миллионы разных документов, и нужно быстро найти релевантные сложному запросу

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

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

4. Частые обновления данных: вам нужно совмещать старую и новую информацию в одном процессе

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

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

Когда RAG — это просто хайп?

Часто бизнес-задачи могут быть решены проще. А сейчас решение про RAG принимается вообще без опоры на какую-то метрику, просто потому что. Всегда стоит несколько раз задать себе вопрос о том, что именно мы улучшим и насколько. Сравниться не с «сейчас нет ничего, а будет RAG сразу +100», а с альтернативами этого RAG'а, попробовать классику, поэкспериментировать.

Нет явных метрик — нет оценки, нет оценки эффективности — не надо и начинать (если это не инженерный интерес потыкать как оно там).

Вот примеры, где RAG выглядит так же нелепо, как блокчейн для семейного бюджета:

1. Данные тривиальны
   У нас база из 500 строк с фиксированными полями. Простой запрос решит задачу быстрее и проще

2. Вопросы пользователя предсказуемы
   Если сервис отвечает на 10 фиксированных вопросов в одно предложение, зачем его усложнять? Статичный FAQ справится лучше

3. Ответы не требуют генерации текста
   Если пользователь спрашивает цену товара или какую-то его характеристику, простая расшифровка запроса и апишечка будет самое то

4. Ограничения бюджета или неявная выгода
   RAG и LLM требуют вычислительных мощностей, GPU и хорошей прод-инфраструктуры. Если ваш бюджет резиновый — ок, но чаше уместно использовать проверенные и хорошо себя зарекомендовавшие NLP-инструменты типа BM25 или классических классификаторов

Примеры совсем простые, но позволяют лучше понять частую абсурдность использования RAG'а.

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

Как понять, нужен ли вам RAG?

Стоит задать вот такие вопросы из простенького чеклиста:

1. У нас огромный объём нестандартных данных?

2. Пользователи действительно задают сложные вопросы, которые нельзя свести к стандартным?

3. Пользователи могут получать очень индивидуальные ответы в конкретно их ситуации?

4. Ваши данные постоянно обновляются, и доступ к ним требуется в реальном времени?

5. У вас есть бюджет на инфраструктуру LLM?

Если ответ «нет» хотя бы на один из вопросов, возможно, вам RAG не нужен и даже может оказаться вреден. Не всегда надо стрелять из RAG'а по воробьям.

Рецепт: как внедрить LLM и RAG туда, где оно не нужно?

Если вы всё-таки хотите внедрить RAG «ради галочки», то вот как это сделать:

1. Выберите абстрактную бизнес-задачу: придумайте что-то вроде «улучшения взаимодействия с клиентами»

2. Игнорируйте уже работающие инструменты: закройте глаза на регулярки, и весь nlp-хардкор

3. Настройте LLM так, чтобы она давала «почти правильные» ответы: ну ведь в целом-то почти правильно, а пользователь дальше сам разберется

4. Не вводите никаких метрик: метрики для скучного бизнеса, а здесь революция на наших глазах

5. Подайте это красиво: используйте слова «генеративный помощник» и «будущее за AI»

Заключение: хайп против пользы

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

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

И, как говорится, RAG вам в помощь.

Спасибо!

P.S.: Если вам понравилась статья, то приглашаю прочитать еще одну похожую по вайбу:

Уродливая математика в машинном обучении или чему нам стоит поучиться у деривативов?

и мои другие

Офис Apple в Москве: как я с нуля стал экспертом и попал на приватную вечеринку для разработчиков

Разбор SAM2 через колено в голову или революция в разметке видео