문서·이미지·오디오 수집과 인덱스 설계

여기서 도메인이 바뀝니다. 앞의 일곱 노트가 「무엇으로 만들고 누가 부르고 무엇이 오가는가」였다면, 이제부터는 데이터를 어떻게 들여오는가입니다. 시험 문항도 성격이 달라집니다 — 서비스를 고르는 문제 대신 구성 값을 고르는 문제가 나오고, 그중 상당수가 「지금 바꿀 수 있는가, 다시 만들어야 하는가」를 묻습니다. 앞 노트에서 검색의 세 갈래와 청킹의 기본을 봤으니, 이 노트는 그 앞단인 수집 파이프라인을 세웁니다.

데이터 원본 연결

지원하는 원본

데이터 원본은 인덱서가 읽어 갈 곳을 등록해 둔 정의입니다. Azure AI Search가 직접 끌어올 수 있는 곳이 정해져 있고, 목록에 없는 곳은 우리가 직접 문서를 밀어 넣어야 합니다.

원본의 종류가 뒤에 오는 것을 정합니다. 파일 창고에서 끌어오면 문서를 열고 텍스트를 뽑는 단계가 필요하고, 데이터베이스에서 끌어오면 그 단계가 없는 대신 어느 열을 어느 필드로 보낼지를 정해야 합니다.

인증

원본을 등록할 때 연결 문자열을 적는 길과 관리 ID로 붙는 길이 있습니다. 앞 노트에서 본 그 선택이고, 관리 ID로 붙으면 Search 서비스 자신의 신원에 원본 쪽 데이터 읽기 역할이 배정돼 있어야 합니다. 「인덱서가 403으로 멈췄다」가 이 자리에서 가장 많이 납니다.

인덱서

세 부품

인덱서는 원본에서 읽어 색인에 넣는 일을 주기적으로 도는 작업이고, 세 부품을 잇습니다 — 데이터 원본, 색인, 그리고 선택 사항인 기술 집합입니다. 기술 집합은 읽은 내용을 색인에 넣기 전에 가공하는 단계의 묶음으로, 문자를 읽어 내는 OCR·문서를 조각내는 분할·조각을 벡터로 바꾸는 임베딩 같은 것이 여기 들어갑니다.

가공 단계가 있으면 필드 매핑이 둘로 갈립니다. 원본의 값을 그대로 색인 필드에 보내는 매핑과, 가공해서 새로 생긴 값을 색인 필드에 보내는 매핑입니다. 전자는 원본의 열 이름과 필드 이름이 다를 때 쓰고, 후자는 기술 집합이 만든 결과를 담을 때 씁니다. 둘을 헷갈려 적으면 색인에 필드는 있는데 값이 비는 증상이 납니다.

실행과 일정

인덱서는 한 번 돌릴 수도 있고 일정을 걸어 반복시킬 수도 있습니다. 한 번 실행에는 처리 시간 상한이 있어 문서가 많으면 한 번에 다 못 끝내는데, 이때 중단된 자리를 기억해 다음 실행이 이어받습니다. 그래서 「문서가 수십만 건인데 인덱서가 다 안 돈다」의 답은 대개 잘못된 구성이 아니라 여러 번 돌게 두는 것입니다.

변경 탐지와 삭제

두 번째 실행부터는 바뀐 것만 처리하는 것이 증분 인덱싱이고, 무엇이 바뀌었는지 아는 방식이 원본마다 다릅니다.

삭제는 따로입니다. 원본에서 행이나 파일을 지워도 인덱서는 없어진 것을 볼 수 없어 색인에 그대로 남습니다. 지우려면 「이 값이 붙은 문서는 삭제된 것으로 친다」는 규칙을 미리 정해 두고, 지울 때 지우는 대신 그 표시를 남기는 방식으로 운영합니다. 「원본에서 지운 문서가 검색에 계속 나온다」는 문항의 답이 여기입니다.

인덱스 스키마

필드 타입과 속성

색인은 필드 목록이 곧 스키마입니다. 필드마다 타입이 있고, 그 위에 무엇을 할 수 있는지를 정하는 속성이 붙습니다.

가장 자주 헷갈리는 짝이 searchable과 filterable입니다. searchable은 값을 토큰으로 쪼개 그중 하나만 맞아도 걸리게 하는 것이고, filterable은 값 전체가 정확히 맞는지를 보는 것입니다. 그래서 제품 범주처럼 골라 거를 값은 filterable이지 searchable이 아니고, 본문처럼 낱말로 찾을 값은 그 반대입니다. 둘 다 켜는 것은 가능하지만 색인 크기를 그만큼 더 씁니다.

{
  "name": "docs",
  "fields": [
    { "name": "id",       "type": "Edm.String", "key": true, "filterable": true },
    { "name": "content",  "type": "Edm.String", "searchable": true, "retrievable": true },
    { "name": "category", "type": "Edm.String", "filterable": true, "facetable": true },
    { "name": "updated",  "type": "Edm.DateTimeOffset", "filterable": true, "sortable": true },
    { "name": "vector",   "type": "Collection(Edm.Single)", "searchable": true,
      "dimensions": 1536, "vectorSearchProfile": "default" }
  ]
}

벡터 필드가 Collection(Edm.Single)이고 차원 수를 함께 적는 것이 눈에 띕니다. 차원은 그 임베딩 모델이 내는 값의 길이라 모델을 바꾸면 이 숫자가 바뀌고, 숫자가 바뀌면 같은 색인에 두 모델의 벡터를 섞어 담을 수 없습니다.

변경할 수 없는 속성

이 절에서 가장 자주 나오는 문항입니다. 색인에 필드를 더하는 것은 됩니다. 이미 있는 필드의 이름이나 타입을 바꾸거나 filterable·sortable·facetable 같은 속성을 나중에 켜는 것은 안 됩니다 — 그 속성이 색인을 만들 때 자료 구조를 함께 세우기 때문입니다. 바꾸려면 색인을 새로 만들고 문서를 다시 넣어야 합니다.

그래서 설계 순서가 정해집니다. 나중에 거르거나 정렬할 것 같은 필드는 처음부터 그 속성을 켜 두는 편이 낫고, 반대로 결과에 실어 보낼 필요가 없는 큰 텍스트는 retrievable을 꺼 응답을 가볍게 합니다. retrievable은 저장 구조와 무관해 뒤에 바꿀 수 있는 몇 안 되는 속성입니다.

형식별 수집 경로

문서

PDF·Word·HTML 같은 파일은 인덱서가 열어 텍스트와 메타데이터를 뽑습니다. 파일 안의 구조를 살리고 싶으면 구문 분석 방식을 지정해 줄로 된 파일이나 JSON 배열을 각각 문서 하나로 갈라 읽게 할 수 있습니다.

이미지

이미지는 두 갈래입니다. 문서 안에 박힌 이미지는 인덱서가 따로 꺼내도록 설정해야 보이고, 그 뒤에 문자를 읽는 기술이나 장면을 설명하는 기술을 걸어야 텍스트가 나옵니다. 설정을 안 하면 그림은 통째로 무시되고 주변 글자만 색인됩니다. 스캔한 PDF가 검색에 하나도 안 걸리는 증상이 이것입니다.

오디오와 비디오

인덱서는 소리를 직접 못 읽습니다. 그래서 경로가 한 단계 길어집니다 — 먼저 음성을 텍스트로 만들거나 분석기로 내용을 뽑아 그 결과를 저장한 뒤, 그 텍스트를 색인합니다. 시험이 「회의 녹음을 검색 가능하게 하라」를 물으면 답은 인덱서 설정 하나가 아니라 이 두 단계이고, 보기에는 「Search 인덱서에서 오디오를 켠다」 같은 그럴듯한 오답이 섞여 나옵니다.

청킹과 투영

분할 기술과 겹침

문서를 통째로 한 벡터로 만들면 긴 문서일수록 뜻이 뭉개지고, 검색에 걸려도 어디를 읽어야 할지 알 수 없습니다. 분할 기술이 문서를 조각으로 자르고, 조각 길이와 겹침 길이를 값으로 받습니다. 겹침은 조각 경계에서 문장이 잘려 뜻이 끊기는 것을 줄이려고 앞 조각의 끝을 다음 조각에 조금 물리는 것입니다.

인덱스 투영

여기서 한 번 갈립니다. 원본 문서 하나가 조각 여럿이 되는데 색인의 문서는 하나이므로, 조각을 어디에 담을지 정해야 합니다.

RAG에서는 두 번째가 기본입니다. 찾아낸 조각을 그대로 모델에 넣어야 하는데 첫 번째 방식은 결국 문서 전체를 다시 들고 와야 하기 때문입니다. 대신 조각 문서에는 원본을 가리키는 키를 같이 담습니다 — 앞 노트에서 본 프로버넌스가 그 키 위에 서고, 사용자에게 「이 답은 이 문서의 이 부분에서 나왔다」를 보일 수 있게 됩니다.

연습 문제

1. Blob Storage의 PDF를 색인하는 인덱서가 매 실행마다 403으로 실패합니다. 데이터 원본은 관리 ID로 등록했습니다. 확인할 곳은?
   ① 색인의 key 필드가 문자열인지
   ② Search 서비스의 관리 ID에 스토리지 읽기 역할이 있는지
   ③ 인덱서 일정이 너무 촘촘한지
   ④ 기술 집합에 OCR이 붙어 있는지

   ②. 관리 ID로 붙는 구성이므로 그 신원에 원본 읽기 역할이 배정돼 있어야 합니다. 나머지 셋은 읽기 권한과 무관합니다.
2. 운영 중인 색인의 category 필드로 결과를 거르려 합니다. 이 필드는 만들 때 searchable만 켜 두었습니다. 해야 할 일은?
   ① 필드 정의에서 filterable을 켜고 인덱서를 다시 돌린다
   ② 색인을 새로 만들어 filterable을 켠 채로 문서를 다시 넣는다
   ③ retrievable을 켜면 거를 수 있다
   ④ 질의에서 $filter 대신 검색어로 찾으면 된다

   ②. filterable은 나중에 켤 수 없는 속성이라 색인을 다시 만들어야 합니다. ③은 결과에 실어 보내는 속성일 뿐이고, ④는 토큰 단위로 걸려 정확한 거르기가 되지 않습니다.
3. 위 JSON에서 임베딩 모델을 차원이 다른 모델로 바꿨습니다. 일어나는 일은?
   ① 차원 값만 고치면 기존 벡터와 함께 쓸 수 있다
   ② 벡터 필드의 차원이 맞지 않아 새 색인이 필요하다
   ③ 검색 품질만 조금 떨어진다
   ④ 인덱서가 자동으로 기존 벡터를 변환한다

   ②. 차원은 벡터 필드의 정의에 박히는 값이고 한 필드에 서로 다른 길이의 벡터를 담을 수 없습니다. ④ 같은 변환은 일어나지 않습니다.
4. 원본 데이터베이스에서 행을 지웠는데 검색 결과에 계속 나옵니다. 원인은?
   ① 인덱서 일정이 걸려 있지 않다
   ② 인덱서는 삭제를 스스로 알 수 없어 삭제 표시 규칙이 필요하다
   ③ 색인에 key 필드가 없다
   ④ 변경 추적이 꺼져 있다

   ②. 변경 탐지는 바뀐 행을 찾아 주지만 없어진 행은 읽을 것 자체가 없습니다. 지우는 대신 표시를 남기고 그 표시를 삭제로 해석하게 구성합니다.
5. 스캔한 PDF 수천 장을 색인했는데 검색에 하나도 안 걸립니다. 가장 먼저 볼 곳은?
   ① 벡터 필드의 차원
   ② 문서 안 이미지를 꺼내는 설정과 문자 인식 기술이 걸려 있는지
   ③ 인덱서의 변경 탐지 방식
   ④ 색인의 retrievable 속성

   ②. 스캔 PDF는 글자가 그림으로 들어 있어 그냥 열어서는 텍스트가 안 나옵니다. 이미지를 꺼내는 설정과 문자 인식을 함께 걸어야 합니다.
6. 사내 회의 녹음을 검색 가능하게 만들어야 합니다. 올바른 경로는?
   ① Search 인덱서에 오디오 원본을 등록하면 자동으로 전사된다
   ② 먼저 음성을 텍스트로 만들어 저장한 뒤 그 텍스트를 색인한다
   ③ 오디오 파일을 벡터 필드에 그대로 넣는다
   ④ 기술 집합의 분할 기술이 오디오를 조각내 처리한다

   ②. 인덱서는 소리를 직접 못 읽으므로 텍스트로 만드는 단계가 앞에 서야 합니다. ①은 그럴듯하지만 없는 기능이고, ④의 분할 기술은 텍스트를 자르는 것입니다.
7. RAG 앱이 찾은 조각만 모델에 넣도록 색인을 설계합니다. 알맞은 방식은?
   ① 문서 하나에 조각 배열을 필드로 담는다
   ② 조각 하나를 색인 문서 하나로 만들고 원본 키를 함께 담는다
   ③ 조각을 나누지 않고 문서 전체를 한 벡터로 만든다
   ④ 조각을 별도 스토리지에만 저장한다

   ②. 조각 단위로 찾아 그 조각만 넣어야 하므로 조각이 검색 단위가 되어야 합니다. 원본 키를 함께 담아야 출처를 되짚을 수 있습니다.

이 절의 문항은 대개 지금 바꿀 수 있는가로 갈립니다. 필드를 더하는 것과 속성을 켜는 것, 인덱서를 다시 돌리는 것과 색인을 새로 만드는 것의 차이를 붙잡아 두면 보기가 빠르게 줄어듭니다.