개요
Struct4Search의 테스트는 코드 한 부분이 맞는지만 확인하는 검사와, 실제 문서를 넣고 질문에 답하기까지 전 과정을 확인하는 E2E 평가로 나뉩니다. 이 페이지에서는 E2E 평가가 필요한 이유, 한 번의 평가가 어디까지 실행되는지와 목적에 맞는 평가 범위를 설명합니다.
E2E 평가가 필요한 이유
파싱, 검색과 답변 코드의 개별 테스트가 모두 통과해도 실제 서비스는 다음과 같은 이유로 실패할 수 있습니다.
- 문서에 사용한 Embedding 모델과 질문에 사용한 모델이 다릅니다.
- OpenSearch에는 데이터가 있지만 검색 pipeline이나 index 설정이 맞지 않습니다.
- 검색은 되지만 Reader에 전달할 원문이나 Citation 정보가 빠집니다.
- 모델 서버는 실행 중이지만 profile의 모델 이름, 주소 또는 입력 길이와 맞지 않습니다.
- 인덱싱 결과는 만들어졌지만 API가 다른 index를 조회합니다.
E2E 평가는 이 연결을 따로 추측하지 않습니다. 원본 문서를 새로 처리한 뒤 실제 검색·답변 경로에 평가 질문을 보내고, 최종 답변과 Citation까지 확인합니다.
한 번의 E2E 평가에서 하는 일
평가 범위에 따라 문서와 질문 수는 달라지지 만 실행 순서는 같습니다.
- 사용할 profile, 모델 서버, PostgreSQL과 OpenSearch가 준비되었는지 확인합니다.
- 평가 문서와 질문 파일의 개수와 해시를 확인합니다. 승인된 평가 자료와 다르면 시작하지 않습니다.
- 운영 데이터와 분리된 OpenSearch index와 PostgreSQL 공간을 만듭니다.
- 원본 PDF를 파싱하고 청킹, NER, Metadata, KG, 검색표현과 인덱싱까지 실행합니다.
- 평가 질문을 실제
QueryService에 보내 Hybrid 검색, RRF, 원문 선택과 답변 생성을 실행합니다. - API 응답의 답변, Citation과 원본 문서 연결이 올바른 형식인지 확인합니다.
- 검색 순위를 정답 문서와 비교해 검색 점수를 계산합니다. 답변 점수가 준비된 경우에는 검색 점수와 함께 비교 결과를 정리합니다.
- 평가에 사용한 임시 검색·데이터베이스 자원을 정리하고 결과 파일을 남깁니다.
따라서 E2E의 PASS는 단순히 서버가 켜졌다는 뜻이 아닙니다. 선택한 범위의 문서 처리와 질문 실행이 끝났고, 필요한 결과 파일과 API 응답 형식이 확인되었다는 뜻입니다. 다만 답변 내용의 정확도까지 통과했다는 뜻인지는 해당 실행에 독립 답변 점수가 포함되었는지 함께 확인해야 합니다.
목적에 맞는 평가 범위
| 범위 | 사용하는 경우 | 확인하는 내용 |
|---|---|---|
| 문서 1건 | 설치 직후 또는 서비스 연결을 바꾼 직후 | 한 문서가 끝까지 인덱싱되고 실제 질문에 답변과 Citation을 반환하는지 |
| 문서 5건 | 여러 문서 형식과 실패·복구 동작을 빠르게 확인할 때 | 고정된 5문서의 인덱싱, 검색, 답변과 실행 기록이 일관적인지 |
| 100문서·100질의 | 코드·모델·검색 설정을 바꾼 뒤 전체 평가 전에 확인할 때 | 작은 고정 범위에서 검색 순위와 답변·Citation 경로가 이전보다 나빠지지 않았는지 |
| 2,567문서·200질의 | 배포 전 최종 확인 | 전체 검색 대상에서 검색·답변 품질과 회귀 여부를 확인하는지 |
한 문서와 5문서 E2E는 연결과 실행 안정성을 빠르게 확인하는 데 적합합니다. 검색 품질을 판단하려면 100문서 또는 전체 문서 평가를 사용합니다. 전체 문서 평가는 실행 시간과 GPU 사용량이 크므로 모든 작은 수정마다 실행하지 않습니다.
E2E 결과와 품질 점수의 차이
E2E 실행에는 두 종류의 판정이 함께 들어갈 수 있습니다.
| 판정 | 확인하는 것 | 계산 방법 |
|---|---|---|
| 실행 판정 | 모든 문서와 질문이 처리되고 답변·Citation·원본 연결 형식이 올바른지 | 프로그램이 결과 파일과 API 응답을 검사 |
| 검색 품질 | 필요한 문서를 상위 검색 결과에서 찾았는지 | 실제 검색 순위를 qrels.jsonl의 정답 문서와 비교 |
| 답변 품질 | 정답의 필 수 내용을 빠뜨리거나 잘못 답하지 않았는지 | 후보 답변을 정답과 비교한 독립 평가 점수 0, 1, 2를 사용 |
답변 품질 평가는 LLM-as-Judge 방식으로 만들 수 있지만, struct4search-evaluate가 평가 도중 유료 모델을 직접 호출하지는 않습니다. 독립 평가가 끝난 점수 파일을 입력받아 누락과 형식을 검사하고 평균과 설정된 비교 결과를 계산합니다. 자세한 흐름과 실제 예시는 평가셋에서 확인합니다.
가장 최근 E2E 결과
문서 전처리 단계의 Metadata 추출, Triple 추출과 검색표현 생성에 사용하는 LLM을 Qwen과 GPT로 바꾸어 검색·답변 성능을 비교했습니다. 문서 전처리 모델의 영향만 비교하기 위해 답변 생성 모델은 Qwen으로 고정했습니다.
| 검색 정확도 | QA 정확도 | 처리 시간 | 비용 | ||
|---|---|---|---|---|---|
| model | nDCG@10 | Recall@10 | QA Accuracy | ||
| Qwen | 0.4328 | 0.6035 | 0.595 | 8시간 36분 | 0원 (자체 GPU) |
| GPT | 0.4411 | 0.6570 | 0.645 | 8시간 31분 | $40 |
GPT 기반 문서 전처리가 Qwen보다 검색 정확도와 QA 정확도가 높았습니다. 전체 E2E 처리 시간은 비슷했지만 GPT 실행 시간에는 API Batch 대 기 시간이 포함되어 있어, 대기 시간을 제외한 실제 처리 속도는 더 빠를 것으로 보입니다.
변경한 부분에 따른 실행 범위
| 변경한 부분 | 작은 코드 검사 | 문서 한 건 E2E | 100문서 또는 전체 평가 |
|---|---|---|---|
| 설정 스키마·입출력 형식 | 필수 | — | — |
| 서비스 주소·모델 | 필수 | 필수 | 필수 |
| 파싱·청킹·NER·KG | 필수 | 필수 | 필수 |
| Metadata·검색표현 프롬프트 | 필수 | 필수 | 필수 |
| 검색 파라미터·점수 통합 | 필수 | — | 필수 |
| Context·답변 프롬프트 | 필수 | — | 필수 |
| 동시 실행 수·서비스 시작 방식 | 필수 | 필수 | — |
평가 자료의 구성은 평가셋, 실제 명령과 결과 파일·점수의 의미는 평가 실행과 결과 확인에서 확인합니다.