신뢰할 수 있는 RAG 구축: 7가지 실패 지점과 평가 프레임워크 심층 분석

검색 증강 생성(Retrieval-Augmented Generation, RAG)은 현대적인 AI 아키텍처에 필수적인 프레임워크로, 컨텍스트 인식 에이전트를 구축하는 데 중요한 역할을 합니다.

하지만 기본적인 프로토타입에서 실제 운영에 투입할 수 있는 시스템으로 발전시키려면 데이터 검색, 컨텍스트 통합, 응답 생성에서 상당한 장애물을 넘어야 합니다.

이 문서에서는 7가지 일반적인 RAG 실패 지점과 실용적인 코딩 예제를 사용하여 평가 메트릭스를 깊이 분석합니다.

RAG 실패의 구조 – 7가지 실패 지점(FPs)

연구자 Barnett와 동료들에 따르면, 검색 증강 생성(RAG) 시스템은 파이프라인 전체에서 7가지 특정 실패 지점(FPs)을 만납니다.

아래 다이어그램은 이러한 단계를 보여줍니다:

그림 A. RAG 시스템 구축에 필요한 인덱싱 및 질의 처리 과정. 인덱싱은 개발 단계에서, 질의 처리는 실행 시점에 수행됩니다. 이 연구에서 식별된 실패 지점은 빨간색 상자로 표시됩니다(출처)

파이프라인 순서에 따라 각 FP를 탐색해 보겠습니다. 그림 A의 왼쪽 위에서 오른쪽 아래로 진행합니다.

FP1. 콘텐츠 없음

콘텐츠 누락은 시스템이 답변할 수 없는 질문을 받았을 때 발생합니다. 관련 정보가 처음부터 사용 가능한 벡터 저장소에 없습니다.

실패는 LLM이 모른다고 말하는 대신 그럴듯하지만 틀린 답변을 제공할 때 발생합니다.

FP2. 상위 순위 문서 누락

이 경우 올바른 문서가 벡터 저장소에 존재하지만, 검색기(retriever)가 문서의 순위를 충분히 높게 매기지 못해 LLM에 컨텍스트로 제공되는 상위 k개 문서에 포함되지 않습니다.

결과적으로 올바른 정보는 LLM에 도달하지 못합니다.

FP3. 컨텍스트 없음(통합 전략 제한)

이 경우 올바른 문서가 존재하고 검색되지만, 통합 과정에서 제외됩니다.

이것은 너무 많은 문서가 반환되고 시스템이 LLM의 컨텍스트 창, 토큰 제한 또는 속도 제한에 맞게 필터링해야 할 때 발생합니다.

FP4. 추출 안됨

이 경우 LLM이 컨텍스트에서 올바른 정보를 식별하지 못합니다. 올바른 정보는 벡터 저장소에 있었고 성공적으로 검색 및 통합되었습니다.

이것은 컨텍스트가 너무 노이즈가 많거나 모순된 정보를 포함하여 LLM을 혼란시킬 때 발생합니다.

FP5. 잘못된 형식

이 경우 저장, 검색, 통합 및 LLM 해석이 성공적으로 처리되지만, LLM이 프롬프트에서 제공된 특정 형식 지침을 따르지 못합니다.

예를 들어, 표, 글머리 기호 목록 또는 JSON 스키마와 같은 형식입니다.

FP6. 부적절한 상세도

LLM이 출력을 생성하기는 하지만 사용자의 요구에 비해 지나치게 일반적이거나 복잡합니다.

예를 들어, 복잡한 전문적 목표를 가진 사용자의 질문에 LLM이 단순한 답변을 생성합니다.

FP7. 불완전한 답변

이 경우 LLM의 출력이 반드시 틀린 것은 아니지만, 컨텍스트에 있던 중요한 정보가 빠져 있습니다.

예를 들어, 사용자가 “문서 A, B, C의 핵심 내용은 무엇인가요?”와 같은 복잡한 질문을 해도 LLM은 한두 개의 출처만 다룹니다.

RAG 파이프라인의 성능을 저하하는 FP

이러한 FP는 RAG 파이프라인의 성능에 영향을 미칩니다.

데이터 무결성 및 신뢰성 실패

정보가 없거나 잘못된 경우 시스템은 더 이상 신뢰할 수 있는 정보원이 아닙니다. 주요 FP는 다음과 같습니다.

• FP1 (콘텐츠 없음): 처음부터 문서에 답변이 없습니다.
• FP4 (추출 안됨): LLM이 문서에서 올바른 답변을 무시합니다.
• FP7 (불완전한 답변): LLM이 반쪽짜리 사실을 제시하고 중요한 정보를 빠뜨립니다.

검색 및 효율성 병목 현상

RAG 파이프라인은 검색 및 통합 단계에서 중요한 정보를 누락할 때 비효율적일 수 있습니다. 주요 FP는 다음과 같습니다.

• FP2 (상위 순위 문서 누락): 임베딩 모델이 상위 k 임베딩을 선택하지 못합니다.
• FP3 (컨텍스트 없음): 스크립트가 LLM 제한에 맞게 문서를 필터링할 때 가장 중요한 부분을 삭제합니다.

사용자 경험 및 형식 오류

올바르지만 읽기 어려운 출력이나 잘못된 형식의 출력은 사용자 경험을 저하할 수 있습니다. 주요 FP는 다음과 같습니다.

• FP5 (잘못된 형식): LLM이 JSON 같은 특정 출력 형식을 따르지 못합니다.
• FP6 (부적절한 상세도): LLM이 간단한 예/아니요 질문에 긴 출력을 생성하거나, 반대로 복잡한 질문에 지나치게 짧게 답합니다.

평가 스택: FP를 완화하는 프레임워크

평가 메트릭은 이러한 FP를 체계적으로 완화하기 위해 설계되었습니다.

이 섹션에서는 주요 평가 메트릭과 실용적인 사용 사례를 탐색합니다.

주요 RAG 평가 메트릭:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – 배포 전 단위 테스트

DeepEval은 기준에 따라 가중 점수를 계산합니다.

LLM-판정관(예: GPT-4o)은 LLM의 출력을 기준에 따라 평가합니다:

DeepEval은 G-eval, 사고 사슬(CoT) 프레임워크를 활용해 여러 단계로 출력을 평가합니다:

1. 평가할 기준을 정의합니다(예: “일관성”, “유창성” 또는 “관련성”).
2. 평가 단계를 생성합니다(평가자 LLM 사용).
3. 평가 단계를 따르고 입력 및 LLM의 출력을 분석합니다.
4. 각 기준 점수의 기대 가중합을 계산합니다.

실제 사례:

• 상황: 복잡한 소프트웨어 제품의 기술 문서 도우미(봇)는 엔지니어링 팀이 코드베이스를 업데이트할 때마다 잘 작동하는 것처럼 보입니다.
• 문제: 봇이 여전히 사용자의 질문에 답할 수 있다는 정량적 증거가 없습니다(그저 작동한다고 “생각”할 뿐입니다).
• 해결책: PyTest 함수를 CI/CD 회귀 테스트 세트로 통합하여 GitHub Actions에서 DeepEval을 실행하고 G-Eval 및 기타 메트릭을 테스트 케이스에 실행합니다:

• 예상 결과: 어느 메트릭이든 점수가 임계값(0.85) 아래로 떨어지면 PyTest가 AssertionError를 발생시켜 CI 빌드를 즉시 실패시키고, 눈에 띄지 않는 성능 저하가 운영 환경에 배포되지 않도록 막습니다.

장점:

• 편향 및 유해성에 대한 특화 검사를 포함하여 50개 이상의 메트릭스가 있습니다.
• 기존 CI/CD 파이프라인과 원활하게 통합됩니다.
• 참조 답변이 필요하지 않습니다. 프롬프트 및 제공된 컨텍스트만을 기반으로 출력을 평가합니다.

단점:

• 평가의 품질은 판정관 LLM의 능력에 크게 의존합니다.
• 판정관 LLM이 고급 모델인 경우 계산 비용이 많이 듭니다.

개발자 노트 – DeepEval 테스트 케이스
LLMTestCase 개체의 집합은 DeepEval이 실행하는 테스트 케이스를 정의합니다.

실제로 이 테스트 케이스는 가장 중요한 사용자 질의, 레이블이 지정된 출력, 검색된 컨텍스트를 포함해야 합니다.

이러한 항목은 JSON 또는 CSV 파일에서 검색할 수 있습니다.

RAGAS – 건초 더미 속 바늘 찾기 최적화 도구

Retrieval Augmented Generation Assessment(Ragas)는 사람이 주석을 단 데이터셋 없이도 합성 테스트 세트를 생성해 RAG를 평가하는 것을 목표로 합니다.

그런 다음 주요 메트릭을 계산합니다. 아래 도표는 질문, 컨텍스트 및 답변을 연결하는 평가 삼각 구조를 보여줍니다:

그림 B. RAGAS 평가 삼각 구조. 정밀도, 재현율, 충실도, 관련성 메트릭으로 연결되는 질문, 컨텍스트, 답변(작성자: Kuriko IWAI)

주요 메트릭은 세 가지 그룹으로 분류됩니다:

• 검색 파이프라인(검은 실선, 그림 B): 컨텍스트 정밀도, 컨텍스트 재현율.
• 생성 파이프라인(검은 점선, 그림 B): 충실도, 답변 관련성.
• 정답 기준 데이터(빨간색 박스, 그림 B): 답변 의미적 유사성, 답변 정확성.

실제 사례:

• 상황: 법률 계약을 위한 RAG 시스템이 주요 조항을 누락하고 있습니다. 검색기 또는 생성기에서 문제가 있는지 확신할 수 없습니다.
• 문제: 최적의 상위 k(검색된 덩어리 수) 값을 알 수 없습니다.
• 해결책: RAGAS를 사용하여 100개의 질문과 증거 쌍으로 구성된 합성 테스트 세트를 생성합니다. 그런 다음 RAG 파이프라인을 테스트 세트에 대해 실행하여 컨텍스트 재현율 및 컨텍스트 정밀도를 계산합니다:
• 예상 결과: 메트릭스의 결과에 따라 조치 계획을 수립할 수 있습니다:

표 1. RAGAS 진단 조치 계획 – 점수를 시스템 조정으로 매핑.

장점:

• 정답 기준 데이터셋이 없는 초기 프로젝트에 적합합니다(코드 예시에서 보았듯 RAGAS는 합성 테스트 세트를 생성할 수 있습니다).

단점:

• 합성 테스트 세트는 미묘한 사실 오류를 놓칠 수 있습니다.
• 답변을 개별 주장으로 분해하기 위해 강력한 추출기 모델이 필요합니다(저는 예시에서 gpt-4o를 사용했습니다).

TruLens – 피드백 루프 전문가

TruLens는 최종 출력뿐 아니라 RAG 프로세스의 내부 메커니즘에 초점을 맞추며 피드백 함수를 사용합니다.

또한, LLM 기반 점수를 사용하여 응답이 질의의 의도를 얼마나 잘 충족하는지 평가합니다(4점 리커트 척도, 0–3). 따라서 여러 검색 결과의 품질 순위를 매기는 데 뛰어납니다.

실제 사례:

• 상황: 의료 자문 봇이 사용자의 질문에 정확하게 답변하지만 검증된 PDF 자료에 없는 프로 팁을 추가합니다.
• 문제: 추가된 프로 팁은 유용할 수 있지만 해당 자료에 근거하지 않습니다.
• 해결책: TruLens를 사용하여 score > 0.8 같은 임계값으로 출처 근거성을 확인하는 피드백 함수를 구현합니다:

• 예상 결과: LLM이 검색된 청크에 없는 정보를 포함한 응답을 생성하면 TruLens는 기록을 대시보드에 플래그합니다.

장점:

• 에이전트가 어디에서 벗어났는지 정확히 찾도록 사고 사슬을 시각화합니다.
• 실시간으로 환각을 탐지할 수 있도록 출처 근거성 검사 기능을 기본 제공합니다.

단점:

• 사용자 정의 피드백 함수를 정의하는 데 학습 곡선이 있습니다.
• 대시보드는 간단한 스크립트에 대해 무겁게 느껴질 수 있습니다.

Arize Phoenix – 실패 지도

Arize Phoenix는 오픈 소스 관측 가능성 및 평가 도구로, 복잡한 RAG 시스템을 포함한 LLM 출력을 평가하는 데 사용됩니다.

Arize AI의 OpenTelemetry를 기반으로 구축된 Phoenix는 관측 가능성을 중시하며 LLM 평가를 MLOps의 하위 집합으로 간주합니다.

RAG 평가의 맥락에서 Phoenix는 임베딩 분석에 탁월하며, Uniform Manifold Approximation and Projection(UMAP)을 사용하여 고차원 임베딩을 2D/3D 공간으로 줄입니다.

이 임베딩 분석은 실패한 질의가 의미적으로 함께 그룹화되어 있는지 수학적으로 나타내어, 벡터 데이터베이스에 갭이 있는지 나타냅니다.

실제 사례:

• 상황: 고객 지원 봇이 환불에는 잘 응답하지만 보증 청구에는 엉뚱한 답변을 합니다.
• 문제: 벡터 데이터베이스에 데이터 공백이 있습니다(로그에서는 찾을 수 없습니다).
• 해결책: Arize Phoenix를 사용하여 문서 덩어리와 사용자 질의를 오버레이하는 3D 맵인 UMAP 임베딩 시각화를 생성합니다:
• 예상 결과: 문서가 없는 영역에 사용자 질의가 클러스터링되는 것을 시각적으로 확인하여, 벡터 저장소에 문서가 누락되어 있음을 알 수 있습니다.

장점:

• OpenTelemetry를 기본 지원해 기존 기업용 모니터링 스택과 원활하게 통합됩니다.
• 벡터 저장소의 사각지대를 시각화하는 데 가장 적합한 도구입니다.

단점:

• 점수에 중점을 두지 않고 관측 가능성에 더 중점을 둡니다.
• 단일 에이전트 도구 또는 소규모 애플리케이션의 경우 과도할 수 있습니다.

Braintrust – 프롬프트 회귀 안전망

Braintrust는 고빈도 반복 주기에 적합하며, 모델 간 비교를 사용합니다.

실제 사례:

• 상황: 엔지니어 팀이 “질문에 답변” 프롬프트(사례 A)를 더 복잡한 500단어 시스템 지침(사례 B)으로 업그레이드합니다.
• 문제: 사례 B의 프롬프트를 개선하면 사례 A가 깨질 수 있습니다.
• 해결책: Braintrust를 사용하여 N개의 완벽한 예시(예: N = 50)로 구성된 기준 데이터셋을 생성합니다. 그런 다음 프롬프트에서 단어 하나를 바꿀 때마다 Braintrust를 사용하여 사이드 바이 사이드 비교를 실행합니다:

• 예상 결과: Braintrust는 N = 50개 기준 사례 중 정확히 무엇이 개선되고 악화되었는지 보여주는 차이 보고서를 제공합니다.

장점:

• 배포 전 테스트에 매우 빠릅니다.
• 비기술자 이해관계자가 출력을 검토하고 평가하기 위한 훌륭한 UI를 제공합니다.

단점:

• 일부 오픈 소스 구성 요소가 있지만 독점 소프트웨어이며 SaaS 중심입니다.
• DeepEval 또는 Ragas와 비교하여 내장된 심층 기술 메트릭스가 적습니다.

요약

적절한 평가 프레임워크와 함께 RAG는 사용자 질의에 가장 관련성이 높은 컨텍스트를 LLM에 제공하는 데 경쟁력 있는 도구가 될 수 있습니다.

구현 전략: 메트릭스를 실패 지점에 매핑

일괄적인 해결책은 없지만, 표 2는 이 문서에서 다룬 각 FP에 대해 적용할 평가 메트릭스를 보여줍니다:

표 2. 실패 지점 완화 행렬 – 어떤 도구가 어떤 FP를 해결합니까?

DeepEval과 RAGAS는 데이터 무결성 실패(FP1, FP4, FP7)를 측정하기 위해 충실도 메트릭스를 활용할 수 있습니다.

TruLens는 컨텍스트 정밀도/재현율을 사용하여 출력에 대한 컨텍스트 관련성을 평가하여 효과적으로 FP2를 평가합니다.

Arize Phoenix는 검색 프로세스의 시각적 추적을 제공하여 문서가 통합 중에 손실되었는지 여부를 쉽게 확인할 수 있습니다(FP3).

사용자 경험 실패의 경우 DeepEval은 사용자 경험 실패를 평가하기 위한 사용자 정의 메트릭스를 생성하며, Braintrust는 정답 기준 데이터셋 비교에 탁월합니다.