Промпт, RAG или дообучение: что на самом деле нужно вашему ИИ-решению

Короткий ответ таков. Если модели не хватает актуальных или закрытых данных компании, начните с передачи контекста: чёткой инструкции с нужными фрагментами документов или RAG, то есть поиска релевантных фрагментов в вашей базе перед каждым ответом. Если у модели есть все нужные данные, но она ведёт себя нестабильно (путает формат, стиль, категории обращений), сначала добавьте примеры и проверку результата. Дообучение стоит рассматривать, когда более простые шаги не дали нужного качества, есть качественная обучающая выборка и доступен способ обучения. Эти методы не являются ступенями, которые нужно проходить по очереди. Они решают разные задачи и часто работают вместе.

Главное условие для любого из этих решений — контрольная выборка с эталонными ответами. Без неё вы выбираете метод на ощущениях. Прочитав статью, вы сможете определить, какую именно ошибку допускает ваше решение, какой рычаг её исправит и когда имеет смысл переходить к более сложному варианту.

Какую ошибку вы исправляете

Фраза «ИИ плохо отвечает» ничего не говорит о причине. Для выбора метода полезно разделить ошибки хотя бы на четыре группы.

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

Модель знает, но отвечает не в том виде. Например, возвращает произвольный текст вместо таблицы, пропускает обязательное поле или пишет слишком разговорно для официального письма. Здесь проблема в поведении, а не в знаниях.

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

Модель получает правильные данные, но неправильно ими пользуется. Фрагмент документа найден, но ответ всё равно неверен: модель пропустила исключение, смешала два условия или взяла не ту строку таблицы. Здесь нужно отдельно проверять и поиск, и генерацию.

Полезная практика: до любых изменений разберите 20–30 реальных запросов, отнесите каждый неверный ответ к одной из этих групп и посчитайте, какая встречается чаще. Это уже задаст направление. Если недостающие факты часто меняются или требуют прослеживаемого источника и контроля доступа, сначала проверьте передачу контекста или поиск. Дообучение может помочь со стабильными отраслевыми примерами, но его эффект нужно оценивать отдельно. Если факты на месте, а проблема в нестабильном формате, расширение базы знаний тоже не поможет.

Когда достаточно промпта

Промпт, то есть инструкция для модели вместе с примерами и входными данными, — самый дешёвый рычаг. Его можно изменить за несколько минут и сразу проверить результат. Для многих задач (суммирование, перевод, черновики типовых писем, извлечение нескольких полей из текста) качественный промпт уже обеспечивает рабочий уровень.

Что обычно входит в хороший промпт для бизнес-задачи:

• Цель и границы. Что именно должна сделать модель, для кого и чего делать нельзя.
• Формат результата. Список полей, допустимые значения, правило для отсутствующих данных.
• Несколько примеров. Две-пять пар «вход — правильный выход», желательно с разными сложными случаями, а не только с очевидными.
• Нужный контекст. Если данных немного и они стабильны, их можно просто включить в инструкцию.

Главная ловушка на этом этапе — проверять промпт на тех же примерах, которые в него включены. Тогда он кажется идеальным, но на новых данных ведёт себя иначе. Отложите отдельный набор запросов, которых модель не видела в инструкции, и сравнивайте качество только на нём.

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

Когда нужен RAG

RAG (retrieval-augmented generation, генерация с поиском) работает так: система получает запрос, ищет в базе документов несколько релевантных фрагментов и передаёт их модели вместе с вопросом. Модель отвечает, опираясь на эти фрагменты.

Этот подход уместен, когда информация:

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

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

В RAG появляется вторая ось качества — поиск. У неверного ответа могут быть две разные причины. Поиск не нашёл нужный фрагмент или принёс слишком много лишнего, и модель потерялась в шуме. Либо фрагмент найден правильно, но модель плохо им воспользовалась. Поэтому RAG нужно оценивать поэтапно: отдельно проверять, попал ли нужный фрагмент в контекст, и отдельно — соответствует ли ответ этому фрагменту. Если объединить эти две метрики, легко начать исправлять не ту часть системы.

Важно: RAG не делает модель «умнее» в процедурных вопросах. Если проблема в нестабильном формате или классификации, более качественный поиск её не устранит.

Когда имеет смысл дообучение

Дообучение (fine-tuning) означает, что модель дополнительно обучают на ваших примерах, чтобы она усвоила определённое поведение без длинных инструкций в каждом запросе. Дообучение прежде всего адаптирует поведение модели и может помочь с отраслевыми примерами. Оно не заменяет надёжный управляемый источник фактов, которые меняются или требуют прослеживаемости.

Признаки того, что дообучение стоит рассмотреть:

• Повторяющаяся задача с чётким правильным ответом. Классификация, извлечение полей, переписывание текста в заданном стиле — задача, для которой есть понятный эталон.
• Промпт с примерами уже исчерпал себя. Вы проверили инструкцию на контрольной выборке, проанализировали ошибки, добавили сложные примеры, но стабильности всё равно не хватает.
• Есть качественная выборка. Примеры отражают реальные входные данные по форме и содержанию. Если в рабочем процессе модель получает фрагменты через RAG, обучающие примеры тоже должны их содержать.
• Достаточный объём использования. Дообучение имеет смысл, когда задача выполняется часто. Тогда короткие промпты или меньшая модель могут снизить стоимость и задержку.
• Доступен способ обучения. Здесь нужна актуальная проверка. Условия разных поставщиков и моделей отличаются и меняются. Например, по состоянию на октябрь 2026 года OpenAI сворачивает свою платформу дообучения: новые пользователи уже не имеют к ней доступа, а существующие могут запускать обучение ещё ограниченное время. Поэтому перед планированием проверьте, доступно ли оно для вашей учётной записи, модели и региона, и есть ли альтернатива на открытых моделях.

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

Также учитывайте затраты на сопровождение. Дообученную модель нужно обучать заново, когда меняются категории, правила или базовая модель. Кто-то должен поддерживать набор данных, проверять качество после каждого обновления и решать, что делать, когда базовую модель снимут с обслуживания.

Когда методы сочетаются

На практике сложные задачи часто включают оба типа проблем. Модели нужны свежие данные и одновременно стабильное поведение. Тогда методы дополняют друг друга.

Типичный процесс может выглядеть так:

1. Базовый промпт и контрольная выборка. Фиксируем исходное качество.
2. Статические примеры в промпте. Проверяем, повысилась ли стабильность.
3. Поиск релевантных фрагментов или примеров для каждого запроса. Качество зависит от того, насколько контекст действительно относится к вопросу.
4. Если поведение всё ещё нестабильно и есть качественные примеры, рассматриваем дообучение на примерах, которые уже содержат найденные фрагменты.
5. Добавляем проверку фактов в ответах и возвращаемся к оценке.

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

Распространённая ошибка — пытаться «записать» всю базу знаний в веса модели с помощью дообучения. Факты в такой модели нельзя быстро обновить, невозможно показать, из какого документа взят ответ, и сложно разграничить доступ. Для меняющихся знаний управляемая база с поиском остаётся более надёжным способом.

Как принять решение по данным

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

Учебная матрица выбора

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

При сравнении вариантов учитывайте не только качество:

• Стоимость ошибки. Неточный черновик, который исправит человек, и неверная сумма возврата денег имеют разную цену. От неё зависит, какое качество достаточно.
• Стоимость внедрения. Сбор и разметка примеров, настройка поиска, обучение.
• Стоимость одной задачи. Длинный контекст увеличивает расходы на каждый запрос; дообучение может их снизить, но добавляет расходы на обучение.
• Сопровождение. Кто обновляет базу, кто поддерживает обучающую выборку и как часто нужно повторять проверку.

Если более простое решение обеспечивает приемлемое качество с учётом цены ошибки, остановитесь на нём. Более сложная архитектура не является самоцелью.

Вывод

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

Что можно сделать в своём процессе уже сейчас:

1. Соберите 30–50 реальных запросов и запишите для каждого правильный ответ. Отложите эту выборку для контроля.
2. Проверьте текущее решение и отметьте тип каждой ошибки: отсутствующий факт, неверный формат, непоследовательная классификация, неправильное использование найденного фрагмента.
3. Для преобладающего типа ошибки сделайте самый простой подходящий шаг: контекст для фактов, примеры и схему для формата.
4. Повторно измерьте качество на той же контрольной выборке. Не добавляйте её примеры в инструкцию.
5. Рассматривайте дообучение, только когда исчерпаны более простые шаги, есть отдельная обучающая выборка и проверена актуальная доступность обучения для вашей модели.
6. Запишите стоимость ошибки, внедрения и сопровождения для каждого варианта, чтобы решение принималось по цифрам.

Если вы выбираете способ повысить качество ИИ для конкретного процесса, команда BotLabs может обсудить его с вами на 15-минутной консультации. Разберём, какие ошибки допускает текущее решение, какие документы и примеры уже есть и с какой контрольной выборки начать проверку. Следующим шагом определим, что именно стоит проверить на ваших данных.

Часто задаваемые вопросы