시리즈: 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월 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가 두세 개만 넘어..
2026년 4월 6일 | 개발 공부Reranker는 1차 검색기가 넓게 모아 온 후보 문서들을 다시 읽고 더 그럴듯한 순서로 재정렬하는 모델 또는 단계다. 보통 RAG나 문서 검색에서 retriever 뒤에 붙는데, 나는 한동안 이걸 그냥 마지막 점수 보정 장치 정도로 생각했다. 그런데 실제 검색 흐름을 자꾸 보다 보니 느낌이 달라졌다. 지금은 reranker를 이미 찾은 후보의 순서를 다듬는 옵션보다, 1차 검색이 만든 거친 순서를 다시 사람 눈에 가까운 우선순위로 복구하는 단계에 더 가깝게 본다.이렇게 보게 된 이유는 retrieval 품질을 볼 때 top-k 안에 정답이 들어왔는지와, 그 정답이 몇 번째로 올라오는지가 전혀 다른 문제라는 걸 자주 느꼈기 때문이다. 벡터 검색이나 BM25가 후보를 잘..
2026년 4월 5일 | 프로젝트GraphRAG 쪽에서 손본 건 겉으로 보면 작은 점수 조정처럼 보이는데, 내가 느끼기에는 MVP가 다음 단계로 넘어가기 위한 기준선을 하나 더 세운 작업에 가까웠다. 최근 며칠 동안은 trace snapshot, query coverage, trace diff처럼 결과를 읽는 도구를 차례대로 붙여 왔다. 그 흐름 다음에 자연스럽게 남은 질문은 하나였다. 지금의 graph score는 실제로 무엇을 보상하고 있는가였다.이전 버전도 아예 나쁘진 않았다. 엔티티가 직접 맞았는지, 그래프 이웃을 통해 간접적으로 닿는지, coverage가 어느 정도인지는 볼 수 있었다. 그런데 막상 랭킹이 바뀌는 이유를 설명하려고 하면 graph score 안이 너무 평평했다. direct hi..
2026년 4월 4일 | 개발 일기최근 GraphRAG 쪽 git log 흐름을 따라가다 보니 다음 단계로 랭킹 이동을 비교하는 diff 도구가 자연스럽게 필요해졌다. 며칠 사이 로그 흐름은 꽤 분명했다. explainable retrieval trace를 넣고, 그다음에 trace snapshot export를 만들고, coverage-aware reranking까지 올라왔다. 여기까지 오고 나니 자연스럽게 다음 질문이 생겼다. 그래서 이번에 붙인 건 성능을 더 올리는 거대한 기능이 아니라, 랭킹이 실제로 어떻게 바뀌었는지를 비교하는 작은 diff 도구였다.이 프로젝트를 만질 때 나는 점점 비슷한 패턴을 보게 된다. 검색 품질을 올리려고 새 점수를 하나 넣으면, 그 직후에는 "그래서 뭐가 위로 올라왔지..
영문 제목: BidirLM: From Text to Omnimodal Bidirectional Encoders by Adapting and Composing Causal LLMs저자/소속: Nicolas Boizard, Théo Deschamps-Berger, Hippolyte Gisserot-Boukhlef, Céline Hudelot, Pierre Colombo | Diabolocom; Artefact Research Center; MICS, CentraleSupélec, Université Paris-Saclay; Cohere | arXiv:2604.02045 | 2026년 4월논문 링크: https://arxiv.org/abs/2604.020451. 서론: 생성형 모델 자산을 표현 학습으로 되돌리..
2026년 4월 3일 | 개발 일기GraphRAG MVP를 사람 눈에 맞게 읽히도록 다듬는 작업이 이번 단계의 중심이었다. 지금까지는 hybrid retrieval 결과를 보면 vector score와 graph score가 같이 나오고, supporting edge랑 reasoning path도 같이 확인할 수 있었다. 여기까지만 해도 왜 이 청크가 올라왔는지는 꽤 설명이 됐는데, 막상 긴 질문이나 엔티티가 여러 개인 질문을 던지면 하나가 계속 남았다. 이 결과가 질문 전체를 어느 정도 받쳐주고 있는지가 바로 안 보인다는 점이었다.예를 들어 Customer Dashboard, Payment API, Root Cause Note를 한 번에 묻는 질문을 던졌을 때, 어떤 결과는 Payment API와 Ro..
To Memorize or to Retrieve: Scaling Laws for RAG-Considerate Pretraininghttps://arxiv.org/abs/2604.00715Karan Singh et al. | Stanford University, Independent, Patronus AI, The Ohio State University, Carnegie Mellon University, DegenAI Labs | arXiv:2604.00715 | 2026년 4월 1일1. 서론: 지식을 외우는 모델과 찾아보는 모델 사이의 설계 선택대규모 언어 모델의 성능 향상 전략은 오랫동안 더 큰 파라미터 수, 더 많은 사전학습 토큰, 더 긴 학습 시간으로 요약되어 왔다. 그러나 실제 서비스 환경에서는 ..
2026년 4월 3일 | 개발 공부HNSW는 Hierarchical Navigable Small World의 약자로, 고차원 벡터들 사이에 다층 그래프를 만들어 근사 최근접 탐색을 빠르게 수행하는 인덱스 구조다. 쉽게 말하면 모든 벡터를 처음부터 끝까지 훑는 대신, 상층에서는 멀리 점프하고 하층에서는 더 촘촘하게 주변을 살피면서 가까운 후보를 좁혀 가는 방식이다. 벡터 DB에서 자주 보이는 이유도 결국 이 구조가 recall과 latency의 균형을 현실적으로 잘 잡아주기 때문이다. 그래서 이 글도 HNSW를 단순한 벡터 DB 옵션이 아니라, 그래프 위를 이동하며 이웃을 찾는 탐색 전략으로 이해하려는 관점에서 정리했다.벡터 검색을 처음 접했을 때 나는 한동안 이걸 거의 마법처럼 받아들였다. 임베딩만 잘 ..
Ken M. Nakanishi | arXiv:2604.01178v1 | 원제: Screening Is Enough | 발행 시점: 2026년 4월논문 초록 링크 · arXiv HTML · PDFScreening Is Enough는 장문맥 언어모델에서 핵심 병목을 계산량 자체보다 무관한 key를 얼마나 정확하게 배제하느냐의 문제로 다시 정의한다. 저자는 표준 softmax attention이 모든 비마스킹 key를 하나의 분모 안에서 경쟁시키기 때문에, 어떤 key가 절대적으로 부적절한 경우에도 완전히 배제하기 어렵다고 본다. 이를 대체하기 위해 제안된 screening 메커니즘은 query-key 유사도를 bounded similarity로 계산한 뒤, 각 key가 절대적 기준선을 넘는지 독립적으로 판정..
2026년 4월 2일 | 개발 일기GraphRAG 검색 결과를 더 읽을 수 있게 만드는 쪽이 이번 작업의 중심이었다. 지금까지는 hybrid retrieval이 돌아가면 final score, vector score, graph score 정도만 숫자로 확인할 수 있었다. 겉으로 보면 그럴듯한데, 막상 어떤 청크가 왜 위로 올라왔는지 바로 설명하려고 하면 손이 멈췄다. 벡터 점수가 먹힌 건지, 질의 엔티티와 직접 겹친 건지, 아니면 그래프 이웃 때문에 추가 점수를 받은 건지 분해가 잘 안 됐다. 이 상태로 다음 단계 실험을 계속 밀면, 나중에는 결과를 보고도 어디를 손봐야 하는지 애매해질 것 같았다.그래서 이번에는 retrieval 결과 자체에 설명 흔적을 남기는 쪽으로 방향을 틀었다. 최근 로컬 git..