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

Разберём ключевые проблемы подробнее.

Знания разбросаны по десяткам мест

Ответы на вопросы клиентов хранятся везде и нигде одновременно: в тикет-системе, в переписке менеджеров, в чатах команды, в Google Docs, в голове у «того парня, который работает здесь с 2019 года». Когда поступает обращение, агент должен проверить 5-7 источников, прежде чем сформулировать ответ. Если проблема нетривиальная - он эскалирует на старшего специалиста, который занят своими задачами.

Одни и те же вопросы решаются снова и снова

В средней SaaS-компании 60-70% обращений - это повторяющиеся вопросы. «Как настроить интеграцию с amoCRM?», «Не работает отчёт по конверсиям», «Как добавить нового пользователя?». Эти проблемы решались десятки раз, но каждый раз агент тратит 10-20 минут на то, чтобы заново найти решение и сформулировать ответ.

Новые сотрудники адаптируются месяцами

Онбординг агента поддержки в компании со сложным продуктом занимает от 2 до 6 месяцев. Всё это время новичок работает медленнее, чаще ошибается и нагружает опытных коллег вопросами. Средняя текучка в отделах поддержки - 30-40% в год. Получается замкнутый круг: компания постоянно тратит ресурсы на обучение людей, которые через год уйдут.

Качество ответов нестабильно

Один и тот же вопрос, заданный двум разным агентам, может получить два разных ответа. Опытный агент даст точный, развёрнутый ответ за 2 минуты. Новичок потратит 15 минут и может допустить ошибку. Клиент не должен зависеть от того, кто именно ему ответил.

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

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

Разберём весь процесс по шагам - от сырых тикетов до готовой системы.

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

Шаг 1. Выгрузка тикетов из helpdesk-системы

Первый этап - получение данных из тикет-системы через API. Мы работаем с большинством популярных платформ: Zendesk, Freshdesk, HelpDeskEddy, Usedesk, а также с кастомными решениями на базе Bitrix24 и amoCRM. Выгружаются не только текст обращений и ответы, но и метаданные: категория, продукт, приоритет, теги, статус, время решения, оценка клиента.

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

Шаг 2. Очистка и нормализация

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

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

Шаг 3. Реструктуризация с помощью LLM

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

Мы используем LLM для реструктуризации: модель получает полный диалог и генерирует структурированную карточку с полями «Проблема», «Контекст», «Решение», «Шаги воспроизведения», «Дополнительные рекомендации». Из путаного диалога на 15 сообщений получается чёткий, информативный документ на 3-5 абзацев.

Важно: стоимость обработки. При тысячах тикетов стоимость реструктуризации через стандартный API может быть существенной. Мы используем Batch API для пакетной обработки: отправляем все тикеты одним пакетом и получаем результат через несколько часов, но со скидкой 50% от стоимости обычных запросов. Для проекта с 10 000 тикетов это экономит сотни долларов.

Шаг 4. Генерация эмбеддингов

Реструктурированные документы преобразуются в числовые векторы - эмбеддинги. Мы используем Voyage AI (модель voyage-4-large, 2048 измерений) для генерации эмбеддингов, которые точно передают семантику технических текстов и описаний проблем.

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

Шаг 5. Сохранение в векторное хранилище

Эмбеддинги вместе с метаданными загружаются в векторную базу данных. Мы используем Turbopuffer для проектов с высокой нагрузкой и большим объёмом данных, pgvector - для проектов, где уже есть PostgreSQL-инфраструктура. Метаданные (категория, продукт, дата, теги) индексируются отдельно для возможности фильтрации.

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

Чисто семантический поиск работает отлично для вопросов, сформулированных на естественном языке. Но в поддержке часто встречаются ситуации, где нужно точное совпадение: коды ошибок («Error 502»), номера тикетов («#12345»), артикулы продуктов, названия API-методов, версии ПО.

Для таких случаев мы реализуем гибридный поиск, который комбинирует два подхода:

• Семантический поиск (по смыслу) - находит документы, описывающие похожую проблему, даже если использованы другие слова. Запрос «страница не грузится после обновления» найдёт тикет с описанием «белый экран при переходе на новую версию»
• Полнотекстовый поиск (BM25) - находит документы с точным совпадением терминов. Запрос «ошибка CORS при вызове API v3.2» найдёт тикет, содержащий именно «CORS» и «API v3.2»

Результаты обоих поисков объединяются и перевзвешиваются: если документ найден обоими методами - он получает максимальный ранг. Такой подход даёт точность на 15-25% выше, чем каждый метод по отдельности.

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

• Фильтр по продукту. Если клиент пишет о проблеме с модулем аналитики, система ищет только среди тикетов по аналитике, игнорируя обращения по другим модулям
• Фильтр по категории. «Технические проблемы», «Вопросы по оплате», «Настройка интеграций» - каждая категория имеет свой корпус решений. Фильтрация исключает нерелевантные результаты
• Фильтр по дате. Для продуктов с частыми обновлениями важна актуальность: решение трёхлетней давности может быть неприменимо к текущей версии. Фильтр по дате приоритизирует свежие тикеты
• Фильтр по тегам. Пользовательские теги (ОС, браузер, тип интеграции) позволяют ещё точнее подбирать релевантные решения
• Фильтр по оценке. Тикеты с высокой оценкой от клиента получают приоритет - это подтверждённо качественные ответы

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

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

Мы настраиваем автоматический пайплайн обновления:

• Вебхук из тикет-системы - при закрытии тикета с положительной оценкой срабатывает вебхук
• Автоматическая обработка - тикет проходит очистку, реструктуризацию через LLM, генерацию эмбеддинга
• Добавление в базу - новый документ с метаданными появляется в векторном хранилище
• Немедленная доступность - следующий запрос к системе уже может использовать новый тикет

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

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

RAG-база для поддержки может использоваться в двух режимах, и часто они работают одновременно.

Режим 1. Подсказки для агентов (Agent Assist)

Когда агент открывает новый тикет, система автоматически ищет похожие обращения и показывает предложенные ответы в боковой панели. Агент видит: «Найдено 3 похожих обращения. Тикет #8742 (95% совпадение): Проблема решена переустановкой модуля интеграции. Тикет #9103 (87% совпадение): Требовалось обновление API-ключа».

Агент не обязан копировать ответ дословно - он берёт решение как основу и адаптирует под конкретную ситуацию. Но вместо 15 минут на исследование проблемы он тратит 2 минуты на адаптацию готового решения.

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

Режим 2. Автоматические ответы (Self-Service)

Для типовых вопросов система может отвечать клиенту напрямую, без участия агента. Клиент пишет вопрос в чат или отправляет тикет. Система находит релевантные решения, генерирует ответ с помощью LLM и отправляет клиенту. Если клиент подтверждает, что проблема решена - тикет закрывается автоматически. Если нет - передаётся агенту с полным контекстом.

Этот режим не подходит для всех обращений - сложные технические проблемы, вопросы по оплате, жалобы должны обрабатываться людьми. Но для простых вопросов («Как сбросить пароль?», «Где найти отчёт по конверсиям?», «Какие форматы файлов поддерживаются?») автоматический ответ работает не хуже живого агента.

Один из наших проектов - построение RAG-системы для службы поддержки SaaS-компании, работающей на российском рынке. Разберём его подробно.

Исходная ситуация

Компания - разработчик бизнес-софта с 2000+ клиентов. Отдел поддержки из 8 человек обрабатывал 300-400 тикетов в неделю. Среднее время ответа - 4 часа в рабочее время, до 24 часов в выходные. Новый сотрудник выходил на полную производительность через 4 месяца. Текучка - 35% в год.

За 4 года работы в тикет-системе накопилось более 15 000 закрытых обращений - колоссальный массив знаний, который никак не использовался системно.

Что мы сделали

Выгрузка и очистка. Выгрузили 15 000 тикетов через API тикет-системы. Отфильтровали: оставили 11 000 с положительной или нейтральной оценкой. Провели автоматическую очистку от шаблонов, подписей и персональных данных.

Реструктуризация. 11 000 тикетов обработали через LLM с использованием Batch API. Пакетная обработка заняла 6 часов, стоимость составила менее 200 долларов. Каждый тикет преобразован в структурированный документ: проблема, контекст, решение, предупреждения.

Параллельная обработка. Для ускорения мы использовали пакеты по 100 тикетов, которые обрабатывались параллельно. Общее время конвейера (от сырых данных до готовой базы знаний) - 8 часов, из которых 6 часов - ожидание результатов Batch API.

Векторизация и индексация. Реструктурированные документы прошли через модель эмбеддингов Voyage AI. Полученные векторы загружены в Turbopuffer вместе с метаданными (категория, продукт, версия, теги, дата). Настроен гибридный поиск - семантический + полнотекстовый.

Интеграция. Подключили Agent Assist в тикет-системе: при открытии нового обращения агент видит 3-5 релевантных прошлых решений. Параллельно настроили автоматические ответы для категорий «Часто задаваемые вопросы» и «Инструкции».

Результаты через 3 месяца

• Среднее время ответа: снизилось с 4 часов до 45 минут (-81%)
• Автоматически закрытые тикеты: 32% обращений решаются без участия агента
• Время адаптации новых сотрудников: сократилось с 4 месяцев до 3 недель
• FCR (First Contact Resolution): вырос с 45% до 72%
• Удовлетворённость клиентов (CSAT): выросла с 3.6 до 4.3 из 5
• Нагрузка на агентов: снизилась на 40%, что позволило не нанимать 2 дополнительных сотрудника при росте клиентской базы на 25%

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

Операционные метрики

• Среднее время первого ответа (FRT) - время от создания тикета до первого ответа агента. RAG снижает этот показатель за счёт мгновенных подсказок
• Среднее время решения (TTR) - время от создания до закрытия тикета. RAG сокращает его за счёт быстрого доступа к проверенным решениям
• Процент автоматических решений - доля тикетов, закрытых без участия агента. Целевой показатель - 25-40% для зрелой системы
• FCR (First Contact Resolution) - процент обращений, решённых с первого ответа. Главный показатель качества поддержки

Бизнес-метрики

• Стоимость одного тикета - общие затраты на поддержку, делённые на количество обращений. RAG снижает этот показатель на 30-50%
• Время адаптации новых сотрудников - сколько времени нужно, чтобы новичок вышел на уровень 80% от опытного агента
• CSAT (Customer Satisfaction Score) - оценка клиентом качества обслуживания. Быстрые точные ответы напрямую влияют на этот показатель
• Отток клиентов из-за качества поддержки - процент клиентов, ушедших после негативного опыта с поддержкой. Сложно измерить напрямую, но коррелирует с CSAT

Технические метрики RAG

• Точность поиска (Precision@K) - какой процент из топ-K результатов действительно релевантен запросу. Целевой показатель - 80%+ для топ-5
• Полнота поиска (Recall) - какой процент релевантных документов находит система. Важно для гарантии, что нужное решение не будет пропущено
• Процент принятия подсказок - как часто агенты используют предложенные ответы. Если меньше 30% - система требует доработки
• Латентность поиска - время от запроса до получения результатов. Должно быть менее 500 мс для комфортного использования

За время работы с проектами мы выявили ряд ошибок, которые допускают команды при построении RAG-систем для службы поддержки.

• Загрузка всех тикетов подряд. Нерешённые обращения, тикеты с негативной оценкой, спам - всё это загрязняет базу знаний. Нужна строгая фильтрация: только закрытые тикеты с подтверждённым решением
• Пропуск этапа реструктуризации. Сырые диалоги содержат шум, повторы и отступления. Без реструктуризации качество поиска падает на 30-40%. LLM-обработка - не опциональный этап, а обязательный
• Игнорирование метаданных. Без фильтрации по продукту, версии и категории система может предлагать решения для другого продукта. Метаданные - это не «бонус», а критический компонент
• Отсутствие обратной связи. Без механизма «это помогло / не помогло» невозможно улучшать систему. Обратная связь от агентов должна быть встроена в интерфейс с первого дня
• Запуск сразу в автоматическом режиме. Начинать нужно с Agent Assist (подсказки для агентов), а не с автоматических ответов. Это позволяет собрать статистику, выявить слабые места и повысить качество перед тем, как доверять системе самостоятельно отвечать клиентам
• Забыть про актуализацию. База знаний устаревает - продукт обновляется, процессы меняются. Автоматический пайплайн добавления новых тикетов и архивирования устаревших решений необходим с момента запуска

Для построения RAG-системы для поддержки мы используем проверенный набор технологий.

• Пакетная обработка: Batch API для реструктуризации тикетов - 50% экономия по сравнению с обычным API, при обработке 100+ документов параллельно
• Эмбеддинги: Voyage AI (voyage-4-large, 2048 измерений) - одна из лучших моделей для технических текстов и мультиязычного контента
• Векторное хранилище: Turbopuffer для высоконагруженных проектов (миллисекундный поиск по миллионам документов), pgvector для компактных установок
• Генерация ответов: YandexGPT для русскоязычных проектов с требованиями по локализации, DeepSeek для задач с приоритетом экономии, Llama или Mistral для on-premise развертывания
• Оркестрация: Серверные функции для вебхуков, очередь задач для пакетной обработки, планировщик для регулярной актуализации

Мы строим RAG-системы для поддержки по отработанной методологии, которая минимизирует риски и даёт измеримый результат на каждом этапе.

• Этап 1. Аудит (1 неделя). Оцениваем объём и качество тикетов, определяем категории, которые дадут максимальный эффект, формируем метрики успеха
• Этап 2. Пилот (2-3 недели). Обрабатываем 500-1000 лучших тикетов, запускаем Agent Assist для 2-3 агентов. Собираем обратную связь и корректируем систему
• Этап 3. Масштабирование (2-4 недели). Обрабатываем полный архив, подключаем всех агентов, настраиваем автоматический пайплайн обновления. Запускаем автоматические ответы для типовых категорий
• Этап 4. Оптимизация (постоянно). Мониторинг метрик, расширение автоматических ответов, обработка edge-кейсов, интеграция с дополнительными источниками данных

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

Свяжитесь с нами для бесплатной оценки вашей тикет-базы - мы проанализируем объём, качество данных и подготовим конкретное предложение по срокам и стоимости.