08. 고급 인덱싱
작은 청크는 검색할 내용을 선명하게 만들지만 답변에 필요한 배경을 잃을 수 있다. 큰 청크는 배경이 충분한 대신 여러 주제가 섞여 검색이 둔해질 수 있다. 이 장은 검색할 표현과 생성에 전달할 원문을 반드시 같은 크기로 둘 필요는 없다는 데서 출발한다.
8.1 RAG 정확도 개선
8.1.1 자료 적재 단계
적재에서는 무엇을 청크로 만들고 어떤 벡터로 검색할지 결정한다. 같은 문서도 제목, 짧은 문장, 요약과 예상 질문 중 무엇을 임베딩하느냐에 따라 다른 질문에 반응할 수 있다.
원문 추출이 틀렸거나 제목과 본문의 관계를 잃었다면 임베딩 모델을 키워도 충분하지 않을 수 있다. 청크의 본문과 메타데이터, 원문으로 돌아갈 식별자를 함께 봐야 한다.
8.1.2 질문과 답변 단계
적재가 괜찮아도 질문이 모호하거나 구조화된 데이터가 다른 DB에 있으면 검색에 실패할 수 있다. 검색 결과에 잡음이 많으면 생성 모델에 전달하기 전의 필터와 재정렬이 필요하다.
8장은 자료 준비를, 9장은 질문 변환을, 10장은 검색 대상 선택과 결과 후처리를 다룬다. 실패가 생긴 위치에 맞춰 수정해야 한다.
8.2 고급 문서 인덱싱
기본 전략은 원문 청크 하나에 벡터 하나를 붙이는 것이다. 고급 전략은 검색에 유리한 여러 표현을 같은 원문에 연결한다.
검색용 자식 청크나 요약이 적중하면 답변에는 더 넓은 부모 문서를 돌려줄 수 있다. 이때 검색 단위와 합성 단위가 나뉜다.
| 단위 | 목적 | 예시 |
|---|---|---|
| 검색 표현 | 질문과 잘 대응하는 후보 찾기 | 짧은 청크, 요약, 예상 질문 |
| 합성 자료 | 생성 모델이 사실과 조건을 읽기 | 원문 절, 부모 청크, 표, 이미지 |
| 연결 정보 | 검색 결과에서 원문 복원 | 부모 ID, 문서 ID, 위치 |
검색 표현은 색인이지 최종 사실의 대체물이 아니다. 요약에 생긴 오류를 답변의 근거로 쓰지 않으려면 원문과 연결을 유지해야 한다.
8.3 분할 전략
8.3.1 구조 기반과 크기 기반
구조 기반 분할은 장, 절, 제목과 문단 같은 원문의 경계를 따른다. 같은 주제의 문맥을 유지하기 쉽지만 청크 길이가 고르지 않을 수 있다.
크기 기반 분할은 문자, 토큰, 문장 등의 길이를 기준으로 나눈다. 처리량과 길이 예산을 관리하기 쉽지만 정의와 예외, 표 제목과 표 본문을 갈라 놓을 수 있다.
두 방식은 조합할 수 있다. 먼저 제목 단위로 나누고 너무 긴 절만 토큰 기준으로 다시 나누는 식이다. 제목 계층을 메타데이터로 보존하면 조각의 배경을 복원하는 데 도움이 된다.
8.3.2 고려할 조건
문서 형식과 질문 유형을 함께 봐야 한다. API 문서에서 특정 파라미터를 묻는 질문과 제품 전반의 차이를 묻는 질문은 필요한 범위가 다르다.
표와 이미지가 섞인 문서는 앞뒤 설명을 떼면 의미가 깨질 수 있다. 숫자가 속한 행과 열의 제목, 단위, 각주까지 유지해야 한다.
8.3.3 선택 기준
청크 크기에 일반적인 정답은 없다. 대표 질문에 필요한 근거가 반환되는지, 반환된 원문만으로 답할 조건을 이해할 수 있는지 비교해야 한다.
작은 청크에서 Recall@k가 좋아져도 모델에 전달할 문맥이 너무 짧으면 최종 답은 나빠질 수 있다. 반대로 부모 청크를 많이 넣으면 검색은 정확해도 문맥 비용이 커진다.
평가에는 검색된 근거와 최종 답을 따로 남긴다. 청크 크기만 바꾸고 반환 개수와 문맥 길이를 무시하면 비교가 공정하지 않을 수 있다.
8.3.4 HTML 제목으로 분할
HTMLHeaderTextSplitter는 HTML의 제목 계층을 기준으로 나눌 수 있다. 여행 문서라면 지역 아래 교통, 볼거리, 숙박 같은 절을 유지하는 데 유용하다.
다만 실제 웹페이지의 제목 구조가 의미를 잘 표현한다는 보장은 없다. 메뉴와 반복 제목이 섞이거나 본문이 잘못 중첩될 수 있으므로 추출된 청크와 메타데이터를 직접 확인해야 한다.
8.4 임베딩 전략
그림에서 중요한 것은 검색에 적중한 작은 내용으로부터 답변에 필요한 넓은 원문을 찾는 연결이다. 모든 구현이 부모와 자식 벡터를 둘 다 자동 생성한다는 뜻은 아니다. 사용하는 Retriever에 따라 실제로 색인하는 대상과 반환하는 대상이 다르다.
8.4.1 ParentDocumentRetriever
원문을 부모 청크로 나누고 그 안을 더 작은 자식 청크로 나눈다. 검색은 자식의 임베딩을 이용하고, 일치한 자식이 가리키는 부모를 문서 저장소에서 가져오는 것이 기본 패턴이다.
“공항에서 역으로 가는 마지막 버스 시간” 같은 질문이 짧은 문장에 적중해도, 주변 문단을 함께 받으면 운행 요일과 예외 조건을 볼 수 있다.
부모가 지나치게 크면 관련 없는 내용까지 반환한다. 여러 자식이 같은 부모를 가리키면 부모의 중복을 제거해야 한다.
8.4.2 MultiVectorRetriever
하나의 원문에 여러 검색 표현을 연결하는 더 일반적인 구조다. 벡터 저장소에는 검색 표현과 부모 ID를, 문서 저장소에는 ID에 대응하는 원문을 둔다.
검색 표현은 자식 청크일 수도 있고 요약이나 예상 질문일 수도 있다. 핵심은 한 원문과 여러 벡터의 다대일 관계다.
두 저장소 중 하나만 갱신하면 연결이 깨진다. 벡터에는 ID가 있는데 원문이 없거나 원문은 바뀌었는데 오래된 요약 벡터가 남을 수 있다. 재색인과 삭제도 두 계층에서 일관되게 처리해야 한다.
8.4.3 문서 요약 임베딩
긴 청크 전체보다 요약이 주제를 뚜렷하게 나타낼 수 있다. 요약의 임베딩으로 후보를 찾고 원문을 반환하면 검색 표현의 간결함과 원문의 상세함을 나눠 활용할 수 있다.
하지만 요약에서 빠진 정보는 그 검색 표현으로 찾기 어려워진다. 원문 임베딩과 요약 임베딩을 함께 사용할지, 어떤 질문에서 각각 유효한지 확인해야 한다.
요약 생성 비용도 인덱싱 비용에 포함된다. 원문이 바뀌면 요약과 그 임베딩도 다시 만들어야 한다.
8.4.4 가상 질문 임베딩
각 원문이 답할 수 있는 질문을 모델로 생성해 색인한다. 사용자의 질문과 원문의 서술 방식이 다를 때 질문끼리의 유사성을 이용하려는 방법이다.
예를 들어 원문이 버스 노선과 시간표를 설명한다면 “차 없이 이곳에 갈 수 있는가?” 같은 질문을 색인할 수 있다. 검색에 적중하면 생성한 질문이 아니라 실제 원문을 반환한다.
생성한 질문이 원문에서 답할 수 없는 내용을 묻는다면 잘못된 후보를 끌어올 수 있다. 질문 수를 늘리는 것뿐 아니라 실제로 해당 원문이 근거가 되는지도 확인해야 한다.
8.5 작은 청크의 문맥 확장
검색은 작은 청크로 하고 일치한 위치 앞뒤의 청크를 추가한다. 부모 청크 반환과 비슷하지만 고정된 부모 경계 대신 문서 위치를 기준으로 주변을 가져올 수 있다.
필요한 메타데이터는 원문 ID와 청크 순서다. 다른 문서의 이웃 청크를 잘못 붙이거나 문서 경계 밖으로 넘어가면 안 된다.
여러 검색 결과의 확장 구간이 겹치면 중복을 합쳐야 한다. 청크 하나가 적중했다고 앞뒤를 무조건 많이 넣으면 검색 정밀도의 이점이 사라진다.
8.6 반정형 자료
표는 문장처럼 잘라 처리하면 행과 열의 관계를 잃을 수 있다. 책은 표의 요약을 검색 표현으로 만들고 실제 표는 별도로 보관하는 방식을 다룬다.
질문이 표 요약에 적중하면 모델에는 원래 표를 전달한다. 요약은 “지역별 요금 비교표”라는 검색 단서가 될 수 있지만 실제 요금을 답하려면 행과 열의 값이 필요하다.
단위와 날짜, 각주도 표의 일부다. 모델에 표만 던지고 열의 의미를 추측하게 하는 것보다 구조를 명시적으로 보존해야 한다.
8.7 멀티모달 RAG
이미지 설명을 텍스트로 생성해 검색하고, 적중한 이미지 원본을 답변 모델에 보내는 구조로 확장할 수 있다. 또 다른 선택은 이미지와 텍스트를 직접 비교하는 멀티모달 임베딩이다.
텍스트 요약만 받는 모델과 이미지까지 이해하는 모델은 전달할 수 있는 근거가 다르다. 차트의 수치나 도형 관계가 설명에서 빠지면 텍스트 경로만으로 정확한 답을 얻기 어려울 수 있다.
원본 이미지의 해상도와 자르기, OCR과 설명 품질도 영향을 준다. 검색된 이미지가 맞는지와 모델이 이미지를 정확히 읽었는지는 따로 평가해야 한다.
질문
작은 청크를 검색했으면 그대로 답변에 넣어야 할까?
검색 표현과 답변 근거의 크기는 다를 수 있다. 필요한 조건을 읽을 수 있도록 부모나 주변 문맥을 반환하는 방법이 있다.
한 문서에 벡터를 많이 붙이면 항상 좋아질까?
중복 후보와 색인 비용이 늘고 부정확한 검색 표현이 추가될 수 있다. 어떤 질문을 더 잘 찾는지와 문맥 비용을 함께 비교해야 한다.