시리즈: GraphRAG 구축기 #15이전: 14편 | 목록 | 다음: 16편2026년 5월 13일 | 개발 일기GraphRAG profile registry가 action report를 읽는 쪽까지 연결됐다. 지난 반복에서는 실행할 profile 목록을 configs/profile_registry.json에 묶어 두고, active, observe, disabled 상태를 나눴다. 그런데 여전히 찜찜한 구석이 있었다. history-stale-origin-actions.json이 “이 profile은 관찰 후보”라고 말해도, 그 판단이 registry 안에는 자동으로 남지 않았다.그래서 이번에는 검색 점수식을 건드리지 않고, 운영 장부를 이어 붙이는 쪽으로 작게 갔다. 이름은 registry actio..
시리즈: GraphRAG 구축기 #13이전: 12편 | 목록 | 다음: 14편2026년 5월 7일 | 개인 프로젝트 · GraphRAGsame-status-from-start로 묶인 profile 두 개가 계속 같은 줄에 남아 있는 것이 GraphRAG 루프에서 제일 거슬렸다. 이전 반복에서 만든 stale origin queue는 "처음부터 같은 non-pass 상태였던 profile"을 잘 골라냈지만, 거기서 한 걸음 더 나아가지는 않았다. path_bridge_probe와 path_bridge_focus가 모두 같은 queue에 들어왔고, 나는 다시 파일을 열어서 하나는 관찰 후보인지, 하나는 제외 후보인지 손으로 읽어야 했다.이런 상태가 몇 번 반복되면 report가 도움을 주는 게 아니라 rep..
시리즈: GraphRAG 구축기 #4이전: 3편 | 목록 | 다음: 5편2026년 4월 24일 | 프로젝트quality_history.json 파일 하나가 생기자 PASS, WARN, HARD-FAIL 세 칸이 처음으로 시간축을 갖기 시작했다. 최근 GraphRAG 쪽은 rank shift report, cluster/tag summary, expected title 기반 품질 지표, staged quality gate까지 차근차근 붙여 오면서 지금 이 profile이 어떤 상태인가는 꽤 빨리 읽을 수 있게 됐다. 그런데 막상 며칠 단위로 실험을 이어 가려니 또 다른 빈칸이 남아 있었다. 이 상태가 어제도 같았는지, warning scope가 늘어난 건지, 숫자는 그대로인데 실패 성격이 바뀐 건지를 보려..
2026년 4월 20일 | 개발 공부Quality Gate는 실험 결과나 검색 profile을 배포 후보인지 아닌지로 자르는 최소 판정 레이어다. 처음에는 나도 pass/fail 두 칸이면 충분하다고 생각했다. 기준선을 넘으면 통과시키고, 못 넘으면 탈락시키면 되는 일처럼 보였기 때문이다. 그런데 최근 retrieval 실험을 계속 보다 보니, 바로 버려야 하는 후보와 아직 더 실험해볼 후보가 같은 fail 안에 눌려 버리는 순간이 생각보다 자주 나왔다.특히 GraphRAG 쪽에서 score profile을 여러 개 비교할 때 이 차이가 또렷했다. 어떤 profile은 overall 품질이 조금만 미끄러져서 "배포는 아직 이르지만 방향은 볼 만한 상태"에 머무르고, 어떤 profile은 핵심 questi..
2026년 4월 16일 | 프로젝트query 세트가 여섯 개쯤만 되어도, 어떤 질문 묶음이 흔들렸는지를 내가 다시 손으로 묶어 보는 시간이 은근히 길어졌다. 최근 GraphRAG 쪽은 rank shift 이유 라벨까지는 잘 남기고 있었는데, 그다음 단계에서 여전히 coverage-sensitive 류 질문이 같이 무너졌는지, 아니면 한두 개 query만 우연히 흔들린 건지를 내가 다시 눈으로 분류해야 했다.그래서 이번에는 scoring 공식을 하나 더 늘리기보다, query 파일 자체에 묶음 정보를 넣고 group 단위로 읽는 판독면을 먼저 붙였다. `profile_eval`이 이제는 `{label, query, cluster, tags}` 구조를 읽고, default 대비 결과 안에 cluster_su..
2026년 4월 15일 | 프로젝트rank-shift report를 붙인 뒤에도 마지막으로 남는 손작업이 하나 있었다. 흔들린 query가 왜 흔들렸는지를 내가 숫자를 다시 읽으면서 머릿속에서 분류하는 일이다. GraphRAG 쪽은 edge, path, coverage가 같이 섞여 있어서, rank shift 1건만 적어 두면 설명이 끝난 것 같아도 막상 다음 반복에 다시 들어갈 때는 한 번 더 표를 들춰보게 된다.그래서 이번에는 새 scoring profile을 더 만들기보다, 흔들림 자체에 이름을 붙이는 얇은 레이어를 먼저 올렸다. `profile_eval`이 rank-shift report를 만들 때 이제는 `primary_shift_reason`과 `shift_reason_labels`를 같이 남..