AI Architecture

RAG vs Fine-tuning — когда использовать каждый

6 измерений, оценённых 1–5, суммированных в decision band. Плюс гибридный паттерн, выигрывающий в большинстве корпоративных LLM use cases — и точка перехода стоимости, которую стоит знать перед стартом.

Обсудить вашу LLM архитектуру Pricing dataset
Рубрика

6 измерений, оценённых 1–5

Оцените каждое по шкале 1–5, где 1 склоняется к fine-tuning, 5 склоняется к RAG. Сложите оценки и прочтите decision band внизу.

📚

1. Свежесть знаний

Стабильный corpus, редкие обновления (1–2): fine-tune. Ежедневные/еженедельные обновления, регулируемый домен (4–5): RAG.

🎯

2. Структура вывода

Специфический формат/тон/persona (1–2): fine-tune. Free-form ответы grounded в источнике (4–5): RAG.

🔍

3. Требование цитирования

Нет или эстетическое (1–2): fine-tune. Жёсткое регуляторное требование (мед, юр, фин) (4–5): RAG.

💰

4. Объём запросов

10M+ запросов/год, узкий домен (1–2): fine-tune амортизируется. Меньше 1M или широкий домен (4–5): RAG.

⚡

5. Latency budget

Нужно sub-300ms p95 (1–2): fine-tune (один LLM call). 500–2000ms приемлемо (4–5): RAG.

🔐

6. Чувствительность данных

Публичные знания (1–2): оба работают. Конфиденциальный corpus, не покидающий VPC (4–5): RAG с self-hosted embeddings.

📊

Decision bands

Сумма 6–14: Fine-tune (или prompt сначала).
Сумма 15–22: ГИБРИД.
Сумма 23–30: RAG only.

Гибридный паттерн

Почему ~60% корпоративных случаев приземляются здесь

В большинстве корпоративных LLM use cases есть и требование стабильного стиля, и меняющаяся база фактов. Ответы customer support должны звучать как бренд и цитировать актуальную политику. Клиническая документация должна следовать шаблону учреждения и ссылаться на последнее руководство.

Гибридный паттерн: fine-tune базовой модели (часто LoRA, не full fine-tune) на ~1–5K курируемых примерах для закрепления стиля и структуры; добавить RAG над живым document corpus. Fine-tuned модель знает, как писать; RAG говорит, о чём.

Подводные камни

Типичные ошибки

⚠️

Fine-tuning для обучения фактам

Fine-tuning сдвигает вероятностные распределения; он не хранит факты надёжно. Если fine-tune должен знать ваш каталог продуктов — вы построили фабрику галлюцинаций.

⚠️

Пропуск prompt baseline

30–40% случаев, где команды сразу прыгнули в RAG или fine-tuning, можно было решить хорошо написанным prompt на сильной базовой модели. Всегда докажите baseline сначала.

⚠️

RAG без качества retrieval

RAG наследует качество retrieval. Если embeddings, chunking или reranking плохие — система хуже, чем prompt-only.

⚠️

Re-fine-tuning на каждое обновление

Если corpus меняется еженедельно, fine-tuning — неверный инструмент. Используйте RAG.

Итог

Что применить завтра

Оцените 6 измерений. Сложите. Прочтите band. Сначала докажите prompt-only baseline — пропустите оба в 1 из 3 случаев. Когда baseline не справляется, гибрид (RAG + LoRA fine-tune) — default. Pure fine-tune только для high-volume, stable-corpus, latency-critical случаев. Pure RAG, когда citations non-negotiable.

Читать методологию Обсудить архитектуру