사내 RAG 검색

맡은 일

에이전시는 같은 고객사 일을 몇 년씩 이어 받는데, 「이 기능을 왜 이렇게 만들었는지」는 업무 댓글·메일·메신저에 흩어져 있다가 담당자가 바뀌면 사라집니다. 이 질문에 근거 문서 링크와 함께 답하는 사내 검색을 기획부터 구현·운영까지 혼자 맡았습니다. 시범 데이터는 제가 가장 오래 맡은 네오팜 기록입니다.

주요 기능

• 수집부터 답변까지 — 두레이 업무·댓글·메일 수집과 정규화, 청킹·임베딩, 검색과 재정렬(리랭커), 근거 링크를 붙인 답변 생성, 웹 화면. FastAPI와 Docker로 운영합니다.
• 평가셋 게이트 — 코드보다 평가셋을 먼저 만들었습니다. 실제 질문과 정답 문서를 묶은 문항(공개분 62개)을 두고, 변경할 때마다 품질 게이트 4개를 통과해야 반영합니다.
• 사내 공통 LLM 서버로 이전 — 인프라 담당과 함께 개인 장비에서 돌던 모델을 옮겼고, 모델 후보는 같은 평가셋으로 비교해 정했습니다.
• 기록 범위 — 질문·답변 과정은 추적 도구에 남기되 시범 기간에는 관리자만 보게 했고, 메신저 원문이 들어가는 호출은 기록에서 뺐습니다.

까다로웠던 점

• 좋아 보이는 개선 거르기 — 메일을 한 통 단위로 잘라 색인하자 검색 품질(MRR)이 0.722에서 0.829로 올랐습니다. 반면 재정렬 후보를 40개에서 100개로 늘린 안은 고치려던 10문항에서는 좋아 보였지만, 전체 53문항에서는 정답률이 0.857에서 0.643으로 떨어져 기각했습니다.
• 조용한 실패 — 재정렬 모델이 오류를 삼키고 꺼진 채 돌아가는 일을 세 번 겪은 뒤, 대체 동작을 없애고 명시적으로 실패하게 바꿨습니다.
• 캐시를 재던 속도 측정 — 같은 질문을 반복한 속도 측정이 실제로는 캐시 속도를 재고 있다는 것을 찾아 측정 방법을 바꿨습니다.

현재

사내 전체 오픈 전입니다. 수집 자동화와 권한 경계 검증이 남아 있습니다.