RAG 를 붙이기 전에 물어야 할 세 가지

검색을 붙이면 모델이 우리 데이터를 안다고 생각하기 쉽다. 붙여 보면 대개 세 곳에서 막힌다.

1. 그 문서를 사람이 읽으면 답이 나오는가

사람이 읽어도 답을 못 찾는 문서는 검색을 붙여도 답이 안 나온다. RAG 는 검색 품질을 올리는 장치지 문서를 쓰는 장치가 아니다.

가장 흔한 실패는 여기서 시작된다 — 사내 위키가 오래되어 서로 모순되는데, 그걸 그대로 색인하고 모델이 헷갈린다고 프롬프트를 고친다.

2. 청크를 나누는 기준이 문서 구조와 맞는가

글자 수로 자르면 표 한가운데가 잘리고, 그 조각은 어떤 질문에도 도움이 안 된다. 제목 단위로 자르고, 잘린 조각에 원래 어느 절이었는지를 남긴다.

3. 틀린 답과 "모르겠다" 중 무엇이 더 싼가

이 답이 정해지지 않으면 검색 임계값을 정할 수 없다. 고객 응대라면 "모르겠다" 가 싸고, 내부 탐색이라면 틀린 답이 낫다. 같은 시스템이라도 화면마다 답이 다르다.

세 가지에 답한 뒤에 벡터 DB 를 고른다. 순서를 뒤집으면 도구부터 정해 놓고 그 도구가 풀 수 있는 문제로 요구사항을 깎게 된다.