RAG 파이프라인 처음부터 끝까지 삽질 기록
사내 문서 검색 챗봇을 만들어달라는 요청을 받고 6주 동안 붙잡았습니다. 결과는 나쁘지 않은데, 과정이 너무 험했어서 기록 남깁니다.
1단계는 그냥 PDF 긁어서 임베딩하고 벡터DB에 넣었습니다. 데모는 잘 됐습니다. 문제는 실사용에서 시작됐죠.
- 스캔본 PDF가 섞여 있어서 텍스트가 아예 안 뽑히는 파일이 30%였음
- 표가 많은 문서는 청킹하면 맥락이 다 깨짐
- 같은 내용이 여러 버전으로 존재해서 어떤 걸 답해야 하는지 애매함
2단계에서 방향을 바꿨습니다. 임베딩 품질을 올리는 데 시간 쓰는 대신, 문서를 사람이 한 번 정리하는 프로세스를 넣었어요. 부서별로 담당자를 정해서 최신본만 올리게 했습니다. 기술보다 조직 문제였던 거죠.
3단계는 평가입니다. 답변이 맞는지 어떻게 알 것인가가 제일 어려웠는데, 질문 100개에 정답 문서를 매핑해놓고 검색 정확도만 측정했습니다. 생성 품질은 그 다음 문제라고 봤어요. 검색이 틀리면 답은 무조건 틀리니까요.
결과적으로 검색 정확도 62%에서 89%까지 올렸습니다. 모델은 한 번도 안 바꿨습니다. 청킹 전략이랑 메타데이터 필터, 그리고 문서 정리 프로세스 이 세 개가 전부였어요.
돌아보면 처음 두 주는 완전히 삽질이었습니다. 모델 갈아끼우는 데 시간 쓸 게 아니라 데이터를 봤어야 했는데, 눈에 보이는 게 모델이다 보니 자꾸 거기로 손이 갔네요.
9 개의 답변
ㅇㅈ 스캔본 30%는 진짜 지옥이지... OCR 넣는 순간 유지보수 지옥 시작됨
글이 잘렸는데 ㅋㅋ 검색 정확도 몇 %까지 나왔는지 궁금하네
기술보다 조직 문제라는 말 진짜 공감합니다. 저희도 문서 최신본 관리 규칙 만드는 데만 3주 걸렸어요. 결국 부서장들이 '누가 최신본을 책임지느냐'에서 안 합의해줘서 프로젝트 반년 밀렸습니다. 모델 바꾸는 건 하루면 되는데 사람 설득하는 건 분기 단위더라고요.
글쎄, 임베딩 튜닝보다 문서 정리가 먼저라는 건 좀 옛날 얘기 아님? 요즘은 파싱이랑 청킹 단에서 웬만큼 커버되는데. 6주 중에 실제로 임베딩 모델 비교는 얼마나 해보셨는지 궁금하네요.
표 많은 문서 청킹 문제는 마크다운 변환 거치는 게 그나마 나았습니다. 저는 문서를 HTML 테이블로 뽑은 다음 행 단위로 헤더를 붙여서 청크 만들었어요. 그냥 텍스트로 자르면 '3분기 매출' 같은 값이 어느 항목 건지 알 수가 없어서요. 이거 만드는 데 2주 날렸지만 그 뒤로 검색 품질이 확 올라갔음.
평가셋 100개는 좀 적지 않나요? 저희는 300개쯤 되니까 그제서야 쿼리 유형별로 편차가 보이더라고요. 그리고 검색 정확도만 보셨다면 recall@k랑 MRR도 같이 찍어보세요. 하나만 보면 리랭커 넣었을 때 판단이 안 됩니다.
검색 정확도 몇 %인지 안 써놨네. 그리고 '나쁘지 않다'는 기준이 뭔지도. 그거 없으면 그냥 일기임
버전 문제는 메타데이터에 시행일이랑 폐기일 박아두고 필터 거는 게 제일 깔끔했습니다. 문서 자체를 지우면 과거 시점 질문에 답을 못 하더라고요. 참고하세요.
결론 부분 마저 써주세요 ㅠㅠ 3단계에서 막힌 사람으로서 너무 궁금합니다