MongoDB Vector Search를 활용한 사내 문서 검색 도우미 구현 및 성능 검증(PoC)_(2)구현 및 검증과정

이전 글: (1) 배경과 아이디어

https://letsstudylog.tistory.com/159

MongoDB Vector Search를 활용한 사내 문서 검색 도우미 구현 및 성능 검증(PoC)_배경과 아이디어

 

---

구현 과정 어려운 점

전처리 구조 잡는 것 자체가 어려웠다.

문서 데이터 depth 자체가 깊고 복잡하며 필요한 데이터를 선별하는 게 쉽지 않았다.

 

해결방법

1. 데이터 정제 기준

질문에 답을 하려면 필요한 데이터가 무엇일지,

질의응답에는 불필요하지만 데이터 관리 차원에서 필요한 데이터는 무엇일지 등을고려해

데이터를 정제해보면서 방향성을 터득해 이를 5가지(표, 맥락, 메타, 목차, 벡터 임베딩용)로 분할 생성하고

결과적으로 하나의 JSONL 파일로 통합했다.

1. 표 데이터(Tables, csv/str)
2. 맥락 데이터(Context Data, llm response, json/json)
3. 메타 데이터(Meta Data, json/json)
4. 목차 데이터(ToC, str/str)
5. 벡터 임베딩용 데이터(Vector Content, str/str)

 

표

문서들을 보니 포맷은 상이해도 주로 표로 내용을 정리하는 것을 확인했다.

환각 없이 문서 기반 정확한 정보를 제공하기 위해서는 표 데이터는 꼭 살리고자 했고,

표에 대한 인덱스와 맥락 정보 1줄을 추가한 CSV로 만들어 추후 모델이 데이터를 찾기 쉽도록 했다.

맥락 데이터

핵심 데이터는 표(Tables)지만, 전체 맥락이 있어야 해당 데이터를 잘 찾을 것으로 판단했으나 하나의 문서당 입력 토큰이 8000 ~ 12000 수준이어서  그대로 쓸 수는 없었고, 문서 전체에 대한 요약 데이터를 만들었다.

메타 데이터

ChatBot 기능으로는 불필요하나, 파일을 관리할 때 필요한 소량의 데이터(작성자, 작성일, 수정일 등)를 남겨두었다.

목차 데이터

표 및 맥락 데이터에서 모델이 데이터를 찾기 쉽도록 처리했지만

전체 길잡이를 위해 목차 데이터를 한줄로 만들어 추가해주었다.

벡터 임베딩용 데이터

Vector Search를 위해서는 모델을 이용해 정제한 데이터를 바탕으로 임베딩 데이터를 만들어야 했다.

텍스트 임베딩 모델을 이용해 정제한 데이터를 바탕으로 해당 데이터를 생성했다.

 

2. 모델을 활용한 데이터 전처리

데이터별 활용 모델

• 맥락 데이터: OpenAI GPT-4o-mini
• 임베딩 데이터: OpenAI text-embedding-3-small
• 검증 프롬프트: OpenAI GPT-4o-mini

모델 선정 이유

• 회사에서 제공하는 OpenAI API 사용
• 문서 요약 및 임베딩용으로 쓰기에 가장 저렴한 모델

즉, 경제적 이유.

1.  

문서당 처리시간 상세

 

문서 당 처리 시간을 단계별로 확인했다.

모든 Confluence 문서를 처리하면 차이가 발생하겠지만,

팀원이 다양성 기반으로 선별해준 샘플 데이터 기준으로 정제하면 소요 시간은 다음과 같다.

	단계 (Phase)	세부 작업 내용	소요 시간	비고
1	Extraction	Confluence API 호출 및 HTML 수집	0.2s ~ 0.5s	네트워크 속도 의존
2	Parsing	HTML -> ToC, Metadata, CSV 변환	0.1s ~ 0.3s	로컬 CPU 연산 (매우 빠름)
3	Summarization	LLM(GPT-4o-mini) 기반 요약/정제	1.5s ~ 3.0s	가장 긴 소요 시간 (LLM 추론)
4	Embedding	text-embedding-3-small 벡터 생성	0.3s ~ 0.8s	API 호출 1회
5	Load/Index	MongoDB 적재 및 인덱싱 동기화	0.2s ~ 0.4s	DB I/O
	합계 (Total)	전체 데이터 파이프라인	약 2.3s ~ 5.0s	평균 3.5초 내외

 

 

검증 환경 및 시나리오

1.검증 환경

• Data: Atlassian Confluence
• Stack: NoSQL & Vector Search (MongoDB Atlas)
• Model: text-embedding-3-small (Embedding), gpt-4o-mini (Generation)

2. 검증 시나리오

(1) 검색 정밀도 검증 (Retrieval Precision)

: 단순 검색 엔진을 넘어, 벡터 유사도 검색이 질문의 의도를 얼마나 잘 파악하여 관련 문서를 상위로 올리는지 검증.

• 테스트 내용: 고유 명사(업체명, 프로젝트명)와 시맨틱 키워드(일정, 비용, 리스크)가 섞인 질문을 던졌을 때, 정답 문서가 Top-k(1~3위) 내에 위치하는지 확인.
• 성공 기준: 질문과 가장 밀접한 문서의 vectorSearchScore가 0.8 이상이며, 검색 결과 상위 3개 이내에 위치함.

(2) 표 데이터 해석 및 수치 정확도 검증 (Table Extraction & Accuracy)

: 가장 난도가 높은 '비구조화된 표(Table) 데이터'를 LLM이 정확히 읽고 수치 답변을 내놓는지 검증.

• 테스트 내용: 복잡한 비용 정산표나 인력 투입 현황표가 포함된 질문(예: "총 매입 금액은 얼마인가요?")을 투입.
• 성공 기준: 검색된 tables 필드의 CSV/Markdown 텍스트를 LLM이 누락이나 오독 없이 원문 그대로 인용하여 답변함. (할루시네이션 유무 확인)

(3) 맥락 기반 답변 충실도 검증 (Context Faithfulness)

: 검색된 컨텍스트(필드명: llm_content)가 실제 답변 생성에 얼마나 충실하게 반영되는지 검증.

• 테스트 내용: 문서 내 '특이사항'이나 'Lesson Learned' 등 서술형 데이터를 기반으로 한 추론 질문 투입.
• 성공 기준: 답변이 검색된 문서의 내용에만 근거하고 있으며, 문서에 없는 내용을 임의로 지어내지 않음.

3. 검증 프롬프트 요소

1. 필수 패턴

• 패턴 A (고객사명 중심): "[고객사명]의 계약서에서 ~~~"
• 패턴 B (프로젝트명 중심): "[프로젝트명] 프로젝트의 ~~~"

2. 환각 방지용 문구

 

다음 문서에 계속...