RAG или дообучение: что выбрать

Почти каждый ИИ-проект, который мы обсуждаем с клиентами, начинается с одного и того же вопроса: «Нужно ли нам дообучать модель на наших данных?» Иногда ответ — да. Но чаще реальная потребность — в другом: ассистент, который знает ваши актуальные документы, ссылается на источники и может быть обновлён во вторник после обеда без обучающего прогона. В этой статье мы простым языком разбираем основные варианты, когда каждый из них уместен и как принять решение, не сжигая месяцы на неправильный подход.

Четыре инструмента в наборе#

Когда говорят «обучить модель на нашем бизнесе», обычно имеют в виду одну из четырёх разных техник. Они решают разные задачи и могут комбинироваться.

Retrieval-augmented generation (RAG)#

RAG не изменяет модель. Вместо этого, когда поступает вопрос, система сначала ищет в вашем собственном контенте — инструкциях, контрактах, тикетах или каталоге продуктов — и передаёт модели наиболее релевантные фрагменты вместе с вопросом. Затем модель отвечает на основе этих фрагментов.

Здесь важны три идеи:

• Retrieval (поиск): нахождение нужных фрагментов. Обычно это сочетание семантического поиска по эмбеддингам и классического поиска по ключевым словам, часто с последующим этапом переранжирования.
• Grounding (обоснование ответа): инструктаж модели отвечать на основе предоставленного материала и честно сообщать, когда материал не содержит ответа.
• Citations (цитирование): указание точного документа, страницы или фрагмента, откуда взят ответ, чтобы человек мог его проверить.

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

Дообучение (fine-tuning)#

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

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

Промптинг с длинным контекстом и кешированием промптов#

Современные модели Anthropic, OpenAI и ряда open-source семейств принимают очень длинные входные данные. Если ваша база знаний невелика — например, справочник по продукту, набор политик или FAQ, — её часто можно целиком поместить прямо в промпт. Никакого индекса, конвейера поиска и решений о чанкинге.

Очевидное возражение — стоимость и задержка: отправлять один и тот же большой документ с каждым запросом расточительно. Кеширование промптов (prompt caching) решает эту проблему. Провайдеры могут кешировать стабильный префикс промпта, так что повторные запросы переиспользуют уже обработанный контент и оплачиваются и обслуживаются эффективнее. Для стабильного, ограниченного массива знаний длинный контекст с кешированием часто — самое простое работающее решение.

Структурированные выводы (structured outputs)#

Многие «ИИ»-проекты на самом деле — проекты по извлечению данных: прочитать счёт, резюме, контракт или письмо и выдать чистые поля. Здесь ключевая возможность — структурированные выводы (structured outputs), когда модель ограничена возвратом данных, соответствующих заданной вами схеме, например JSON с конкретными полями и типами. Это вообще не про знания — это про надёжность формата, и обычно это устраняет необходимость в дообучении для задач извлечения.

Когда какой подход подходит#

Полезный способ рассуждения: отделите знания от поведения.

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

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

Сравнение по критериям#

Практический чек-лист для принятия решения#

Прежде чем выбирать архитектуру, честно ответьте на эти вопросы:

1. В чём именно задача? Отвечать на вопросы, черновить тексты, классифицировать или извлекать? Запишите пять реальных примеров входных данных и идеального вывода.
2. Как часто меняются лежащие в основе знания? Ежедневные или еженедельные изменения — сильный аргумент против дообучения.
3. Нужно ли пользователям проверять ответы? В юридическом, финансовом, комплаенс-контексте, в поддержке или в здравоохранении цитирование обычно не подлежит обсуждению.
4. Насколько велика база знаний? Если она с запасом помещается в контекстное окно, сначала попробуйте длинный контекст с кешированием.
5. Кто что может видеть? Если разные пользователи имеют доступ к разным документам, нужен поиск с фильтрацией по правам, а не единый общий промпт или модель, обученная на всём.
6. Какой объём и задержку вы ожидаете? Большой объём на узкой задаче — то место, где меньшие или дообученные модели окупают себя.
7. Есть ли у вас размеченные примеры? Дообучение без солидного набора качественных примеров редко превосходит хорошо написанный промпт.
8. Как вы будете измерять успех? Если не можете ответить — остановитесь и сначала соберите оценочный набор.

Если большинство ответов указывает на «меняющиеся знания, нужны цитаты, умеренный объём», вам нужны RAG или длинный контекст. Если на «стабильная задача, строгий формат, очень большой объём» — рассмотрите дообучение или меньшую модель.

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

Это проблемы, которые мы чаще всего видим при ревью ИИ-систем, которые «почти работают».

• Плохой чанкинг. Разбиение документов на произвольные куски фиксированного размера разрезает таблицы пополам, отрывает заголовки от их содержимого и теряет контекст. Делите по структуре документа и сохраняйте полезные метаданные — заголовок, раздел и дату.
• Нет оценки качества. Без тестового набора каждое изменение — гадание. Команды крутят промпты, меняют модели и размеры чанков, не зная, стало лучше или хуже.
• Устаревшие индексы. Исходные документы обновили, индекс — нет. Ассистент уверенно цитирует прошлогоднюю политику. Переиндексация должна быть частью процесса работы с контентом, а не ручной задачей «когда вспомнят».
• Галлюцинации без цитат. Если система не показывает, откуда взят ответ, пользователи не могут отличить обоснованный ответ от выдуманного. Требуйте цитирования и учите модель говорить «я не знаю», когда источники молчат.
• Приватность и GDPR. Персональные данные в документах, промптах и логах остаются персональными данными. Знайте, какой провайдер их обрабатывает, в каком регионе, по какому соглашению об обработке данных и как долго хранятся логи. Дообучение на персональных данных требует особой осторожности, потому что удалить их потом сложно.
• Промпт-инъекции из документов. Найденный контент — недоверенный ввод. Документ может содержать текст, пытающийся инструктировать модель — например, игнорировать правила или раскрыть другие данные. Относитесь к найденному тексту как к данным, ограничивайте, что модель может делать с инструментами, и никогда не позволяйте содержимому документов выдавать разрешения.

Сначала оценка, потом оптимизация#

Самый ценный шаг в любом ИИ-проекте — одновременно самый незаметный: соберите оценочный набор до выбора архитектуры.

Хороший стартовый набор — это просто от нескольких десятков до нескольких сотен реальных вопросов или входных данных, каждый с ожидаемым ответом или документами, которые должны быть процитированы. Затем измеряйте:

• Качество поиска: нашла ли система нужные фрагменты?
• Качество ответа: корректен ли ответ, полон ли и обоснован ли источниками?
• Точность цитирования: действительно ли процитированные фрагменты подтверждают утверждение?
• Поведение при отказе: говорит ли система «я не знаю», когда должна?
• Соответствие формату: при извлечении данных каждый ли вывод соответствует схеме?

Когда это есть, сравнения становятся фактическими. Вы можете тестировать длинный контекст против RAG, одну модель против другой, дообученную модель против промптованной — на собственных данных, а не на общих бенчмарках. Часто окажется, что самое дешёвое исправление — лучший поиск или более чёткий промпт, а не большая модель или обучающий прогон.

Автоматическая оценка моделью может это ускорить, но выборочно проверяйте её людьми-ревьюерами, особенно на раннем этапе.

Как наши собственные демо иллюстрируют эти подходы#

Мы стараемся применять то, что рекомендуем, и два демо на этом сайте показывают эти подходы в действии.

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

Демо Document Q&A показывает другую сторону. Вы загружаете документ, задаёте вопросы, и каждый ответ снабжён цитатами, указывающими на фрагменты, на которые опиралась система. Это главное обещание обоснованного ИИ: каждое утверждение можно проверить по источнику.

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

Кратко#

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

Если вы взвешиваете эти варианты для реального проекта, наша команда AI & Automation под руководством техлида с более чем 20-летним опытом поможет определить рамки, собрать оценочный набор и выпустить первую версию, которую действительно можно измерить. Свяжитесь с нами и расскажите, какую задачу вы решаете.