Fine‑tuning vs RAG vs «просто промпт»: как выбрать подход для CRM‑бота

Представьте ситуацию: вы защищаете бюджет на внедрение AI в компании. Финдиректор задаёт резонный вопрос: «Зачем нам тратить деньги на какое-то дообучение и серверы, если у конкурентов вроде бы всё работает на обычном ChatGPT?». Или обратная история — команда разработки настаивает на сложном RAG-конвейере с векторными базами и кучей интеграций, а вы уже представляете, как бот цитирует клиентам древние PDF-ки образца 2019 года.

Знакомо? Такие разговоры происходят почти на каждом втором совещании, где обсуждают внедрение AI-ассистента в CRM. И что характерно — правы могут быть обе стороны. Всё зависит от контекста.

Выбор архитектуры языковой модели — это не про технологии. Это бизнес-решение, от которого зависит, окупится ли проект вообще. Ошибка здесь обходится дорого: можно получить «глупого» бота, который подрывает доверие клиентов и раздражает сотрудников. А можно — «золотого» бота, который работает идеально, но стоит столько, что никогда не окупится.

В этой статье разберём три основных подхода к построению CRM-ботов. Не в терминах «энтропии» и «attention-механизмов», а через простую аналогию — представьте, что вы нанимаете нового сотрудника в отдел.

Аналогия «на пальцах»: кого мы нанимаем?

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

1. Prompt-only — «Толковый стажёр»

Это самый простой вариант. Вы берёте готовую модель (GPT-4, Claude, Gemini — неважно) и просто пишете ей хорошую инструкцию: кто она, как должна отвечать, чего делать нельзя. Модель умная, эрудированная, схватывает на лету. Вы даёте ей письмо клиента — она выдаёт ответ.

Главное преимущество — такой «сотрудник» работает буквально с первого дня. Никаких настроек инфраструктуры, никаких датасетов. Написали промпт, подключили API — готово.

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

2. RAG — «Стажёр с доступом в библиотеку»

RAG расшифровывается как Retrieval-Augmented Generation — генерация с поиском по источникам. По сути, это тот же стажёр, но теперь у него есть ключ от корпоративного архива. Прежде чем ответить на вопрос, он обязан найти соответствующий документ и сослаться на него.

Технически это работает так: вопрос клиента превращается в поисковый запрос, система находит релевантные фрагменты из вашей базы знаний (FAQ, инструкции, договоры), и модель формулирует ответ на основе этих источников. В хорошем RAG-боте можно даже показать пользователю, откуда взята информация.

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

3. Fine-tuning — «Эксперт после полугода стажировки»

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

Результат впечатляет: модель идеально попадает в Tone of Voice компании, не нуждается в длинных промптах (а значит, каждый запрос дешевле), работает быстро. Для компаний с огромным потоком однотипных обращений это может быть экономически выгодно.

Но за всё приходится платить. Подготовка качественного датасета для дообучения — это месяцы работы. Нужна команда для разметки, MLOps-инженеры для обучения и деплоя модели, серверы с GPU. И самое неприятное: если бизнес-правила изменились (новый прайс-лист, обновлённый SLA), модель придётся переучивать. Это не просто «обновить документ в базе» — это повторить весь цикл обучения.

Когда какой подход выбрать — без маркетингового тумана

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

Prompt-only подойдёт, когда: задача — переформулировать текст, сделать саммари встречи, написать вежливый отказ или подготовить черновик письма. Вся необходимая информация уже «в руках» — либо в самом запросе, либо подтягивается из CRM через API. Не нужно искать по базе знаний, не нужна сложная логика. Это 80% рутинных задач в продажах и аккаунтинге.

RAG необходим, когда: бот должен отвечать на вопросы типа «как настроить интеграцию с 1С?» или «какие условия возврата для корпоративных клиентов?». Здесь критически важно, чтобы ответ был не выдумкой, а цитатой из актуального документа. Клиент задаёт вопрос — бот находит нужный раздел инструкции и формулирует ответ на его основе. Это стандарт де-факто для техподдержки, внутренних HR-ботов и Sales Enablement.

Fine-tuning оправдан, когда: у вас очень специфический доменный язык (медицинская или юридическая терминология), жёсткие требования к формату вывода (JSON для интеграции с другими системами) или огромный поток однотипных запросов. Если компания обрабатывает 100 000+ обращений в день, дообученная модель на 7 миллиардов параметров может оказаться дешевле, чем GPT-4 с длинным промптом на каждый запрос.

Важный нюанс: эти подходы не взаимоисключающие. На практике часто комбинируют RAG с хорошим промптом, а fine-tuned модель используют только для определённого класса задач (например, генерация коммерческих предложений), а всё остальное покрывают RAG.

Что нужно подготовить: требования к данным

Какой бы подход вы ни выбрали, без данных никуда. Но объём и характер этих данных сильно различаются.

Для prompt-only достаточно минимума: 10–20 эталонных примеров того, как должен отвечать бот, плюс несколько «негативных» кейсов (что отвечать нельзя, на какие вопросы отказывать). Также понадобится доступ к CRM через API или webhook, чтобы подтягивать в промпт актуальные данные о клиенте и его заказах.

Для RAG требования серьёзнее. Нужна чистая база знаний: без дублей, без устаревших версий, с удалёнными персональными данными там, где это необходимо. Документы нужно правильно «порезать» на фрагменты (чанки) — оптимально 500–1200 токенов на чанк. Каждый фрагмент желательно снабдить метаданными: откуда взят, какая версия, на каком языке, для какого канала актуален. И главное — настроить регулярное обновление индекса, чтобы новые документы попадали в поиск автоматически.

Для fine-tuning порог входа самый высокий. Нужны десятки тысяч пар «вопрос → эталонный ответ» или реальных диалогов из чатов поддержки. Причём данные должны быть сбалансированы по категориям (нельзя, чтобы 90% примеров были про один тип вопросов). Обязательны разметка качества, разделение на обучающую и тестовую выборки, а также политика регулярного переобучения — иначе модель быстро «протухнет».

Универсальные требования ко всем подходам: чёткий список запрещённых полей (персональные данные, внутренние цены, конфиденциальные условия партнёров), система логирования для аудита, версионирование промптов и данных.

Во сколько это обойдётся: реальная стоимость владения

Вот где начинается самое интересное. Стартовые затраты — это одно, а вот полная стоимость владения (TCO) за год — совсем другое. Многие проекты «срезаются» именно на этом этапе, когда выясняется, что дешёвый в запуске prompt-only оказывается дорогим в эксплуатации, а «дорогой» fine-tuning экономит деньги на масштабе.

Частая ошибка — сравнивать только стартовые затраты. Да, prompt-only можно запустить за пару дней. Но если через полгода выяснится, что для покрытия сложных кейсов нужны промпты на 8000 токенов, а запросов 50 000 в месяц — счёт за API превысит зарплату того инженера, который это настраивал.

Типичные проблемы и как их предотвратить

Каждый подход несёт свои риски. Вот на что стоит обратить внимание ещё до запуска.

Галлюцинации в prompt-only. Модель уверенно сочиняет то, чего не знает. Как бороться: ограничивайте длину ответа, добавляйте в промпт инструкцию «если не уверен — так и скажи», используйте stop-фразы и шаблоны для критичных тем. Некоторые команды добавляют автоматическую проверку фактов через второй запрос к модели — это увеличивает latency, но снижает количество ошибок.

Устаревшие данные в RAG. Клиент спрашивает про текущие тарифы, а бот находит прайс-лист двухлетней давности. Решение: настройте автоматическое обновление индекса по расписанию или при изменении файлов, добавьте версионирование документов, мониторьте метрику groundedness (насколько ответ соответствует найденным источникам). Если процент «промахов» retrieval растёт — это сигнал, что база знаний требует чистки.

Дрейф fine-tuned модели. Обучили модель на данных прошлого года, а в этом году сменился продуктовый портфель. Модель продолжает отвечать «по-старому». Нужен регламент периодического переобучения (раз в 2–4 недели для динамичных бизнесов), A/B-тестирование новых версий на части трафика, регулярные проверки на безопасность и запрещённые темы.

Избыточная сложность на старте. Хочется сразу сделать бота, который работает в чате, почте, мессенджерах и ещё отвечает по телефону. На практике это приводит к тому, что проект не взлетает вообще. Рекомендация: начните с одного канала (обычно это веб-чат или почта), добейтесь хороших метрик качества, и только потом масштабируйте на другие каналы.

Безопасность: о чём забывают в 90% проектов

Это неудобная тема, которую все откладывают на «потом». А потом случается инцидент, и оказывается, что бот радостно рассказал клиенту про внутренние скидки для партнёров или выдал персональные данные другого пользователя.

Политика данных. Определите заранее, какие поля никогда не должны попадать в контекст модели: персональные данные (ФИО, телефоны, адреса), внутренние цены и скидки, конфиденциальные условия договоров. Настройте маскирование этих полей ещё на этапе передачи данных в LLM.

Разграничение доступа. Если бот работает с несколькими командами или регионами, индексы в RAG должны быть разделены. Менеджер из московского офиса не должен получать документы питерского филиала, если это не предусмотрено политикой. Настройте RBAC (ролевой доступ) на уровне промптов и датасетов, ведите аудит-логи всех запросов.

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

Red teaming перед запуском. До продакшена прогоните бота через набор «вредных» запросов: попытки jailbreak (заставить бота нарушить инструкции), запросы на получение чужих данных, провокации на ответы вне компетенции. Убедитесь, что бот умеет отвечать «я не знаю» и «это вне моей компетенции».

Как это работает на практике: кейсы продаж и поддержки

А теперь посмотрим, как это работает на практике — в B2B-продажах и клиентской поддержке.

Сводная матрица: ценность, сложность, риск

Чтобы упростить выбор, вот таблица, которую можно показать на совещании руководству. Каждый подход оценен по трём параметрам: какую ценность даёт бизнесу, насколько сложен в реализации и какие риски несёт.

Обратите внимание: «высокий риск» у prompt-only не означает, что подход плохой. Это означает, что он требует более тщательного контроля качества — регулярных аудитов ответов, чётких guardrails, быстрого реагирования на жалобы пользователей.

30-дневный пилот: пошаговый план

Хватит разговоров — вот реалистичный план пилотного проекта на месяц. На каждом этапе есть типичная точка провала — покажу и её.

Чеклист: готовы ли вы к масштабированию

Пилот прошёл успешно, команда довольна, метрики в порядке. Можно катить на всю компанию? Не спешите. Вот минимальный чеклист, который должен быть закрыт перед масштабированием.

Организация: назначены ответственные — владелец продукта (CRM/AI), специалист по безопасности, data steward. Есть календарь регулярных ревью качества.

Метрики качества: groundedness (соответствие ответов источникам) не ниже 85%, CSAT по ответам бота не хуже базовой линии, для RAG — не менее 70% ответов со ссылками на документы.

Мониторинг: настроены логи и алерты — детектор персональных данных в ответах, мониторинг ошибок поиска, отслеживание дрейфа качества модели.

Безопасность: тесты на запрещённые темы и попытки jailbreak пройдены с результатом не ниже 95%. Проверены сценарии утечки конфиденциальной информации.

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

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

Вот вопросы, которые задают чаще всего на стратегических сессиях по внедрению AI-ботов.

Можно ли начать с промптов, а потом перейти на RAG? Конечно. Это даже рекомендуемый путь для большинства компаний. Главное — с самого начала сохраняйте версии промптов, проектируйте логирование и метрики качества. Тогда добавление RAG-компонента станет естественной эволюцией, а не переделкой с нуля. Retrieval-слой добавляется как middleware между пользовательским запросом и генерацией ответа.

При каком объёме запросов fine-tuning окупится? Как правило, точка окупаемости — где-то от 50 000 запросов в месяц при условии, что предметная область стабильна (не меняется каждую неделю) и есть жёсткие требования к стилю или формату (юридические документы, финансовые отчёты). Экономия на токенах и сокращение редакторской правки могут перекрыть затраты на GPU и MLOps.

Нужна ли собственная модель на своих серверах? Только если есть жёсткие требования по локализации данных (data residency) или отраслевой сертификации. В остальных случаях проще и дешевле использовать облачную LLM с шифрованием, логированием и приватным RAG-индексом. Собственный хостинг — это отдельная головная боль с обновлениями, масштабированием и безопасностью.

Бот ошибается. Что делать? Добавьте кнопку «сообщить об ошибке» прямо в интерфейс — это самый ценный источник данных для улучшения. Настройте быструю разметку проблемных кейсов, автотесты на новых данных, регулярное обновление индекса (для RAG) или переобучение модели (для fine-tuning). Ошибки неизбежны — важно, как быстро вы их исправляете.