Можно ли запустить RAG на локальной модели без передачи данных во внешнее облако?

Да. Мы разворачиваем Llama 3.3, Qwen 2.5 или Mistral на GPU-сервере заказчика. Embedding-модель тоже работает локально — данные не покидают контур компании. Актуально для банков, юриспруденции, государственных учреждений.

Чем RAG отличается от fine-tuning LLM?

Fine-tuning «запекает» знания в веса модели — дорого, долго, при каждом обновлении базы нужно переобучать. RAG передаёт нужные документы модели в момент запроса — дёшево, обновляется мгновенно, позволяет ссылаться на источник. В 95% бизнес-задач правильный выбор — RAG.

Как мерить качество RAG?

Базовые метрики: faithfulness (отвечает ли модель по тексту или фантазирует), answer relevancy, context precision/recall. Используем RAGAS и свою набор золотых вопросов (30–50 штук). Считаем метрики до и после каждого релиза.

Сколько времени занимает пилот?

От 3 до 4 недель при готовой базе документов. Основное время уходит не на код, а на парсинг, очистку и разметку источников — сами нейросети в 2026 ставятся за пару дней.

А если база документов закрытая — договоры, медкарты?

Работаем под NDA. Разворачиваем всё в контуре клиента, embedding и LLM локально, никаких внешних API. Можем пройти ваш аудит информационной безопасности — опыт есть.

RAG-системы для бизнеса: когда пора и как не наступить на грабли

К 2026 году словосочетание «RAG-система» перестало быть модным — это инструмент, который ставят себе юрфирмы, службы поддержки, внутренние базы знаний и маркетплейсы. При этом половина запусков выглядит так: потратили 800 000 ₽, получили ассистента, который уверенно врёт. Ниже — наш разбор, когда RAG реально нужен, как его собирать, и где все обычно ошибаются.

Что такое RAG и чем он отличается от «обычного» ChatGPT

RAG (retrieval augmented generation) — это архитектура, в которой LLM отвечает не из своей «памяти», а из конкретной базы документов клиента. Упрощённо схема выглядит так: пользователь задал вопрос → система ищет релевантные куски текста в корпоративной базе → LLM получает вопрос + найденные куски и генерирует ответ со ссылками на источники.

Ключевое отличие от обычного GPT: модель не придумывает факты, а пересказывает то, что нашла. Поэтому RAG подходит везде, где важна точность и цитируемость — договоры, регламенты, техподдержка, медицинские протоколы, каталоги товаров.

Когда RAG реально нужен, а когда нет

За два года мы запускали RAG для 14 компаний. Из них 3 — отказались после аудита: оказалось, задачу закрывает обычный поиск по сайту или FAQ. Признаки того, что RAG действительно оправдан:

У вас — 500+ документов разного формата (PDF, DOCX, XLSX, страницы Confluence), и менеджеры тратят 20+ минут на поиск нужной информации.
Информация регулярно обновляется: нельзя обучить модель один раз и забыть.
Требуются ссылки на источник ответа — регуляторика, юриспруденция, медицина.
Поток вопросов стабильный: 100+ обращений в день, на которые нужна консистентная формулировка.

RAG не нужен, если вопросов мало, база небольшая (<50 документов) и структура простая. В таких случаях дешевле написать FAQ-раздел и добавить полнотекстовый поиск — без нейросетей.

Архитектура RAG-системы: из чего она состоит

На верхнем уровне любой RAG складывается из шести слоёв:

Ingestion pipeline — извлечение текста из источников (PDF, Confluence, Notion, 1С, CRM, почта).
Chunking — нарезка документов на куски по 300–800 токенов с перекрытием. Стратегия нарезки влияет на качество сильнее, чем сама модель.
Embedding — преобразование кусков в векторы. Мы используем text-embedding-3-large от OpenAI для мультиязычных данных и multilingual-e5-large там, где нужна полная локальность.
Vector DB — хранилище векторов с быстрым поиском по косинусной близости. Базовый выбор: Qdrant, pgvector в PostgreSQL, Weaviate.
Retriever + reranker — поиск топ-20 кусков и переранжирование их кроссэнкодером. Без реранкера RAG «плывёт» на длинных базах — обязательный компонент.
LLM с промптом — финальная модель, которая получает контекст и формирует ответ. Для коммерческих данных обычно GigaChat, YandexGPT или локальная Llama 3.1 на закрытом контуре.

Как выбрать векторную базу

Первый вопрос, который мы задаём клиенту: «У вас уже есть PostgreSQL в проде?» Если да — в 80% случаев правильный ответ это pgvector. Это расширение для Postgres, которое добавляет тип vector и индекс HNSW. На базе до 2–3 млн векторов оно работает не хуже специализированных решений и не требует админить ещё один сервис.

Qdrant и Weaviate нужны, когда векторов становится больше 10 млн, или когда нужна продвинутая фильтрация по метаданным. Qdrant в 2026 году остаётся нашим выбором для среднего сегмента: написан на Rust, работает на 8 ГБ RAM с базой в миллион документов.

Какую LLM поставить в production

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

Облачные российские — GigaChat (Сбер) и YandexGPT. Отвечают на русском лучше зарубежных, соответствуют 152-ФЗ. Цена — 0,5–2 ₽ за 1000 токенов. Подходят для клиентского сервиса, каталогов, FAQ.
Локальные open-source — Llama 3.3 70B, Qwen 2.5, Mistral Large. Разворачиваются на GPU-сервере клиента (A100 или 2×RTX 6000 Ada). Актуально для юриспруденции, банков, медицины.
Гибрид — embedding локально, генерация через API. Самый частый вариант в 2026 году.

Типичные ошибки: что ломает RAG в 90% случаев

1. Игнорируют качество парсинга

Первая ошибка — «скормить» PDF напрямую через pypdf и удивляться галлюцинациям. Сложные документы с таблицами, сканами, формулами требуют отдельной обработки: Unstructured, LlamaParse или своё решение на основе OCR + layout-парсера. Иначе модель получает кашу и галлюцинирует на её основе.

2. Чанкуют «в лоб»

Фиксированная нарезка по 500 символов без учёта структуры — гарантия плохих ответов. Правильный подход — semantic chunking: разбивать по смысловым границам (заголовкам, абзацам, пунктам регламента) и добавлять контекст предыдущего блока в metadata.

3. Запускают без реранкера

Векторный поиск возвращает релевантные по форме, но не по смыслу результаты. Добавление cross-encoder для переранжирования топ-20 → топ-5 улучшает ответы на 30–40% по нашим метрикам. Используем bge-reranker-v2-m3 или jina-reranker-v2.

4. Нет обратной связи

RAG без thumbs-up/down в интерфейсе — это RAG, который никогда не улучшится. Мы логируем каждый запрос, ответ, использованные куски и оценку пользователя. Раз в две недели пересматриваем кейсы с плохой оценкой и дорабатываем промпт или структуру базы.

Сколько это стоит в 2026 году

Для понимания: ниже цифры по нашим проектам.

MVP (база до 1000 документов, облачная LLM, 1 интерфейс) — от 350 000 ₽, срок 3–4 недели. Сюда входит парсинг, chunking, pgvector, Python-бэкенд на FastAPI, виджет.
Production (10 000+ документов, гибридная архитектура, 2–3 интеграции с CRM/портал) — от 900 000 ₽, срок 2 месяца.
Enterprise (локальная LLM, несколько отделов, роли и права, SSO, SLA) — от 2 500 000 ₽, срок 3–5 месяцев.

Инференс в среднем обходится в 3 000–18 000 ₽/мес в зависимости от объёма запросов. Локальная LLM на GPU-сервере — от 70 000 ₽/мес за аренду или от 600 000 ₽ капекс за свой сервер.

Как мы работаем над RAG-проектами

Наш стандартный цикл:

Discovery (1 неделя). Собираем источники, размечаем типы документов, формулируем 30 реальных вопросов пользователей — на них будет считаться метрика качества.
Прототип (2 недели). Pgvector + облачная LLM + минимальный UI. Цель — подтвердить, что на ваших данных RAG даёт результат лучше Google/1С-поиска.
Production (1–2 месяца). Ingestion pipeline, оркестрация, мониторинг, роли, интеграции, бизнес-метрики.
Сопровождение. Раз в две недели — ретроспектива плохих ответов, обновление промпта и структуры базы, A/B-тесты.

Если вы уже задумывались про своего ИИ-ассистента по базе знаний — напишите нам, проведём бесплатный аудит: посмотрим на объём, форматы, сформулируем гипотезу и скажем честно, нужен ли вам RAG или достаточно обычного поиска.