GraphRAG | Same-status stale queue 추가

시리즈: GraphRAG 구축기 #12

이전: 11편 | 목록 | 다음: 13편

2026년 5월 6일 | 개발 일기

---

GraphRAG profile_eval에 queue를 하나 더 얹었다. 이름은 글에서는 same-status stale queue라고 부르지만, 실제 산출물 파일은 history-stale-origin.json이다. 전 단계에서 만든 stale status queue가 오래 반복되는 non-pass profile을 잡아 줬다면, 이번에는 그 안에서도 처음부터 같은 상태로 굳어 있던 profile만 다시 따로 뺐다.

작업 자체는 크지 않았다. 그래도 붙이고 나니 summary를 읽는 순서가 꽤 달라졌다. 예전에는 WARNx6나 HARD-FAILx6를 보면 곧장 trace diff를 다시 열었다. 그런데 이 상태가 개선 뒤 정체인지, 악화 뒤 정체인지, 아니면 history 시작부터 계속 같은 상태였는지에 따라 다음 행동은 다르다. 이번 변경은 그중 마지막 케이스를 조용히 분리하는 쪽에 가깝다.

Figure 1: stale status queue에서 same-status-from-start profile만 다시 분리한 구조

1. 왜 또 queue를 나눴나

지난 반복에서 stale transition split을 붙였다. 같은 stale 상태라도 이전 distinct 상태와 비교해서 좋아진 뒤 멈춘 것인지, 나빠진 뒤 멈춘 것인지, 아니면 처음부터 같은 상태였는지 나눠 보자는 의도였다. 운영 run을 돌려 보니 결과는 조금 허무했다. path_bridge_probe와 path_bridge_focus가 둘 다 same-status-from-start로 나왔다.

처음에는 새 분류가 별로 일을 안 한 것처럼 보였다. 하지만 다시 보니 그게 오히려 중요한 신호였다. compatible history 기준으로 처음부터 WARN이었던 profile을 두고 “개선이 멈췄다”고 말하면 과잉 해석이다. 처음부터 HARD-FAIL이었던 profile을 두고 “최근에 망가졌다”고 말해도 마찬가지다. 그래서 이번에는 same-status-from-start만 따로 모아, 방향을 붙이기 전에 한 번 더 멈추게 만들었다.

2. 구현은 기존 stale report를 재사용

새 기능을 만들면서 별도 계산을 다시 하지 않았다. 이미 history-stale-status.json 안에는 profile 이름, latest status, streak count, previous distinct status, stale transition이 들어 있다. 이번에는 그 report를 한 번 더 읽는 방식으로 갔다. 조건은 단순하다. stale_transition 값이 same-status-from-start인 항목만 모아 history-stale-origin.json으로 저장한다.

• source_stale_status_report_path: 원본 stale status report를 되짚는 경로
• profile_count: origin queue에 들어온 profile 수
• status_counts: WARN과 HARD-FAIL 같은 최신 상태별 개수
• history_namespace_counts: operational, sample 같은 namespace별 개수
• profiles: 실제로 다시 열 profile payload

일부러 새 CLI 옵션은 만들지 않았다. stale status report가 필요한 상황이면 origin queue도 거의 같이 필요하다고 봤다. 옵션을 하나 더 두면 어느 날은 report가 있고 어느 날은 없어져서, 나중에 history bundle을 비교할 때 더 헷갈릴 가능성이 크다. 그래서 trace_dir와 history 파일이 주어진 실행에서는 두 report를 항상 함께 남기게 했다.

3. 이번 run에서 보인 결과

iter28 history를 seed로 복사한 뒤 iter29-stale-origin-queue를 append했다. 결과는 예상대로였다. default와 relation_weight_dense는 PASS streak라 기본 stale queue에서 빠졌다. 반면 path_bridge_probe와 path_bridge_focus는 각각 WARN과 HARD-FAIL 상태가 6회 이어졌고, 둘 다 이전 distinct status가 없었다.

profile	latest status	streak	stale transition	이번 해석
default	PASS	PASSx6	queue 제외	안정 기준선 유지
relation_weight_dense	PASS	PASSx6	queue 제외	stable lane 유지
path_bridge_probe	WARN	WARNx6	same-status-from-start	관찰 후보, 개선 방향 단정 금지
path_bridge_focus	HARD-FAIL	HARD-FAILx6	same-status-from-start	장기 제외 후보로 별도 관리

summary 상단에는 이제 두 줄이 붙는다. 첫 줄은 전체 stale queue이고, 둘째 줄은 origin queue다. 내가 실제로 보는 순서는 둘째 줄이 먼저에 가깝다. history-stale-origin-report에 profile이 있으면, 그 profile은 “방금 나빠진 것”이 아니라 처음부터 같은 non-pass 상태로 오래 남은 것으로 읽어야 한다. 이 차이가 작아 보여도, 다음 작업을 정할 때는 꽤 크게 느껴진다.

4. 테스트에서 고정한 경계

회귀 테스트도 하나 늘렸다. synthetic history에 path_bridge_probe는 WARN으로 두 번, path_bridge_focus는 HARD-FAIL로 두 번 넣어 둔 뒤, 현재 run에서도 같은 상태가 나오도록 만들었다. 이때 origin report는 두 profile을 모두 잡아야 하고, status count는 hard-fail:1, warning:1이어야 한다.

전체 테스트는 32개를 다시 돌렸다. 이번 테스트에서 더 보고 싶었던 건 단순히 파일이 생성되는지가 아니었다. source_stale_status_report_path가 원본 stale report를 가리키는지, previous_distinct_status가 비어 있는 profile만 들어오는지, text summary에 history-stale-origin-report가 실제로 노출되는지까지 같이 확인했다.

5. 남은 판단

이번 변경은 검색 품질을 올리는 작업은 아니다. 오히려 품질 판단을 조금 더 늦추는 작업이다. GraphRAG 실험을 오래 돌리다 보면 숫자가 많아질수록 사람이 더 확신하게 된다. 그런데 확신이 빠르면 틀린 이야기도 빨리 붙는다. same-status stale queue는 그 지점에서 “이건 개선도 악화도 아니라, 시작부터 같은 상태였을 수 있다”고 말해 주는 작은 브레이크다.

다음에는 이 origin queue 안에서도 한 번 더 나눠 볼 생각이다. WARN으로 오래 남은 profile은 관찰 후보일 수 있지만, HARD-FAIL로 오래 남은 profile은 튜닝 대상이 아니라 제외 후보에 가까울 수 있다. 결국 내가 필요한 건 더 많은 report가 아니라, 다음에 열어 볼 목록을 더 작게 만드는 report다. 이번 작업은 그 목록을 한 칸 더 접은 정도의 변화였다.

시리즈: GraphRAG 구축기 #12

이전: 11편 | 목록 | 다음 없음