RAG는 질문과 비슷한 문단을 찾아 모델에 전달하지만, 그 문단이 정확한 근거인지까지 확인하지는 않는다. 복잡한 질문에서는 관련 있어 보이는 조각이 실제 조건이나 예외를 놓칠 수 있고, 모델은 그 자료를 바탕으로 틀린 답을 만들 수 있다. 생성 결과와 함께 검색 결과의 품질도 확인해야 한다.
문서를 나눌 때 구조가 사라질 수 있다
문서를 일정한 토큰 수로만 나누면 헤딩·문서 경계·표의 행과 열처럼 의미를 판단하는 구조가 사라질 수 있다. 벡터 유사도만 비교하면 "이 조항이 저 조항의 예외"이거나 "이 수치는 3분기에만 해당한다"는 관계를 놓치기 쉽다.
검색 결과에 관련 없는 조각이 섞이거나 필요한 문단이 빠지면 생성 모델도 충분한 근거를 사용할 수 없다. 따라서 RAG를 평가할 때는 최종 답의 정확도와 함께 정답 근거가 검색 결과에 포함됐는지, 상위 결과에 불필요한 문서가 얼마나 섞였는지를 따로 측정해야 한다.
긴 컨텍스트가 항상 검색을 대신하지는 않는다
긴 컨텍스트를 지원하는 모델은 문서를 통째로 넣는 선택지를 넓혔다. 한 문서 안의 명확한 사실을 찾는 과제에서는 별도 검색 없이도 좋은 결과를 낼 수 있다. 하지만 이런 과제의 점수를 여러 문서의 조건과 예외를 종합하는 업무에 그대로 적용하기는 어렵다.
여러 문서를 교차 참조하거나 흩어진 값을 모으는 과제에서는 입력 길이와 정보 위치에 따라 정확도가 달라질 수 있다. 긴 입력의 가운데 있는 정보를 덜 활용하는 ‘lost in the middle’ 현상도 여러 연구에서 관찰됐다. 모델과 과제마다 차이가 크므로 자체 문서 길이와 질문 유형으로 평가해야 한다.
비용과 지연도 함께 비교해야 한다. 긴 문서를 매번 모두 넣는 방식은 필요한 부분만 검색하는 방식보다 훨씬 많은 토큰을 쓸 수 있다. 문서 크기와 질문 유형에 따라 전체 입력과 검색을 나눠 쓰는 판단이 필요하다.
관계 그래프가 도움이 되는 경우
GraphRAG는 문서에서 엔티티와 관계를 추출해 검색에 구조 정보를 더한다. "이 회사의 자회사가 소유한 특허"처럼 여러 관계를 따라가야 하는 질문에는 도움이 될 수 있다. 반면 모든 문서와 질문에 그래프가 필요한 것은 아니다.
그래프를 만들고 갱신하는 데는 추출 비용과 품질 관리가 필요하다. 관계를 잘못 추출하면 검색 결과도 잘못 연결되고, 문서가 자주 바뀌면 그래프 갱신 지연이 생긴다. 먼저 어떤 질문에 관계 탐색이 필요한지 정하고 그 범위의 엔티티와 관계만 관리하는 편이 현실적이다.
검색 구조와 검증을 함께 설계한다
작은 팀은 다음 세 가지부터 적용할 수 있다.
- 문서 구조를 메타데이터로 남겨라. 문서를 나눌 때 헤딩·표·문서 경계를 함께 저장하면 검색 결과가 어느 문맥에 속하는지 확인할 수 있다.
- 필요한 경우 다시 검색하라. 첫 결과에 근거가 부족하면 질의를 바꿔 추가 검색하되 최대 반복 횟수와 중단 조건을 정한다.
- 권한과 근거를 검색 단계에서 확인하라. 에이전트는 사용자의 접근 권한 안에서만 문서를 검색해야 한다. 답을 만들기 전에는 검색된 문장이 질문의 조건과 시점에 실제로 맞는지 확인한다.
RAG의 품질은 생성 모델뿐 아니라 문서를 나누는 방식, 메타데이터, 권한, 검색 후 검증에 달려 있다. 벡터 검색은 유사성을 찾는 도구이므로 사실 여부와 관계 정보는 별도로 확인해야 한다. 도메인의 문서 구조와 예외 관계를 검색 단계에 보존하면 근거가 맞지 않는 답을 줄일 수 있다.