RAG в техподдержке: проблемы и пути улучшения

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

1. Ограничения поиска по документации

Согласно приблизительным оценкам, векторный поиск корректно находит нужный кусок документации лишь в 30% случаев (эта цифра не подтверждена отдельными исследованиями, отражает субъективное восприятие автора). Остальные 70% запросов возвращают нерелевантные или неточные результаты. Основные причины следующие:

• Большая база знаний
  При обширном объёме документации некоторые эмбеддинги могут пересекаться. Это затрудняет выбор действительно оптимального совпадения.

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

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

2. Влияние на AHT и важность правильных ответов

Что такое AHT?

AHT (Average Handling Time) — это среднее время обработки запроса. Для техподдержки это одна из ключевых метрик: чем быстрее оператор находит корректное решение, тем лучше для клиента и компании.

Проблема с неправильными ответами

Когда система RAG возвращает нерелевантный или неправильный ответ, это напрямую влияет на AHT:

• Потеря времени оператора

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

Также если оператор недостаточно опытен, он может быть излишне лоялен к системе и передать клиенту ложные сведения (но это не является сегодняшней темой).

Отсюда следует чёткий вывод: если мы хотим уменьшить AHT, нужно давать правильные ответы.

3. Можно ли автоматически проверять корректность ответа?

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

• Если бы у нас уже был эталонный ответ для любого запроса со 100%-й точностью, то мы бы сразу выдавали этот эталон и не нуждались бы в RAG.

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

В итоге полностью исключить риск некорректных ответов с помощью автоматической проверки пока невозможно.

4. Нужно ли улучшать поиск?

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

• Re-rank: дополнительный слой переупорядочивания результатов, который повышает приоритет более релевантных фрагментов.

• Гибридный поиск: совмещение векторного и классического (символьного) подхода.

Предположим, мы разработали эффективный RAG, который достигает 50% точности в нахождении правильных фрагментов. Для оптимизации важно не только обеспечивать ответы быстрее средней скорости оператора, но и компенсировать дополнительные издержки — время, которое операторы тратят на чтение неправильных ответов.

5. Что можно еще сделать для повышения эффективности RAG?

• Альтернативный подход:
  

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

  • Качественная категоризация запросов
    Встроить в первое звено обработки «оркестрацию», которая определяет тему/категорию запроса.

  • Fallback-стратегия
    Если вопрос попал в категорию, по которой система даёт плохие ответы, вернуть оператору сообщение: «Я пока не умею помогать с категорией xxx».

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

Заключение

Технология RAG способна ускорить работу службы техподдержки лишь при условии выдачи правильных ответов. Однако система далеко не всегда найдёт нужный фрагмент документации из-за особенностей векторного поиска и «шума» в базе знаний.

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