Коротко

RAG снижает нагрузку на поддержку, когда оператор или клиент быстро получает ответ из утвержденных материалов: регламентов, FAQ, PDF, таблиц, базы знаний, инструкций, карточек услуг. Но RAG не лечит плохую базу знаний. Если документы старые, противоречивые и без владельца, агент будет быстрее доставать неправильные ответы.

В локальных компаниях знания часто разбросаны: что-то в Google Docs, что-то в 1C, что-то в Bitrix24, что-то в закрепе Telegram-чата, что-то в файле «финальная_версия_2.pdf». RAG полезен не как модное слово, а как способ привести этот хаос к рабочему поиску и ответам.

Как RAG помогает поддержке

Обычный оператор решает вопрос так: вспоминает правило, ищет документ, спрашивает коллегу, копирует шаблон, проверяет статус, отвечает клиенту. Если оператор новый, он чаще спрашивает старшего. Если старший занят, клиент ждет.

RAG меняет этот участок. Система получает вопрос, ищет подходящие источники и готовит ответ на их основе. Оператор видит не просто текст, а откуда он взялся. Это снижает повторы и ускоряет обучение новых людей.

Для клиента разницы почти нет: ему просто быстрее отвечают. Для компании разница большая: знания перестают жить только в головах опытных сотрудников.

Из чего состоит нормальный RAG для поддержки

Первый слой - источники. Это могут быть инструкции, регламенты, правила возвратов, прайсы, расписания, карточки услуг, ответы на частые вопросы, внутренние базы знаний. У каждого источника должен быть владелец. Иначе никто не знает, кто отвечает за актуальность.

Второй слой - индексация. Документы надо разбить так, чтобы система находила нужный кусок, а не весь PDF целиком. Нужны метаданные: тема, филиал, продукт, дата, версия, язык, доступ, тип аудитории.

Третий слой - поиск. Одних embedding’ов часто мало. Нужны фильтры, ключевые слова, reranking, иногда отдельные правила для артикулов, городов, дат, ошибок, номеров услуг.

Четвертый слой - ответ. Агент должен понимать, можно ли отвечать клиенту напрямую, лучше ли дать черновик оператору, надо ли спросить номер заказа или сразу передать человеку.

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

Почему просто «загрузить документы в чат» не хватает

Демо обычно выглядит красиво: загрузили PDF, спросили, получили ответ. В бою всё выглядит иначе. Клиент спрашивает коротко и криво. Документ называется странно. Правило зависит от города. В одном PDF старые условия, в другом новые. Часть информации только для сотрудников. Вопрос требует статуса из CRM или 1C, а в базе знаний его нет.

Поэтому хороший RAG - это не только векторный поиск. Это контроль источников, версии, права доступа, тесты и понятные границы ответа.

В кейсе Olzhas - база знаний Magnum логика была именно такой: сотрудник задает вопрос обычным языком, система ищет по внутренним материалам, отвечает с опорой на источник, а команда может обновлять материалы через админку. Для поддержки клиентов принцип тот же, только рисков больше: внешний человек видит ответ, и ошибка бьет по сервису.

Где RAG снижает нагрузку сильнее всего

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

График, документы, правила участия, условия возврата, подготовка к услуге, сроки, адреса, статусы. Если вопрос повторяется десятки раз, RAG быстро окупается.

Поддержка новичков

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

Длинные внутренние инструкции

В компаниях любят PDF на 40 страниц. Оператору нужно не всё, а один пункт. RAG находит кусок и объясняет его нормальным языком.

Мультиязычные вопросы

В Казахстане клиент может написать на русском, казахском, смешанно, с транслитом и опечатками. Поиск должен понимать смысл, но ответ брать из утвержденного источника.

Что измерять

Не надо мерить только количество автоматических ответов. Лучше смотреть:

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

Для этого нужны evals на реальных вопросах. В тестовый набор надо добавить злых клиентов, короткие сообщения, смешанный язык, старые правила, конфликтующие документы и вопросы, на которые агент обязан сказать: «не могу ответить, передаю оператору».

Какие риски надо закрыть

Первый риск - устаревшие документы. Решение: владелец источника, дата, версия, архивирование.

Второй риск - неправильный доступ. Внутренние инструкции не всегда можно показывать клиенту. Права должны проверяться при поиске, а не только в интерфейсе.

Третий риск - уверенный ответ без основания. Если источник слабый или не найден, агент должен отказаться от ответа или передать человеку.

Четвертый риск - отсутствие данных из систем. Например, вопрос зависит от статуса заказа в 1C или CRM. Тогда RAG по документам не хватит. Нужен AI-агент, который умеет безопасно читать нужную систему.

Как запускать

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

Сначала соберите топ-50 вопросов поддержки и реальные диалоги. Затем подготовьте источники: удалите старое, назначьте владельцев, добавьте метаданные. После этого проверьте поиск на исторических вопросах.

Первый боевой режим - черновики для операторов. Агент предлагает ответ и источник, оператор отправляет или правит. Через пару недель будет видно, какие темы можно автоматизировать напрямую, а какие лучше оставить человеку.

Для публичных каналов вроде WhatsApp и Instagram не торопитесь. Сначала пусть агент помогает оператору. Прямой ответ клиенту включайте только там, где правила стабильные и проверенные.

FAQ

RAG полностью убирает ошибки модели?

Нет. Он снижает риск, потому что ответ опирается на документы. Но если поиск принес не тот источник, модель всё равно может ошибиться.

Можно ли использовать старые тикеты как базу знаний?

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

Что делать, если документов много, но они плохие?

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

Нужны ли ссылки на источник в ответе клиенту?

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

RAG снижает нагрузку не потому, что «ИИ умный». Он снижает нагрузку, когда компания наконец приводит знания в вид, пригодный для ежедневной работы.