Connect with us

์‹ ๋ขฐํ•  ์ˆ˜ ์žˆ๋Š” RAG ๊ตฌ์ถ• ๋ฐฉ๋ฒ•: 7๊ฐ€์ง€ ์‹คํŒจ ์ง€์ ๊ณผ ํ‰๊ฐ€ ํ”„๋ ˆ์ž„์›Œํฌ์— ๋Œ€ํ•œ ์‹ฌ์ธต ๋ถ„์„

์‚ฌ์ƒ ๋ฆฌ๋”

์‹ ๋ขฐํ•  ์ˆ˜ ์žˆ๋Š” RAG ๊ตฌ์ถ• ๋ฐฉ๋ฒ•: 7๊ฐ€์ง€ ์‹คํŒจ ์ง€์ ๊ณผ ํ‰๊ฐ€ ํ”„๋ ˆ์ž„์›Œํฌ์— ๋Œ€ํ•œ ์‹ฌ์ธต ๋ถ„์„

mm

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

하지만 기본 프로토タイプ에서 프로덕션 준비 시스템으로 이동하는 과정에는 데이터 검색, 컨텍스트 통합, 응답 생성에서 상당한 장애물이 있습니다.

이 기사에서는 7가지 일반적인 RAG 실패 지점과 평가 지표에 대한 심층 분석을 제공합니다.

RAG 고장의 해부학 – 7가지 실패 지점(FPs)

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

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

그림 A. RAG 시스템을 생성하기 위한 인덱싱 및 쿼리 프로세스. 인덱싱 프로세스는 개발 시간에 수행되고 쿼리는 런타임에 수행됩니다. 이 연구에서 식별된 실패 지점은 빨간 상자로 표시됩니다(출처)

그림 A. RAG 시스템을 생성하기 위한 인덱싱 및 쿼리 프로세스. 인덱싱 프로세스는 개발 시간에 수행되고 쿼리는 런타임에 수행됩니다. 이 연구에서 식별된 실패 지점은 빨간 상자로 표시됩니다(출처)

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

FP1. 컨텐츠 없음

컨텐츠가 없음은 시스템이 컨텐츠가 없는 경우에 질문을 받았을 때 발생하는 현상입니다.

실패는 LLM이 올바른 답변을 제공하는 대신 그럴듯한 그러나 잘못된 답변을 제공할 때 발생합니다.

FP2. 상위 문서 누락

이 상황은 올바른 문서가 벡터 저장소에 존재하지만 검색기가 그것을 상위 k개 문서에 포함시킬 만큼 충분히 높은 순위를 매기지 못하는 경우입니다.

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

FP3. 컨텍스트 아님(통합 전략 제한)

이 상황은 올바른 문서가 존재하고 벡터 저장소에서 검색되었지만 통합 과정에서 제외되는 경우입니다.

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

FP4. 추출 안됨

이 상황은 LLM이 컨텍스트에서 올바른 정보를 식별하지 못하는 경우입니다.

이것은 컨텍스트가 너무 노이즈가 많거나 모순된 정보로 혼동을 일으킬 때 발생합니다.

FP5. 잘못된 형식

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

예를 들어, LLM이 테이블, 번호 매기기 목록 또는 JSON 스키마와 같은 형식 지침을 따르지 못할 때 발생합니다.

FP6. 부정확한 특이성

LLM의 출력은 기술적으로 존재하지만 사용자의需求에 비해 너무 일반적이거나 너무 복잡할 수 있습니다.

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

FP7. 불완전한 답변

이 상황은 LLM이 출력을 생성하지만 그 출력에 중요한 정보가 누락된 경우입니다.

예를 들어, 사용자가 복잡한 질문을 할 때, 예를 들어 “문서 A, B, C의 주요 사항은 무엇입니까?”와 같은 경우, LLM은 하나 또는 두 개의 소스만 다루는 경우에 발생합니다.

FP가 RAG 파이프라인 성능에 미치는 영향

이러한 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, 사슬-생각(Chain-of-Thought, CoT) 프레임워크를 사용하여 출력을 평가합니다:

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

실제 시나리오

  • 상황: 복잡한 소프트웨어 제품에 대한 기술 문서 보조자(봇)가 코드베이스를 업데이트할 때마다 작동하는 것 같습니다.
  • 문제: 사용자 질의에 대한 봇의 답변을 검증할 수 있는 колич적 증거가 없습니다(당신은 그냥 “작동한다”고 생각합니다…).
  • 해결책: PyTest 함수를 CI/CD 회귀 테스트 세트로 통합하여 Github Action에서 DeepEval을 실행하고 다른 지표와 함께 G-Eval을 실행합니다:
  • 예상 결과: 지표의 점수가 임계값(0.85) 아래로 떨어지면 PyTest는 AssertionError를 발생시켜 CI 빌드를 실패시키고, 침묵적인 회귀를 생산에 도달하는 것을 방지합니다.

장점

  • 편향 및 유독성 확인을 포함한 다양한 지표(50+)가 사용 가능합니다.
  • 기존 CI/CD 파이프라인과 无缝하게 통합됩니다.
  • 참조가 필요하지 않습니다. 출력을 프롬프트와 제공된 컨텍스트만으로 평가합니다.

단점

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

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

실제로 이 테스트 케이스는 가장 중요한 사용자 질의와 레이블이 지정된 출력을 포함해야 하며, 이러한 출력은 JSON 또는 CSV 파일에서 검색할 수 있습니다.

RAGAS – 바늘을 찾는 최적화

RAGAS(Retrieval Augmented Generation Assessment)는 인간이 주석을 단 데이터셋 없이 합성 테스트 세트를 생성하여 RAG를 평가하는 것을 목표로 합니다.

그런 다음, 플래그십 지표를 계산합니다:

그림 B. 질문, 컨텍스트 및 답변을 연결하는 RAGAS 평가 트라이어드 다이어그램(정확도, 재현율, 충실도 및 관련성 지표)(Kuriko IWAI가 만든 것)

그림 B. 질문, 컨텍스트 및 답변을 연결하는 RAGAS 평가 트라이어드 다이어그램(정확도, 재현율, 충실도 및 관련성 지표)(Kuriko IWAI가 만든 것)

플래그십 지표는 세 가지 그룹으로 분류됩니다:

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

실제 시나리오

  • 상황: 법률 계약을 위한 RAG 시스템이 주요 조항을 누락하고 있습니다. 검색기 또는 생성기 중 어디에 문제가 있는지 확신할 수 없습니다.
  • 문제: 최적의 상위 k(검색된 청크 수)에 대한 아이디어가 없습니다.
  • 해결책: RAGAS를 사용하여 100개의 질문과 증거 쌍으로 구성된 합성 테스트 세트를 생성합니다. 그런 다음 RAG 파이프라인을 테스트 세트에 대해 실행하여 컨텍스트 재현율 및 컨텍스트 정확도를 계산합니다:
  • 예상 결과: 지표 결과에 따라 조치 계획은 다음과 같습니다:
지표 점수 진단 조치 계획
컨텍스트 재현율 낮음 검색기가 올바른 정보를 놓쳤습니다. – 상위 k 증가.
– 하이브리드 검색(BM25 + 벡터)을 시도합니다.
컨텍스트 정확도 낮음 상위 k 청크에 너무 많은 노이즈 및 필터가 포함되어 있습니다. – 상위 k 감소.
– 리랭커(Cohere와 같은)를 구현합니다.
충실도 낮음 생성기가 데이터에도 불구하고 환각을 합니다. – 시스템 프롬프트 조정.
– 컨텍스트 창 제한을 확인합니다.

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

장점

  • 초기 단계 프로젝트에 적합합니다(그림과 같이 RAGAS는 합성 테스트 세트를 생성할 수 있습니다).

단점

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

TruLens – 피드백 루프 전문가

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

또한 LLM 기반 점수를 사용하여 응답이 질의의 의도에 얼마나 잘 만족하는지 평가합니다(0-3의 4점 리커트 척도).

실제 시나리오

  • 상황: 의료 고문 봇이 사용자의 질문에 올바르게 답변하지만 검증된 PDF 기반에 없는 프로 팁을 추가합니다.
  • 문제: 추가된 프로 팁은 유용할 수 있지만 근거가 없습니다.
  • 해결책: TruLens를 사용하여 근거를 위한 피드백 함수를 구현하고 점수 > 0.8과 같은 임계값을 설정합니다.
  • 예상 결과: LLM이 정보를 포함하는 응답을 생성할 때 TruLens는 기록을 대시보드에서 플래그합니다.

장점

  • 이유 체인을 시각화하여 에이전트가 어디서 잘못된 경로를 따랐는지 정확히 식별할 수 있습니다.
  • 실시간으로 환각을 잡기 위한 내장 지원을 제공합니다.

단점

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

Arize Phoenix – 침묵의 실패 지도

Arize Phoenix는 LLM 출력을 평가하기 위한 오픈 소스 관측 가능성 및 평가 도구입니다.

Arize AI에서 구축된 OpenTelemetry를 기반으로 하며, MLOps의 하위 집합으로 LLM 평가에 중점을 둡니다.

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

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

실제 시나리오

  • 상황: 고객 지원 봇이 환불에 대해서는 잘 작동하지만 보증 청구에 대해서는 무의미한 답변을 제공합니다.
  • 문제: 로그에서 찾을 수 없는 벡터 데이터베이스에 데이터 홀입니다.
  • 해결책: Arize Phoenix를 사용하여 벡터 데이터베이스에 대한 Umap 임베딩 시각화를 생성하고, 사용자 질의를 문서 청크에 오버레이합니다.
  • 예상 결과: 문서가 없는 어둠의 영역에 사용자 질의가 클러스터링되는 것을 시각적으로 확인하여, 벡터 저장소에 문서가 누락되었음을 알 수 있습니다.

장점

  • 기존 엔터프라이즈 모니터링 스택과 통합됩니다.
  • 벡터 저장소의 블라인드 스폿을 시각화하는 데 최적인 도구입니다.

단점

  • 점수에 중점을 두기보다 관측에 중점을 둡니다.
  • 소규모 응용 프로그램이나 단일 에이전트 도구에는 과도할 수 있습니다.

Braintrust – 프롬프트 회귀 안전망

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

실제 시나리오

  • 상황: 엔지니어 팀이 “질문에 답변” 프롬프트(케이스 A)를 더 복잡한 500단어 시스템 지침(케이스 B)으로 업그레이드합니다.
  • 문제: 케이스 B의 프롬프트를 개선하면 케이스 A가 깨질 수 있습니다.
  • 해결책: Braintrust를 사용하여 완벽한 예시(예: N = 50)로 구성된 골든 데이터셋을 생성하고, 팀이 프롬프트를 업데이트할 때마다 사이드 바이 사이드 비교를 실행합니다.
  • 예상 결과: 각 골든 데이터셋( N = 50 )에 대한 차이 보고서가 생성되어, 프롬프트 업데이트에서 어떤 경우가 개선되었는지 또는 악화되었는지 정확히 보여줍니다.

장점

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

단점

  • 사유/SaaS 중심(그러나 오픈 소스 구성 요소가 있습니다).
  • DeepEval 또는 Ragas와 비교하여 내장된 심층 기술 지표가 적습니다.

まとめ

적절한 평가 프레임워크와 함께 처리된 경우, RAG는 사용자 질의와 가장 관련이 있는 컨텍스트를 제공하기 위한 경쟁력 있는 도구가 될 수 있습니다.

구현 전략: 지표를 실패 지점에 매핑

한 가지 해결책이 모든 경우에 적합한 것은 아니지만, 표 2는 이 기사에서 다룬 각 FP에 대해 어떤 평가 지표를 적용해야 하는지 보여줍니다:

실패 지점 평가 지표 아이디어 기능 사용
FP1: 컨텐츠 없음 RAGAS 충실도 / 답변 정확성
FP2: 상위 문서 누락 TruLens 컨텍스트 재현율 / 컨텍스트 정확도
FP3: 통합 Arize Phoenix 검색 추적 및 대기 시간 분석
FP4: 추출 안됨 DeepEval 충실도 / 컨텍스트 재현율
FP5: 잘못된 형식 DeepEval G-Eval(사용자 정의 루브릭)
FP6: 특이성 Braintrust 수동 평가 및 사이드 바이 사이드 평가
FP7: 불완전한 RAGAS 답변 관련성

표 2. 실패 지점 완화 매트릭스 – 어떤 도구가 어떤 FP를 해결합니까?

DeepEvalRAGAS는 데이터 무결성 실패(FP1, FP4, FP7)를 측정하기 위해 충실도 지표를 활용할 수 있습니다.

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

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

사용자 경험 실패의 경우, DeepEval은 사용자 경험 실패를 평가하기 위한 사용자 정의 지표를 생성할 수 있으며, Braintrust는 근거 데이터셋 비교에 탁월합니다.

Kuriko IWAI๋Š” Kernel Labs์˜ ์‹œ๋‹ˆ์–ด ML ์—”์ง€๋‹ˆ์–ด๋กœ, ML ์—ฐ๊ตฌ๋ฅผ ์ž๋™ํ™”๋œ ์ƒ์‚ฐ ์ค€๋น„ ํŒŒ์ดํ”„๋ผ์ธ์œผ๋กœ ์ „ํ™˜ํ•˜๋Š” ์—ฐ๊ตฌ ๋ฐ ์—”์ง€๋‹ˆ์–ด๋ง ํ—ˆ๋ธŒ์—์„œ ์ผํ•ฉ๋‹ˆ๋‹ค.
ๅฝผๅฅณ๋Š” ML ์‹œ์Šคํ…œ ๊ตฌ์ถ•์„ ์ „๋ฌธ์œผ๋กœ ํ•˜๋ฉฐ, ์ƒ์„ฑ์  AI ์•„ํ‚คํ…์ฒ˜, ML ๊ณ„๋ณด, ๊ณ ๊ธ‰ NLP์— ์ค‘์ ์„ ๋‘๊ณ  ์žˆ์Šต๋‹ˆ๋‹ค.
๋™๋‚จ์•„์‹œ์•„ ์ „์—ญ์—์„œ ์ œํ’ˆ ์†Œ์œ ๊ถŒ์— ๋Œ€ํ•œ ๊ด‘๋ฒ”์œ„ํ•œ ๊ฒฝํ—˜์„ ๋ณด์œ ํ•˜๊ณ  ์žˆ๋Š” Kuriko๋Š” ๊ธฐ์ˆ  ์‹คํ—˜์„ ๋น„์ฆˆ๋‹ˆ์Šค ๊ฐ€์น˜์™€ ์ผ์น˜์‹œํ‚ค๋Š” ๋ฐ ํƒ์›”ํ•ฉ๋‹ˆ๋‹ค.
ํ˜„์žฌ Indeed์˜ ํŒ€๊ณผ ํ˜‘๋ ฅํ•˜์—ฌ ์ž๋™ํ™” ํŒŒ์ดํ”„๋ผ์ธ์„ ๊ตฌ์ถ• ์ค‘์ž…๋‹ˆ๋‹ค.