회사에서 AI 도구를 만들고 있는데, 이번에는 사내 규정 챗봇 구축기를 공유해봅니다.
처음 문제는 단순했습니다.
“출장비 한도 얼마예요?”
“이 규정 최신본 맞아요?”
“어느 조항에 있는 내용이에요?”
규정은 PDF, 한글파일로 흩어져 있고, 사람들은 결국 문서를 찾기보다 옆 사람에게 물어봤습니다. 그래서 규정을 채팅으로 물어보면 답변과 출처 조항까지 알려주는 챗봇을 만들기로 했습니다.
첫 단계는 원본 규정을 마크다운(MD) 으로 변환하는 일이었습니다.
PDF나 한글파일을 그대로 넣는 것보다, 제목·조항·표 구조를 정리해두면 RAG 검색에도 좋고 나중에 “어느 규정 몇 조”인지 추적하기도 쉬웠습니다.
규정마다 OOBS-001 같은 코드 체계도 붙였습니다. 접두어만 봐도 인사, 총무, 안전 등 분류가 가능하게 하고, 신규 업로드 시 코드 형식도 검증하도록 했습니다.
그다음은 일반적인 RAG 구조였습니다.
MD 문서 청킹 → 임베딩 → 질문 입력 → 관련 조각 검색 → LLM 답변 생성
핵심은 답변 하단에 반드시 출처 규정과 조항을 표시하는 것이었습니다. 그래야 사용자가 답변을 믿고 확인할 수 있으니까요.
그런데 진짜 어려운 건 여기부터였습니다.
초기에는 챗봇이 그럴듯하게 없는 조항을 지어냈습니다. “제15조에 따르면…”이라고 답하는데, 실제로는 그런 조항이 없었습니다.
그래서 3중 방어막을 넣었습니다.
검색된 내용에만 근거해 답하도록 프롬프트 제한
코드 레벨에서 근거 없는 답변 차단
모르면 “해당 규정을 찾을 수 없습니다”라고 답하도록 처리
또 하나의 문제는 종합형 질문이었습니다.
“이런 경우 절차 전체 알려줘” 같은 질문은 문서를 너무 잘게 쪼개면 필요한 내용이 흩어져서 답변이 약해졌습니다. 그래서 청크 크기와 묶는 기준을 다시 조정했습니다.
표 기반 질문도 까다로웠습니다.
“업무분장표에서 OO팀 담당 업무 알려줘” 같은 질문은 표 구조, 검색 랭킹, 컨텍스트 예산 문제까지 같이 봐야 했습니다. 단순히 데이터를 예쁘게 고친다고 해결되는 문제가 아니었습니다.
결론적으로 배운 점은 이겁니다.
RAG는 “문서 변환”보다 검색 품질과 평가가 훨씬 중요합니다.
그래서 질문-정답 평가셋을 만들고, 개선할 때마다 정답률을 수치로 확인했습니다. “느낌상 좋아졌다”는 믿으면 안 되더라고요.
그리고 가장 중요한 원칙 하나.
모른다고 답하는 챗봇이, 그럴듯하게 거짓말하는 챗봇보다 훨씬 낫다.
