Архитектура AI-чатбота для SaaS: RAG, Fine-tuning, Hybrid

Если промахнуться с архитектурой AI-чатбота в SaaS, вы месяцами будете латать халлюцинации, жалобы саппорта и непредсказуемую стоимость токенов. Это не про «магию LLM», а про дисциплину: правильный пайплайн данных, инженерный контроль и измеряемые метрики качества/стоимости.

Короткий ответ: для большинства SaaS RAG — базовый слой, который даёт быструю адаптацию к вашей базе знаний. Fine-tuning добавляют, когда нужна устойчивая стилевость, надёжное следование политикам и тонкая подстройка инструментов. Гибрид (RAG + лёгкий fine-tune + маршрутизация) нужен в доменах с тяжёлой предметной областью и высокими требованиями к консистентности. Ниже — схемы, стек и производственные компромиссы.

Карта задач чатбота в SaaS

Прежде чем спорить «RAG vs fine-tuning», зафиксируем типы задач:

• Поддержка клиентов по вашей документации и доменной базе знаний.
• Пошаговые рабочие процессы: настройка аккаунта, импорты, интеграции.
• Доступ к данным продукта: отчёты, аналитика, статус задач (функциональные вызовы / tool calling).
• Охрана контента: соблюдение тона, политик, комплаенса.

Ключевые метрики:

• Точность ответа: offline eval (precision/recall по эталонам), online «полезно/не полезно», deflection rate (сколько тикетов ушло без человека).
• Стоимость: стоимость на диалог и на сессию (встроенная формула: входные токены + выходные токены + retrieval/перегенерации).
• Задержки: p95, p99; особенно при цепочках инструментов.
• Надёжность: доля ответов без обращения к оператору при сложных сценариях, доля детерминированных JSON-результатов.

Совет: начните с формализации «классов запросов» (Q-классы): информационные (FAQ), задачные (вызови API), аналитические (собери отчёт), эскалационные (перешли в саппорт). Это поможет маршрутизировать запросы и замерять качество отдельно по каждому классу.

Архитектура RAG в продакшене

RAG (Retrieval-Augmented Generation) остаётся самым быстрым способом «научить» LLM вашей базе знаний без переподготовки модели.

Базовый пайплайн

• Инжест: забираем документы (доки, changelog, тикеты, Jira/Confluence/Notion, базы SQL).
• Нормализация: чистим HTML, генерируем canonical-версии, резолвим ссылки и версии продукта.
• Чанкинг: 300–800 токенов (по домену), с overlap 10–20% для сохранения контекста.
• Эмбеддинги: например, OpenAI text-embedding-3-large, bge-m3; храним L2-нормализованные в pgvector или специализированном векторном хранилище (Pinecone, Weaviate, Qdrant).
• Ретрив: топ-k семантических кандидатов + переранжировка кросс-энкодером (Cohere Rerank, bge-rerank), возможно self-query retrieval (извлечение по структуре).
• Конструирование промпта: инструкция + контекст + цитаты с источниками + политики тона и отказов.
• Генерация: GPT-4o/Claude 3.5/Llama 3 70B (через vLLM) в зависимости от конфиденциальности и бюджета.
• Постпроцессинг: структурированные форматы (JSON schema), ссылка на источники, контроль длины.
• Телееметрия: логирование латентности, стоимости, решений маршрутизатора, результат переранжировки.

Ниже — минимальный пример на Postgres+pgvector, TS-скелет для запроса + ретривала + LLM.

-- Подготовка Postgres
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE IF NOT EXISTS docs (
  id BIGSERIAL PRIMARY KEY,
  content TEXT NOT NULL,
  metadata JSONB,
  embedding VECTOR(1536) -- подберите размер под выбранную модель эмбеддингов
);

-- Индекс
CREATE INDEX IF NOT EXISTS idx_docs_embedding ON docs USING ivfflat (embedding vector_cosine_ops);

// pnpm add pg openai zod
import { Client } from 'pg';
import OpenAI from 'openai';
import { z } from 'zod';

const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY! });
const pg = new Client({ connectionString: process.env.DATABASE_URL! });
await pg.connect();

async function embed(text: string): Promise<number[]> {
  const res = await openai.embeddings.create({
    model: 'text-embedding-3-large',
    input: text
  });
  return res.data[0].embedding as unknown as number[];
}

async function retrieve(query: string, k = 8) {
  const qvec = await embed(query);
  const rows = await pg.query(
    'SELECT content, metadata, 1 - (embedding <=> $1::vector) AS score FROM docs ORDER BY embedding <=> $1::vector LIMIT $2',
    [qvec, k]
  );
  return rows.rows as { content: string; metadata: any; score: number }[];
}

const AnswerSchema = z.object({
  answer: z.string(),
  sources: z.array(z.string()).max(5)
});

async function answer(query: string) {
  const hits = await retrieve(query, 8);
  const context = hits.map((h, i) => `# Doc ${i+1}\n` + h.content).join('\n\n');
  const prompt = `Ты ассистент по продукту. Отвечай только на основе КОНТЕКСТА.\n` +
    `Если ответа нет в контексте — скажи «не нашёлся ответ» и предложи создать тикет.\n` +
    `Формат ответа — JSON: {"answer": string, "sources": string[]}\n\nКОНТЕКСТ:\n${context}\n\nВОПРОС: ${query}`;

  const chat = await openai.chat.completions.create({
    model: 'gpt-4o-mini',
    messages: [{ role: 'user', content: prompt }],
    temperature: 0.1
  });

  // Простая валидация
  const raw = chat.choices[0].message.content ?? '{}';
  const jsonStart = raw.indexOf('{');
  const json = JSON.parse(raw.slice(jsonStart));
  return AnswerSchema.parse(json);
}

answer('Как включить SSO в тарифе Business?')
  .then(console.log)
  .catch(console.error);

Практические детали:

• Для мультиарендности разделяйте коллекции по tenant_id и добавляйте фильтры в запросе, чтобы исключить утечки межу клиентов.
• Переранжировка часто поднимает точность на 5–10 п.п. относительно одного семантического поиска (оффлайн-оценка по вашим наборам вопросов). Если Latency критичен — делайте её асинхронной или на меньшем кросс-энкодере.
• Кэшируйте ответы для частых FAQ и используйте семантический кэш (например, Redis с HNSW-плагином или отдельный слой Qdrant на быстрых NVMe).
• При потоковой генерации через SSE/WebSocket контролируйте «задержки первого байта» — p50 < 600 мс заметно улучшает восприятие.

Fine-tuning: когда переподготавливать модель

Fine-tuning пригодится, когда нужно:

• Последовательный стиль бренда и строгие политики (например, не обсуждаем дорожную карту, не даём юридических советов).
• Устойчивое «следование инструментам»: модель должна надёжно вызывать функции API вашего продукта, распознавать классы запросов и заполнять JSON без галлюцинаций.
• Доменно-специфические форматы (SQL-генерация под ваш диалект, нестандартные единицы измерения, сложные DSL).

Как подойти:

• Данные: выгрузите хорошие диалоги с метками «полезно/неполезно», добавьте золотые примеры правильного tool-calling (параметры, валидации, пограничные кейсы). Уберите PII или зашифруйте.
• Тип тренировок: SFT (supervised fine-tuning) на инструкциях +, при необходимости, DPO/ORPO для смещения к полезным ответам без тяжёлого RLHF. Лёгкие адаптеры: LoRA/QLoRA на Llama 3 8B/13B — хорошая стартовая точка, которую можно держать on-prem.
• Шаблон промпта: фиксируйте system-промпт и формат I/O (JSON schema), чтобы не переучивать «всё». Fine-tune должен усиливать следование правилам, а не заменять retrieval.
• Serving: vLLM/Inference Endpoints, автоскейл по RPS. Для on-prem — A100/L40S, для облака — серверлесс GPU под пиковые окна.

Компромиссы: fine-tune быстрее и дешевле в рантайме при переходе на меньшую модель (дистилляция), но требует непрерывного MLOps — датасеты версионировать, метрики не отклеивать от онлайна, артефакты хранить с чекпоинтами. Ещё и юридически: если дообучаете на пользовательских данных — проверьте лицензию и DPA.

Гибрид: RAG + тонкая подстройка + маршрутизатор

Гибридная схема чаще всего выглядит так:

• Роутер (классификатор запросов) решает: «достаточно ли RAG» или нужно «инструмент/аналитика/эскалация». Это может быть небольшая модель-классификатор или тот же LLM со strict JSON-ответом.
• Если информационный запрос — RAG c переранжировщиком. Если задачный — tool calling (API продукта), а затем суммаризация результата кратким ответом. Если аналитический — генерация SQL/полей фильтра и повторный запуск.
• Fine-tuning используется для устойчивой «процедуры» (инструменты, шаблоны ответов, форматирование) и для снижения стоимости на потоке задач с предсказуемым паттерном.
• Защитный слой: детектор промпт-инъекций и конфиденциального контента, плюс политики отказов.

Текстовая схема потока:

Пользователь → Роутер (JSON-классификация) →

• Ветка A: RAG (ретривер → переранжировка → LLM) → Ответ + ссылки
• Ветка B: Tool-calling (LLM → функции продукта → LLM) → Ответ/JSON
• Ветка C: Эскалация (формирование тикета) → Человек

Секрет результата не в «большой модели», а в аккуратной декомпозиции. Мы регулярно видим, как избыточные LLM-запуски в цепочке съедают бюджет и добавляют флеки. Маршрутизатор + телеметрия спасают.

Сравнение подходов

Примечание: «время запуска» — про инженеринг. «Стоимость рантайма» — складывается из токенов LLM, эмбеддингов (разово/по крону) и хранения векторов.

Что ломается в продакшене

• Контекст переполняется: без строгих лимитов и rerank модель тащит лишнее. Итог — длинные ответы, рост стоимости и снижение точности.
• Векторное хранилище пухнет: дубликаты версий доков, отсутствие дедупликации и TTL. Введите хеширование чанков, версии, soft-delete.
• Мультиарендность: забыли фильтр tenant_id — утечки между клиентами. Тестируйте контекст на «чужих» данных, ставьте политики на уровне SQL.
• Rate limits и холодные старты GPU/серверлесс: всплески RPS лягут на самое узкое место. Держите тепловые пулы и реже вызывайте LLM (кэш, ранние отказы).
• Инструменты нестабильны: плохие таймауты и ретраи в tool calling рушат UX. Отдельно версионируйте контракт функций.
• Промпт-инъекции и data exfiltration: фильтруйте ввод (регексы мало помогают), используйте контент-фильтры и строгое «отвечай только по контексту». Логи анонимизируйте.
• Оценка «слетает»: оффлайн-метрики обещают одно, а онлайн — другое. Вводите A/B и тревоги на падение полезности/дефлекшна. По теме архитектурных сдвигов уместно почитать наш разбор как LLM ломаёт привычный системный дизайн.

Операционные мелочи (но бьют по деньгам): как только заведёте runbook — убедитесь, что он исполняется. Иначе он живёт только в Notion. По культуре исполнения см. ваш ранбук написан — никто его не запускает.

Стоимость и ROI: что закладывать в бюджет

Не называя конкретных цен за токены (они меняются), разложим компоненты стоимости и подход к окупаемости:

• Инженеринг (единовременно):
  • MVP (RAG, базовый ретривер, один провайдер LLM, фронт-чат, метрики): 4–6 недель, 2 инженера (бекенд/ML + фронт), продакт на полставки.
  • Гибрид, инструменты, маршрутизатор, оффлайн-оценка с наборами эталонов: ещё 4–8 недель.
  • Fine-tuning (подбор датасета, пайплайн, обучение, валидация, деплой): 2–6 недель, зависит от объёма и комплаенса.
• Рантайм (повторяющаяся):
  • LLM-вызовы: пропорционально токенам. Ввод и вывод можно сокращать агрессивной прунингом контекста и сжатием промпта.
  • Эмбеддинги: платите при обновлении данных (полный инжест или инкремент). Планируйте дедупликацию.
  • Хранение векторов и телеметрии: учитывайте рост коллекции и бэкапы.
• Скрытые издержки:
  • Модерирование/комплаенс: фильтры, ручная проверка спорных кейсов.
  • Поддержка оценок качества и датасетов: это вечная статья расходов, иначе качество упадёт к моменту, когда вам это будет особенно неудобно.

Как считать ROI:

• Прямые выгоды: снижение нагрузки на саппорт (deflection), ускорение онбординга, рост конверсии в продукте (помощь в фичах), апсейл/кросс-сейл в чате.
• Косвенные: удержание (меньше фрустрации), бренд (качественные ответы), разработка быстрее за счёт ассистента для внутренних команд.
• Формула на салфетке: (сэкономленные часы саппорта × ставка + доп. выручка от апсейла) − (рантайм + инженеринг/амортизация). Сверяйте ежемесячно.

Пошаговый план внедрения за 30–60 дней

• Недели 1–2: аудит базы знаний, настройка инжеста, чанкинг, эмбеддинги, базовый RAG с Postgres/pgvector и одним LLM. Собираем телеметрию и семантический кэш.
• Недели 3–4: оффлайн-eval (100–300 эталонных вопросов), переранжировка, строгий формат JSON для ответов, базовый роутер классов запросов, подключение 1–2 инструментов (например, «получить статус счета»).
• Недели 5–6: гибридизация — усиливаем роутер, добавляем guardrails (инъекции, PII), вводим A/B, готовим датасет для fine-tune (стиль, tool calling), обучаем лёгкий адаптер на open-source модели и сравниваем стоимость/качество с базовой.
• Недели 7–8: оптимизация стоимости: уменьшение токенов промпта, сжатие контекста, кэш, fallback-модели (дешёвая по умолчанию, дорогая при неуверенности). Документы по инцидентам и SLO.

В один из дней закладывайте время на «уборку долгов»: выверка метаданных, нормализация чанков, бенчмарк ретриверов на свежем корпусе. Это скучно, но экономит месяцы (и нервы).

Когда что выбирать: практические сценарии

• Молодой SaaS с живой документацией, NPS зависит от быстрой поддержки: стартуйте с RAG, добавьте переранжировщик и строгие отказы «не знаю» вне контекста.
• Продукт с богатым API в чате (создание задач, отчётов, экспорта): гибрид — роутер + инструменты + RAG для пояснений. Fine-tune на tool calling.
• Enterprise-домен с политиками, юридическими ограничениями, аудитами: гибрид + fine-tune для соответствия стилю/комплаенсу, on-prem inference, строгие логи.
• Высоконагруженный B2C-вход: дистиллированная модель с fine-tune для дешёвых частых сценариев, с эскалацией на большую модель при неуверенности.

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

FAQ

• Что выбрать для MVP: RAG или fine-tuning?

  • В 90% случаев — RAG. Он быстрее запускается, знания обновляются через инжест. Fine-tuning добавляйте позже для стиля и инструментов.

• Нужен ли векторный сервис или хватит Postgres с pgvector?

  • Для старта и среднего объёма — pgvector плюс нормальные индексы и фильтры. При росте до десятков миллионов чанков/тенантов — рассмотрите специализированное векторное хранилище.

• Как уменьшить галлюцинации?

  • Строгие инструкции «только по контексту», короткий и релевантный контекст (rerank), temperature ~0–0.2, жёсткий формат JSON и проверки. Плюс отказ «не знаю» как допустимый исход.

• Когда оправдан гибрид?

  • Когда у вас есть и «глубокие знания» (доки/домены), и процедурные шаги (вызовы API), и требования к консистентности/тону. Роутинг + RAG + fine-tune — золотая середина.

• Как оценивать качество?

  • Оффлайн-наборы вопросов с метками, автоматические метрики (nDCG/Recall@k для ретрива, структурная валидность JSON), онлайн-сигналы (thumbs, deflection, повторные вопросы). A/B must-have.

• Можно ли обойтись без переранжировщика?

  • Можно, но вы теряете точность на неоднозначных запросах. Компромисс — включать rerank только при низкой уверенности семантического поиска.

Ключевые выводы

• Стартуйте с RAG: это быстрый baseline, который масштабируется и легко обновляется.
• Fine-tuning добавляйте для стиля, политик и надёжного tool calling; держите датасеты и метрики в порядке.
• Гибрид (роутер + RAG + инструменты + лёгкий FT) — рабочий стандарт для зрелого SaaS.
• Производственные риски: контекст-спам, мультиарендность, инъекции, холодные старты, дрифт качества — планируйте заранее.
• Бюджетируйте не только LLM-токены, но и data/ops: инжест, кэш, оценку качества и наблюдаемость.

Если вы строите SaaS-чатбот с RAG, fine-tuning или гибридной архитектурой — MTBYTE помогает спроектировать пайплайн, выбрать стек, собрать MVP за 4–8 недель и довести до продакшен-SLO. Напишите нам через /contact — обсудим, что окупится быстрее именно у вас.