RAG Retrieval PoC

01 / 문제와 범위

비슷한 문서가 검색돼도 답하면 안 되는 질문이 있었습니다.

팀 실행 환경에 등장하는 기술이 개인 기여로 읽히거나, 근거에 없는 기술 질문에 가까운 문서가 붙을 수 있습니다. 검색 순위만으로 답변을 허용하지 않고, 문서가 다루는 주제와 기여 범위를 별도로 확인하도록 구성했습니다.

실험 범위 — BM25 검색·답변 허용 규칙·개발 평가. 보존된 코드와 설정 동결 기록에서 어떤 조건을 확인했는지 볼 수 있습니다.

1. 질문주제·대상 확인
2. BM25 검색관련 근거 top-5
3. 범위 판단주제·기여·거절 조건
4. 답변 또는 보류허용 범위와 인용 연결

Vector DB나 생성 모델의 응답 품질을 평가한 시스템이 아니라, 검색과 답변 허용 범위를 검증하는 PoC입니다.

02 / 실패와 수정

첫 holdout 실패 9건 중 8건은 검색 뒤의 판단에서 생겼습니다.

1. 가장 가까운 근거를 무조건 채택하지 않도록 했습니다.

   주제를 뒷받침하는 단서가 없으면 답변 범위 카드를 고르지 않는 선택을 넣었습니다. '구축·운영' 같은 넓은 표현만으로 적용 범위를 넓히지 않았습니다.

2. 문자열 일치보다 명시된 기여 범위를 먼저 봤습니다.

   검색된 문구에 기술 이름이 있다는 이유로 개인 경험을 인정하지 않고, 근거 카드에 선언된 기여와 주제 지지를 확인했습니다. 범위 밖·근거 없는 주제·기여 미귀속을 별도 신호로 처리했습니다.

3. 검색을 바꾸는 대안도 측정하고 기각했습니다.

   질문을 나눠 검색 결과를 합치는 대안은 cross R@3가 0.857 → 0.714로 낮아졌습니다. top-5에 근거가 있어야만 범위 카드를 허용하는 대안도 경계 질문에서 필요한 판단을 놓쳤습니다.

   v2의 BM25 파라미터는 유지했습니다. 검색이 모든 질문에 일반화됐다는 결론은 아닙니다.

03 / 개발 평가

개발 평가 100건에서 설정 확정 기준을 충족했습니다.

개발 60건과 이미 확인한 holdout v1 40건을 합친 combined100입니다. 한 번 본 holdout을 개발에 사용했으므로, 이 결과를 새 질문의 성능으로 읽을 수는 없습니다.

04 / 남은 한계

찾지 못한 질문과 확인하지 않은 성능을 남겼습니다.

데이터 수집부터 학습까지의 기여를 함께 묻는 개발 문항 X08에서는 필요한 근거가 4위에 남았습니다. 질문을 나누는 검색으로도 해결하지 못했고, 한 문항만을 위한 튜닝은 하지 않았습니다.

v1에서 R@3가 개발 1.000 → holdout 0.800으로 낮아진 전례가 있습니다. 새로운 평가 세트(holdout v2)의 검증이 남아 있으므로 개발 기준 통과는 설정 동결의 근거로만 사용합니다.

검증 범위와 미검증 항목 — 검색 실패와 답변 범위 판단 실패를 나눠 분석한 과정, 기각한 대안, 개발 평가 결과입니다. 상용 RAG 운영·Vector DB 운영·RAGAS 활용 경험으로 확대하지 않습니다.

05 / 평가 기록

개발 결과와 남은 한계를 공개 요약으로 정리했습니다.

• 개발 평가표 · 기각 대안 · 남은 실패 →

동결 당시 기록에서 공개 가능한 결과와 조건을 발췌한 요약입니다. 원본 코드·평가 데이터 전체나 독립 재현 패키지는 제공하지 않습니다. unseen holdout v2 검증 전의 개발 결과입니다.