LLM Wiki를 수치로 검증하기: 회귀 측정과 지식 그래프 실험
2주 전까지 위키 검색 평가셋의 Recall@5는 0.96이었습니다. 문서 540개에서 636개로 18% 늘어난 뒤 같은 평가셋을 돌리니 0.88이 나왔습니다. 노트는 쌓았는데 검색은 나빠진 것입니다. 어디서부터 무너졌고, 무엇을 기준으로 복구할지를 수치로 따라가 봅니다.
1. 컴파일된 위키와 검색의 역행
LLM 위키 패턴의 전제는 지식을 질의 시점마다 다시 유추하지 않고, 섭취 시점에 한 번 정리해 계속 갱신하는 것입니다. 흩어진 원문에서 관련 문서를 다시 찾아내는 RAG와 달리, 교차 참조와 모순 표시가 이미 문서 사이에 박혀 있습니다. 그래서 위키의 가치는 문서 수가 아니라 문서 간 연결과 검색 경로가 얼마나 살아 있는가로 측정해야 합니다.
2주간의 운영 기록이 이 전제를 시험했습니다. 일일 브리핑 아카이브가 지속적으로 추가되며 문서 수는 540개에서 636개로 18% 늘었고, 같은 기간 자주 묻는 질문 50개로 구성된 회귀 평가셋을 돌린 결과는 역행했습니다.
| 지표 | 2주 전 | 측정 시점 |
|---|---|---|
| 문서 수 | 540 | 636 |
| Recall@5 | 0.96 | 0.88 |
| MRR@5 | 0.804 | 0.641 |
| 색인에서 도달 불가능한 문서 | 20 | 59 |
Recall@5는 상위 5개 결과에 정답 문서가 하나라도 들어가는 비율이고, MRR@5는 정답의 순위를 역수로 환산한 값이라 순서까지 벌점을 봅니다. 0.96에서 0.88로 떨어졌다는 것은 50개 질문 중 네 개에서 정답이 상위 5개 밖으로 밀려났다는 뜻입니다. 성장이 곧 품질이라는 가정이 수치로 깨진 순간이었습니다.
원인을 분류하니 두 가지였습니다. 첫째, 신규 문서 96개 중 59개가 색인에서 도달 불가능한 상태로 남아 있었습니다. 허브 문서에 연결되지 않은 문서는 검색의 후보 풀에조차 안정적으로 들어가지 못합니다. 둘째, 같은 주제의 문서가 늘며 유사 문서들이 정답을 밀어내는 순위 교란이 발생했습니다. 브리핑 아카이브가 하루에 두 문서씩 쌓이는 구조라 이런 경쟁이 구조적으로 커집니다.
이 측정이 가능했던 이유는 평가셋이 먼저 있었기 때문입니다. 실제로 자주 묻는 질문 50개에 정답 문서를 매핑해둔 JSON 파일 하나가 없었다면 이 역행은 체감으로만 존재하고 수치로는 보이지 않았을 것입니다.
2. 검색 품질을 수치로 만드는 최소 구성
위키 검색을 측정 가능하게 만드는 구성은 생각보다 작습니다. 세 가지면 충분합니다.
평가셋: 실제 질문과 정답 문서의 쌍을 50개 만듭니다. 위네트워크 설정, 특정 주택 청약 후보, 리플레이 분석 결론처럼 실제로 궁금했던 것들을 그대로 씁니다. 만들어낸 질문은 실제 분포를 대표하지 못합니다.
재현 가능한 검색기: 파일 제목, 태그, 본문을 색인하는 BM25 구현체 하나면 됩니다. 그래프 가중치를 소량 섞는 정도의 조정만 둡니다. 핵심은 같은 입력에 같은 출력을 내는 결정론적 파이프라인이라 회귀 비교가 가능한 것입니다.
게이트: 문서를 대량으로 추가하거나 구조를 바꾸는 작업 뒤에는 평가셋을 돌립니다. Recall이 떨어지면 그 변경은 위키의 검색 가능성을 해친 변경이므로, 구조를 고치거나 되돌립니다.
BM25가 임베딩 검색보다 먼저라는 점도 데이터로 확인했습니다. 수백 문서 규모에서는 표제어만 잘 맞으면 BM25가 정확하고, 임베딩은 동의어 확장에 강하지만 인프라와 재색인 비용이 상시 발생합니다. 커뮤니티의 관찰도 같은 방향이었습니다. 대부분의 팀은 측정 없이 벡터로 건너뛴다는 것은 자주 반복되는 실패 패턴입니다.
3. 지식 그래프 도입 실험
검색 품질의 역행을 관측한 시점에, 코드베이스와 문서를 지식 그래프로 변환하는 도구를 같은 위키에 시험했습니다. 10만 스타 규모로 성장한 오픈소스로, tree-sitter로 코드를 결정론적으로 파싱하고 문서는 LLM으로 개체와 관계를 추출합니다. 임베딩이나 벡터 저장소 없이 그래프 순회로 질의한다는 점이 특징입니다.
마크다운 위키에 적용한 결과는 다음과 같습니다.
1
2
988 nodes / 2,338 edges / 50 communities
입력 913,479 토큰 / 출력 626,108 토큰 (약 80분)
모든 마크다운 링크와 위키링크는 references 엣지로 변환되었고, 본문에 언급만 되는 개념들도 개별 노드로 승격되었습니다. 각 엣지에는 근원이 문서에 명시된 것인지 추론된 것인지 태그가 붙어 근거 추적이 가능합니다. 50개 커뮤니티 감지 결과는 브리핑, 주거, 리플레이 분석, 데브옵스 같은 실제 주제 클러스터와 일치했습니다.
같은 평가셋으로 비교한 숫자는 명확했습니다.
| 시스템 | Recall@5 |
|---|---|
| BM25 (기존) | 0.86 |
| 그래프 순회 질의 | 0.70 |
그래프가 밀렸습니다. miss 패턴을 열어보니 원인이 구조적이었습니다. 넓은 의미의 질문에서 순회 시작 노드가 고빈도 허브에 착지하고, 그 허브가 속한 커뮤니티 전체로 확산되면서 정답 문서보다 관련성 낮은 이웃이 회수됐습니다. Cilium 네트워크 정책을 묻는 질문이 Cilium을 언급한 일일 브리핑 노드들로 답을 채우는 식입니다. 또한 651개 문서 중 37개는 LLM 섭취 단계에서 노드로 승격되지 못해 그래프에 존재하지도 않았습니다.
반대로 그래프가 확실히 이기는 질문 유형도 있었습니다. 두 개념 사이의 연결 경로를 묻는 질의입니다. 최단 경로 탐색으로 두 개념을 잇는 엣지 사슬을 보여주는 것은 키워드 검색이 구조적으로 못하는 일입니다.
4. 측정이 도구 선택을 바꾼다
실험 전에는 그래프가 검색 품질 역행의 해법이 될 수 있다고 기대했습니다. 측정 뒤의 결론은 달랐습니다. 두 시스템은 경쟁 관계가 아니라 용도가 달랐습니다.
상시 검색은 BM25를 유지합니다. recall이 높고, LLM 비용이 0이며, 결정론적이라 회귀 추적이 됩니다. 문서가 늘어도 재색인 비용이 없습니다.
그래프는 구조 감사와 경로 탐색에 씁니다. 커뮤니티 감지로 위키의 실제 주제 클러스터를 확인하고, 가장 연결이 많은 허브 노드 목록으로 특정 주제가 그래프를 왜곡하는지를 봅니다. 두 개념의 연결을 확인할 때만 순회 질의를 씁니다. 재빌드는 위키 구조가 크게 바뀔 때에만 하고, 일일 재색인은 비용 대비 이득이 없어 운영하지 않습니다.
이 결정의 요점은 어느 쪽이 우월한가가 아니라, 측정 없이는 이런 용도 분리 자체를 몰랐다는 것입니다. 그래프의 벤치마크 수치만 보고 상시 검색을 갈아탔다면 recall이 16점 떨어지는 회귀를 스스로 만들었을 것입니다.
5. 위키 운영에 남긴 것들
이번 측정과 실험으로 위키 운영에 다음이 반영됐습니다.
첫째, 회귀 평가셋을 게이트로 못 박았습니다. 대량 섭취 작업 뒤에는 반드시 50개 질문을 돌려 이전 스코어와 비교합니다.
둘째, 신규 문서의 색인 연결을 규칙으로 만들었습니다. 문서를 만들면 그 주제의 허브 문서에 링크를 추가하고, 90일 접근이 없는 문서는 아카이브 후보로 표시합니다. 상위 색인은 항목당 한 줄을 유지하며 상한을 두는 것이 업계 표준 관행과도 일치했습니다.
셋째, 문서 단위가 아니라 주장 단위의 신뢰도 표시를 도입했습니다. 여러 출처가 뒷받침하는 주장과 단일 출처의 주장을 frontmatter로 구분하고, 모순이 발견되면 병합 대신 양쪽을 남기고 표시합니다. 합의 요약으로 다듬어지면 개인 위키의 관점이 사라지는데, 그것은 위키가 백과사전과 다른 이유이기도 합니다.
지식 시스템의 성숙은 새 도구 추가가 아니라 측정 가능한 상태로 만드는 데서 시작합니다. 문서 수가 늘어나도 검색 품질이 유지되는구나를 확인할 수 있는 순간, 위키는 비로소 신뢰할 수 있는 기억 계층이 됩니다.
6. Reference
궁금하신 점이나 추가해야 할 부분은 댓글이나 아래의 링크를 통해 문의해주세요.
Written with KKamJi