ИИ‑ассистент: либо дорого, либо тупит. А что если — нет?
Режим №1 — «правильно, но долго и дорого».
Вам предлагают построить RAG‑контур: ingestion‑пайплайны, embeddings, векторную базу, ранжирование, мониторинг качества, логи, доступы, безопасность. Архитектура сильная — но часто это превращается в проект на месяцы с бюджетом, который для SMB выглядит как «взрослый энтерпрайз».
Режим №2 — «быстро, но стыдно».
Ставите простой чат‑виджет «на промпте», и он вроде бы отвечает… пока не начнёт уверенно придумывать: условия доставки, наличие, характеристики, сроки гарантии. В итоге вместо роста конверсии получаются AI hallucinations и репутационные риски. Либо бот просто ведет по сценариям, предлагая варианты ответов, и клиента это не цепляет.
И вот контр‑интуитивная мысль, к которой мы пришли, развивая платформу AI‑виджетов Riserlabs: в большинстве задач малого и среднего бизнеса RAG — не первый шаг.
Почему проблема не в «умении говорить», а в контексте и контроле
За последние годы запустить чатбота стало просто: выбрать LLM, написать prompt, встроить на сайт. Но бизнес упирается в другое:
- Что именно ассистент знает (и где «истина»).
- Насколько знания актуальны — особенно в e‑commerce, где цены/наличие/ассортимент меняются постоянно.
- При слишком большом контексте модель начинает хуже работать.
- Предсказуемое поведение: чтобы AI‑продавец продавал, AI‑поддержка помогала, а не «фантазировала», не уводила к конкурентам и не делала сомнительных обещаний.
Поэтому ключевой актив — не UI чата и не «идеальный промпт», а управление контекстом: какие источники считаются правдой, как они обновляются, какая часть контекста используется при конкретном запросе, что ассистенту разрешено и что он делает, если данных нет.
Когда RAG действительно нужен (и это нормально)
Чтобы не выглядеть «анти‑RAG пропагандой», честно: на наш взгляд RAG оправдан, когда:
- источников много и они разнородные (1000+ документов, регламенты, базы знаний);
- критичны точные цитаты и ссылки на первоисточник («покажи пункт договора»);
- нужны сложные права доступа и аудит;
- цена ошибки высокая (юридические/медицинские/комплаенс‑сценарии).
Там «тяжёлый» контур — инвестиция в качество и безопасность.
Но в типовом ecom/услугах это часто оверкилл на старте.
Что нужно большинству СМБ вместо RAG: «лёгкий контур»
Если у вас интернет‑магазин или услуги, 80% вопросов повторяются:
- «Чем отличается модель A от B?»
- «Подберите под мой сценарий и бюджет»
- «Есть ли в наличии, сколько доставка?»
- «Оплата, гарантия, возврат»
- «Что лучше для моей задачи?»
Это не «поиск по 500 PDF». Это консультация по понятным правилам и данным, которые у бизнеса уже есть.
Поэтому на практике часто работает более простой подход:
- Подключить источники знаний, которые реально поддерживаются (каталог, FAQ, политика доставки/возврата, прайс/фид).
- Задать роль/персону ассистента: тон, границы, политика отказов, запрет на выдумки, правила уточняющих вопросов.
- Включить регулярное обновление, чтобы знания не устаревали.
- Настроить lead pipeline: куда отправлять заявки (CRM/Telegram/email), чтобы ассистент не просто «болтал», а приводил к покупке.
- И только затем усложнять — когда вы уже видите, где именно упёрлись.
Пример e‑commerce: актуальные цены, наличие и сравнение без «обучения модели»
Один из самых прагматичных сценариев для магазина — не «дообучить модель», а дать ей правильный, обновляемый источник.
- отвечает по реальным товарам и характеристикам;
- учитывает актуальные цены и наличие;
- сравнивает позиции и помогает выбрать;
- отвечает на языке, на котором задается вопрос;
- ведёт к следующему шагу: корзина/заявка/контакт.
Ключевое: ассистент опирается на то, что вы дали, и не должен «достраивать правду» из воздуха.
Контроль поведения: чтобы AI‑продавец не превращался в «самодеятельность»
Даже идеальные знания бесполезны, если ассистент ведёт себя непредсказуемо. Поэтому важны:
- Персона и правила: строгая привязка к источникам, «если не уверен — уточни/передай оператору», запрет на конкурентные рекомендации.
- Контролируемые действия (CTA): кнопки/шаги, которые исполняются server‑side (это снижает риск prompt‑injection и «внезапных» действий модели).
- Безопасность и анти‑бот: лимиты, CAPTCHA, allowlist, шифрование и контроль затрат — то, что обычно всплывает не в демо, а на проде.
Вывод: сначала польза и метрики — потом сложность
ИИ‑помощник не обязан быть либо «за миллионы», либо «галлюцинирующим». Во многих сценариях достаточно правильно собрать контекст, держать его актуальным, задать роль и встроить лид‑контур — и вы уже получаете измеримую пользу: разгрузку поддержки и рост конверсии в заявку/покупку.
Если хотите проверить гипотезу быстро — начните с одного сценария (например: «подбор товара + доставка/оплата/гарантия») и посмотрите на реальные диалоги пользователей. А RAG оставьте как следующий этап, когда он действительно станет нужен, плюс сценарии и ценность станут очевидны.