Component Evaluation - 답변에 필요한 문서를 잘 가져왔는가?
개요
이번 강의는 AI 에이전트가 답변에 필요한 문서를 제대로 가져왔는지를 평가하는 Component Evaluation을 다룹니다.
기존의 답변 정확도 평가는 유지하면서, 여기에 문서 검색/선택 평가자를 추가해 한 번의 실행으로 여러 평가를 동시에 수행하는 방법을 설명합니다.
평가 설계의 핵심
1. 평가자(Evaluator)를 여러 개 추가할 수 있음
•
evaluate는 evaluators 리스트를 받습니다.
•
여기에 새로운 평가자를 추가하면, Wrapper는 한 번만 실행하면서도 복수의 평가를 동시에 돌릴 수 있습니다.
•
이번 실습에서는:
◦
기존의 답변 정확도 평가
◦
새로 추가하는 소스 문서 적합성 평가
를 함께 수행합니다.
2. 문서 이름 비교는 LLM 대신 Python으로 처리
•
비교 대상이 문서 이름(String) 이므로,
•
굳이 LLM을 호출해 토큰 비용을 쓰지 않고
•
Python 문자열 비교로 평가합니다.
•
결과는 Binary(0/1) 형태로 처리합니다.
◦
일치하면 1
◦
불일치하면 0
평가 데이터의 구조 차이
기존 정확도 평가
•
사용 데이터:
◦
Input
◦
Output
◦
Reference Output
•
의미:
◦
Input: 골든 데이터셋의 질문
◦
Reference Output: 골든 데이터셋의 정답
◦
Output: 에이전트의 실행 결과
문서 가져오기 평가
•
사용 데이터:
◦
example
◦
agent output
•
이유:
◦
지금 평가하려는 것은 정답 생성 능력이 아니라,
◦
에이전트가 답변에 필요한 문서를 잘 가져왔는지이기 때문입니다.
•
따라서 골든 데이터셋의 메타데이터에 저장된 source 문서와
에이전트가 실제로 사용한 문서를 비교합니다.
LangSmith에서의 데이터 활용
메타데이터에 source 저장
•
골든 데이터셋을 업데이트할 때,
•
각 샘플에 메타데이터(metadata) 필드를 두고
•
그 안에 source 문서 정보를 넣어둡니다.
평가 시 source 추출
•
평가는 example의 metadata에서 source를 꺼내는 방식으로 진행합니다.
•
즉, 정답 텍스트 자체보다 어떤 문서를 참조했는지가 중요합니다.
에이전트 출력에서 문서 정보 가져오기
에이전트 실행 결과에서 source를 확인하는 방식은 상황에 따라 다릅니다.
1. FAQ가 true인 경우
•
FAQ 문서를 반환하면 되므로 비교가 단순합니다.
•
즉, FAQ == true라면 FAQ 문서가 반환되었는지만 보면 됩니다.
2. FAQ가 false인 경우
•
에이전트가 참조한 문서가 여러 형태로 들어올 수 있어,
•
단순 문자열/JSON 파싱이 어려운 경우가 있습니다.
•
이때는 이전 tool message에서 getDocumentName 같은 도구 호출 결과를 확인해
문서 이름을 추출합니다.
비교 로직의 예
•
check_faq 메시지인지 확인
•
메시지 content가 true인지 문자열 비교
•
true면 특정 FAQ 문서 반환
•
아니면 get_document_name 도구의 실행 결과를 사용
•
이후 예상 source와 실제 source를 비교하여 일치 여부를 판단
평가 방식
Binary 판정
•
실제 가져온 문서가 정답 source와 일치하면 1
•
일치하지 않으면 0
결과 해석
•
문서를 잘 가져왔지만 답변이 부정확할 수도 있고,
•
반대로 문서 선택은 틀렸는데 답변은 우연히 맞을 수도 있습니다.
•
따라서 답변 정확도 평가와 문서 검색 평가를 함께 봐야 합니다.
실습 중 발견한 문제와 수정
1. 문서는 잘못 가져왔지만 답변은 맞는 경우
•
어떤 케이스에서는 source 평가가 낮게 나왔지만,
•
답변 정확도는 높게 나오는 상황이 있었습니다.
•
원인 분석 결과:
◦
골든 데이터셋의 정답 source가 너무 좁게 지정되어 있었고,
◦
실제로는 여러 문서에 같은 내용이 존재했습니다.
2. 골든 데이터셋 수정
•
이런 경우는 에이전트만 고치기보다,
•
골든 데이터셋의 source 기준을 수정해야 합니다.
•
예를 들어:
◦
legal and compliance
◦
hr policy
둘 중 하나를 참조해도 정답으로 인정하도록 변경할 수 있습니다.
3. 평가 기준 완화
•
actual source가 ground truth 후보들 중 하나에 포함되면 성공으로 처리하도록 수정합니다.
•
즉, 하나의 정답만 강제하지 않고 허용 가능한 source 후보를 복수로 둡니다.
정확도 점수 변동과 해석
점수가 흔들리는 이유
•
프롬프트를 바꾸지 않았는데도 점수가 달라질 수 있습니다.
•
이는 주로 모델의 비결정성 때문입니다.
•
특히:
◦
temperature
◦
모델 자체의 일관성 한계
가 영향을 줍니다.
핵심 메시지
•
100% 정확도를 목표로 할 필요는 없습니다.
•
평가 점수는 항상 약간의 변동이 있을 수 있으므로,
•
오버피팅이나 과도한 튜닝에 주의해야 합니다.
실습 흐름 요약
1.
기존 정확도 평가자를 유지한다.
2.
문서 source 비교 평가자를 추가한다.
3.
골든 데이터셋의 metadata에서 source를 읽는다.
4.
에이전트 실행 결과에서 실제 참조 문서명을 추출한다.
5.
두 값을 비교해 0/1 평가를 수행한다.
6.
필요하면 골든 데이터셋의 source 기준을 수정한다.
7.
결과를 확인하며 답변 정확도와 문서 검색 품질을 함께 분석한다.
결론
이 강의의 핵심은 답변이 맞는가뿐 아니라, 그 답변을 만들기 위해 필요한 문서를 제대로 가져왔는가를 별도로 평가해야 한다는 점입니다.
즉, e2e 평가만으로는 놓칠 수 있는 문제를 Component Evaluation으로 보완합니다.
또한 정답 문서는 하나로 고정하지 말고, 실제 상황에 맞게 허용 가능한 source 후보를 유연하게 설계하는 것이 중요합니다.
