RAG 파라미터 실험 7종
사내 규정 문서 3종으로 답하고 출처를 붙이는 Q&A API를 만든 뒤, 청크 크기·top-k·threshold를 한 번에 하나씩만 바꿔 가며 골든 세트 10문항으로 측정한 실험.
주요 기여
청크 크기, top-k, threshold를 하나씩만 바꿔가며 7가지 조합을 재봤습니다. 교재에 있는 threshold 기본값을 그대로 쓰면 이 문서에서는 근거가 하나도 안 걸린다는 걸 알게 됐고, 같은 설정을 여러 번 돌려도 결과가 흔들려서 그 폭부터 먼저 쟀습니다.
청크 크기·top-k·threshold 조합 중 어떤 것이 나은지 판단해야 했는데, 1회 측정으로 조합을 고르면 1문항 차이가 조합의 차이인지 노이즈인지 구분할 수 없었습니다.
통과/실패 개수가 아니라 '왜 이 조합인지' 설명 가능한 상태로 파라미터를 채택하는 것.
A~G 7개 조합을 한 번에 하나씩만 바꿔 측정했습니다(기준 400/4/0.3, 청크 200·800·100, top-k 8, threshold 0.7, 조합). 실패를 ㉠ 근거를 못 찾아 거절 / ㉡ 근거는 찾았으나 오답으로 유형 분류하고, 정답 문자열뿐 아니라 출처(src)까지 검사하는 채점을 넣었습니다. temperature 0.0에서도 같은 설정이 10/10 → 9/10으로 흔들리는 것을 반복 측정으로 확인해 노이즈 기준선으로 삼았습니다.
100토큰으로 잘게 자르자 내용 키워드는 맞지만 출처가 뒤바뀌는 실패가 나왔고(배송 질문에 반품 규정을 근거로 삼음), 청크를 800으로 키우자 통과율은 같은데 실패 유형이 오답 → 거절로 바뀌었습니다. 어떤 조합도 구어체 8번 문항은 고치지 못했습니다.
A(400 · top-k 4 · threshold 0.3)를 채택했습니다 — G와 통과율이 같은데 근거를 절반만 넣어 토큰 비용이 쌉니다. 8번 문항은 청크·top-k·threshold가 '검색 대상'을 바꿀 뿐 '질문 자체'를 바꾸지 못하는 사례로 분류해 HyDE·MultiQuery가 필요한 문제로 남겼고, overlap 실험은 splitter에 옵션이 없어 실행하지 못했다는 것도 이유와 함께 기록했습니다.
통과율이 같아도 실패의 내용은 읽어야 합니다. 틀린 답과 거절은 사용자에게 다른 경험입니다. 교재 기본값이 내 데이터에서도 맞으리라는 보장이 없다는 것도 숫자로 확인했습니다.