LLM 성능은 나날이 좋아지고, RAG(검색 증강 생성) 파이프라인을 만드는 일도 그만큼 쉬워졌습니다. 문제는 그다음입니다. 대부분의 팀은 RAG 시스템을 만들고, 그럴듯해 보이는 답을 몇 번 확인한 뒤 “됐다”고 넘어갑니다. 그러다 사용자가 환각이나 빠진 맥락, 엉뚱한 조각을 맞닥뜨리고 나서야 문제를 알아챕니다.

이 간극을 메우려고 나온 게 RAGAS, TruLens, DeepEval 같은 평가 프레임워크입니다. 셋 다 RAG 품질을 재는 도구지만, 정작 무엇을 왜 재는지 들여다보면 서로 다른 철학으로 만들어졌습니다.

출처: RAG Evaluation Frameworks: RAGAS vs TruLens vs DeepEval – Analytics Vidhya

검색기와 생성기, 서로 다르게 실패한다

RAG 시스템에는 두 개의 축이 있습니다. 컨텍스트를 가져오는 검색기와, 그 컨텍스트로 답을 쓰는 생성기입니다. 둘 중 하나만 삐끗해도 최종 답은 틀리지만, 틀리는 방식은 서로 다릅니다. 검색기가 나쁘면 엉뚱하거나 불완전한 조각을 가져옵니다. 생성기가 나쁘면 좋은 컨텍스트를 받고도 무시한 채 환각을 일으키거나, 사실은 맞지만 도움이 안 되는 답을 씁니다.

번역 품질을 잴 때 쓰던 BLEU나 ROUGE 같은 전통적인 지표는 이 문제를 잡아내지 못합니다. 생성된 답과 정답 사이의 단어 겹침만 비교할 뿐, 모델이 실제로 근거에 충실했는지나 검색기가 제 역할을 했는지는 보지 않기 때문입니다. RAG 평가는 이 두 축을 따로, 또 함께 확인할 수 있는 지표가 필요했고, 그 자리를 메운 게 오늘 살펴볼 세 도구입니다.

RAGAS, 빠르게 자동으로 점수부터 낸다

RAGAS는 사람이 손으로 만든 정답 없이도 평가가 가능하다는 게 가장 큰 강점입니다. LLM을 심판으로 세워, 생성된 답을 검색된 컨텍스트 자체와 대조해 다음과 같은 지표들을 자동으로 채점합니다.

• Faithfulness — 답변이 실제로 근거한 진술로만 이루어졌는가
• Answer Relevance — 질문에 직접 답하고 있는가
• Context Precision — 가져온 조각들이 쓸데없는 내용 없이 답과 맞아떨어지는가

특히 눈에 띄는 기능은 테스트셋을 자동으로 만들어주는 부분입니다. 문서에서 조각을 뽑아 LLM으로 현실적인 질문과 정답, 더 어려운 변형까지 생성해줍니다. 보통 RAG 평가에서 가장 오래 걸리는 일이 라벨링된 테스트셋을 만드는 작업인데, 이 과정을 상당 부분 덜어주는 셈이죠.

다만 대부분의 지표가 LLM 심판에 의존하다 보니, 같은 걸 다시 돌려도 점수가 살짝씩 흔들리고 평가할 때마다 LLM 호출 비용이 추가로 듭니다. 프로토타입을 막 만들었을 때 빠르게 벤치마킹하거나, 검색기나 프롬프트 두 버전을 A/B 테스트하고 싶을 때 적합한 도구입니다.

TruLens, “왜 틀렸는지”를 추적한다

TruLens는 접근 자체가 다릅니다. 한 번 평가해서 리포트를 받는 게 아니라, RAG 애플리케이션에 계측을 심어 매 단계(무엇을 검색했는지, LLM이 뭘 봤는지, 뭘 생성했는지)를 계속 기록합니다. 이 로그가 점수의 근거가 됩니다.

핵심 개념은 “RAG 삼각형”입니다.

• 컨텍스트 관련성 — 검색된 컨텍스트가 질문과 얼마나 관련 있는지를 조각 단위로 채점
• 근거성 — 답변이 검색된 근거로 뒷받침되는지
• 답변 관련성 — 답변이 실제 질문에 부합하는지

TruLens가 다른 두 도구와 차별화되는 지점은 이 점수들을 다루는 대시보드입니다. 여러 실험 결과를 나란히 비교하고, 실패한 사례 하나를 파고들어 정확히 어느 조각이 관련 없었는지 확인하고, 프롬프트나 청크 크기를 바꿔가며 점수가 시간에 따라 어떻게 변하는지 추적할 수 있습니다.

빠른 점수 하나만 원한다면 RAGAS보다 설정이 번거롭습니다. 대신 프로덕션에서 RAG를 계속 운영하며 시간에 따른 품질 변화를 추적하고 싶은 팀, 프롬프트나 검색기를 반복해서 조정하며 무엇이 왜 바뀌었는지 보고 싶은 팀에 더 맞습니다.

DeepEval, 배포 전 유닛테스트처럼 돌린다

DeepEval은 RAG 평가를 아예 유닛테스트처럼 취급합니다. Pytest에 바로 꽂혀 들어가죠. 이미 배포 전에 자동 테스트를 돌리는 팀이라면, RAG 품질 검사를 별도의 노트북이나 대시보드가 아니라 같은 파이프라인 안에 끼워 넣을 수 있습니다.

답변이 질문에 실제로 답하는지, 모든 주장이 검색된 컨텍스트로 뒷받침되는지, 검색된 조각이 관련 있고 완전한지를 각각 점수화하고, 소스에 없는 주장을 잡아내는 환각 탐지 기능도 있습니다. 정해진 지표로는 부족한 도메인이라면 평가 기준을 자연어로 직접 정의해 LLM이 그 기준을 일관되게 적용하도록 만들 수도 있습니다. 테스트 케이스를 정의하고 통과 기준을 정한 뒤 돌리면, 기준을 밑도는 순간 마치 망가진 함수가 테스트를 실패하듯 그대로 실패 처리됩니다.

세 도구 모두 결국 같은 질문에 답하려 합니다. 내 RAG가 정말 작동하는지 어떻게 알 수 있는가라는 질문입니다. 다만 그 답을 빠른 점수 하나로 원하는지, 실패 원인을 계속 추적하고 싶은지, 배포 파이프라인의 자동 관문으로 쓰고 싶은지에 따라 셋 중 어느 걸 먼저 집어야 할지가 달라집니다.