RAG против fine-tuning: что выбрать для бизнес-ассистента

Введение. Бизнес спрашивает «дообучить модель» там, где достаточно качественного retrieval и политик доступа. Материал для product- и engineering-лидеров, которые принимают решения на горизонте 12–24 месяцев, а не гонятся за хайпом в презентации.

Где AI реально окупается

Большинство срывов в теме «RAG и fine-tuning» начинается не с кода, а с размытого scope: маркетинг обещает одно, продажи фиксируют другое, а ИТ закрывает техдолг третьим приоритетом. В итоге бюджет уходит в интеграции «на скотч» и ручные сверки в Excel. Мы видим это в проектах, где не описаны границы MVP, нет владельца метрик и не зафиксированы SLA на данные между системами.

Команды, которые выбирают fine-tuning раньше, чем собрали eval-датасет, в среднем тратят 20–40% бюджета AI-инициативы на повторное обучение после первого же апдейта base model — потому что не зафиксировали baseline качества и не с чем сравнивать результат.

Рабочие сценарии для SMB

Опорный принцип: сначала поток ценности, потом стек. Нарисуйте journey от первого касания до оплаты и поддержки, отметьте ручные шаги и точки отказа. Только после этого выбирайте RAG и модель данных. Для RAG и fine-tuning мы обычно рекомендуем RAG по умолчанию; fine-tuning для тона/формата; guardrails и eval на каждом релизе: она даёт предсказуемый TCO и не блокирует масштабирование команды.

Зафиксируйте ADR по ключевым решениям: хранилище, очереди, авторизация, наблюдаемость. Включите в Definition of Done контрактные тесты API, схему событий и политику миграций. LLM имеет смысл заказывать только когда есть согласованный backlog с приоритетами P0/P1 и измеримые KPI на квартал.

Наблюдаемость для RAG — это трассировка «вопрос → retrieved chunks → ответ → источник» на каждый диалог, а не логи сервера. Без неё невозможно понять, ошибка в поиске или в генерации, и eval превращается в гадание. Ведите отдельный лог retrieval-качества (recall@k, similarity score) параллельно с логом ответов модели.

Данные, RAG и качество ответов

Кейс A (банк). Клиент пришёл с болью: галлюцинации в ответах про тарифы. Мы разбили релиз на три волны: стабилизация данных, автоматизация рутины, персонализация. Через 14 недель цитирование chunk + ACL снизило эскалации на 26%. Критично было не «переписать всё», а остановить утечку лидов на стыке каналов.

Кейс B (SaaS). Другая ситуация: нужен узкий формат JSON-ответов. Здесь сработала обратная стратегия — сначала интеграция с CRM и нормализация справочников, затем редизайн витрины. Итог: лёгкий fine-tune + схема валидации стабилизировал парсинг.

Риски и compliance

1. Выбор fine-tuning для знаний, которые меняются еженедельно — модель устаревает быстрее, чем окупается дообучение.
2. Chunking по фиксированной длине без учёта смысловых границ документа.
3. Отсутствие eval-датасета — качество оценивают «на глаз» по десятку демо-вопросов.
4. Игнорирование ACL: RAG отдаёт chunks без учёта прав доступа пользователя.
5. Смешивание fine-tuning стиля и fine-tuning знаний в одном датасете.

Пилот → production

• [ ] Собран golden set из 50–100 реальных вопросов с эталонными ответами
• [ ] Стратегия chunking протестирована на разных типах документов
• [ ] Настроен ACL на уровне chunks, а не только документа
• [ ] Каждый ответ модели логируется вместе с источником (citation)
• [ ] Зафиксирована политика обновления индекса и SLA на актуальность базы
• [ ] Hallucination rate закреплён как метрика приёмки, а не как субъективная оценка

С чего начать

Начните с eval-набора из реальных тикетов, не с выбора модели. Если нужна внешняя экспертиза — начните с брифа или оценки: так быстрее получить реалистичный план, чем спорить о стеке в вакууме.

• Chunking по смыслу, не только по длине
• Метрики faithfulness/relevance
• Логи запросов без PII в plain text

Когда RAG, когда fine-tuning

RAG подходит, когда знания часто меняются (регламенты, каталог, FAQ) и нужны ссылки на источник. Fine-tuning — когда важен стиль, формат ответа или доменная терминология при относительно стабильной базе. В 2026 году для большинства SMB-кейсов стартуют с RAG на OpenAI или Claude + quality chunking; fine-tuning рассматривают, если RAG не держит tone of voice после prompt engineering.

Оценивайте hallucination rate, latency и стоимость токенов на 1000 диалогов. Для RAG-разработки заложите pipeline обновления индекса, PII-фильтрацию и human escalation. Fine-tuning требует curated dataset и регрессионных тестов при смене base model — иначе каждый апдейт провайдера ломает поведение.

Сравните качество на golden set из 50–100 реальных вопросов сотрудников или клиентов — один и тот же набор для RAG и fine-tune. Метрики: factual accuracy, citation rate, refusal when unknown. Храните версии индекса и промптов в git. Для compliance включите audit log: кто спросил, какой chunk использован. Партнёрская AI-разработка обычно начинает с двухнедельного POC на ваших документах, а не с выбора модели «на глаз».

Зафиксируйте в контракте с провайдером LLM политику хранения логов и регион inference — это часто блокер для enterprise.