1
Подход 1. Вся база знаний передаётся модели целиком
Самый простой и при этом рабочий вариант для небольшого и среднего бизнеса — хранить знания в структурированном виде (например, в JSON) и передавать их модели полностью вместе с вопросом пользователя.
Так работает большинство корпоративных чат-ботов на старте: карточки товаров, услуги, тарифы, FAQ, правила компании собираются в компактные тематические блоки, и вся эта база «прикладывается» к каждому запросу.
Плюсы:
- минимальные требования к серверной части: всё работает на обычном PHP-хостинге;
- не нужны embeddings и векторные базы данных;
- модель видит всю картину целиком и может сопоставлять данные из разных разделов между собой;
- базу легко редактировать, проверять и обновлять вручную;
- нет риска, что нужный фрагмент «не найдётся» - он и так уже в контексте.
Минусы:
Единственная реальная проблема - это рост объёма базы. Чем больше знаний, тем больше токенов передаётся при каждом сообщении, а значит, растут стоимость запроса и время ответа. Кроме того, если в контекст попадает много лишней, нерелевантной информации, модель иногда начинает путать похожие сущности, например, близкие по характеристикам товарные позиции.
Когда достаточно этого варианта:
Для компактных и средних баз знаний, как правило, это диапазон в несколько десятков тысяч токенов. Для интернет-магазина с ограниченным ассортиментом, сайта услуг или консалтинговой компании этого практически всегда хватает с запасом.
Полезный приём:
Если ассистент встроен в конкретную страницу сайта (например, карточку товара), ему можно передавать не всю базу, а только относящийся к этой странице раздел плюс общие сведения о компании. Это сокращает объём контекста вообще без дополнительной инфраструктуры.
2
Подход 2. Умный выбор нужных разделов базы
Когда база знаний вырастает и товарных категорий и разделов становится много, оптимальным решением часто оказывается не полноценный RAG, а промежуточный вариант: перед основным ответом небольшой вспомогательный запрос определяет, какие именно разделы базы относятся к вопросу пользователя.
Модели передаётся не сама база, а её «оглавление» — краткое описание каждого раздела. Модель выбирает, какие разделы действительно нужны, и уже после этого система формирует основной запрос только с релевантными фрагментами.
Плюсы:
- по-прежнему не требуется векторная база данных;
- по-прежнему работает на стандартном хостинге;
- заметно сокращается объём передаваемых токенов, а значит — и стоимость диалога;
- легко контролировать и логировать, какие именно данные получила модель для ответа;
- для предварительного выбора разделов можно использовать более дешёвую и быструю модель, а для финального ответа — основную.
Минусы:
Появляется дополнительный шаг обработки запроса, а значит — доля риска, что вспомогательный «маршрутизатор» ошибётся и не подключит нужный раздел. Это решается тем, что критически важные общие данные (например, о компании и условиях доставки) можно подключать всегда, независимо от выбора.
Когда стоит переходить на этот вариант:
Когда база знаний становится тематически разветвлённой - десятки разделов, у каждого из которых своя группа вопросов. Например, каталог с множеством категорий товаров, каждая со своими техническими особенностями.
Этот подход часто называют «light RAG» — он даёт часть преимуществ полноценного RAG (модель работает только с релевантным фрагментом базы), но без затрат на векторную инфраструктуру.
3
Подход 3. Классический RAG
Полноценный RAG нужен, когда база знаний перестаёт быть компактным набором структурированных карточек и превращается в массив документов: инструкции, регламенты, технические паспорта, статьи, отраслевые стандарты — то есть сотни тысяч и миллионы токенов неструктурированного текста.
В этом случае документы заранее разбиваются на фрагменты (chunks), каждый фрагмент превращается в векторное представление (embedding) и сохраняется в специализированной векторной базе данных. При вопросе пользователя система ищет наиболее семантически близкие фрагменты и передаёт модели только их — обычно 5–10 фрагментов вместо всего массива документов.
Плюсы:
- база знаний может масштабироваться практически без ограничений;
- модель получает лишь несколько тысяч токенов на запрос, даже если исходная база — миллионы;
- семантический поиск находит релевантные фрагменты даже без точного совпадения формулировок.
Минусы - здесь начинается главное отличие от первых двух подходов
Для полноценного RAG требуется:
- отдельная векторная база данных (Pinecone, Chroma и подобные);
- сервис для генерации и хранения embeddings;
- логика chunking, обновления индекса и контроля качества поиска.
Именно этот набор компонентов практически всегда означает, что обычного хостинга недостаточно и нужен отдельный VPS - специализированные векторные базы и постоянно работающие сервисы поиска не размещаются в стандартной среде виртуального хостинга, где живёт большинство корпоративных сайтов на PHP. Это ощутимо усложняет серверную часть проекта, требует администрирования и увеличивает регулярные расходы на инфраструктуру.
Стоит учитывать и обратную сторону: RAG сам по себе не гарантирует более точные ответы. Появляется новая точка отказа - если поисковый механизм не найдёт нужный фрагмент, модель до него просто не доберётся, даже если правильный ответ есть в базе. Качество RAG-системы целиком зависит от того, насколько грамотно выполнены разбиение документов, поиск и ранжирование фрагментов.
Когда RAG действительно оправдан:
У вас большие массивы неструктурированной документации, десятки и сотни инструкций, юридические и технические тексты, база знаний, которая продолжает расти без предсказуемой структуры.
