Я давно вижу, как люди путаются между двумя похожими по цели, но разными по механике подходами — Retrieval Augmented Generation и дообучение моделей. В этой статье я разобрала на примерах, когда RAG даёт выигрыш по качеству и скорости внедрения, а когда fine-tuning снимает узкие места и превращает LLM в операционного помощника, который пишет как ваш бренд и разбирает ваш домен. Покажу архитектуры на n8n и Make.com, объясню, где нужны векторные базы, а где достаточно пайплайна с классификатором и ограниченным промптом. Добавлю метрики и грабли, которые обычно прилетают на второй неделе запуска, и покажу гибрид, где RAG и fine-tuning работают вместе — спокойно, без магии и хайпа. Материал подойдёт всем, кто строит автоматизацию вокруг контента, поддержки, аналитики и внутренних знаний, а также тем, кто хочет экономить часы и не терять прозрачность и 152-ФЗ на входе.
Время чтения: ~15 минут
История из практики и вопрос, который всё решает
Однажды утром у меня остыл кофе, потому что я полчаса спорила с командой поддержки: нужен ли им RAG для базы знаний или хватит дообучить модель на примерах тикетов. Агент отвечал красиво, но иногда выдумывал статусы заявок — те самые галлюцинации, которые в операционке ранят больнее, чем неловкий тон. Мы открыли логи и увидели типичную картину: 70% запросов требуют свежих данных, которые меняются каждый день, а 30% — это стабильные паттерны, где важны тон и формат. Тогда я сформулировала простой вопрос, который всегда задаю первой: ответ должен базироваться на актуальном источнике или на усвоенном умении. Всё, что про источник — тянем через RAG. Всё, что про умение — доучиваем модель.
Если честно, чаще всего побеждает не один из подходов, а комбинация. Я спокойно отношусь к гибридным схемам: там, где справки из базы и цены меняются каждый час, хорошо живёт retrieval. Там, где нужны устойчивые форматы писем, классификация намерений, тональность, пригодится fine-tuning. Разница на бумаге звучит очевидно, на проде же многие путают RAG с выгрузкой PDF в промпт, а fine-tuning — с копированием стиля в пару подсказок. Продолжим без мифов, с цифрами и тем самым тёплым реализмом.
Где спотыкаются проекты и почему выбор подхода решает половину боли
Первая типичная ошибка — пытаться закрыть всю компанию одним подходом. Команда маркетинга хочет, чтобы модель писала тексты в корпоративном стиле, служба поддержки — чтобы отвечала строго по базе знаний, юристы — чтобы она ничего не выдумывала и не нарушала 152-ФЗ, а ИТ-риски тихо шепчут про аудит и трейсинг. Если поставить на всё fine-tuning, вы получите красивый тон, но устареете каждый раз, когда меняется регламент. Если поставить на всё RAG, вы получите актуальность, но потеряете устойчивое поведение в форматах, где важна структурная предсказуемость.
Вторая ошибка — воспринимать RAG как волшебный поиск по PDF. На деле retrieval — это инженерия: нормализация источников, чанкинг, эмбеддинги, векторная база, ранжирование и проверка обоснованности. Без политики обновления индекса и без оценки релевантности модель будет цитировать старые документы и на голубом глазу ссылаться на пункт, которого уже нет. Меня это не веселит, зато дисциплинирует. И да, RAG — это не rag n bone man, не rag bone и не тот ragged man из плейлиста, хотя смешные пересечения поисковых запросов иногда попадаются.
Третья ошибка — недооценка объёма данных для fine-tuning. Чтобы получить устойчивый навык, нужно несколько сотен или тысяч хорошо размеченных примеров, а не две дюжины. Особенно если целимся в llm fine tuning с контролируемым стилем и специфичными форматами. Маленькие выборки годятся для адаптеров или инструкционного дообучения, но и там важна чистота. Иначе получите fine tuned модель, которая уверенно повторяет ваши баги и странные обороты, от которых вы сами уже уходите.
Четвёртая ошибка — смешивать задачи. RAG хорошо отвечает на вопросы уровня выберите правильный ответ что, найдите вероятность того что случайно выбранное правило сработает — если всё это явное знание в документах. Fine-tuning уместен, когда нужно научить модель решать типовые кейсы без поиска: структурировать тикеты, конвертировать неформальные описания в стандартизированные поля, держать фирменный тон. На смешанной задаче один подход всегда будет выглядеть хуже, чем другого от него ждут.
Ключ к выбору простой: требуется внешний источник — RAG. Нужен устойчивый навык — fine-tuning. Всё остальное — инженерия вокруг.
Наконец, пятая ошибка — забывать про метрики. Если не измерять groundedness, точность извлечения, время ответа и стоимость запроса, то кажется, что всё работает. Стоит добавить дешборд — картина становится взрослой: где-то ответы стары, где-то пропадает контекст, а где-то растёт чек на инференс. Мой совет простой: договоритесь о 3-5 метриках на старте и обновляйте их раз в неделю, иначе будет вечная вера на слово.
Отталкиваясь от этих наблюдений, я дальше разложу оба подхода по полочкам, затем покажу гибрид и предложу готовые связки на n8n и Make.com. Это тот случай, когда структура экономит часы внедрения и спасает от сюрпризов в проде.
RAG на практике: как тянуть знания снаружи и оставаться честными
Retrieval Augmented Generation — это когда модель не пытается помнить все детали мира, а умеет быстро спросить внешний источник, взять релевантные фрагменты и на основе их сформировать ответ. Простая аналогия: я не помню наизусть все регламенты, я храню их в Confluence и в корпоративном диске, знаю, где что лежит, и умею сослаться на конкретный пункт. В RAG роль памяти исполняют эмбеддинги и векторная база, а роль аккуратности — ранжирование и проверка цитат. Если база обновляется, модель автоматически начинает работать с актуальными данными, без повторного обучения. Именно это делает RAG незаменимым в динамичных доменах.
Чтобы RAG был не на бумаге, а в деле, вам нужны четыре столпа. Первый — сбор и нормализация источников: базы знаний, регламенты, письма, табличные данные. Второй — чанкинг: делим документы на логические куски, чтобы модель не тащила весь PDF. Третий — эмбеддинги и векторная база, например, Qdrant или PostgreSQL с pgvector. Четвёртый — перегенерация ответа с обоснованием: мы явно показываем, на какие отрывки опираемся. Всё это складывается в конвейер, который легко автоматизируется в n8n и Make.com.
У RAG три очевидных плюса. Он тянет актуальные данные без переобучения, он гибок к изменениям источников, и он снижает галлюцинации, потому что заставляет модель опираться на реальные фрагменты. Минусы тоже есть: зависимость от качества источников, необходимость поддерживать индекс в свежем состоянии и инфраструктурная нагрузка. Но это честные минусы — их видно, ими можно управлять расписаниями обновлений и мониторингом покрытий.
Чтобы не быть голословной, приведу интересное наблюдение из открытых исследований. В совместной работе с департаментом WXG Tencent показали, что продуманный RAG с хорошими моделями встраивания может превосходить простое дообучение на точности, особенно на редких знаниях. Источник есть в открытом доступе, можно углубиться и сравнить настройки при желании, ссылка здесь: arxiv.org. У меня ощущение схожее: когда вопросы про редкие детали, правильный retrieval бьёт память модели.
В бытовых кейсах RAG особенно хорош: база знаний поддержки, справочная система для сотрудников, поиск по договорам и техническим описаниям, аналитические сводки по свежим данным. Это те сценарии, где вопрос звучит как что выбери ответ на основе документа, или найдите вероятность того что выбранный пункт относится к процедуре. Перевожу на русский без академизма: нужно точно ссылаться — идём в retrieval.
Если собрать всё это вместе, получается так: RAG — это способ дать модели глаза и слух в виде внешних данных. Хорошо подходит туда, где истина живёт не в параметрах модели, а в документах и таблицах. А когда истина — это устойчивый способ действовать, мы идём в дообучение. К этому как раз и перейдём.
Когда выигрывает fine-tuning и как не потерять общие знания
Fine-tuning — это дополнительное обучение предварительно обученной модели на вашем наборе данных. Он нужен, когда вы хотите навык, а не ссылку: писать письма в определённом стиле, классифицировать документы по доменному признаку, соблюдать строгую структуру ответа, обрабатывать тикеты в едином формате. Здесь retrieval не поможет — модели нечего извлекать, потому что задача про поведение. Пара-тройка промптов иногда играет роль, но устойчивости мало, зато риск дрейфа велик. Дообучение обучает модель делать одно и то же правильно и предсказуемо.
В плюсах fine-tuning — специализация. Модель резко лучше справляется с вашей задачей и перестаёт «плавать» между вариантами. Второй плюс — управляемый стиль и тон: если вы хотите, чтобы письма звучали как ваш бренд, это не про RAG. Третий плюс — эффективность: на узких задачах дообученные модели часто дешевле в инференсе и быстрее на ответах, особенно если применяются адаптеры вроде LoRA. Минусы тоже есть: риск забывания общих знаний, зависимость от качества и объёма данных, необходимость поддерживать датасет свежим и чистым.
Я люблю разносить задачи по корзинам. Нет текстовых источников, но есть шаблоны и правила — fine-tuning моделей. Есть много меток и нужна классификация без «подглядеть в документ» — тоже сюда. Нужна стойкая форма, где каждое поле критично — сюда же. А вот когда вопрос зависит от конкретной версии регламента и актуальных цифр, fine tuned модель будет теряться, потому что у неё нет глаз. Это проверено на десятках пайплайнов.
Чтобы снизить риск забывания, я рекомендую не трогать базовую языковую способность модели, а доучивать адаптеры — меньше риск портить общие знания. Плюс, сильный трюк — миксовать примеры: часть чисто доменных, часть общеязыковых, часть с негативными примерами. Дисциплина разметки критична: если в данных есть «выбери правильное что» рядом с «что выберешь 1», модель начнёт копировать странные формулировки. Лучше вычистить, чем потом ловить рваные ответы.
Fine-tuning — это про «делать одинаково хорошо». Не путайте с «знать всё» — это всё-таки к RAG.
Завершая блок, обозначу типовые задачи, где дообучение — золотой стандарт: стиль корпоративной переписки, конвертация свободного текста в фиксированный JSON, классификация обращений и маршрутизация, извлечение доменных сущностей, составление отчётов по жёсткому шаблону. Актуальные факты туда подтянем retrieval-ом — чуть позже покажу, как это сводится в гибрид.
Гибридный путь: дружим RAG и fine-tuning без конфликтов
Самое рабочее сочетание — обучить модель устойчивому поведению и тону, а знания доставлять retrieval-ом. Такой гибрид часто называют RAFT, но названия не важны. Важно, что в одном запросе мы совмещаем два действия: ищем опорные фрагменты в источниках, а затем просим модель, которая уже умеет писать как мы и соблюдать форму, собрать ответ и сослаться на документ. В результате получаем и актуальность, и предсказуемость. А ещё — удобную трассировку для аудита: видно, откуда взялась каждая цифра.
Технически это выглядит так. На входе — классификатор намерения определяет, нужен ли retrieval. Если нужен — векторный поиск, ранжирование, подготовка контекста. Если не нужен — сразу генерация от fine tuned модели по шаблону. Обе ветки завершаются проверкой: есть ли обоснование, не нарушена ли политика безопасности, не вытекли ли персональные данные. В конце — приведение к формату ответа и запись лога для метрик. В n8n эта развилка собирается в два-три узла, выглядит аккуратно и понятно любому аналитику.
Мой фаворит в гибриде — навыки с узким шаблоном и ссылками. Например, ответ поддержки: первый абзац — короткая персонализация человеком, второй — факты из базы с ссылками, третий — следующий шаг. Там fine-tuning держит тон и структуру, а RAG даёт актуалку. Если часть данных чувствительна по 152-ФЗ, мы добавляем редактирование: вычёркиваем и маскируем поля до того, как что-либо попадает в модель. Это и есть моя «white-data-зона», здесь я спокойна.
И ещё нюанс из жизни. Иногда у вас появится соблазн слить всё в одну модель — и формат, и знания, и поиск, и ответы. Я пробовала, я тоже думала, что так будет проще. Нет, лучше так: навыки отдельно, retrieval отдельно, логика в оркестраторе. Становится ремонтопригодно и предсказуемо по затратам. Плюс ребята из ИТ-рисков меньше морщатся, когда видят чёткий граф прохождения данных и понятные журналы событий.
С этой картой в голове имеет смысл перейти к конкретным инструментам и показать, как собрать такую систему из доступных блоков. Как раз к n8n и Make.com.
Инструменты и архитектуры на n8n и Make.com
Я строю такие вещи на двух оркестраторах — n8n и Make.com. Оба позволяют собрать читаемые пайплайны без лишней экзотики, в которых аналитик видит, откуда пришли данные и куда ушли. В российской реальности к ним обычно добавляются Telegram-боты, корпоративные порталы, Confluence или Notion, плюс векторная база вроде Qdrant или pgvector. Важно, что всё это живёт в понятной инфраструктуре и не конфликтует с требованиями к персональным данным.
Вариант для RAG. В n8n я делаю поток, который по расписанию выкачивает источники, нормализует текст, режет на чанки и отправляет в векторное хранилище. На запрос пользователя работает ветка поиска: эмбеддинг запроса, топ-k ближайших фрагментов, фильтрация по дате и правам доступа, сборка контекста и генерация ответа с цитатами. Логи уходят в базу, чтобы мерить точность и groundedness. На Make.com схема похожая, просто узлы называются иначе, зато удобно подключать SaaS без собственного кода.
Вариант для fine-tuning. Мы готовим датасет: параллели «вход-выход», негативные примеры, жёсткие шаблоны. Затем дообучаем модель с адаптерами, проверяем на валидации, оборачиваем в сервис и вызываем из n8n. Узлы оркестратора добавляют проверку форматности, постпроцессинг, JSON-схемы. Классика — конвертация свободного текста в стандартизированный объект, который потом уходит в ваш бэкофис.
Гибридная схема. В начале стоит классификатор намерений, затем развилка: ветка retrieval или ветка навыка. В конце — слой проверки политики безопасности: маскирование PII, стоп-слова, контроль длины и источников. В нодах n8n это пара блоков с регулярками и простыми правилами, но эффект огромный: сразу меньше инцидентов и меньше нервных тикетов. Если видите в логах странные слова вроде rag bone human, rag n man или rag bone man — это не утечка, а шум из пользовательских запросов, часто смешные SEO-хвосты. Фильтруем и идём дальше.
В итоге вся конструкция выглядит не сложнее, чем хорошая ETL-схема: источники, нормализация, индекс, retrieval, генерация, проверка и логирование. На практике всё решают аккуратность в данных и дисциплина обновлений. Оркестратор тут как спокойный диспетчер — даёт увидеть, где у вас узкое место и куда утекают лишние минуты.
Как мерить качество и не обманывать себя
Если у вас нет метрик, у вас нет системы — только надежда. Для RAG я начинаю с трёх чисел: доля ответов с корректной ссылкой, доля релевантных фрагментов в топ-k и частота галлюцинаций. Дополняю временем ответа и стоимостью на запрос. Для fine-tuning базовые метрики — точность по шаблону, полнота по извлекаемым полям, стабильность формата, доля перегенераций. В гибриде добавляю долю правильной развилки: когда классификатор верно определил, что нужен retrieval, а не навык.
Нужен и ручной контроль качества. Я собираю набор золотых вопросов: 30-50 штук на разные сценарии, где есть эталонные ответы. Там специально встречаются формулировки уровня выберите правильный ответ что и найдите вероятность того что случайно выбранная запись будет соответствовать критерию, чтобы проверять устойчивость к шаблонным задачам. Этот набор гоняется по расписанию, а результаты попадают на дешборд. Один взгляд утром — и видно, где у нас просел индекс или забылся шаблон.
Отдельно слежу за дрейфом стоимости. В гибриде соблазн высок: чем больше контекста подсовываем, тем дороже запрос. Тут спасает дисциплина топ-k и сжатие контекста: не тащим всё подряд, выбираем 3-5 фрагментов, а не 15. Ещё помогает заранее фиксировать верхнюю границу времени ответа, чтобы пользователи не видели вечного «думаю» в интерфейсе бота.
Метрики — это зеркало. Если в нём мутно, дело не в зеркале. Нужно протереть данные и пересобрать пайплайн.
Про честность цифр. Легко накрутить метрики, если тестовые вопросы похожи на тренировочные образцы. Поэтому держите отложенный набор, меняйте его раз в месяц и следите, чтобы там были редкие запросы. В RAG они больше всего оголяются — и это хорошо, сразу видно, где не хватает источников или где чанкинг режет смыслы.
Когда всё это заведено, люди перестают спорить «чей подход лучше» и начинают обсуждать видимые числа: что поменяли в индексаторе, кому чинить адаптер, почему выросла стоимость на запрос. Тихая профессиональная радость, никакой магии, только работа.
Подводные камни: данные, закон, деньги и безопасность
Начну с очевидного — данные. В RAG источники быстро стареют, если нет расписания обновлений. Обновляйте индексы как минимум раз в сутки, а лучше по событию: изменился регламент — переиндексировали соответствующую коллекцию. Следите за чанкингом: слишком мелко — потеря контекста, слишком крупно — слишком дорогой запрос и токсичный контекст. Поддерживайте версии документов, чтобы можно было ответить на спорный вопрос: откуда взялся этот совет и когда документ обновлялся.
Теперь про закон и этику. В нашей реальности 152-ФЗ — это не страшилка, а норма. Маскируйте PII ещё до того, как текст попадёт в модель, храните только белые данные, ведите журнал запросов и результатов. Делайте трейсинг: для любого ответа должно быть видно, какие куски данных использовались. Это не только про контроль, это про доверие пользователей. Я настаиваю на белой зоне именно потому, что иначе всё хорошее рушится о реальность.
Деньги и производительность. В гибриде легко незаметно удвоить чек, если релевантность низкая и вы гоняете длинные контексты. Повышайте качество эмбеддингов, ограничивайте топ-k, внедряйте политику цитат. Для fine-tuning следите, чтобы модель не перетренировалась на узком датасете — держите отложенную валидацию и не стесняйтесь откатываться. Иногда достаточно частичного fine tuning обучения с адаптерами, чтобы не тянуть полный цикл.
Безопасность и атаки. Prompt injection — реальная штука. В retrieval нужно фильтровать источники и не давать модели исполнять инструкции из документа. В hybrid — проверять, что в контексте нет вредных подсказок. Простой детектор правил и стоп-слов на входе и выходе закрывает 80% рисков. Остальное — дисциплина доступа к источникам и регулярные ревью.
Самая дорогая ошибка — не техническая, а организационная. Когда непонятно, кто отвечает за источник, индексы и метрики. Назначьте владельцев.
И ещё маленькая заметка. В логах иногда встречается мусор вроде rag n, rag n bone, rag bone human. Это не про нас, это следы поисковых привычек. Фильтр в один узел решает, зато команда не путает RAG с Rag’n’Bone Man. Улыбнулись — и вернулись к делу.
Практические шаги для запуска
Чтобы не расплываться, собрала короткий план, по которому можно пройтись даже в небольшом проекте. Пункты кажутся простыми, но именно они экономят недели. Я бы сказала, что это мой минимальный чек-лист перед тем, как нажать «пустить в прод» (поймала себя, подумала, нет, лучше так — «включить расписание»).
- Сформулируйте вопрос выбора: ответ опирается на внешний источник или на навык. Если источник — идём в RAG, если навык — в fine-tuning. Если и то, и другое — гибрид.
- Соберите белые источники. Нормализуйте формат, заведите версии, настройте расписание обновления индекса. Добавьте метку доступов, чтобы retrieval не видел лишнего.
- Подготовьте датасет для навыков. Не меньше 300-500 примеров на один тип задачи, с негативными примерами и жёсткими шаблонами. Разделите на train, dev, test.
- Соберите оркестрацию в n8n или Make.com. Развилка намерений, ветка retrieval, ветка навыка, слой безопасности и слой логирования. Проверьте, что ошибки ловятся и сохраняются.
- Заведите метрики и дешборд. Groundedness, точность, время ответа, стоимость запроса, доля правильной развилки. Проверка каждый день первой неделе, потом — раз в неделю.
- Прогоните золотой набор вопросов. Включите редкие кейсы и формулировки вроде выберите правильный ответ что, чтобы увидеть границы устойчивости.
- Запустите мягко. Сначала ограниченная группа, потом расширение. Собирайте обратную связь и логи, замеряйте экономию времени.
- Обслуживайте. Расписание переиндексации, обновление датасета, ревью шаблонов. Плюс аудит доступа к источникам и проверка 152-ФЗ.
Если идти по этим шагам, вы увидите, как система становится предсказуемой и прозрачной. Это та самая тёплая уверенность, ради которой мы всё затеяли.
Что уносить с собой после чтения
RAG и fine-tuning — не конкуренты, а инструменты для разных задач. RAG приносит актуальность и снижает галлюцинации, когда ответ должен опираться на свежий документ или базу. Fine-tuning делает поведение модели устойчивым, когда важны формат, стиль и доменные навыки. В гибриде мы разводим роли: retrieval достаёт факты, дообученная модель собирает ответ в нужной форме и тоне. Всё это хорошо живёт на оркестраторах вроде n8n и Make.com, где можно прозрачно разложить по узлам источники, проверки и метрики.
Ключ — дисциплина. Белые данные, версии документов, регулярные обновления индексов, чистые датасеты, понятные метрики. На таком фундаменте исчезает соблазн «подкрутить промпт» и появляется здоровая инженерия. Если коротко, выбирать стоит по простому правилу: нужен внешний источник — RAG, нужен навык — fine-tuning, нужна зрелость — оба, с чистыми границами. И помните про жизненную мелочь: лучше один спокойный дешборд каждое утро, чем десять восторженных демо без цифр.
Хочется продолжить спокойно и предметно
Если хочется структурировать эти знания под свои процессы и собрать понятный пайплайн на n8n или Make.com, у меня на сайте есть развёрнутые заметки и схемы, без лишнего шума — загляните на promaren.ru. А тем, кто любит практику, кейсы и разборы нестандартных связок с RAG, fine-tuning и ИИ-агентами, будет комфортно в моём телеграм-канале t.me/promaren — там я делюсь находками и аккуратными экспериментами. Спокойный ритм, белые данные, прозрачные метрики — ровно то, чем я живу в проектах.
Частые вопросы по этой теме
Как понять, что мне нужен именно RAG
Если ответ должен ссылаться на актуальный документ или данные, которые меняются, это RAG. Если без внешнего источника модель не способна сказать правду, тоже RAG. Простой тест: можно ли обновить ответ без обучения модели — тогда retrieval.
Когда без fine-tuning не обойтись
Когда задача про устойчивый навык: стиль письма, строгий формат, классификация, извлечение сущностей по правилам. Если промпт работает, но «плавает», дообучение закрепит поведение и снизит количество перегенераций.
Можно ли обойтись гибридом сразу
Да, но лучше начать с развилки намерений. Там, где нужен источник, включайте RAG, где нужен навык — fine-tuning. Когда оба блока стабильны, соединяйте. Так меньше рисков и понятнее метрики.
Какие инструменты выбрать для векторного поиска
Часто хватает Qdrant или PostgreSQL с pgvector. Важно качество эмбеддингов и дисциплина обновлений индексов. Для небольших проектов и прототипов этого более чем достаточно.
Как не нарушить 152-ФЗ
Редактируйте и маскируйте персональные данные до передачи в модель, храните только белые источники, ведите журнал событий. Делайте ревью доступа к данным и трейсинг ответов. Это несложно, если заложить с самого начала.
Какие метрики считать первыми
Для RAG: релевантность извлечения, доля ответов с корректной ссылкой, частота галлюцинаций, время ответа, стоимость на запрос. Для fine-tuning: точность по шаблону, полнота, стабильность формата, доля перегенераций.
Что делать, если в логах много мусорных запросов
Фильтруйте по стоп-словам и простым правилам в оркестраторе, ведите статистику, чтобы не тратить ресурсы впустую. Отдельно проверяйте, не влияeт ли мусор на индекс и на стоимость контекстов.
Метки: ai-agents, rag, контент-план