Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Закрытые обращения научились искать по текущему этапу расследования, а не только по сходству всего текста. RAFT от команды Microsoft обошёл обычный RAG и два графовых подхода на всех стадиях проверки, хотя препринт не рецензирован и все числа получили сами авторы. Практический вывод: прежде чем усложнять базу графом сущностей, стоит изменить единицу индексации с обращения или фрагмента на осмысленный шаг расследования.
Почему сходство целых обращений теряет полезные случаи
Обычная генерация с дополненным поиском (RAG) воспринимает закрытое обращение как документ. Система режет его на фрагменты или строит одно представление для всего текста, а затем ищет материалы, похожие на текущий запрос.
Для диагностики этого мало. В начале инженер знает симптом и код ошибки, затем проверяет гипотезы, изучает журналы и только потом устанавливает причину. Два обращения могут начинаться по-разному, но сходиться на промежуточном состоянии или требовать одинакового исправления.
Исходная переписка также смешивает технические сведения с уточнениями, повторами и административными сообщениями. Отдельный фрагмент может совпасть с запросом, но не показать, что происходило до него и чем закончился случай. Возвращать обращение целиком тоже дорого: длинная история занимает контекст и сокращает число примеров, которые сможет изучить агент.
Граф сущностей решает другую задачу. Он связывает продукты, ошибки и компоненты, но не обязательно сохраняет последовательность расследования. RAFT вместо отношений между отдельными сущностями делает основной структурой путь от симптома через гипотезы к причине и исправлению.
Как RAFT индексирует состояние расследования
При подготовке базы RAFT превращает каждое закрытое обращение в компактную временную шкалу. Отдельная запись появляется, когда заметно меняется понимание проблемы: возникла гипотеза, проверка её опровергла, нашлась причина или инженер подтвердил исправление. Подтверждения и сообщения без новых технических сведений остаются внутри текущего этапа.
Длинную историю модель обрабатывает частями и переносит накопленное состояние в следующий проход. После этого отдельная модель проверяет результат, исправляет пропуски и формирует структурированное описание: этапы расследования, причину, действия по устранению, значимые сущности и оценку практической пользы случая.
Такой промежуточный слой позволяет до индексации убрать персональные сведения и исключить обращения, которые закрыли без диагностики. Метаданные можно сохранить как фильтры по продукту, версии, категории, времени или исходу.
Для каждой записи временной шкалы строится числовой вектор для смыслового поиска. При запросе RAFT сочетает смысловую близость с совпадением характерных слов по алгоритму BM25, ранжирует отдельные этапы и поднимает лучшие совпадения до родительских обращений.
Агент получает не случайный фрагмент, а структурированную траекторию обращения вместе с отметкой, какой этап совпал с текущей ситуацией. Ранний запрос поэтому приводит к начальному симптому прошлого случая, а более подробный — к соответствующей промежуточной проверке. Контекст сохраняет и ближайший следующий шаг, и путь до окончательного решения.
Граф в RAFT остаётся необязательным дополнением. Он связывает обращения по сходству причин и исправлений, а затем расширяет первоначальную выдачу соседними случаями. Это помогает найти одинаковую причину за разными симптомами, но не заменяет поиск по этапам.
Когда подход меняет архитектуру агента
Методику проверяли отдельно от полного диагностического агента. Основной тест построили на 826 синтетических обращениях по материалам Microsoft Learn о Windows Server. Все методы использовали одинаковые модели, а выдачу ограничивали бюджетом в 6000 токенов, чтобы сравнение зависело прежде всего от способа индексировать и искать случаи.
Главная метрика — попадание по кейсу: среди найденных материалов должен быть случай с той же причиной и способом устранения. Когда запрос содержал только начальный симптом, RAFT достиг 84,2% против 67,3% у обычного RAG. Преимущество сохранялось по мере развития расследования и было статистически значимым на каждом проверенном этапе; HippoRAG2 и Fast-GraphRAG также уступили RAFT.
Перенос на реальные истории проверили на 30 вручную просмотренных группах дубликатов из Apache Jira. RAFT снова чаще находил связанное обращение на каждой стадии, но этот тест даёт только направление: основное доказательство получено на синтетическом наборе умеренного масштаба.
Работа оценивает поиск, а не итоговый диагноз, долю решённых обращений или время инженера. Поэтому она не подтверждает экономический эффект всей системы. Она показывает более узкий результат: структурированная история повышает шанс передать агенту релевантный прошлый случай.
Для команды с многоэтапными обращениями это повод изменить план эксперимента. Вместо раннего внедрения сложного GraphRAG можно сначала выделить переходы состояния, индексировать их отдельно и возвращать вместе с полной траекторией случая. Такая перестройка затрагивает подготовку данных и поиск, но не требует менять основную LLM агента.
Проверять подход стоит на собственных группах дубликатов или обращениях с общей причиной, а затем измерять итог диагностики в рабочем процессе. Для базы из статических инструкций и одношаговых вопросов работа не даёт оснований заменять обычный RAG: её результат относится именно к историям, где полезный сигнал меняется по ходу расследования.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
