[AI 실험실]/[개인 프로젝트] GraphRAG / GraphRAG | Exit Policy Draft의 registry 반영.md

GraphRAG | Exit Policy Draft의 registry 반영

조회

시리즈: GraphRAG 구축기 #21

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

2026년 6월 23일 | 개인 프로젝트 · GraphRAG


GraphRAG profile registry에서 장기 observe 상태로 남은 profile을 볼 때마다, 나는 한 가지가 계속 걸렸다. 평가 결과로는 아직 버리기 애매하고, 그렇다고 active baseline처럼 믿기에도 애매한 profile이 있다. 그 profile을 그냥 observe로만 두면 다음 실험에서 다시 같은 질문을 하게 된다. “이건 언제 승격하고, 언제 끄고, 언제 사람 검토로 넘길까?”라는 질문이다.

이번 회차에서는 그 질문을 코드로 아주 작게 정리했다. 핵심은 exit policy draft를 profile registry의 눈에 보이는 정책 필드로 올리는 것이다. 바로 active 정책으로 승격한 것은 아니다. 아직 수동 확인이 필요한 조건은 그대로 draft로 두되, 더 이상 last_action 깊은 곳에 묻혀 있지 않게 만들었다.

GraphRAG exit policy draft materialization 흐름
장기 observe profile의 exit policy draft를 profile-level policy로 올리되, manual-confirmation gate는 그대로 남긴 구조.

observe 상태가 길어질 때 생기는 문제

지금 GraphRAG MVP에는 여러 scoring profile이 있다. 어떤 profile은 안정적인 baseline이고, 어떤 profile은 특정 질의 묶음에서만 좋아 보이는 probe다. 문제는 probe가 애매하게 오래 살아남을 때다. 예를 들어 path_bridge_probe는 bridge 성격의 질의에서 볼 만한 신호가 있었지만, 전체 top-1 hit rate나 full coverage 기준에서는 warning scope가 계속 남았다.

이런 profile을 곧바로 disable하면 나중에 놓친 신호가 아깝다. 반대로 active처럼 두면 sweep 결과를 해석할 때 baseline과 probe가 섞인다. 그래서 이전 회차에서는 review queue와 action draft를 만들고, “일단 더 관찰하되 exit 조건 초안을 붙이자”라는 형태로 닫았다. 다만 그 초안이 registry의 주 필드가 아니라 last_action.exit_policy_draft 안에만 있었다.

나는 여기서 작은 불편함을 기준선으로 삼았다. 다음번에 registry를 열었을 때 사람 눈에 바로 보여야 하는 정보는 최신 action 로그가 아니라 이 profile을 언제 닫을지에 대한 조건이다. 그래서 이번에는 조건을 profile-level exit_policy로 materialize했다.

이번에 붙인 최소 기능

새로 추가한 함수는 registry를 훑으면서 각 profile의 last_action.exit_policy_draft를 찾는다. draft가 있으면 그 내용을 복사해 exit_policy 필드를 만든다. 단순 복사만 하면 위험하니, 몇 가지 메타데이터를 같이 넣었다.

가장 중요한 값은 policy_statusactivation_gate다. draft에 requires_manual_confirmation이 남아 있으면 policy는 draft 상태이고, gate는 manual-confirmation으로 기록된다. 즉 registry에 올라갔다고 해서 자동으로 promote나 disable 판단에 쓰이는 것은 아니다. “정책으로 보이게 만들었지만 아직 사람이 승인해야 한다”는 상태가 JSON 안에 남는다.

CLI에도 옵션을 붙였다. 하나는 실제 출력 registry에 policy를 반영하는 옵션이고, 다른 하나는 어떤 profile이 materialize됐는지 별도 report로 남기는 옵션이다. 이렇게 해 두면 preview만 보고 멈출 수도 있고, config에 직접 반영하면서 smoke report까지 같이 만들 수도 있다.

path_bridge_probe에 남긴 조건

이번에 실제로 반영된 profile은 path_bridge_probe 하나다. 이 profile은 여전히 observe 상태다. 대신 이제 registry에서 바로 다음 조건을 볼 수 있다.

  • 연속 pass 3회가 나오면 promote 후보로 볼 수 있다.
  • 연속 hard fail 2회가 나오면 disable 후보로 볼 수 있다.
  • warning streak가 12회까지 이어지면 manual review 대상으로 본다.
  • 좁혀야 할 warning scope 6개를 그대로 보존한다.

여기서 마음에 든 부분은 “좋아지면 올리고, 나빠지면 끈다”를 말로만 적은 게 아니라, registry 안에 숫자로 남겼다는 점이다. 작은 값들이지만 다음 평가 결과를 읽을 때 꽤 도움이 된다. 예전에는 warning이 또 뜨면 “이 profile은 원래 애매했지” 정도로 넘어갔는데, 이제는 “이 조건을 채웠는지”를 바로 물을 수 있다.

검증하면서 확인한 것

단위 테스트는 profile registry 쪽을 먼저 늘렸다. manual confirmation이 필요한 draft는 policy_status: draft로 남아야 하고, source action report와 review queue 경로도 보존되어야 한다. 이 부분이 깨지면 나중에 왜 이 policy가 생겼는지 추적하기 어렵다.

그 다음 전체 테스트를 돌렸다. 이번 변경은 retrieval ranking 자체를 건드리지는 않았지만, registry CLI는 여러 report 생성 경로와 연결되어 있다. 그래서 profile registry 테스트만 통과했다고 끝내지 않고 전체 회귀 테스트까지 확인했다. 결과는 전체 47개 테스트 통과였다.

실행 산출물도 따로 남겼다. preview registry, materialization report, review smoke report를 한 묶음으로 남기니 이번 회차의 기준선이 더 분명해졌다. 특히 smoke report가 계속 pass로 남은 점이 중요했다. policy를 profile-level로 올렸지만, 같은 profile이 다시 review queue에 열린 항목으로 들어오지는 않았다.

작지만 다음 실험이 쉬워진 지점

이번 작업은 화려한 기능은 아니다. 검색 품질 숫자가 갑자기 오르지도 않는다. 그래도 나는 이런 종류의 작은 운영 코드가 GraphRAG 실험에서는 꽤 중요하다고 본다. graph score와 vector score를 조합하다 보면 profile이 자꾸 늘고, profile이 늘면 “어떤 실험을 계속 믿을지”를 결정하는 기준도 같이 늘어야 한다.

이번 기준선 덕분에 다음에는 두 갈래로 갈 수 있다. 하나는 draft policy를 실제 active policy로 승격하는 승인 기준을 분리하는 일이다. 다른 하나는 warning_scopes_to_narrow에 남은 doc-bridges 쪽 scope를 줄이는 profile 수정 실험이다. 둘 중 어느 쪽으로 가든, 적어도 이제는 장기 observe profile이 왜 남아 있는지와 언제 닫을지를 registry 안에서 바로 읽을 수 있다.

GraphRAG MVP를 만들면서 계속 느끼는 건, 검색 알고리즘보다 주변의 판정 장치가 더 오래 발목을 잡을 때가 많다는 점이다. 이번에는 그 발목을 조금 덜 잡히게 만든 회차였다. 다음 실험에서는 이 policy를 실제 action report 생성 단계에서 읽게 해 볼 생각이다.

시리즈: GraphRAG 구축기 #21

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

댓글

홈으로 돌아가기

검색 결과

"" 검색 결과입니다.