RAGAS와 하네스 엔지니어링
RAGAS는 RAG 시스템을 더 적절하게 평가하기 위해 다음 지표들을 봅니다.
| RAGAS 지표 | 평가 질문 |
|---|---|
| Faithfulness | 답변이 검색 문서에 근거했는가? |
| Answer Relevancy | 답변이 질문에 직접 답했는가? |
| Context Precision | 검색 결과 중 관련 문서가 상위에 잘 왔는가? |
| Context Recall | 정답에 필요한 정보를 빠뜨리지 않고 검색했는가? |
즉 BLEU/ROUGE는 주로 정답 문장과 답변 문장의 단어 겹침을 봅니다.
반면 RAGAS는 RAG 파이프라인의 핵심인 검색 품질과 답변 근거성을 나눠서 봅니다.
Context Precision / Recall이 낮다
→ 검색기를 의심한다.
Faithfulness가 낮다
→ 생성 프롬프트나 LLM을 의심한다.
Answer Relevancy가 낮다
→ 답변 형식, 질문 이해, 최종 프롬프트를 의심한다.
정리
| 지표 | 측정 | 낮으면 |
|---|---|---|
| Faithfulness | 답변이 문서에 근거 | 환각 발생 |
| Answer Relevancy | 답변이 질문에 답 | 동문서답 |
| Context Precision | 검색 결과 관련성 | 검색 품질 ↓ |
| Context Recall | 검색 완전성 | 검색 누락 |
지표는 하나씩 보지 말고 조합해서 본다
RAGAS 점수는 개별 지표보다 조합해서 볼 때 더 유용합니다.
| Faithfulness | Relevancy | Precision | Recall | 해석 |
|---|---|---|---|---|
| 낮음 | 높음 | 높음 | 높음 | 검색은 잘됐지만 LLM이 문서 밖 내용을 생성 |
| 높음 | 낮음 | 높음 | 높음 | 문서에 근거했지만 질문에 직접 답하지 않음 |
| 낮음 | 낮음 | 낮음 | 낮음 | 검색과 생성 모두 문제 |
| 높음 | 높음 | 낮음 | 높음 | 필요한 정보는 있지만 무관 문서가 많음 |
| 높음 | 중간 | 높음 | 낮음 | 필요한 정보 일부를 검색하지 못함 |
왜 LLM-as-Judge가 필요한가
LLM 답변은 정답 표현이 하나로 고정되지 않습니다.
예를 들어 다음 세 답변은 모두 의미상 정답입니다.
- 휴가는 연 15일입니다.
- 연차는 15일 제공됩니다.
- TechCorp 직원은 기본적으로 연 15일의 휴가를 받습니다.
문자열 비교만 하면 두 번째와 세 번째는 오답처럼 보일 수 있습니다. 하지만 사람은 모두 같은 의미라고 판단합니다.
LLM-as-Judge는 이런 의미 기반 평가를 자동화하기 위해 사용합니다.
즉, LLM-as-Judge는 단순히 “AI가 AI를 평가한다”가 아니라, 사람이 하던 주관적 품질 평가를 어느 정도 자동화하는 방법입니다.
4-1. LLM-as-Judge가 가능한가? (10분)
“LLM이 LLM을 평가한다고? 신뢰할 수 있나?”
연구·실무 결과:
- 강한 평가 모델(
gpt-5등)이 평가하면 사람 평가와 높은 상관을 보일 수 있음 - 단순한 정답 매칭보다 의미 평가에 강함
- 단점: 모델의 편향 (자기 답을 더 좋게 평가하는 경향, 길이 편향 등)
사용 가이드
✅ OK
- 의미 기반 평가 (정답이 다양한 표현)
- 답변 품질·관련성·완성도
- 안전성·도메인 이탈
⚠️ 주의
- 사실 검증 (학습 시점 이후 사실은 모름)
- 미묘한 정확도 (소수점 계산 등)
- 자기 모델 평가 (편향)
LLM-as-Judge가 좋은 이유
LLM-as-Judge의 가장 큰 장점은 평가 속도입니다.
사람이 답변 1,000개를 읽고 평가하려면 시간이 오래 걸립니다. 하지만 LLM-as-Judge를 사용하면 같은 평가 기준으로 빠르게 초벌 평가를 할 수 있습니다.
현업에서는 보통 다음처럼 사용합니다.
- LLM-as-Judge로 대량 자동 평가
- 낮은 점수 또는 애매한 케이스만 사람이 샘플 검토
- 실패 사례를 평가셋에 추가
- 프롬프트나 모델을 수정한 뒤 다시 평가
이렇게 하면 사람이 모든 답변을 직접 보지 않아도, 품질이 낮은 영역을 빠르게 찾을 수 있습니다.
그룹 AI 개발자용 CLAUDE.md 만들기
이제 프로젝트 루트에 CLAUDE.md를 만듭니다.
Claude Code에 아래처럼 요청합니다.복사
이 프로젝트를 위한 CLAUDE.md 파일을 만들어줘. 아래 내용을 그대로 포함해줘.
# Group AI Development Project
## Project Context
- 이 프로젝트는 그룹 내 AI 서비스, RAG 에이전트, LangGraph 에이전트, 평가 자동화 개발을 위한 프로젝트다.
- 실제 계열사 내부 데이터가 없을 때는 반드시 mock data, sample data, public data를 사용한다.
- 특정 계열사의 정책, 수치, 내부 시스템 정보를 근거 없이 만들어내지 않는다.
- 사용자가 제공한 문서, 코드, 데이터, 승인된 도구 결과를 우선 근거로 사용한다.
## Security and Data Rules
- API key, token, secret, credential은 코드나 문서에 직접 쓰지 않는다.
- 개인정보, 임직원 정보, 고객 정보, 영업비밀은 예제에 실제값으로 넣지 않는다.
- 로그, trace, 테스트 출력에 민감정보가 남지 않게 마스킹한다.
- 외부 서비스 전송이 필요한 작업은 사용자가 제공한 설정과 승인된 도구 범위 안에서만 수행한다.
- 불확실한 내부 규정은 추측하지 말고 "확인 필요"로 표시한다.
## AI Agent Development Rules
- 기존 프로젝트의 프레임워크와 폴더 구조를 우선 따른다.
- 한 번에 하나의 기능 또는 하나의 버그만 수정한다.
- RAG 답변은 근거 문서 또는 출처를 함께 제시하도록 설계한다.
- Tool calling 결과와 모델 추론을 구분해서 다룬다.
- Guardrail, fallback, error handling을 사용자 경험의 일부로 설계한다.
- 모델 출력이 업무 의사결정에 쓰일 수 있으면 평가 데이터셋과 회귀 테스트를 함께 만든다.
## Evaluation Rules
- 기능 변경 후에는 가능한 경우 test, lint, build, smoke test 중 하나 이상을 실행한다.
- RAG 또는 Agent 품질 변경은 샘플 질문 세트로 전후 비교한다.
- 낮은 점수, hallucination, 근거 누락, 개인정보 노출 가능성은 progress.md에 기록한다.
- LangSmith 또는 유사 tracing 도구가 설정되어 있으면 실행 결과 링크나 experiment 이름을 기록한다.
## Working Loop
- 작업 전 tasks.json과 progress.md를 먼저 읽는다.
- pending 작업 하나만 선택한다.
- 선택한 작업을 구현한 뒤 scripts/verify.sh를 실행한다.
- 검증이 실패하면 원인을 읽고 다시 수정한다.
- 검증이 통과한 뒤에만 작업을 done으로 표시한다.
- 마지막에는 변경 파일, 실행 명령, 검증 결과, 남은 리스크를 progress.md에 기록한다.
## Response Rules
- 항상 한국어로 답변한다.
- 불확실한 내용은 단정하지 않는다.
- 보안상 실제값을 넣으면 안 되는 곳은 <REDACTED> 또는 예시값을 사용한다.
- 최종 답변에는 변경 파일과 검증 결과를 짧게 포함한다.
