[RAG] RAG의 고질병 '환각(Hallucination)'을 줄이는 3가지 검증 레이어

RAG 시스템을 운영하다 보면 반드시 한번 겪는 문제가 있습니다. 모델이 그럴듯하게 말을 하는데 실제로는 틀린 정보를 답하는 상황입니다. 이게 바로 환각입니다. 처음에는 모델 문제라고 생각했는데 운영을 하다 보니 시스템 구조 문제라는 걸 알게 되었습니다. RAG에서 환각을 줄이기 위해 실제로 운영에 넣었던 검증 레이어 이야기를 말씀드리겠습니다.

RAG 환각 문제가 실제 서비스에서 어떻게 발생했는가

RAG 시스템을 처음 붙이면 대부분 기대가 큽니다. 내부 문서를 기반으로 답을 하니까 정확할 것이라고 생각합니다. 저희도 Elasticsearch 기반 벡터 검색과 LLM을 붙여서 FAQ 챗봇을 만들었습니다.

초기 트래픽은 RPS 40 정도였습니다. 하루 질문 수는 약 30만 건 정도였습니다

그런데 문제가 하나 생기기 시작했습니다. 사용자가 질문하지도 않은 내용이 답변에 섞이기 시작했습니다. 문서에 없는 내용인데도 모델이 확신에 찬 톤으로 설명하는 경우가 있었습니다.

운영 로그를 분석해 보니 전체 응답 중 약 12퍼센트 정도에서 이런 현상이 나타났습니다. 숫자만 보면 작아 보이지만 실제 서비스에서는 꽤 큰 문제입니다. 사용자 입장에서는 틀린 정보를 진짜처럼 믿을 수 있기 때문입니다.

 

RAG 환각이 발생하는 운영 환경 Pain Point

환각이 발생하는 이유를 로그 기준으로 분석해보니 크게 세 가지 패턴이 있었습니다.

첫 번째는 검색 실패입니다. 벡터 검색이 질문과 관련 없는 문서를 가져오는 경우입니다. 문서가 틀리면 모델이 아무리 좋아도 답이 틀립니다.

두 번째는 문서 부족입니다. 검색 결과가 너무 적거나 관련 문서가 없는 경우입니다. 이때 모델은 빈 공간을 스스로 채우기 시작합니다. 생각보다 자주 발생합니다.

세 번째는 모델 과신입니다. LLM 특성상 모르면 모른다고 말하지 않습니다. 그럴듯한 답을 만들어냅니다. 운영에서 한번 겪어보면 꽤 당황스럽습니다.

 

초기 RAG 구조

처음 구조는 굉장히 단순했습니다. 검색 결과 몇 개를 LLM에 전달하고 답변을 생성하는 방식입니다. 대부분의 팀이 이렇게 시작합니다.

user question
   |
vector search
   |
top 5 documents
   |
LLM generate answer
   |
response

이 구조는 구현이 간단합니다. latency도 낮습니다. 하지만 운영 환경에서는 환각이 꽤 많이 발생합니다. 특히 문서 품질이 완벽하지 않으면 더 그렇습니다.

 

환각 문제를 해결하기 위한 의사결정 과정

이 문제를 해결하기 위해 팀 내부에서 여러 방법을 검토했습니다. 처음에는 모델 문제라고 생각했습니다. 그래서 모델 교체도 논의했습니다.

방법 A 더 큰 LLM 사용

첫 번째 방법은 더 큰 모델을 사용하는 것이었습니다. 모델이 좋아지면 환각이 줄어들 것이라는 가정입니다.

장점은 간단합니다. 시스템 구조를 크게 바꾸지 않아도 됩니다. 모델만 교체하면 됩니다.

단점도 명확했습니다. 비용이 크게 증가합니다. 질문이 하루 30만 건인데 모델 비용이 두 배가 되면 운영비가 바로 문제 됩니다.

 

방법 B 검증 레이어 추가

두 번째 방법은 RAG 파이프라인에 검증 레이어를 추가하는 방식입니다. 검색과 생성 사이에 검증 단계를 넣는 구조입니다.

장점은 환각을 구조적으로 줄일 수 있다는 점입니다. 모델 자체에 의존하지 않습니다.

단점은 시스템이 복잡해진다는 점입니다.

결국 저희는 검증 레이어를 추가하는 방식을 선택했습니다. 모델을 바꾸는 것보다 구조적으로 문제를 해결하는 게 장기적으로 낫다고 판단했습니다.

 

RAG 환각을 줄이기 위한 3가지 검증 레이어

RAG 환각을 줄이기 위해 실제 운영에 넣은 구조는 세 단계 검증 방식입니다. 검색 단계 검증, 문서 품질 검증, 답변 검증입니다.

레이어 1 검색 결과 유사도 검증

첫 번째 레이어는 검색 결과 품질을 검증하는 단계입니다. 벡터 유사도 점수가 일정 기준 이하이면 답변 생성을 하지 않습니다.

이 레이어 하나만 넣어도 환각이 꽤 줄어듭니다. 검색이 틀리면 답변도 틀리기 때문입니다. 이해가 될까요.

if (topScore < 0.75) {
    return "관련 문서를 찾지 못했습니다.";
}

이 기준값은 운영하면서 계속 조정했습니다. 처음에는 0.7이었는데 실제 로그를 보니 환각이 꽤 발생하더군요. 결국 0.75 정도로 올렸습니다.

 

레이어 2 문서 컨텍스트 검증

두 번째 레이어는 문서 자체를 검증하는 단계입니다. 검색된 문서가 질문과 실제로 관련이 있는지 다시 평가합니다.

여기서는 Relevance 모델을 사용했습니다. 질문과 문서를 다시 비교해서 관련도가 낮으면 제외합니다.

List<Document> filteredDocs =
    docs.stream()
        .filter(doc -> relevanceScore(query, doc) > 0.8)
        .toList();

생각보다 이 단계가 효과가 좋았습니다. 벡터 검색이 가져온 노이즈 문서를 많이 걸러줍니다.

 

레이어 3 답변 근거 검증

마지막 레이어는 답변 자체를 검증하는 단계입니다. 생성된 답변이 실제 문서에 근거가 있는지 확인합니다.

방법은 간단합니다. 답변 문장을 다시 문서와 비교합니다. 근거 문장이 없으면 답변을 차단합니다.

boolean grounded = groundingCheck(answer, docs);

if (!grounded) {
    return "문서 기반 답변을 생성하지 못했습니다.";
}

환각 방지 효과는 꽤 좋았습니다. 실제 운영 로그 기준으로 환각 비율이 12퍼센트에서 약 3퍼센트 수준으로 떨어졌습니다.

 

RAG 환각 방지에 대한 결론

RAG에서 환각은 완전히 없애기 어렵습니다. 모델 특성 때문입니다. 하지만 시스템 구조를 잘 설계하면 상당히 줄일 수 있습니다.

다만 검증 레이어를 추가하면 운영 복잡도는 분명히 올라갑니다. 

그래서 서비스 특성에 맞게 균형을 잡는 게 중요합니다. 내부 문서 검색처럼 정확도가 중요한 서비스라면 이런 구조가 꽤 효과적입니다.