ИИ в поддержке: ответы по базе знаний в 2026

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

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

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

Что именно автоматизирует ИИ в поддержке

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

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

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

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

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

Как связать ответ с базой знаний

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

Начинать я советую с аудита документов. Для каждой статьи фиксируются дата обновления, ответственная команда и область применения. Инструкция от 12 марта 2026 года должна иметь более высокий приоритет, чем копия от 18 ноября 2025 года, если обе описывают один процесс. Срок действия тарифа, лимит возврата или список документов нельзя оставлять без даты и владельца.

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

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

Модельный кейс: в базе есть 240 статей, но после удаления дублей остаётся 180 действующих документов. Для вопроса о возврате поиск находит 5 фрагментов, из которых 2 относятся к отмене заказа, 1 описывает банковскую задержку, а 2 относятся к другой услуге. В ответ можно включать только первые 3, если их даты и область применения совпадают.

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

Где проходит граница между автоответом и оператором

Границу я задаю двумя условиями: уровень уверенности должен быть не ниже 0,85, а в найденном фрагменте обязаны совпадать услуга и действующее правило. При нарушении хотя бы одного условия обращение передаётся человеку без готового обещания клиенту.

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

Я разделяю обращения на четыре уровня. Первый уровень, точная справка по действующей статье, подходит для автоматического черновика. Второй, вопрос с одной недостающей деталью, требует уточнения. Третий, конфликтующие документы или нестандартная ситуация, передаётся оператору. Четвёртый, юридически или финансово значимое обращение, не должно закрываться без проверки сотрудником.

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

Как проверить качество до запуска

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

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

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

Полезная форма результата выглядит так:

Эти ориентиры не стоит выдавать за отраслевой стандарт. Их задача, создать измеримую точку отсчёта. Если точность равна 92%, но 3 из 20 финансовых вопросов получили неверное решение, пилот нельзя считать готовым. Отдельный отчёт по критичным категориям важнее среднего процента.

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

Что получает оператор в ежедневной работе

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

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

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

Длинный ответ не всегда полезнее короткого. Для справочного вопроса достаточно 3–5 предложений, а для спорной ситуации лучше передать контекст и не маскировать отсутствие данных вежливой формулировкой. Обучение сотрудников работе с такими черновиками можно связать с подходом из материала о нейросетях в образовании и саморазвитии: модель помогает разбирать варианты, но решение проверяет человек.

Какие ошибки ломают автоматизацию

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

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

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

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

Четвёртая ошибка, измерять только скорость. Черновик за 4 секунды, который оператор исправляет в 40% случаев, не даёт устойчивого выигрыша. Поэтому скорость нужно смотреть рядом с точностью, корректностью источника и долей эскалаций.

Как провести пилот за 10 рабочих дней

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

В дни 1–2 команда собирает 200 обезличенных вопросов и отмечает 20–30 типичных намерений. В дни 3–4 очищаются документы, удаляются дубли и добавляются даты редакции. К концу четвёртого дня у каждого ответа из тестовой выборки должен быть эталонный источник.

В дни 5–6 настраивается шаблон ответа. В нём фиксируются длина до 5 предложений для простой справки, обязательная ссылка на документ и условие передачи оператору. В дни 7–8 проводится слепая проверка: сотрудник оценивает ответ, не видя, какая версия модели его подготовила.

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

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

Как принять решение о запуске

Я запускаю автоматические черновики, когда на 200 тестовых вопросах точность простых справок достигает 90%, все критичные случаи уходят оператору, а числа подтверждаются документами. Если хотя бы один из этих критериев провален, нейросеть оставляю в режиме поиска и подсказок.

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

Если бы я запускал этот процесс сегодня, начал бы с 20–30 повторяющихся намерений, 200 обезличенных вопросов и одной версии базы с датами. Через 10 рабочих дней у команды появились бы измеримые ошибки, а не общее впечатление от нескольких удачных диалогов. Именно по этим ошибкам решается, что исправлять дальше: поиск, документы, шаблон или границу участия оператора.