GraphRAG | observe profile 장기 관찰 큐

시리즈: GraphRAG 구축기 #19

이전: 18편 | 목록 | 다음: 20편

2026년 5월 18일 | 개인 프로젝트 GraphRAG

---

GraphRAG의 observe profile은 버리기에는 아깝고, 그렇다고 active 기준선으로 보기에는 아직 찜찜한 설정을 임시로 붙잡아 두는 칸이다. 몇 번 전부터 path_bridge_probe를 이 칸에 넣어 두고 있었는데, 막상 run이 쌓이니 다른 문제가 보였다. keep-observing이라는 판단이 계속 정상적으로 나오는데, 관찰이 길어지고 있다는 사실 자체는 따로 보이지 않았다.

이번 작업은 그 빈칸을 줄이는 쪽으로 잡았다. 점수 계산이나 retrieval ranking을 바꾸는 작업은 아니고, observation review 뒤에 registry-observation-aging.json이라는 작은 queue를 하나 더 붙였다. 이름은 조금 길지만, 역할은 단순하다. 계속 관찰하자는 profile 중에서 같은 상태가 오래 반복되는 것만 다시 모아 “이제 종료 조건을 정해야 하지 않나?”를 보여 주는 report다.

observation review 뒤에 aging queue를 하나 더 두어, keep-observing이 길어지는 profile만 따로 접었다.

왜 keep-observing만으로는 부족했나

전 단계까지 만든 흐름은 나쁘지 않았다. registry에는 active, observe, disabled 상태가 있고, observation review는 observe profile을 다시 읽어 promote-candidate, keep-observing, disable-candidate로 분류한다. 거기에 registry sync까지 연결했기 때문에, review 결과를 preview로 넣어 보고 안전하면 registry provenance도 갱신할 수 있었다.

그런데 keep-observing은 애매하게 편한 판단이다. 당장 hard-fail은 아니니 끄지 않고, PASS streak도 아니니 승격하지 않는다. 이 자체는 맞다. 문제는 같은 판단이 5번, 10번, 12번 이어질 때다. 여전히 맞는 판단일 수도 있지만, 그냥 종료 조건을 안 정해서 계속 남아 있는 것일 수도 있다.

나는 이 구간을 그냥 summary 한 줄에 묻어 두면 나중에 헷갈릴 것 같았다. 실험 profile이 observe에 오래 머물수록 “이건 아직 보는 중인가, 아니면 결정을 미루는 중인가”가 흐려진다. 그래서 이번에는 keep-observing 자체를 실패로 보지 않되, 오래 이어지는 keep-observing만 따로 queue로 빼기로 했다.

이번에 붙인 것

새로 만든 report는 reports/registry-observation-aging.json이다. 입력은 기존 registry-observation-review.json이고, 조건은 일부러 얇게 잡았다.

• recommended_registry_action이 keep-observing일 것
• 같은 status streak가 기본 3회 이상일 것
• profile 이름, registry status, warning scope, last_action provenance를 그대로 보존할 것
• observation_followup과 exit_condition_candidates를 붙일 것

text summary에도 새 줄을 하나 추가했다. 이제 bundle 상단에서 이런 식으로 바로 보인다.

registry-observation-aging: .../registry-observation-aging.json | profiles=1 | min_streak=3 | followups=review-exit-condition:1

이 줄을 보려는 이유는 명확하다. observation review는 “이번 판단이 keep-observing이다”를 말하고, aging queue는 “그 keep-observing이 오래됐다”를 말한다. 둘을 한 파일에 섞지 않고 나눈 것도 일부러다. review는 현재 상태 분류이고, aging은 상태가 길어졌을 때의 후속 검토 queue에 가깝다.

테스트에서 고정한 장면

테스트는 기존 observation review 케이스를 확장했다. path_bridge_probe를 observe 상태로 두고, 이전 history에 WARN run을 몇 개 넣은 뒤 현재 run을 붙인다. 기대값은 observation review에서 keep-observing: 1이 나오고, 이어서 aging report에서도 profile 하나가 잡히는 것이다.

aging report 쪽에서는 observation_followup이 review-exit-condition인지 확인했다. 그리고 후보 조건에는 promote-after-pass-streak, disable-after-hard-fail-streak, manual-review-if-warning-streak-persists 같은 값이 남는다. 여기서 바로 registry를 바꾸지는 않는다. 이번 단계는 자동 처리가 아니라, 사람이 다음 판단을 덜 조립하게 만드는 queue에 가깝다.

전체 테스트는 41개가 통과했다. 테스트 개수는 늘지 않았지만, 기존 observation review 테스트가 더 많은 구조를 검증하게 됐다. 이런 작은 report 레이어는 숫자 하나보다 필드 보존이 더 중요해서, JSON payload 안의 field가 사라지지 않는지를 테스트로 잡아 두는 편이 마음이 편하다.

iter37 실행 결과

실제 operational history를 이어서 돌려 보니 예상한 결과가 나왔다. default와 relation_weight_dense는 계속 PASS streak를 유지했고, path_bridge_probe는 여전히 WARN 상태였다. 중요한 건 이번에 그 WARN이 얼마나 길어졌는지가 report 상단에 바로 드러났다는 점이다.

항목	결과	해석
registry-observation-review	keep-observing: 1	observe profile을 아직 승격/비활성화하지 않음
registry-observation-aging	review-exit-condition: 1	관찰 종료 조건을 검토할 profile 1개
path_bridge_probe	WARNx12	hard-fail은 아니지만 warning streak가 길어짐
warning scope	overall, doc-bridges, docs	다음 profile 수정은 이 범위를 먼저 보면 됨

여기서 path_bridge_probe를 바로 disabled로 내리지는 않았다. WARNx12라는 숫자만 보면 오래 버틴 실패처럼 보이지만, hard-fail은 아니고 일부 query family에서는 여전히 쓸 만한 움직임이 있다. 그래서 이번 report의 결론은 “비활성화”가 아니라 “관찰 종료 조건을 검토”하는 쪽이다.

하면서 느낀 점

GraphRAG 프로젝트가 점점 검색기 자체보다 검색 실험을 읽는 장부에 가까워지고 있다. 처음에는 ranking을 조금이라도 낫게 만드는 데 집중했는데, 지금은 어떤 profile이 살아 있고, 왜 살아 있고, 언제 내려야 하는지를 기록하는 일이 더 중요해졌다. 솔직히 화려한 작업은 아니다. 하지만 이런 장부가 없으면 profile이 셋만 넘어가도 실험이 금방 감으로 굴러간다.

이번 aging queue도 그런 의미의 작업이다. 결과 점수가 좋아진 것은 아니다. 대신 “계속 관찰”이라는 편한 결정을 오래 반복할 때, 그 반복 자체를 다시 보게 만들었다. 나는 이 정도의 마찰이 필요하다고 본다. 실험에서 보류는 꼭 필요하지만, 보류가 너무 조용하면 언젠가 방치가 된다.

다음에는 이 queue를 실제 action sync preview와 어떻게 연결할지 봐야 한다. 지금은 review-exit-condition이라는 follow-up만 남긴다. 여기서 한 단계 더 가면, warning streak가 일정 횟수 이상이면 수동 review를 강제하거나, threshold를 CLI option으로 조정하는 방식도 생각해 볼 수 있다. 다만 바로 자동 disable까지 가고 싶지는 않다. 아직은 warning scope를 좁히고, path_bridge_probe가 왜 doc-bridges에서 계속 밀리는지 먼저 보는 편이 맞아 보인다.

시리즈: GraphRAG 구축기 #19

이전: 18편 | 목록 | 다음: 20편