Запрос ко мне приходит примерно раз в неделю в одном и том же виде: «Нам нужен ИИ, обученный на наших данных. Чтобы знал нашу базу клиентов, наши продукты, наши инструкции. Только мы боимся 152-ФЗ, поэтому давайте локально». Дальше выясняется, что под «обучить ИИ» человек имеет в виду что-то среднее между fine-tuning и RAG, локально - это где-то на ноуте сисадмина, а 152-ФЗ боится скорее на всякий случай.

Разбираю по полочкам: чем RAG отличается от fine-tune, когда нужен локальный LLM, что реально требует 152-ФЗ и сколько это всё стоит в рублях.

Сначала про сам вопрос: что значит «обучить ИИ на наших данных»

За этим вопросом обычно стоит одна из трёх задач, и они решаются разными инструментами:

  • Бот должен знать наш ассортимент / прайс / FAQ. Тут не нужно никакого обучения. Нужен RAG или просто подсовывание в контекст.
  • Бот должен общаться в нашем тоне голоса. Это решается промптом и парой примеров. Не fine-tune.
  • Бот должен делать что-то нестандартное, чему публичные модели не обучены (специфический формат документов, узкий жаргон, редкий язык). Тут уже fine-tune может быть оправдан.

В 95% случаев бизнесу нужен пункт 1 или 2. Fine-tune на этой стадии - это пушка по воробьям. Дорого, медленно, и часто результат хуже, чем у обычного RAG.

RAG - что это и как работает

RAG - Retrieval-Augmented Generation. По-русски: поиск + генерация. Идея простая. У вас есть база документов (FAQ, инструкции, договоры, прайсы, история тикетов). Когда пользователь задаёт вопрос, система сначала ищет в базе релевантные куски (тут не классический поиск по словам, а поиск по смыслу - через эмбеддинги), вытаскивает топ-3-5 кусков, подсовывает их в контекст модели вместе с вопросом, и модель отвечает уже по этому контексту.

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

Что в этом не очень: качество ответа упирается в то, насколько хорошо ретривер находит правильные куски. Если в базе 10 тысяч документов и они плохо размечены - модель будет ловить нерелевантный контекст и отвечать мимо. Качество RAG - это 80% работа над данными и 20% работа над моделью.

Архитектура RAG в типовом проекте:

  • Хранилище документов (S3, файлы, выгрузка из 1С/CRM).
  • Парсер и chunker (режет документы на куски по 500-1500 токенов).
  • Эмбеддер (превращает кусок в вектор; в РФ обычно YandexGPT Embeddings, GigaChat Embeddings, либо локальные модели типа bge-m3).
  • Векторная база (Qdrant, Weaviate, pgvector). Для малого объёма (до 100 тысяч кусков) подойдёт даже sqlite.
  • LLM (YandexGPT, GigaChat, Claude через прокси, либо локальный Qwen / Llama).
  • Прослойка-оркестратор (LangChain, LlamaIndex или собственный код).

Подробнее про устройство ИИ-агента в целом, включая RAG как один из компонентов, я разбирал в статье про анатомию ИИ-агента. Архитектура та же, разница только в том, что чистый RAG - это один шаг (поиск-ответ), а агент может ходить в RAG как в инструмент несколько раз за диалог.

Fine-tuning - что это и когда правда нужен

Fine-tuning - это дообучение модели на ваших данных. То есть вы берёте готовую модель (например, Llama 3.1 8B или Qwen 2.5 7B) и продолжаете её обучать на своём датасете - примерах вопросов и ответов в нужном вам формате.

Когда это правда нужно:

  • У вас уникальный формат вывода, который сложно описать промптом. Например, разметка документов в специфичный JSON по ГОСТу.
  • Узкий жаргон, на котором публичные модели плохо ориентируются (медицинские термины, узкая инженерная область).
  • Очень тонкая стилистика, которую промптом не поймать (юмор бренда, специфическая интонация поддержки).
  • Хочется уменьшить размер промпта, чтобы экономить токены при тысячах запросов в день.

Когда не нужно:

  • Бот должен знать ваш ассортимент - RAG, не fine-tune.
  • Бот должен говорить «в нашем тоне» - промпт + 3-5 примеров, не fine-tune.
  • Бот должен ссылаться на ваши документы - RAG, не fine-tune.

Цена fine-tuning сильно зависит от модели и размера датасета. Для малого бизнеса в РФ это обычно 250-700 тысяч ₽ за подготовку датасета и тренировочный прогон, плюс расходы на инфраструктуру для инференса (от 30 тысяч ₽ в месяц на VPS с GPU). RAG в большинстве случаев укладывается в 150-400 тысяч ₽ под ключ и работает на копеечной инфраструктуре.

Локальная нейросеть - когда правда нужна

Тут самая болезненная часть. «Локально» в голове клиента - это всё что угодно: то на ноуте бухгалтера, то на сервере в офисе, то на VPS в РФ.

Реальная необходимость в локальной модели возникает, когда:

  • Вы правда работаете с чувствительными данными (мед.карты, ПДн в большом объёме, банковская тайна).
  • У вас есть требования регулятора (ФСБ, Минцифры) на не-передачу данных за периметр.
  • Вы оборонка, госорг или критическая инфраструктура.

Для типового SMB - интернет-магазина, агентства, строительной компании - локальный LLM обычно избыточен. Можно работать с YandexGPT или GigaChat - это российские модели в российском контуре, на российских серверах. С точки зрения 152-ФЗ это полностью валидно.

Если всё-таки нужно локально - это сервер с GPU (A100/H100 или хотя бы RTX 4090) и модель типа Qwen 2.5 7B / Llama 3.1 8B / YandexGPT-Lite (если есть лицензия). Минимальная конфигурация для прода - от 200 тысяч ₽ за железо или от 80 тысяч ₽ в месяц за аренду. Это серьёзное удорожание, поэтому идти на это надо осознанно, а не «на всякий случай».

152-ФЗ: что он реально требует и чего боятся зря

Это любимая страшилка. Реально 152-ФЗ требует не «не отправлять данные в нейросеть», а гораздо более скромных вещей:

  1. Согласие субъекта на обработку персональных данных. Если у вас уже подписано согласие на обработку (а оно подписано у любого клиента, который оставляет заявку), - 90% работы уже сделано.
  2. Локализация на территории РФ. Серверы, на которых хранятся ПДн граждан РФ, должны быть в РФ. Это касается базы. Если данные обрабатываются в YandexGPT (РФ) или GigaChat (РФ) - всё ок. Если отправляете в OpenAI напрямую - нет.
  3. Уведомление в Роскомнадзор об обработке ПДн. Это разовое уведомление, делается за день.
  4. Меры защиты: шифрование, контроль доступа, журналирование. Стандартный набор для любого нормального проекта.

То есть отправлять данные клиентов в YandexGPT или GigaChat - не нарушение 152-ФЗ. Это полностью легально, провайдер сам обеспечивает соответствие закону. Опасно отправлять напрямую в Claude, GPT, Gemini без прокладки - там данные уезжают за периметр РФ.

Решение для большинства задач: использовать YandexGPT/GigaChat для работы с ПДн, использовать Claude/GPT для работы с обезличенными данными (тексты без имён, статистика, документы без персональной информации). Это нормально работает и дешевле, чем поднимать локальную модель.

Что выбрать в каждом конкретном случае

Простая шпаргалка, к которой я возвращаюсь на каждом проекте:

  • Бот по FAQ для сайта. RAG поверх ваших инструкций + YandexGPT/GigaChat. От 80 тысяч ₽.
  • Бот для поддержки с историей клиента. RAG + интеграция с CRM + YandexGPT. От 200 тысяч ₽.
  • Бот, отвечающий по базе договоров. RAG + Claude (через прокси, на обезличенных данных). От 250 тысяч ₽.
  • ИИ-помощник по 1С. RAG поверх справочников 1С + LLM. Я отдельно разбирал этот сценарий. От 300 тысяч ₽.
  • Бот для медицинской компании / банка / госконтракта. Локальный Qwen или Llama на сервере с GPU. От 600 тысяч ₽ + железо.
  • Любой fine-tune. Сначала проверьте, не закроется ли задача через RAG. В 9 из 10 случаев - закрывается.

Где сэкономить, где не надо

Где экономия имеет смысл:

  • Не платить за GPU, если данные позволяют использовать YandexGPT/GigaChat.
  • Не делать fine-tune на старте - начать с RAG, дойти до его пределов и только тогда смотреть на дообучение.
  • Не покупать топовый эмбеддер, если задача типовая - bge-m3 или multilingual-e5 справляются для большинства русскоязычных кейсов.
  • Не платить за Qdrant в облаке, если у вас 5-10 тысяч документов - локальный экземпляр в Docker работает не хуже.

Где экономить не надо:

  • На chunker'е и парсере. Если документы плохо порезаны на куски - RAG будет находить мусор.
  • На разметке датасета. Качество вопрос-ответ напрямую влияет на качество поиска.
  • На безопасности. Один утечённый промпт с ключом доступа к 1С - и проект превращается в заголовок в новостях.

Про другие принципы экономии в ИИ-проектах подробно разбирал в гайде по внедрению ИИ-агента - там цифры применимы и к чистому RAG.

Что в итоге

«Обучить ИИ на данных компании» в 95% случаев - это RAG, а не fine-tune. RAG быстрее, дешевле, гибче и проще в поддержке. Fine-tune нужен в нишевых задачах, где промптом и контекстом задачу не закрыть.

Локальная модель нужна в редких сценариях с реально чувствительными данными или жёстким регулятором. Для большинства SMB достаточно YandexGPT или GigaChat - это российский контур, 152-ФЗ-совместимо, дешевле локального GPU в разы.

152-ФЗ не запрещает работать с нейросетями - он требует только согласия пользователя, локализации серверов и стандартных мер защиты. Если у вас всё это уже есть для обычной CRM - вы готовы и для ИИ.

Не начинайте проект с самой сложной архитектуры. Начните с RAG поверх 5-10 ключевых документов. Запустите. Посмотрите, где он проседает. Дальше уже добавляйте: больше данных в индекс, лучше chunker, опционально - fine-tune. Этот итеративный путь работает лучше любого «давайте сразу сделаем правильно».