Summary
블로그는 내가 직접 정제한 지식이 담긴 현실적인 비정형 데이터라 실험 대상으로 최적이다. 블로그에 들어오는 쿼리 유형이 다양해서 단일 검색 방식으로는 커버가 안 된다. 검색 모듈을 독립적으로 구현하고 조합할 수 있는 구조를 먼저 만들고, LangSmith로 전 과정을 추적하면서 체계적으로 평가하는 게 목표다.
왜 블로그인가
RAG를 공부하면서 항상 아쉬웠던 점이 있었다. 튜토리얼은 대부분 Wikipedia 덤프나 PDF 몇 개를 예제로 쓴다. 구현 방법은 배울 수 있지만, 실제로 이게 얼마나 잘 동작하는지 체감하기 어렵다. 모르는 데이터니까.
내 블로그는 다르다.
- 내가 직접 쓴 글이라 내용을 안다. 질문을 만들고 답을 직접 평가할 수 있다.
- 실제 비정형 데이터다. 길이도 다르고, 주제도 다르고, 구조도 제각각이다.
- wikilink로 연결된 그래프 구조가 있다. 단순 벡터 검색 너머의 실험이 가능하다.
- 잘 되면 진짜로 쓸 수 있다. "내가 RAG에 대해 쓴 글들 요약해줘"가 동작하는 것 자체가 성과다.
왜 검색 모듈을 교체 가능하게 만드는가
블로그에 들어오는 쿼리는 성격이 다양하다.
- "RAG가 뭐야?" → 의미 기반 검색이 맞다
- "LangGraph 태그 달린 글 목록" → 메타데이터 필터가 맞다
- "nuartz 프로젝트 전체 내용" → 파일 직접 접근이 맞다
- "Nuartz랑 연결된 개념들" → 그래프 탐색이 맞다
- "context engineering" → 키워드 검색이 맞다 (한국어로 쓴 글이 없을 수 있으니)
단일 검색 전략으로는 이 모든 케이스를 커버하기 어렵다. 그렇다고 처음부터 모든 전략을 한 파이프라인에 우겨넣으면 뭐가 잘 되고 뭐가 안 되는지 파악하기 힘들다.
그래서 방향을 이렇게 잡았다:
- 각 검색 전략을 독립적인 모듈로 구현한다
- 파이프라인에서 모듈을 조합할 수 있게 만든다
- 같은 질문으로 다른 조합을 테스트하고 비교한다
레포 재편 맥락
이 프로젝트의 위치와 레포 구조는 Nuartz — Headless 설계와 레포 생태계 재편에서 다뤘다.
블로그 데이터의 특성
실험 전에 데이터를 먼저 이해해야 한다.
| 특성 | 내용 |
|---|---|
| 포맷 | Obsidian 마크다운 (wikilink, callout, 코드 블록 포함) |
| 언어 | 한국어 + 영어 혼용 |
| 카테고리 | AI, Dev, Projects, Study, Tools, Events, Others |
| 구조 | 단순 파일 + 폴더, wikilink로 연결된 그래프 |
| 길이 | 짧은 메모부터 긴 기술 문서까지 다양 |
한국어 혼용은 특히 중요한 변수다. 시맨틱 검색의 임베딩 품질, 키워드 검색의 토크나이징, 쿼리 언어 불일치 모두 영향을 받는다. Nuartz에서 한국어 검색을 위해 CJK-aware 토크나이저를 따로 구현했던 것처럼, 여기서도 신경 써야 할 부분이다. → Nuartz — 한국어 검색 구현
답하고 싶은 질문들
조합 효과
- Semantic + Keyword Hybrid가 각각 단독보다 항상 나은가?
- 메타데이터 사전 필터링이 시맨틱 검색 품질을 높이는가?
- 그래프 탐색을 추가하면 연관 노트 발견에 실질적인 차이가 있는가?
모듈별 특성
- 키워드 검색은 어떤 쿼리 유형에서 시맨틱 검색을 이기는가?
- 파일 직접 접근은 언제 쓰는 게 맞는가?
평가
- 어떤 방식으로 조합 간 품질을 정량 비교할 수 있는가?