시리즈: GraphRAG 구축기 #14이전: 13편 | 목록 | 다음 없음2026년 5월 12일 | 개인 프로젝트 · GraphRAGexclude-candidate로 표시해 둔 profile이 다음 실행에서도 계속 평가되는 게 최근 GraphRAG 루프에서 조금 찜찜했다. iter30에서 stale origin action queue를 붙이면서 path_bridge_focus는 제외 후보, path_bridge_probe는 관찰 후보로 잘 갈라졌다. 그런데 막상 다음 profile sweep을 돌리면, 명령어에 세 profile을 그대로 넣는 한 제외 후보도 다시 평가 대상에 들어왔다.그래서 이번 반복은 새 점수식을 만드는 쪽이 아니라, 이전 report의 판단을 다음 실행에 반영하는 쪽으로 잡았다. 이..
시리즈: 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 구축기 #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를 다시 열었다. 그..
2026년 4월 29일 | 개인 프로젝트 GraphRAGGraphRAG profile_eval에서 history mismatch report를 열 때마다 한 번 더 손이 갔다. 지난 반복에서 이미 query_set, quality_gate, dataset, top_k 같은 mismatch reason을 section으로 접어 두긴 했다. 그런데 실제로 report를 읽다 보면 reason을 확인한 뒤에도 곧바로 다른 값을 다시 봐야 했다. 이 mismatch가 단순히 기준선이 달라진 흔적인지, 아니면 같은 순간에 profile의 PASS/WARN/HARD-FAIL 상태도 흔들린 건지 한 화면에서 바로 안 보였기 때문이다.그래서 이번 작업은 점수를 더 올리는 쪽이 아니라, 읽는 순서를 한 칸 더 줄이는 쪽..
시리즈: GraphRAG 구축기 #11이전: 10편 | 목록 | 다음: 12편2026년 5월 2일 | 개인 프로젝트GraphRAG quality history를 보다가 같은 정체 상태도 방향이 다르다는 점이 계속 걸렸다. 전 회차에서 만든 stale status queue는 `WARNx3`, `HARD-FAILx3`처럼 오래 반복되는 non-pass profile을 잘 줄여 줬다. 그런데 그 숫자만 보고 있으면 한 가지 중요한 맥락이 빠진다. 이 warning이 hard-fail에서 내려온 뒤 멈춘 것인지, 아니면 pass에서 밀려 올라온 뒤 멈춘 것인지가 보이지 않았다.이번 반복에서는 그 빈칸을 아주 작게 메웠다. 이름은 거창하지 않게 stale transition split이라고 붙였다. 기존 `hi..
시리즈: GraphRAG 구축기 #10이전: 9편 | 목록 | 다음: 11편2026년 5월 1일 | 개인 프로젝트 GraphRAGHistory status streak를 붙이고 나니, 숫자는 보이는데 다음 행동은 아직 손으로 골라야 했다. `PASSx3`, `WARNx3`, `HARD-FAILx3`가 한 줄에 같이 나오면 처음에는 꽤 시원해 보인다. 그런데 막상 다음 실험을 잡으려고 보면, 나는 다시 summary를 훑으면서 “그래서 어떤 profile부터 열어야 하지?”를 묻고 있었다. 이건 지표가 부족하다기보다, 지표를 작업 큐로 접는 단계가 하나 빠진 상태에 가까웠다.이번 GraphRAG 반복에서는 그 빈칸을 작게 메웠다. `profile_eval`에 history stale status queue..
시리즈: GraphRAG 구축기 #9이전: 8편 | 목록 | 다음: 10편2026년 5월 1일 | 개발 일기GraphRAG profile_eval의 history 줄은 점점 길어지고 있었다. 처음에는 실행 결과를 한 번 더 저장해 두는 정도였는데, 어느 순간부터는 quality gate, history transition, baseline mismatch, namespace, scope growth queue까지 붙었다. 기능이 늘어난 건 좋은데, 내가 실제로 summary를 볼 때 제일 먼저 알고 싶은 건 더 단순했다. 이 profile이 지금 막 바뀐 건지, 아니면 같은 상태로 계속 버티고 있는지였다.그래서 이번에는 점수를 올리는 쪽이 아니라, 상태가 몇 run째 반복되는지를 보여 주는 작은 필드를 ..
시리즈: GraphRAG 구축기 #8이전: 7편 | 목록 | 다음: 9편2026년 4월 30일 | 개인 프로젝트 GraphRAGHistory 파일이 길어지기 시작하면, 성능 변화보다 먼저 장부가 섞이는 문제가 보인다. 이번 GraphRAG 반복에서는 sample fixture로 만든 history와 operational run으로 만든 history를 같은 파일 안에 둘 수는 있되, 비교 기준선은 서로 건드리지 않도록 history namespace를 분리했다. 겉으로 보면 옵션 하나를 추가한 작은 작업인데, 실제로는 앞으로 quality history를 오래 쌓기 위한 청소에 가깝다.조금 허무하게 들릴 수도 있지만, 이런 장부 정리가 retrieval 평가에서는 꽤 중요하다. 모델 점수나 top-1 결..
시리즈: GraphRAG 구축기 #7이전: 6편 | 목록 | 다음: 8편2026년 4월 30일 | 개인 프로젝트 GraphRAGGraphRAG profile_eval의 history 쪽을 다시 만지다 보니, 내가 계속 같은 곳에서 헷갈린다는 걸 알았다. 상태가 WARN인지 HARD-FAIL인지 보는 것까지는 좋은데, 막상 다음에 어디를 열어야 하는지는 여전히 한 번 더 손으로 골라야 했다. 특히 baseline mismatch가 같이 잡히는 날에는 더 그렇다. query set이 달라진 건지, gate 기준이 달라진 건지, 아니면 정말 실패 범위가 새로 넓어진 건지를 한 화면에서 나눠 보고 싶었다.그래서 이번 반복에서는 history report에 scope growth queue를 하나 더 붙였다. 이..
시리즈: GraphRAG 구축기 #6이전: 5편 | 목록 | 다음: 7편2026년 4월 29일 | 프로젝트history-baseline-mismatches.json을 profile별 목록으로만 보니, 다음에 열 때마다 내가 먼저 해야 하는 일이 하나 남았다. 어떤 profile에서 빠졌는지는 보이는데, 왜 빠졌는지를 이유별로 다시 머릿속에서 접어야 했다. query set이 바뀐 건지, quality gate 기준선이 바뀐 건지, 아니면 dataset이나 top-k가 달라진 건지부터 갈라야 하는데, report 구조는 아직 profile 중심이었다.이번 GraphRAG 작업은 그 작은 불편을 줄이는 쪽이었다. retrieval 점수를 올리거나 새 profile을 만든 것은 아니다. 대신 history m..
시리즈: GraphRAG 구축기 #5이전: 4편 | 목록 | 다음: 6편2026년 4월 27일 | 프로젝트history-baseline-mismatches.json 파일 하나를 따로 만들고 나니, GraphRAG 실험 history를 읽는 순서가 조금 더 안전해졌다. 지난번에는 query set이나 quality gate 기준선이 달라진 run을 history delta 계산에서 빼는 guard를 붙였다. 그때도 `history_warning=baseline-mismatch(...)`가 보이기는 했지만, 막상 다음에 다시 열어 보려면 어떤 profile에서 어떤 과거 run이 빠졌는지를 다시 summary 안에서 찾아야 했다. 이번에는 그 빠진 run 자체를 별도 리포트로 모으는 쪽을 먼저 붙였다.나는 ..
2026년 4월 25일 | 개발 일기quality_history.json 하나를 며칠 단위로 붙여 읽기 시작하니, 내가 먼저 고쳐야 했던 건 status가 아니라 baseline이었다. 표면만 보면 PASS, WARN, HARD-FAIL 세 칸이 날짜 순으로 잘 쌓이고 있었는데, 가만히 생각해 보면 그 줄들이 정말 같은 시험지 위에 서 있는지부터 확인해야 했다. query 파일 안의 질문 구성이 달라지거나, quality gate 임계값이 조금만 바뀌어도 숫자는 이어 보이지만 의미는 더 이상 같은 축이 아니다. 그 상태에서 history_transition이나 top1_hitΔ를 읽으면, 정작 내가 보고 싶은 변화보다 시험지 교체 효과를 먼저 읽게 된다.그래서 이번에는 성능을 더 올리는 쪽보다 histo..
시리즈: 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월 21일 | 개발 공부Query Coverage는 검색 결과가 질문 안의 핵심 대상과 조건을 얼마나 빠짐없이 실제로 받쳐 주는지를 보는 관점이다. 쉽게 말해 관련 문서가 어딘가에 하나 들어왔는지만 보는 게 아니라, 지금 앞에 올라온 결과들이 질문의 몇 퍼센트를 완성하고 있는가를 따로 읽는 방식이다. 나는 한동안 검색 품질을 recall이나 top-k hit로만 보는 쪽에 가까웠는데, 최근 GraphRAG 쪽 실험을 만지면서는 이 중간 층을 분리해서 보지 않으면 계속 같은 착시를 겪게 된다는 걸 꽤 또렷하게 느꼈다.특히 엔티티가 두세 개 섞인 질문에서는 이 차이가 더 크게 드러났다. 검색기는 분명 꽤 괜찮은 후보를 가져오는데, 막상 답변은 한 조각이 비어 있는 느낌이 반복됐다. 로그를 열어보..
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`를 같이 남..
2026년 4월 15일 | 프로젝트profile_eval 출력이 길어지기 시작하면, 결국 다시 볼 query를 사람이 눈으로 골라야 하는 순간이 남는다. GraphRAG 쪽은 점수 축이 여러 개라서 이 마지막 한 칸이 은근히 거슬렸다. stable한 query가 대부분인데도, rank shift가 난 몇 개를 다시 손으로 추려야 하면 메모가 먼저 흐려진다.그래서 이번에는 새 scoring profile을 하나 더 늘리기보다, 흔들린 query만 바로 다시 여는 판독면을 먼저 붙였다. 이름은 rank-shift focus report다. trace bundle을 남길 때 custom profile별로 실제로 움직인 query만 따로 모아 주고, 같은 자리에서 trace before / after / dif..
2026년 4월 13일 | 프로젝트profile_eval 출력에서 rank-shift라는 단어가 보이기 시작하면, 그다음에는 거의 반사적으로 trace diff를 열고 싶어진다. 문제는 그 사이가 은근히 길었다는 점이다. query 세트로 profile을 비교하고, 이상한 query를 찾고, 다시 같은 query로 trace를 따로 저장하고, before/after 파일을 맞춰 `trace_diff`를 돌리는 흐름이 계속 수동이었다. 며칠 동안은 이 정도도 괜찮다고 생각했는데, tuning 실험이 두세 번만 쌓여도 메모가 먼저 흐려졌다. 어떤 query가 흔들렸는지는 남는데, 그 흔들림을 바로 다시 펼쳐 보는 경로가 끊겨 있었다.나는 이런 마지막 한 칸이 은근히 중요하다고 본다. GraphRAG 쪽은 지..
2026년 4월 6일 | 개발 일지오늘은 GraphRAG 트랙의 최근 git log를 다시 훑어보면서 작업 순서를 정리했다. 바로 직전 커밋들은 relation-weighted graph scoring, configurable scoring profile 쪽에 몰려 있었다. 그러니까 지금 프로젝트는 "그래프 점수 체계를 어떻게 바꿀 것인가"보다도, 이미 바꿀 수 있게 만든 체계를 어떻게 덜 번거롭게 비교할 것인가가 다음 병목이었다. 실제로 지난 단계에서 scoring profile을 JSON으로 분리해 놓고도 비교 과정은 꽤 수동적이었다. query 하나를 던지고 결과를 보고, config를 바꾸고 다시 던진 뒤, top-1 제목과 edge score를 눈으로 대조해야 했다. query가 두세 개만 넘어..