faithfulness가 1인데 answer_correctness가 0.39라면 모델이 계산을 틀린 것일까?

점수만으로는 알 수 없다. 제공된 실습 자료를 대조하면 이 질문이 더 분명해진다. README는 해당 행을 계산 실패라고 설명하지만, 노트북에 저장된 답변은 참조 정답과 같은 계산 결과를 내고 있다.

이번 글은 Task-3.ipynb와 README.md를 검토한 기록이다. 새 평가를 실행하지 않았으며, 제공된 점수의 원인을 확정하지 않는다.

먼저 확인 가능한 자료의 범위를 정한다

항목 첨부 자료에서 확인한 내용
평가 질문 5개
생성·평가 모델 코드 둘 다 amazon.nova-lite-v1:0
평가용 임베딩 코드 amazon.titan-embed-text-v2:0
생성 기록 5개 질문의 답변과 참조 정답이 저장됨
점수 README에 5행 표가 있음
Ragas 실행 버전 확정할 lock 파일이나 전체 환경 기록 없음
평가 완료 기록 평가 셀의 execution_count가 비어 있고 상세 판정도 저장되지 않음

설명문에는 다른 생성 모델 이름이 남아 있지만 실행 코드에는 Nova Lite가 지정돼 있다. 글에서는 코드에서 확인한 설정을 기준으로 설명한다.

객체를 생성용과 평가용으로 둘로 나눴다고 서로 독립적인 평가자가 되는 것도 아니다. 같은 모델 계열의 오류나 선호가 겹칠 수 있다.

점수표와 저장 답변을 동일 실행의 산출물로 연결하는 run ID도 없다. 따라서 둘을 대조해 의문점을 찾을 수는 있어도, 해당 점수가 정확히 그 답변을 채점한 결과라고 확정할 수는 없다.

지표마다 비교 대상이 다르다

노트북은 이전 형태의 Ragas import와 데이터 열 이름을 사용한다. 아래 설명은 해당 명칭을 이해하기 위한 Ragas v0.1.21 문서 기준이며, 노트북의 실제 설치 버전이 v0.1.21이었다는 뜻은 아니다.

지표 무엇을 비교하는가 피해야 할 해석
faithfulness 답변의 주장을 제공 문맥으로 뒷받침할 수 있는지 1이면 현실에서도 완전히 정확
answer_relevancy 답변에서 만든 질문과 원 질문의 의미 관련성 등 질문에 관련 있으면 사실도 정확
answer_correctness 참조 정답과 답변의 사실·의미 유사성 낮으면 반드시 계산 오류
context_precision 참조 정답 관련 근거가 검색 순위의 앞에 있는지 0.7이면 문서의 70%가 관련
context_recall 참조 정답의 주장 중 문맥으로 설명 가능한 비율 낮으면 곧바로 생성의 추론 실패
context_entity_recall 참조 정답의 엔티티가 문맥에 얼마나 포함되는지 문서의 정보 밀도를 직접 측정

faithfulness는 답변의 주장을 검사하고 context_recall은 참조 정답의 주장을 검사한다. 서로 다른 집합을 보므로 하나가 높고 다른 하나가 낮아도 모순은 아니다. 답변이 검색된 일부 정보만 충실히 말하면서 정답에 필요한 나머지 정보를 누락할 수 있다.

answer_similarity도 정확한 숫자·부정 표현·시점의 일치를 보장하지 않는다. 또한 노트북의 Aspect Critique correctness와 answer_correctness는 다른 평가다. 전자가 1이고 후자가 낮다고 같은 산식이 충돌한 것으로 해석하면 안 된다.

README의 5행을 다시 읽는다

다음은 제공된 수치를 소수 셋째 자리까지 반올림한 표다. 새로 측정한 값이나 모델의 일반 성능이 아니다.

행 faithfulness relevancy context precision context recall answer correctness
0 0.800 0.973 1.000 1.000 0.571
1 0.750 0.793 1.000 1.000 0.620
2 1.000 0.995 1.000 1.000 0.796
3 1.000 0.851 0.700 0.333 0.391
4 1.000 0.880 0.000 0.400 0.787

행 0·1의 entity recall이 낮다고 “문서의 정보 밀도가 낮다”고 확정할 수 없다. 어떤 엔티티를 추출했는지와 참조 정답의 범위를 확인해야 한다. 행 2의 일부 지표가 높더라도 “완벽한 RAG”라는 결론은 과하다.

행 4의 precision이 0이라는 이유만으로 “모델이 자체 지식으로 보완했다”고 추정하는 것도 근거가 부족하다. 검색 결과와 답변의 주장, 평가자의 관련성 판정을 함께 확인해야 한다.

계산 실패라는 설명은 저장 답변과 맞지 않는다

행 3에 대응하는 것으로 보이는 질문은 두 연도 수치의 증감률을 묻는다. 저장된 답변과 참조 정답은 모두 같은 두 값으로 계산해 37.14%를 제시한다. 산술을 독립적으로 확인해도 그 결과와 일치한다.

즉, 현재 자료로는 “계산 오류 때문에 correctness가 0.39”라고 설명할 수 없다. 낮은 점수의 원인은 열려 있다.

  • README와 답변이 다른 실행에서 만들어졌을 수 있다.
  • 평가용 문맥이 생성에 사용한 문맥과 다를 수 있다.
  • 참조 정답의 주장 분해나 평가 모델의 판정이 영향을 줬을 수 있다.
  • 구현 버전과 실제 적용 설정이 예상과 달랐을 수 있다.

이 중 무엇이 실제 원인인지는 평가 상세 기록 없이 결정하지 않는다. 적절한 결론은 “점수와 저장 출력의 관계를 확인하고, 생성·검색·평가 단계를 분리해 점검해야 한다”이다.

점수 전에 평가 파이프라인을 점검한다

이전 글에서 다룬 것처럼 원본은 생성 후 평가용 검색을 한 번 더 수행한다. 성공한 답변 수만큼 질문 배열의 앞부분을 잘라 연결하는 코드도 있어, 중간 실패가 발생하면 행 정렬이 깨질 수 있다. 저장된 실행은 5개 모두 성공했으므로 실제 행 오류가 있었다고 단정하지 않는다.

또한 config_override라는 키워드를 전달했다는 사실만으로 생성 설정이 실제 모델 호출에 적용됐다고 볼 수 없다. 사용 중인 Runnable·모델 래퍼의 버전과 최종 요청을 확인해야 한다.

README의 datasets==2.19.0, pyarrow==14.0.2 설치 안내는 특정 환경의 해결 기록이다. Python·Ragas·LangChain·NumPy까지 포함한 호환성을 보장하는 전체 환경 명세는 아니다. 모든 경고를 숨기거나 호환 함수를 덧붙여 실행만 통과시키면 평가 실패를 놓칠 수 있다.

기존 환경을 재현할 때는 버전을 기록하고, 새 환경으로 옮길 때는 변경 전후 평가를 구분한다. 실패나 NaN을 0점 또는 성공으로 임의 치환하지 않는다.

개선 방법은 원인에 따라 선택한다

프롬프트 → RAG → 파인튜닝 → 프리트레이닝을 무조건 순서대로 밟을 필요는 없다. 이 자료에는 파인튜닝이나 사전학습을 실행한 결과도 없다.

관찰한 문제 먼저 검토할 조치
필요한 근거가 검색되지 않음 수집·청킹·필터·검색 순위
근거는 있으나 조건을 잘못 적용 프롬프트·문맥 구성·출력 검증
숫자 연산이 틀림 계산기나 결정적 코드로 산술 분리
특정 작업의 동작이 반복적으로 불안정 충분한 사례를 확보한 뒤 파인튜닝 필요성 검토
평가 점수와 원본 판정이 어긋남 평가 입력·기준·평가자·버전 점검

검색의 영향을 보려면 사람이 확인한 충분한 근거를 제공하는 대조 조건을 만들 수 있다. 이때도 생성 변동을 고려해야 하며 한 번 정답을 냈다는 이유만으로 인과관계를 확정하지 않는다.

5개 질문은 실습을 이해하는 데 유용하지만 운영 품질을 대표하기에는 범위가 좁다. 점수를 높이는 것보다 실패 사례와 근거를 확인할 수 있는 평가 기록을 만드는 것이 먼저다.

다음 글은 Guardrails가 무엇을 차단했고 무엇은 보장하지 않는지를 다룬다.

참고 자료