RAG vs Fine-tuning: Практическое пособие чтобы сделать работу с AI полезной

Канал автора The AI Architect Blog — подписывайтесь 😎

“Как научить ChatGPT работать с данными нашей компании?" Этот вопрос возникает у каждой команды, внедряющей AI, и обычно влечет за собой долгие часы исследований подходов RAG и fine-tuning. Учитывая, что компании тратят от $100 000 до $1 000 000 ежемесячно на API-вызовы языковых моделей, выбор неправильного подхода – это не просто техническая ошибка, а дорогостоящий стратегический просчет.

В этом руководстве мы разберемся в сложностях и предоставим четкую схему принятия решений для выбора между RAG (Retrieval Augmented Generation) и fine-tuning. Основываясь на реальном опыте внедрения, мы рассмотрим:

Почему некоторые компании впустую тратят сотни тысяч долларов на fine-tuning, когда RAG был бы эффективнее
Как оценить, какой подход лучше подходит для вашего конкретного случая
Практический фреймворк для принятия правильного решения

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

Что такое Retrieval Augmented Generation?

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

Чаще всего, RAG включает в себя:

векторную базу данных (vector database) для хранения данных о продукте;
поиск по этой векторной базе данных;
возможность редактирования контента в этой базе данных (добавить новый, обновить текущий, удалить старый);
механизм работы с LLM по API.

Есть ещё дополнительные полезные фичи, которые можно включить в RAG (например, на самом первом этапе выделять вопросы из запроса пользователя; ограничивать, работу с системой в случае если пользователь задает провокационные/оскорбительные вопросы и т.д.), но это тема отдельной статьи.

RAG очень удобен когда:

вы готовите MVP;
у вас не так много узко специализированных терминов;
у вас мало статических данных в промпте;
ваш knowledge base часто обновляется

Что такое Fine-tuning?

Fine-tuning это процесс дообучения LLM модели на ваших данных.

Для чего он нужен? Чаще всего, он нужен для того, если в вашем кейсе очень много спец. жаргона, который обычной модели очень сложно понять.

Как поведет себя модель, если она не знает спец. терминов? Правильно, она будет глючить и галлюцинировать.

Чтобы такого избежать, обычно, в промпте добавляют объяснение используемых терминов. Но если у вас их очень много, то такие пояснения придётся добавлять для каждого запроса в LLM, что будет тратить токены. (Мы держим в голове, что мы платим за токены и окно промпта не резиновое и состоит из определённого количества токенов)

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

В чем состоит процесс дообучения? В том, что вам необходимо предоставить dataset из примеров, в которых будет объяснение

Например, OpenAI в своей статье с описанием Fine-tuning использует следующий пример:

{"messages": [{"role": "system", "content": "Marv is a factual chatbot that is also sarcastic."}, {"role": "user", "content": "What's the capital of France?"}, {"role": "assistant", "content": "Paris, as if everyone doesn't know that already."}]}

{"messages": [{"role": "system", "content": "Marv is a factual chatbot that is also sarcastic."}, {"role": "user", "content": "Who wrote 'Romeo and Juliet'?"}, {"role": "assistant", "content": "Oh, just some guy named William Shakespeare. Ever heard of him?"}]}

{"messages": [{"role": "system", "content": "Marv is a factual chatbot that is also sarcastic."}, {"role": "user", "content": "How far is the Moon from Earth?"}, {"role": "assistant", "content": "Around 384,400 kilometers. Give or take a few, like that really matters."}]}

По каждому вопросу необходимо предоставить, как минимум, 10 хороших примеров. OpenAI советует предоставлять 50-100 примеров для своих моделей gpt-3.5 и gpt-4o-mini.

Также, необходимо чтобы примеры были довольно разнообразными. Ну и конечно, необходимо иметь список контрольных вопросов, чтобы можно было оценить то, насколько качественно LLM дообучилась, но это уже тема (оценка качества ответов) отдельной статьи.

Что подойдет больше для моего кейса?

Окей, теперь давайте попробуем ответить на главный вопрос. Для примера, возьмём популярный кейс с чатботом для вашего SaaS, у которого есть свой раздел базы данных (helpdesk, knowledge base). Цель такого чатбота – отвечать на самые простые вопросы пользователей по этой базе данных, а если не справляется, то звать человека на помощь.

Для примера возьмём кейс SpreadSimple – это конструктор интернет-магазинов на основе Google Sheet таблиц. У SpreadSimple есть свой, довольно объемный, хелпдеск, но большинство пользователей не любит читать инструкции и им проще задать вопрос о своей проблеме в чате. Например, пользователь хочет понять, как ему создать сайт. При использовании RAG, мы должны будем пойти в нашу векторную базу знаний, найти релевантные кусочки релевантных статей с объяснением того, как создать сайт, предоставить этот контекст в промпт и попросить LLM ответить на вопрос пользователя, используя этот контекст. В таком случае, если контекст найден правильно и он отвечает на вопрос пользователя, то составить ответ, используя этот контекст, не является проблемой для почти любой LLM.

Как бы мы применили Fine-tuning в таком случае? Никак, fine-tuning для такого кейса бесполезен.

Хорошо, но в каких случаях тогда можно применять Fine-tuning?

В случаях, когда:

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

Использование Fine-tuning и RAG одновременно

Также, мы можем объединить оба подхода, если они подходят к вашим требованиям.

Имплементация Retrieval Augmented Generation

Типичная RAG система включает в себя:

модуль разделения статьи knowledge base на куски (chunking);
преобразование текста в вектора – embeddings;
хранение векторов в базе данных;
преобразование запроса пользователя в векторы;
модуль поиска по векторной базе данных;
слияние найденного полученного результата поиска в промпт;
отправка полученного промпта в LLM;
возвращение результата пользователю;

Также, могут быть дополнительные шаги:

выделение вопросов из запроса пользователя и обработка каждого;
процесс обновления данных в векторной базе данных;
guardrails – модуль проверки введенного запроса от пользователя на предмет наличия в нём оскорблений, неправомерного контента и т. д. Также, с помощью guardrails можно проверять и полученный ответ от LLM;
применение structured output (у OpenAI) или аналогов для запроса в LLM для того чтобы получить машино-читаемые данные, например, в формате JSON, чтобы далее их можно было удобно обрабатывать приложением;
добавление различных evaluations ответов LLM;

Обычно, создание MVP RAG системы у Middle Backend инженера может занимать 1-2 недели.

Заключение

На этапе создание Proof-of-Concept или Minimal Viable Product я рекомендую использовать RAG, так как в этом подходе можно очень быстро и дешево менять входные параметры и проверять идею. Fine-tuning лучше использовать тогда, когда есть уже продакшен версия приложения и вы планируете оптимизировать расходы, это поможет сэкономить токены на использовании статических данных (жаргоны, стилистика, паттерны и прочее)

В моём Telegram канале я делюсь своим опытом в разработке AI решений — The AI Architect Blog. Буду рад подписке 🙂