Veltos.Tech

AI и ML

ИИ-ассистент на своей базе знаний: как работает RAG и сколько стоит внедрение

Разбираем, чем RAG-ассистент отличается от бота с кнопками и от LLM без данных, откуда берутся галлюцинации и что их реально снижает, сколько стоит SaaS против кастомной разработки и на каком месяце проект выходит в ноль.

Коротко

RAG-ассистент ищет ответ в ваших документах и отвечает по найденному фрагменту со ссылкой на источник. Рыночные цены: SaaS-платформы от ~59 000 ₽ в месяц, кастомная разработка от ~500 000 ₽ плюс поддержка 10 000–50 000 ₽ в месяц. Veltos.Tech делает AI/ML-проекты от 180 000 ₽. При 3000 обращений в месяц окупаемость наступает на 11–12 месяце.

Четыре поколения ботов и почему первые два разочаровали

Первое поколение — сценарный бот с кнопками. Он работал ровно в тех ветках, которые кто-то заранее нарисовал, и любой вопрос вне дерева упирался в «выберите один из вариантов». Пользователи быстро научились нажимать «связаться с оператором» первым же действием, и в отчётах это выглядело как высокая нагрузка на поддержку при работающем боте. Такие боты не бесполезны, но они автоматизируют навигацию, а не ответы.

Второе поколение — бот на большой языковой модели без доступа к вашим данным. Он говорит грамотно, поддерживает любую тему и на вопрос «какой у вас срок доставки в Новосибирск» уверенно называет срок, которого не существует. Это и есть главная проблема второго поколения: красивая форма без знания фактов. В корпоративной поддержке такой ответ хуже отсутствия ответа, потому что клиент ему верит и строит на нём свои действия.

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

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

Как на самом деле работает RAG

Начинается всё с подготовки базы. Документы — регламенты, инструкции, описания товаров, база вопросов — режутся на фрагменты по несколько сотен слов, обычно с перекрытием, чтобы мысль не обрывалась посередине. Разбиение важнее, чем кажется: слишком крупные куски приносят в ответ много лишнего и путают модель, слишком мелкие теряют контекст, из-за чего фрагмент перестаёт быть понятным сам по себе. На этом этапе решается половина будущего качества.

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

Дальше найденные фрагменты подставляются в промпт вместе с вопросом, и языковая модель формулирует ответ, опираясь на этот контекст. Ключевая инструкция в промпте — отвечать только по предоставленным материалам и прямо сообщать, если ответа в них нет. Финальный шаг — цитирование: к ответу прикладывается ссылка на документ и раздел. Это не украшение, а механизм контроля: пользователь может проверить, а вы можете разобрать любой спорный ответ по логам.

Логичный вопрос: почему не дообучить модель на своих данных? Для большинства бизнес-задач RAG выигрывает по трём причинам. Обновление: чтобы изменить ответ, достаточно заменить документ в базе, а не запускать переобучение. Прозрачность: RAG показывает источник, дообученная модель — нет, и разобрать её ошибку принципиально сложнее. Стоимость: подготовка и запуск RAG измеряются неделями, качественное дообучение — месяцами и требует объёма данных, которого у большинства компаний просто нет.

  • Разбиение на фрагменты: несколько сотен слов с перекрытием, по смысловым границам, а не по числу символов.
  • Эмбеддинги и векторное хранилище: поиск по смыслу вместо совпадения слов.
  • Промпт с найденным контекстом и запретом отвечать за его пределами.
  • Цитирование источника — механизм проверки, а не оформление ответа.
  • Обновление знаний через замену документа, без переобучения модели.

Откуда берутся галлюцинации и что реально их снижает

Первый источник ошибок — вовсе не модель, а база. Если в компании лежат три версии регламента возврата, две устаревшие и одна актуальная, поиск честно найдёт любую из трёх, и ассистент честно процитирует неверную. Это самый частый и самый недооценённый случай: система работает правильно, а отвечает неправильно, потому что источник противоречив. Поэтому первая работа в проекте — не промпты, а инвентаризация документов, удаление дублей и назначение владельца каждого раздела базы.

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

Третий контур защиты — передача человеку. Ассистент должен уметь эскалировать: при отказе, при повторном непонятом вопросе, при явном раздражении пользователя, при теме из стоп-листа (деньги, юридические обязательства, персональные данные). Правильная эскалация передаёт оператору собранный контекст, а не начинает разговор с нуля. Это заметно влияет на восприятие: клиента раздражает не то, что бот не смог, а то, что после бота приходится рассказывать всё заново.

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

Полная модель стоимости: SaaS против кастомной разработки

На рынке есть два принципиально разных пути. Готовая SaaS-платформа: вы загружаете документы, настраиваете виджет, платите помесячно. Рыночные тарифы для бизнес-использования начинаются примерно от 59 000 ₽ в месяц и растут в зависимости от объёма запросов и числа каналов. Кастомная разработка: система строится под ваши процессы и интеграции, рыночная стоимость начинается примерно от 500 000 ₽, поддержка — 10 000–50 000 ₽ в месяц. В Veltos.Tech AI/ML-проекты начинаются от 180 000 ₽, и в этом бюджете обычно делается пилот на одном процессе с ограниченной базой знаний.

Обе оценки почти всегда занижены, потому что в них не входит самая трудоёмкая часть — подготовка базы знаний. Документы нужно собрать из разных мест, привести к разбираемому формату, убрать дубли и устаревшие версии, разделить внутреннее и клиентское, назначить владельцев. На средней компании это две-четыре недели работы, и делать её должен человек, знающий предметную область, а не подрядчик. Проекты, которые провалились, чаще всего провалились именно здесь, а не на технике.

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

Третья и четвёртая статьи — интеграции и контроль качества. Ассистент, не связанный с CRM и учётной системой, отвечает только на общие вопросы, а на «где мой заказ» ответить не может; интеграция превращает справочник в рабочий инструмент и обычно составляет заметную часть сметы. Контроль качества — постоянная работа, описанная выше: просмотр выборки, разбор ошибок, обновление документов. Если этой строки нет в бюджете, она всё равно появится, просто в виде претензий от клиентов.

Статья затратSaaS-платформаКастомная разработкаКомментарий
Запуск системыНастройка за несколько дней, часто входит в тарифот ~500 000 ₽ на рынке, пилот от 180 000 ₽Кастом окупается объёмом и интеграциями
Подготовка базы знаний2–4 недели работы на вашей стороне2–4 недели, часть можно передать подрядчикуСамая недооценённая статья в обоих вариантах
Лицензия или подпискаот ~59 000 ₽ в месяц по рынкуНетРастёт с объёмом запросов и числом каналов
Запросы к моделиОбычно в тарифе, сверх лимита — доплатаОплата по факту, считать с запасом ×2В RAG в промпт уходит контекст, а не только вопрос
Интеграции с CRM и учётной системойТолько если поддерживаются платформойЛюбые, отдельная строка сметыБез них ассистент не ответит «где мой заказ»
Контроль качестваОтчёты платформы плюс ваш просмотр выборкиСобственные метрики и логи с источникамиНесколько часов в неделю, постоянно
Поддержка и доработкаВходит в подписку10 000–50 000 ₽ в месяц по рынкуБаза знаний меняется чаще, чем код
Размещение данныхЗависит от платформы, требует проверкиПолный контроль, возможен on-premКритично при персональных данных и 152-ФЗ
Статьи затрат на ИИ-ассистента: SaaS и кастомная разработка, рыночные ориентиры

Расчёт окупаемости на конкретном сценарии

Формула окупаемости простая: экономия равна стоимости обращения, умноженной на объём, на долю автоматизируемых тем и на качество автоматизации, минус совокупная стоимость владения. Разберём её на условном, но типичном сценарии: поддержка получает 3000 обращений в месяц, оператор тратит на обращение около восьми минут, полная стоимость часа оператора — примерно 500 ₽. Значит одно обращение стоит компании около 70 ₽, а вся поддержка — порядка 210 000 ₽ в месяц.

Дальше два коэффициента, которые обычно завышают. Доля обращений, ответ на которые действительно есть в базе знаний, реалистично составляет около 60% — остальное требует данных из систем или решения человека. Из этих 60% ассистент закрывает без участия оператора примерно 70%: часть пользователей всё равно уйдёт к человеку, часть вопросов окажется сформулирована слишком сложно. Итого автоматизируется около 1260 обращений в месяц, что даёт экономию порядка 88 000 ₽ в месяц.

Теперь стоимость владения. Для кастомного решения: разработка 600 000 ₽ единовременно и около 35 000 ₽ в месяц на запросы к модели, инфраструктуру и контроль качества. Чистая экономия получается около 53 000 ₽ в месяц, а точка безубыточности — примерно одиннадцатый-двенадцатый месяц. Для SaaS: подготовка базы 150 000 ₽ и 59 000 ₽ подписки в месяц, чистая экономия около 29 000 ₽ в месяц и окупаемость на пятом-шестом месяце.

Самое интересное в этом сравнении — не то, что SaaS окупается быстрее, а то, где пути пересекаются. Совокупные затраты сравниваются примерно на девятнадцатом месяце: до этого дешевле подписка, после — собственное решение. Отсюда практический вывод: если горизонт планирования меньше полутора лет или объём обращений невелик, начинать надо с SaaS, и это честная рекомендация вне зависимости от того, кто её даёт. Кастомная разработка оправдана объёмом, интеграциями и требованиями к размещению данных, а не желанием иметь своё.

ПараметрЗначениеКомментарий
Обращений в месяц3000Ниже 1000 экономика обычно не сходится
Стоимость обработки одного обращения≈ 70 ₽ (8 минут при 500 ₽ за час)Считать полную стоимость часа, а не оклад
Текущая стоимость поддержки≈ 210 000 ₽ в месяцБаза для сравнения
Доля тем, покрытых базой знаний60%Остальное требует данных из систем или человека
Доля закрытых без оператора70% от покрытых темРеалистичный, а не рекламный коэффициент
Экономия в месяц≈ 88 000 ₽1260 обращений × 70 ₽
Кастом: вложения и эксплуатация600 000 ₽ + 35 000 ₽ в месяцЧистая экономия ≈ 53 000 ₽ в месяц
Кастом: точка безубыточности11–12 месяцДальше экономия накапливается
SaaS: вложения и подписка150 000 ₽ + 59 000 ₽ в месяцЧистая экономия ≈ 29 000 ₽ в месяц
SaaS: точка безубыточности5–6 месяцБыстрее, но потолок экономии ниже
Пересечение путей по совокупным затратам≈ 19 месяцДо него выгоднее SaaS, после — своё решение
Расчёт окупаемости на условном сценарии: 3000 обращений в месяц

Данные и закон: где всё хранится

Первый вопрос, который стоит задать до выбора платформы: какие данные вообще попадут в систему. Если ассистент отвечает только по публичным материалам — описаниям услуг, условиям доставки, инструкциям — правовой режим простой. Как только в диалог попадают имя, телефон, номер заказа или содержание обращения конкретного клиента, вы обрабатываете персональные данные, и к системе применяются требования 152-ФЗ, включая обязанность хранить их в базе, расположенной на территории России.

Отсюда практические ограничения. Зарубежные SaaS-платформы для поддержки с персональными данными в большинстве случаев не подходят без отдельной юридической проработки. Отправка фрагментов переписки во внешний API зарубежной модели — тоже обработка, и её нужно оценивать. Рабочие варианты: российские модели, доступные по API из отечественных облаков; открытые модели, развёрнутые в вашем контуре; либо архитектура, в которой персональные данные вырезаются из запроса до отправки во внешний сервис.

On-prem-развёртывание перестало быть экзотикой: открытые модели среднего размера работают на одном сервере с видеокартой и дают качество, достаточное для задач поддержки на своей базе знаний. Плата за это — стоимость железа или его аренды, работа по обновлению и заметно более высокие требования к команде. Разумная логика выбора: чем чувствительнее данные и чем больше объём запросов, тем сильнее аргументы в пользу собственного контура; для небольшой публичной базы знаний он избыточен.

Внедрение: пилот, метрики, масштабирование

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

Метрики нужны трёх видов. Покрытие: какая доля вопросов получила ответ, а не отказ. Качество: какая доля ответов правильна по оценке человека на выборке, — именно оценка человека, а не автоматическая метрика, потому что уверенно сформулированный неверный ответ автоматика не отличит. И бизнес-метрика: доля диалогов, завершившихся без оператора, и изменение времени первого ответа. Третья группа решает судьбу проекта, первые две объясняют, почему получилось так.

Масштабирование идёт по двум осям: новые темы в базе знаний и новые каналы. Расширять лучше по одной оси за раз, чтобы падение качества можно было объяснить. И почти всегда более выгодная ось — не новый канал, а переход от ответов к действиям: ассистент, который умеет проверить статус заказа и создать заявку, снимает нагрузку сильнее, чем тот же ассистент, добавленный ещё в один мессенджер.

Когда не надо делать вообще. Первое: маленький объём — при паре сотен обращений в месяц никакая экономия не покроет стоимость владения, и честный ответ здесь «пока не нужно». Второе: хаотичная база знаний — если актуальных документов нет, а знания живут в головах, сначала нужно навести порядок, и это отдельный проект, который полезен сам по себе. Третье: нет владельца — если после запуска никто не отвечает за актуальность базы и разбор ошибок, система деградирует за несколько месяцев и превратится в источник неверных ответов от имени компании.

  • Пилот: одна тема, один канал, 4–6 недель, критерии успеха до старта.
  • Метрики: покрытие, качество по человеческой оценке, доля диалогов без оператора.
  • Расширение по одной оси за раз: сначала темы, потом каналы.
  • Переход от ответов к действиям даёт больше, чем ещё один канал.
  • Не начинать при объёме менее ~1000 обращений в месяц или без владельца базы знаний.

Частые вопросы

Сколько стоит чат-бот для бизнеса на основе ИИ?

На российском рынке готовые SaaS-платформы для бизнеса начинаются примерно от 59 000 ₽ в месяц, кастомная разработка — примерно от 500 000 ₽ плюс поддержка 10 000–50 000 ₽ в месяц. В Veltos.Tech AI/ML-проекты начинаются от 180 000 ₽, и в этом бюджете обычно делается пилот на одном процессе. К любой из этих цифр нужно прибавить подготовку базы знаний — две-четыре недели работы на вашей стороне, которую нельзя полностью передать подрядчику, потому что она требует знания предметной области.

Чем RAG лучше дообучения модели на своих данных?

Тремя вещами. Обновление: чтобы изменить ответ, вы заменяете документ в базе, а не запускаете переобучение — это часы вместо недель. Прозрачность: RAG показывает, из какого документа взят ответ, поэтому спорный случай можно разобрать, а у дообученной модели источник восстановить нельзя. Стоимость и данные: качественное дообучение требует объёма примеров, которого у большинства компаний нет, тогда как RAG работает уже на существующих регламентах и инструкциях, ничего дополнительно не размечая.

Как избежать того, что бот выдумывает ответы?

Полностью — никак, но довести до приемлемого уровня можно четырьмя мерами. Привести базу знаний в порядок: одна актуальная версия каждого документа, без дублей и противоречий. Поставить порог релевантности, ниже которого система считает, что ничего не нашла. Явно разрешить и требовать ответ «в базе нет информации по этому вопросу» вместо попытки помочь. И включить обязательную передачу человеку по стоп-темам и после второго непонятого вопроса. Плюс логирование с еженедельным разбором выборки — без него всё остальное со временем перестаёт работать.

Через сколько ИИ-ассистент окупается?

Для типового сценария с 3000 обращений в месяц кастомное решение выходит в ноль примерно на 11–12 месяце, SaaS — на 5–6, но с более низким потолком экономии. Совокупные затраты по двум путям сравниваются примерно на 19 месяце. Ключевые переменные — объём обращений и доля тем, ответ на которые есть в базе знаний. При объёме менее тысячи обращений в месяц окупаемость обычно не достигается вовсе, и правильное решение — отложить проект, а не искать более дешёвого подрядчика.

Можно ли использовать зарубежные модели по 152-ФЗ?

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

Что делать, если база знаний в компании в хаосе?

Начать с неё, а не с ассистента. Соберите документы в одно место, оставьте по одной актуальной версии каждого, удалите противоречия, разделите внутренние и клиентские материалы, назначьте владельца каждому разделу. Это две-четыре недели работы, и она полезна сама по себе: сотрудники начинают находить ответы быстрее ещё до всякого ИИ. Запуск ассистента на хаотичной базе даёт уверенные неверные ответы от имени компании, что хуже, чем отсутствие ассистента вообще.

Нужна помощь с этой задачей?

Мы делаем это на практике, а не только пишем об этом. Опишите задачу — разберём и пришлём смету по этапам.

Услуги по теме

Читать дальше