RAFT는 트러블슈팅 이력을 단계별로 검색하는 상태 기반 RAG다.

무엇인가

이 논문은 기업 고객지원에서 트러블슈팅 에이전트가 과거의 닫힌 사례에서 실행 가능한 지침을 검색하는 문제를 다룬다. 저자들은 해결이 한 번에 끝나지 않고 초기 증상 보고, 가설 형성, 로그와 진단 도구를 통한 반복적 정보 수집, 근본 원인 확인, 조치 제안과 검증으로 이어지는 다단계 과정이라고 본다. 기존 RAG는 지원 사례를 정적인 문서로 취급해 이런 상태성과 중간 단계를 반영하지 못하고, GraphRAG는 엔티티 중심 그래프를 오프라인에서 만들어 검색을 유도하지만 개별 조사의 진행 과정을 명시적으로 표현하지 않는다. 논문은 기존 접근의 네 가지 한계로 잡음 많고 비구조적인 원시 데이터, 일관성 없는 검색 청크, 진단·해결에 쓸모없는 비실행 사례, 개인정보 제약을 든다. RAFT는 이 문제를 검색 계층에서 직접 평가하며, 전체 에이전트 시스템이나 운영 환경 배포 없이도 재현 가능한 비교를 하려 한다.

어떻게 동작하나

RAFT의 색인은 각 닫힌 사례 h_i를 구조화된 표현으로 바꾼다. 그 표현은 검토자 평가 rho_i, 시간순 타임라인 엔트리 집합 phi_k, 확립된 근본 원인 r_i, 문서화된 해결 또는 완화 단계 a_i, 트러블슈팅 관련 엔티티 e_i로 구성된다. 작업자는 이메일, 노트, 로그 같은 순서 있는 산출물을 제한된 배치로 처리하면서 이전 배치의 사례 상태를 다음 배치로 넘기고, 새 발견을 추가하거나 이전 해석을 수정한다. 모든 배치가 끝나면 검토자가 누락과 불일치를 확인해 rho_i를 만든다. 타임라인 엔트리는 연속된 턴을 의미 있는 조사 단계로 증류한 것이며, 문제의 틀이나 현재 이해가 실질적으로 바뀌는 상태 전이마다 새 엔트리가 시작된다. 감사 인사나 새 통찰이 없는 사소한 업데이트는 현재 엔트리에 흡수되어 K_i가 전체 턴 수 T_i보다 훨씬 작아진다. 선택적으로 사례 수준 그래프 G=(V,E)를 만들며, 연결에 쓸 텍스트는 근본 원인, 이슈 요약 등 배포별로 설정할 수 있다. 실험에서는 근본 원인과 해결 텍스트를 이어 붙이고, 의미 유사도와 BM25 어휘 유사도를 RRF로 결합해 모든 사례 쌍을 점수화한 뒤 각 사례를 상위 k개 이웃에 연결하고 대칭화하며 공유 최근접 이웃 가중치를 부여한다.

무엇과 다른가

검색은 사례 전체가 아니라 타임라인 엔트리 단위로 이뤄진다. 색인된 모든 사례의 모든 엔트리를 임베딩해 두고, 질의 q가 들어오면 사용자가 지정한 사례 필터를 적용한 뒤 남은 사례의 엔트리를 하이브리드 점수로 순위화한다. 그다음 순위가 높은 엔트리를 부모 사례로 탐욕적으로 승격해, 미리 정한 컨텍스트 예산 안에서 최대 n개의 서로 다른 사례를 고른다. 선택된 각 사례 c에 대해 가장 높은 점수를 받은 엔트리 k*_c가 앵커로 함께 반환되므로, 에이전트는 어떤 사례가 걸렸는지뿐 아니라 어떤 조사 상태가 매칭됐는지도 본다. 초기 엔트리 수준 매칭으로 시드 사례를 찾은 뒤에는 사례 수준 그래프를 통해, 엔트리 수준에서는 매칭되지 않지만 설정된 연결 관점에서는 유사한 이웃으로 확장할 수 있다. 저자들은 초기 n을 단순히 늘리면 잡음이 늘어나므로 그래프 확장이 더 표적화된 방법이라고 주장한다. 이 설계는 질의가 초기 증상만 담을 때는 과거 사례의 도입 엔트리와, 조사가 진행될수록 중간 상태 엔트리와 매칭되도록 만든다.

어떻게 쓰나

실험은 공개 다단계 트러블슈팅 데이터가 거의 없다는 문제에서 출발한다. 저자들은 Microsoft Learn Windows Server 트러블슈팅 문서로 만든 합성 벤치마크와, 사람이 만든 중복 레이블이 있는 실제 Apache Jira 이슈를 함께 사용한다. 합성 벤치마크는 826개 지원 사례로 구성되며, 문서화된 근본 원인마다 2~4개 사례를 생성하고 근본 원인 그룹마다 하나를 테스트 질의로 홀드아웃해 나머지를 색인 코퍼스로 둔다. 합성 사례는 평균 2767토큰이다. 베이스라인은 vanilla RAG, HippoRAG2, Fast-GraphRAG이며, 모든 방법이 text-embedding-3-large 임베딩과 gpt-5.2 색인 LLM을 공유하고 평가에는 gpt-5.4를 쓴다. 메타데이터 필터링은 적용하지 않았고, 합성 코퍼스의 모든 사례가 실행 가능하므로 RAFT의 실행 가능성 필터는 이 비교에서 아무 사례도 제외하지 않아 이점을 주지 않는다. 검색 컨텍스트는 6000토큰으로 제한하고, 사례 단위를 반환하는 방법은 5개 사례로도 제한한다. 평가는 각 테스트 사례의 턴 접두사 0%, 30%, 60% 지점에서 질의를 만들고 Case Hit, Root Cause Coverage, Resolution Steps Coverage를 측정한다. RAFT는 모든 지표에서 가장 좋았고, 0% 진행에서 Case Hit 84.2%로 vanilla RAG 67.3%, HippoRAG2 65.0%를 앞섰으며 60% 진행에서는 88.8%에 도달했다. 가장 강한 베이스라인인 vanilla RAG 대비 Case Hit 개선은 근본 원인 그룹으로 클러스터링한 부트스트랩 재표본에서 세 진행 지점 모두 통계적으로 유의했다. Fast-GraphRAG는 모든 진행 수준에서 vanilla RAG보다 낮았고 HippoRAG2도 vanilla RAG를 넘지 못했다. 매칭이 사례 내 어디에서 일어나는지 보면 평균 깊이가 0%에서 9.1%, 60%에서 54.0%로 깊어져, 질의가 진행될수록 중간 상태와 맞는 의도된 동작을 확인했다. 잡음 질의에 대한 강건성 실험에서도 RAFT는 vanilla RAG보다 덜 악화됐다.

전제와 한계

실제 데이터로의 전이를 확인하기 위한 Apache Jira 평가는 공개 Jira 프로젝트에서 엔지니어가 중복 이슈를 연결한 기록을 사용한다. 최종 평가 세트는 감사된 중복 그룹 30개이며, 각 그룹은 추가로 해결된 Fixed 이슈 570개를 방해 항목으로 두고 기여자가 작성한 비편집 이슈 이력을 대상으로 평가된다. RAFT는 합성 실험의 추출 프롬프트, 스키마, 모델, 검색 절차를 바꾸지 않고 그대로 적용됐고, 비교 대상은 합성에서 가장 강한 베이스라인이었던 vanilla RAG다. Case Hit는 0%, 30%, 60% 진행 지점에서 각각 16.7, 17.3, 10.5 퍼센트포인트 향상됐다. 저자들은 이를 실제 사례 이력으로 이점이 전이된다는 방향성 증거로 해석한다. 논문은 벤치마크, 구현, Apache Jira 평가 세트를 github.com/microsoft/RAFT에 공개한다고 밝힌다.

개발자 관점에서 RAFT는 기업 지원, IT 서비스, 장애 대응처럼 과거 티켓이 많고 조사가 여러 단계로 진행되는 에이전트에 적합하다. 티켓 전체를 하나의 문서로 임베딩하는 대신, 조사 단계별 타임라인 엔트리를 만들어 현재 상태와 맞는 과거 사례를 찾고 그 사례의 전체 궤적을 앵커와 함께 보여주는 방식은, 에이전트가 다음 단계 지침과 전체 해결 맥락을 동시에 얻는 데 초점이 있다. 도입을 검토한다면 원시 티켓에서 타임라인 엔트리를 얼마나 잘 추출하는지, 상태 전이 경계를 어떻게 정하는지, 사례 그래프의 연결 텍스트와 top-k, RRF 가중치를 어떻게 설정하는지, 검색 컨텍스트 토큰 예산과 반환 사례 수를 어떻게 제한하는지 확인해야 한다. 또한 실행 가능성 필터와 개인정보 비식별화 계층이 실제 코퍼스에서 어떤 사례를 제외하는지도 중요하다. 이 논문은 검색 계층만 평가하므로, 최종 진단 정확도나 해결 성공률, 엔지니어 생산성 같은 엔드투엔드 효과는 별도로 검증해야 한다.

저자들이 밝힌 한계는 분명하다. 주 평가는 중간 규모의 합성 데이터셋에서 이뤄졌고, 실제 운영 코퍼스는 사례 수가 훨씬 많고 사례당 토큰 수도 훨씬 클 수 있다. Apache Jira 평가는 감사된 중복 그룹 30개에 불과하고 신뢰구간도 제시하지 않아 포괄적인 실제 평가가 아니라 방향성 전이 증거로 취급된다. 이 연구는 최종 진단, 해결 성공, 엔지니어 생산성, 기타 엔드투엔드 트러블슈팅 결과를 평가하지 않으며, 검색 계층에 범위를 한정한다. 따라서 RAFT의 기여는 상태 기반 검색 표현과 그 검색 품질의 개선에 있으며, 전체 에이전트의 문제 해결 능력 향상을 주장하는 것은 아니다.