RAG простыми словами: почему ассистент не выдумывает

На созвоне кто-то говорит: «Давайте подключим ИИ, он будет знать наш продукт и отвечать клиентам». Звучит удобно, но в этой фразе прячется главная ошибка.

Ассистент не знает ваш продукт так, как его знает опытный сотрудник. Он не помнит, что вы поменяли условия возврата в понедельник, что для старого тарифа есть исключение, а в инструкции для партнёров осталась старая формулировка.

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

Модель хорошо пишет, но это не то же самое, что знать правило

Языковая модель умеет собирать связный текст. Она может написать спокойно, вежливо и уверенно. Поэтому её ответ легко принять за знание.

Клиент спрашивает: «Можно ли вернуть деньги за годовой тариф, если мы пользовались сервисом два дня?» Модель без ваших материалов может дать правдоподобный ответ: «Возврат возможен в течение 14 дней», «Возврат зависит от условий договора», «Напишите в поддержку, мы всё проверим».

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

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

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

RAG добавляет перед ответом поиск по вашим материалам

RAG расшифровывается как Retrieval-Augmented Generation: генерация с поиском. Название можно забыть. Важно другое: ассистент сначала ищет факты, а потом пишет ответ.

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

Дальше модель получает вопрос клиента и найденные фрагменты. Её задача — не придумать правило с нуля, а сформулировать ответ на основе того, что нашлось. Если в статье написано, что возврат считается только за неиспользованные месяцы, ответ должен опираться именно на это.

Это похоже не на сотрудника, который всё помнит, а на сотрудника, который перед ответом быстро открывает нужные статьи. Разница принципиальная. Если статья есть, она актуальна и написана однозначно, у ассистента появляется опора. Если статьи нет, опоры нет.

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

Но из этого же растут пределы. RAG не исправит плохую базу знаний. Если в одной статье написано «возврат в течение 14 дней», а в другой «возврат невозможен после оплаты», ассистент может выбрать не тот фрагмент или смешать правила. Если важное исключение живёт только в голове старшего оператора, модель его не найдёт.

Источники важнее красивой формулировки

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

Допустим, ассистент отвечает клиенту: «Закрывающие документы появляются в личном кабинете после оплаты». Если рядом видно, что ответ построен по статье «Оплата и документы», оператору проще проверить логику. Если источник странный — например, статья про смену тарифа, — это сигнал не доверять ответу сразу.

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

Есть и обратная ситуация. Клиенты часто спрашивают одно и то же, но ассистент не находит подходящий материал. Значит, в базе знаний есть пробел. Не в модели, не в «магии ИИ», а в документации: у команды нет текста, на который можно опереться.

Поэтому внедрение RAG почти всегда вытаскивает наружу старые долги поддержки. Где-то статья устарела. Где-то правило есть в регламенте для операторов, но не опубликовано в базе знаний. Где-то условия описаны юридическим языком, а клиент спрашивает проще: «Можно отменить оплату?»

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

Где RAG помогает, а где лучше звать человека

RAG особенно хорошо подходит для вопросов, где ответ уже описан в правилах. Как поменять пароль. Где скачать счёт. Какие способы оплаты доступны. Что делать, если письмо не пришло. Как работает возврат по стандартному сценарию.

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

Сложнее с ситуациями, где мало фактов или много ответственности. Клиент просит исключение. Спорит с условиями. Угрожает жалобой. Описывает проблему, которой нет в базе знаний. Пишет про деньги, договор, персональные данные или нестандартную интеграцию. Здесь одного поиска по статьям может быть недостаточно.

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

Важно заранее решить, какие темы можно отдавать ассистенту, а какие нет. Например, стандартные инструкции — можно. Индивидуальные скидки, юридические претензии и конфликтные возвраты — только оператору. Это скучное правило, но оно защищает и клиента, и команду.

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

База знаний становится частью поддержки, а не архивом

До ИИ база знаний часто жила как склад статей. Что-то написали при запуске, что-то добавили после частых вопросов, часть материалов устарела, но не мешала каждый день. Операторы всё равно знали, как правильно.

С RAG это перестаёт работать. База знаний становится рабочим инструментом, из которого ассистент берёт факты. Если там бардак, он выходит наружу в ответах клиентам.

Хорошая статья для RAG не обязательно длинная. Скорее наоборот: ей полезно быть ясной. Один вопрос — один ответ. Условия и исключения рядом с правилом. Даты, тарифы и ограничения написаны так, чтобы их не приходилось угадывать. Если есть разные сценарии, они разделены.

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

Лучше: «Для месячного тарифа возврат можно запросить в течение 7 дней после оплаты, если услугой не пользовались. Для годового тарифа возврат считается за полные неиспользованные месяцы. Тарифы со скидкой по индивидуальному договору рассматривает менеджер». Даже если это пример, видно, почему такая статья полезнее: в ней есть условия, границы и момент передачи человеку.

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

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

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