Разбираемся, как создать эффективный чат-бот для e-commerce с RAG-памятью | Автор: Марина Погодина
Когда я вбиваю в поиск «как создать чат бот e-commerce с долгосрочной RAG-памятью», меня всегда немного поддёргивает: хочется, чтобы рядом сразу добавлялась приписка «в России, по 152-ФЗ и без штрафов». В 2026-м чат-бот для интернет-магазина — это уже не игрушка, а рабочая лошадка, которая должна помнить клиентов, их заказы, странные ночные вопросы и не сливать всё это куда-то за океан. В этом тексте я разберу, как в российских реалиях собрать такого бота с долговременной RAG-памятью, который работает в Telegram, живет на российских серверах и не рисует вам в бюджете плюс 500 тысяч за счёт Роскомнадзора. Статья для тех, кто руками трогает автоматизацию, любит n8n и Make, но уже устал от «магии ИИ» в стиле «подключите одну кнопку — будет счастье». Расскажу, что из этого реально собрать своими силами, где всё-таки нужен инженер, а где достаточно здравого смысла и одной крепкой таблицы в Notion или Postgres. Это история не про чудо, а про аккуратную архитектуру, понятные шаги и немножко самоиронии, когда бот в третий раз падает на ночном релизе.
Время чтения: примерно 15 минут
- Зачем e-commerce в России в 2026-м нужен чат-бот с RAG-памятью
- Как устроен RAG-бот для магазина под 152-ФЗ по шагам
- Какие инструменты и стеки работают в России в 2026-м
- Как построить процесс: от первой схемы до боевого бота
- Каких рисков бояться и где e-commerce чаще всего ошибается
- Какие результаты ждать и как мерить пользу от такого бота
- Что ещё важно знать про RAG-ботов в 2026-м
Зачем интернет-магазину в России в 2026 году чат-бот с RAG-памятью
Я иногда сижу ночью, допиваю остывший кофе и смотрю в логи: очередной клиент в полночь спрашивал у бота, «подойдёт ли это пальто под мою фигуру, как то синее в октябре», а бот честно выкатил каталог «похожие модели». Без долгосрочной RAG-памяти это классическая картинка: бот вроде отвечает, но не помнит прошлые диалоги и не тянет контекст, который для живого менеджера очевиден. В e-commerce это бьёт по двум местам — по конверсии и по нервам, потому что человек второй раз объяснять свои предпочтения не хочет, а вы платите за трафик, который сливается на этапе «мне лень всё повторять». В 2026-м клиенты в России уже привыкли, что сервисы их узнают: маркетплейсы помнят размеры, банки — любимые сценарии, а вот небольшой магазин на Tilda или самописном движке почему-то до сих пор каждый раз делает вид, что видит покупателя впервые.
Я заметила, что как только начинаешь говорить «долгосрочная RAG-память», у многих включается фантазия про вечное хранение всего: чатов, эмоций, смайликов, голосов. В наших реалиях так делать нельзя и технически, и юридически. RAG-память для e-commerce — это не бесконечный дневник клиента, а аккуратная база фактов, которые бот может подтащить в диалог: размер, предпочтения по цвету, история заказов, иногда ограничения по составу ткани. Всё это подпадает под персональные данные, и в 2025-2026 годах к этому уже очень плотно подошёл Роскомнадзор: обязательная регистрация оператора, локализация баз в РФ, отдельные цели обработки и техническая защита. Это означает, что вопрос «как создать чат бот в телеграмме» в российской повестке автоматически превращается в «как создать чат бота в телеграмме и при этом не собрать на себя акт проверки».
Вот как это выглядит на практике с точки зрения клиента: она один раз рассказывает боту, что носит 46-й размер, не любит синтетику и живёт в Екатеринбурге, а через пару недель заходит снова и пишет что-то вроде «хочу как то синее пальто, но потеплее, зима у нас в этом году странная». RAG-слой подтягивает вектор её прошлых запросов и заказов, находит те самые синие позиции, смотрит по ИД клиента её покупки и подсовывает модели из новой коллекции, которые близки по посадке и составу. Для неё это ощущается как нормальный человек в чате, который «помнит», хотя под капотом просто аккуратная работа с эмбеддингами и векторной базой. Для меня как для владельца магазина это плюс к повторным покупкам и минус к времени менеджеров, которые не тонут в типовых вопросах по наличию и размерной сетке.
Мне нравится проговаривать ещё одну деталь: долгосрочная память не обязана быть вечной. По 152-ФЗ у нас работают принципы минимизации и ограничения сроков хранения, и в RAG-архитектуре это даже удобно. Можно хранить эмбеддинги предпочтений 12 или 24 месяца, дальше либо анонимизировать их, либо стирать связку с конкретным человеком, оставаясь только с обобщённой статистикой. Ключевая мысль здесь в том, что RAG-память для e-commerce в России — это про персонализацию «на разумный срок», а не про вечный цифровой след. Такой подход даёт возможность честно писать в политике обработки, что память используется для улучшения рекомендаций в рамках договора купли-продажи и не превращается в отдельную социальную сеть в духе «мы знаем о вас всё».
Я ловлю себя на том, что разговоры про чат-ботов часто уходят в магию: «AI всё сделает сам, подключите GigaChat и спите». На самом деле хороший RAG-бот для интернет-магазина — это продолжение вашей CRM, а не отдельное чудо. Он должен смотреть на заказы, статусы доставок, остатки на складе, иметь аккуратный доступ к ценам и акциям, а не генерировать их из головы. Это критично, потому что LLM без RAG-слоя и бизнес-правил будет галлюцинировать скидки, несуществующие модели и условную «оплату после примерки», которой вы никогда не делали. Получается, что в 2026-м вопрос не «нужен ли мне бот», а «готова ли я впустить бота внутрь своих процессов и дать ему нормальные данные». Если да — RAG-память становится естественным шагом, а не дорогой игрушкой для витрины.
Постепенно подходим к неприятной части — регуляторной. В России сейчас уже не сработает подход «я маленький магазин, меня не заметят». Роскомнадзор научился сканировать сайты автоматически, подлавливать отсутствие политики обработки, зарубежные формы обратной связи и даже интеграции с чат-ботами на иностранных платформах. Если бот в Telegram складывает чаты на зарубежный сервер без шифрования и локализации, вы, как владелец, формально становитесь оператором, который нарушает требования по хранению ПДн. Это критично, потому что штрафы за обработку без уведомления и без законного основания уже идут в сотни тысяч рублей, а вместе с утечкой или жалобой клиента всё может закончиться очень неприятной проверкой. На этом фоне долгосрочная RAG-память оказывается не только технической задачей, но и тестом на вашу зрелость в управлении данными.
Когда я первый раз открыла уведомление от Роскомнадзора с вопросом «куда у вас утекают данные», было совсем не до красивых архитектур. Поэтому сейчас я честно говорю: RAG-бот в 2026-м — это сначала документооборот и процессы по 152-ФЗ, а уже потом красивые интеграции с LLM.
Как меняется клиентский опыт с появлением осознанной RAG-памяти
Я часто смотрю на чат-бота глазами своей клиентки, которая заходит ко мне третью зиму подряд за пальто и брюками. Для неё классический «кнопочный» бот — это набор меню, где она каждый раз жмёт «женская одежда», «верхняя», «зима», а потом листает 40 позиций без намёка на то, что кто-то помнит её прошлые заказы. Как только появляется RAG-память, сценарий меняется: она пишет живым текстом, иногда с опечатками, иногда голосом, а бот подтягивает из векторной базы контекст, не спрашивая её по кругу «какой у вас размер» и «вы в каком городе». На практике это означает, что хороший диалог строится не на предзаданных скриптах, а на смеси сохранённых фактов, логики и генерации, где модель понимает, что «как прошлой зимой» — это ссылка на конкретный заказ из истории.
На практике я вижу три основных эффекта от такой памяти. Во-первых, уменьшается число повторяющихся вопросов, потому что бот сам уточняет детали, а не гоняет клиента по меню. Во-вторых, растёт доверие: люди довольно быстро замечают, что система «помнит» их достаточно, но не навязчиво, и это похоже на любимого продавца в офлайновом магазине, который знает, что вы не носите красное. В-третьих, сильно упрощается работа поддержки: те случаи, где действительно нужен человек, становятся заметнее на фоне потока однотипных запросов, который бот спокойно переваривает. Я, если честно, первое время просто радовалась, что менеджеры наконец перестали по 15 раз писать «да, размер 44 есть в наличии» в разных формулировках.
Перед тем как двигаться к архитектуре, мне важно проговорить, что такой бот в российском e-commerce в 2026-м уже нельзя строить по принципу «мы всё запишем и потом разберёмся». Принципы privacy by design и минимизации данных перестали быть модной теорией, они переехали в чек-листы проверок и требования к проектам. Это означает, что когда мы думаем «как создать чат бот самостоятельно бесплатно», на самом деле нужно считать не только стоимость хостинга и разработчика, но и риски: регистрация оператора, внутренняя документация, обучение команды, техническая защита. Чуть позже я покажу, как всё это уложить в более-менее реалистичный план для малого интернет-магазина, а пока можно выдохнуть и принять мысль: RAG — это не про максимум данных, а про «достаточно для хорошего сервиса».
Получается забавный парадокс: чем аккуратнее мы обращаемся с персональными данными и ограничиваем память бота по срокам и объёму, тем охотнее клиенты делятся с ним тем, что действительно помогает. Люди спокойно называют свои размеры и предпочтения, когда видят, что это используется по делу, а не для бесконечной рассылки «у нас распродажа, скидки до». В этом месте долгосрочная RAG-память начинает играть роль не только технологического элемента, но и маркера уважения к времени и нервам покупателя. Дальше уже можно переключаться на технику и шаги: где крутится база, как связать Telegram с бэком, куда положить векторы и чем всё это накрыть, чтобы спать спокойно.
Вопрос «зачем» мы для себя закрыли, теперь пора переходить к «как именно», иначе разговор так и останется в зоне красивых презентаций без рабочего бота в Telegram или на сайте.
Как устроен RAG-бот для магазина под 152-ФЗ по шагам
Когда я первый раз столкнулась с задачей «создать чат бота самому» для своего магазина, у меня в голове встала каша из терминов: LLM, RAG, эмбеддинги, ECP, ИСПДн, УЗ-1, Telegram API. Разруливать это проще всего через картинку из четырёх слоёв: интерфейс, бизнес-логика, RAG-память и контур защиты данных. В интерфейсе живут привычные вещи — Telegram-бот, веб-чат на сайте, иногда мини-приложение во VK. В бизнес-логике сидят правила e-commerce: статусы заказов, условия доставки, акции, размерные сетки. RAG-память отвечает за то, чтобы подтянуть из базы всё нужное к конкретному диалогу. А контур защиты — это то, о чём обычно вспоминают в самом конце, хотя по-хорошему начинать надо как раз с него, особенно в российской реальности 2026 года.
Я заметила, что полезно сначала разложить, какие данные вообще нужны боту для работы. Если цель — персональные рекомендации и отслеживание заказов, достаточно ИД клиента в вашей CRM, истории покупок и нескольких атрибутов вроде города и размеров. ФИО и телефон уже живут в вашей ИСПДн, и боту чаще всего они в явном виде не нужны. Хитрость RAG-подхода как раз в том, что в векторную базу отправляются не целые диалоги с именами и номерами, а обезличенные эмбеддинги фраз и объектов: «женское пальто, размер 46, шерсть 80%, синий, Екатеринбург». В связке с ИД заказа этого достаточно, чтобы в следующем диалоге понять, чего ждёт клиент, не вываливая наружу его персональные данные. Это критично, потому что при утечке векторной базы у вас будут утекать предпочтения без прямой привязки к человеку, а не полные чаты с адресами и телефонами.
Вот как это выглядит на практике в виде алгоритма, если сильно упростить. Клиент пишет боту в Telegram вопрос «подойдёт ли это пальто как то синее в октябре, только потеплее». Запрос летит через API на ваш бэк, где первая стадия — это эмбеддинг: текст превращается в вектор при помощи модели эмбеддингов (российский аналог, который можно крутить в VK Cloud или Yandex Cloud). Потом этот вектор идёт в векторную базу знаний, где лежат векторы прошлых заказов и описаний товаров. База возвращает несколько ближайших соседей — те позиции, которые максимально похожи на «синее пальто из октября». Эти данные собираются в контекст, к ним добавляется служебная информация по клиенту из CRM, и всё это передаётся в LLM (GigaChat, YandexGPT и другие российские модели). Модель уже формирует ответ в человеческом виде, а вы добавляете поверх проверку бизнес-правил: не предлагать товары, которых нет в наличии, не придумывать вымышленные акции и так далее.
Я люблю в этот момент рисовать на листке простой конвейер с подписями, потому что иначе легко заблудиться в деталях. Интерфейс (Telegram) — Бэкенд — Эмбеддинги — Векторная база — LLM — Ответ. Каждое звено здесь можно реализовать по-разному: где-то руками, где-то через n8n, где-то через готовые SDK от банковских или облачных платформ. Для российского бизнеса добавляется ещё одно обязательное звено — аудит обработки персональных данных. Нужны регистрация оператора в Роскомнадзоре, внутренняя политика обработки, назначение ответственного за ПДн и описание ИСПДн, где живут ваши базы RAG. Звучит скучно, но без этого диалог «как создать чат бот в телеграмме самостоятельно» в e-commerce в 2026-м превращается в «как получить предписание за незаконную обработку данных».
На практике полезно сразу разбить проект на два потока: юридико-организационный и технический. В первом вы описываете цели обработки («персонализация рекомендаций в интернет-магазине», «сопровождение исполнения договора купли-продажи»), приводите в порядок пользовательское соглашение и политику конфиденциальности, оформляете модель угроз и выбираете СЗИ. Во втором рисуете архитектуру бота, выбираете стеки и инструменты, настраиваете интеграции с CRM и складской системой. Хорошая новость в том, что это можно делать параллельно, не дожидаясь, пока юристы всё согласуют. Плохая — придётся пару раз вернуться и поправить архитектуру, когда выяснится, что какой-нибудь любимый зарубежный сервис по-хорошему использовать нельзя.
Я часто слышу вопрос: «можно ли создать чат бота бесплатно», особенно от небольших магазинов и соло-предпринимателей. Теоретически да — если взять бесплатные тарифы Telegram, использовать open-source векторное хранилище и развернуть всё на скромном виртуальном сервере в российском облаке. Практически основная стоимость уходит не в железо, а во время: нужно продумать флоу, настроить безопасность, описать промпты, собрать пайплайны в том же n8n или аналоге и протестировать на реальных диалогах. Здесь хорошо помогает привычка разбивать задачу на минимальный рабочий кусок: сначала бот, который просто отвечает по каталогу без памяти, потом добавление RAG-слоя для истории заказов, потом уже более тонкая персонализация по предпочтениям.
Мне однажды хватило недели на «быстрый MVP», который через месяц пришлось переписывать с нуля, потому что в него не заложили обработку ошибок и политику по срокам хранения. С тех пор я к сложным чат-ботам отношусь как к продукту, а не к разовой интеграции.
Как вписать RAG-память в требования 152-ФЗ без паники
Когда я говорю с коллегами из e-commerce про 152-ФЗ, в глазах у многих читается усталость: все примерно слышали про уведомление оператора, про локализацию и про какие-то уровни защищённости, но мало кто хочет в этом разбираться. С RAG-ботами выбора особо нет: как только вы начинаете хранить историю взаимодействий, предпочтения и привязку к заказам, вы попадаете в классическую ИСПДн, которую Роскомнадзор вполне может спросить. На практике это означает, что перед тем как писать первый промпт для модели, надо хотя бы схематично ответить себе на четыре вопроса: что обрабатываем, зачем, где храним и кто имеет доступ. Этот минимум уже сильно снижает риск сделать архитектуру, которую потом невозможно легализовать.
На практике есть несколько рабочих правил. Во-первых, минимизация: боту не нужны паспортные данные, СНИЛС, полные адреса, если он не оформляет кредит или сложную доставку. Достаточно идентификаторов заказов, обезличенных параметров и небольшого набора предпочтений. Во-вторых, ограничение срока хранения: можно честно написать в политике, что предпочтения по размерам и стилю хранятся, скажем, 24 месяца, после чего либо удаляются, либо обезличиваются. В-третьих, понятные права доступа: не должно быть ситуации, когда весь штат магазина имеет прямой доступ к векторной базе и логам диалогов, особенно если там иногда всплывают чувствительные детали. Здесь хорошо работают роли: бот и несколько сервисных аккаунтов имеют технический доступ, люди — только через интерфейсы CRM и отчётов.
Я поняла, что упрощает жизнь ещё один приём — разделение логов и RAG-памяти. Логи диалогов нужны для отладки, аналитики и обучения модели, а RAG-память — для персонализации в онлайне. Можно хранить логи без привязки к конкретным ИД клиентов или с псевдонимизацией, а в векторной базе держать только то, что реально используется в диалогах. Такое разделение помогает и с точки зрения безопасности: вы можете накрыть RAG-базу более строгими средствами защиты, чем обычный журнал запросов, и при необходимости быстро её «очистить» по требованию субъекта данных. В ИИ-проектах это часто забывают, а потом удивляются, почему любая доработка бота превращается в операцию по вскрытию всего хранилища.
Получается, что техническая архитектура RAG-бота и юридические требования 152-ФЗ на самом деле хорошо стыкуются, если сразу думать категориями «минимум данных, максимум пользы» и «отдельные контуры для разных задач». В 2026-м это уже не выглядит экзотикой: российские облака предлагают готовые средства защиты ИСПДн, модули шифрования и даже полуготовые шаблоны типовых документов. Да, это не отменяет необходимости включить голову и один раз всё описать под свой магазин, но планка вхождения стала заметно ниже, чем ещё пару лет назад. Дальше останется решить, чем именно собирать пайплайны и к каким российским LLM и эмбеддингам вы готовы морально и финансово привязаться.
Когда картина по слоям и требованиям складывается, становится уже не так страшно, и вопрос «как создать чат бот самостоятельно бесплатно» снова превращается в техническую задачку, а не в юридический триллер.
Какие инструменты и стеки работают в России в 2026-м
Я помню, как пару лет назад половина гайдов «как создать чат бот» начиналась с фразы про зарубежные LLM и облака, а дальше шли примеры на сервисах, которые сейчас под вопросом с точки зрения трансграничной передачи данных. В 2026-м для российского e-commerce картина уже гораздо приземлённее: если вы работаете с персональными данными россиян, то стэк автоматически сужается до российских облаков и моделей. Не потому что «так патриотичнее», а потому что штраф в 300-500 тысяч и блокировка ресурсов — это слишком дорогая плата за удобный API. Поэтому, когда я сажусь рисовать архитектуру нового бота, я сначала выбираю, где будет крутиться бэкенд и храниться RAG-память, а уж потом думаю, в каком интерфейсе он живёт — в Telegram, VK или на сайте.
На практике выбор сейчас крутится вокруг пары-тройки крупных облачных площадок: VK Cloud, Yandex Cloud, Ростелеком и несколько отраслевых дата-центров, которые умеют работать с ИСПДн. В них можно развернуть самописный бэкенд, векторную базу (open-source или коммерческую), крутить эмбеддинги и подключать российские LLM вроде GigaChat, YandexGPT или решений от крупных банков и ИТ-компаний. Хорошая новость в том, что многие из этих моделей уже имеют готовые SDK и интеграции с популярными фреймворками для чат-ботов, включая те, что любят автоматизаторы: n8n, Make-подобные решения, no-code конструкторы. Плохая — иногда приходится мириться с чуть большей задержкой ответа и меньшим количеством «магии», чем в западных аналогах, хотя для e-commerce это редко критично.
Я заметила, что удобнее всего строить связку из трёх типов инструментов. Во-первых, оркестратор потоков — тот же n8n, где удобно собирать пайплайны «Telegram запрос — бэкенд — LLM — ответ» без глубокого погружения в код. Во-вторых, отдельный модуль для работы с эмбеддингами и векторной базой, который можно обернуть в микросервис. В-третьих, интеграционный слой с CRM, складом, платёжными системами. Если смотреть со стороны владельца бизнеса, то вам критичнее всего, чтобы эти три уровня были прозрачны: чтобы вы понимали, куда ушёл запрос клиента, на каком этапе он сломался и что именно бот «помнит». Это одна из причин, по которой я осторожно отношусь к полностью чёрным ящикам «бот-платформа всё сделает», где непонятно ни где хранятся данные, ни как реализован RAG-слой.
Отдельно стоит сказать про интерфейсы. Многие приходят с запросом «как создать чат бот в телеграмме бесплатно», потому что Telegram в России стал де-факто стандартом оперативных коммуникаций. С технической точки зрения это удобно: у Telegram понятный Bot API, множество библиотек на популярных языках и куча примеров. Но с точки зрения данных бот в Telegram — это всего лишь фронтенд, а не место хранения. Ваша задача — принимать от него сообщения, обрабатывать их на своём сервере в российском облаке и хранить там же, а не мечтать, что весь бизнес живёт в Телеге. Когда мне приходится объяснять это владельцам магазинов, я иногда прямо рисую, как стрелочка от Telegram идёт в VK Cloud или Yandex Cloud, а дальше разветвляется в разные сервисы.
Я поняла, что любая рекомендация по стеку должна учитывать размер бизнеса и аппетиты к развитию. Для совсем небольших магазинов, которые только пробуют RAG, имеет смысл начать с относительно простого контура: один облачный сервер, на нём бэкенд, open-source векторная база и подключенная российская LLM по API. Для средних и крупных уже оправдано разделение на несколько сервисов, использование управляемых баз данных и выделенных контуров безопасности. Тут хорошо работает принцип «расти по мере необходимости»: не стоит начинать с архитектуры уровня маркетплейса, если у вас пока сотни заказов в месяц, но и держать всё на одном VPS без бэкапов и DLP уже странно.
Я как-то наблюдала, как магазин с оборотом в несколько миллионов в месяц хранил всю RAG-память и логи бота в SQLite-файле на одном сервере «потому что так проще». Когда сервер лёг, вместе с ним легла и вся «долгосрочная память». После этого они стали внимательнее относиться к выбору стека.
Как автоматизация через n8n и аналоги помогает не утонуть в интеграциях
Когда в архитектуре появляется RAG-память, количество «переходов» растёт: бот должен не только принимать сообщения и отвечать, но и дергать CRM, проверять склад, обновлять векторную базу, логировать действия для ИСПДн. Если всё это писать монолитом на одном языке, через пару месяцев вы будете бояться кода, как ремонта в ванной после неудачного мастера. В этом месте на сцену выходят инструменты вроде n8n, которые позволяют собрать значительную часть пайплайнов визуально и прозрачно. Я сама несколько раз спасала проекты тем, что выносила оркестрацию в n8n, а сложную логику и RAG-сервисы оставляла в коде, чтобы не пытаться объяснить всё в одной диаграмме.
На практике схема выглядит так: в n8n приходят вебхуки от Telegram-бота, дальше нода проверяет тип сообщения (текст, голос, кнопка), передаёт его в сервис эмбеддингов, получает от него ИД релевантных записей из векторной базы, дергает CRM и только потом собирает всё это в запрос к LLM. Ответ модели можно обогатить данными о наличии, актуальных ценах, сроках доставки и уже в готовом виде вернуть в Telegram. Преимущество такого подхода в том, что вы всегда видите, где что пошло не так: если вдруг зависла интеграция с CRM, n8n сразу это подсветит, а бот сможет честно ответить «у нас временно проблема с доступом к истории заказов, давайте я предложу базовые варианты». Это гораздо лучше, чем молчаливый крах всей системы с ощущением «бот опять тупит».
Я заметила, что ещё одно достоинство автоматизаторов — простая реализация фоновых задач. Например, вы можете раз в час обновлять эмбеддинги для новых товаров, раз в сутки пробегать по заказам и анонимизировать тех, у кого истёк срок хранения, или по требованию субъекта данных запускать удаление его следов из RAG-памяти. Такие процессы удобно собирать в отдельных нодах n8n, не смешивая их с боевыми диалогами. Это даёт редкое ощущение контроля: вы не просто «где-то храните векторы», а понимаете, как и когда они создаются, обновляются и удаляются, что особенно приятно при общении с безопасниками и аудиторами.
Понятно, что n8n и аналоги — это не серебряная пуля. Если пайплайны становятся слишком жирными, с десятками нод и веток, отлаживать их бывает не легче, чем код. Но для этапа, когда вы только собираете прототип RAG-бота для своего интернет-магазина и хотите проверить гипотезы, это прекрасный инструмент. В связке с российским облаком и LLM вы получаете достаточно гибкости, чтобы не зависеть от одной платформы и при этом не уехать в бесконечную разработку с нуля. Когда прототип начинает стабильно работать и приносить понятный эффект, часть логики можно постепенно переносить в более устойчивые микросервисы, оставляя n8n на стыке интеграций и фоновых задач.
В итоге стек для RAG-бота в России в 2026-м выглядит не так уж страшно: российское облако, LLM с поддержкой русского языка, векторное хранилище, оркестратор вроде n8n и аккуратная интеграция с вашими данными. Всё это уже сегодня можно собрать руками небольшой команды или даже силами одного упрямого инженера, если не пытаться прыгнуть сразу в космос и дать себе время на эволюцию.
Как построить процесс: от первой схемы до живого бота
Я поняла, что самое сложное в проектах чат-ботов для e-commerce — это даже не LLM и не 152-ФЗ, а момент «с чего начать, чтобы через три месяца не хотелось всё выбросить». Проще всего думать об этом как о продукте с несколькими итерациями, а не как о разовой интеграции. На первом шаге вы честно описываете, какие задачи должен решать бот: консультации по товарам, статус заказов, рекомендации, работа с возвратами. На втором — выбираете минимальный набор сценариев, с которых стартуете. На третьем — строите первую версию без RAG-памяти, просто на базе часто задаваемых вопросов и интеграции с CRM. И только когда это начинает стабильно работать, добавляете слой долгосрочной памяти и эмбеддингов, чтобы бот мог опираться на историю.
Вот как это выглядит на практике в живом проекте малого магазина. Неделя уходит на то, чтобы собрать список типовых вопросов клиентов: пролистать почту, посмотреть чаты менеджеров, выгрузить обращения из поддержки. Ещё пара дней — на то, чтобы разложить это по темам и решить, где вам критично человеческое участие, а где можно доверить всё боту. Обычно в первый релиз попадают консультации по наличию, размерной сетке, доставке и базовым возвратам. Дальше вы делаете простой Telegram-бот без памяти: подключаете его к CRM по API, обучаете на FAQ и даёте возможности живому оператору подхватывать сложные диалоги. Этот этап важен тем, что он даёт реальную статистику: сколько обращений, какая нагрузка, где бот ошибается, где люди злятся, а где благодарят.
Я заметила, что попытка сразу же запустить RAG-память без этого базового этапа обычно приводит к тому, что вы тратите время на оптимизацию того, что вообще не нужно. Вместо этого лучше через 3-4 недели работы простого бота снять метрики и только тогда проектировать, какие фрагменты истории нужно хранить. Например, можно выявить, что люди часто ссылаются на «как в прошлый раз», «как то пальто в октябре», «как те брюки, что вы мне советовали», и понять, что в RAG-память точно должны попадать предыдущие покупки с ключевыми параметрами. Такой подход экономит и ваши ресурсы, и вычислительные мощности, потому что вы храните и обрабатываете только то, что реально используется в диалогах.
Когда базовый сценарий отработан, начинается вторая итерация — проектирование RAG-слоя. Здесь я обычно сажусь с большой кружкой чая и рисую таблицу: какие события должны попадать в память (новый заказ, возврат, явное предпочтение по размеру или цвету), как они будут кодироваться в вектора, как долго храниться и как их связывать с клиентом. Дальше настраиваются сервисы эмбеддингов и векторная база, подключается обновление при каждом новом событии из CRM и магазина. На стороне бота меняется промпт: модель учится сначала запрашивать релевантные кусочки из RAG-хранилища и только потом формировать ответ, а не генерировать его из пустоты. Это та стадия, на которой бот начинает вести себя «по-человечески» и помнить прошлые контакты.
Мне нравится добавлять ещё один слой — прозрачность. В интерфейсе бота можно дать пользователю возможность увидеть, что именно он «помнит»: последний размер, последние заказы, предпочтения. Можно добавить команду «очистить память обо мне», которая запускает сценарий удаления данных из RAG-базы и связанных логов. Такой жест сильно повышает доверие клиентов: люди видят, что вы не держитесь за каждую крупицу их данных до конца света, а даёте контроль. Плюс это технически дисциплинирует вас: если команда удаления не работает, вы сразу это увидите в бою, а не во время проверки.
Я заметила, что без регулярных ревизий такой бот быстро обрастает «историческим мусором»: устаревшими промо, старыми условиями доставки, моделями, которых уже нет в продаже. Поэтому в процесс хорошо бы встроить ежемесячные и квартальные циклы. Раз в месяц вы смотрите на логи, где бот запутался, анализируете жалобы клиентов и корректируете промпты, сценарии и RAG-память. Раз в квартал — проводите небольшой аудит: соответствуют ли цели обработки фактическому использованию данных, не расширился ли список собираемых параметров, не пора ли сократить срок хранения каких-то фрагментов. Это звучит бюрократично, но на практике спасает от снежного кома проблем, который иначе вылезет через год с сообщением «наш бот давно живёт своей жизнью».
У меня был случай, когда бот полгода продолжал предлагать бесплатную доставку от суммы, которая уже давно выросла. Просто потому, что никто не заложил регулярный пересмотр правил. Клиенты радовались, бухгалтерия — не очень.
Как тестировать RAG-бота, чтобы не стыдиться на проде
Когда техническая часть кажется более-менее готовой, всегда появляется соблазн «включить всем и посмотреть». Опыт научил меня, что лучше потратить неделю на осмысленное тестирование, чем потом месяц выслушивать жалобы и править репутацию. Я обычно делю тесты на три слоя: функциональные, регуляторные и пользовательские. В функциональных проверяю, что бот корректно тянет историю заказов, понимает ссылки на прошлые диалоги, не путает клиентов между собой и не ломается от опечаток и странных формулировок. В регуляторных — что логи не содержат лишних персональных данных, что RAG-база действительно хранит только то, что мы описали в документации, что запросы к внешним сервисам не уезжают за пределы РФ.
Отдельное удовольствие — пользовательские тесты. Я обычно прошу пару знакомых, которые не трогали проект, пообщаться с ботом так, как они это делали бы в реальной жизни: с эмоциями, с «ой, не то, перепутала», с голосовыми. Потом разбираем диалоги: где бот выглядел естественно, а где было ощущение скрипта или непонятной механики. Особенно ценны случаи, когда люди начинают использовать бота неожиданным образом, например, просить посоветовать образ «на тёплую осень с внезапным снегом» или задавать несколько вопросов подряд без паузы. Такие сценарии хорошо подсвечивают, насколько гибко работает RAG-слой и не ломается ли всё при выходе за идеальный путь.
Я поняла, что тестирование RAG-бота — это не разовое событие, а постоянный процесс. После запуска стоит настроить мониторинг базовых метрик: доля успешных ответов без участия оператора, среднее время ответа, число эскалаций на человека, частота команд «очистить память», количество жалоб на некорректные рекомендации. Эти цифры быстро становятся вашим главным аргументом и в разговорах с командой, и в общении с руководством, если вы не единственный собственник. Когда видно, что доля диалогов, закрываемых ботом, растёт, а количество конфликтных случаев падает, скепсис по поводу «очередной игрушки с ИИ» обычно рассасывается.
В результате вы получаете не просто бота «как у всех», а управляемый процесс, где каждая следующая итерация основана на данных и обратной связи, а не на слепой вере в нейросети. Да, это требует дисциплины и привычки смотреть в отчёты, но зато через полгода-год у вас будет неодноразовый проект, а живая система, которая растёт вместе с вашим магазином и не превращается в динозавра.
Каких рисков бояться и где e-commerce чаще всего ошибается
Когда ко мне приходят с вопросом «как создать чат бот самостоятельно бесплатно» и при этом «чтобы всё по закону», я уже заранее знаю, какие грабли всплывут в разговоре. Первая ошибка — это вера в то, что согласие на обработку персональных данных можно спрятать где-то внизу страницы или в чеке, и этого всем хватит. В 2025-2026 годах регулятор прямо говорит, что согласие должно быть отдельным, конкретным, а для многих сценариев обработки достаточно иного основания — договора или законного интереса. RAG-память для персонализации рекомендаций в интернет-магазине вполне может обосновываться договором купли-продажи и законным интересом бизнеса, если вы честно описываете это в политике и не расширяете сбор данных «на всякий случай».
Я заметила, что вторая типичная ошибка — собирать и хранить слишком много. Есть соблазн «ложить в память всё», включая свободный текст, эмоциональные сообщения, иногда даже фотографии и голосовые, чтобы потом «научить модель понимать клиента». В реальности для нормальной работы RAG-слоя достаточно структурированных фактов и семантических представлений запросов. Каждый лишний кусочек данных — это не только место на диске, но и дополнительный риск при утечке или проверке. Роскомнадзор смотрит не только на утечки, но и на избыточный сбор, и задаёт неприятные вопросы, если видит, что вы храните данные, которые никак не связаны с целями обработки.
Третий частый риск — трансграничная передача через «незаметные» сервисы. Кто-то использует зарубежный сервис распознавания речи для голосовых сообщений, кто-то — иностранную платформу аналитики, которая собирает логи диалогов, кто-то — облако для резервного копирования, находящееся вне РФ. На бумаге всё красиво, а по факту персональные данные вылетают за границу, иногда без достаточного правового основания. В 2026-м такие вещи всё чаще всплывают при проверках, потому что многие зарубежные сервисы открыто указывают в договорах юрисдикцию и местоположение серверов, а автоматизированные сканеры легко находят вызовы к внешним API на сайте или в коде.
Четвёртый слой рисков — технический. Я уже видела несколько проектов, где RAG-база и логи диалогов лежали без шифрования, доступ к ним был возможен по паролю «123456», а бэкапы не делались месяцами. При этом в компании честно были назначены ответственные за ПДн и написаны красивые положения, которые никто не читал. Противоречие между бумажной и реальной безопасностью — то, что проверяющие чувствуют почти интуитивно. Если у вас в документах написано, что данные шифруются, а по факту они лежат в открытом виде в БД без каких-либо СЗИ, это повод для серьёзного разговора и штрафов. Поэтому я всегда повторяю: лучше иметь честно описанную, но скромную защиту, чем нарисованный «идеальный контур», который не реализован.
Пятая ошибка — недооценка репутационных последствий. Даже если вам удастся договориться по штрафам или уйти с предупреждением, новость о том, что у интернет-магазина утекли переписки с ботом, где люди делились размерами, предпочтениями и какими-то личными деталями, быстро разойдётся. В эпоху соцсетей и мессенджеров информационный удар иногда бьёт сильнее финансового, особенно для небольших брендов, которые строят отношения с клиентами на доверии. Поэтому, когда вы принимаете решение «сэкономить на шифровании» или «отложить настройку DLP», стоит помнить, что вы играете не только бюджетом этого квартала, но и лояльностью людей, которые к вам возвращаются.
Я однажды слышала фразу от коллеги: «ну что там в этих чатах, ничего страшного». Через полгода у них всплыла утечка, и скриншоты с обсуждениями телосложения и размеров клиентов очень быстро оказались в публичных каналах. После этого они стали большим фанатом шифрования.
Какие юридические мифы до сих пор мешают делать нормальных ботов
Я часто сталкиваюсь с тем, что юридический блок проекта живёт на наборе мифов. Например, кто-то искренне считает, что если магазин маленький, то можно не уведомлять Роскомнадзор о начале обработки персональных данных. Или что использование чат-бота в Telegram автоматически снимает с вас ответственность за хранение данных, потому что «это же Телега, а не мы». В реальности закон смотрит на фактическую обработку и на то, кто определяет цели и средства обработки. Если вы решаете, что бот собирает, как обрабатывает и где хранит историю диалогов, вы — оператор, вне зависимости от масштаба бизнеса.
Ещё один упорный миф — про согласие как универсальный костыль. Многие до сих пор пытаются подложить под все виды обработки одно общее согласие, в котором перечислено всё: от доставки до передачи партнёрам и использования в маркетинге и RAG-памяти. На практике такой документ нельзя считать конкретным и информированным, особенно с учётом новых подходов регулятора. Гораздо честнее и безопаснее разделить цели: отдельные условия договора и политика для обслуживания заказа, отдельные механизмы для маркетинговых рассылок, понятное описание RAG-памяти и сроков хранения. Да, это чуть сложнее в текстах, но зато понятно и для клиентов, и для проверяющих.
Есть и обратный крен, когда из страха перед 152-ФЗ бизнес вообще отказывается от персонализации, храня только минимальные сведения и удаляя всё через неделю. В итоге страдает и клиентский опыт, и экономика: вы сами добровольно отказываетесь от тех 20-30% прироста удержания, которые даёт осмысленная работа с данными. Здесь помогает трезвый диалог с юристом или консультантом по privacy: определить, какие данные действительно критичны, как их можно обезличить или псевдонимизировать, какие сроки хранения разумны и как правильно оформить процессы удаления. Задача не в том, чтобы «ничего не собирать», а в том, чтобы собирать ровно столько, сколько нужно для сервиса.
Я иногда слышу и про миф «если всё хранится в облаке крупного провайдера, то он за всё отвечает». Увы, нет. Облако — это просто инструмент, а оператором остаётся тот, кто решил, какие именно персональные данные туда положить, с какими целями и как долго их там держать. Облако может быть соисполнителем или привлечённым лицом, но ответственность за общую архитектуру обработки лежит на вас. Поэтому выбор провайдера — это только половина истории, вторая половина — это ваши настройки доступа, шифрования, логирования и процедуры реагирования на инциденты.
Когда эти мифы постепенно рассыпаются, становится гораздо проще строить внятные, а не «прячу голову в песок» архитектуры RAG-ботов. И разговор «как создать чат бот в тг» переезжает из плоскости «лишь бы работало» в плоскость «как сделать, чтобы работало и не прилетело». Это немного скучнее как история, зато сильно спокойнее как бизнес.
Какие результаты ждать и как мерить пользу от такого бота
Я заметила, что разговоры про чат-боты часто ломаются на вопросе «а оно вообще окупится». В презентациях любят рисовать фантастические ROI в сотни процентов за пару недель, но в реальном e-commerce в России картина скромнее, хотя и вполне приятная. Когда вы внедряете RAG-бота с долгосрочной памятью, первые ощущения обычно не про деньги, а про дыхание команды: уменьшается вал однотипных запросов, менеджеры поддержки перестают гореть, люди перестают по ночам отвечать в личных мессенджерах клиентам «а есть ли 44 размер в синем». Но если подождать 3-6 месяцев и аккуратно собрать цифры, всё становится проявляться в метриках.
На практике я смотрю на три группы показателей. Первая — операционная: время ответа на запрос, доля обращений, закрываемых ботом без участия человека, средняя длина диалога до решения вопроса. Вторая — продуктовая: конверсия в покупку после диалога с ботом, доля повторных покупок среди тех, кто взаимодействовал с RAG-слоем, средний чек. Третья — качественная: NPS по обслуживанию, количество жалоб, отзывы о боте. Если RAG-память настроена осмысленно, через полгода можно увидеть рост удержания на 15-30%, снижение нагрузки на поддержку на 20-40% и лёгкий рост среднего чека за счёт более точных рекомендаций. Это не сказка про «удвоили выручку за месяц», но очень достойный эффект для устойчивого бизнеса.
Важно, что для честной оценки нужно отделять влияние самого факта наличия бота от влияния именно RAG-памяти. Я обычно делаю так: первые 1-2 месяца работает бот без долгосрочной памяти, только с FAQ и CRM, и собираются базовые метрики. Потом включается RAG-слой, и мы смотрим, как меняются показатели именно в сценариях, где память может сыграть роль — повторные обращения, ссылки на прошлые покупки, персональные рекомендации. Такой A/B-подход позволяет не приписывать RAG-слою заслуги, которые на самом деле даёт просто круглосуточная доступность бота. И наоборот, не ругать память за то, что она «не увеличила трафик», потому что это вообще из другой оперы.
Я поняла, что ещё один полезный показатель — количество ситуаций, когда бот честно признаётся в ограничениях. Например, «я не вижу у вас прошлых заказов, потому что они старше двух лет» или «я не запоминаю такие детали, давайте уточним ещё раз». Такие фразы показывают, что вы не пытаетесь создать иллюзию всеведения, а честно обозначаете границы. Люди в большинстве своём это ценят: им комфортнее понимать, что бот не превращается в Большого Брата, а работает в рамках разумной памяти. Плюс это снижает риск конфликтов, когда клиент вдруг ожидает, что система помнит его покупки десятилетней давности, а вы по политике хранения уже давно всё удалили.
В деньгах всё складывается примерно так. Допустим, у вас небольшой интернет-магазин, который тратит на поддержку и обработку заказов 100-150 тысяч в месяц (менеджеры, частичная аутсорс-поддержка). Внедрение RAG-бота с учётом разработки, настройки облака, описания процессов может стоить в районе нескольких сотен тысяч рублей и занять 2-3 месяца. Если в результате бот возьмёт на себя 30-50% типовых вопросов, а повторные покупки вырастут пусть на те же 15-20%, то за полгода-год проект обычно отбивается. Главное, что эта окупаемость идёт не только через экономию, но и через рост выручки, а это гораздо приятнее, чем просто «сократили одного сотрудника».
Я, честно, больше всего радуюсь не моменту «проект отбился», а моменту, когда менеджер пишет «я впервые за квартал успела спокойно пообедать, потому что бот снял весь утренний завал вопросов про доставку». Эти вещи в отчёты не попадают, но для выгорания команды значат очень много.
Как встроить аналитику и не утонуть в цифрах
Когда бот начинает жить своей жизнью, легко попасть в другую крайность — собирать всё подряд и не понимать, что с этим делать. Я стараюсь начинать с минимального набора дашбордов: число диалогов в день, доля диалогов, закрытых ботом, среднее время ответа, CSAT по итогам общения. Всё это можно реализовать либо через встроенные механизмы чат-платформ, либо через отдельный модуль аналитики в вашем бэкенде. Ключевой момент здесь — разделять операционный мониторинг и продуктовые инсайты. Первое нужно, чтобы понимать, что бот «жив», второе — чтобы улучшать сценарии и RAG-память.
Я заметила, что хорошо работает еженедельный ритуал: собирать команду или хотя бы ответственных за бота и за 30-40 минут проходиться по основным показателям и паре конкретных диалогов. Одно дело смотреть на средний CSAT, другое — на живые письма клиентов вроде «спасибо, что бот помнил, что я не люблю синтетику» или «меня смутило, что бот вспомнил, что я заказывала это мужу». Такие истории помогают калибровать, где граница между полезной персонализацией и ощущением избыточного знания. Иногда одно такое письмо может инициировать пересмотр того, какие именно факты попадают в RAG-память, и это нормально: продуктовая работа редко бывает статичной.
По мере взросления проекта имеет смысл добавлять более сложные срезы. Например, смотреть на эффективность RAG в разных категориях товаров, сравнивать метрики по новым и возвращающимся клиентам, анализировать, как меняется поведение людей после первого позитивного опыта общения с ботом. Для телеграм-ботов удобно использовать тегирование диалогов и событий, чтобы потом строить вменяемую аналитику по сценариям. Да, на это уходит время, но именно здесь рождаются идеи, которые потом превращаются в новые версии бота, более точные рекомендации и аккуратные эксперименты с допродажами.
В итоге RAG-бот перестаёт быть просто «штукой, которая отвечает в чате», и превращается в источник данных о том, как люди реально думают и говорят о вашем товаре. Это уже уровень, на котором вы можете не только отвечать на запросы, но и улучшать ассортимент, логистику и интерфейсы на сайте, опираясь на живой язык клиентов, а не на абстрактные портреты из презентаций.
Что ещё важно знать про RAG-ботов в 2026-м
Я иногда ловлю себя на мысли, что вокруг RAG и чат-ботов образовался лёгкий ореол «слишком сложно для обычного магазина». Мол, это удел крупных сетей, у которых есть свои ИТ-отделы, юристы и бюджеты на консалтинг. По факту в 2026-м порог входа уже сильно снизился: есть российские облака с готовыми LLM, есть open-source для векторных баз, есть удобные оркестраторы, есть комьюнити, где люди делятся реальными наработками. Но есть и другая сторона — ответственность. Как только вы начинаете автоматизировать общение с клиентами на таком уровне, вы становитесь не только владельцем магазина, но и оператором достаточно серьёзной ИСПДн со своей архитектурой, журналами и процедурами.
Я заметила, что помогает относиться к этому спокойно следующая рамка. Считать RAG-бота частью своей операционной системы, а не отдельным «AI-проектом». Тогда все вопросы о том, как уведомлять Роскомнадзор, как описывать цели обработки, как настраивать безопасность, ложатся в уже знакомые категории «как мы работаем с CRM» или «как мы используем систему рассылок». Разница только в том, что здесь добавляется слой генерации текста и векторных представлений, который даёт боту возможность звучать по-человечески и помнить контекст. Всё остальное — про те же дисциплину, прозрачность и уважение к клиенту, что и в любой другой части бизнеса.
Для тех, кто хочет копнуть глубже, я обычно предлагаю двигаться в двух направлениях. Первое — прокачать понимание архитектуры и автоматизации: как строятся пайплайны, как использовать n8n и аналогичные инструменты, как тестировать ИИ-агентов и делать им ревью промптов. Здесь хорошо помогают разборы реальных кейсов, и часть таких историй я регулярно выкладываю в своём Telegram-канале про практическую автоматизацию и AI-агентов MAREN, где мы без пафоса обсуждаем, как это работает в живом бизнесе. Второе направление — укрепить базу по privacy и 152-ФЗ: понять разницу между согласиями и законными интересами, освоить минимальный набор документов, научиться говорить с безопасниками на одном языке.
Я поняла, что именно на стыке этих двух тем — автоматизации и управления данными — рождаются самые устойчивые решения. Когда инженеры понимают, зачем им нужны уровни доступа и сроки хранения, а юристы представляют себе, что такое эмбеддинги и векторная база, проекты получаются и рабочими, и юридически аккуратными. Это тот случай, когда между отделами выгоднее строить мост, а не стену. Если чувствуешь, что таких мостов не хватает, можно начать с малого: обсудить текущую архитектуру бота с кем-то, кто уже прошёл этот путь, или заглянуть на сайт про MAREN и мои проекты по AI-автоматизации, чтобы посмотреть, как мы решаем похожие задачи для разных команд.
В итоге RAG-бот с долгосрочной памятью в 2026-м — это уже не футуризм, а нормальный рабочий инструмент для e-commerce в России. Да, он требует больше внимания на старте, чем простая форма обратной связи, но и отдача у него другого уровня. Он не устает к утру, не забывает про размер 46 и нелюбовь к синтетике, не просит отпуск и не уходит к конкурентам. Зато он честно живёт по тем правилам, которые вы ему задали — и по технической архитектуре, и по 152-ФЗ. И здесь всё зависит уже не от «магии AI», а от того, насколько аккуратно вы эти правила продумаете и опишете.
Что ещё может пригодиться тем, кто строит таких ботов
Как создать чат бота в телеграмме самостоятельно для интернет-магазина одежды
Сначала нужно зарегистрировать бота через BotFather в Telegram и получить токен, потом настроить вебхук на свой сервер в российском облаке, где будет жить бэкенд и логика диалогов. Далее подключаете бота к своей CRM и базе товаров, добавляете обработку типовых вопросов, а уже потом настраиваете RAG-память и долгосрочное хранение предпочтений. Весь процесс можно собрать либо в коде, либо частично через оркестратор вроде n8n, если не хочется погружаться в программирование с нуля.
Можно ли создать чат бот самостоятельно бесплатно, если бюджет совсем небольшой
Теоретически можно, если использовать бесплатные тарифы облаков, open-source векторные базы и ограничиться минимальным набором функций. На практике основные затраты будут во времени: нужно разобраться с API Telegram, с базовой безопасностью, с архитектурой RAG и 152-ФЗ. Для самых маленьких магазинов имеет смысл начинать с простого бота без RAG и уже по мере роста добавлять долгосрочную память и интеграции.
Как создать чат бот в тг и при этом не нарушить 152-ФЗ в 2026 году
Нужно заранее описать, какие персональные данные бот обрабатывает, с какими целями и где они хранятся, уведомить Роскомнадзор как оператора и локализовать базы на серверах в России. В технической части важно не хранить лишние данные, шифровать хранилища, ограничивать доступ и не отправлять персональные данные в зарубежные сервисы без основания. RAG-память стоит строить на обезличенных эмбеддингах и привязке к ИД заказов, а не к открытым ФИО и телефонам в явном виде.
Что делать, если клиент просит удалить всю память о себе из чат-бота
Нужно реализовать процесс, который удаляет или обезличивает данные клиента и в основной базе, и в RAG-памяти, и в логах диалогов, насколько это возможно. Желательно предусмотреть в интерфейсе команду или форму для такого запроса, а внутри компании прописать порядок действий и сроки. После выполнения удаления полезно сохранить служебную отметку о том, что обработка завершена, без хранения самих исходных данных.
Как понять, что RAG-память в боте действительно даёт эффект, а не просто усложняет систему
Нужно сравнить метрики до и после включения RAG-слоя: долю повторных покупок, конверсию после диалога, количество обращений «как в прошлый раз», время на решение типовых вопросов. Если после появления долгосрочной памяти растёт удержание клиентов, падает нагрузка на поддержку и уменьшается число повторных разъяснений, значит, RAG работает по назначению. Если изменений нет или они отрицательные, имеет смысл пересмотреть, какие данные вы храните и как бот их использует в диалоге.
Можно ли обойтись без программиста и сделать такого бота целиком в конструкторах
Базовый чат-бот с кнопками и FAQ можно собрать в конструкторах, но для RAG-памяти, интеграции с CRM и соблюдения 152-ФЗ почти всегда нужен хотя бы минимальный инженерный ресурс. Даже если интерфейс и часть логики делаются на no-code, работу с эмбеддингами, векторной базой и безопасностью лучше доверить человеку, который умеет думать архитектурно. Это не значит, что нужен целый ИТ-отдел, но один толковый специалист сильно снизит риски и ускорит запуск.