RAG란 무엇인가? AI가 내 문서에서 답을 찾는 방식

AI를 활용하여 생성한 이미지입니다.

회사 규정 PDF나 개인 메모를 AI에게 읽혀 질문하고 싶을 때, 모델이 그 문서를 실제로 찾아보고 답하는지 확인해야 합니다. RAG는 답변을 만들기 전에 연결된 문서에서 관련 내용을 검색하고, 검색 결과를 답변의 재료로 넣는 구조입니다. Retrieval-Augmented Generation이라는 이름처럼 검색과 생성 단계를 붙이지만, 출처를 붙였다고 답변이 자동으로 사실이 되는 것은 아닙니다.[1][2][3]

RAG의 세 단계

일반 모델만 사용할 때는 모델이 학습한 자료와 질문이 주된 참고 범위입니다. RAG에서는 조직의 문서, 데이터베이스, 파일처럼 연결된 외부 지식이 검색 대상이 됩니다. 모델을 다시 학습시키지 않고도 문서 묶음을 갱신할 수 있다는 점이 파인튜닝과 다른 부분입니다.

문서를 어떻게 찾는가

RAG 시스템은 문서를 그대로 한 덩어리로 넣기보다 검색 가능한 작은 조각으로 나누는 경우가 많습니다. OpenAI의 Retrieval 문서는 파일을 조각으로 나누고 임베딩한 뒤 벡터 저장소에 연결하는 흐름을 설명합니다.[3] 임베딩은 글의 의미를 숫자 벡터로 표현하는 방식이어서, 질문과 같은 단어가 없어도 의미가 가까운 조각을 찾는 데 사용할 수 있습니다.

문서를 너무 잘게 쪼개면 조건과 예외가 서로 떨어지고, 너무 크게 넣으면 관련 없는 내용이 함께 검색될 수 있습니다. 제목, 조항, 표의 행처럼 의미가 끊기지 않는 단위를 우선 고려하세요. 스캔 PDF의 글자가 깨지거나 표와 각주가 추출되지 않으면 검색 단계부터 품질이 떨어집니다.

출처가 있어도 원문을 확인해야 하는 이유

RAG의 검색 대상이 오래됐거나 질문과 맞지 않으면 답변도 흔들립니다. 문서의 작성일과 개정일, 적용 대상, 검색 결과로 표시된 원문을 확인해야 합니다. 예를 들어 최신 휴가 규정과 이전 규정이 함께 색인되어 있다면 검색 결과가 그럴듯해도 어느 버전이 현재인지 판단하기 어렵습니다.

문서형 AI를 고를 때의 결정 기준

1. 답변 아래에 참고 파일명, 페이지, 원문 링크가 표시되는지 확인합니다.
2. 문서를 추가·삭제했을 때 검색 색인이 언제 갱신되는지 봅니다.
3. 내 문서 전체인지 특정 폴더인지 검색 범위를 확인합니다.
4. 계약서·인사자료처럼 민감한 파일의 보관·접근 정책을 읽습니다.
5. 검색 실패나 근거 부족을 “모르겠다”고 표시할 수 있는지 확인합니다.

제품 이름에 RAG가 들어간다고 같은 기능을 제공하는 것은 아닙니다. 파일 형식, OCR 지원, 권한 분리, 문서 삭제 반영 시점, 출처 표시 방식을 실제 안내에서 비교하세요. 작은 문서 묶음으로 질문을 만들어 검색된 문단과 답변이 맞는지 먼저 확인한 뒤 중요한 자료를 연결하는 편이 안전합니다.

RAG와 파인튜닝은 같은가요?

아닙니다. RAG는 답변 시 외부 문서를 검색해 참고하는 방식이고, 파인튜닝은 모델의 동작이나 출력 경향을 추가 학습으로 조정하는 방식입니다. 내부 문서가 자주 바뀐다면 일반적인 RAG 구성에서는 모델 재학습보다 색인을 최신 문서로 갱신하는 작업을 먼저 검토합니다. 갱신 주기와 지원 파일 형식은 제품마다 다릅니다.[2][3]

실제로 적용하는 순서

1. 최신 문서와 적용 대상을 정하고 이전 버전을 분리합니다.
2. PDF·DOCX·웹페이지에서 글자와 표가 정상적으로 추출되는지 확인합니다.
3. 제목과 조항 단위로 검색 색인을 만들고 권한 범위를 정합니다.
4. 질문을 입력한 뒤 검색된 문단 또는 인용 표시를 엽니다.
5. 답변의 숫자, 날짜, 예외 조건을 원문과 대조합니다.

근거 문단을 찾지 못한 답변은 확정하지 말고 질문을 구체화하거나 담당자에게 원문 확인을 요청하세요. RAG는 문서 품질과 검색 품질의 영향을 크게 받으며, 개인정보와 접근 권한도 함께 관리해야 합니다.[1][2]

검색이 틀렸을 때의 진단 순서

답변이 이상할 때 곧바로 모델을 바꾸기보다 검색 결과부터 분리해 보세요. 첫째, 질문에 필요한 문서가 색인에 실제로 들어갔는지 확인합니다. 둘째, 최신 버전과 이전 버전이 함께 검색되는지 봅니다. 셋째, 검색된 조각에 표의 열 제목이나 조항의 예외 조건이 붙어 있는지 확인합니다. 넷째, 검색 결과는 맞는데 생성 단계에서 숫자나 날짜를 바꿨는지 원문과 대조합니다.

필요한 조각 자체가 나오지 않으면 문서 분할, 제목, 임베딩, 검색 범위를 점검해야 합니다. 관련 조각은 나오지만 답이 틀리면 근거 사용 규칙이나 모델의 해석을 살펴야 합니다. 출처 링크는 맞는데 적용 대상이 다른 경우도 있으므로 회사 전체 규정과 특정 팀 규정을 섞지 않도록 문서 메타데이터를 함께 관리하세요.

권한과 삭제 반영도 품질의 일부입니다

RAG에 문서를 연결할 때 검색 품질만 보고 권한을 나중으로 미루면 안 됩니다. 사용자가 읽을 권한이 없는 파일 조각이 검색 결과에 섞이지 않는지 확인하고, 문서 삭제나 권한 변경이 색인에 언제 반영되는지 물어보세요. 계약서나 인사자료는 원문을 업로드해도 되는지, 보관 기간과 운영자 접근 범위가 무엇인지 먼저 확인해야 합니다.

작은 검증 세트도 만들어 두세요. 정상 질문, 문서에 없는 질문, 최신 버전과 이전 버전이 충돌하는 질문, 권한이 없는 문서를 묻는 질문을 포함하면 기능 설명만 읽을 때 보이지 않는 실패를 찾을 수 있습니다. 이는 제품 성능을 보장하는 테스트가 아니라, 실제 도입 전에 확인할 조건을 정하는 점검표입니다.

자주 묻는 질문

RAG를 쓰면 환각이 사라지나요?

아닙니다. 검색된 문서를 잘못 해석하거나 문서에 없는 결론을 덧붙일 수 있습니다. 중요한 답은 원문 조항을 직접 열어 확인해야 합니다.[1][3]

RAG는 인터넷 검색과 같은가요?

검색 단계는 닮았지만, RAG는 웹페이지뿐 아니라 미리 연결한 파일·데이터베이스·지식 기반을 검색할 수 있습니다. 어떤 자료가 연결됐는지가 답변 범위를 결정합니다.

출처 링크가 있으면 믿어도 되나요?

아닙니다. 링크가 있다는 사실과 답변이 그 출처를 정확히 해석했다는 사실은 별개입니다. 원문, 버전, 적용 날짜를 함께 보세요.

도입 담당자는 답변 화면만 평가하지 말고 검색된 원문과 권한 처리까지 함께 기록하세요. 질문, 검색 결과, 최종 답변, 사람이 수정한 내용을 남기면 문서가 바뀌었을 때 같은 질문을 다시 비교할 수 있습니다. 다만 보존 로그에도 원문 개인정보가 그대로 복사되지 않도록 마스킹 규칙을 적용해야 합니다.

문서에 없는 질문에 근거 없는 답을 내놓는지 확인하는 것도 중요합니다. RAG가 연결된 문서 안에서 답을 찾지 못했다면 모른다고 말하거나 담당자 확인으로 넘기는 흐름이 있어야 합니다. 이 실패 경로가 없으면 출처 표시가 있는 그럴듯한 문장이 오히려 검토를 늦출 수 있습니다. 특히 숫자와 날짜는 답변보다 원문 표를 먼저 여는 습관이 필요합니다. 예외 조건도 함께 확인하세요. 질문자의 권한에 따라 같은 질문의 검색 결과가 달라지는지도 확인해야 합니다.

관련 글: AI가 거짓말하는 걸까? 틀린 답을 자신 있게 말하는 환각의 이유

Sources

1. [1] Google Cloud, Retrieval-augmented generation
2. [2] AWS, What is Retrieval-Augmented Generation?
3. [3] OpenAI Developers, Retrieval