RAG, fine-tuning или prompt engineering: что выбрать

RAG, fine-tuning и prompt engineering решают разные дефициты LLM-приложения. Prompt engineering задаёт инструкции и примеры в контексте запроса. RAG находит внешние данные и добавляет их в этот контекст. Fine-tuning изменяет веса модели на обучающих примерах, чтобы устойчивее воспроизводить нужное поведение.

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

Короткий ответ: начните с prompt и eval. Если ответ зависит от изменяемых или закрытых источников — добавьте RAG. Если после этого на достаточном наборе примеров остаётся повторяемый дефект поведения, рассмотрите fine-tuning. Точные значения и действия получайте через API, правила или structured output, а не из памяти модели.

Главное за минуту

Prompt engineering меняет инструкцию, а не знания или веса модели.
RAG подаёт найденные факты во время запроса и может показывать источники.
Fine-tuning меняет модель на примерах, но не заменяет базу актуальных фактов.
API и бизнес-правила — четвёртый вариант для точных данных и действий.
Сравнивайте методы на одном frozen eval и одной модели-базе.
Комбинация оправдана, когда каждый слой устраняет измеренный класс ошибок.
Считайте не только запуск, но и обновление, review, inference и rollback.

Содержание

Три способа адаптации LLM
Метод ДИАГНОЗ
Ошибка подсказывает метод
Когда достаточно prompt engineering
Когда нужен RAG
Когда оправдан fine-tuning
Когда нужен API или обычный код
Как сочетать методы
Как сравнить варианты честно
Стоимость и эксплуатация
Риски и безопасность
План эксперимента
Карточка решения
Частые вопросы
Как AI рассвет выбирает стек адаптации
Вывод

Три способа адаптации LLM

Метод	Что меняется	Где находятся данные	Типичная сильная сторона	Главная граница
prompt engineering	инструкция и примеры	в запросе/context	быстро проверить правило и формат	ограниченное окно, нестабильность
RAG	контекст из поиска	во внешнем источнике и индексе	свежие/частные факты, provenance	качество retrieval и источников
fine-tuning	веса модели	в обучающем наборе и артефакте модели	повторяемое поведение на узкой задаче	данные, обучение, переоценка и rollback

Официальное руководство OpenAI по оптимизации моделей ставит eval до prompt и fine-tuning: сначала измерение, затем инструкции, а обучение — для части сценариев. Этот порядок полезен независимо от выбранного провайдера.

Методы не образуют лестницу зрелости. Fine-tuning не «выше» RAG, а длинный prompt не «проще» поиска во всех случаях. Это разные места, где команда меняет систему.

Метод ДИАГНОЗ

ДИАГНОЗ — семь вопросов перед выбором:

Д — Дефицит: чего не хватает — инструкции, факта, поведения или действия?
И — Изменчивость: как часто меняются знания, политика и формат?
А — Аудитируемость: должен ли пользователь увидеть источник и версию?
Г — Границы риска: какова цена неверного ответа или раскрытия?
Н — Набор eval: есть ли representative и negative cases?
О — Операционная цена: кто обновляет prompt, индекс, dataset и model artifact?
З — Запасной маршрут: clarify, abstain, human review или deterministic fallback?

Результат ДИАГНОЗ — не название технологии, а проверяемая гипотеза: «ошибка вызвана отсутствием документа в контексте; добавление permission-aware retrieval должно улучшить retrieval/answer rubric без access leakage».

Ошибка подсказывает метод

Наблюдаемая ошибка	Первая гипотеза	Что проверить
ответ нарушает явное правило	prompt/policy	ясность инструкции, конфликт и приоритет
не знает новый регламент	RAG или API	источник, version, ACL, retrieval
путает точный статус заказа	API/tool	schema, auth, current state
формат нестабилен	structured output, prompt	schema compliance на eval
стиль расходится с примерами	prompt, затем fine-tuning	blind style rubric
классификация повторяемо ошибочна	prompt/few-shot, затем tuning	confusion matrix
цитата не подтверждает вывод	RAG + answer policy	retrieval и grounding отдельно
раскрывает закрытый документ	access architecture	filter before retrieval, logs, cache

Если тесты не локализуют ошибку, добавление нового слоя создаёт ещё одну переменную. Например, дообучение не исправит отсутствующий документ, а RAG не гарантирует соблюдение JSON-schema.

Когда достаточно prompt engineering

Prompt подходит, когда модели уже доступны нужные данные, а задача — объяснить роль, цель, ограничения, последовательность и формат. Few-shot examples помогают показать пограничные случаи без изменения весов.

OpenAI prompt engineering guide рекомендует строить инструкции с ясными секциями, релевантным контекстом и примерами; конкретные приёмы зависят от семейства модели. На практике prompt должен иметь owner, version и regression eval так же, как код.

Сигналы, что prompt недостаточен:

необходимые факты не помещаются или меняются;
требуется provenance и документный доступ;
примеров становится слишком много;
после систематической оптимизации остаётся устойчивый класс ошибок;
inference-context становится дорогим или медленным по вашим измерениям.

Не лечите prompt-ом отсутствие business rule. Если решение можно выразить таблицей условий, храните правило в конфигурации и передавайте модели только результат или допустимые варианты.

Когда нужен RAG

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

RAG требует ingestion, parsing, chunking, metadata, ACL, retrieval, reranking, answer policy, eval и monitoring. Подробный производственный контур описан в статье о RAG-системе для бизнеса.

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

Когда оправдан fine-tuning

Fine-tuning рассматривают для повторяемой узкой задачи, где есть качественные примеры входа и ожидаемого выхода, стабильная rubric и доказанный остаточный дефект после prompt/baseline. Возможные цели: классификация, специфический формат, стиль, терминология или более короткая инструкция при большом объёме запросов — последнее подтверждается только измерением TCO и качества.

В Google Cloud documentation по tuning tuning описан как адаптация модели на собственных данных под конкретные задачи. Реальные возможности, поддерживаемые модели и форматы зависят от платформы и меняются; фиксируйте provider/model snapshot в решении.

Fine-tuning — слабый выбор для точных изменяемых фактов. Обучающий пример влияет на поведение модели, но не даёт управляемого механизма «обновить один пункт, показать источник, отозвать доступ». Для этого нужны RAG, API или база правил.

Перед обучением проверьте dataset provenance, права на использование, PII, противоречия, leakage между train/validation/test и качество разметки. Сохраняйте base model, dataset version, параметры, eval report и rollback path.

Когда нужен API или обычный код

Четвёртый выбор часто важнее трёх модных терминов:

точное поле из CRM/ERP — API с авторизацией;
расчёт налога или лимита — проверяемая функция;
разрешённый статус — enum и schema validation;
критическое решение — rule engine и human approval;
поиск по артикулу — keyword/exact match;
изменение записи — bounded tool с idempotency и audit log.

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

Как сочетать методы

Комбинация имеет смысл, когда роли не пересекаются:

Prompt + API: модель извлекает намерение, API возвращает текущее значение.
Prompt + RAG: инструкция задаёт policy, retrieval приносит разрешённые факты.
Prompt + fine-tuning: короткий runtime prompt управляет моделью с выученным поведением.
RAG + fine-tuning: поиск отвечает за knowledge/provenance, tuning — за узкий стиль или задачу.
Все слои + tools: только для сценария, где каждый слой прошёл отдельную абляцию.

Абляция означает сравнить систему без нового слоя и с ним на одном eval. Если fine-tuning не улучшает целевую rubric или ухудшает critical cases, его сложность не оправдана.

Как сравнить варианты честно

Один frozen eval включает типовые, редкие, ambiguous, unanswerable, adversarial и unauthorized случаи. Для каждого задайте ожидаемый outcome и critical fails.

Сравнение фиксирует:

provider, model и snapshot;
prompt/policy version;
corpus/index/retrieval version;
fine-tune dataset и model artifact;
tool schemas и business rules;
temperature/effort и прочие значимые параметры;
качество, latency и стоимость по одному определению.

Отдельно оценивайте retrieval, grounding, task correctness, format, safety и action correctness. Средняя оценка не должна скрывать критическую утечку или неверное действие.

Стоимость и эксплуатация

Слой	Создание	Runtime	Изменение	Основной владелец
prompt	design + eval	context tokens	version + regression	product/prompt owner
RAG	ingestion + retrieval + eval	search + context + generation	reindex + regression	knowledge/data owner
fine-tuning	dataset + training + eval	tuned-model inference	dataset + retrain + release	ML/model owner
API/rules	integration + tests	call/compute	schema/rule release	system/process owner

Не делайте универсальный вывод «метод X дешевле». Цена зависит от объёма запросов, context, частоты обновления, review, инфраструктуры и инцидентов. Используйте CAPEX/OPEX-модель из статьи о стоимости внедрения ИИ и подставляйте свои измерения.

Риски и безопасность

Prompt может быть раскрыт или обойдён, RAG — вернуть запрещённый или отравленный документ, fine-tuning — запомнить нежелательный паттерн, tool — выполнить опасное действие. Ни один метод сам по себе не является guardrail.

OWASP LLM01:2025 указывает, что RAG и fine-tuning не устраняют prompt injection полностью. Поэтому права, allowlist tools, validation, approval, isolation, monitoring и incident response остаются внешними controls.

План эксперимента

Соберите baseline на исходной модели и коротком prompt.
Разметьте ошибки по ДИАГНОЗ.
Исправьте явные инструкции и business rules.
Добавьте structured output или API там, где нужна детерминированность.
Если не хватает внешних фактов, испытайте RAG отдельно.
Если остаётся стабильный behavioral gap, подготовьте tuning dataset.
Сравните base и tuned model на закрытом test set.
Проверьте комбинацию только после отдельных тестов.
Запустите shadow/canary и production sampling.
Примите scale / revise / stop и сохраните decision record.

Карточка решения

бизнес-процесс и владелец;
наблюдаемая ошибка и baseline;
выбранный слой и отвергнутые альтернативы;
evidence: eval, sample, logs;
данные, права, retention и версии;
acceptance и critical fails;
runtime/change-cost assumptions;
fallback и human review;
monitoring и incident owner;
дата пересмотра решения.

Эта карточка предотвращает «вечную архитектуру»: при смене модели, источников или объёма решение можно пересмотреть по тем же критериям.

Частые вопросы

Что выбрать для корпоративной базы знаний?

Обычно нужен prompt + RAG с документными правами, citations и abstention. Но сначала проверьте качество источников; для точных структурированных значений используйте API.

Можно ли fine-tuning загрузить знания компании?

Обучающие данные могут влиять на ответы, но fine-tuning не заменяет управляемый источник актуальных фактов, версий и прав. Для изменяемого knowledge используйте retrieval или API.

Что попробовать первым?

Baseline, eval и ясный prompt. Затем добавьте наименьший слой, который соответствует измеренному дефициту.

RAG и fine-tuning можно использовать вместе?

Да. RAG может отвечать за факты и provenance, tuning — за устойчивое узкое поведение. Пользу каждого слоя докажите отдельным сравнением.

Длинный контекст заменяет RAG?

Иногда небольшое фиксированное собрание документов можно передать целиком. Но остаются доступ, отбор, обновление, latency, стоимость и provenance. Сравните long-context baseline с retrieval на своих данных.

Как понять, что fine-tuning окупится?

Нужны измеренные объём, дефект, качество после tuning, стоимость dataset/training/release и runtime. Без этих данных окупаемость Unknown.

Как AI рассвет выбирает стек адаптации

AI рассвет может провести аудит процесса, собрать eval и baseline, настроить prompts, RAG, integrations и bounded tools, подготовить fine-tuning experiment, сравнить варианты и организовать запуск, monitoring, обучение и поддержку.

Безопасный первый шаг — выбрать один процесс, описать наблюдаемую ошибку, источники, ограничения и критерий приёмки. Затем проверить наименьшее изменение на frozen eval. Обсудить задачу.

Вывод

RAG, fine-tuning и prompt engineering — не взаимоисключающие продукты. Prompt управляет инструкцией, RAG приносит внешние факты, fine-tuning изменяет устойчивое поведение модели, а API и правила обеспечивают точные значения и действия.

Используйте ДИАГНОЗ: назовите дефицит, изменчивость, требования к аудиту, риск, eval, операционную цену и fallback. Начинайте с наименьшего изменения и добавляйте следующий слой только тогда, когда его вклад виден в тестах.