RAG 구축, 사내 문서 검색 AI가 틀리는 이유부터
RAG 구축을 앞둔 IT 담당자를 위해 사내 문서 검색 AI가 답을 지어내거나 권한 밖 문서를 보여 주는 이유와, 구축 전에 정해야 할 문서 분할, 검색 방식, 권한 설계를 정리했습니다.
이 글의 목차
"우리 회사 규정이랑 매뉴얼을 다 아는 챗봇 하나 만들어 봐." 이런 지시를 받으면 IT 담당자는 두 가지가 먼저 걱정됩니다. 그럴듯하지만 틀린 답을 내면 어떡하지, 그리고 인사팀만 봐야 할 문서 내용을 아무에게나 말해 버리면 어떡하지. 이 글은 사내 문서 검색 AI를 만드는 가장 흔한 방식인 RAG가 어떻게 동작하는지, 그리고 그 두 걱정이 실제로 어디서 생기고 어떻게 막는지를 구축 전에 정할 것 위주로 정리했습니다.
RAG란 무엇이고, 왜 사내 챗봇에 쓰나
생성형 AI의 언어 모델은 인터넷에 공개된 글로 학습했습니다. 그래서 회사 안의 출장 규정이나 제품 매뉴얼은 모릅니다. 모르는 것을 물으면 아는 것처럼 지어내기도 합니다.
RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 이 문제를 단순하게 풉니다. 답하기 전에 관련 문서를 먼저 찾아서, 찾은 문서를 근거로만 답하게 하는 것입니다. 이 이름은 2020년 Meta(당시 Facebook) AI 연구진 등이 발표한 논문에서 처음 쓰였습니다(Lewis 외, 2020). 모델을 새로 학습시키지 않아도 되고, 문서가 바뀌면 검색 대상만 다시 정리하면 되기 때문에 규정이 자주 바뀌는 회사에 잘 맞습니다.
질문에서 답까지 어떻게 흘러가나
- 01문서 준비
규정집, 매뉴얼, 회의록을 알맞은 크기로 나누고, 뜻을 숫자로 바꾼 값(임베딩)과 함께 저장합니다.
- 02검색
질문한 사람이 볼 수 있는 문서 안에서, 질문과 뜻이나 낱말이 가까운 문단을 찾습니다.
- 03근거 전달
가까운 순서대로 몇 개의 문단을 골라 언어 모델에게 건넵니다.
- 04답변과 출처
건넨 문단 안의 내용으로만 답하고, 어느 문서의 어느 부분을 근거로 했는지 함께 보여 줍니다.
이 흐름에서 언어 모델이 하는 일은 마지막 한 단계뿐입니다. 나머지는 모두 검색과 문서 준비입니다. 그래서 RAG의 품질은 모델보다 앞단에서 갈리는 경우가 훨씬 많습니다.
파인튜닝과는 무엇이 다른가
"우리 문서로 모델을 학습시키면 되지 않나"라는 질문도 자주 나옵니다. 두 방식은 잘하는 일이 다릅니다.
| 비교 | RAG(검색해서 건네기) | 파인튜닝(추가 학습) |
|---|---|---|
| 문서가 바뀌면 | 검색 대상만 다시 정리 | 다시 학습해야 반영 |
| 답의 근거 표시 | 문서와 문단을 보여 줄 수 있음 | 어디서 배운 내용인지 보여 주기 어려움 |
| 권한별로 다른 답 | 검색 단계에서 거를 수 있음 | 한번 배운 내용은 누구에게나 나올 수 있음 |
| 잘 맞는 일 | 규정, 매뉴얼, 사내 지식 질의응답 | 정해진 말투, 양식, 분류 방식 익히기 |
사내 지식 질의응답이라면 대부분 RAG에서 시작합니다. 파인튜닝은 "우리 회사 보고서 양식대로 써 줘"처럼 형식을 익혀야 할 때 함께 검토합니다.
답이 엉뚱해지는 이유는 대개 검색에 있습니다
시범으로 만들어 보면 "이 질문에는 왜 이런 답을 하지?" 하는 순간이 옵니다. 원인을 따라가 보면 언어 모델이 아니라 엉뚱한 문단을 근거로 건넨 경우가 많습니다. 확인할 곳은 네 군데입니다.
문서를 나누는 단위
너무 잘게 나누면 앞뒤 맥락이 잘리고, 너무 크게 나누면 질문과 상관없는 내용이 섞입니다. 문서 종류마다 나누는 기준이 달라야 합니다.
| 문서 종류 | 나누는 기준(출발점) | 놓치기 쉬운 것 |
|---|---|---|
| 규정집, 사규 | 조항 단위, 조 제목을 함께 붙임 | 부칙과 개정 이력, 별표 |
| 매뉴얼 | 절차 한 묶음 단위 | 앞 단계를 전제로 한 설명 |
| 회의록 | 안건 단위 | 누가 말했는지, 결정인지 의견인지 |
| 표가 많은 문서 | 표 한 개 단위, 머리글 행 포함 | 표를 글로 펼치면 숫자와 항목이 어긋남 |
뜻 검색과 낱말 검색을 함께
임베딩을 쓰는 뜻 검색은 "휴가"를 물어도 "연차" 조항을 잘 찾습니다. 대신 제품 코드, 조항 번호, 사람 이름처럼 글자가 정확히 같아야 하는 검색에는 약합니다. 그래서 실제 서비스에서는 낱말 검색을 함께 쓰고, 두 결과를 합쳐 다시 순서를 매기는 방식을 많이 씁니다.
최신본과 옛 문서
2023년 출장 규정과 2026년 개정 규정이 같이 들어 있으면 옛 규정을 근거로 답할 수 있습니다. 문서마다 개정일, 적용 부서, 폐지 여부 같은 꼬리표를 붙이고, 검색할 때 최신본을 먼저 보게 해야 합니다.
근거가 없을 때의 행동
검색 결과가 질문과 충분히 가깝지 않으면 지어내지 말고 "관련 문서를 찾지 못했습니다"라고 답하게 해야 합니다. 이 한 줄이 없으면 모델은 아는 척을 합니다.
권한 밖 문서가 답에 섞이지 않게 하려면
이를 위해 정할 것은 세 가지입니다. 첫째, 문서 관리 시스템이나 그룹웨어의 권한 정보를 문서와 함께 가져와 검색 대상에 붙입니다. 둘째, 권한이 바뀌면 검색 대상의 권한도 같은 날 바뀌도록 동기화 주기를 정합니다. 셋째, 퇴사자나 부서 이동처럼 사람의 권한이 바뀌는 경우를 시험 질문에 꼭 넣습니다.
지어낸 답을 줄이는 장치
완벽하게 막을 수는 없지만 크게 줄일 수는 있습니다. 답변마다 근거 문서와 문단을 보여 주면 사용자가 스스로 확인할 수 있습니다. 그리고 출시 전에 실제 질문 50~100개와 모범 답안을 모아 두고, 문서나 설정을 바꿀 때마다 같은 질문으로 다시 재야 합니다. 평가 방법은 생성형 AI 답변 품질 평가 글에 따로 정리했습니다.
구축 전에 확인할 것
RAG 구축 전 점검표
- 답의 근거가 될 문서가 어디에 몇 건 있는지 알고 있다
- 같은 문서의 여러 판 중 최신본을 구분할 수 있다
- 문서마다 누가 볼 수 있는지 권한 정보가 남아 있다
- 실제 사용자가 할 질문과 모범 답안을 50개 이상 모을 수 있다
- 문서를 외부 서비스로 보내도 되는지, 사내에서만 처리해야 하는지 정했다
마지막 항목의 답이 "사내에서만"이라면 구성과 비용이 달라집니다. 이 경우는 온프레미스 LLM 구축 글을 함께 보시면 좋습니다.
자주 묻는 질문
RAG와 ChatGPT 같은 일반 챗봇은 무엇이 다른가요?
일반 챗봇은 학습한 공개 지식으로 답합니다. RAG는 회사 문서를 먼저 찾아 그 내용으로만 답하고 출처를 보여 줍니다. 회사 규정처럼 정답이 문서에 있는 질문이라면 RAG가 맞습니다.
문서가 몇 건 정도부터 RAG를 만들 만한가요?
건수보다 질문이 얼마나 자주 반복되는지가 중요합니다. 규정집 하나라도 하루에 수십 번 묻는다면 충분히 가치가 있습니다.
엑셀이나 표가 많은 문서도 검색할 수 있나요?
할 수 있지만 준비가 더 필요합니다. 표를 문장으로 풀어 버리면 항목과 숫자가 어긋나기 쉬워서, 표 단위로 나누고 머리글을 함께 저장하는 식으로 따로 다룹니다.
구축 기간은 어느 정도 걸리나요?
문서가 정리되어 있고 권한 정보가 있다면 시범 버전은 몇 주 안에 만들 수 있습니다. 문서를 모으고 최신본을 가리는 일이 남아 있으면 그 기간이 더 깁니다.
사내 문서 검색 AI는 모델을 고르는 일보다 문서와 권한을 정리하는 일이 더 큽니다. 지금 가진 문서로 어디까지 가능한지 궁금하다면 AI 솔루션 소개를 보시거나 문의로 문서 현황을 알려 주세요.
