● Архитектура / Уровень: базовый / Q2 · 2026 / 03 из 90

RAG.

поиск + генерация по корпоративной базе
Короткий
ответ
RAG (Retrieval-Augmented Generation) — это паттерн «поиск + LLM». Модель не пытается помнить ваши документы — она ищет нужные куски в базе, кладёт их в контекст и отвечает по ним со ссылками. Главная альтернатива дорогому fine-tuning.

01 Зачем нужен RAG

Проблема: вы хотите, чтобы LLM отвечала про ваши процессы, контракты, продукты. Но «голая» модель про это ничего не знает — она училась на интернете до 2024 года. Два пути:

  1. Fine-tune модель на своих данных. Дорого (тысячи долларов), устаревает с каждой сменой модели, не отвечает с цитатами.
  2. RAG. Загружаете свои документы в векторную базу, на каждый запрос ищете релевантные куски и подкладываете в промпт. Дёшево, обновляется в реальном времени, отвечает с пруфами.

В 95% бизнес-задач выбираем RAG. Fine-tuning — только когда RAG объективно не справляется (узкий жаргон, специфический стиль).

02 Как работает RAG-пайплайн

Стандартный пайплайн состоит из двух фаз:

Indexing (один раз)

  1. Chunking. Документы режутся на куски ~500-1000 токенов.
  2. Embedding. Каждый кусок превращается в вектор через модель эмбеддингов.
  3. Загрузка в vector DB (Qdrant, Pinecone, pgvector).

Retrieval + Generation (на каждый запрос)

  1. Запрос пользователя → эмбеддинг → поиск top-N похожих кусков.
  2. (Опционально) Reranker переранжирует — оставляет top-5.
  3. Куски кладутся в системный промпт LLM. Модель отвечает + указывает источники.

03 Где применяется в бизнесе

  • Внутренний справочник. Сотрудник спрашивает «как оформить отпуск?» — ассистент находит регламент и отвечает со ссылкой.
  • Поддержка клиентов L1. База FAQ + история тикетов → 60-80% запросов закрывает агент.
  • Юристы. «Что писали в договоре с X про штрафы?» — ассистент находит все упоминания в архиве.
  • Sales enablement. Менеджеру нужен ответ на вопрос клиента → ассистент находит в product docs + презентациях.
  • Onboarding. Новый сотрудник задаёт вопросы 24/7 — ассистент учит на корпоративной базе.

04 Подводные камни

  • Качество retrieval. Если плохо чанкуете или эмбеддинги слабые — модель отвечает по релевантному мусору. Главный точка для оптимизации.
  • Стоимость токенов. Каждый запрос несёт 3-10K токенов контекста. На 10К запросов в день — заметные деньги.
  • Свежесть данных. Кто-то обновил документ → надо переэмбедить. Нужен авто-пайплайн.
  • Permissions. RAG не должен показывать пользователю чужие документы. Фильтр по правам — на уровне retrieval.

05 Когда RAG не нужен

  • База маленькая (десятки документов). Можно просто положить всё в промпт — современные модели держат 200K+ токенов.
  • Задача — рассуждение, а не факт. «Спланируй стратегию» — RAG не поможет, нужна reasoning-модель.
  • Данные мультимедийные (видео, аудио без транскриптов). Сначала нужен Whisper + индексация транскриптов.
// 08

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

01 RAG или fine-tuning — что выбрать?

Начинайте с RAG. Он дешевле, гибче, отвечает с цитатами и обновляется мгновенно. Fine-tuning берите только если RAG объективно не справляется со специфическим жаргоном.

02 Сколько стоит запустить RAG?

MVP на 1000 документов — ₽200-500 тыс. за разработку + ₽3-15 тыс./мес. на инфраструктуру. На Team-программе учим вашу команду делать самостоятельно.

03 Какую векторную базу взять?

Для старта — pgvector в PostgreSQL (бесплатно, в большинстве компаний уже есть). При нагрузке выше 1М векторов — Qdrant (open-source, on-prem) или Pinecone (managed).

04 Можно ли RAG без OpenAI/Claude?

Да. Llama 4 + локальные эмбеддинги — рабочая конфигурация для on-prem. Качество чуть ниже, но данные не уходят наружу.

05 Как контролировать качество ответов?

Через evals: набор из 50-100 пар «вопрос — правильный ответ», прогоняется при каждом изменении пайплайна.

Понимаем — учим
работать с RAG
внутри команды.

Час бесплатной диагностики: разбираем 2–3 ваших процесса и говорим прямо, где AI окупится за квартал, а где брать рано. Знания остаются у вашей команды.

Готовы поговорить?
@Aleksei_Shturbin Бот →