처음에는 문서를 많이 넣어두기만 한 상태였다. 지금은 질문을 하면 관련 법령ㆍ예규ㆍ해설 문서를 찾아내고, 그 근거가 믿을 만한지 점검한 다음, 필요한 조문만 짧게 꺼내고, 답변 끝에 "이 근거가 어떤 자격으로 쓰였는지"까지 표시할 수 있는 상태가 됐다.
전체 그림
처음 상태
문서가 많음
|
v
어디에 뭐가 있는지 찾기 어려움
|
v
AI가 답하더라도 근거를 확인하기 어려움
현재 상태
문서 원문
|
v
작은 조각으로 나눔
|
v
검색용 색인에 넣음
|
v
여러 검색 방식으로 후보를 찾음
|
v
공식 근거인지 점검함
|
v
짧은 근거와 함께 답변함이 위키가 해결하려는 문제
지방계약 문서는 길고 복잡하다. 법령, 시행령, 시행규칙, 예규, CSR 유권해석, 블로그, 직접 작성한 해설이 섞여 있다.
사람이 볼 때 어려운 점은 세 가지다.
어디에 답이 있는지 찾기 어렵다.
찾은 문서가 공식 근거인지 참고자료인지 구분하기 어렵다.
문서 전체가 너무 길어서 실제로 필요한 한 문장을 찾기 어렵다.
이 위키는 이 세 가지를 줄이기 위해 만들어졌다.
질문: 임대차계약은 수의계약이 가능할까?
예전 방식
시행령 제25조 전체를 열어봄
긴 조문 안에서 제1항, 제5호, 사목을 사람이 찾아야 함
개선 후
바로 제25조 제1항 제5호 사목 조각을 찾음
필요한 한 문장만 답변 근거로 보여줌어려운 용어 쉽게 번역하기
어려운 말
쉬운 말
실제 의미
RAG
자료 찾아서 답하기
AI가 자기 머리로만 답하지 않고, 저장된 문서를 먼저 찾아서 답하는 방식
chunk
문서 조각
긴 문서를 검색하기 좋게 나눈 작은 단위
micro chunk
아주 작은 문서 조각
조문을 항ㆍ호ㆍ목 단위까지 더 잘게 나눈 것
embedding
의미 좌표 만들기
문장의 의미가 비슷한지 비교할 수 있게 숫자로 바꾸는 것
vector search
의미 검색
단어가 똑같지 않아도 뜻이 비슷한 문서를 찾는 검색
FTS/BM25
정확한 글자 검색
조문번호, 문구, 제목처럼 정확히 들어간 단어를 찾는 검색
MongoDB RAG
문서조각 저장소 검색
많은 chunk를 저장하고 의미 검색하는 기본 검색 창고
OpenViking hybrid
여러 검색법을 섞은 검색
의미 검색, 정확 검색, 우선순위 규칙을 합쳐 더 좋은 근거를 고르는 방식
qmd
Markdown 문서 탐색기
Obsidian 문서 위치를 찾는 데 좋은 보조 검색
evidence quality
근거 품질 검사
찾은 문서가 답변 근거로 써도 되는지 점검하는 과정
성능 지표 쉽게 보기
숫자
쉬운 뜻
예시
hit@1 1.0000
첫 번째 결과가 정답이라는 뜻
시험 질문을 물었을 때 기대한 근거가 바로 1등으로 나옴
hit@5 1.0000
상위 5개 안에는 정답이 있다는 뜻
첫 번째가 아니어도 5개 안에는 들어옴
MRR 1.0000
정답이 거의 항상 앞에 있다는 뜻
1.0에 가까울수록 좋음
answer-eligible@1
첫 번째 결과가 답변에 써도 되는 근거라는 뜻
공식자료나 잘 정리된 위키 문서인지 확인
low_trust_top 0
첫 번째 결과에 낮은 신뢰도 문서가 없다는 뜻
개인 메모나 임시 보고서가 1등으로 올라오지 않음
전체 발전 과정 한눈에 보기
[0] 문서 구조 점검
|
v
[1] MongoDB RAG 저장소 구축
|
v
[2] L0/L1 요약 지도 추가
|
v
[3] OpenViking식 구조 실험
|
v
[4] OpenViking 실제 실행 실험
|
v
[5] Hybrid 검색 우선순위 개선
|
v
[6] FTS/BM25 정확 검색 추가
|
v
[7] 근거 품질 평가 추가
|
v
[8] 법제처 공식 법령 원문 추가
|
v
[9] 조문 단위로 자르기
|
v
[10] 항ㆍ호ㆍ목 단위로 더 잘게 자르기
|
v
[11] 답변 끝에 공식 근거 성적표 붙이기
|
v
[12] 근거 자격표를 더 세밀하게 나누기단계별 쉬운 해설
0단계: 문서가 망가지지 않았는지 확인
처음에는 검색 성능보다 기본 정리가 중요했다. 문서 링크가 깨지지 않았는지, 출처 번호가 맞는지, 파일 구조가 맞는지 확인했다.
검증 결과
lint PASS
errors 0
warnings 0쉬운 의미:
문서함 정리 상태: 정상
깨진 링크: 없음
출처 목록: 정상1단계: 문서를 검색 창고에 넣기
긴 Markdown 문서를 작은 조각으로 나누고 MongoDB라는 저장소에 넣었다.
긴 문서
|
v
작은 조각들
|
v
MongoDB 저장소
|
v
질문하면 비슷한 조각 검색주요 결과:
최초 전체 ingest: 14803/14803 chunks complete쉬운 의미:
문서 조각 14,803개를 검색 창고에 모두 넣었다.2단계: 문서 지도를 만들기
문서 조각만 많으면 검색이 느리고, 엉뚱한 조각이 나올 수 있다. 그래서 각 문서에 짧은 요약 지도인 L0/L1을 만들었다.
L0 = 아주 짧은 요약
L1 = 조금 더 긴 개요
L2 = 실제 원문그림으로 보면:
질문
|
v
먼저 L0/L1 지도에서 관련 문서 후보를 찾음
|
v
필요할 때만 L2 원문 조각을 봄초기 평가:
24문항 평가
MongoDB baseline hit@5 0.9583
MongoDB context hit@5 0.9583
MongoDB strict hit@5 0.9167개선 후:
MongoDB baseline hit@5 1.0000
MongoDB context hit@5 1.0000쉬운 의미:
처음에는 24문제 중 23문제 정도를 상위 5개 안에서 찾았다.
개선 후에는 24문제 모두 상위 5개 안에서 찾았다.3단계: OpenViking식 구조로 바꿔볼 준비
OpenViking은 자료, 기억, 기술을 파일 시스템처럼 정리하는 방식이다. 이 단계에서는 실제 OpenViking을 완전히 쓰기 전에, 우리 위키 자료를 OpenViking이 읽을 수 있는 모양으로 정리했다.
LLM Wiki 문서
|
v
OpenViking식 resource / skill / session 구조
|
v
나중에 OpenViking으로 옮기거나 비교 가능검증 결과:
coverage 1.0000
lexical-hybrid hit@5 1.0000쉬운 의미:
OpenViking식으로 내보낸 자료 안에 필요한 정답 문서가 빠짐없이 들어 있었다.4단계: OpenViking을 실제로 돌려본 실험
OpenAI API Key 없이, 로컬 embedding만으로 OpenViking runtime을 시험했다.
결과:
hit@1 0.5000
hit@5 0.6250
MRR 0.5778쉬운 의미:
실제 OpenViking runtime만으로는 아직 성능이 충분하지 않았다.
첫 번째 결과가 정답인 경우가 절반 정도였다.그래서 결론은 이랬다.
OpenViking runtime 단독 사용: 아직 이르다
MongoDB RAG: 기본 검색으로 유지
OpenViking: 구조 실험과 보조 검색으로 활용5단계: 여러 검색 결과를 섞어 더 좋은 결과 고르기
이 단계에서 OpenViking hybrid가 중요해졌다. 단순히 한 검색엔진만 믿지 않고 여러 후보를 섞은 뒤, 공식 근거와 좋은 concept 문서를 위로 올렸다.
MongoDB 검색 결과
+
OpenViking식 L0/L1 결과
+
정확 문구 검색
+
우선순위 규칙
|
v
OpenViking hybrid 결과27문항 평가:
OpenViking hybrid hit@1 1.0000
OpenViking hybrid hit@5 1.0000
MRR 1.0000쉬운 의미:
27개 시험 질문에서 첫 번째 결과가 모두 기대한 근거였다.다만 이때 중요한 깨달음이 있었다.
검색 점수만 높다고 좋은 답변 근거는 아니다.
CSR 사례나 블로그가 1등으로 올라오면 답변에는 조심해서 써야 한다.6단계: 정확한 글자 검색 FTS/BM25 추가
의미 검색은 비슷한 뜻을 찾는 데 좋지만, 조문번호나 정확한 문구는 글자 그대로 찾는 검색이 더 강하다.