Нужен ли RAG для ИИ-консультанта на сайт: когда достаточно простой базы знаний

Что вообще нужно ИИ-консультанту небольшого сайта

Что общего у сайта платного водоёма, дизайнера интерьеров, языковой школы, салона красоты или небольшой базы отдыха?

Как правило, посетители задают довольно ограниченный набор вопросов:

• сколько стоит;
• как вы работаете;
• где находитесь;
• как добраться;
• есть ли доставка;
• какие способы оплаты;
• чем отличаются тарифы;
• что входит в стоимость;
• можно ли приехать с ребёнком, друзьями или супругом;
• есть ли парковка;
• можно ли с животными;
• как забронировать;
• какие документы нужны;
• что взять с собой.

У стоматологии список будет один, у базы отдыха другой, у небольшого производства третий.

Но принцип одинаковый.

Посетителю обычно не надо искать иголку в библиотеке из миллиона документов.

Ему надо получить нормальный ответ из относительно небольшого объёма информации о конкретном бизнесе.

И здесь появляется вопрос:

куда вообще складывать эти знания?

RAG? Иногда да. Но не по привычке

RAG прекрасно решает свою задачу, когда данных действительно много.

Допустим, у нас:

• 15 000 товаров;
• документация на сотни страниц;
• инструкции;
• характеристики;
• статьи;
• постоянно меняющийся ассортимент.

Засовывать всё это целиком в контекст каждого запроса было бы странно.

В таком случае логика понятна:

Но так же дороже по токенам?

Да.

Каждый запрос содержит базу знаний целиком.

Это цена простоты.

Но смотреть надо на реальные масштабы.

Если у бизнеса несколько десятков или несколько сотен диалогов в месяц, а база небольшая, расходы на input-токены могут оказаться смешными по сравнению с разработкой и поддержкой отдельной инфраструктуры.

Особенно если использовать недорогую модель.

Можно неделю оптимизировать расход токенов на десять рублей.

Технически увлекательно.

Экономически не всегда.

Поэтому вопрос я бы ставил иначе:

При каком объёме данных и запросов более сложная архитектура начнёт окупать собственную сложность?

Для небольшого бизнеса этот момент может вообще не наступить.

Простую базу знаний проще поддерживать

Здесь вопрос уже не архитектуры, а владельца бизнеса.

Ему неинтересны:

• embeddings;
• chunks;
• vector indexes;
• reindex;
• similarity threshold.

Ему надо поменять:

Доставка теперь стоит не 500, а 700 рублей.

В простом варианте он открывает базу знаний, меняет 500 на 700 и сохраняет.

Готово.

Без переиндексации, проверки чанков и размышлений о том, какая версия цены сейчас лежит в поисковом индексе.

А откуда брать базу знаний

Можно заставить владельца бизнеса писать её вручную.

Но чаще всего большая часть нужной информации уже есть на сайте.

Цены, услуги, условия, адрес, режим работы, правила, доставка, FAQ.

То есть можно дать системе список URL и сначала собрать информацию автоматически, а потом уже проверить и поправить результат.

Это как раз тот случай, когда ИИ полезен не только как собеседник, но и как инструмент подготовки исходной базы.

Людям часто лень искать нужный ответ даже на одностраничнике. Что уж говорить об «огромном» сайте на пять-семь страниц.

В итоге я автоматизировал не ИИ, а обвязку вокруг него

После нескольких ручных проектов стало понятно, что каждый раз повторяется одно и то же:

• создать консультанта;
• задать ему имя;
• написать приветствие;
• определить стиль общения;
• добавить базу знаний;
• подключить модель;
• получить код виджета;
• установить его на сайт;
• хранить историю и настройки.

Сам вызов LLM — вообще не самая сложная часть.

Повторяется именно инфраструктура вокруг него.

Так появился Cyberiada Chat — сервис, где нового консультанта можно настроить без ручной сборки workflow.

В самом простом варианте настройка сводится примерно к пяти шагам:

1. Задать имя консультанта.
2. Написать приветственную фразу.
3. Выбрать стиль общения.
4. Добавить базу знаний вручную, загрузить Markdown-файл или дать ссылки на страницы сайта.
5. Получить код и вставить его на сайт.

Тот же консультант может работать и в Telegram с той же базой знаний.

Если нужна простая консультация по информации бизнеса, этого часто достаточно.

Попробовать Cyberiada Chat

Где такая схема уже не подходит

Разумеется, не любой ИИ-консультант можно построить настолько просто.

Допустим, у интернет-магазина 15 000 товаров, постоянно меняющиеся остатки, и покупатель спрашивает:

Нужен насос для скважины 40 метров, диаметром не больше такого-то. Что сейчас есть в наличии?

Тут одной текстовой базы уже мало.

Нужно:

1. понять параметры запроса;
2. обратиться к каталогу;
3. проверить характеристики;
4. проверить остатки;
5. отфильтровать подходящие варианты;
6. сформировать ответ.

Здесь уже могут понадобиться RAG, SQL, API магазина, function calling, отдельный поиск по каталогу и другие инструменты.

То же самое со статусом заказа.

На вопрос:

Сколько стоит доставка?

можно ответить из базы знаний.

На вопрос:

Где сейчас мой заказ №12345?

надо идти в систему заказов.

Это уже другой класс задачи.

Для таких проектов у нас есть отдельное направление — индивидуальная разработка ИИ-консультантов и интеграций.

Поэтому я бы начинал не с архитектуры

Сначала стоит ответить на два вопроса:

Что консультант должен знать?

и

Откуда эта информация берётся?

Если ответ:

Вот несколько страниц сайта и небольшой прайс.

я бы не спешил устанавливать векторную базу.

Если:

Вот каталог на 50 000 товаров, остатки меняются каждые десять минут, плюс документация на 600 страниц.

тогда разговор уже совсем другой.

Проблема в том, что технически интересные решения очень хочется применять.

Если вчера разобрался с vector database, сегодня почему-то каждому сайту срочно нужен RAG.

Но у небольшого бизнеса задача обычно гораздо скучнее:

Вы завтра работаете?

Можно приехать с собакой?

Сколько стоит домик?

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

Что в итоге

После первых двух консультантов мне казалось, что надо научиться быстрее собирать ИИ-ботов.

В итоге оказалось, что автоматизировать надо было совсем другое: повторяющуюся инфраструктуру вокруг довольно простой операции.