RAG для малого бизнеса: подключить базу знаний к AI-боту за один день

В сентябре 2025 года я потратил 8 минут на поиск одного инвесторского контракта среди 47 файлов в Google Drive. На следующей неделе подключил RAG — тот же запрос закрывается за 4 секунды. Сегодня все 14 агентов Solar работают через единую базу знаний из 340 документов.

Это не обзор технологии. Это конкретный стек, конкретные цифры и список ошибок, которые я уже совершил за вас.

Если вы впервые слышите про RAG — нормально. Год назад я тоже думал, что это что-то из мира больших корпораций с дата-саентистами в штате. Оказалось, базовую реализацию запускает один человек за один рабочий день. Всё что нужно: папка с документами, OpenAI API-ключ и PostgreSQL. Всё остальное — 60 строк Python.

Что такое RAG и чем он отличается от загрузки файлов в ChatGPT

RAG расшифровывается как Retrieval-Augmented Generation — поиск с усилением генерации. Вместо того чтобы загружать все документы в контекст AI-модели, система сначала находит нужные фрагменты, а потом передаёт только их в качестве контекста для ответа.

Когда вы загружаете PDF в ChatGPT, он читает весь файл целиком и держит его в памяти до конца диалога. Для документа на 40 страниц работает нормально. При базе из 200 документов контекст переполняется: цена одного запроса вырастает в 30-50 раз, качество падает — модель начинает «забывать» содержимое из начала контекста. Загрузить 50 PDF одновременно в ChatGPT нельзя технически. Загрузить 500 — и подавно.

RAG решает иначе. При добавлении документа в базу он автоматически разбивается на фрагменты по 300-500 слов. Каждый фрагмент превращается в числовой вектор — математическое представление смысла текста в пространстве из 1536 измерений. Семантически похожие тексты получают близкие векторы, независимо от того, используются ли в них одинаковые слова. «Цена аренды» и «стоимость проживания» — разные фразы, но векторы окажутся рядом. Это значит, что поиск работает по смыслу, а не по ключевым словам. Векторы хранятся в специальной базе данных — pgvector, Pinecone, Chroma или другой.

Когда пользователь задаёт вопрос, система конвертирует его в такой же вектор и ищет 3-5 фрагментов с максимальным косинусным сходством. Только эти фрагменты идут в контекст модели — всё остальное остаётся в базе. Результат: точность высокая, стоимость запроса низкая, база содержит тысячи документов без деградации ответов.

Критическое отличие от ChatGPT с загруженными файлами: RAG работает масштабируемо. При росте базы с 50 до 5 000 документов время поиска вырастает с 3 мс до 8 мс. Качество ответов не падает — модель всегда получает только релевантные фрагменты, независимо от размера базы.

Три сценария, где RAG окупается за первый месяц

Не каждый бизнес-процесс нуждается в RAG. Вот где он даёт реальный, измеримый эффект:

Поддержка клиентов по внутренней базе

Если у вас есть FAQ, прайс-лист и инструкция по продукту — AI-бот с RAG отвечает на типовые вопросы клиентов точнее, чем менеджер на второй неделе работы. В проекте по аренде недвижимости на Бали бот обрабатывает 340 типовых вопросов про условия заезда, трансферы, депозиты, ценообразование по сезонам — без участия человека. 78% диалогов закрывается без эскалации к менеджеру.

Ключевой момент: бот не придумывает ответы. Он цитирует конкретный документ из базы. Если вопроса нет в базе — говорит явно: «По этой теме информации нет, уточните у менеджера.» Галлюцинации исчезают — AI физически не может ответить по тому, чего нет в индексированных фрагментах. Это принципиально отличает RAG-бот от обычного чат-бота с промптом.

Для клиентов с большим потоком однотипных запросов: туризм, аренда, услуги, eCommerce — это прямое снижение нагрузки на поддержку. Менеджер переключается с «сколько стоит?» и «когда можно заехать?» на нестандартные случаи и реальные продажи. В пересчёте на деньги: если менеджер поддержки стоит 50 000 руб/мес и тратит 60% времени на типовые вопросы — RAG-бот освобождает 30 000 руб ежемесячно или даёт одному менеджеру вести в 2 раза больше клиентов.

Внутренний поиск по документации компании

Google Drive с 200 плюс файлами — типичная ситуация для команды от 5 человек. По данным McKinsey, сотрудники тратят в среднем 1.8 часа в день на поиск информации внутри компании. Это не поиск нужного файла в неправильной папке — это поиск конкретного пункта в нужном файле. «В каком параграфе договора прописан порядок досрочного расторжения?» — 8 минут ручного чтения или 4 секунды запроса в RAG-базу.

В Solar Property поиск по контрактам, финансовым отчётам, регламентам и инструкциям агентов сократился с 8-12 минут ручного перебора до 4-8 секунд машинного поиска. На 10-15 таких запросов в день это 1.5-2 часа, которые теперь идут на другие задачи. Умножьте на 5 сотрудников — и получите 7-10 высвобожденных часов ежедневно.

Дополнительный эффект: онбординг новых сотрудников ускоряется вдвое. Вместо «спроси Аню, она знает где договор» — новый человек сам находит ответ через базу за секунды.

Подготовка КП и коммерческих предложений

AI-агент с доступом к базе прошлых проектов, тарифов, кейсов и шаблонов готовит первый черновик коммерческого предложения за 3-5 минут. Менеджер правит детали под конкретного клиента, а не пишет с нуля. На потоке из 15 КП в месяц экономия составляет 15-20 часов рабочего времени — это почти полная рабочая неделя.

RAG в этом сценарии работает как «память» о том, что вы уже делали: похожие задачи, рабочие решения, подходящие ценовые ориентиры. Агент не придумывает — он переиспользует реальный опыт, оформленный в документах.

Когда RAG не нужен: честный список

RAG — не универсальное решение. Прежде чем внедрять, проверьте себя по этому списку:

Меньше 20 документов в базе. При такой базе проще залить всё содержимое в системный промпт. Никаких баз, никаких векторов, никакого индексирования — просто текст в начале диалога. Работает отлично до 50-80 тысяч символов. Сложность нулевая, стоимость нулевая.

Каждый клиентский случай уникален. RAG работает с повторяющимися запросами по стабильной базе. Если каждый запрос требует анализа уникальных данных, которых нет в документах — нужен агент с инструментами: доступ к API, CRM, базе данных в реальном времени. Разница принципиальная: RAG ищет по тому, что уже записано; агент с инструментами получает актуальные данные по запросу.

Документы обновляются ежедневно. Без pipeline переиндексации AI будет давать устаревшие ответы. Переиндексация решаема (cron каждую ночь), но добавляет сложности. Для первого проекта лучше взять статичную или редко меняющуюся базу, убедиться что всё работает — и потом добавлять автообновление.

Нет документов вообще. RAG работает только с текстом. Если знания существуют только в головах сотрудников — сначала нужна документация. Это организационная задача, не техническая. RAG потом, документация сначала.

Вопросы требуют вычислений, а не поиска. «Какая прибыль по вилле Сансет за март?» — не вопрос к RAG, а запрос к базе данных с аналитикой. RAG ищет по тексту, не считает по числам. Для аналитических задач — SQL-агент с доступом к BI-инструменту или напрямую к БД.

Реальный стек: как устроена RAG-база в Solar Property

Минималистичный стек без отдельного AI-сервера и без DevOps в команде:

Модель для embeddings: OpenAI text-embedding-3-small. Размер вектора: 1536 измерений. Цена: $0.02 за миллион токенов — это почти бесплатно. При первичном индексировании 340 документов с суммарным объёмом около 60 тысяч токенов стоимость составила $1.20. Ежемесячные обновления базы — менее $0.10. Для сравнения: text-embedding-ada-002 стоит в 5 раз дороже при том же качестве. text-embedding-3-large даёт прирост качества на 5-8%, но стоит в 13 раз дороже — избыточно для большинства бизнес-задач.

Векторная база: pgvector — расширение для PostgreSQL. Никаких отдельных сервисов: Pinecone с ценником от $70/мес, Weaviate, Chroma, Qdrant. Всё в той же базе данных, которая уже работает на сервере. Поиск по 50 000 векторов с IVFFlat-индексом занимает 3-8 мс. При базе до 100 000 документов pgvector справляется без видимых задержек на стандартном VPS за $20/мес.

Чанкинг: Python-скрипт разбивает документы на фрагменты по 400 слов с перекрытием 50 слов на границах. Перекрытие критично — оно сохраняет контекст, когда важная информация оказывается на стыке двух фрагментов. Без перекрытия ответ может физически «сидеть» в хвосте одного чанка и начале следующего, и retrieval не найдёт его ни в одном из них.

Retrieval: При каждом запросе система получает embedding вопроса через один API-вызов стоимостью $0.0000002, выполняет косинусный поиск по pgvector, собирает top-5 фрагментов. Они идут в контекст модели вместе с системной инструкцией: «Отвечай только на основе предоставленных фрагментов. Если информации нет — скажи об этом явно».

Модель для генерации: Claude claude-sonnet-4-6 через API Anthropic. Время ответа: 3-5 секунд. Стоимость одного запроса при среднем ответе на 200 слов: $0.003-0.005. При 1 000 запросов в месяц — $3-5 суммарно на API. Месячная стоимость всей RAG-системы на 1 000 запросов: $8-12 с учётом обновлений базы. Это не опечатка.

Пошаговый план: запустить RAG за один день

Этот план я прошёл сам в сентябре 2025. Без магических скачков, без «и далее система волшебным образом работает».

Шаг 1: Собрать и почистить базу документов — 2 часа

Соберите в одну папку всё, что должен знать AI: FAQ, прайс-листы, регламенты, инструкции, шаблоны ответов. Форматы: PDF, TXT, DOCX, Markdown. Главное правило: уберите устаревшие файлы. Если в папке лежит прайс 2024 года рядом с прайсом 2026-го — AI начнёт давать противоречивые ответы. Один актуальный документ лучше трёх устаревших версий одного и того же содержимого.

Типичная структура хорошей стартовой базы для клиентского бота: FAQ клиентов на 10-15 страниц, актуальный прайс-лист, регламент работы на 5-10 страниц, топ-20 шаблонов ответов на частые запросы, описание продукта или услуги на 3-5 страниц. Для внутреннего инструмента добавьте регламенты, договоры шаблоны и инструкции по работе с инструментами.

Шаг 2: Настроить pgvector — 30 минут

Если PostgreSQL уже есть, пять SQL-команд создают всю необходимую структуру:

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE rag_documents (
  id SERIAL PRIMARY KEY,
  source_file TEXT,
  chunk_index INTEGER,
  content TEXT,
  embedding vector(1536),
  created_at TIMESTAMP DEFAULT NOW()
);

CREATE INDEX ON rag_documents
USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 100);

Нет PostgreSQL — Supabase даёт pgvector в бесплатном плане с 500 MB хранилища. Этого хватит для базы из 5 000 плюс документов. Регистрация и создание проекта занимают 10 минут. Connection string получаете сразу в дашборде.

Шаг 3: Проиндексировать документы — 2 часа

Python-скрипт на 60 строк делает всё: читает папку, разбивает каждый файл на чанки, отправляет пакетами в OpenAI Embeddings API, сохраняет результат в pgvector. Полный скрипт с комментариями выкладываю в клубе «Solar — внутрянка».

Алгоритм в шесть шагов: сканировать папку с документами, читать содержимое каждого файла, нарезать на 400-словные фрагменты с перекрытием 50 слов, пакетно отправить в OpenAI Embeddings API, получить векторы, записать каждый фрагмент и его вектор в таблицу rag_documents с метаданными источника.

На 340 документах суммарным объёмом 800 страниц процесс занял 12 минут и стоил $1.20. Для первых 20-30 документов: 3-4 минуты и $0.10.

Шаг 4: Написать retrieval-функцию — 1 час

Логика при каждом запросе пользователя:

1. Получить embedding вопроса через один API-вызов к OpenAI Embeddings
2. SQL к pgvector: SELECT content, source_file FROM rag_documents ORDER BY embedding по косинусному расстоянию LIMIT 5
3. Собрать контекст: системный промпт плюс retrieved chunks с указанием source_file плюс вопрос пользователя
4. Отправить в Claude API
5. Вернуть ответ пользователю с указанием источника документа

Эта функция на Python занимает 20 строк кода. Общее время выполнения запроса: 3-5 секунд от момента вопроса до получения ответа.

Шаг 5: Тест и калибровка — 2-3 часа

Задайте 20 вопросов из реального общения с клиентами или сотрудниками. Зафиксируйте каждый неточный ответ, разберите причину. Типичные проблемы и решения:

• Ответ разорван — информация находится в двух соседних чанках одновременно. Решение: увеличьте перекрытие с 50 до 100 слов.
• AI не находит ответ, хотя он есть в документах. Решение: добавьте явные заголовки в исходный файл и переиндексируйте.
• Общий вопрос даёт нерелевантные результаты. Решение: добавьте query expansion — отдельным вызовом попросите модель переформулировать вопрос в 3 варианта, ищите по всем трём.
• Слишком много похожих фрагментов из одного документа. Решение: добавьте MMR — Maximal Marginal Relevance — он диверсифицирует результаты поиска по источникам.

После калибровки выведите базовые метрики: какой процент вопросов получает точный ответ по вашей оценке. Мой рабочий порог: 85% плюс означает готовность к запуску для пользователей. Ниже 85% — ещё раунд калибровки перед релизом. Логируйте каждый диалог в первые 2 недели после запуска — это золото для понимания, что ищут реальные пользователи, и позволяет быстро найти пробелы в базе знаний.

Три ошибки при внедрении RAG, которые я совершил сам

Ошибка 1: Загрузить всё подряд

В первой версии базы я залил 700 файлов: переписку в чатах, черновики предложений, устаревшие версии прайсов трёхлетней давности, тестовые документы. Качество ответов упало — AI находил противоречия между старыми и новыми данными и давал несогласованные ответы. «По прайсу 2023: X, по прайсу 2026: Y, уточните у менеджера» — это не то, что ожидает клиент.

После ревизии оставил 340 актуальных, проверенных документов. Качество ответов выросло значительно, хотя база уменьшилась вдвое по количеству файлов. Размер базы — не главное. Качество и актуальность каждого документа — главное. Лучше 50 хороших файлов, чем 500 случайных с устаревшими данными.

Ошибка 2: Не указывать источник в ответе

Первые версии бота давали ответы без ссылки на конкретный документ. Часть клиентов периодически сомневалась в точности — «откуда он это взял, не выдумал ли?» После добавления формата «По данным прайс-листа от июня 2026: ...» или «Согласно регламенту заезда, раздел 3: ...» доверие к ответам выросло заметно. Люди понимают, что AI работает по конкретным документам компании, а не генерирует из общих обучающих данных.

Для внутреннего корпоративного инструмента это менее критично — сотрудники знают систему. Для клиентского бота — указывать источник нужно с первого дня и для каждого ответа.

Ошибка 3: Забыть про переиндексацию

Через 2 месяца после запуска бот начал давать клиентам устаревшие тарифы. Я обновил прайс-лист в папке, но не переиндексировал базу. Один клиент получил цену трёхнедельной давности и пришёл с обоснованной претензией.

После этого настроил cron-задачу: каждую субботу в 03:00 ночи скрипт проверяет дату изменения каждого файла в папке и переиндексирует только те документы, которые изменились с прошлого прогона. Полный прогон на 340 документах: 4 минуты и $0.03. Теперь база всегда актуальна автоматически, без ручного контроля.

От RAG к агентной системе: следующий шаг

RAG — фундамент. Когда база работает и даёт точные ответы, на ней строятся более сложные агентные сценарии. Бот, который не просто отвечает на вопросы, но и выполняет действия: создаёт задачи в трекере, обновляет записи в CRM, запрашивает данные из внешних API, формирует документы по шаблонам, отправляет уведомления нужным людям.

В Solar это выглядит так: клиент спрашивает про аренду виллы, RAG находит подходящие варианты из каталога с актуальными ценами, агент формирует персонализированный ответ с конкретными предложениями. Если клиент готов к бронированию — агент создаёт заявку в системе и отправляет менеджеру уведомление в Telegram с полным контекстом диалога. Человек подключается только на этапе оформления договора и получения предоплаты. Всё что до — на агенте.

Архитектура масштабируется естественно: добавляете новые документы в базу без перезапуска системы, добавляете новые типы действий к агенту через новые инструменты, добавляете новые каналы с одним и тем же backend. Telegram, WhatsApp, веб-чат, голосовой ввод — всё работает через одну RAG-базу и одну retrieval-функцию. Единожды написанный retrieval-код переиспользуется в любом новом проекте без переработки.

По опыту первого года: самая дорогая часть RAG-проекта — не техника. Это составление и поддержка качественной базы документов. Техника занимает 1 день. База знаний — постоянная работа: обновления, добавление новых документов, удаление устаревших. Тот, кто это понял с самого начала, получает систему которая реально работает. Тот, кто думал что достаточно один раз загрузить — получает систему с устаревшими ответами через 2 месяца.

Такую архитектуру — RAG плюс агентные цепочки плюс Telegram-интерфейс — я разбираю внутри клуба «Solar — внутрянка» с реальными скриптами. Там есть: полный Python-скрипт индексирования с обработкой PDF, DOCX и TXT, retrieval-функция под pgvector с указанием источника в ответе, AGENTS.md для RAG-бота, настройка cron-переиндексации и пример интеграции с Telegram Bot API. Не теория — код, который крутится в проде с сентября 2025 года.

Клуб «Solar — внутрянка», от 2 500 руб/мес. Бери и адаптируй: https://4bos.ru/inside/

По смежным темам на блоге: как создать AI-ассистента для управления бизнесом, как защитить multi-agent систему от регрессий.

— Solar OS.