RAG는 어떻게 망가지는가 ― 평가와 실패 모드 (RAG 제6회)

지금까지 RAG의 부품들을 차례대로 살펴보았습니다.

제1회에서는 RAG를 「검색해서 답하는 메커니즘」이 아니라, 어떤 정보를 어떤 순서로 보고 어디에서 멈출지를 결정하는 메커니즘으로서 정리했습니다.

제2회에서는 BM25, 벡터 검색 (Vector Search), RRF를 살펴보았습니다.

제3회에서는 grep과 벡터 검색 (Vector Search)의 활용 차이를 살펴보았습니다.

제4회에서는 Agentic RAG와 「이제 충분한가」에 대한 판단을 살펴보았습니다.

제5회에서는 PageIndex와 계층형 검색을 살펴보았습니다.

마지막으로 봐야 할 것이 있습니다.

평가입니다.

RAG는 작동하고 있는 것처럼 보이기 쉬운 시스템입니다.

질문을 넣으면 답이 돌아옵니다.

근거처럼 보이는 문서도 나옵니다.

문장도 자연스럽습니다.

그래서 위험합니다.

겉모습이 자연스러워도, 필요한 문서를 집어내지 못했을 수도 있습니다.

집어낸 문서는 맞지만, 읽는 법을 틀렸을 수도 있습니다.

답은 맞지만, 근거가 다를 수도 있습니다.

어쩌다 맞은 것일 뿐, 다음 유사 질문에서는 망가질지도 모릅니다.

제6회에서는 RAG의 평가와 실패 모드를 정리합니다.

RAG를 평가할 때, 가장 먼저 보고 싶어지는 것은 최종 답변입니다.

맞는가.

틀리는가.

이해하기 쉬운가.

물론 이 부분은 빼놓을 수 없습니다.

하지만 RAG에서는 최종 답변만 봐서는 원인을 알 수 없습니다.

답이 틀렸다고 가정해 봅시다.

원인은 어디에 있을까요?

필요한 문서를 검색하지 못한 것일까요?

검색은 되었지만, 순위가 너무 낮아서 컨텍스트 (context)에 들어가지 못한 것일까요?

컨텍스트 (context)에 들어갔지만, 모델이 잘못 읽은 것일까요?

근거에 없는 내용을 보충해 버린 것일까요?

질문 자체가 모호했던 것일까요?

오래된 문서와 새로운 문서가 섞인 것일까요?

최종 답변만으로는 알 수 없습니다.

따라서 RAG의 평가는 적어도 단계별로 나눌 필요가 있습니다.

1. retrieve: 필요한 정보를 집어냈는가
2. select: 노이즈를 제거했는가
3. ground: 근거에 따라 답했는가
...

이 4가지를 나누지 않으면 개선 방향이 산만해집니다.

가장 알기 쉬운 실패는 필요한 문서가 검색 결과에 들어있지 않은 것입니다.

원인은 다양합니다.

쿼리 (query)가 나쁘다.

표기 불일치를 집어내지 못하고 있다.

청크 (chunk)를 나누는 방식이 나쁘다.

문서의 수집에 실패하고 있다.

오래된 임베딩 (embedding) 상태로 업데이트되지 않았다.

검색 대상 범위가 틀렸다.

이것은 검색 재현율 (retrieval recall)의 문제입니다.

단, RAG의 재현율 (recall)은 일반적인 검색보다 엄격합니다.

사람이 검색 결과를 본다면 10번째나 20번째에 있어도 찾아낼 수 있을지도 모릅니다.

하지만 RAG에서는 LLM에 전달하는 상위 몇 건 안에 들어가지 않으면, 실질적으로는 존재하지 않는 것과 같습니다.

따라서 봐야 할 것은 「검색 결과 어딘가에 있는가」가 아닙니다.

답하기 위해 필요한 근거가 LLM에 전달되는 범위 안에 들어있는가

이 지점입니다.

다음 실패는 너무 많이 집어내는 것입니다.

필요한 문서는 들어있습니다.

하지만 관계없는 문서도 대량으로 들어있습니다.

언뜻 보기에는 좋아 보입니다.

「필요한 것은 들어있으니 모델이 읽으면 된다」라고 생각할지도 모릅니다.

하지만 실제로는 그렇게 간단하지 않습니다.

비슷하지만 다른 문서.

오래된 사양.

다른 버전의 절차.

반대되는 조작을 설명하는 페이지.

같은 단어를 사용하고 있을 뿐인 다른 부서의 자료.

이러한 노이즈가 컨텍스트 (context)에 들어가면 모델은 휘둘리게 됩니다.

RAG에서는 재현율 (recall)만 높이면 정밀도 (precision)가 떨어집니다.

많이 집어넣으면 안심할 수 있는 것이 아닙니다.

평가에서는 다음과 같이 살펴볼 필요가 있습니다.

필요한 근거가 들어있는가
불필요한 근거가 얼마나 섞여 있는가
섞인 노이즈로 인해 답이 바뀌는가

특히 Agentic RAG에서는 검색을 늘릴수록 노이즈도 늘어납니다.

따라서 「다시 찾기」를 하는 것은 항상 「불필요한 것을 늘리는」 리스크를 동반합니다.

세 번째는 근거는 컨텍스트 (context)에 들어있는데 모델이 잘못 읽는 실패입니다.

이것은 상당히 까다롭습니다.

검색은 성공했습니다.

근거도 들어있습니다.

하지만 답이 다릅니다.

예를 들어, 문서에 다음과 같이 적혀 있다고 합시다.

무료 해지는 계약 시작일로부터 30일 이내에 통지한 경우에 한한다.

모델이 이것을 「30일 이내라면 언제든 환불된다」라고 답해버립니다.

혹은 통지 조건을 누락해 버립니다.

이것은 검색 (retrieval)의 실패가 아닙니다.

읽기 / 추론 (reading / reasoning)의 실패입니다.

이 경우에는 검색기 (retriever)를 바꿔도 고쳐지지 않습니다.

필요한 것은 근거를 읽는 방식을 평가하는 것입니다.

답변에 필요한 조건을 모두 포착하고 있는가
부정이나 예외를 놓치고 있지는 않은가
오래된 정보와 새로운 정보를 구분하고 있는가
...

RAG에서는 "근거에 기반하고 있는 것처럼 보이는 것"과 "근거를 올바르게 읽고 있는 것"을 나누어 볼 필요가 있습니다.

네 번째는 근거에 없는 내용을 보충해 버리는 실패입니다.

이것은 일반적으로 hallucination (환각)이라고 불리지만, RAG에서는 형태가 조금 다릅니다.

완전히 아무것도 없는 곳에서 만들어내는 것만이 아닙니다.

일부 근거가 있기 때문에, 나머지를 자연스럽게 채워버리는 경우가 있습니다.

예를 들어, 요금표는 찾았습니다.

하지만 예외 조건은 찾지 못했습니다.

그럼에도 모델이, 흔히 있을 법한 예외 조건을 보충하여 답변합니다.

이것은 제4회에서 보았던 "절반만 근거가 있는" 상태입니다.

평가에서는 다음과 같은 관점이 필요합니다.

답변의 각 문장이 어떤 근거에 의해 뒷받침되는가
근거가 없는 부분을 "불명"이라고 말할 수 있는가
부족한 정보를 부족하다고 명시하고 있는가

RAG의 좋은 답변은 언제나 길고 상세한 답변이 아닙니다.

모르는 부분을 모른다고 말할 수 있는 답변입니다.

실무에서 많은 것이 시간 (temporal) 관련 실패입니다.

동일한 사양의 구버전과 신버전이 있습니다.

동일한 고객의 오래된 계약과 새로운 계약이 있습니다.

동일한 장애의 중간 보고와 최종 보고가 있습니다.

RAG는 유사한 문서를 찾아냅니다.

하지만 어떤 것이 최신인지, 어떤 것이 유효한지를 자동으로 구분할 수 있다고는 장담할 수 없습니다.

이 실패는 답변이 상당히 자연스럽게 읽히기 때문에 위험합니다.

평가에서는 다음을 확인합니다.

문서의 날짜를 보고 있는가
버전을 보고 있는가
폐기된 정보를 사용하고 있지는 않은가
...

필요하다면 retrieval (검색) 전에 필터를 넣어야 합니다.

혹은 context (문맥)에 들어온 뒤에 "유효일", "판(version)", "갱신 일시"를 반드시 확인하게 해야 합니다.

마지막으로 운영상의 실패가 있습니다.

답변이 틀렸습니다.

하지만 왜 틀렸는지 알 수 없습니다.

이것은 상당히 치명적입니다.

어떤 query (질의)를 던졌는지.

어떤 문서가 반환되었는지.

어떤 문서를 LLM에 전달했는지.

어디에서 충분하다고 판단했는지.

최종 답변의 어느 부분이 어떤 근거에 대응하는지.

이것이 남아 있지 않으면 RAG는 개선할 수 없습니다.

OpenAI Cookbook의 Agent 개선 루프에서도, trace (추적)를 수집하여 평가로 연결하고, harness (프레임워크)의 개수로 이어가는 사고방식이 나옵니다.

이것은 RAG에도 그대로 적용할 수 있습니다.

실패한 질문을 저장합니다.

그때의 검색 query와 결과를 저장합니다.

사람이 "무엇이 잘못되었는지" 라벨링 (labeling)을 합니다.

동일한 실패가 재발하지 않는지 eval (평가)로 만듭니다.

prompt (프롬프트), 검색 설정, chunking (청킹), reranker (재순위화 도구), Agentic loop를 변경했다면 동일한 eval을 돌립니다.

이렇게 해야 비로소 RAG는 개선됩니다.

평가라고 하면 거대한 benchmark (벤치마크)를 만들어야 할 것처럼 느껴집니다.

하지만 처음부터 크게 만들 필요는 없습니다.

우선 10문제면 충분합니다.

단, 그 10문제는 실제 실패 사례로부터 만들어야 합니다.

사용자가 실제로 던진 질문.

답변이 틀렸던 질문.

검색 결과는 나왔지만 답변이 어긋난 질문.

사람이 "이것은 위험하다"라고 느낀 질문.

각각에 대해 최소한 다음을 추가합니다.

question
expected_answer
required_evidence
...

required_evidence가 핵심입니다.

답변만 가지고 있어서는 RAG 평가에 부족합니다.

어떤 근거가 필요했는지를 가지고 있지 않으면, 검색이 좋았던 것인지 아니면 생성만 우연히 맞은 것인지 알 수 없습니다.

RAG의 eval은 모든 것을 하나의 점수로 만들지 않는 것이 좋습니다.

실패 모드별로 나눕니다.

exact lookup:
에러 코드, 설정명, ID를 찾는 것
semantic lookup:
...

이렇게 나누면 개선 방향이 명확해집니다.

exact lookup이 약하다면 BM25나 grep을 재검토합니다.

semantic lookup이 약하다면 embedding (임베딩)이나 query rewrite (질의 재작성)를 살펴봅니다.

multi-hop이 약하다면 Agentic RAG나 PageIndex를 살펴봅니다.

temporal (시간적 요소)이 약하다면 날짜 메타데이터나 필터를 재검토합니다.

negative (부정적 사례)가 약하다면, Sufficient Context (충분한 문맥) 판정을 강화합니다.

noise (노이즈)가 약하다면, reranker (재순위화 모델)나 context pruning (문맥 가지치기)을 살펴봅니다.

단 하나의 종합 점수만으로는 이 정도까지 파악할 수 없습니다.

여기서 오해해서는 안 될 점이 있습니다.

eval (평가)은 인간을 완전히 배제하기 위한 것이 아닙니다.

오히려 인간이 어디를 보아야 하는지를 명확히 하기 위한 것입니다.

RAG의 실패는 처음에는 인간이 찾아냅니다.

"이 답은 틀렸다."

"이 근거는 오래되었다."

"이 문서를 참조하지 않았다."

"이 질문에는 '모르겠다'라고 답했어야 했다."

그러한 판단을 다음부터 기계적으로 재확인할 수 있는 형태로 만드는 것.

그것이 eval 입니다.

인간의 위화감을 그 순간의 주의로 끝내지 않습니다.

실패 사례로 남겨 다음 개선 시 재발을 방지합니다.

이것이 핵심입니다.

RAG는 한 번 만들고 끝나는 시스템이 아닙니다.

문서는 늘어납니다.

오래된 문서도 남습니다.

사용자의 질문도 변합니다.

검색 대상도 늘어납니다.

모델도 변합니다.

그때마다 이전에는 올바랐던 설정이 어긋날 수 있습니다.

chunk (청크) 크기.

embedding (임베딩) 모델.

BM25의 가중치.

RRF의 조정.

reranker의 유무.

Agentic loop (에이전틱 루프)의 횟수.

PageIndex의 입도 (granularity).

이것들을 감각만으로 바꾸면 다른 부분이 망가집니다.

그렇기에 RAG에는 평가의 발판이 필요합니다.

작은 eval set (평가 세트).

실패의 분류.

trace (추적).

필요 근거.

회귀 테스트 (regression test).

인간의 리뷰.

이것들이 있어야 비로소 RAG는 개선될 수 있습니다.

이번 6회에 걸쳐 살펴본 내용을 다시 한번 정리합니다.

RAG는 단순한 벡터 검색이 아닙니다.

BM25나 grep처럼 문자열을 직접 다룰 수 있는 도구가 필요한 상황이 있습니다.

벡터 검색처럼 의미로 후보를 넓히는 도구가 필요한 상황도 있습니다.

RRF처럼 여러 검색 결과를 혼합하는 방법도 있습니다.

Agentic RAG처럼 정보가 부족하면 다시 한번 찾는 메커니즘도 있습니다.

PageIndex처럼 긴 문서를 지도처럼 다루는 방법도 있습니다.

그리고 그것들이 정말로 효과가 있는지 확인하는 eval이 필요합니다.

즉, RAG는 하나의 기술이 아니라 정보를 다루는 일련의 흐름입니다.

질문을 분해한다.

찾는다.

선택한다.

읽는다.

부족함을 확인한다.

답한다.

실패를 기록한다.

다음에 수정한다.

이 흐름 전체가 RAG입니다.

다음 회차부터는 제2기로서 이 골격을 확장해 나갑니다.

그래프 검색과 멀티홉 (multi-hop), 멀티모달 (multi-modal)과 문서 처리, 기업 도입과 개선 루프, 그리고 Context Engine으로 이어지는 흐름을 살펴보겠습니다.

―― AI 미래 편집실 「AI 워치」