RAGAS 평가 2026 — RAG 평가 지표 4개가 무엇을 재고, 몇 점을 합격으로 적나

RAGAS 는 「답이 맞았나」를 재는 도구가 아니다. RAG 응답 하나를 네 조각으로 갈라서, 틀린 책임이 검색에 있는지 생성에 있는지를 가린다. 그래서 점수가 낮게 나왔을 때 고칠 곳이 바로 지목된다 — 임베딩을 바꿀 일인지, 프롬프트를 바꿀 일인지, 애초에 그 문서가 없는 것인지.

결론부터 말하면, RAGAS 를 발주·검수에 쓸 때 실제로 갈리는 것은 지표 선택이 아니라 셋이다. ① 골든셋(정답이 붙은 질문 묶음)을 누가 만드나 ② 점수를 내는 심판이 LLM 이라는 사실을 계약에 어떻게 적나 ③ 몇 점을 합격으로 볼 것인가. 지표 설명은 공식 문서에 다 있고, 프로젝트가 깨지는 곳은 이 셋이다.

네 지표가 각각 무엇을 재나

RAGAS 의 핵심 지표는 네 개다. 이름이 비슷해서 섞이는데, 보는 대상이 서로 다르다.

읽는 순서가 중요하다. 위 두 개는 생성 단계, 아래 두 개는 검색 단계다. 그리고 아래 두 개가 깨져 있으면 위 두 개를 올리려는 모든 시도가 헛수고다 — 없는 문맥에서 충실한 답은 나올 수 없다.

네 지표를 두 축으로 접으면 책임이 갈린다

발주처가 외주 업체와 다툴 때 실제로 필요한 것은 네 숫자가 아니라 책임 구분이다. 같은 네 지표를 이렇게 접어 두면 회의가 짧아진다.

여기서 한 가지가 자주 빠진다. Context Recall 은 정답(ground truth)이 있어야 계산된다. 나머지 셋은 질문·문맥·답변만으로 계산되지만, 재현율은 「있어야 할 문맥」을 알아야 재는 값이다. 그래서 골든셋에 정답을 안 붙이면 네 지표 중 하나는 아예 측정 불가가 된다. 검수 기준에 네 지표를 다 적어 놓고 정답 데이터를 안 주는 발주가 흔하다.

점수를 내는 심판이 LLM 이다 — 그래서 흔들린다

RAGAS 의 점수는 규칙 기반 계산이 아니다. 대부분의 지표가 LLM 에게 판정을 물어서 얻는다. 「이 답변의 각 문장이 문맥에서 뒷받침되나」를 LLM 이 읽고 세는 식이다.

이 사실이 실무에 주는 영향은 셋이다.

• 같은 입력에 같은 점수가 안 나온다. 온도를 0 으로 둬도 완전히 고정되지 않는다. 그래서 단일 측정값으로 합격·불합격을 가르면 안 된다.
• 심판 모델을 바꾸면 점수대가 바뀐다. 검수 기준에 「faithfulness 0.85 이상」만 적고 심판 모델을 안 적으면, 업체가 점수가 잘 나오는 모델로 바꿔도 할 말이 없다.
• 심판 비용이 평가 비용의 거의 전부다. 아래 과금 단위에서 다시 본다.

그래서 숫자를 하나만 적는 대신 이렇게 적는다. 「골든셋 50문항, 심판 모델 고정, 3회 반복 측정, 평균과 표준편차를 함께 제출」. 표준편차를 같이 받으면 그 뒤로는 「0.83 과 0.85 는 다른 값인가」를 두고 싸울 일이 없다.

골든셋이 없으면 어떤 지표도 못 쓴다 — 50문항 만드는 절차

평가 이야기의 90%가 지표에 쏠려 있지만, 실제 공수는 골든셋에 있다. 없으면 평가 자체가 시작되지 않는다. 50문항을 만드는 순서는 이렇다.

1. 실제 질문을 모은다. 상상해서 쓰지 말고 운영 로그·고객센터 티켓·사내 문의에서 긁는다. 없으면 담당자 3명에게 각자 20개씩 쓰게 한다.
2. 유형별로 쪼갠다. 단순 조회 / 조건 비교 / 절차 안내 / 예외 처리 / 답할 수 없는 질문. 마지막 유형이 핵심이다 — 자료에 없는 것을 물었을 때 "모른다"고 답하는지 보는 문항이다.
3. 각 유형에서 10문항씩 고른다. 쉬운 것만 모이면 점수가 전부 높게 나와 변화가 안 보인다.
4. 정답과 근거 문서를 같이 적는다. 정답 문장 한두 줄 + 그 근거가 들어 있는 문서·페이지. 이게 Context Recall 의 입력이다.
5. 두 사람이 교차 검토한다. 한 사람이 쓴 정답은 그 사람의 해석이다. 두 사람이 다르게 적은 문항은 질문이 모호한 것이므로 문항을 고친다.

50문항이 적어 보이지만, 유형이 다섯이고 각 문항에 정답과 근거가 붙으면 사람 손으로 이틀은 간다. 발주 일정에 이 이틀을 안 넣으면 평가는 "다음 주에"로 밀리고, 그대로 검수 없이 넘어간다.

몇 점을 합격으로 적나

여기가 계약서에 실제로 들어가는 부분이다. 절대 점수를 한 줄 적는 방식은 거의 항상 실패한다. 데이터와 질문 난이도에 따라 달성 가능한 점수대가 달라서, 0.9 가 쉬운 프로젝트도 있고 0.7 이 벽인 프로젝트도 있다.

쓸 수 있는 형태는 셋이다.

실무에서 가장 잘 버티는 조합은 유형별 하한 + 기준선 대비다. 그리고 유형별 하한 중 「답할 수 없는 질문에서 환각 0건」은 거의 모든 프로젝트에 넣을 수 있다 — 데이터 난이도와 무관하게 "모른다"는 답은 가능해야 하기 때문이다.

하나 더. 네 지표를 모두 통과 조건으로 걸면 통과율이 생각보다 급하게 내려간다. 지표 하나하나가 90% 확률로 기준을 넘는다고 해도, 넷이 독립이면 동시 통과는 0.9⁴ = 약 66%다. 전부 AND 로 묶는 대신 핵심 지표 2개를 차단 조건으로, 나머지 2개를 보고 항목으로 두는 편이 분쟁이 적다.

전후 비교가 아니라 「바꾼 것 하나」로 재라

점수가 올랐다는 보고를 받으면 무엇을 바꿨는지 묻게 된다. 그런데 대개 임베딩 모델·청크 크기·top-k·리랭커·프롬프트를 같이 바꿔 놓는다. 그러면 올랐어도 어느 것이 효과였는지 모르고, 다음에 같은 처방을 쓸 수 없다.

• 한 번에 하나만 바꾼다. 청크 크기 → 측정, top-k → 측정.
• 검색 쪽 변경은 검색 지표로만 판정한다. 청크를 바꿨는데 faithfulness 가 올랐다면 우연일 가능성을 먼저 본다.
• 골든셋을 바꾸면 그 전후 점수는 비교 불가다. 문항을 추가했으면 기준선도 다시 잡는다. 이걸 안 지켜서 "개선됐다"가 "쉬운 문항이 늘었다"였던 경우가 흔하다.

과금 단위 — 평가 한 번에 돈이 얼마나 드나

금액은 분기마다 바뀌므로 단가가 아니라 호출 수로 센다. 그래야 모델 가격이 바뀌어도 계산이 살아 있다.

평가 1회의 심판 호출 수는 대략 문항 수 × 지표 수 × (지표당 호출 1~2) 다. 50문항·4지표면 200~400 호출이고, 분산을 보려고 3회 반복하면 600~1,200 호출이다. 여기에 답변을 생성하는 호출(문항 수만큼)이 따로 붙는다.

실무에서 이 숫자가 의미 있는 이유는, CI 에 평가를 붙일지 말지를 이 숫자가 결정하기 때문이다. 커밋마다 전체 골든셋을 돌리면 호출이 금방 쌓인다. 그래서 보통 이렇게 나눈다.

• 커밋마다: 10문항 스모크 세트 (호출 40~80)
• 배포 전: 50문항 전체 1회
• 월 1회·주요 변경 후: 50문항 3회 반복 + 표준편차

RAGAS 말고 무엇이 있나

RAG 평가 프레임워크는 RAGAS 하나가 아니다. 고르는 기준은 기능 목록이 아니라 「누가 결과를 볼 것인가」다.

선택 트리는 짧다. 평가를 CI 에 붙이는 것이 목적이면 DeepEval, RAG 내부 책임 구분이 목적이면 RAGAS, 이미 관측 도구를 쓰고 있고 가벼운 점검만 하면 그 도구의 평가 기능으로 시작한다. 셋을 다 깔 필요는 없다.

관측과 평가는 다른 일이다

현장에서 가장 자주 섞이는 둘이다. 관측(옵저버빌리티)은 "지금 무슨 일이 있었나"를 보고, 평가는 "그게 잘한 일이었나"를 판정한다. 관측 도구가 trace 를 쌓아 두면 평가의 입력이 생기고, 평가가 점수를 내면 관측 화면에서 낮은 점수의 trace 를 뒤져 볼 수 있다 — 서로의 입력이지 대체재가 아니다.

도구 선택 자체는 별개 결정이다. Langfuse·LangSmith·Phoenix 를 셀프호스팅·프레임워크 결합·과금 단위로 가른 비교는 LLM 모니터링 도구 비교에 정리했다. 평가를 그 도구 안에서 돌릴지 밖에서 돌릴지도 그쪽에서 다룬다.

모델 자체를 손보는 쪽으로 가기 전에 평가를 먼저 깔아야 하는 이유도 같다. LoRA·QLoRA 파인튜닝 비교처럼 가중치를 건드리는 작업은 되돌리기 어려운 변경이라, 기준선 점수가 없으면 좋아졌는지조차 말할 수 없다.

최소 경로 — 30분에 첫 점수 보기

도입을 결정하기 전에 우리 데이터로 숫자가 나오는지만 먼저 확인한다. 골든셋 50문항을 다 만들지 않아도 된다.

1. 질문 10개 + 정답 10개를 스프레드시트에 적는다        (20분)
2. 지금 돌고 있는 RAG 에 10개를 넣어 답변과
   검색된 문맥을 그대로 받아 적는다                      (5분)
3. 질문·문맥·답변·정답 네 열을 RAGAS 에 넣고
   네 지표를 한 번 돌린다                                (5분)
4. 네 숫자 중 **가장 낮은 것**을 본다 →
   검색 지표면 데이터·색인부터, 생성 지표면 프롬프트부터

여기서 나온 네 숫자는 합격 판정에 쓸 수 없다(문항 10개·1회 측정이다). 쓸 수 있는 것은 방향이다 — 어느 단계를 먼저 손댈지가 거의 항상 분명해진다.

흔한 실수 여섯 가지

1. 정답 없이 네 지표를 요구한다. Context Recall 은 계산이 안 된다.
2. 심판 모델을 안 적는다. 점수대가 모델에 따라 움직여 기준이 무의미해진다.
3. 1회 측정으로 합격을 가른다. 재실행하면 값이 달라진다.
4. 골든셋을 바꾸고 전후를 비교한다. 비교 불가인데 "개선"으로 보고된다.
5. 네 지표를 전부 AND 차단 조건으로 건다. 통과율이 급하게 내려간다(0.9⁴ ≈ 66%).
6. 「답할 수 없는 질문」을 골든셋에 안 넣는다. 환각을 재는 가장 싼 방법을 버리는 셈이다.

자주 묻는 질문

골든셋은 몇 문항이 적정인가? 시작은 50문항이면 충분하다. 유형 5개 × 10문항으로 잡고, 운영 로그가 쌓이면 실제로 틀린 질문을 우선 추가한다. 문항을 추가하면 기준선도 다시 잡는다.

점수가 0.9 면 좋은 건가? 그 자체로는 알 수 없다. 질문이 쉬우면 0.95 도 나온다. 같은 골든셋에서 전후를 보는 값이거나, 「답할 수 없는 질문에서 환각 0건」처럼 난이도와 무관한 조건이어야 판정에 쓸 수 있다.

평가를 외주 업체가 직접 돌려도 되나? 돌리는 것은 업체가 해도 되지만, 골든셋은 발주처가 쥐고 있어야 한다. 채점표를 만든 쪽이 시험도 만들면 점수는 올라가게 되어 있다. 최소한 정답과 근거 문서는 발주처가 확정한다.

지표를 직접 만들어도 되나? 업무 규칙이 분명한 영역(금액 계산, 코드 생성, 양식 채우기)은 규칙 기반 채점이 LLM 심판보다 싸고 안정적이다. 기계로 채점할 수 있으면 기계로 한다. LLM 심판은 "문장이 근거에 맞나"처럼 규칙으로 못 쓰는 판정에만 쓴다.

정리

• RAGAS 의 값은 네 지표를 두 축(검색 책임 / 생성 책임)으로 접었을 때 나온다. 검색 쪽이 깨져 있으면 생성 쪽을 올리려는 시도는 헛수고다.
• 점수는 LLM 심판이 매긴다. 심판 모델을 고정하고, 반복 측정하고, 표준편차를 같이 받는다.
• 골든셋이 공수의 대부분이다. 50문항·5유형·정답과 근거 포함, 사람 손으로 이틀. 일정에 넣는다.
• 합격 기준은 절대값 한 줄이 아니라 유형별 하한 + 기준선 대비로 적는다. 「답할 수 없는 질문에서 환각 0건」은 거의 언제나 넣을 수 있다.
• 비용은 단가가 아니라 호출 수로 센다. 50문항·4지표·3회면 600~1,200 호출이고, 이 숫자가 CI 에 붙일지를 결정한다.

RAG 품질을 지표로 분해하고 검수 기준까지 같이 설계하는 일은 지식그래프·RAG 구축에서 함께 진행한다.