Фреймворк RAFT: как работает RAG на максималках от Microsoft

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

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

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

В этой статье разберемся, как устроен RAFT, кому он нужен и чем он отличается от обычного RAG. Заодно посмотрим, что показали тесты Microsoft.

Для чего нужен RAFT

RAFT (Retrieval-Augmented Framework for Troubleshooting Agents) — система, которая помогает ИИ-агентам искать подсказки в старых обращениях в техподдержку. Идея в том, чтобы предлагать агенту следующие шаги на основе предыдущего опыта. RAFT находит похожий этап диагностики и показывает, как в прошлый раз нашли нужное решение.

Представьте ситуацию: сотрудник компании N обращается в техподдержку с проблемой — он не может авторизоваться во внутреннем сервисе.

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

Инженер зовет на помощь коллег из смежного отдела. И тут выясняется: сертификат подписи SSO недавно обновили. Без этого сертификата система просто не пустит пользователя внутрь. А сервис-то у нас использует еще старый сертификат — все сходится. Инженер обновляет настройки... Бинго! Вход по SSO снова работает. 

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

Чтобы упростить работу, некоторые команды техподдержки используют RAG. Такие системы ищут в архиве предыдущих обращений похожие сообщения или целые тикеты. Проблема в том, что данные в них обычно сырые и неструктурированные. Чтобы продраться сквозь этот шум и восстановить контекст, инженеру нужно потратить много времени, а ИИ-агенту — токенов. 

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

Как работает RAFT

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

Условно для RAFT старый тикет может состоять из цепочки этапов:

• симптом;

• первая гипотеза;

• проверка;

• новый факт;

• другая гипотеза;

• причина;

• результат;

С виду кажется: ну окей, обычная разбивка тикета по этапам. Что нового? Соль в том, что новый этап появляется только в том случае, если в расследовании реально что-то изменилось. Например, пользователь сообщил новый факт, инженер выдвинул гипотезу или предложил конкретное решение. Такие «контрольные точки» называются записями хронологии (timeline entries). 

За подготовку тикета отвечает два агента: worker и reviewer. Worker собирает историю расследования и делит ее на этапы. Reviewer смотрит, не потерялись ли важные данные, и отсеивает неподходящие тикеты — например, такие, где пользователь перестал отвечать, или проблема не была решена.

Каждая запись хранится отдельно. Благодаря этому RAFT может искать кейсы не только по похожим симптомам, но и по тому, что стало известно в ходе расследования. Скажем, инженер выяснил, что обычный вход работает, а через SSO — нет. Теперь система ищет обращения с учетом новой информации.

Как RAFT ищет похожие тикеты

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

1. Пользователь заводит тикет: «не получается войти в корпоративный мессенджер»

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

3. Инженер просит ИИ-помощника найти похожий случай. ИИ собирает запрос и отправляет его в RAFT.

4. RAFT находит подходящий кейс и показывает его инженеру. Заодно отмечает похожие моменты.

5. В истории видно, что инженер проверил замену сертификата подписи SSO — и это стало ключом к решению проблемы.

6. Инженер смотрит настройки текущего сервиса, находит старый сертификат, обновляет его — и вход через SSO снова работает.

Если в ходе диагностики открываются новые факты, инженер уточняет запрос и запускает поиск заново.

Какие методы поиска использует RAFT

RAFT ищет похожие тикеты двумя способами.

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

Поиск по словам и терминам — BM25. Нужен для поиска точных совпадений: код ошибки, название сервиса, версия программы или параметр конфигурации.

Дальше результаты двух поисков нужно как-то свести вместе. Для этого в RAFT используют Reciprocal Rank Fusion. Если тикет оказался высоко в обеих выдачах, он поднимается и в общем списке.

Зачем это нужно? Семантический поиск может найти похожий кейс, даже если в нем использованы другие формулировки. BM25, в свою очередь, не даст потерять важную техническую деталь — например, конкретный код ошибки. Так меньше шансов пропустить нужный тикет из-за слишком разных, наоборот, похожих формулировок.

Результаты бенчмарков

Ребята из Microsoft протестили свое детище на двух наборах данных. 

Сначала RAFT протестировали на синтетическом наборе из 826 обращений. Их создали на базе документации Microsoft Learn по устранению неполадок в Windows Server. Для одной и той же проблемы создали несколько разных историй: в каждой инженеры проверяли несколько версий, прежде чем найти проблему.

Для каждого тикета система получала только часть переписки:

• Только исходный симптом;

• 30% переписки;

• 60% переписки. 

За основу взяли метрику Case Hit или точность работы алгоритмов. Она показывает, удалось ли системе найти хотя бы один архивный кейс с той же причиной проблемы и тем же способом ее устранения.

Вот, что показало тестирование:

На старте разница составила 16,9%. Когда системе открыли 30% переписки, она сократилась до 15,2%, а после 60% — до 11,9%.

Авторы также проверили, где именно в старых тикетах находились совпадения. Когда системе был известен только исходный симптом, нужный этап в среднем находился на глубине 9,1% истории. При доступе к 30% переписки совпадение находилось на глубине 20%, а при доступе к 60% — на глубине 54%.

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

Затем RAFT проверили уже на реальных обращениях в Spark, Cassandra, HBase и Hadoop. Задача была аналогичной: отыскать нужный кейс среди сотни архивных обращений. Цифры получились такие:

Видим, что результаты теста на синтетических и реальных данных практически совпадают.

Чего RAFT не умеет

RAFT — это лишь инструмент поиска по предыдущим обращениям. Сам по себе он не умеет ставить правильные диагнозы и не гарантирует, что найденные кейсы помогут решить проблему.

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

Плюс ко всему, работа RAFT сильно зависит от того, какие данные ему «скормили». Если в датасете мало примеров, где проблему действительно удалось решить, дельных советов от него ждать не стоит. Как и любому ИИ-инструменту, ему нужны хорошие исходные данные.

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